The following (occuring on debian/testing with kernel-image-2.6.8-2-386 version 2.6.8-13 and iproute version 20041019-3) confuses me: # tc qdisc add dev eth0 root handle 1: prio # tc filter add dev eth0 parent 1: proto ip pref 1 handle 1 fw classid 1:2 # tc filter ls dev eth0 filter parent 1: protocol ip pref 1 fw filter parent 1: protocol ip pref 1 fw handle 0x1 classid 1:2 # tc filter del dev eth0 parent 1: proto ip prio 1 fw # tc filter ls dev eth0 # tc filter add dev eth0 parent 1: proto ip pref 1 handle 1 fw classid 1:2 RTNETLINK answers: Invalid argument We have an error talking to the kernel # tc filter ls dev eth0 filter parent 1: protocol ip pref 1 fw # tc filter del dev eth0 parent 1: proto ip prio 1 fw # tc filter ls dev eth0 # tc filter add dev eth0 parent 1: proto ip pref 1 handle 1 fw classid 1:2 RTNETLINK answers: Invalid argument We have an error talking to the kernel # tc qdisc del dev eth0 root # tc qdisc add dev eth0 root handle 1: prio # tc filter add dev eth0 parent 1: proto ip pref 1 handle 1 fw classid 1:2 # tc filter ls dev eth0 filter parent 1: protocol ip pref 1 fw filter parent 1: protocol ip pref 1 fw handle 0x1 classid 1:2 # tc filter del dev eth0 parent 1: proto ip pref 1 handle 1 fw # tc filter ls dev eth0 filter parent 1: protocol ip pref 1 fw # tc filter add dev eth0 parent 1: proto ip pref 1 handle 1 fw classid 1:2 # tc filter ls dev eth0 filter parent 1: protocol ip pref 1 fw filter parent 1: protocol ip pref 1 fw handle 0x1 classid 1:2 # What is going on? Why are 2 entries created at first, then, if I delete the one without a handle they both dissapear but I can''t recreate the one with the handle? Why is it if I delete the one with the handle, it is the only one deleted, and can be re-added and re-deleted just fine? What are filter handles actually used for? Should I just omit the handle to make everything better? Second, tc doesn''t seem to want me to create filters without a filter type, so how should I create a filter that will always match? i.e. I want a prio 1 filter based on u32, then a prio 2 filter based on fw, then a prio 3 filter that will match everything that the prio 1 and 2 filters didn''t get? Thirdly, I haven''t seen this actually written down anywhere, so I''d like to double check: the fw filter matches any packet with non-zero fwmark value, yes? Finally, when using netem `tc qdisc ls` always shows a duplicate value of around %75, even when I don''t set it, and setting the duplicate value seems to have no effect. Is this a header mismatch between the kernel and userland? Apologies to those who don''t like multiple questions in one email :-) Alexey
On Wed, 25 May 2005, Robert Siemer wrote:> Second a "tc filter add" can get translated to a bunch of "low level" > filter rules. E.g. a human readable u32 filter ends up as 3 rules > forming a little hash table network.Where is this documented? How should one interpret the multiple "low level" entries correctly? Any idea why I was having a problem recreating the filter after deleting it, until I deleted and recreated the parent qdisc?>> Finally, when using netem `tc qdisc ls` always shows a duplicate value of >> around %75, even when I don''t set it, and setting the duplicate value seems >> to have no effect. Is this a header mismatch between the kernel and >> userland? > > Don''t understand that question. Show us the "tc qdisc ls" output...# tc qdisc add dev eth0 root handle 1: netem # tc qdisc ls qdisc netem 1: dev eth0 limit 1000 duplicate 76.388% # tc qdisc del dev eth0 root # tc qdisc add dev eth0 root handle 1: netem duplicate 10% # tc qdisc ls qdisc netem 1: dev eth0 limit 1000 duplicate 76.6335% # tc qdisc del dev eth0 root # tc qdisc add dev eth0 root handle 1: netem duplicate 100% # tc qdisc ls qdisc netem 1: dev eth0 limit 1000 duplicate 76.169% # tc qdisc ls qdisc netem 1: dev eth0 limit 1000 duplicate 76.0071% # tc qdisc ls qdisc netem 1: dev eth0 limit 1000 duplicate 76.3702% # In all cases, no actual packet duplication occurs for packets passing through the qdisc. All other features of netem work as expected. Alexey
On Wed, May 25, 2005 at 01:51:41AM +0000, Alexey Toptygin wrote:> On Wed, 25 May 2005, Robert Siemer wrote: > > >Second a "tc filter add" can get translated to a bunch of "low level" > >filter rules. E.g. a human readable u32 filter ends up as 3 rules > >forming a little hash table network. > > Where is this documented?Nowhere.> How should one interpret the multiple "low level" entries correctly?You need to know the u32 filter syntax for "advanced" filtering rules. Than you''ll recognise some keywords which show up on "tc filter ls". It should be possible to add directly the hardcore versions of the u32 filters... I don''t know about other filters.> Any idea why I was having a problem recreating > the filter after deleting it, until I deleted and recreated the parent > qdisc?Probably a kernel bug.> >>Finally, when using netem `tc qdisc ls` always shows a duplicate value of > >>around %75, even when I don''t set it, and setting the duplicate value > >>seems > >>to have no effect. Is this a header mismatch between the kernel and > >>userland? > > > >Don''t understand that question. Show us the "tc qdisc ls" output... > > # tc qdisc add dev eth0 root handle 1: netem > # tc qdisc ls > qdisc netem 1: dev eth0 limit 1000 duplicate 76.388% > # tc qdisc del dev eth0 root > # tc qdisc add dev eth0 root handle 1: netem duplicate 10% > # tc qdisc ls > qdisc netem 1: dev eth0 limit 1000 duplicate 76.6335%Old software? panorama:/home/siemer# tc qdisc add dev eth0 root handle 1: netem panorama:/home/siemer# tc qdisc show dev eth0 qdisc netem 1: limit 1000 panorama:/home/siemer# tc qdisc change dev eth0 handle 1: netem duplicate 1% panorama:/home/siemer# tc qdisc show dev eth0 qdisc netem 1: limit 1000 duplicate 1% panorama:/home/siemer# Bye, Robert
Alexey Toptygin wrote:> What is going on? Why are 2 entries created at first,That''s normal output of tc filter ls - you may see more than 2 with u32 rules. then, if I delete> the one without a handle they both dissapear but I can''t recreate the > one with the handle?Doesn''t happen for me with 2.6.12-rc1 and latest iproute Why is it if I delete the one with the handle, it> is the only one deleted, and can be re-added and re-deleted just fine? > What are filter handles actually used for?They are not usually used, the "handle 1 fw" goes together to allow you to match marks, it''s not so you can del specific filters - you would be better deleting the root qdisc and starting again if you need to change filters. Should I just omit the handle> to make everything better? > > Second, tc doesn''t seem to want me to create filters without a filter > type, so how should I create a filter that will always match? i.e. I > want a prio 1 filter based on u32, then a prio 2 filter based on fw, > then a prio 3 filter that will match everything that the prio 1 and 2 > filters didn''t get?... u32 match u32 0 0 ...> > Thirdly, I haven''t seen this actually written down anywhere, so I''d like > to double check: the fw filter matches any packet with non-zero fwmark > value, yes?Well you can''t match 0 to mean unmarked like you can with iptables (you can also classify directly now with iptables -j CLASSIFY). For >0 the fw matches the mark you specify not any marked packet. Andy.