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.
