Penguin
Diff: TrafficControl
EditPageHistoryDiffInfoLikePages

Differences between current version and predecessor to the previous major change of TrafficControl.

Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History

Newer page: version 13 Last edited on Thursday, March 5, 2009 10:03:15 pm by PerryLorier
Older page: version 9 Last edited on Thursday, March 5, 2009 11:01:08 am by PerryLorier Revert
@@ -74,4 +74,78 @@
 ** <tt>sudo ./tc action add action mirred help</tt> 
 ** <tt>sudo ./tc action add action nat help</tt> 
 ** <tt>sudo ./tc action add action pedit help</tt> (pedit says it has an example, ... it doesn't. But the command does look particularly interesting) 
 ** <tt>sudo ./tc action add action police help</tt> 
+  
+!!!filters  
+!!basic  
+<tt>./tc filter add dev eth1 basic match help</tt>  
+  
+basic is anything but. It allows complicated matches to be built up from boolean operations on various criteria (called extended matches, or "ematches"). The syntax for this is "criteria(arguments)". You can use brackets to force precedence, as well as "and","or" and "not" to combine criteria. Supported extended match modules are "cmp","meta","nbyte" and "u32". see <tt>tc filter add dev lo basic match cmp(help)</tt>, <tt>tc filter add dev lo basic match meta(help)</tt>, <tt>tc filter add dev lo basic match meta(list)</tt>, <tt>tc filter add dev lo basic match nbyte(help)</tt> and <tt>tc filter add dev lo basic match u32(help)</tt> for suggested syntaxes.  
+  
+the cmp extended basic match appears to be the recommended way to match on layer 2 fields ([ref|http://lists.openwall.net/netdev/2007/08/15/63])  
+  
+!cmp ematch  
+This ematch module lets you match on various 8,16 or 32 bit quantities relative to layer 2, layer 3 or transport headers.  
+  
+An example (that we didn't have time to get to work properly, but it shows a valid syntax), this should match IP packets inside PPPoE sourced from 192.0.2.0/24.:  
+<verbatim>  
+$TC filter add dev $DEV \  
+ parent 1: prio 10 \  
+ protocol all \  
+ basic match "cmp(u16 at 12 layer 2 eq 0x8864) and cmp(u32 at 34 layer 2 mask 0xFFFFFF00 eq 0xC0000200)" \  
+ flowid 1:10  
+</verbatim>  
+  
+!meta ematch  
+This ematch module lets you match on various attributes of the system (such as load average), or metadata about the packet (such as the firewall mark).  
+<tt>tc filter add dev lo basic match meta(list)</tt> lists all the possible attributes.  
+!nbyte ematch  
+When you want to match on a string inside a packet, nbyte is the module for you.  
+!u32 ematch  
+u32 is the same as the normal u32 match. Being an ematch it allows for lt,gt or eq matches as well as the usual matches. You can also use the "basic" system to allow for combining this with other ematches in one single rule.  
+  
+!!u32  
+The u32 match appears to be the most frequently used match. It appears that having multiple u32 matches on the same "prio" will be attempted to be "stack" into a single hash table. Errors can occur if they can't be "stacked". Try giving them a unique prio. u32 always matches from the "network" (aka IP/IP6) header. To get at the link layer header, negative offsets can be used as a hack.  
+  
+!!tcindex  
+This matches on the skb->tc_index. I don't know what this is used for? ([ref|http://www.opalsoft.net/qos/DS-210.htm])  
+  
+!!rsvp  
+Match on RSVP flow labels. ([ref|http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=net/sched/cls_rsvp.h;hb=HEAD])  
+  
+!!flow  
+This is an extremely useful classifier that allows classifying packets into queues inside a <tt>SFQ</tt>.  
+  
+Example:  
+<verbatim>  
+$TC filter add dev $DEV \  
+ parent 1: prio 1 \  
+ handle 2 \  
+ protocol all \  
+ flow hash keys dst divisor 1024  
+</verbatim>  
+This rule will change the SFQ classifier from the Internal one, to using one that only matches on destination address. This will fairly share bandwidth between destination IP's, instead of between 5 tuple flows.  
+  
+One caveat discovered with the sfq classifier is that if a packet doesn't match, it will get dropped from the sfq, where as the default behavior of the SFQ's internal hashing algorithm is for packets it can't classify, to place them in bucket 0. While the external sfq classifier makes this obvious during testing (100% packet loss), the internal classifier will only show horrible performance when the sfq is under load (and there are many other buckets used).  
+  
+The divisor is the divisor of a modulo operation. It must be equal or smaller than the hash size configured in the SFQ that this is classifying for. The SFQ size is defined at compile time, by default to be 1,024 elements in size. So set the divisor to 1024.  
+  
+the flow keys can be src (source ip), dst (destination ip), proto (ip protocol), proto-src (transport protocol source address), proto-dst (transport protocol destination address), iif (input interface), priority (?), mark (firewall mark), nfct (netfilter conntrack?), nfct-src (original netfilter source), nfct-dst (original netfilter destination), nfct-proto-src (original netfilter conntrack transport protocol src), nfct-proto-dst (and so on), rt-classid (?), sk-uid (uid from the skbuff), sk-gid (gid from the skbuff), vlan-tag. At [WAND] we have extended this to include mac-src, mac-dst, mac-proto.  
+  
+This also supports <tt>or</tt>/<tt>and</tt>/<tt>xor</tt>/<tt>rshift</tt>/<tt>append</tt> <i>NUM<i>. I don't know why this is here, possibly to allow you to attach multiple classifiers to the same sfq, and then limit them to different parts of the hash table?  
+  
+!!fw  
+This match module matches only on the fwmark. It uses the "handle" to select which firewall mark to match. Internally this uses a hash table, so having multiple fwmarks at the same prio appear to able to "stack".  
+  
+Example:  
+<verbatim>  
+$TC filter add dev $DEV \  
+ parent 1: prio 2 \  
+ protocol ip \  
+ handle $FWMARK \  
+ fw \  
+ flowid 1:10  
+</verbatim>  
+  
+!!route  
+This match module allows matching on "realms". realms are tags that can be applied to routes. Supports matching <tt>from <i>realm</i></tt>, <tt>fromif <i>tag</i></tt>, <tt>to <i>realm</i></tt>. I've not experimented with this match, but [several other people have|http://www.meta.net.nz/~daniel/blog/2008/09/24/qos-and-ip-accounting-with-bgp-under-linux/]. This seems to be the easiest way to match routes from quagga. (eg national vs international)