NAME¶

SYNOPSIS¶

HANDLE := { u12_hex_htid:[u8_hex_hash:[u12_hex_nodeid] | 0xu32_hex_value }

OPTION_LIST := [ OPTION_LIST ] OPTION

HASHKEY := [ mask u32_hex_value ] [ at 4*int_value ]

CLASSID := { root | none | [u16_major]:u16_minor | u32_hex_value }

OFFSET := [ plus int_value ] [ at 2*int_value ] [ mask u16_hex_value ] [ shift int_value ] [ eat ]

OPTION := { match SELECTOR | action ACTION }

SELECTOR := { u32 VAL_MASK_32 | u16 VAL_MASK_16 | u8 VAL_MASK_8 | ip IP | ip6 IP6 | { tcp | udp } TCPUDP | icmp ICMP | mark VAL_MASK_32 | ether ETHER }

IP := { { src | dst } { default | any | all | ip_address [ / { prefixlen | netmask } ] } AT | { dsfield | ihl | protocol | precedence | icmp_type | icmp_code } VAL_MASK_8 | { sport | dport } VAL_MASK_16 | nofrag | firstfrag | df | mf }

IP6 := { { src | dst } { default | any | all | ip6_address [/prefixlen ] } AT | priority VAL_MASK_8 | { protocol | icmp_type | icmp_code } VAL_MASK_8 | flowlabel VAL_MASK_32 | { sport | dport } VAL_MASK_16 }

TCPUDP := { src | dst } VAL_MASK_16

ICMP := { type VAL_MASK_8 | code VAL_MASK_8 }

ETHER := { src | dst } ether_address AT

VAL_MASK_32 := u32_value u32_hex_mask [ AT ]

VAL_MASK_16 := u16_value u16_hex_mask [ AT ]

VAL_MASK_8 := u8_value u8_hex_mask [ AT ]

AT := [ at [ nexthdr+ ] int_value ]

DESCRIPTION¶

There are two general modes of invocation: The first mode creates a new filter to delegate packets to different destinations. Apart from the obvious ones, namely classifying the packet by specifying a CLASSID or calling an action, one may link one filter to another one (or even a list of them), effectively organizing filters into a tree-like hierarchy.

Typically filter delegation is done by means of a hash table, which leads to the second mode of invocation: it merely serves to set up these hash tables. Filters can select a hash table and provide a key selector from which a hash is to be computed and used as key to lookup the table's bucket which contains filters for further processing. This is useful if a high number of filters is in use, as the overhead of performing the hash operation and table lookup becomes negligible in that case. Using hashtables with u32 basically involves the following pattern:

(1)

Creating a new hash table, specifying it's size using the divisor parameter and ideally a handle by which the table can be identified. If the latter is not given, the kernel chooses one on it's own, which has to be guessed later.

(2)

Creating filters which link to the created table in (1) using the link parameter and defining the packet data which the kernel will use to calculate the hashkey.

(3)

Adding filters to buckets in the hash table from (1). In order to avoid having to know how exactly the kernel creates the hash key, there is the sample parameter, which gives sample data to hash and thereby define the table bucket the filter should be added to.

VALUES¶

Sometimes values need to be dividable by a certain number. In that case a name of the form N*val was chosen, indicating that val must be dividable by N. Or the other way around: the resulting value must be a multiple of N.

OPTIONS¶

handle HANDLE

The handle is used to reference a filter and therefore must be unique. It consists of a hash table identifier htid and optional hash (which identifies the hash table's bucket) and nodeid. All these values are parsed as unsigned, hexadecimal numbers with length 12bits ( htid and nodeid) or 8bits ( hash). Alternatively one may specify a single, 32bit long hex number which contains the three fields bits in concatenated form. Other than the fields themselves, it has to be prefixed by 0x.

offset OFFSET

Set an offset which defines where matches of subsequent filters are applied to. Therefore this option is useful only when combined with link or a combination of ht and sample. The offset may be given explicitly by using the plus keyword, or extracted from the packet data with at. It is possible to mangle the latter using mask and/or shift keywords. By default, this offset is recorded but not implicitly applied. It is used only to substitute the nexthdr+ statement. Using the keyword eat though inverses this behaviour: the offset is applied always, and nexthdr+ will fall back to zero.

hashkey HASHKEY

Spefify what packet data to use to calculate a hash key for bucket lookup. The kernel adjusts the value according to the hash table's size. For this to work, the option link must be given.

classid CLASSID

Classify matching packets into the given CLASSID, which consists of either 16bit major and minor numbers or a single 32bit value combining both.

divisor u32_value

Specify a modulo value. Used when creating hash tables to define their size or for declaring a sample to calculate hash table keys from. Must be a power of two with exponent not exceeding eight.

order u32_value

A value to order filters by, ascending. Conflicts with handle which serves the same purpose.

sample SELECTOR

Used together with ht to specify which bucket to add this filter to. This allows one to avoid having to know how exactly the kernel calculates hashes. The additional divisor defaults to 256, so must be given for hash tables of different size.

link HANDLE

Delegate matching packets to filters in a hash table. HANDLE is used to only specify the hash table, so only htid may be given, hash and nodeid have to be omitted. By default, bucket number 0 will be used and can be overridden by the hashkey option.

indev ifname

Filter on the incoming interface of the packet. Obviously works only for forwarded traffic.

skip_sw

Do not process filter by software. If hardware has no offload support for this filter, or TC offload is not enabled for the interface, operation will fail.

skip_hw

Do not process filter by hardware.

help

Print a brief help text about possible options.

SELECTORS¶

u32 VAL_MASK_32

u16 VAL_MASK_16

u8 VAL_MASK_8

Match packet data to a given value. The selector name defines the sample length to extract (32bits for u32, 16bits for u16 and 8bits for u8). Before comparing, the sample is binary AND'ed with the given mask. This way uninteresting bits can be cleared before comparison. The position of the sample is defined by the offset specified in AT.

ip IP

ip6 IP6

Assume packet starts with an IPv4 ( ip) or IPv6 ( ip6) header. IP/IP6 then allows to match various header fields:

tcp TCPUDP

udp TCPUDP

Match fields of next header of protocol TCP or UDP. The possible values for TCPDUP are:

icmp ICMP

Match fields of next header of protocol ICMP. The possible values for ICMP are:

mark VAL_MASK_32

Match on netfilter fwmark value.

ether ETHER

Match on ethernet header fields. Possible values for ETHER are:

EXAMPLES¶

tc filter add dev eth0 parent 999:0 prio 99 protocol ip u32 \
        match ip src 192.168.8.0/24 classid 1:1

This attaches a filter to the qdisc identified by 999:0. It's priority is 99, which affects in which order multiple filters attached to the same parent are consulted (the lower the earlier). The filter handles packets of protocol type ip, and matches if the IP header's source address is within the 192.168.8.0/24 subnet. Matching packets are classified into class 1.1. The effect of this command might be surprising at first glance:

filter parent 1: protocol ip pref 99 u32
filter parent 1: protocol ip pref 99 u32 \
        fh 800: ht divisor 1
filter parent 1: protocol ip pref 99 u32 \
        fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1 \
        match c0a80800/ffffff00 at 12

So parent 1: is assigned a new u32 filter, which contains a hash table of size 1 (as the divisor indicates). The table ID is 800. The third line then shows the actual filter which was added above: it sits in table 800 and bucket 0, classifies packets into class ID 1:1 and matches the upper three bytes of the four byte value at offset 12 to be 0xc0a808, which is 192, 168 and 8.

Now for something more complicated, namely creating a custom hash table:

tc filter add dev eth0 prio 99 handle 1: u32 divisor 256

This creates a table of size 256 with handle 1: in priority 99. The effect is as follows:

filter parent 1: protocol all pref 99 u32
filter parent 1: protocol all pref 99 u32 fh 1: ht divisor 256
filter parent 1: protocol all pref 99 u32 fh 800: ht divisor 1

So along with the requested hash table (handle 1:), the kernel has created his own table of size 1 to hold other filters of the same priority.

The next step is to create a filter which links to the created hash table:

tc filter add dev eth0 parent 1: prio 1 u32 \
        link 1: hashkey mask 0x0000ff00 at 12 \
        match ip src 192.168.0.0/16

The filter is given a lower priority than the hash table itself so u32 consults it before manually traversing the hash table. The options link and hashkey determine which table and bucket to redirect to. In this case the hash key should be constructed out of the second byte at offset 12, which corresponds to an IP packet's third byte of the source address field. Along with the match statement, this effectively maps all class C networks below 192.168.0.0/16 to different buckets of the hash table.

Filters for certain subnets can be created like so:

tc filter add dev eth0 parent 1: prio 99 u32 \
        ht 1: sample u32 0x00000800 0x0000ff00 at 12 \
        match ip src 192.168.8.0/24 classid 1:1

The bucket is defined using the sample option: In this case, the second byte at offset 12 must be 0x08, exactly. In this case, the resulting bucket ID is obviously 8, but as soon as sample selects an amount of data which could exceed the divisor, one would have to know the kernel-internal algorithm to deduce the destination bucket. This filter's match statement is redundant in this case, as the entropy for the hash key does not exceed the table size and therefore no collisions can occur. Otherwise it's necessary to prevent matching unwanted packets.

Matching upper layer fields is problematic since IPv4 header length is variable and IPv6 supports extension headers which affect upper layer header offset. To overcome this, there is the possibility to specify nexthdr+ when giving an offset, and to make things easier there are the tcp and udp matches which use nexthdr+ implicitly. This offset has to be calculated in beforehand though, and the only way to achieve that is by doing it in a separate filter which then links to the filter which wants to use it. Here is an example of doing so:

tc filter add dev eth0 parent 1:0 protocol ip handle 1: \
        u32 divisor 1
tc filter add dev eth0 parent 1:0 protocol ip \
        u32 ht 1: \
        match tcp src 22 FFFF \
        classid 1:2
tc filter add dev eth0 parent 1:0 protocol ip \
        u32 ht 800: \
        match ip protocol 6 FF \
        match ip firstfrag \
        offset at 0 mask 0f00 shift 6 \
        link 1:

This is what is being done: In the first call, a single element sized hash table is created so there is a place to hold the linked to filter and a known handle (1:) to reference to it. The second call then adds the actual filter, which pushes packets with TCP source port 22 into class 1:2. Using ht, it is moved into the hash table created by the first call. The third call then does the actual magic: It matches IPv4 packets with next layer protocol 6 (TCP), only if it's the first fragment (usually TCP sets DF bit, but if it doesn't and the packet is fragmented, only the first one contains the TCP header), and then sets the offset based on the IP header's IHL field (right-shifting by 6 eliminates the offset of the field and at the same time converts the value into byte unit). Finally, using link, the hash table from first call is referenced which holds the filter from second call.

SEE ALSO¶