1021 lines
22 KiB
HTML
1021 lines
22 KiB
HTML
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<HTML><HEAD><TITLE>Man page of Universal 32bit classifier in tc</TITLE>
|
|
</HEAD><BODY>
|
|
<H1>Universal 32bit classifier in tc</H1>
|
|
Section: Linux (8)<BR>Updated: 25 Sep 2015<BR><A HREF="#index">Index</A>
|
|
<A HREF="/cgi-bin/man/man2html">Return to Main Contents</A><HR>
|
|
|
|
<P>
|
|
<A NAME="lbAB"> </A>
|
|
<H2>NAME</H2>
|
|
|
|
u32 - universal 32bit traffic control filter
|
|
<A NAME="lbAC"> </A>
|
|
<H2>SYNOPSIS</H2>
|
|
|
|
|
|
<BR>
|
|
|
|
<B>tc</B> <B>filter</B> ... [ <B>handle</B>
|
|
|
|
<I>HANDLE</I> ]
|
|
|
|
<B>u32</B>
|
|
|
|
<I>OPTION_LIST</I> [
|
|
|
|
<B>offset</B>
|
|
|
|
<I>OFFSET</I> ] [
|
|
|
|
<B>hashkey</B>
|
|
|
|
<I>HASHKEY</I> ] [
|
|
|
|
<B>classid</B>
|
|
|
|
<I>CLASSID</I> ] [
|
|
|
|
<B>divisor</B>
|
|
|
|
<I>uint_value</I> ] [
|
|
|
|
<B>order</B>
|
|
|
|
<I>u32_value</I> ] [
|
|
|
|
<B>ht</B>
|
|
|
|
<I>HANDLE</I> ] [
|
|
|
|
<B>sample</B>
|
|
|
|
<I>SELECTOR</I> [
|
|
|
|
<B>divisor</B>
|
|
|
|
<I>uint_value</I> ] ] [
|
|
|
|
<B>link</B>
|
|
|
|
<I>HANDLE</I> ] [
|
|
|
|
<B>indev</B>
|
|
|
|
<I>ifname</I> ] [
|
|
|
|
<B>skip_hw</B> |
|
|
|
|
<B>skip_sw</B> ] [
|
|
|
|
<B>help</B> ]
|
|
|
|
<P>
|
|
<BR>
|
|
|
|
<I>HANDLE</I> := {
|
|
|
|
<I>u12_hex_htid</I><B>:</B>[<I>u8_hex_hash</I><B>:</B>[<I>u12_hex_nodeid</I>] | <B>0x</B><I>u32_hex_value</I> }
|
|
<P>
|
|
<BR>
|
|
|
|
<I>OPTION_LIST</I> := [ <I>OPTION_LIST</I> ] <I>OPTION</I>
|
|
|
|
<P>
|
|
<BR>
|
|
|
|
<I>HASHKEY</I> := [
|
|
|
|
<B>mask</B>
|
|
|
|
<I>u32_hex_value</I> ] [
|
|
|
|
<B>at</B>
|
|
|
|
<I>4*int_value</I> ]
|
|
|
|
<P>
|
|
<BR>
|
|
|
|
<I>CLASSID</I> := {
|
|
|
|
<B>root</B> |
|
|
|
|
<B>none</B> |
|
|
|
|
[<I>u16_major</I>]<B>:</B><I>u16_minor</I> | <I>u32_hex_value</I> }
|
|
<P>
|
|
<BR>
|
|
|
|
<I>OFFSET</I> := [
|
|
|
|
<B>plus</B>
|
|
|
|
<I>int_value</I> ] [
|
|
|
|
<B>at</B>
|
|
|
|
<I>2*int_value</I> ] [
|
|
|
|
<B>mask</B>
|
|
|
|
<I>u16_hex_value</I> ] [
|
|
|
|
<B>shift</B>
|
|
|
|
<I>int_value</I> ] [
|
|
|
|
<B>eat</B> ]
|
|
|
|
<P>
|
|
<BR>
|
|
|
|
<I>OPTION</I> := {
|
|
|
|
<B>match</B>
|
|
|
|
<I>SELECTOR</I> |
|
|
|
|
<B>action</B>
|
|
|
|
<I>ACTION</I> }
|
|
|
|
<P>
|
|
<BR>
|
|
|
|
<I>SELECTOR</I> := {
|
|
|
|
<B>u32</B>
|
|
|
|
<I>VAL_MASK_32</I> |
|
|
|
|
<B>u16</B>
|
|
|
|
<I>VAL_MASK_16</I> |
|
|
|
|
<B>u8</B>
|
|
|
|
<I>VAL_MASK_8</I> |
|
|
|
|
<B>ip</B>
|
|
|
|
<I>IP</I> |
|
|
|
|
<B>ip6</B>
|
|
|
|
<I>IP6</I> | {
|
|
|
|
<B>tcp</B> | <B>udp</B> }
|
|
|
|
<I>TCPUDP</I> |
|
|
|
|
<B>icmp</B>
|
|
|
|
<I>ICMP</I> |
|
|
|
|
<B>mark</B>
|
|
|
|
<I>VAL_MASK_32</I> |
|
|
|
|
<B>ether</B>
|
|
|
|
<I>ETHER</I> }
|
|
|
|
<P>
|
|
<BR>
|
|
|
|
<I>IP</I> := { {
|
|
|
|
<B>src</B> | <B>dst</B> } { <B>default</B> | <B>any</B> | <B>all</B> |
|
|
|
|
<I>ip_address</I> [
|
|
|
|
<B>/</B> {
|
|
|
|
<I>prefixlen</I> | <I>netmask</I> } ] } <I>AT</I> | {
|
|
|
|
<B>dsfield</B> | <B>ihl</B> | <B>protocol</B> | <B>precedence</B> |
|
|
|
|
<B>icmp_type</B> | <B>icmp_code</B> }
|
|
|
|
<I>VAL_MASK_8</I> | {
|
|
|
|
<B>sport</B> | <B>dport</B> }
|
|
|
|
<I>VAL_MASK_16</I> |
|
|
|
|
<B>nofrag</B> | <B>firstfrag</B> | <B>df</B> | <B>mf</B> }
|
|
|
|
<P>
|
|
<BR>
|
|
|
|
<I>IP6</I> := { {
|
|
|
|
<B>src</B> | <B>dst</B> } { <B>default</B> | <B>any</B> | <B>all</B> |
|
|
|
|
<I>ip6_address</I> [/<I>prefixlen</I> ] } <I>AT</I> |
|
|
|
|
<B>priority</B>
|
|
|
|
<I>VAL_MASK_8</I> | {
|
|
|
|
<B>protocol</B> | <B>icmp_type</B> | <B>icmp_code</B> }
|
|
|
|
<I>VAL_MASK_8</I> |
|
|
|
|
<B>flowlabel</B>
|
|
|
|
<I>VAL_MASK_32</I> | {
|
|
|
|
<B>sport</B> | <B>dport</B> }
|
|
|
|
<I>VAL_MASK_16</I> }
|
|
|
|
<P>
|
|
<BR>
|
|
|
|
<I>TCPUDP</I> := {
|
|
|
|
<B>src</B> | <B>dst</B> }
|
|
|
|
<I>VAL_MASK_16</I>
|
|
|
|
<P>
|
|
<BR>
|
|
|
|
<I>ICMP</I> := {
|
|
|
|
<B>type</B>
|
|
|
|
<I>VAL_MASK_8</I> |
|
|
|
|
<B>code</B>
|
|
|
|
<I>VAL_MASK_8</I> }
|
|
|
|
<P>
|
|
<BR>
|
|
|
|
<I>ETHER</I> := {
|
|
|
|
<B>src</B> | <B>dst</B> }
|
|
|
|
<I>ether_address</I> <I>AT</I>
|
|
|
|
<P>
|
|
<BR>
|
|
|
|
<I>VAL_MASK_32</I> := <I>u32_value</I> <I>u32_hex_mask</I> [ <I>AT</I> ]
|
|
|
|
<P>
|
|
<BR>
|
|
|
|
<I>VAL_MASK_16</I> := <I>u16_value</I> <I>u16_hex_mask</I> [ <I>AT</I> ]
|
|
|
|
<P>
|
|
<BR>
|
|
|
|
<I>VAL_MASK_8</I> := <I>u8_value</I> <I>u8_hex_mask</I> [ <I>AT</I> ]
|
|
|
|
<P>
|
|
<BR>
|
|
|
|
<I>AT</I> := [
|
|
|
|
<B>at</B> [ <B>nexthdr+</B> ]
|
|
|
|
<I>int_value</I> ]
|
|
|
|
<A NAME="lbAD"> </A>
|
|
<H2>DESCRIPTION</H2>
|
|
|
|
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 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.
|
|
<P>
|
|
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
|
|
<I>CLASSID</I>
|
|
|
|
or calling an
|
|
<B>action</B>,
|
|
|
|
one may
|
|
<B>link</B>
|
|
|
|
one filter to another one (or even a list of them), effectively organizing
|
|
filters into a tree-like hierarchy.
|
|
<P>
|
|
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
|
|
<B>u32</B>
|
|
|
|
basically involves the following pattern:
|
|
<DL COMPACT>
|
|
<DT id="1">(1)<DD>
|
|
Creating a new hash table, specifying it's size using the
|
|
<B>divisor</B>
|
|
|
|
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.
|
|
<DT id="2">(2)<DD>
|
|
Creating filters which link to the created table in
|
|
<I>(1)</I>
|
|
|
|
using the
|
|
<B>link</B>
|
|
|
|
parameter and defining the packet data which the kernel will use to calculate
|
|
the
|
|
<B>hashkey</B>.
|
|
|
|
<DT id="3">(3)<DD>
|
|
Adding filters to buckets in the hash table from
|
|
<I>(1)</I>.
|
|
|
|
In order to avoid having to know how exactly the kernel creates the hash key,
|
|
there is the
|
|
<B>sample</B>
|
|
|
|
parameter, which gives sample data to hash and thereby define the table bucket
|
|
the filter should be added to.
|
|
<P>
|
|
|
|
In fact, even if not explicitly requested
|
|
<B>u32</B>
|
|
|
|
creates a hash table for every
|
|
<B>priority</B>
|
|
|
|
a filter is being added with. The table's size is 1 though, so it is in fact
|
|
merely a linked list.
|
|
</DL>
|
|
<A NAME="lbAE"> </A>
|
|
<H2>VALUES</H2>
|
|
|
|
Options and selectors require values to be specified in a specific format, which
|
|
is often non-intuitive. Therefore the terminals in
|
|
<I>SYNOPSIS</I>
|
|
|
|
have been given descriptive names to indicate the required format and/or maximum
|
|
allowed numeric value: Prefixes
|
|
<I>u32</I>, <I>u16</I> and <I>u8</I>
|
|
|
|
indicate four, two and single byte unsigned values. E.g.
|
|
<I>u16</I>
|
|
|
|
indicates a two byte-sized value in range between 0 and 65535 (0xFFFF)
|
|
inclusive. A prefix of
|
|
<I>int</I>
|
|
|
|
indicates a four byte signed value. A middle part of
|
|
<I>_hex_</I>
|
|
|
|
indicates that the value is parsed in hexadecimal format. Otherwise, the
|
|
value's base is automatically detected, i.e. values prefixed with
|
|
<I>0x</I>
|
|
|
|
are considered hexadecimal, a leading
|
|
<I>0</I>
|
|
|
|
indicates octal format and decimal format otherwise. There are some values with
|
|
special formatting as well:
|
|
<I>ip_address</I> and <I>netmask</I>
|
|
|
|
are in dotted-quad formatting as usual for IPv4 addresses. An
|
|
<I>ip6_address</I>
|
|
|
|
is specified in common, colon-separated hexadecimal format. Finally,
|
|
<I>prefixlen</I>
|
|
|
|
is an unsigned, decimal integer value in range from 0 to the address width in
|
|
bits (32 for IPv4 and 128 for IPv6).
|
|
<P>
|
|
Sometimes values need to be dividable by a certain number. In that case a name
|
|
of the form
|
|
<I>N*val</I>
|
|
|
|
was chosen, indicating that
|
|
<I>val</I>
|
|
|
|
must be dividable by
|
|
<I>N</I>.
|
|
|
|
Or the other way around: the resulting value must be a multiple of
|
|
<I>N</I>.
|
|
|
|
<A NAME="lbAF"> </A>
|
|
<H2>OPTIONS</H2>
|
|
|
|
<B>U32</B>
|
|
|
|
recognizes the following options:
|
|
<DL COMPACT>
|
|
<DT id="4"><B>handle</B><I> HANDLE</I>
|
|
|
|
<DD>
|
|
The handle is used to reference a filter and therefore must be unique. It
|
|
consists of a hash table identifier
|
|
<B>htid</B>
|
|
|
|
and optional
|
|
<B>hash</B>
|
|
|
|
(which identifies the hash table's bucket) and
|
|
<B>nodeid</B>.
|
|
|
|
All these values are parsed as unsigned, hexadecimal numbers with length 12bits
|
|
(
|
|
<B>htid</B> and <B>nodeid</B>)
|
|
|
|
or 8bits (
|
|
<B>hash</B>).
|
|
|
|
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
|
|
<B>0x</B>.
|
|
|
|
<DT id="5"><B>offset</B><I> OFFSET</I>
|
|
|
|
<DD>
|
|
Set an offset which defines where matches of subsequent filters are applied to.
|
|
Therefore this option is useful only when combined with
|
|
<B>link</B> or a combination of <B>ht</B> and <B>sample</B>.
|
|
|
|
The offset may be given explicitly by using the
|
|
<B>plus</B>
|
|
|
|
keyword, or extracted from the packet data with
|
|
<B>at</B>.
|
|
|
|
It is possible to mangle the latter using
|
|
<B>mask</B> and/or <B>shift</B>
|
|
|
|
keywords. By default, this offset is recorded but not implicitly applied. It is
|
|
used only to substitute the
|
|
<B>nexthdr+</B>
|
|
|
|
statement. Using the keyword
|
|
<B>eat</B>
|
|
|
|
though inverses this behaviour: the offset is applied always, and
|
|
<B>nexthdr+</B>
|
|
|
|
will fall back to zero.
|
|
<DT id="6"><B>hashkey</B><I> HASHKEY</I>
|
|
|
|
<DD>
|
|
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
|
|
<B>link</B>
|
|
|
|
must be given.
|
|
<DT id="7"><B>classid</B><I> CLASSID</I>
|
|
|
|
<DD>
|
|
Classify matching packets into the given
|
|
<I>CLASSID</I>,
|
|
|
|
which consists of either 16bit
|
|
<B>major</B> and <B>minor</B>
|
|
|
|
numbers or a single 32bit value combining both.
|
|
<DT id="8"><B>divisor</B><I> u32_value</I>
|
|
|
|
<DD>
|
|
Specify a modulo value. Used when creating hash tables to define their size or
|
|
for declaring a
|
|
<B>sample</B>
|
|
|
|
to calculate hash table keys from. Must be a power of two with exponent not
|
|
exceeding eight.
|
|
<DT id="9"><B>order</B><I> u32_value</I>
|
|
|
|
<DD>
|
|
A value to order filters by, ascending. Conflicts with
|
|
<B>handle</B>
|
|
|
|
which serves the same purpose.
|
|
<DT id="10"><B>sample</B><I> SELECTOR</I>
|
|
|
|
<DD>
|
|
Used together with
|
|
<B>ht</B>
|
|
|
|
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
|
|
<B>divisor</B>
|
|
|
|
defaults to 256, so must be given for hash tables of different size.
|
|
<DT id="11"><B>link</B><I> HANDLE</I>
|
|
|
|
<DD>
|
|
Delegate matching packets to filters in a hash table.
|
|
<I>HANDLE</I>
|
|
|
|
is used to only specify the hash table, so only
|
|
<B>htid</B> may be given, <B>hash</B> and <B>nodeid</B>
|
|
|
|
have to be omitted. By default, bucket number 0 will be used and can be
|
|
overridden by the
|
|
<B>hashkey</B>
|
|
|
|
option.
|
|
<DT id="12"><B>indev</B><I> ifname</I>
|
|
|
|
<DD>
|
|
Filter on the incoming interface of the packet. Obviously works only for
|
|
forwarded traffic.
|
|
<DT id="13"><B>skip_sw</B>
|
|
|
|
<DD>
|
|
Do not process filter by software. If hardware has no offload support for this
|
|
filter, or TC offload is not enabled for the interface, operation will fail.
|
|
<DT id="14"><B>skip_hw</B>
|
|
|
|
<DD>
|
|
Do not process filter by hardware.
|
|
<DT id="15"><B>help</B>
|
|
|
|
<DD>
|
|
Print a brief help text about possible options.
|
|
</DL>
|
|
<A NAME="lbAG"> </A>
|
|
<H2>SELECTORS</H2>
|
|
|
|
Basically the only real selector is
|
|
<B>u32 .</B>
|
|
|
|
All others merely provide a higher level syntax and are internally translated
|
|
into
|
|
<B>u32 .</B>
|
|
|
|
<DL COMPACT>
|
|
<DT id="16"><B>u32</B><I> VAL_MASK_32</I>
|
|
|
|
<DD>
|
|
|
|
<B>u16</B><I> VAL_MASK_16</I>
|
|
|
|
|
|
<B>u8</B><I> VAL_MASK_8</I>
|
|
|
|
Match packet data to a given value. The selector name defines the sample length
|
|
to extract (32bits for
|
|
<B>u32</B>,
|
|
|
|
16bits for
|
|
<B>u16</B>
|
|
|
|
and 8bits for
|
|
<B>u8</B>).
|
|
|
|
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
|
|
<I>AT</I>.
|
|
|
|
<DT id="17"><B>ip</B><I> IP</I>
|
|
|
|
<DD>
|
|
|
|
<B>ip6</B><I> IP6</I>
|
|
|
|
Assume packet starts with an IPv4 (
|
|
<B>ip</B>)
|
|
|
|
or IPv6 (
|
|
<B>ip6</B>)
|
|
|
|
header.
|
|
<I>IP</I>/<I>IP6</I>
|
|
|
|
then allows to match various header fields:
|
|
<DL COMPACT><DT id="18"><DD>
|
|
<DL COMPACT>
|
|
<DT id="19"><B>src</B><I> ADDR</I>
|
|
|
|
<DD>
|
|
|
|
<B>dst</B><I> ADDR</I>
|
|
|
|
Compare Source or Destination Address fields against the value of
|
|
<I>ADDR</I>.
|
|
|
|
The reserved words
|
|
<B>default</B>, <B>any</B> and <B>all</B>
|
|
|
|
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.
|
|
<DT id="20"><B>dsfield</B><I> VAL_MASK_8</I>
|
|
|
|
<DD>
|
|
IPv4 only. Match the packet header's DSCP/ECN field. Synonyms to this are
|
|
<B>tos</B> and <B>precedence</B>.
|
|
|
|
<DT id="21"><B>ihl</B><I> VAL_MASK_8</I>
|
|
|
|
<DD>
|
|
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
|
|
<I>u8_value</I>
|
|
|
|
has to be 6.
|
|
<DT id="22"><B>protocol</B><I> VAL_MASK_8</I>
|
|
|
|
<DD>
|
|
Match the Protocol (IPv4) or Next Header (IPv6) field value, e.g. 6 for TCP.
|
|
<DT id="23"><B>icmp_type</B><I> VAL_MASK_8</I>
|
|
|
|
<DD>
|
|
|
|
<B>icmp_code</B><I> VAL_MASK_8</I>
|
|
|
|
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.
|
|
<DT id="24"><B>sport</B><I> VAL_MASK_16</I>
|
|
|
|
<DD>
|
|
|
|
<B>dport</B><I> VAL_MASK_16</I>
|
|
|
|
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.
|
|
<DT id="25"><B>nofrag</B>
|
|
|
|
<DD>
|
|
|
|
<B>firstfrag</B>
|
|
|
|
|
|
<B>df</B>
|
|
|
|
|
|
<B>mf</B>
|
|
|
|
IPv4 only, check certain flags and fragment offset values. Match if the packet
|
|
is not a fragment
|
|
(<B>nofrag</B>),
|
|
|
|
the first fragment
|
|
(<B>firstfrag</B>),
|
|
|
|
if Don't Fragment
|
|
(<B>df</B>)
|
|
|
|
or More Fragments
|
|
(<B>mf</B>)
|
|
|
|
bits are set.
|
|
<DT id="26"><B>priority</B><I> VAL_MASK_8</I>
|
|
|
|
<DD>
|
|
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.
|
|
<DT id="27"><B>flowlabel</B><I> VAL_MASK_32</I>
|
|
|
|
<DD>
|
|
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.
|
|
</DL>
|
|
</DL>
|
|
|
|
<DT id="28"><B>tcp</B><I> TCPUDP</I>
|
|
|
|
<DD>
|
|
|
|
<B>udp</B><I> TCPUDP</I>
|
|
|
|
Match fields of next header of protocol TCP or UDP. The possible values for
|
|
<I>TCPDUP</I>
|
|
|
|
are:
|
|
<DL COMPACT><DT id="29"><DD>
|
|
<DL COMPACT>
|
|
<DT id="30"><B>src</B><I> VAL_MASK_16</I>
|
|
|
|
<DD>
|
|
Match on Source Port field value.
|
|
<DT id="31"><B>dst</B><I> VALMASK_16</I>
|
|
|
|
<DD>
|
|
Match on Destination Port field value.
|
|
</DL>
|
|
</DL>
|
|
|
|
<DT id="32"><B>icmp</B><I> ICMP</I>
|
|
|
|
<DD>
|
|
Match fields of next header of protocol ICMP. The possible values for
|
|
<I>ICMP</I>
|
|
|
|
are:
|
|
<DL COMPACT><DT id="33"><DD>
|
|
<DL COMPACT>
|
|
<DT id="34"><B>type</B><I> VAL_MASK_8</I>
|
|
|
|
<DD>
|
|
Match on ICMP Type field.
|
|
<DT id="35"><B>code</B><I> VAL_MASK_8</I>
|
|
|
|
<DD>
|
|
Match on ICMP Code field.
|
|
</DL>
|
|
</DL>
|
|
|
|
<DT id="36"><B>mark</B><I> VAL_MASK_32</I>
|
|
|
|
<DD>
|
|
Match on netfilter fwmark value.
|
|
<DT id="37"><B>ether</B><I> ETHER</I>
|
|
|
|
<DD>
|
|
Match on ethernet header fields. Possible values for
|
|
<I>ETHER</I>
|
|
|
|
are:
|
|
<DL COMPACT><DT id="38"><DD>
|
|
<DL COMPACT>
|
|
<DT id="39"><B>src</B><I> ether_address</I><B> </B><I>AT</I>
|
|
|
|
<DD>
|
|
|
|
<B>dst</B><I> ether_address</I><B> </B><I>AT</I>
|
|
|
|
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.
|
|
</DL>
|
|
</DL>
|
|
|
|
</DL>
|
|
<A NAME="lbAH"> </A>
|
|
<H2>EXAMPLES</H2>
|
|
|
|
<DL COMPACT><DT id="40"><DD>
|
|
|
|
tc filter add dev eth0 parent 999:0 prio 99 protocol ip u32 \
|
|
<BR> match ip src 192.168.8.0/24 classid 1:1
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
This attaches a filter to the qdisc identified by
|
|
<B>999:0.</B>
|
|
|
|
It's priority is
|
|
<B>99</B>,
|
|
|
|
which affects in which order multiple filters attached to the same
|
|
<B>parent</B>
|
|
|
|
are consulted (the lower the earlier). The filter handles packets of
|
|
<B>protocol</B>
|
|
|
|
type
|
|
<B>ip</B>,
|
|
|
|
and
|
|
<B>match</B>es
|
|
|
|
if the IP header's source address is within the
|
|
<B>192.168.8.0/24</B>
|
|
|
|
subnet. Matching packets are classified into class
|
|
<B>1.1</B>.
|
|
|
|
The effect of this command might be surprising at first glance:
|
|
<P>
|
|
<DL COMPACT><DT id="41"><DD>
|
|
|
|
filter parent 1: protocol ip pref 99 u32
|
|
filter parent 1: protocol ip pref 99 u32 \
|
|
<BR> fh 800: ht divisor 1
|
|
filter parent 1: protocol ip pref 99 u32 \
|
|
<BR> fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1 \
|
|
<BR> match c0a80800/ffffff00 at 12
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
So parent
|
|
<B>1:</B>
|
|
|
|
is assigned a new
|
|
<B>u32</B>
|
|
|
|
filter, which contains a hash table of size 1 (as the
|
|
<B>divisor</B>
|
|
|
|
indicates). The table ID is
|
|
<B>800</B>.
|
|
|
|
The third line then shows the actual filter which was added above: it sits in
|
|
table
|
|
<B>800</B>
|
|
|
|
and bucket
|
|
<B>0</B>,
|
|
|
|
classifies packets into class ID
|
|
<B>1:1</B>
|
|
|
|
and matches the upper three bytes of the four byte value at offset
|
|
<B>12</B>
|
|
|
|
to be
|
|
<B>0xc0a808</B>,
|
|
|
|
which is 192, 168 and 8.
|
|
<P>
|
|
Now for something more complicated, namely creating a custom hash table:
|
|
<P>
|
|
<DL COMPACT><DT id="42"><DD>
|
|
|
|
tc filter add dev eth0 prio 99 handle 1: u32 divisor 256
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
This creates a table of size 256 with handle
|
|
<B>1:</B>
|
|
|
|
in priority
|
|
<B>99</B>.
|
|
|
|
The effect is as follows:
|
|
<P>
|
|
<DL COMPACT><DT id="43"><DD>
|
|
|
|
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
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
So along with the requested hash table (handle
|
|
<B>1:</B>),
|
|
|
|
the kernel has created his own table of size 1 to hold other filters of the same
|
|
priority.
|
|
<P>
|
|
The next step is to create a filter which links to the created hash table:
|
|
<P>
|
|
<DL COMPACT><DT id="44"><DD>
|
|
|
|
tc filter add dev eth0 parent 1: prio 1 u32 \
|
|
<BR> link 1: hashkey mask 0x0000ff00 at 12 \
|
|
<BR> match ip src 192.168.0.0/16
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
The filter is given a lower priority than the hash table itself so
|
|
<B>u32</B>
|
|
|
|
consults it before manually traversing the hash table. The options
|
|
<B>link</B> and <B>hashkey</B>
|
|
|
|
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
|
|
<B>match</B>
|
|
|
|
statement, this effectively maps all class C networks below 192.168.0.0/16 to
|
|
different buckets of the hash table.
|
|
<P>
|
|
Filters for certain subnets can be created like so:
|
|
<P>
|
|
<DL COMPACT><DT id="45"><DD>
|
|
|
|
tc filter add dev eth0 parent 1: prio 99 u32 \
|
|
<BR> ht 1: sample u32 0x00000800 0x0000ff00 at 12 \
|
|
<BR> match ip src 192.168.8.0/24 classid 1:1
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
The bucket is defined using the
|
|
<B>sample</B>
|
|
|
|
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
|
|
<B>sample</B>
|
|
|
|
selects an amount of data which could exceed the
|
|
<B>divisor</B>,
|
|
|
|
one would have to know the kernel-internal algorithm to deduce the destination
|
|
bucket. This filter's
|
|
<B>match</B>
|
|
|
|
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.
|
|
<P>
|
|
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
|
|
<B>nexthdr+</B>
|
|
|
|
when giving an offset, and to make things easier there are the
|
|
<B>tcp</B> and <B>udp</B>
|
|
|
|
matches which use
|
|
<B>nexthdr+</B>
|
|
|
|
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:
|
|
<P>
|
|
<DL COMPACT><DT id="46"><DD>
|
|
|
|
tc filter add dev eth0 parent 1:0 protocol ip handle 1: \
|
|
<BR> u32 divisor 1
|
|
tc filter add dev eth0 parent 1:0 protocol ip \
|
|
<BR> u32 ht 1: \
|
|
<BR> match tcp src 22 FFFF \
|
|
<BR> classid 1:2
|
|
tc filter add dev eth0 parent 1:0 protocol ip \
|
|
<BR> u32 ht 800: \
|
|
<BR> match ip protocol 6 FF \
|
|
<BR> match ip firstfrag \
|
|
<BR> offset at 0 mask 0f00 shift 6 \
|
|
<BR> link 1:
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
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
|
|
(<B>1:</B>)
|
|
|
|
to reference to it. The second call then adds the actual filter, which pushes
|
|
packets with TCP source port 22 into class
|
|
<B>1:2</B>.
|
|
|
|
Using
|
|
<B>ht</B>,
|
|
|
|
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
|
|
<B>link</B>,
|
|
|
|
the hash table from first call is referenced which holds the filter from second
|
|
call.
|
|
<A NAME="lbAI"> </A>
|
|
<H2>SEE ALSO</H2>
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?8+tc">tc</A></B>(8),
|
|
|
|
<BR>
|
|
|
|
<B>cls_u32.txt</B> at <B><A HREF="http://linux-tc-notes.sourceforge.net/">http://linux-tc-notes.sourceforge.net/</A></B>
|
|
|
|
<P>
|
|
|
|
<HR>
|
|
<A NAME="index"> </A><H2>Index</H2>
|
|
<DL>
|
|
<DT id="47"><A HREF="#lbAB">NAME</A><DD>
|
|
<DT id="48"><A HREF="#lbAC">SYNOPSIS</A><DD>
|
|
<DT id="49"><A HREF="#lbAD">DESCRIPTION</A><DD>
|
|
<DT id="50"><A HREF="#lbAE">VALUES</A><DD>
|
|
<DT id="51"><A HREF="#lbAF">OPTIONS</A><DD>
|
|
<DT id="52"><A HREF="#lbAG">SELECTORS</A><DD>
|
|
<DT id="53"><A HREF="#lbAH">EXAMPLES</A><DD>
|
|
<DT id="54"><A HREF="#lbAI">SEE ALSO</A><DD>
|
|
</DL>
|
|
<HR>
|
|
This document was created by
|
|
<A HREF="/cgi-bin/man/man2html">man2html</A>,
|
|
using the manual pages.<BR>
|
|
Time: 00:06:18 GMT, March 31, 2021
|
|
</BODY>
|
|
</HTML>
|