tc-u32(8) - phpMan

Command: man perldoc info search(apropos)  

Universal 32bit classifier in tc(8)  Linux Universal 32bit classifier in tc(8)

       u32 - universal 32bit traffic control filter

       tc filter ... [ handle HANDLE ] u32 OPTION_LIST [ offset OFFSET ] [ hashkey HASHKEY
               ] [ classid CLASSID ] [ divisor uint_value ] [ order u32_value ] [ ht  HAN-
               DLE  ]  [  sample SELECTOR [ divisor uint_value ] ] [ link HANDLE ] [ indev
               ifname ] [ help ]

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


       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 ]

       The  Universal/Ugly 32bit filter allows to match arbitrary bitfields in the packet.
       Due to breaking everything down to values, masks and offsets, It is equally  power-
       ful  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 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 com-
       puted and used as key to lookup the table's bucket which contains filters for  fur-
       ther processing. This is useful if a high number of filters is in use, as the over-
       head 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 parame-
           ter and defining the packet data which the kernel will  use  to  calculate  the

       (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 param-
           eter,  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

       Options and selectors require values to be specified in a specific format, which is
       often  non-intuitive.  Therefore the terminals in SYNOPSIS have been given descrip-
       tive 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)  inclu-
       sive.  A  prefix  of int indicates a four byte signed value. A middle part of _hex_
       indicates that the value is parsed in hexadecimal format.  Otherwise,  the  value's
       base  is  automatically  detected, i.e. values prefixed with 0x are considered hex-
       adecimal, a leading 0 indicates octal format and decimal  format  otherwise.  There
       are some values with special formatting as well: ip_address and netmask are in dot-
       ted-quad formatting as usual for IPv4 addresses. An  ip6_address  is  specified  in
       common, colon-separated hexadecimal format. Finally, prefixlen is an unsigned, dec-
       imal 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  dividable  by  N.   Or  the
       other way around: the resulting value must be a multiple of N.

       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).   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  com-
              bination  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 overrid-
              den 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.

       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 selec-
              tor  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 compari-
              son. 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. Synonyms 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
                     values.  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

       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 values for ICMP

              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 unexpected things  if
                     used with layer three interfaces like e.g. tun or ppp.

              tc filter add dev eth0 parent 999:0 prio 99 protocol ip u32 \
                      match ip src 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  con-
       sulted (the lower the earlier). The filter handles packets of protocol type ip, and
       matches if the IP header's source address  is  within  the  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

              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

       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 con-
       structed 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 effec-
       tively maps all class C networks below 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 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 ta-
       ble from first call is referenced which holds the filter from second call.

       cls_u32.txt at

iproute2                          25 Sep 20Universal 32bit classifier in tc(8)

Generated by $Id: phpMan.php,v 4.55 2007/09/05 04:42:51 chedong Exp $ Author: Che Dong
On Apache
Under GNU General Public License
2017-12-12 19:32 @ CrawledBy CCBot/2.0 (
Valid XHTML 1.0!Valid CSS!