{ "mode": "man", "parameter": "tc-u32", "section": "8", "url": "https://www.chedong.com/phpMan.php/man/tc-u32/8/json", "generated": "2026-10-08T12:40:56Z", "synopsis": "tc filter ... [ handle HANDLE ] u32 OPTIONLIST [ offset OFFSET ] [ hashkey HASHKEY ] [ clas‐\nsid CLASSID ] [ divisor uintvalue ] [ order u32value ] [ ht HANDLE ] [ sample SE‐\nLECTOR [ divisor uintvalue ] ] [ link HANDLE ] [ indev ifname ] [ skiphw | skipsw\n] [ help ]\nHANDLE := { u12hexhtid:[u8hexhash:[u12hexnodeid] | 0xu32hexvalue }\nOPTIONLIST := [ OPTIONLIST ] OPTION\nHASHKEY := [ mask u32hexvalue ] [ at 4*intvalue ]\nCLASSID := { root | none | [u16major]:u16minor | u32hexvalue }\nOFFSET := [ plus intvalue ] [ at 2*intvalue ] [ mask u16hexvalue ] [ shift intvalue ] [\neat ]\nOPTION := { match SELECTOR | action ACTION }\nSELECTOR := { u32 VALMASK32 | u16 VALMASK16 | u8 VALMASK8 | ip IP | ip6 IP6 | { tcp |\nudp } TCPUDP | icmp ICMP | mark VALMASK32 | ether ETHER }\nIP := { { src | dst } { default | any | all | ipaddress [ / { prefixlen | netmask } ] } AT |\n{ dsfield | ihl | protocol | precedence | icmptype | icmpcode } VALMASK8 | {\nsport | dport } VALMASK16 | nofrag | firstfrag | df | mf }\nIP6 := { { src | dst } { default | any | all | ip6address [/prefixlen ] } AT | priority\nVALMASK8 | { protocol | icmptype | icmpcode } VALMASK8 | flowlabel VALMASK32\n| { sport | dport } VALMASK16 }\nTCPUDP := { src | dst } VALMASK16\nICMP := { type VALMASK8 | code VALMASK8 }\nETHER := { src | dst } etheraddress AT\nVALMASK32 := u32value u32hexmask [ AT ]\nVALMASK16 := u16value u16hexmask [ AT ]\nVALMASK8 := u8value u8hexmask [ AT ]\nAT := [ at [ nexthdr+ ] intvalue ]", "sections": { "NAME": { "content": "u32 - universal 32bit traffic control filter\n", "subsections": [] }, "SYNOPSIS": { "content": "tc filter ... [ handle HANDLE ] u32 OPTIONLIST [ offset OFFSET ] [ hashkey HASHKEY ] [ clas‐\nsid CLASSID ] [ divisor uintvalue ] [ order u32value ] [ ht HANDLE ] [ sample SE‐\nLECTOR [ divisor uintvalue ] ] [ link HANDLE ] [ indev ifname ] [ skiphw | skipsw\n] [ help ]\n\nHANDLE := { u12hexhtid:[u8hexhash:[u12hexnodeid] | 0xu32hexvalue }\n\nOPTIONLIST := [ OPTIONLIST ] OPTION\n\nHASHKEY := [ mask u32hexvalue ] [ at 4*intvalue ]\n\nCLASSID := { root | none | [u16major]:u16minor | u32hexvalue }\n\nOFFSET := [ plus intvalue ] [ at 2*intvalue ] [ mask u16hexvalue ] [ shift intvalue ] [\neat ]\n\nOPTION := { match SELECTOR | action ACTION }\n\nSELECTOR := { u32 VALMASK32 | u16 VALMASK16 | u8 VALMASK8 | ip IP | ip6 IP6 | { tcp |\nudp } TCPUDP | icmp ICMP | mark VALMASK32 | ether ETHER }\n\nIP := { { src | dst } { default | any | all | ipaddress [ / { prefixlen | netmask } ] } AT |\n{ dsfield | ihl | protocol | precedence | icmptype | icmpcode } VALMASK8 | {\nsport | dport } VALMASK16 | nofrag | firstfrag | df | mf }\n\nIP6 := { { src | dst } { default | any | all | ip6address [/prefixlen ] } AT | priority\nVALMASK8 | { protocol | icmptype | icmpcode } VALMASK8 | flowlabel VALMASK32\n| { sport | dport } VALMASK16 }\n\nTCPUDP := { src | dst } VALMASK16\n\nICMP := { type VALMASK8 | code VALMASK8 }\n\nETHER := { src | dst } etheraddress AT\n\nVALMASK32 := u32value u32hexmask [ AT ]\n\nVALMASK16 := u16value u16hexmask [ AT ]\n\nVALMASK8 := u8value u8hexmask [ AT ]\n\nAT := [ at [ nexthdr+ ] intvalue ]\n", "subsections": [] }, "DESCRIPTION": { "content": "The Universal/Ugly 32bit filter allows one to match arbitrary bitfields in the packet. Due to\nbreaking everything down to values, masks and offsets, It is equally powerful and hard to\nuse. Luckily many abstracting directives are present which allow defining rules on a higher\nlevel and therefore free the user from having to fiddle with bits and masks in many cases.\n\nThere are two general modes of invocation: The first mode creates a new filter to delegate\npackets to different destinations. Apart from the obvious ones, namely classifying the packet\nby specifying a CLASSID or calling an action, one may link one filter to another one (or even\na list of them), effectively organizing filters into a tree-like hierarchy.\n\nTypically filter delegation is done by means of a hash table, which leads to the second mode\nof invocation: it merely serves to set up these hash tables. Filters can select a hash table\nand provide a key selector from which a hash is to be computed and used as key to lookup the\ntable's bucket which contains filters for further processing. This is useful if a high number\nof filters is in use, as the overhead of performing the hash operation and table lookup be‐\ncomes negligible in that case. Using hashtables with u32 basically involves the following\npattern:\n\n(1) Creating a new hash table, specifying it's size using the divisor parameter and ideally a\nhandle by which the table can be identified. If the latter is not given, the kernel\nchooses one on it's own, which has to be guessed later.\n\n(2) Creating filters which link to the created table in (1) using the link parameter and\ndefining the packet data which the kernel will use to calculate the hashkey.\n\n(3) Adding filters to buckets in the hash table from (1). In order to avoid having to know\nhow exactly the kernel creates the hash key, there is the sample parameter, which gives\nsample data to hash and thereby define the table bucket the filter should be added to.\n\nIn fact, even if not explicitly requested u32 creates a hash table for every priority a fil‐\nter is being added with. The table's size is 1 though, so it is in fact merely a linked list.\n", "subsections": [] }, "VALUES": { "content": "Options and selectors require values to be specified in a specific format, which is often\nnon-intuitive. Therefore the terminals in SYNOPSIS have been given descriptive names to indi‐\ncate the required format and/or maximum allowed numeric value: Prefixes u32, u16 and u8 indi‐\ncate four, two and single byte unsigned values. E.g. u16 indicates a two byte-sized value in\nrange between 0 and 65535 (0xFFFF) inclusive. A prefix of int indicates a four byte signed\nvalue. A middle part of hex indicates that the value is parsed in hexadecimal format. Oth‐\nerwise, the value's base is automatically detected, i.e. values prefixed with 0x are consid‐\nered hexadecimal, a leading 0 indicates octal format and decimal format otherwise. There are\nsome values with special formatting as well: ipaddress and netmask are in dotted-quad for‐\nmatting as usual for IPv4 addresses. An ip6address is specified in common, colon-separated\nhexadecimal format. Finally, prefixlen is an unsigned, decimal integer value in range from 0\nto the address width in bits (32 for IPv4 and 128 for IPv6).\n\nSometimes values need to be dividable by a certain number. In that case a name of the form\nN*val was chosen, indicating that val must be dividable by N. Or the other way around: the\nresulting value must be a multiple of N.\n", "subsections": [] }, "OPTIONS": { "content": "U32 recognizes the following options:\n\nhandle HANDLE\nThe handle is used to reference a filter and therefore must be unique. It consists of\na hash table identifier htid and optional hash (which identifies the hash table's\nbucket) and nodeid. All these values are parsed as unsigned, hexadecimal numbers with\nlength 12bits ( htid and nodeid) or 8bits ( hash). Alternatively one may specify a\nsingle, 32bit long hex number which contains the three fields bits in concatenated\nform. Other than the fields themselves, it has to be prefixed by 0x.\n\noffset OFFSET\nSet an offset which defines where matches of subsequent filters are applied to.\nTherefore this option is useful only when combined with link or a combination of ht\nand sample. The offset may be given explicitly by using the plus keyword, or ex‐\ntracted from the packet data with at. It is possible to mangle the latter using mask\nand/or shift keywords. By default, this offset is recorded but not implicitly applied.\nIt is used only to substitute the nexthdr+ statement. Using the keyword eat though in‐\nverses this behaviour: the offset is applied always, and nexthdr+ will fall back to\nzero.\n\nhashkey HASHKEY\nSpecify what packet data to use to calculate a hash key for bucket lookup. The kernel\nadjusts the value according to the hash table's size. For this to work, the option\nlink must be given.\n\nclassid CLASSID\nClassify matching packets into the given CLASSID, which consists of either 16bit major\nand minor numbers or a single 32bit value combining both.\n\ndivisor u32value\nSpecify a modulo value. Used when creating hash tables to define their size or for de‐\nclaring a sample to calculate hash table keys from. Must be a power of two with expo‐\nnent not exceeding eight.\n\norder u32value\nA value to order filters by, ascending. Conflicts with handle which serves the same\npurpose.\n\nsample SELECTOR\nUsed together with ht to specify which bucket to add this filter to. This allows one\nto avoid having to know how exactly the kernel calculates hashes. The additional divi‐\nsor defaults to 256, so must be given for hash tables of different size.\n\nlink HANDLE\nDelegate matching packets to filters in a hash table. HANDLE is used to only specify\nthe hash table, so only htid may be given, hash and nodeid have to be omitted. By de‐\nfault, bucket number 0 will be used and can be overridden by the hashkey option.\n\nindev ifname\nFilter on the incoming interface of the packet. Obviously works only for forwarded\ntraffic.\n", "subsections": [ { "name": "skip_sw", "content": "Do not process filter by software. If hardware has no offload support for this filter,\nor TC offload is not enabled for the interface, operation will fail.\n" }, { "name": "skip_hw", "content": "Do not process filter by hardware.\n\nhelp Print a brief help text about possible options.\n" } ] }, "SELECTORS": { "content": "Basically the only real selector is u32 . All others merely provide a higher level syntax\nand are internally translated into u32 .\n\nu32 VALMASK32\nu16 VALMASK16\nu8 VALMASK8\nMatch packet data to a given value. The selector name defines the sample length to ex‐\ntract (32bits for u32, 16bits for u16 and 8bits for u8). Before comparing, the sample\nis binary AND'ed with the given mask. This way uninteresting bits can be cleared be‐\nfore comparison. The position of the sample is defined by the offset specified in AT.\n\nip IP\nip6 IP6\nAssume packet starts with an IPv4 ( ip) or IPv6 ( ip6) header. IP/IP6 then allows one\nto match various header fields:\n\nsrc ADDR\ndst ADDR\nCompare Source or Destination Address fields against the value of ADDR. The\nreserved words default, any and all effectively match any address. Otherwise an\nIP address of the particular protocol is expected, optionally suffixed by a\nprefix length to match whole subnets. In case of IPv4 a netmask may also be\ngiven.\n\ndsfield VALMASK8\nIPv4 only. Match the packet header's DSCP/ECN field. Synonyms to this are tos\nand precedence.\n\nihl VALMASK8\nIPv4 only. Match the Internet Header Length field. Note that the value's unit\nis 32bits, so to match a packet with 24byte header length u8value has to be 6.\n\nprotocol VALMASK8\nMatch the Protocol (IPv4) or Next Header (IPv6) field value, e.g. 6 for TCP.\n\nicmptype VALMASK8\nicmpcode VALMASK8\nAssume a next-header protocol of icmp or ipv6-icmp and match Type or Code field\nvalues. This is dangerous, as the code assumes minimal header size for IPv4 and\nlack of extension headers for IPv6.\n\nsport VALMASK16\ndport VALMASK16\nMatch layer four source or destination ports. This is dangerous as well, as it\nassumes a suitable layer four protocol is present (which has Source and Desti‐\nnation Port fields right at the start of the header and 16bit in size). Also\nminimal header size for IPv4 and lack of IPv6 extension headers is assumed.\n\nnofrag\nfirstfrag\ndf\nmf IPv4 only, check certain flags and fragment offset values. Match if the packet\nis not a fragment (nofrag), the first fragment of a fragmented packet (first‐\nfrag), if Don't Fragment (df) or More Fragments (mf) bits are set.\n\npriority VALMASK8\nIPv6 only. Match the header's Traffic Class field, which has the same purpose\nand semantics of IPv4's ToS field since RFC 3168: upper six bits are DSCP, the\nlower two ECN.\n\nflowlabel VALMASK32\nIPv6 only. Match the Flow Label field's value. Note that Flow Label itself is\nonly 20bytes long, which are the least significant ones here. The remaining up‐\nper 12bytes match Version and Traffic Class fields.\n\ntcp TCPUDP\nudp TCPUDP\nMatch fields of next header of protocol TCP or UDP. The possible values for TCPDUP\nare:\n\nsrc VALMASK16\nMatch on Source Port field value.\n\ndst VALMASK16\nMatch on Destination Port field value.\n\nicmp ICMP\nMatch fields of next header of protocol ICMP. The possible values for ICMP are:\n\ntype VALMASK8\nMatch on ICMP Type field.\n\ncode VALMASK8\nMatch on ICMP Code field.\n\nmark VALMASK32\nMatch on netfilter fwmark value.\n\nether ETHER\nMatch on ethernet header fields. Possible values for ETHER are:\n\nsrc etheraddress AT\ndst etheraddress AT\nMatch on source or destination ethernet address. This is dangerous: It assumes\nan ethernet header is present at the start of the packet. This will probably\nlead to unexpected things if used with layer three interfaces like e.g. tun or\nppp.\n", "subsections": [] }, "EXAMPLES": { "content": "tc filter add dev eth0 parent 999:0 prio 99 protocol ip u32 \\\nmatch ip src 192.168.8.0/24 classid 1:1\n\nThis attaches a filter to the qdisc identified by 999:0. It's priority is 99, which affects\nin which order multiple filters attached to the same parent are consulted (the lower the ear‐\nlier). The filter handles packets of protocol type ip, and matches if the IP header's source\naddress is within the 192.168.8.0/24 subnet. Matching packets are classified into class 1.1.\nThe effect of this command might be surprising at first glance:\n\nfilter parent 1: protocol ip pref 99 u32\nfilter parent 1: protocol ip pref 99 u32 \\\nfh 800: ht divisor 1\nfilter parent 1: protocol ip pref 99 u32 \\\nfh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1 \\\nmatch c0a80800/ffffff00 at 12\n\nSo parent 1: is assigned a new u32 filter, which contains a hash table of size 1 (as the di‐\nvisor indicates). The table ID is 800. The third line then shows the actual filter which was\nadded above: it sits in table 800 and bucket 0, classifies packets into class ID 1:1 and\nmatches the upper three bytes of the four byte value at offset 12 to be 0xc0a808, which is\n192, 168 and 8.\n\nNow for something more complicated, namely creating a custom hash table:\n\ntc filter add dev eth0 prio 99 handle 1: u32 divisor 256\n\nThis creates a table of size 256 with handle 1: in priority 99. The effect is as follows:\n\nfilter parent 1: protocol all pref 99 u32\nfilter parent 1: protocol all pref 99 u32 fh 1: ht divisor 256\nfilter parent 1: protocol all pref 99 u32 fh 800: ht divisor 1\n\nSo along with the requested hash table (handle 1:), the kernel has created his own table of\nsize 1 to hold other filters of the same priority.\n\nThe next step is to create a filter which links to the created hash table:\n\ntc filter add dev eth0 parent 1: prio 1 u32 \\\nlink 1: hashkey mask 0x0000ff00 at 12 \\\nmatch ip src 192.168.0.0/16\n\nThe filter is given a lower priority than the hash table itself so u32 consults it before\nmanually traversing the hash table. The options link and hashkey determine which table and\nbucket to redirect to. In this case the hash key should be constructed out of the second byte\nat offset 12, which corresponds to an IP packet's third byte of the source address field.\nAlong with the match statement, this effectively maps all class C networks below\n192.168.0.0/16 to different buckets of the hash table.\n\nFilters for certain subnets can be created like so:\n\ntc filter add dev eth0 parent 1: prio 99 u32 \\\nht 1: sample u32 0x00000800 0x0000ff00 at 12 \\\nmatch ip src 192.168.8.0/24 classid 1:1\n\nThe bucket is defined using the sample option: In this case, the second byte at offset 12\nmust be 0x08, exactly. In this case, the resulting bucket ID is obviously 8, but as soon as\nsample selects an amount of data which could exceed the divisor, one would have to know the\nkernel-internal algorithm to deduce the destination bucket. This filter's match statement is\nredundant in this case, as the entropy for the hash key does not exceed the table size and\ntherefore no collisions can occur. Otherwise it's necessary to prevent matching unwanted\npackets.\n\nMatching upper layer fields is problematic since IPv4 header length is variable and IPv6 sup‐\nports extension headers which affect upper layer header offset. To overcome this, there is\nthe possibility to specify nexthdr+ when giving an offset, and to make things easier there\nare the tcp and udp matches which use nexthdr+ implicitly. This offset has to be calculated\nin beforehand though, and the only way to achieve that is by doing it in a separate filter\nwhich then links to the filter which wants to use it. Here is an example of doing so:\n\ntc filter add dev eth0 parent 1:0 protocol ip handle 1: \\\nu32 divisor 1\ntc filter add dev eth0 parent 1:0 protocol ip \\\nu32 ht 1: \\\nmatch tcp src 22 FFFF \\\nclassid 1:2\ntc filter add dev eth0 parent 1:0 protocol ip \\\nu32 ht 800: \\\nmatch ip protocol 6 FF \\\nmatch u16 0 1fff at 6 \\\noffset at 0 mask 0f00 shift 6 \\\nlink 1:\n\nThis is what is being done: In the first call, a single element sized hash table is created\nso there is a place to hold the linked to filter and a known handle (1:) to reference to it.\nThe second call then adds the actual filter, which pushes packets with TCP source port 22\ninto class 1:2. Using ht, it is moved into the hash table created by the first call. The\nthird call then does the actual magic: It matches IPv4 packets with next layer protocol 6\n(TCP), only if it's the first fragment (usually TCP sets DF bit, but if it doesn't and the\npacket is fragmented, only the first one contains the TCP header), and then sets the offset\nbased on the IP header's IHL field (right-shifting by 6 eliminates the offset of the field\nand at the same time converts the value into byte unit). Finally, using link, the hash table\nfrom first call is referenced which holds the filter from second call.\n", "subsections": [] }, "SEE ALSO": { "content": "tc(8),\nclsu32.txt at http://linux-tc-notes.sourceforge.net/\n\niproute2 25 Sep 2015 Universal 32bit classifier in tc(8)", "subsections": [] } }, "summary": "u32 - universal 32bit traffic control filter", "flags": [], "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 ear‐", "lier). 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 di‐", "visor 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 sup‐", "ports 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 u16 0 1fff at 6 \\", "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." ], "see_also": [ { "name": "tc", "section": "8", "url": "https://www.chedong.com/phpMan.php/man/tc/8/json" }, { "name": "tc", "section": "8", "url": "https://www.chedong.com/phpMan.php/man/tc/8/json" } ] }