1Universal 32bit classifier in tc(8) Linux Universal 32bit classifier in tc(8)
2
6 u32 - universal 32bit traffic control filter
7
9 tc filter ... [ handle HANDLE ] u32 OPTION_LIST [ offset OFFSET ] [
10 hashkey HASHKEY ] [ classid CLASSID ] [ divisor uint_value ] [
11 order u32_value ] [ ht HANDLE ] [ sample SELECTOR [ divisor
12 uint_value ] ] [ link HANDLE ] [ indev ifname ] [ skip_hw |
13 skip_sw ] [ help ]
14 HANDLE := { u12_hex_htid:[u8_hex_hash:[u12_hex_nodeid] |
16 0xu32_hex_value }
17 OPTION_LIST := [ OPTION_LIST ] OPTION
19 HASHKEY := [ mask u32_hex_value ] [ at 4*int_value ]
21 CLASSID := { root | none | [u16_major]:u16_minor | u32_hex_value }
23 OFFSET := [ plus int_value ] [ at 2*int_value ] [ mask u16_hex_value ]
25 [ shift int_value ] [ eat ]
26 OPTION := { match SELECTOR | action ACTION }
28 SELECTOR := { u32 VAL_MASK_32 | u16 VAL_MASK_16 | u8 VAL_MASK_8 | ip IP
30 | ip6 IP6 | { tcp | udp } TCPUDP | icmp ICMP | mark VAL_MASK_32
31 | ether ETHER }
32 IP := { { src | dst } { default | any | all | ip_address [ / { pre‐
34 fixlen | netmask } ] } AT | { dsfield | ihl | protocol | prece‐
35 dence | icmp_type | icmp_code } VAL_MASK_8 | { sport | dport }
36 VAL_MASK_16 | nofrag | firstfrag | df | mf }
37 IP6 := { { src | dst } { default | any | all | ip6_address [/prefixlen
39 ] } AT | priority VAL_MASK_8 | { protocol | icmp_type |
40 icmp_code } VAL_MASK_8 | flowlabel VAL_MASK_32 | { sport |
41 dport } VAL_MASK_16 }
42 TCPUDP := { src | dst } VAL_MASK_16
44 ICMP := { type VAL_MASK_8 | code VAL_MASK_8 }
46 ETHER := { src | dst } ether_address AT
48 VAL_MASK_32 := u32_value u32_hex_mask [ AT ]
50 VAL_MASK_16 := u16_value u16_hex_mask [ AT ]
52 VAL_MASK_8 := u8_value u8_hex_mask [ AT ]
54 AT := [ at [ nexthdr+ ] int_value ]
56
58 The Universal/Ugly 32bit filter allows to match arbitrary bitfields in
59 the packet. Due to breaking everything down to values, masks and off‐
60 sets, It is equally powerful and hard to use. Luckily many abstracting
61 directives are present which allow defining rules on a higher level and
62 therefore free the user from having to fiddle with bits and masks in
63 many cases.
64 There are two general modes of invocation: The first mode creates a new
66 filter to delegate packets to different destinations. Apart from the
67 obvious ones, namely classifying the packet by specifying a CLASSID or
68 calling an action, one may link one filter to another one (or even a
69 list of them), effectively organizing filters into a tree-like hierar‐
70 chy.
71 Typically filter delegation is done by means of a hash table, which
73 leads to the second mode of invocation: it merely serves to set up
74 these hash tables. Filters can select a hash table and provide a key
75 selector from which a hash is to be computed and used as key to lookup
76 the table's bucket which contains filters for further processing. This
77 is useful if a high number of filters is in use, as the overhead of
78 performing the hash operation and table lookup becomes negligible in
79 that case. Using hashtables with u32 basically involves the following
80 pattern:
81 (1) Creating a new hash table, specifying it's size using the divisor
83 parameter and ideally a handle by which the table can be identi‐
84 fied. If the latter is not given, the kernel chooses one on it's
85 own, which has to be guessed later.
86 (2) Creating filters which link to the created table in [4m(1) using the
88 link parameter and defining the packet data which the kernel will
89 use to calculate the hashkey.
90 (3) Adding filters to buckets in the hash table from [4m(1). In order to
92 avoid having to know how exactly the kernel creates the hash key,
93 there is the sample parameter, which gives sample data to hash and
94 thereby define the table bucket the filter should be added to.
95 In fact, even if not explicitly requested u32 creates a hash table for
97 every priority a filter is being added with. The table's size is 1
98 though, so it is in fact merely a linked list.
99
101 Options and selectors require values to be specified in a specific for‐
102 mat, which is often non-intuitive. Therefore the terminals in SYNOPSIS
103 have been given descriptive names to indicate the required format
104 and/or maximum allowed numeric value: Prefixes u32, u16 and u8 indicate
105 four, two and single byte unsigned values. E.g. u16 indicates a two
106 byte-sized value in range between 0 and 65535 (0xFFFF) inclusive. A
107 prefix of int indicates a four byte signed value. A middle part of
108 _hex_ indicates that the value is parsed in hexadecimal format. Other‐
109 wise, the value's base is automatically detected, i.e. values prefixed
110 with 0x are considered hexadecimal, a leading 0 indicates octal format
111 and decimal format otherwise. There are some values with special for‐
112 matting as well: ip_address and netmask are in dotted-quad formatting
113 as usual for IPv4 addresses. An ip6_address is specified in common,
114 colon-separated hexadecimal format. Finally, prefixlen is an unsigned,
115 decimal integer value in range from 0 to the address width in bits (32
116 for IPv4 and 128 for IPv6).
117 Sometimes values need to be dividable by a certain number. In that case
119 a name of the form N*val was chosen, indicating that val must be divid‐
120 able by N. Or the other way around: the resulting value must be a mul‐
121 tiple of N.
122
124 U32 recognizes the following options:
125 handle HANDLE
127 The handle is used to reference a filter and therefore must be
128 unique. It consists of a hash table identifier htid and optional
129 hash (which identifies the hash table's bucket) and nodeid. All
130 these values are parsed as unsigned, hexadecimal numbers with
131 length 12bits ( htid and nodeid) or 8bits ( hash). Alterna‐
132 tively one may specify a single, 32bit long hex number which
133 contains the three fields bits in concatenated form. Other than
134 the fields themselves, it has to be prefixed by 0x.
135 offset OFFSET
137 Set an offset which defines where matches of subsequent filters
138 are applied to. Therefore this option is useful only when com‐
139 bined with link or a combination of ht and sample. The offset
140 may be given explicitly by using the plus keyword, or extracted
141 from the packet data with at. It is possible to mangle the lat‐
142 ter using mask and/or shift keywords. By default, this offset is
143 recorded but not implicitly applied. It is used only to substi‐
144 tute the nexthdr+ statement. Using the keyword eat though in‐
145 verses this behaviour: the offset is applied always, and nex‐
146 thdr+ will fall back to zero.
147 hashkey HASHKEY
149 Specify what packet data to use to calculate a hash key for
150 bucket lookup. The kernel adjusts the value according to the
151 hash table's size. For this to work, the option link must be
152 given.
153 classid CLASSID
155 Classify matching packets into the given CLASSID, which consists
156 of either 16bit major and minor numbers or a single 32bit value
157 combining both.
158 divisor u32_value
160 Specify a modulo value. Used when creating hash tables to define
161 their size or for declaring a sample to calculate hash table
162 keys from. Must be a power of two with exponent not exceeding
163 eight.
164 order u32_value
166 A value to order filters by, ascending. Conflicts with handle
167 which serves the same purpose.
168 sample SELECTOR
170 Used together with ht to specify which bucket to add this filter
171 to. This allows one to avoid having to know how exactly the ker‐
172 nel calculates hashes. The additional divisor defaults to 256,
173 so must be given for hash tables of different size.
174 link HANDLE
176 Delegate matching packets to filters in a hash table. HANDLE is
177 used to only specify the hash table, so only htid may be given,
178 hash and nodeid have to be omitted. By default, bucket number 0
179 will be used and can be overridden by the hashkey option.
180 indev ifname
182 Filter on the incoming interface of the packet. Obviously works
183 only for forwarded traffic.
184 skip_sw
186 Do not process filter by software. If hardware has no offload
187 support for this filter, or TC offload is not enabled for the
188 interface, operation will fail.
189 skip_hw
191 Do not process filter by hardware.
192 help Print a brief help text about possible options.
194
196 Basically the only real selector is u32 . All others merely provide a
197 higher level syntax and are internally translated into u32 .
198 u32 VAL_MASK_32
200 u16 VAL_MASK_16
201 u8 VAL_MASK_8
202 Match packet data to a given value. The selector name defines
203 the sample length to extract (32bits for u32, 16bits for u16 and
204 8bits for u8). Before comparing, the sample is binary AND'ed
205 with the given mask. This way uninteresting bits can be cleared
206 before comparison. The position of the sample is defined by the
207 offset specified in AT.
208 ip IP
210 ip6 IP6
211 Assume packet starts with an IPv4 ( ip) or IPv6 ( ip6) header.
212 IP/IP6 then allows to match various header fields:
213 src ADDR
215 dst ADDR
216 Compare Source or Destination Address fields against the
217 value of ADDR. The reserved words default, any and all
218 effectively match any address. Otherwise an IP address of
219 the particular protocol is expected, optionally suffixed
220 by a prefix length to match whole subnets. In case of
221 IPv4 a netmask may also be given.
222 dsfield VAL_MASK_8
224 IPv4 only. Match the packet header's DSCP/ECN field. Syn‐
225 onyms to this are tos and precedence.
226 ihl VAL_MASK_8
228 IPv4 only. Match the Internet Header Length field. Note
229 that the value's unit is 32bits, so to match a packet
230 with 24byte header length u8_value has to be 6.
231 protocol VAL_MASK_8
233 Match the Protocol (IPv4) or Next Header (IPv6) field
234 value, e.g. 6 for TCP.
235 icmp_type VAL_MASK_8
237 icmp_code VAL_MASK_8
238 Assume a next-header protocol of icmp or ipv6-icmp and
239 match Type or Code field values. This is dangerous, as
240 the code assumes minimal header size for IPv4 and lack of
241 extension headers for IPv6.
242 sport VAL_MASK_16
244 dport VAL_MASK_16
245 Match layer four source or destination ports. This is
246 dangerous as well, as it assumes a suitable layer four
247 protocol is present (which has Source and Destination
248 Port fields right at the start of the header and 16bit in
249 size). Also minimal header size for IPv4 and lack of
250 IPv6 extension headers is assumed.
251 nofrag
253 firstfrag
254 df
255 mf IPv4 only, check certain flags and fragment offset val‐
256 ues. Match if the packet is not a fragment (nofrag), the
257 first fragment (firstfrag), if Don't Fragment (df) or
258 More Fragments (mf) bits are set.
259 priority VAL_MASK_8
261 IPv6 only. Match the header's Traffic Class field, which
262 has the same purpose and semantics of IPv4's ToS field
263 since RFC 3168: upper six bits are DSCP, the lower two
264 ECN.
265 flowlabel VAL_MASK_32
267 IPv6 only. Match the Flow Label field's value. Note that
268 Flow Label itself is only 20bytes long, which are the
269 least significant ones here. The remaining upper 12bytes
270 match Version and Traffic Class fields.
271 tcp TCPUDP
273 udp TCPUDP
274 Match fields of next header of protocol TCP or UDP. The possible
275 values for TCPDUP are:
276 src VAL_MASK_16
278 Match on Source Port field value.
279 dst VALMASK_16
281 Match on Destination Port field value.
282 icmp ICMP
284 Match fields of next header of protocol ICMP. The possible val‐
285 ues for ICMP are:
286 type VAL_MASK_8
288 Match on ICMP Type field.
289 code VAL_MASK_8
291 Match on ICMP Code field.
292 mark VAL_MASK_32
294 Match on netfilter fwmark value.
295 ether ETHER
297 Match on ethernet header fields. Possible values for ETHER are:
298 src ether_address AT
300 dst ether_address AT
301 Match on source or destination ethernet address. This is
302 dangerous: It assumes an ethernet header is present at
303 the start of the packet. This will probably lead to unex‐
304 pected things if used with layer three interfaces like
305 e.g. tun or ppp.
306
308 tc filter add dev eth0 parent 999:0 prio 99 protocol ip u32 \
309 match ip src 192.168.8.0/24 classid 1:1
310 This attaches a filter to the qdisc identified by 999:0. It's priority
312 is 99, which affects in which order multiple filters attached to the
313 same parent are consulted (the lower the earlier). The filter handles
314 packets of protocol type ip, and matches if the IP header's source ad‐
315 dress is within the 192.168.8.0/24 subnet. Matching packets are classi‐
316 fied into class 1.1. The effect of this command might be surprising at
317 first glance:
318 filter parent 1: protocol ip pref 99 u32
320 filter parent 1: protocol ip pref 99 u32 \
321 fh 800: ht divisor 1
322 filter parent 1: protocol ip pref 99 u32 \
323 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1 \
324 match c0a80800/ffffff00 at 12
325 So parent 1: is assigned a new u32 filter, which contains a hash table
327 of size 1 (as the divisor indicates). The table ID is 800. The third
328 line then shows the actual filter which was added above: it sits in ta‐
329 ble 800 and bucket 0, classifies packets into class ID 1:1 and matches
330 the upper three bytes of the four byte value at offset 12 to be
331 0xc0a808, which is 192, 168 and 8.
332 Now for something more complicated, namely creating a custom hash ta‐
334 ble:
335 tc filter add dev eth0 prio 99 handle 1: u32 divisor 256
337 This creates a table of size 256 with handle 1: in priority 99. The
339 effect is as follows:
340 filter parent 1: protocol all pref 99 u32
342 filter parent 1: protocol all pref 99 u32 fh 1: ht divisor 256
343 filter parent 1: protocol all pref 99 u32 fh 800: ht divisor 1
344 So along with the requested hash table (handle 1:), the kernel has cre‐
346 ated his own table of size 1 to hold other filters of the same prior‐
347 ity.
348 The next step is to create a filter which links to the created hash ta‐
350 ble:
351 tc filter add dev eth0 parent 1: prio 1 u32 \
353 link 1: hashkey mask 0x0000ff00 at 12 \
354 match ip src 192.168.0.0/16
355 The filter is given a lower priority than the hash table itself so u32
357 consults it before manually traversing the hash table. The options link
358 and hashkey determine which table and bucket to redirect to. In this
359 case the hash key should be constructed out of the second byte at off‐
360 set 12, which corresponds to an IP packet's third byte of the source
361 address field. Along with the match statement, this effectively maps
362 all class C networks below 192.168.0.0/16 to different buckets of the
363 hash table.
364 Filters for certain subnets can be created like so:
366 tc filter add dev eth0 parent 1: prio 99 u32 \
368 ht 1: sample u32 0x00000800 0x0000ff00 at 12 \
369 match ip src 192.168.8.0/24 classid 1:1
370 The bucket is defined using the sample option: In this case, the second
372 byte at offset 12 must be 0x08, exactly. In this case, the resulting
373 bucket ID is obviously 8, but as soon as sample selects an amount of
374 data which could exceed the divisor, one would have to know the kernel-
375 internal algorithm to deduce the destination bucket. This filter's
376 match statement is redundant in this case, as the entropy for the hash
377 key does not exceed the table size and therefore no collisions can oc‐
378 cur. Otherwise it's necessary to prevent matching unwanted packets.
379 Matching upper layer fields is problematic since IPv4 header length is
381 variable and IPv6 supports extension headers which affect upper layer
382 header offset. To overcome this, there is the possibility to specify
383 nexthdr+ when giving an offset, and to make things easier there are the
384 tcp and udp matches which use nexthdr+ implicitly. This offset has to
385 be calculated in beforehand though, and the only way to achieve that is
386 by doing it in a separate filter which then links to the filter which
387 wants to use it. Here is an example of doing so:
388 tc filter add dev eth0 parent 1:0 protocol ip handle 1: \
390 u32 divisor 1
391 tc filter add dev eth0 parent 1:0 protocol ip \
392 u32 ht 1: \
393 match tcp src 22 FFFF \
394 classid 1:2
395 tc filter add dev eth0 parent 1:0 protocol ip \
396 u32 ht 800: \
397 match ip protocol 6 FF \
398 match ip firstfrag \
399 offset at 0 mask 0f00 shift 6 \
400 link 1:
401 This is what is being done: In the first call, a single element sized
403 hash table is created so there is a place to hold the linked to filter
404 and a known handle (1:) to reference to it. The second call then adds
405 the actual filter, which pushes packets with TCP source port 22 into
406 class 1:2. Using ht, it is moved into the hash table created by the
407 first call. The third call then does the actual magic: It matches IPv4
408 packets with next layer protocol 6 (TCP), only if it's the first frag‐
409 ment (usually TCP sets DF bit, but if it doesn't and the packet is
410 fragmented, only the first one contains the TCP header), and then sets
411 the offset based on the IP header's IHL field (right-shifting by 6
412 eliminates the offset of the field and at the same time converts the
413 value into byte unit). Finally, using link, the hash table from first
414 call is referenced which holds the filter from second call.
415
417 tc(8),
418 cls_u32.txt at http://linux-tc-notes.sourceforge.net/
419iproute2 25 Sep 201U5niversal 32bit classifier in tc(8)