1Universal 32bit classifier in tc(8)  Linux Universal 32bit classifier in tc(8)
2
3
4

NAME

6       u32 - universal 32bit traffic control filter
7

SYNOPSIS

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
15       HANDLE     :=     {     u12_hex_htid:[u8_hex_hash:[u12_hex_nodeid]    |
16               0xu32_hex_value }
17
18       OPTION_LIST := [ OPTION_LIST ] OPTION
19
20       HASHKEY := [ mask u32_hex_value ] [ at 4*int_value ]
21
22       CLASSID := { root | none | [u16_major]:u16_minor | u32_hex_value }
23
24       OFFSET := [ plus int_value ] [ at 2*int_value ] [ mask u16_hex_value  ]
25               [ shift int_value ] [ eat ]
26
27       OPTION := { match SELECTOR | action ACTION }
28
29       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
33       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
38       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
43       TCPUDP := { src | dst } VAL_MASK_16
44
45       ICMP := { type VAL_MASK_8 | code VAL_MASK_8 }
46
47       ETHER := { src | dst } ether_address AT
48
49       VAL_MASK_32 := u32_value u32_hex_mask [ AT ]
50
51       VAL_MASK_16 := u16_value u16_hex_mask [ AT ]
52
53       VAL_MASK_8 := u8_value u8_hex_mask [ AT ]
54
55       AT := [ at [ nexthdr+ ] int_value ]
56

DESCRIPTION

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
65       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
72       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
82       (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
87       (2) Creating filters which link to the created table in (1)  using  the
88           link  parameter  and defining the packet data which the kernel will
89           use to calculate the hashkey.
90
91       (3) Adding filters to buckets in the hash table from (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
96In  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

98in fact merely a linked list.
99

VALUES

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
118       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

OPTIONS

124       U32 recognizes the following options:
125
126       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
136       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
145              inverses this behaviour: the offset is applied always, and  nex‐
146              thdr+ will fall back to zero.
147
148       hashkey HASHKEY
149              Spefify  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
154       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
159       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
165       order u32_value
166              A  value  to  order filters by, ascending. Conflicts with handle
167              which serves the same purpose.
168
169       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
175       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
181       indev ifname
182              Filter on the incoming interface of the packet. Obviously  works
183              only for forwarded traffic.
184
185       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
190       skip_hw
191              Do not process filter by hardware.
192
193       help   Print a brief help text about possible options.
194

SELECTORS

196       Basically  the only real selector is u32 .  All others merely provide a
197       higher level syntax and are internally translated into u32 .
198
199       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
209       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
214              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
223              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
227              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
232              protocol VAL_MASK_8
233                     Match the Protocol (IPv4) or  Next  Header  (IPv6)  field
234                     value, e.g. 6 for TCP.
235
236              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
243              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
252              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
260              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
266              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
272       tcp TCPUDP
273       udp TCPUDP
274              Match fields of next header of protocol TCP or UDP. The possible
275              values for TCPDUP are:
276
277              src VAL_MASK_16
278                     Match on Source Port field value.
279
280              dst VALMASK_16
281                     Match on Destination Port field value.
282
283       icmp ICMP
284              Match  fields of next header of protocol ICMP. The possible val‐
285              ues for ICMP are:
286
287              type VAL_MASK_8
288                     Match on ICMP Type field.
289
290              code VAL_MASK_8
291                     Match on ICMP Code field.
292
293       mark VAL_MASK_32
294              Match on netfilter fwmark value.
295
296       ether ETHER
297              Match on ethernet header fields. Possible values for ETHER are:
298
299              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

EXAMPLES

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
311       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
315       address is within the 192.168.8.0/24 subnet. Matching packets are clas‐
316       sified  into class 1.1.  The effect of this command might be surprising
317       at first glance:
318
319              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
326       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
333       Now  for  something more complicated, namely creating a custom hash ta‐
334       ble:
335
336              tc filter add dev eth0 prio 99 handle 1: u32 divisor 256
337
338       This creates a table of size 256 with handle 1: in  priority  99.   The
339       effect is as follows:
340
341              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
345       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
349       The next step is to create a filter which links to the created hash ta‐
350       ble:
351
352              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
356       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
365       Filters for certain subnets can be created like so:
366
367              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
371       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
378       occur. Otherwise it's necessary to prevent matching unwanted packets.
379
380       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
389              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
402       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

SEE ALSO

417       tc(8),
418       cls_u32.txt at http://linux-tc-notes.sourceforge.net/
419
420
421
422iproute2                          25 Sep 201U5niversal 32bit classifier in tc(8)
Impressum