Re: [LARTC] why isn't 1:1 getting the traffic? [filter question]
Andreas Hasenack wrote: With the below script, whenever I ping 10.0.16.10 (which matches the only filter I have), traffic still get's sent to the default 1:2 class instead of 1:1 and I don't know why... Any hints? (kernel 2.6.12, iproute2-2.6.15) tc qdisc del dev eth0 root /dev/null 21 tc qdisc add dev eth0 handle 1: root htb default 2 tc class add dev eth0 classid 1:1 parent 1: htb rate 100kbps ceil 100kbps quantum 1500 tc class add dev eth0 classid 1:2 parent 1: htb rate 90mbit ceil 90mbit quantum 1500 tc qdisc add dev eth0 handle 2: parent 1:2 sfq perturb 10 tc class add dev eth0 classid 1:10 parent 1:1 htb prio 0 rate 30kbps quantum 1500 tc qdisc add dev eth0 handle 10: parent 1:10 sfq perturb 10 tc class add dev eth0 classid 1:11 parent 1:1 htb prio 0 rate 70kbps ceil 100kbps quantum 1500 tc qdisc add dev eth0 handle 20: parent 1:11 sfq perturb 10 tc class add dev eth0 classid 1:12 parent 1:1 htb rate 60kbps ceil 100kbps quantum 1500 tc qdisc add dev eth0 handle 30: parent 1:12 sfq perturb 10 tc filter add dev eth0 parent 1:0 prio 1 protocol ip u32 \ match ip dst 10.0.16.10/32 \ flowid 1:1 It's because 1:1 isn't a leaf, you need more filters with parent 1:1 to filter to the leaves. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] why isn't 1:1 getting the traffic? [filter question]
With the below script, whenever I ping 10.0.16.10 (which matches the only filter I have), traffic still get's sent to the default 1:2 class instead of 1:1 and I don't know why... Any hints? (kernel 2.6.12, iproute2-2.6.15) tc qdisc del dev eth0 root /dev/null 21 tc qdisc add dev eth0 handle 1: root htb default 2 tc class add dev eth0 classid 1:1 parent 1: htb rate 100kbps ceil 100kbps quantum 1500 tc class add dev eth0 classid 1:2 parent 1: htb rate 90mbit ceil 90mbit quantum 1500 tc qdisc add dev eth0 handle 2: parent 1:2 sfq perturb 10 tc class add dev eth0 classid 1:10 parent 1:1 htb prio 0 rate 30kbps quantum 1500 tc qdisc add dev eth0 handle 10: parent 1:10 sfq perturb 10 tc class add dev eth0 classid 1:11 parent 1:1 htb prio 0 rate 70kbps ceil 100kbps quantum 1500 tc qdisc add dev eth0 handle 20: parent 1:11 sfq perturb 10 tc class add dev eth0 classid 1:12 parent 1:1 htb rate 60kbps ceil 100kbps quantum 1500 tc qdisc add dev eth0 handle 30: parent 1:12 sfq perturb 10 tc filter add dev eth0 parent 1:0 prio 1 protocol ip u32 \ match ip dst 10.0.16.10/32 \ flowid 1:1 Status after pinging 10.0.16.10 a few times (notice traffic on 1:2, but not on 1:1): qdisc htb 1: r2q 10 default 2 direct_packets_stat 0 ver 3.17 Sent 516 bytes 7 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 2: parent 1:2 limit 128p quantum 1514b flows 128/1024 perturb 10sec Sent 516 bytes 7 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 10: parent 1:10 limit 128p quantum 1514b flows 128/1024 perturb 10sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 20: parent 1:11 limit 128p quantum 1514b flows 128/1024 perturb 10sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 30: parent 1:12 limit 128p quantum 1514b flows 128/1024 perturb 10sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 class htb 1:11 parent 1:1 leaf 20: prio 0 quantum 1500 rate 56bit ceil 80bit burst 1669b/8 mpu 0b overhead 0b cburst 1699b/8 mpu 0b overhead 0b level 0 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 lended: 0 borrowed: 0 giants: 0 tokens: 24429 ctokens: 17408 class htb 1:1 root rate 80bit ceil 80bit burst 1699b/8 mpu 0b overhead 0b cburst 1699b/8 mpu 0b overhead 0b level 7 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 lended: 0 borrowed: 0 giants: 0 tokens: 17408 ctokens: 17408 class htb 1:10 parent 1:1 leaf 10: prio 0 quantum 1500 rate 24bit ceil 24bit burst 1629b/8 mpu 0b overhead 0b cburst 1629b/8 mpu 0b overhead 0b level 0 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 lended: 0 borrowed: 0 giants: 0 tokens: 55636 ctokens: 55636 class htb 1:2 root leaf 2: prio 0 quantum 1500 rate 9Kbit ceil 9Kbit burst 12836b/8 mpu 0b overhead 0b cburst 12836b/8 mpu 0b overhead 0b level 0 Sent 516 bytes 7 pkt (dropped 0, overlimits 0 requeues 0) rate 8bit 0pps backlog 0b 0p requeues 0 lended: 7 borrowed: 0 giants: 0 tokens: 1164 ctokens: 1164 class htb 1:12 parent 1:1 leaf 30: prio 0 quantum 1500 rate 48bit ceil 80bit burst 1659b/8 mpu 0b overhead 0b cburst 1699b/8 mpu 0b overhead 0b level 0 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 lended: 0 borrowed: 0 giants: 0 tokens: 28329 ctokens: 17408 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] why isn't 1:1 getting the traffic? [filter question]
Jody Shumaker wrote: tc qdisc del dev eth0 root /dev/null 21 tc qdisc add dev eth0 handle 1: root htb default 2 tc class add dev eth0 classid 1:1 parent 1: htb rate 100kbps ceil 100kbps quantum 1500 tc class add dev eth0 classid 1:2 parent 1: htb rate 90mbit ceil 90mbit quantum 1500 You're defining 2 root classes to the HTB qdisc, while it should possibly have given an error, it seems to instead just put the first one, 1:1, into a state of limbo where its never used. This was fairly obvious looking at your tc statistics output, where it lists both 1:1 and 1:2 as roots with no parent. There can only be one valid root class. Why? I need two virtual circuits. I don't want the 90mbit class interfere with the 200kbit class: no lending, no borrowing. Should really set it up something like this with one main root: tc qdisc add dev eth0 handle 1: root htb default 2 tc class add dev eth0 classid 1:0 parent 1: htb rate 90100kbps ceil 90100kbps quantum 1500 tc class add dev eth0 classid 1:1 parent 1:0 htb rate 100kbps ceil 100kbps quantum 1500 tc class add dev eth0 classid 1:2 parent 1:0 htb rate 90mbit ceil 90mbit quantum 1500 Then I imagine your tc filter would actually work. It actually works if I use a *leaf* class as the target of the filter (see my subsequent email). But this contradicts the documentation, which even mentions one could gain speed by adding further filters to other classes besides a root one. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] why isn't 1:1 getting the traffic? [filter question]
On Fri, Feb 24, 2006 at 06:19:53PM -0300, Andreas wrote: This was fairly obvious looking at your tc statistics output, where it lists both 1:1 and 1:2 as roots with no parent. There can only be one valid root class. Why? I need two virtual circuits. I don't want the 90mbit class interfere with the 200kbit class: no lending, no borrowing. I think there can be more than just one root class - the question is just wether it makes sense or not. I prefer using one root class - after all, you only got one interface, and you have to make sure that you do not exceed the total interface capacity. Therefore, the root class is the interface limiter. You can add isolated circuits to that root class easily; as long as all child classes of the root class have the same rate and ceil, no lending or borrowing between them will be done, simply because it is not necessary. This way you get your desired features plus an overview on how much rate the physical interface actually has to offer - from my point of view, that's a win-win situation. It actually works if I use a *leaf* class as the target of the filter (see my subsequent email). But this contradicts the documentation, which even mentions one could gain speed by adding further filters to other classes besides a root one. I never got filters to work that do not point to leaf classes. Wether it is possible at all or not, I do not know. Maybe it was planned and turned out to be too complicated - maybe it is implemented but not working due to some undiscovered bug. I'm too lazy to look at the code right now. I usually end up using iptables for classification; I find it to be far more userfriendly than the tc filters, and you can group filters any way you want. Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] why isn't 1:1 getting the traffic? [filter question]
Andreas Hasenack wrote: With the below script, whenever I ping 10.0.16.10 (which matches the only filter I have), traffic still get's sent to the default 1:2 class instead of 1:1 and I don't know why... Any hints? (kernel 2.6.12, iproute2-2.6.15) tc qdisc del dev eth0 root /dev/null 21 tc qdisc add dev eth0 handle 1: root htb default 2 tc class add dev eth0 classid 1:1 parent 1: htb rate 100kbps ceil 100kbps quantum 1500 tc class add dev eth0 classid 1:2 parent 1: htb rate 90mbit ceil 90mbit quantum 1500 tc qdisc add dev eth0 handle 2: parent 1:2 sfq perturb 10 tc class add dev eth0 classid 1:10 parent 1:1 htb prio 0 rate 30kbps quantum 1500 tc qdisc add dev eth0 handle 10: parent 1:10 sfq perturb 10 tc class add dev eth0 classid 1:11 parent 1:1 htb prio 0 rate 70kbps ceil 100kbps quantum 1500 tc qdisc add dev eth0 handle 20: parent 1:11 sfq perturb 10 tc class add dev eth0 classid 1:12 parent 1:1 htb rate 60kbps ceil 100kbps quantum 1500 tc qdisc add dev eth0 handle 30: parent 1:12 sfq perturb 10 tc filter add dev eth0 parent 1:0 prio 1 protocol ip u32 \ match ip dst 10.0.16.10/32 \ flowid 1:1 Status after pinging 10.0.16.10 a few times (notice traffic on 1:2, but not on 1:1): qdisc htb 1: r2q 10 default 2 direct_packets_stat 0 ver 3.17 Sent 516 bytes 7 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 2: parent 1:2 limit 128p quantum 1514b flows 128/1024 perturb 10sec Sent 516 bytes 7 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 10: parent 1:10 limit 128p quantum 1514b flows 128/1024 perturb 10sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 20: parent 1:11 limit 128p quantum 1514b flows 128/1024 perturb 10sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 30: parent 1:12 limit 128p quantum 1514b flows 128/1024 perturb 10sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 class htb 1:11 parent 1:1 leaf 20: prio 0 quantum 1500 rate 56bit ceil 80bit burst 1669b/8 mpu 0b overhead 0b cburst 1699b/8 mpu 0b overhead 0b level 0 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 lended: 0 borrowed: 0 giants: 0 tokens: 24429 ctokens: 17408 class htb 1:1 root rate 80bit ceil 80bit burst 1699b/8 mpu 0b overhead 0b cburst 1699b/8 mpu 0b overhead 0b level 7 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 lended: 0 borrowed: 0 giants: 0 tokens: 17408 ctokens: 17408 class htb 1:10 parent 1:1 leaf 10: prio 0 quantum 1500 rate 24bit ceil 24bit burst 1629b/8 mpu 0b overhead 0b cburst 1629b/8 mpu 0b overhead 0b level 0 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 lended: 0 borrowed: 0 giants: 0 tokens: 55636 ctokens: 55636 class htb 1:2 root leaf 2: prio 0 quantum 1500 rate 9Kbit ceil 9Kbit burst 12836b/8 mpu 0b overhead 0b cburst 12836b/8 mpu 0b overhead 0b level 0 Sent 516 bytes 7 pkt (dropped 0, overlimits 0 requeues 0) rate 8bit 0pps backlog 0b 0p requeues 0 lended: 7 borrowed: 0 giants: 0 tokens: 1164 ctokens: 1164 class htb 1:12 parent 1:1 leaf 30: prio 0 quantum 1500 rate 48bit ceil 80bit burst 1659b/8 mpu 0b overhead 0b cburst 1699b/8 mpu 0b overhead 0b level 0 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 lended: 0 borrowed: 0 giants: 0 tokens: 28329 ctokens: 17408 Andreas, Your filter looks for protocol ip. Are you POSITIVE your ping uses ip? Try 'protocol all' rather than 'protocol ip'. -- gypsy ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
