Prior to a recent update on NS 6.6, traffic shaping worked as advertised. Now, just enabling traffic shaping, for me, is throttling bandwidth down to 5% of my speed for http and https traffic, even though I don’t have rules for those ports. Inbound and outbound interface speeds are correct. I’m comparing an NS 6.6 system that hasn’t been updated with one that has all recent updates. I have tried deleting and re-entering the interface speeds, as well as using very, very large numbers for those speeds. It acts as if a global low-priority rule is in effect for all traffic as soon as traffic shaping is enabled, whereas I believe the docs say that high priority is the default. Thanks.
If it helps, the working system kernel release is 2.6.32-504.12.2.el6.x86_64, the one with the issue is …16.2.el6…
I think I’ve seen something similar (slowdowns) in the past, but my investigation led to nothing. First I made the idea that shaping has problems with high bandwidth links, then it seemed that asymmetrical links have problems. But I was never able to reproduce results.
You seems to have found the culprit: the kernel version. I’ll try to reproduce the problem again.
I did a dump of the shorewall config in three versions: 1) new kernel, no traffic shaping, 2) new kernel with traffic shaping, 3) old kernel with traffic shaping. I have the output in a file that I could send to you – I don’t think I can attach it here – or I can dump it into a post, but it’s pretty long. What would you prefer?
I upgraded the machine with the working traffic shaping from the 12.2 kernel to 16.2, and traffic shaping continues to work fine. This is an older 32-bit machine, Pentium D, whereas the machine with the problem is a 64-bit Intel core i5. So the issue may come down to 32 vs 64-bit kernel, or perhaps some other hardware difference?