Andreas Hasenack
2006-Feb-24 17:57 UTC
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 2>&1
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 560000bit ceil
800000bit 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 800000bit ceil 800000bit 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 240000bit ceil
240000bit 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 90000Kbit ceil 90000Kbit
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 480000bit ceil
800000bit 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
Jody Shumaker wrote:>>tc qdisc del dev eth0 root > /dev/null 2>&1 >>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.
Andreas Klauer
2006-Feb-24 23:01 UTC
Re: 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
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 2>&1 > 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 560000bit ceil 800000bit 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 800000bit ceil 800000bit 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 240000bit ceil 240000bit 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 90000Kbit ceil 90000Kbit 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 480000bit ceil 800000bit 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: 17408Andreas, Your filter looks for protocol ip. Are you POSITIVE your ping uses ip? Try ''protocol all'' rather than ''protocol ip''. -- gypsy
Andy Furniss
2006-Feb-25 11:45 UTC
Re: 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 2>&1 > 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:1It''s because 1:1 isn''t a leaf, you need more filters with parent 1:1 to filter to the leaves. Andy.