Universal 32bit classifier in tc(8) Linux Universal 32bit classifier in tc(8)
NAME
u32 - universal 32bit traffic control filter
SYNOPSIS
tc filter ... [ handle HANDLE ] u32 OPTION_LIST [ offset OFFSET ] [
hashkey HASHKEY ] [ classid CLASSID ] [ divisor uint_value ] [
order u32_value ] [ ht HANDLE ] [ sample SELECTOR [ divisor
uint_value ] ] [ link HANDLE ] [ indev ifname ] [ help ]
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 [ / { pre-
fixlen | netmask } ] } AT | { dsfield | ihl | protocol | prece-
dence | 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
The Universal/Ugly 32bit filter allows to match arbitrary bitfields in
the packet. Due to breaking everything down to values, masks and off-
sets, It is equally powerful and hard to use. Luckily many abstracting
directives are present which allow defining rules on a higher level and
therefore free the user from having to fiddle with bits and masks in
many cases.
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 hierar-
chy.
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 identi-
fied. 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.
In fact, even if not explicitly requested u32 creates a hash table for every
priority a filter is being added with. The table's size is 1 though, so it is
in fact merely a linked list.
VALUES
Options and selectors require values to be specified in a specific for-
mat, which is often non-intuitive. Therefore the terminals in SYNOPSIS
have been given descriptive names to indicate the required format
and/or maximum allowed numeric value: Prefixes u32, u16 and u8 indicate
four, two and single byte unsigned values. E.g. u16 indicates a two
byte-sized value in range between 0 and 65535 (0xFFFF) inclusive. A
prefix of int indicates a four byte signed value. A middle part of
_hex_ indicates that the value is parsed in hexadecimal format. Other-
wise, the value's base is automatically detected, i.e. values prefixed
with 0x are considered hexadecimal, a leading 0 indicates octal format
and decimal format otherwise. There are some values with special for-
matting as well: ip_address and netmask are in dotted-quad formatting
as usual for IPv4 addresses. An ip6_address is specified in common,
colon-separated hexadecimal format. Finally, prefixlen is an unsigned,
decimal integer value in range from 0 to the address width in bits (32
for IPv4 and 128 for IPv6).
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 divid-
able by N. Or the other way around: the resulting value must be a mul-
tiple of N.
OPTIONS
U32 recognizes the following 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). Alterna-
tively 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 com-
bined 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 lat-
ter using mask and/or shift keywords. By default, this offset is
recorded but not implicitly applied. It is used only to substi-
tute the nexthdr+ statement. Using the keyword eat though
inverses this behaviour: the offset is applied always, and nex-
thdr+ 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 ker-
nel 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.
help Print a brief help text about possible options.
SELECTORS
Basically the only real selector is u32 . All others merely provide a
higher level syntax and are internally translated into u32 .
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:
src ADDR
dst ADDR
Compare Source or Destination Address fields against the
value of ADDR. The reserved words default, any and all
effectively match any address. Otherwise an IP address of
the particular protocol is expected, optionally suffixed
by a prefix length to match whole subnets. In case of
IPv4 a netmask may also be given.
dsfield VAL_MASK_8
IPv4 only. Match the packet header's DSCP/ECN field. Syn-
onyms to this are tos and precedence.
ihl VAL_MASK_8
IPv4 only. Match the Internet Header Length field. Note
that the value's unit is 32bits, so to match a packet
with 24byte header length u8_value has to be 6.
protocol VAL_MASK_8
Match the Protocol (IPv4) or Next Header (IPv6) field
value, e.g. 6 for TCP.
icmp_type VAL_MASK_8
icmp_code VAL_MASK_8
Assume a next-header protocol of icmp or ipv6-icmp and
match Type or Code field values. This is dangerous, as
the code assumes minimal header size for IPv4 and lack of
extension headers for IPv6.
sport VAL_MASK_16
dport VAL_MASK_16
Match layer four source or destination ports. This is
dangerous as well, as it assumes a suitable layer four
protocol is present (which has Source and Destination
Port fields right at the start of the header and 16bit in
size). Also minimal header size for IPv4 and lack of
IPv6 extension headers is assumed.
nofrag
firstfrag
df
mf IPv4 only, check certain flags and fragment offset val-
ues. Match if the packet is not a fragment (nofrag), the
first fragment (firstfrag), if Don't Fragment (df) or
More Fragments (mf) bits are set.
priority VAL_MASK_8
IPv6 only. Match the header's Traffic Class field, which
has the same purpose and semantics of IPv4's ToS field
since RFC 3168: upper six bits are DSCP, the lower two
ECN.
flowlabel VAL_MASK_32
IPv6 only. Match the Flow Label field's value. Note that
Flow Label itself is only 20bytes long, which are the
least significant ones here. The remaining upper 12bytes
match Version and Traffic Class fields.
tcp TCPUDP
udp TCPUDP
Match fields of next header of protocol TCP or UDP. The possible
values for TCPDUP are:
src VAL_MASK_16
Match on Source Port field value.
dst VALMASK_16
Match on Destination Port field value.
icmp ICMP
Match fields of next header of protocol ICMP. The possible val-
ues for ICMP are:
type VAL_MASK_8
Match on ICMP Type field.
code VAL_MASK_8
Match on ICMP Code field.
mark VAL_MASK_32
Match on netfilter fwmark value.
ether ETHER
Match on ethernet header fields. Possible values for ETHER are:
src ether_address AT
dst ether_address AT
Match on source or destination ethernet address. This is
dangerous: It assumes an ethernet header is present at
the start of the packet. This will probably lead to unex-
pected things if used with layer three interfaces like
e.g. tun or ppp.
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 clas-
sified 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 ta-
ble 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 ta-
ble:
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 cre-
ated his own table of size 1 to hold other filters of the same prior-
ity.
The next step is to create a filter which links to the created hash ta-
ble:
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 off-
set 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 frag-
ment (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
tc(8),
cls_u32.txt at http://linux-tc-notes.sourceforge.net/
iproute2 25 Sep 20Universal 32bit classifier in tc(8)
Linux-Distributionen
Huschi als Linux-Admin