Re: tc not matching
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Jonathan Gazeley wrote:
Hi Andy,Thanks a bunch for your help - really good of you to put time into helping a newbie.Andy Furniss wrote:I managed to have a play - CBQ doesn't seem too accurate it let netperf get throughput of about 180kbit. HTB was OK so I used that.I was only using CBQ because that's what was being used in the tutorials and howtos I looked at - there doesn't seem to be a massive amount of documentation out there. My script was basically a copy & paste job... If you recommend HTB then I'll give it a try.
OK - I just noticed I forgot to change ... match ip src 172.19.123.$i ... back to match dst so if you copy & paste mine you'll need to.
If you have a multicore/smp CPU you shouldn't use CPU as a clocksource. I don't know how much memory this does/could use, if you don't specify child qdiscs htb uses pfifos with a length taken from txqueuelen (1000 on eth) so that adds up to quite a bit. With window scaling on and a netperf running for each IP I managed to backlog >200 packets on each.It runs on relatively sporty hardware and doesn't do anything other than NAT and shaping, so I don't think memory usage is really a problem. It has dual processors so I guess that means I shouldnt use CPU as a clocksource.
Yes I guess so - I havent got anything other than uniprocessors so don't know what's best. Whatever you choose I would still use Hz 1000 as HTB is a bit more accurate that way. I also haven't tried no Hz yet so don't know what that's like.
Rather than police you could, if using recentish 2.6 use ifb and have the same setup on ingress eth0. Or if you don't do nat on the same box on the wan. If you do do nat and don't have ifb then you need to use netfilter to mark by ip and match the marks.This box is also a NAT box, so I'll do marking with iptables to sort the incoming traffic. I read about it somewhere on Google so I'm sure I can manage! If I'm marking packets with iptables, would it be better to shape them as they leave on the internal interface, rather than doing something with ingress on the external interface?What is ifb? For once, Google doesn't seem to turn up much.
You have it already if modprobe ifb ip link set up dev ifb0works for you, if not it's called intermediate functional block under netdevices in kernel config.
If you had ifb then you could just use the same script with the different rates and tc src match. No need to use netfilter as you could direct the incoming traffic on eth0 to the ifb0 device with a tc filter and it would be shaped before any NAT happened.
tc filter add dev eth0 ingresstc filter add dev eth0 parent ffff: protocol ip u32 match ip src 172.17.123.0/24 flowid 1:0 action mirred egress redirect dev ifb0
then just change the script so LAN=ifb0, the rates and ... match ip src ... But as you say you can also easily shape on wan and use netfilter marks.I assume your box only forwards traffic for 172.17.123.0/24 if there is traffic to and from the box its self then you need to decide whether it needs shaping aswell and make a filter to exempt it, or if it is to be shaped then you need to think about whether the nic, if it's gig eht does tcp segmentation offload. If it does you can turn it off with ethtool -k.
Cheers, Jonathan ------------------------ Jonathan Gazeley ResNet | Wireless & VPN Team Information Systems & Computing University of Bristol ------------------------
_______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc