<\/a> <\/h2>\naction<\/b> ACTION_SPEC<\/i><\/p>\n
Apply an action from the generic actions framework on matching packets.<\/p>\n
baseclass<\/b> ID<\/i><\/p>\n
An offset for the resulting class ID. ID<\/i> may be root<\/b>, none<\/b> or a hexadecimal class ID in the form [X<\/i>:<\/b>]Y<\/i>. X<\/i> must match qdisc\u2019s\/class\u2019s major handle (if omitted, the correct value is chosen automatically). If the whole baseclass<\/b> is omitted, Y<\/i> defaults to 1.<\/p>\n
divisor<\/b> NUM<\/i><\/p>\n
Number of buckets to use for sorting into. Keys are calculated modulo NUM<\/i>.<\/p>\n
hash keys<\/b> KEY-LIST<\/i><\/p>\n
Perform a jhash2<\/b> operation over the keys in KEY-LIST<\/i>, the result (modulo the divisor<\/b> if given) is taken as class ID, optionally offset by the value of baseclass<\/b>. It is possible to specify an interval (in seconds) after which jhash2<\/b>\u2019s entropy source is recreated using the perturb<\/b> parameter.<\/p>\n
map key<\/b> KEY<\/i><\/p>\n
Packet data identified by KEY<\/i> is translated into class IDs to push the packet into. The value may be mangled by OPS<\/i> before using it for the mapping. They are applied in the order listed here:
and<\/b> NUM<\/i><\/p>\n
Perform bitwise AND<\/b> operation with numeric value NUM<\/i>.<\/p>\n
or<\/b> NUM<\/i><\/p>\n
Perform bitwise OR<\/b> operation with numeric value NUM<\/i>.<\/p>\n
xor<\/b> NUM<\/i><\/p>\n
Perform bitwise XOR<\/b> operation with numeric value NUM<\/i>.<\/p>\n
rshift<\/b> NUM<\/i><\/p>\n
Shift the value of KEY<\/i> to the right by NUM<\/i> bits.<\/p>\n
addend<\/b> NUM<\/i><\/p>\n
Add NUM<\/i> to the value of KEY<\/i>.<\/p>\n
For the or<\/b>, and<\/b>, xor<\/b> and rshift<\/b> operations, NUM<\/i> is assumed to be an unsigned, 32bit integer value. For the addend<\/b> operation, NUM<\/i> may be much more complex: It may be prefixed by a minus (\u2019-\u2019) sign to cause subtraction instead of addition and for keys of src<\/b>, dst<\/b>, nfct-src<\/b> and nfct-dst<\/b> it may be given in IP address notation. See below for an illustrating example.<\/p>\n
match<\/b> EMATCH_TREE<\/i><\/p>\n
Match packets using the extended match infrastructure. See tc-ematch<\/b>(8) for a detailed description of the allowed syntax in EMATCH_TREE<\/i>.<\/p>\n\n\n| <\/td>\n | \n proto<\/b><\/p>\n<\/td>\n | <\/td>\n | \n Use the layer four protocol number as key.<\/p>\n<\/td>\n | <\/td>\n<\/tr>\n<\/table>\n proto-src<\/b><\/p>\n Use the layer four source port as key. If not available, the kernel-internal socket address is used instead.<\/p>\n proto-dst<\/b><\/p>\n Use the layer four destination port as key. If not available, the associated kernel-internal dst_entry address is used after XOR\u2019ing with the packet\u2019s layer three protocol number.<\/p>\n \n\n| <\/td>\n | \n iif<\/b><\/p>\n<\/td>\n | <\/td>\n | \n Use the incoming interface index as key.<\/p>\n<\/td>\n | <\/td>\n<\/tr>\n<\/table>\n priority<\/b><\/p>\n Use the packet\u2019s priority as key. Usually this is the IP header\u2019s DSCP\/ECN value.<\/p>\n \n\n| <\/td>\n | \n mark<\/b><\/p>\n<\/td>\n | <\/td>\n | \n Use the netfilter fwmark<\/b> as key.<\/p>\n<\/td>\n | <\/td>\n<\/tr>\n | \n| <\/td>\n | \n nfct<\/b><\/p>\n<\/td>\n | <\/td>\n | \n Use the associated conntrack entry address as key.<\/p>\n<\/td>\n | <\/td>\n<\/tr>\n<\/table>\n nfct-src<\/b>, nfct-dst<\/b>, nfct-proto-src<\/b>, nfct-proto-dst<\/b><\/p>\n These are conntrack-aware variants of src<\/b>, dst<\/b>, proto-src<\/b> and proto-dst<\/b>. In case of NAT, these are basically the packet header\u2019s values before NAT was applied.<\/p>\n rt-classid<\/b><\/p>\n Use the packet\u2019s destination routing table entry\u2019s realm as key.<\/p>\n \n\n| <\/td>\n | \n sk-uid<\/b><\/p>\n<\/td>\n | <\/td>\n | <\/td>\n<\/tr>\n | \n| <\/td>\n | \n sk-gid<\/b><\/p>\n<\/td>\n | <\/td>\n | \n For locally generated packets, use the user or group ID the originating socket belongs to as key.<\/p>\n<\/td>\n<\/tr>\n<\/table>\n vlan-tag<\/b><\/p>\n Use the packet\u2019s vlan ID as key.<\/p>\n \n\n| <\/td>\n | \n rxhash<\/b><\/p>\n<\/td>\n | <\/td>\n | \n Use the flow hash as key.<\/p>\n<\/td>\n | <\/td>\n<\/tr>\n<\/table>\n\n\n| <\/td>\n | <\/td>\n | \n keys src,dst,proto,proto-src,proto-dst divisor 1024<\/p>\n<\/td>\n<\/tr>\n<\/table>\n Classic SFQ hash, but using information from conntrack to work properly
in combination with NAT:<\/p>\n tc filter add … flow hash <\/p>\n \n\n| <\/td>\n | <\/td>\n | \n keys nfct-src,nfct-dst,proto,nfct-proto-src,nfct-proto-dst <\/p>\n<\/td>\n<\/tr>\n | \n| <\/td>\n | <\/td>\n | \n divisor 1024<\/p>\n<\/td>\n<\/tr>\n<\/table>\n Map destination IPs of 192.168.0.0\/24 to classids 1-256:<\/p>\n tc filter add … flow map <\/p>\n \n\n| <\/td>\n | <\/td>\n | \n key dst addend -192.168.0.0 divisor 256<\/p>\n<\/td>\n<\/tr>\n<\/table>\n Alternative to the above:<\/p>\n tc filter add … flow map <\/p>\n \n\n| <\/td>\n | <\/td>\n | \n key dst and 0xff<\/p>\n<\/td>\n<\/tr>\n<\/table>\n The same, but in reverse order:<\/p>\n tc filter add … flow map <\/p>\n \n\n| <\/td>\n | <\/td>\n | \n key dst and 0xff xor 0xff<\/p>\n<\/td>\n<\/tr>\n<\/table>\n | | | | | | | | | |