Re: tc not matching

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Jonathan Gazeley wrote:

Results appended. Sadly everything seems to show zero bytes. I checked that everything is flowing through the correct interface, and yes it appears to do so. This box has 3 interfaces. eth0 is the one facing the NAT clients, eth1 is the public internet connection and eth2 is a management interface. Only ssh traffic to my workstation is flowing on eth2. I see two-way FTP traffic flowing on eth1 (I am downloading large files from an FTP server for testing) but on eth0, i only see traffic LEAVING the NAT clients and entering my shaping box. I have no idea why I don't see traffic with destination of the NAT clients. There is no way that the traffic could be "leaking" around my shaping box - eth0 is physically connected to a 5 port switch with my test clients on.

That's strange - so there are no vlans involved and tcpdump -nnei eth0 only sees traffic coming in?

If the nic is a gig eth, I wonder if its drivers are doing something strange to do with segmentation offload. You should be able to turn it off with ethtool.

ethtool -k eth0 to see if it is on and turn it off with

ethtool -k eth0 tso off

FWIW I tried browsing with this setup and downloading aswell and it's not very nice with such a long queue. An ISP/teleco would never have that long a fifo on a 128kbit line. It would be better to add an sfq to the bulk class or limit the length of the fifo.
Sorry for such a simplistic question - how might this be done? However I'm not overly worried about making the quality of service perfect - I just need it to be limited bandwidth. The reason why I want such a restricted service is because the shaped NAT clients of this box are going to be the "naughty" users on the university network who will have their 100Mbit service reduced to 128kbit for a week as punishment for rulebreaking etc. So if people complain about the occasional dropped packet - they shouldn't have been downloading copyright material in the first place!

Ahh I see - actually packet loss could make things nicer by getting the tcp senders congestion control to back off. The command for sfq would be

tc qdisc add dev $LAN parent 1:b$total handle b$total: sfq limit 30

in the loop under the bulk class.

You could just have pfifo instead of sfq if you wanted, and the limit of 30 can be changed. sfq has a parameter called perturb, which can make it fairer at the expense of packet reordering, but it can also make single downloads back off a bit too much, so I didn't use it.

The script is not the best example bash wise as I just adapted it from the one you started with. It could be done better - eg my mixing of hex and decimal for class ids is not ideal and total is not needed as such, but it should work.


LARTC mailing list

[Bugtraq]     [Fedora Legacy]     [GCC Help]     [Yosemite News]     [Yosemite Photos]     [IP Tables]     [Netfilter Devel]     [Fedora Users]

Powered by Linux