tc-gate

title: tc-gate(8)

summary: Stream Gate Action

text:
# tc-gate(8)

## NAME
gate - Stream Gate Action

## SYNOPSIS
tc ... action gate [ base-time BASETIME ] [ clockid CLOCKID ] sched-entry <gate state> <interval 1> [ <internal priority> <max octets> ] sched-entry <gate state> <interval 2> [ <internal priority> <max octets> ] sched-entry <gate state> <interval 3> [ <internal priority> <max octets> ] ...... sched-entry <gate state> <interval N> [ <internal priority> <max octets> ]

## DESCRIPTION
GATE action allows specified ingress frames can be passed at specific time slot, or be dropped at specific time slot. Tc filter filters the ingress frames, then tc gate action would specify which time slot and how many bytes these frames can be passed to device and which time slot frames would be dropped. Gate action also assign a base-time to tell when the entry list start. Then gate action would start to repeat the gate entry list cyclically at the start base-time. For the software simulation, gate action requires the user assign reference time clock type.

## PARAMETERS
base-time

Specifies the instant in nanoseconds, defining the time when the schedule starts. If 'base-time' is a time in the past, the schedule will start at base-time + (N * cycle-time)

where N is the smallest integer so the resulting time is greater than "now", and "cycle-time" is the sum of all the intervals of the entries in the schedule. Without base-time specified, will default to be 0.

clockid

Specifies the clock to be used by qdisc's internal timer for measuring time and scheduling events. Not valid if gate action is used for offloading filter. For example, tc filter command with skip_sw parameter.

sched-entry

There may multiple sched-entry parameters in a single schedule. Each one has the format: sched-entry <gate state> <interval> [ <internal priority> <max octets> ]

<gate state> means gate states. 'open' keep gate open, 'close' keep gate close.

<interval> means how much nano seconds for this time slot.

<internal priority> means internal priority value. Present of the internal receiving queue for this stream. "-1" means wildcard. <internal priority> and <max octets> can be omit default to be "-1" which both

value to be "-1" for this <sched-entry>.

<max octets> means how many octets size could pass in this time slot. Dropped if overlimited. "-1" means wildcard. <max octets> can be omit default to be "-1" which value to be "-1" for this <sched-entry>.

Note that <internal priority> and <max octets> are nothing meaning for gate state is "close" in a "sched-entry". All frames are dropped when "sched-entry" with "close" state.

## EXAMPLES
The following example shows tc filter frames source ip match to the 192.168.0.20 will keep the gate open for 200ms and limit the traffic to 8MB in this sched-entry. Then keep the traffic gate to be close for 100ms. Frames arrived at gate close state would be dropped. Then the cycle would run the gate entries periodically. The schedule will start at instant 200.0s using the reference CLOCK_TAI. The schedule is composed of two entries each of 300ms duration.

```
# tc qdisc add dev eth0 ingress
# tc filter add dev eth0 parent ffff: protocol ip \

           flower skip_hw src_ip 192.168.0.20 \

           action gate index 2 clockid CLOCK_TAI \

           base-time 200000000000ns \

           sched-entry open 200000000ns -1 8000000b \

           sched-entry close 100000000ns
```

Following commands is an example to filter a stream source mac match to the 10:00:80:00:00:00 icmp frames will be dropped at any time with cycle 200ms. With a default basetime 0 and clockid is CLOCK_TAI as default.

```
# tc qdisc add dev eth0 ingress
# tc filter add dev eth0 parent ffff:  protocol ip \
	flower ip_proto icmp dst_mac 10:00:80:00:00:00 \
	action gate index 12 sched-entry close 200000000ns
```

## AUTHORS
Po Liu <Po.Liu@nxp.com>


tc-hfsc

title: tc-hfsc(8)

text:
# tc-hfsc(8)

## NAME
HFSC - Hierarchical Fair Service Curve's control under linux

## SYNOPSIS

```
tc qdisc add ... hfsc [ default CLASSID ]
tc class add ... hfsc [ [ rt SC ] [ ls SC ] | [ sc SC ] ] [ ul SC ]
rt : realtime service curve
ls : linkshare service curve
sc : rt+ls service curve
ul : upperlimit service curve
• at least one of rt, ls or sc must be specified
• ul can only be specified with ls or sc
```

SC := [ [ m1 BPS ] d SEC ] m2 BPS

```
m1 : slope of the first segment
d  : x-coordinate of intersection
m2 : slope of the second segment
```

SC := [ [ umax BYTE ] dmax SEC ] rate BPS

```
umax : maximum unit of work
dmax : maximum delay
rate : rate
```

```

```

For description of BYTE, BPS and SEC - please see UNITS section of tc(8).

## DESCRIPTION (qdisc)
HFSC qdisc has only one optional parameter - default. CLASSID specifies the minor part of the default classid, where packets not classified by other means (e.g. u32 filter, CLASSIFY target of iptables) will be enqueued. If default is not specified, unclassified packets will be dropped.

## DESCRIPTION (class)
HFSC class is used to create a class hierarchy for HFSC scheduler. For explanation of the algorithm, and the meaning behind rt, ls, sc and ul service curves - please refer to tc-hfsc(7).

As you can see in SYNOPSIS, service curve (SC) can be specified in two ways. Either as maximum delay for certain amount of work, or as a bandwidth assigned for certain amount of time. Obviously, m1 is simply umax/dmax.

Both m2 and rate are mandatory. If you omit other parameters, you will specify linear service curve.

## SEE ALSO
tc(8), tc-hfsc(7), tc-stab(8)

Please direct bugreports and patches to: <netdev@vger.kernel.org>

## AUTHOR
Manpage created by Michal Soltys (soltys@ziu.info)


tc-htb

title: tc-htb(8)

summary: Hierarchy Token Bucket

text:
# tc-htb(8)

## NAME
HTB - Hierarchy Token Bucket

## SYNOPSIS
tc qdisc ... dev dev ( parent classid | root) [ handle major: ] htb [ default minor-id ] [ r2q divisor ] [ offload ]

tc class ... dev dev parent major:[minor] [ classid major:minor ] htb rate rate [ ceil rate ] burst bytes [ cburst bytes ] [ prio priority ] [ quantum bytes ]

## DESCRIPTION
HTB is meant as a more understandable and intuitive replacement for the CBQ qdisc in Linux. Both CBQ and HTB help you to control the use of the outbound bandwidth on a given link. Both allow you to use one physical link to simulate several slower links and to send different kinds of traffic on different simulated links. In both cases, you have to specify how to divide the physical link into simulated links and how to decide which simulated link to use for a given packet to be sent.

Unlike CBQ, HTB shapes traffic based on the Token Bucket Filter algorithm which does not depend on interface characteristics and so does not need to know the underlying bandwidth of the outgoing interface.

## SHAPING ALGORITHM
Shaping works as documented in tc-tbf (8).

## CLASSIFICATION
Within the one HTB instance many classes may exist. Each of these classes contains another qdisc, by default tc-pfifo(8).

When enqueueing a packet, HTB starts at the root and uses various methods to determine which class should receive the data.

In the absence of uncommon configuration options, the process is rather easy. At each node we look for an instruction, and then go to the class the instruction refers us to. If the class found is a barren leaf-node (without children), we enqueue the packet there. If it is not yet a leaf node, we do the whole thing over again starting from that node.

The following actions are performed, in order at each node we visit, until one sends us to another node, or terminates the process.

(i)

Consult filters attached to the class. If sent to a leafnode, we are done. Otherwise, restart.

(ii)

If none of the above returned with an instruction, enqueue at this node.

This algorithm makes sure that a packet always ends up somewhere, even while you are busy building your configuration.

## LINK SHARING ALGORITHM
FIXME

## QDISC
The root of a HTB qdisc class tree has the following parameters:

parent major:minor | root

This mandatory parameter determines the place of the HTB instance, either at the root of an interface or within an existing class.

handle major:

Like all other qdiscs, the HTB can be assigned a handle. Should consist only of a major number, followed by a colon. Optional, but very useful if classes will be generated within this qdisc.

default minor-id

Unclassified traffic gets sent to the class with this minor-id.

r2q divisor

Divisor used to calculate quantum values for classes. Classes divide rate by this number. Default value is 10.

offload

Offload the HTB algorithm to hardware (requires driver and device support).

## CLASSES
Classes have a host of parameters to configure their operation.

parent major:minor

Place of this class within the hierarchy. If attached directly to a qdisc and not to another class, minor can be omitted. Mandatory.

classid major:minor

Like qdiscs, classes can be named. The major number must be equal to the major number of the qdisc to which it belongs. Optional, but needed if this class is going to have children.

prio priority

In the round-robin process, classes with the lowest priority field are tried for packets first.

rate rate

Maximum rate this class and all its children are guaranteed. Mandatory.

ceil rate

Maximum rate at which a class can send, if its parent has bandwidth to spare. Defaults to the configured rate, which implies no borrowing

burst bytes

Amount of bytes that can be burst at ceil speed, in excess of the configured rate. Should be at least as high as the highest burst of all children.

cburst bytes

Amount of bytes that can be burst at 'infinite' speed, in other words, as fast as the interface can transmit them. For perfect evening out, should be equal to at most one average packet. Should be at least as high as the highest cburst of all children.

quantum bytes

Number of bytes to serve from this class before the scheduler moves to the next class. Default value is rate divided by the qdisc r2q parameter. If specified, r2q is ignored.

## NOTES
Due to Unix timing constraints, the maximum ceil rate is not infinite and may in fact be quite low. On Intel, there are 100 timer events per second, the maximum rate is that rate at which 'burst' bytes are sent each timer tick. From this, the minimum burst size for a specified rate can be calculated. For i386, a 10mbit rate requires a 12 kilobyte burst as 100*12kb*8 equals 10mbit.

## SEE ALSO
tc(8)

HTB website: http://luxik.cdi.cz/~devik/qos/htb/

## AUTHOR
Martin Devera <devik@cdi.cz>. This manpage maintained by bert hubert <ahu@ds9a.nl>


tc-ife

title: tc-ife(8)

text:
# tc-ife(8)

## NAME
IFE - encapsulate/decapsulate metadata

## SYNOPSIS

tc ... action ife DIRECTION [ ACTION ] [ dst DMAC ] [ src SMAC ] [ type TYPE ] [ CONTROL ] [ index INDEX ]

DIRECTION := { decode | encode }

ACTION := { allow ATTR | use ATTR value }

ATTR := { mark | prio | tcindex }

CONTROL := { reclassify | use | pipe | drop | continue | ok | goto chain CHAIN_INDEX }

## DESCRIPTION
The ife action allows for a sending side to encapsulate arbitrary metadata, which is then decapsulated by the receiving end. The sender runs in encoding mode and the receiver in decode mode. Both sender and receiver must specify the same ethertype. In the future, a registered ethertype may be available as a default.

## OPTIONS
decode

For the receiving side; decode the metadata if the packet matches.

encode

For the sending side. Encode the specified metadata if the packet matches.

allow

Encode direction only. Allows encoding specified metadata.

use

Encode direction only. Enforce static encoding of specified metadata.

mark [

u32_value ] The value to set for the skb mark. The u32 value is required only when use is specified. If mark value is zero, it will not be encoded, instead "overlimits" statistics increment and CONTROL action is taken.

prio [

u32_value ] The value to set for priority in the skb structure. The u32 value is required only when use is specified.

tcindex [

u16_value ] Value to set for the traffic control index in the skb structure. The u16 value is required only when use is specified.

dmac DMAC

smac SMAC

Optional six byte destination or source MAC address to encode.

type TYPE

Optional 16-bit ethertype to encode. If not specified value of 0xED3E will be used.

CONTROL

Action to take following an encode/decode.

index INDEX

Assign a unique ID to this action instead of letting the kernel choose one automatically. INDEX is a 32bit unsigned integer greater than zero.

## EXAMPLES
On the receiving side, match packets with ethertype 0xdead and restart classification so that it will match ICMP on the next rule, at prio 3:

```
# tc qdisc add dev eth0 handle ffff: ingress
# tc filter add dev eth0 parent ffff: prio 2 protocol 0xdead \
	u32 match u32 0 0 flowid 1:1 \
	action ife decode reclassify
# tc filter add dev eth0 parent ffff: prio 3 protocol ip \
	u32 match ip protocol 0xff flowid 1:1 \
	action continue
```

Match with skb mark of 17:

```
# tc filter add dev eth0 parent ffff: prio 4 protocol ip \
	handle 0x11 fw flowid 1:1 \
	action ok
```

Configure the sending side to encode for the filters above. Use a destination IP address of 192.168.122.237/24, then tag with skb mark of decimal 17. Encode the packaet with ethertype 0xdead, add skb->mark to whitelist of metadatum to send, and rewrite the destination MAC address to 02:15:15:15:15:15.

```
# tc qdisc add dev eth0 root handle 1: prio
# tc filter add dev eth0 parent 1: protocol ip prio 10 u32 \
	match ip dst 192.168.122.237/24 \
	match ip protocol 1 0xff \
	flowid 1:2 \
	action skbedit mark 17 \
	action ife encode \
	type 0xDEAD \
	allow mark \
	dst 02:15:15:15:15:15
```

## SEE ALSO
tc(8), tc-u32(8)


tc-matchall

title: tc-matchall(8)

text:
# tc-matchall(8)

## NAME
matchall - traffic control filter that matches every packet

## SYNOPSIS

tc filter ... matchall [ skip_sw | skip_hw ] [ action ACTION_SPEC ] [ classid CLASSID ]

## DESCRIPTION
The matchall filter allows to classify every packet that flows on the port and run a action on it.

## OPTIONS
action ACTION_SPEC

Apply an action from the generic actions framework on matching packets.

classid CLASSID

Push matching packets into the class identified by CLASSID.

skip_sw

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.

skip_hw

Do not process filter by hardware.

## EXAMPLES
To create ingress mirroring from port eth1 to port eth2:

```
tc qdisc  add dev eth1 handle ffff: ingress
tc filter add dev eth1 parent ffff:           \

        matchall skip_sw                      \

        action mirred egress mirror           \

        dev eth2
```

The first command creates an ingress qdisc with handle ffff: on device eth1 where the second command attaches a matchall filters on it that mirrors the packets to device eth2.

To create egress mirroring from port eth1 to port eth2:

```
tc qdisc add dev eth1 handle 1: root prio
tc filter add dev eth1 parent 1:               \

        matchall skip_sw                       \

        action mirred egress mirror            \

        dev eth2
```

The first command creates an egress qdisc with handle 1: that replaces the root qdisc on device eth1 where the second command attaches a matchall filters on it that mirrors the packets to device eth2.

To sample one of every 100 packets flowing into interface eth0 to psample group 12:

```
tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev eth0 parent ffff: matchall \

     action sample rate 100 group 12
```

## SEE ALSO
tc(8),


tc-mirred

title: tc-mirred(8)

text:
# tc-mirred(8)

## NAME
mirred - mirror/redirect action

## SYNOPSIS

tc ... action mirred DIRECTION ACTION [ index INDEX ] dev DEVICENAME

DIRECTION := { ingress | egress }

ACTION := { mirror | redirect }

## DESCRIPTION
The mirred action allows packet mirroring (copying) or redirecting (stealing) the packet it receives. Mirroring is what is sometimes referred to as Switch Port Analyzer (SPAN) and is commonly used to analyze and/or debug flows.

## OPTIONS
ingress

egress

Specify the direction in which the packet shall appear on the destination interface.

mirror

redirect

Define whether the packet should be copied (mirror) or moved (redirect) to the destination interface.

index INDEX

Assign a unique ID to this action instead of letting the kernel choose one automatically. INDEX is a 32bit unsigned integer greater than zero.

dev DEVICENAME

Specify the network interface to redirect or mirror to.

## EXAMPLES
Limit ingress bandwidth on eth0 to 1mbit/s, redirect exceeding traffic to lo for debugging purposes:

```
# tc qdisc add dev eth0 handle ffff: ingress
# tc filter add dev eth0 parent ffff: u32 \
	match u32 0 0 \
	action police rate 1mbit burst 100k conform-exceed pipe \
	action mirred egress redirect dev lo
```

Mirror all incoming ICMP packets on eth0 to a dummy interface for examination with e.g. tcpdump:

```
# ip link add dummy0 type dummy
# ip link set dummy0 up
# tc qdisc add dev eth0 handle ffff: ingress
# tc filter add dev eth0 parent ffff: protocol ip \
	u32 match ip protocol 1 0xff \
	action mirred egress mirror dev dummy0
```

Using an ifb interface, it is possible to send ingress traffic through an instance of sfq:

```
# modprobe ifb
# ip link set ifb0 up
# tc qdisc add dev ifb0 root sfq
# tc qdisc add dev eth0 handle ffff: ingress
# tc filter add dev eth0 parent ffff: u32 \
	match u32 0 0 \
	action mirred egress redirect dev ifb0
```

## SEE ALSO
tc(8), tc-u32(8)


tc-mpls

title: tc-mpls(8)

text:
# tc-mpls(8)

## NAME
mpls - mpls manipulation module

## SYNOPSIS

tc ... action mpls { POP | PUSH | MODIFY | dec_ttl } [ CONTROL ]

POP := pop protocol MPLS_PROTO

PUSH := { push | mac_push } [ protocol MPLS_PROTO ] [ tc MPLS_TC ] [ ttl MPLS_TTL ] [ bos MPLS_BOS ] label MPLS_LABEL

MODIFY := modify [ label MPLS_LABEL ] [ tc MPLS_TC ] [ ttl MPLS_TTL ]

CONTROL := { reclassify | pipe | drop | continue | pass | goto chain CHAIN_INDEX }

## DESCRIPTION
The mpls action performs mpls encapsulation or decapsulation on a packet, reflected by the operation modes POP, PUSH, MODIFY and DEC_TTL. The POP mode requires the ethertype of the header that follows the MPLS header (e.g. IPv4 or another MPLS). It will remove the outer MPLS header and replace the ethertype in the MAC header with that passed. The PUSH and MODIFY modes update the current MPLS header information or add a new header. PUSH requires at least an MPLS_LABEL. DEC_TTL requires no arguments and simply subtracts 1 from the MPLS header TTL field.

## OPTIONS
pop

Decapsulation mode. Requires the protocol of the next header.

push

Encapsulation mode. Adds the MPLS header between the MAC and the network headers. Requires at least the label option.

mac_push

Encapsulation mode. Adds the MPLS header before the MAC header. Requires at least the label option.

modify

Replace mode. Existing MPLS tag is replaced. label, tc, and ttl are all optional.

dec_ttl

Decrement the TTL field on the outer most MPLS header.

label MPLS_LABEL

Specify the MPLS LABEL for the outer MPLS header. MPLS_LABEL is an unsigned 20bit integer, the format is detected automatically (e.g. prefix with '0x' for hexadecimal interpretation, etc.).

protocol MPLS_PROTO

Choose the protocol to use. For push actions this must be mpls_uc or mpls_mc (mpls_uc is the default). For pop actions it should be the protocol of the next header. This option cannot be used with modify.

tc MPLS_TC

Choose the TC value for the outer MPLS header. Decimal number in range of 0-7. Defaults to 0.

ttl MPLS_TTL

Choose the TTL value for the outer MPLS header. Number in range of 0-255. A non-zero default value will be selected if this is not explicitly set.

bos MPLS_BOS

Manually configure the bottom of stack bit for an MPLS header push. The default is for TC to automatically set (or unset) the bit based on the next header of the packet.

CONTROL

How to continue after executing this action.

reclassify

Restarts classification by jumping back to the first filter attached to this action's parent.

pipe

Continue with the next action, this is the default.

drop

Packet will be dropped without running further actions.

continue

Continue classification with next filter in line.

pass

Return to calling qdisc for packet processing. This ends the classification process.

## EXAMPLES
The following example encapsulates incoming IP packets on eth0 into MPLS with a label 123 and sends them out eth1:

```
#tc qdisc add dev eth0 handle ffff: ingress
#tc filter add dev eth0 protocol ip parent ffff: flower \
	action mpls push protocol mpls_uc label 123  \
	action mirred egress redirect dev eth1
```

In this example, incoming MPLS unicast packets on eth0 are decapsulated and redirected to eth1:

```
#tc qdisc add dev eth0 handle ffff: ingress
#tc filter add dev eth0 protocol mpls_uc parent ffff: flower \
	action mpls pop protocol ipv4  \
	action mirred egress redirect dev eth1
```

Here is another example, where incoming Ethernet frames are encapsulated into MPLS with label 123 and TTL 64. Then, an outer Ethernet header is added and the resulting frame is finally sent on eth1:

```
#tc qdisc add dev eth0 ingress
#tc filter add dev eth0 ingress matchall \
	action mpls mac_push label 123 ttl 64 \
	action vlan push_eth \
		dst_mac 02:00:00:00:00:02 \
		src_mac 02:00:00:00:00:01 \
	action mirred egress redirect dev eth1
```

The following example assumes that incoming MPLS packets with label 123 transport Ethernet frames. The outer Ethernet and the MPLS headers are stripped, then the inner Ethernet frame is sent on eth1:

```
#tc qdisc add dev eth0 ingress
#tc filter add dev eth0 ingress protocol mpls_uc \
	flower mpls_label 123 mpls_bos 1 \
	action vlan pop_eth \
	action mpls pop protocol teb \
	action mirred egress redirect dev eth1
```

## SEE ALSO
tc(8), tc-mirred(8), tc-vlan(8)


tc-mqprio

title: tc-mqprio(8)

text:
# tc-mqprio(8)

## NAME
MQPRIO - Multiqueue Priority Qdisc (Offloaded Hardware QOS)

## SYNOPSIS
tc qdisc ... dev dev ( parent classid | root) [ handle major: ] mqprio [ num_tc tcs ] [ map P0 P1 P2... ] [ queues count1@offset1 count2@offset2 ... ] [ hw 1|0 ] [ mode dcb|channel] ] [ shaper dcb| [ bw_rlimit min_rate min_rate1 min_rate2 ... max_rate max_rate1 max_rate2 ... ]]

## DESCRIPTION
The MQPRIO qdisc is a simple queuing discipline that allows mapping traffic flows to hardware queue ranges using priorities and a configurable priority to traffic class mapping. A traffic class in this context is a set of contiguous qdisc classes which map 1:1 to a set of hardware exposed queues.

By default the qdisc allocates a pfifo qdisc (packet limited first in, first out queue) per TX queue exposed by the lower layer device. Other queuing disciplines may be added subsequently. Packets are enqueued using the map parameter and hashed across the indicated queues in the offset and count. By default these parameters are configured by the hardware driver to match the hardware QOS structures.

Channel mode supports full offload of the mqprio options, the traffic classes, the queue configurations and QOS attributes to the hardware. Enabled hardware can provide hardware QOS with the ability to steer traffic flows to designated traffic classes provided by this qdisc. Hardware based QOS is configured using the shaper parameter. bw_rlimit with minimum and maximum bandwidth rates can be used for setting transmission rates on each traffic class. Also further qdiscs may be added to the classes of MQPRIO to create more complex configurations.

## ALGORITHM
On creation with 'tc qdisc add', eight traffic classes are created mapping priorities 0..7 to traffic classes 0..7 and priorities greater than 7 to traffic class 0. This requires base driver support and the creation will fail on devices that do not support hardware QOS schemes.

These defaults can be overridden using the qdisc parameters. Providing the 'hw 0' flag allows software to run without hardware coordination.

If hardware coordination is being used and arguments are provided that the hardware can not support then an error is returned. For many users hardware defaults should work reasonably well.

As one specific example numerous Ethernet cards support the 802.1Q link strict priority transmission selection algorithm (TSA). MQPRIO enabled hardware in conjunction with the classification methods below can provide hardware offloaded support for this TSA.

## CLASSIFICATION
Multiple methods are available to set the SKB priority which MQPRIO uses to select which traffic class to enqueue the packet.

From user space

A process with sufficient privileges can encode the destination class directly with SO_PRIORITY, see socket(7).

with iptables/nftables

An iptables/nftables rule can be created to match traffic flows and set the priority. iptables(8)

with net_prio cgroups

The net_prio cgroup can be used to set the priority of all sockets belong to an application. See kernel and cgroup documentation for details.

## QDISC PARAMETERS
num_tc

Number of traffic classes to use. Up to 16 classes supported.

map

The priority to traffic class map. Maps priorities 0..15 to a specified traffic class.

queues

Provide count and offset of queue range for each traffic class. In the format, count@offset. Queue ranges for each traffic classes cannot overlap and must be a contiguous range of queues.

hw

Set to 1 to support hardware offload. Set to 0 to configure user specified values in software only.

mode

Set to channel for full use of the mqprio options. Use dcb to offload only TC values and use hardware QOS defaults. Supported with 'hw' set to 1 only.

shaper

Use bw_rlimit to set bandwidth rate limits for a traffic class. Use dcb for hardware QOS defaults. Supported with 'hw' set to 1 only.

min_rate

Minimum value of bandwidth rate limit for a traffic class.

max_rate

Maximum value of bandwidth rate limit for a traffic class.

## AUTHORS
John Fastabend, <john.r.fastabend@intel.com>


tc-nat

title: tc-nat(8)

text:
# tc-nat(8)

## NAME
nat - stateless native address translation action

## SYNOPSIS

tc ... action nat DIRECTION OLD NEW

DIRECTION := { ingress | egress }

OLD := IPV4_ADDR_SPEC

NEW := IPV4_ADDR_SPEC

IPV4_ADDR_SPEC := { default | any | all | in_addr[/{prefix|netmask}]

## DESCRIPTION
The nat action allows to perform NAT without the overhead of conntrack, which is desirable if the number of flows or addresses to perform NAT on is large. This action is best used in combination with the u32 filter to allow for efficient lookups of a large number of stateless NAT rules in constant time.

## OPTIONS
ingress

Translate destination addresses, i.e. perform DNAT.

egress

Translate source addresses, i.e. perform SNAT.

OLD

Specifies addresses which should be translated.

NEW

Specifies addresses which OLD should be translated into.

## NOTES
The accepted address format in OLD and NEW is quite flexible. It may either consist of one of the keywords default, any or all, representing the all-zero IP address or a combination of IP address and netmask or prefix length separated by a slash (/) sign. In any case, the mask (or prefix length) value of OLD is used for NEW as well so that a one-to-one mapping of addresses is assured.

Address translation is done using a combination of binary operations. First, the original (source or destination) address is matched against the value of OLD. If the original address fits, the new address is created by taking the leading bits from NEW (defined by the netmask of OLD) and taking the remaining bits from the original address.

There is rudimental support for upper layer protocols, namely TCP, UDP and ICMP. While for the first two only checksum recalculation is performed, the action also takes care of embedded IP headers in ICMP packets by translating the respective address therein, too.

## SEE ALSO
tc(8)


tc-netem

title: tc-netem(8)

summary: Network Emulator

text:
# tc-netem(8)

## NAME
NetEm - Network Emulator

## SYNOPSIS
tc qdisc ... dev DEVICE ] add netem OPTIONS

OPTIONS := [ LIMIT ] [ DELAY ] [ LOSS ] [ CORRUPT ] [ DUPLICATION ] [ REORDERING ] [ RATE ] [ SLOT ]

LIMIT := limit packets

DELAY := delay TIME [ JITTER [ CORRELATION ]]]

[ distribution { uniform | normal | pareto | paretonormal } ]

LOSS := loss { random PERCENT [ CORRELATION ] |

state p13 [ p31 [ p32 [ p23 [ p14]]]] |

gemodel p [ r [ 1-h [ 1-k ]]] } [ ecn ]

CORRUPT := corrupt PERCENT [ CORRELATION ]]

DUPLICATION := duplicate PERCENT [ CORRELATION ]]

REORDERING := reorder PERCENT [ CORRELATION ] [ gap DISTANCE ]

RATE := rate RATE [ PACKETOVERHEAD [ CELLSIZE [ CELLOVERHEAD ]]]]

SLOT := slot { MIN_DELAY [ MAX_DELAY ] |

distribution { uniform | normal | pareto | paretonormal | FILE } DELAY JITTER }

[ packets PACKETS ] [ bytes BYTES ]

## DESCRIPTION
NetEm is an enhancement of the Linux traffic control facilities that allow to add delay, packet loss, duplication and more other characteristics to packets outgoing from a selected network interface. NetEm is built using the existing Quality Of Service (QOS) and Differentiated Services (diffserv) facilities in the Linux kernel.

## netem OPTIONS
netem has the following options:

### limit packets
maximum number of packets the qdisc may hold queued at a time.

### delay
adds the chosen delay to the packets outgoing to chosen network interface. The optional parameters allows to introduce a delay variation and a correlation. Delay and jitter values are expressed in ms while correlation is percentage.

### distribution
allow the user to choose the delay distribution. If not specified, the default distribution is Normal. Additional parameters allow to consider situations in which network has variable delays depending on traffic flows concurring on the same path, that causes several delay peaks and a tail.

### loss random
adds an independent loss probability to the packets outgoing from the chosen network interface. It is also possible to add a correlation, but this option is now deprecated due to the noticed bad behavior.

### loss state
adds packet losses according to the 4-state Markov using the transition probabilities as input parameters. The parameter p13 is mandatory and if used alone corresponds to the Bernoulli model. The optional parameters allows to extend the model to 2-state (p31), 3-state (p23 and p32) and 4-state (p14). State 1 corresponds to good reception, State 4 to independent losses, State 3 to burst losses and State 2 to good reception within a burst.

### loss gemodel
adds packet losses according to the Gilbert-Elliot loss model or its special cases (Gilbert, Simple Gilbert and Bernoulli). To use the Bernoulli model, the only needed parameter is p while the others will be set to the default values r=1-p, 1-h=1 and 1-k=0. The parameters needed for the Simple Gilbert model are two (p and r), while three parameters (p, r, 1-h) are needed for the Gilbert model and four (p, r, 1-h and 1-k) are needed for the Gilbert-Elliot model. As known, p and r are the transition probabilities between the bad and the good states, 1-h is the loss probability in the bad state and 1-k is the loss probability in the good state.

### ecn
can be used optionally to mark packets instead of dropping them. A loss model has to be used for this to be enabled.

### corrupt
allows the emulation of random noise introducing an error in a random position for a chosen percent of packets. It is also possible to add a correlation through the proper parameter.

### duplicate
using this option the chosen percent of packets is duplicated before queuing them. It is also possible to add a correlation through the proper parameter.

### reorder
to use reordering, a delay option must be specified. There are two ways to use this option (assuming 'delay 10ms' in the options list).

reorder 25% 50% gap 5

in this first example, the first 4 (gap - 1) packets are delayed by 10ms and subsequent packets are sent immediately with a probability of 0.25 (with correlation of 50% ) or delayed with a probability of 0.75. After a packet is reordered, the process restarts i.e. the next 4 packets are delayed and subsequent packets are sent immediately or delayed based on reordering probability. To cause a repeatable pattern where every 5th packet is reordered reliably, a reorder probability of 100% can be used.

reorder 25% 50%

in this second example 25% of packets are sent immediately (with correlation of 50%) while the others are delayed by 10 ms.

### rate
delay packets based on packet size and is a replacement for TBF. Rate can be specified in common units (e.g. 100kbit). Optional PACKETOVERHEAD (in bytes) specify an per packet overhead and can be negative. A positive value can be used to simulate additional link layer headers. A negative value can be used to artificial strip the Ethernet header (e.g. -14) and/or simulate a link layer header compression scheme. The third parameter - an unsigned value - specify the cellsize. Cellsize can be used to simulate link layer schemes. ATM for example has an payload cellsize of 48 bytes and 5 byte per cell header. If a packet is 50 byte then ATM must use two cells: 2 * 48 bytes payload including 2 * 5 byte header, thus consume 106 byte on the wire. The last optional value CELLOVERHEAD can be used to specify per cell overhead - for our ATM example 5. CELLOVERHEAD can be negative, but use negative values with caution.

Note that rate throttling is limited by several factors: the kernel clock granularity avoid a perfect shaping at a specific level. This will show up in an artificial packet compression (bursts). Another influence factor are network adapter buffers which can also add artificial delay.

### slot
defer delivering accumulated packets to within a slot. Each available slot can be configured with a minimum delay to acquire, and an optional maximum delay. Alternatively it can be configured with the distribution similar to distribution for delay option. Slot delays can be specified in nanoseconds, microseconds, milliseconds or seconds (e.g. 800us). Values for the optional parameters BYTES will limit the number of bytes delivered per slot, and/or PACKETS will limit the number of packets delivered per slot.

These slot options can provide a crude approximation of bursty MACs such as DOCSIS, WiFi, and LTE.

Note that slotting is limited by several factors: the kernel clock granularity, as with a rate, and attempts to deliver many packets within a slot will be smeared by the timer resolution, and by the underlying native bandwidth also.

It is possible to combine slotting with a rate, in which case complex behaviors where either the rate, or the slot limits on bytes or packets per slot, govern the actual delivered rate.

## LIMITATIONS
The main known limitation of Netem are related to timer granularity, since Linux is not a real-time operating system.

## EXAMPLES
tc qdisc add dev eth0 root netem rate 5kbit 20 100 5

delay all outgoing packets on device eth0 with a rate of 5kbit, a per packet overhead of 20 byte, a cellsize of 100 byte and a per celloverhead of 5 byte:

## SOURCES
1.

Hemminger S. , "Network Emulation with NetEm", Open Source Development Lab, April 2005 (http://devresources.linux-foundation.org/shemminger/netem/LCA2005_paper.pdf)

2.

Netem page from Linux foundation, (https://wiki.linuxfoundation.org/networking/netem)

3.

Salsano S., Ludovici F., Ordine A., "Definition of a general and intuitive loss model for packet networks and its implementation in the Netem module in the Linux kernel", available at http://netgroup.uniroma2.it/NetemCLG

## SEE ALSO
tc(8), tc-tbf(8)

## AUTHOR
Netem was written by Stephen Hemminger at Linux foundation and is based on NISTnet. This manpage was created by Fabio Ludovici <fabio.ludovici at yahoo dot it> and Hagen Paul Pfeifer <hagen@jauu.net>


tc-pedit

title: tc-pedit(8)

text:
# tc-pedit(8)

## NAME
pedit - generic packet editor action

## SYNOPSIS

tc ... action pedit [ex] munge { RAW_OP | LAYERED_OP | EXTENDED_LAYERED_OP } [ CONTROL ]

RAW_OP := offset OFFSET { u8 | u16 | u32 } [ AT_SPEC ] CMD_SPEC

AT_SPEC := at AT offmask MASK shift SHIFT

LAYERED_OP := { ip IPHDR_FIELD | ip BEYOND_IPHDR_FIELD } CMD_SPEC

EXTENDED_LAYERED_OP := { eth ETHHDR_FIELD | ip IPHDR_FIELD | ip EX_IPHDR_FIELD | ip6 IP6HDR_FIELD | tcp TCPHDR_FIELD | udp UDPHDR_FIELD } CMD_SPEC

ETHHDR_FIELD := { src | dst | type }

IPHDR_FIELD := { src | dst | tos | dsfield | ihl | protocol | precedence | nofrag | firstfrag | ce | df }

BEYOND_IPHDR_FIELD := { dport | sport | icmp_type | icmp_code }

EX_IPHDR_FIELD := { ttl }

IP6HDR_FIELD := { src | dst | traffic_class | flow_lbl | payload_len | nexthdr | hoplimit }

TCPHDR_FIELD := { sport | dport | flags }

UDPHDR_FIELD := { sport | dport }

CMD_SPEC := { clear | invert | set VAL | add VAL | preserve } [ retain RVAL ]

CONTROL := { reclassify | pipe | drop | shot | continue | pass | goto chain CHAIN_INDEX }

## DESCRIPTION
The pedit action can be used to change arbitrary packet data. The location of data to change can either be specified by giving an offset and size as in RAW_OP, or for header values by naming the header and field to edit the size is then chosen automatically based on the header field size.

## OPTIONS
ex

Use extended pedit. EXTENDED_LAYERED_OP and the add CMD_SPEC are allowed only in this mode.

offset OFFSET { u32 | u16 | u8 }

Specify the offset at which to change data. OFFSET is a signed integer, it's base is automatically chosen (e.g. hex if prefixed by 0x or octal if prefixed by 0). The second argument specifies the length of data to change, that is four bytes (u32), two bytes (u16) or a single byte (u8).

at AT offmask MASK shift SHIFT

This is an optional part of RAW_OP which allows to have a variable OFFSET depending on packet data at offset AT, which is binary ANDed with MASK and right-shifted by SHIFT before adding it to OFFSET.

eth ETHHDR_FIELD

Change an ETH header field. The supported keywords for ETHHDR_FIELD are:

src

dst

Source or destination MAC address in the standard format: XX:XX:XX:XX:XX:XX

type

Ether-type in numeric value

ip IPHDR_FIELD

Change an IPv4 header field. The supported keywords for IPHDR_FIELD are:

src

dst

Source or destination IP address, a four-byte value.

tos

dsfield

precedence

Type Of Service field, an eight-bit value.

ihl

Change the IP Header Length field, a four-bit value.

protocol

Next-layer Protocol field, an eight-bit value.

nofrag

firstfrag

ce

df

mf

Change IP header flags. Note that the value to pass to the set command is not just a bit value, but the full byte including the flags field. Though only the relevant bits of that value are respected, the rest ignored.

ip BEYOND_IPHDR_FIELD

Supported only for non-extended layered op. It is passed to the kernel as offsets relative to the beginning of the IP header and assumes the IP header is of minimum size (20 bytes). The supported keywords for BEYOND_IPHDR_FIELD are:

dport

sport

Destination or source port numbers, a 16-bit value. Indeed, IPv4 headers don't contain this information. Instead, this will set an offset which suits at least TCP and UDP if the IP header is of minimum size (20 bytes). If not, this will do unexpected things.

icmp_type

icmp_code

Again, this allows to change data past the actual IP header itself. It assumes an ICMP header is present immediately following the (minimal sized) IP header. If it is not or the latter is bigger than the minimum of 20 bytes, this will do unexpected things. These fields are eight-bit values.

ip EX_IPHDR_FIELD

Supported only when ex is used. The supported keywords for EX_IPHDR_FIELD are:

ttl

ip6 IP6HDR_FIELD

The supported keywords for IP6HDR_FIELD are:

src

dst

traffic_class

flow_lbl

payload_len

nexthdr

hoplimit

tcp TCPHDR_FIELD

The supported keywords for TCPHDR_FIELD are:

sport

dport

Source or destination TCP port number, a 16-bit value.

flags

udp UDPHDR_FIELD

The supported keywords for UDPHDR_FIELD are:

sport

dport

Source or destination TCP port number, a 16-bit value.

clear

Clear the addressed data (i.e., set it to zero).

invert

Swap every bit in the addressed data.

set VAL

Set the addressed data to a specific value. The size of VAL is defined by either one of the u32, u16 or u8 keywords in RAW_OP, or the size of the addressed header field in LAYERED_OP.

add VAL

Add the addressed data by a specific value. The size of VAL is defined by the size of the addressed header field in EXTENDED_LAYERED_OP. This operation is supported only for extended layered op.

preserve

Keep the addressed data as is.

retain RVAL

This optional extra part of CMD_SPEC allows to exclude bits from being changed. Supported only for 32 bits fields or smaller.

CONTROL

The following keywords allow to control how the tree of qdisc, classes, filters and actions is further traversed after this action.

reclassify

Restart with the first filter in the current list.

pipe

Continue with the next action attached to the same filter.

drop

shot

Drop the packet.

continue

Continue classification with the next filter in line.

pass

Finish classification process and return to calling qdisc for further packet processing. This is the default.

## EXAMPLES
Being able to edit packet data, one could do all kinds of things, such as e.g. implementing port redirection. Certainly not the most useful application, but as an example it should do:

First, qdiscs need to be set up to attach filters to. For the receive path, a simple ingress qdisc will do, for transmit path a classful qdisc (HTB in this case) is necessary:

```
tc qdisc replace dev eth0 root handle 1: htb
tc qdisc add dev eth0 ingress handle ffff:
```

Finally, a filter with pedit action can be added for each direction. In this case, u32 is used matching on the port number to redirect from, while pedit then does the actual rewriting:

```
tc filter add dev eth0 parent 1: u32 \
	match ip dport 23 0xffff \
	action pedit pedit munge ip dport set 22
tc filter add dev eth0 parent ffff: u32 \
	match ip sport 22 0xffff \
	action pedit pedit munge ip sport set 23
tc filter add dev eth0 parent ffff: u32 \
	match ip sport 22 0xffff \
	action pedit ex munge ip dst set 192.168.1.199
tc filter add dev eth0 parent ffff: u32 \
	match ip sport 22 0xffff \
	action pedit ex munge ip6 dst set fe80::dacb:8aff:fec7:320e
tc filter add dev eth0 parent ffff: u32 \
	match ip sport 22 0xffff \
	action pedit ex munge eth dst set 11:22:33:44:55:66
tc filter add dev eth0 parent ffff: u32 \
	match ip dport 23 0xffff \
	action pedit ex munge tcp dport set 22
```

To rewrite just part of a field, use the retain directive. E.g. to overwrite the DSCP part of a dsfield with $DSCP, without touching ECN:

```
tc filter add dev eth0 ingress flower ... \
	action pedit ex munge ip dsfield set $((DSCP << 2)) retain 0xfc
```

And vice versa, to set ECN to e.g. 1 without impacting DSCP:

```
tc filter add dev eth0 ingress flower ... \
	action pedit ex munge ip dsfield set 1 retain 0x3
```

## SEE ALSO
tc(8), tc-htb(8), tc-u32(8)


title: tc-pfifo_fast(8)

summary: three-band first in, first out queue

text:
# tc-pfifo_fast(8)

## NAME
pfifo_fast - three-band first in, first out queue

## DESCRIPTION
pfifo_fast is the default qdisc of each interface.

Whenever an interface is created, the pfifo_fast qdisc is automatically used as a queue. If another qdisc is attached, it preempts the default pfifo_fast, which automatically returns to function when an existing qdisc is detached.

In this sense this qdisc is magic, and unlike other qdiscs.

## ALGORITHM
The algorithm is very similar to that of the classful tc-prio(8) qdisc. pfifo_fast is like three tc-pfifo(8) queues side by side, where packets can be enqueued in any of the three bands based on their Type of Service bits or assigned priority.

Not all three bands are dequeued simultaneously - as long as lower bands have traffic, higher bands are never dequeued. This can be used to prioritize interactive traffic or penalize 'lowest cost' traffic.

Each band can be txqueuelen packets long, as configured with ifconfig(8) or ip(8). Additional packets coming in are not enqueued but are instead dropped.

See tc-prio(8) for complete details on how TOS bits are translated into bands.

## PARAMETERS
txqueuelen

The length of the three bands depends on the interface txqueuelen, as specified with ifconfig(8) or ip(8).

## BUGS
Does not maintain statistics and does not show up in tc qdisc ls. This is because it is the automatic default in the absence of a configured qdisc.

## SEE ALSO
tc(8)

## AUTHORS
Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>

This manpage maintained by bert hubert <ahu@ds9a.nl>


tc-pie

title: tc-pie(8)

text:
# tc-pie(8)

## NAME
PIE - Proportional Integral controller-Enhanced AQM algorithm

## SYNOPSIS
tc qdisc ... pie [ limit PACKETS ] [ target TIME ] [ tupdate TIME ] [ alpha int ] [ beta int ] [ ecn | noecn ] [ bytemode | nobytemode ] [ dq_rate_estimator | no_dq_rate_estimator ]

## DESCRIPTION
Proportional Integral controller-Enhanced (PIE) is a control theoretic active queue management scheme. It is based on the proportional integral controller but aims to control delay. The main design goals are

o Low latency control

o High link utilization

o Simple implementation

o Guaranteed stability and fast responsiveness

## ALGORITHM
PIE is designed to control delay effectively. First, an average dequeue rate is estimated based on the standing queue. The rate is used to calculate the current delay. Then, on a periodic basis, the delay is used to calculate the dropping probability. Finally, on arrival, a packet is dropped (or marked) based on this probability.

PIE makes adjustments to the probability based on the trend of the delay i.e. whether it is going up or down.The delay converges quickly to the target value specified.

alpha and beta are statically chosen parameters chosen to control the drop probability growth and are determined through control theoretic approaches. alpha determines how the deviation between the current and target latency changes probability. beta exerts additional adjustments depending on the latency trend.

The drop probability is used to mark packets in ecn mode. However, as in RED, beyond 10% packets are dropped based on this probability. The bytemode is used to drop packets proportional to the packet size.

Additional details can be found in the paper cited below.

## PARAMETERS

### limit
limit on the queue size in packets. Incoming packets are dropped when this limit is reached. Default is 1000 packets.

### target
is the expected queue delay. The default target delay is 15ms.

### tupdate
is the frequency at which the system drop probability is calculated. The default is 15ms.

### beta
alpha and beta are parameters chosen to control the drop probability. These should be in the range between 0 and 32.

### ecn | noecn
is used to mark packets instead of dropping. ecn to turn on ecn mode, noecn to turn off ecn mode. By default, ecn is turned off.

### bytemode | nobytemode
is used to scale drop probability proportional to packet size. bytemode to turn on bytemode, nobytemode to turn off bytemode. By default, bytemode is turned off.

### dq_rate_estimator | no_dq_rate_estimator
is used to calculate delay using Little's law. dq_rate_estimator to turn on dq_rate_estimator, no_dq_rate_estimator to turn off no_dq_rate_estimator. By default, dq_rate_estimator is turned off.

## EXAMPLES

\# tc qdisc add dev eth0 root pie

\# tc -s qdisc show

qdisc pie 8036: dev eth0 root refcnt 2 limit 1000p target 15.0ms tupdate 16.0ms alpha 2 beta 20

Sent 31216108 bytes 20800 pkt (dropped 80, overlimits 0 requeues 0)

backlog 16654b 11p requeues 0

prob 0.006161 delay 15666us

pkts_in 20811 overlimit 0 dropped 80 maxq 50 ecn_mark 0

\# tc qdisc add dev eth0 root pie dq_rate_estimator

\# tc -s qdisc show

qdisc pie 8036: dev eth0 root refcnt 2 limit 1000p target 15.0ms tupdate 16.0ms alpha 2 beta 20

Sent 63947420 bytes 42414 pkt (dropped 41, overlimits 0 requeues 0)

backlog 271006b 179p requeues 0

prob 0.000092 delay 22200us avg_dq_rate 12145996

pkts_in 41 overlimit 343 dropped 0 maxq 50 ecn_mark 0

\# tc qdisc add dev eth0 root pie limit 100 target 20ms tupdate 30ms ecn

\# tc -s qdisc show

qdisc pie 8036: dev eth0 root refcnt 2 limit 100p target 20.0ms tupdate 32.0ms alpha 2 beta 20 ecn

Sent 6591724 bytes 4442 pkt (dropped 27, overlimits 0 requeues 0)

backlog 18168b 12p requeues 0

prob 0.008845 delay 11348us

pkts_in 4454 overlimit 0 dropped 27 maxq 65 ecn_mark 0

\# tc qdisc add dev eth0 root pie limit 100 target 50ms tupdate 30ms bytemode

\# tc -s qdisc show

qdisc pie 8036: dev eth0 root refcnt 2 limit 100p target 50.0ms tupdate 32.0ms alpha 2 beta 20 bytemode

Sent 1616274 bytes 1137 pkt (dropped 0, overlimits 0 requeues 0)

backlog 13626b 9p requeues 0

prob 0.000000 delay 0us

pkts_in 1146 overlimit 0 dropped 0 maxq 23 ecn_mark 0

## SEE ALSO
tc(8), tc-codel(8) tc-red(8)

## SOURCES

o RFC 8033: https://tools.ietf.org/html/rfc8033

## AUTHORS
PIE was implemented by Vijay Subramanian and Mythili Prabhu, also the authors of this man page. Please report bugs and corrections to the Linux networking development mailing list at <netdev@vger.kernel.org>.


tc-police

title: tc-police(8)

text:
# tc-police(8)

## NAME
police - policing action

## SYNOPSIS

tc ... action police [ rate RATE burst BYTES[/BYTES] ] [ pkts_rate RATE pkts_burst PACKETS] [ mtu BYTES[/BYTES] ] [ peakrate RATE ] [ overhead BYTES ] [ linklayer TYPE ] [ CONTROL ]

tc ... filter ... [ estimator SAMPLE AVERAGE ] action police avrate RATE [ CONTROL ]

CONTROL := conform-exceed EXCEEDACT[/NOTEXCEEDACT

EXCEEDACT/NOTEXCEEDACT := { pipe | ok | reclassify | drop | continue | goto chain CHAIN_INDEX }

## DESCRIPTION
The police action allows limiting of the byte or packet rate of traffic matched by the filter it is attached to.

There are two different algorithms available to measure the byte rate: The first one uses an internal dual token bucket and is configured using the rate, burst, mtu, peakrate, overhead and linklayer parameters. The second one uses an in-kernel sampling mechanism. It can be fine-tuned using the estimator filter parameter.

There is one algorithm available to measure packet rate and it is similar to the first algorithm described for byte rate. It is configured using the pkt_rate and pkt_burst parameters.

At least one of the rate and pkt_rate parameters must be configured.

## OPTIONS
rate RATE

The maximum byte rate of packets passing this action. Those exceeding it will be treated as defined by the conform-exceed option.

burst BYTES[/BYTES]

Set the maximum allowed burst in bytes, optionally followed by a slash ('/') sign and cell size which must be a power of 2.

pkt_rate RATE

The maximum packet rate or packets passing this action. Those exceeding it will be treated as defined by the conform-exceed option.

pkt_burst PACKETS

Set the maximum allowed burst in packets.

mtu BYTES[/BYTES]

This is the maximum packet size handled by the policer (larger ones will be handled like they exceeded the configured rate). Setting this value correctly will improve the scheduler's precision. Value formatting is identical to burst above. Defaults to unlimited.

peakrate RATE

Set the maximum bucket depletion rate, exceeding rate.

avrate RATE

Make use of an in-kernel bandwidth rate estimator and match the given RATE against it.

overhead BYTES

Account for protocol overhead of encapsulating output devices when computing rate and peakrate.

linklayer TYPE

Specify the link layer type. TYPE may be one of ethernet (the default), atm or adsl (which are synonyms). It is used to align the precomputed rate tables to ATM cell sizes, for ethernet no action is taken.

estimator SAMPLE AVERAGE

Fine-tune the in-kernel packet rate estimator. SAMPLE and AVERAGE are time values and control the frequency in which samples are taken and over what timespan an average is built.

conform-exceed EXCEEDACT[/NOTEXCEEDACT]

Define how to handle packets which exceed or conform the configured bandwidth limit. Possible values are:

continue

Don't do anything, just continue with the next action in line.

drop

Drop the packet immediately.

shot

This is a synonym to drop.

ok

Accept the packet. This is the default for conforming packets.

pass

This is a synonym to ok.

reclassify

Treat the packet as non-matching to the filter this action is attached to and continue with the next filter in line (if any). This is the default for exceeding packets.

pipe

Pass the packet to the next action in line.

## EXAMPLES
A typical application of the police action is to enforce ingress traffic rate by dropping exceeding packets. Although better done on the sender's side, especially in scenarios with lack of peer control (e.g. with dial-up providers) this is often the best one can do in order to keep latencies low under high load. The following establishes input bandwidth policing to 1mbit/s using the ingress qdisc and u32 filter:

```
# tc qdisc add dev eth0 handle ffff: ingress
# tc filter add dev eth0 parent ffff: u32 \
	match u32 0 0 \
	police rate 1mbit burst 100k
```

As an action can not live on it's own, there always has to be a filter involved as link between qdisc and action. The example above uses u32 for that, which is configured to effectively match any packet (passing it to the police action thereby).

## SEE ALSO
tc(8)


tc-prio

title: tc-prio(8)

summary: Priority qdisc

text:
# tc-prio(8)

## NAME
PRIO - Priority qdisc

## SYNOPSIS
tc qdisc ... dev dev ( parent classid | root) [ handle major: ] prio [ bands bands ] [ priomap band band band... ] [ estimator interval timeconstant ]

## DESCRIPTION
The PRIO qdisc is a simple classful queueing discipline that contains an arbitrary number of classes of differing priority. The classes are dequeued in numerical descending order of priority. PRIO is a scheduler and never delays packets - it is a work-conserving qdisc, though the qdiscs contained in the classes may not be.

Very useful for lowering latency when there is no need for slowing down traffic.

## ALGORITHM
On creation with 'tc qdisc add', a fixed number of bands is created. Each band is a class, although is not possible to add classes with 'tc qdisc add', the number of bands to be created must instead be specified on the command line attaching PRIO to its root.

When dequeueing, band 0 is tried first and only if it did not deliver a packet does PRIO try band 1, and so onwards. Maximum reliability packets should therefore go to band 0, minimum delay to band 1 and the rest to band 2.

As the PRIO qdisc itself will have minor number 0, band 0 is actually major:1, band 1 is major:2, etc. For major, substitute the major number assigned to the qdisc on 'tc qdisc add' with the handle parameter.

## CLASSIFICATION
Three methods are available to PRIO to determine in which band a packet will be enqueued.

From userspace

A process with sufficient privileges can encode the destination class directly with SO_PRIORITY, see socket(7).

with a tc filter

A tc filter attached to the root qdisc can point traffic directly to a class

with the priomap

Based on the packet priority, which in turn is derived from the Type of Service assigned to the packet.

Only the priomap is specific to this qdisc.

## QDISC PARAMETERS
bands

Number of bands. If changed from the default of 3, priomap must be updated as well.

priomap

The priomap maps the priority of a packet to a class. The priority can either be set directly from userspace, or be derived from the Type of Service of the packet. Determines how packet priorities, as assigned by the kernel, map to bands. Mapping occurs based on the TOS octet of the packet, which looks like this:

```
0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|           |               |   |
|PRECEDENCE |      TOS      |MBZ|
|           |               |   |
+---+---+---+---+---+---+---+---+
```

The four TOS bits (the 'TOS field') are defined as:

```
Binary Decimal  Meaning
-----------------------------------------
1000   8         Minimize delay (md)
0100   4         Maximize throughput (mt)
0010   2         Maximize reliability (mr)
0001   1         Minimize monetary cost (mmc)
0000   0         Normal Service
```

As there is 1 bit to the right of these four bits, the actual value of the TOS field is double the value of the TOS bits. Tcpdump -v -v shows you the value of the entire TOS field, not just the four bits. It is the value you see in the first column of this table:

```
TOS     Bits  Means                    Linux Priority    Band
------------------------------------------------------------
0x0     0     Normal Service           0 Best Effort     1
0x2     1     Minimize Monetary Cost   0 Best Effort     1
0x4     2     Maximize Reliability     0 Best Effort     1
0x6     3     mmc+mr                   0 Best Effort     1
0x8     4     Maximize Throughput      2 Bulk            2
0xa     5     mmc+mt                   2 Bulk            2
0xc     6     mr+mt                    2 Bulk            2
0xe     7     mmc+mr+mt                2 Bulk            2
0x10    8     Minimize Delay           6 Interactive     0
0x12    9     mmc+md                   6 Interactive     0
0x14    10    mr+md                    6 Interactive     0
0x16    11    mmc+mr+md                6 Interactive     0
0x18    12    mt+md                    4 Int. Bulk       1
0x1a    13    mmc+mt+md                4 Int. Bulk       1
0x1c    14    mr+mt+md                 4 Int. Bulk       1
0x1e    15    mmc+mr+mt+md             4 Int. Bulk       1
```

The second column contains the value of the relevant four TOS bits, followed by their translated meaning. For example, 15 stands for a packet wanting Minimal Monetary Cost, Maximum Reliability, Maximum Throughput AND Minimum Delay.

The fourth column lists the way the Linux kernel interprets the TOS bits, by showing to which Priority they are mapped.

The last column shows the result of the default priomap. On the command line, the default priomap looks like this:

1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

This means that priority 4, for example, gets mapped to band number 1. The priomap also allows you to list higher priorities (> 7) which do not correspond to TOS mappings, but which are set by other means.

This table from RFC 1349 (read it for more details) explains how applications might very well set their TOS bits:

```
TELNET                   1000           (minimize delay)
FTP

        Control          1000           (minimize delay)

        Data             0100           (maximize throughput)
TFTP                     1000           (minimize delay)
SMTP

        Command phase    1000           (minimize delay)

        DATA phase       0100           (maximize throughput)
Domain Name Service

        UDP Query        1000           (minimize delay)

        TCP Query        0000

        Zone Transfer    0100           (maximize throughput)
NNTP                     0001           (minimize monetary cost)
ICMP

        Errors           0000

        Requests         0000 (mostly)

        Responses        <same as request> (mostly)
```

## CLASSES
PRIO classes cannot be configured further - they are automatically created when the PRIO qdisc is attached. Each class however can contain yet a further qdisc.

## BUGS
Large amounts of traffic in the lower bands can cause starvation of higher bands. Can be prevented by attaching a shaper (for example, tc-tbf(8) to these bands to make sure they cannot dominate the link.

## AUTHORS
Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>, J Hadi Salim <hadi@cyberus.ca>. This manpage maintained by bert hubert <ahu@ds9a.nl>


tc-red

title: tc-red(8)

summary: Random Early Detection

text:
# tc-red(8)

## NAME
red - Random Early Detection

## SYNOPSIS
tc qdisc ... red limit bytes [ min bytes ] [ max bytes ] avpkt bytes [ burst packets ] [ ecn ] [ harddrop ] [ nodrop ] [ bandwidth rate ] [ probability chance ] [ adaptive ] [ qevent early_drop block index ] [ qevent mark block index ]

## DESCRIPTION
Random Early Detection is a classless qdisc which manages its queue size smartly. Regular queues simply drop packets from the tail when they are full, which may not be the optimal behaviour. RED also performs tail drop, but does so in a more gradual way.

Once the queue hits a certain average length, packets enqueued have a configurable chance of being marked (which may mean dropped). This chance increases linearly up to a point called the max average queue length, although the queue might get bigger.

This has a host of benefits over simple taildrop, while not being processor intensive. It prevents synchronous retransmits after a burst in traffic, which cause further retransmits, etc.

The goal is to have a small queue size, which is good for interactivity while not disturbing TCP/IP traffic with too many sudden drops after a burst of traffic.

Depending on if ECN is configured, marking either means dropping or purely marking a packet as overlimit.

## ALGORITHM
The average queue size is used for determining the marking probability. This is calculated using an Exponential Weighted Moving Average, which can be more or less sensitive to bursts.

When the average queue size is below min bytes, no packet will ever be marked. When it exceeds min, the probability of doing so climbs linearly up to probability, until the average queue size hits max bytes. Because probability is normally not set to 100%, the queue size might conceivably rise above max bytes, so the limit parameter is provided to set a hard maximum for the size of the queue.

## PARAMETERS
min

Average queue size at which marking becomes a possibility. Defaults to max /3

max

At this average queue size, the marking probability is maximal. Should be at least twice min to prevent synchronous retransmits, higher for low min. Default to limit /4

probability

Maximum probability for marking, specified as a floating point number from 0.0 to 1.0. Suggested values are 0.01 or 0.02 (1 or 2%, respectively). Default : 0.02

limit

Hard limit on the real (not average) queue size in bytes. Further packets are dropped. Should be set higher than max+burst. It is advised to set this a few times higher than max.

burst

Used for determining how fast the average queue size is influenced by the real queue size. Larger values make the calculation more sluggish, allowing longer bursts of traffic before marking starts. Real life experiments support the following guideline: (min+min+max)/(3*avpkt).

avpkt

Specified in bytes. Used with burst to determine the time constant for average queue size calculations. 1000 is a good value.

bandwidth

This rate is used for calculating the average queue size after some idle time. Should be set to the bandwidth of your interface. Does not mean that RED will shape for you! Optional. Default : 10Mbit

ecn

As mentioned before, RED can either 'mark' or 'drop'. Explicit Congestion Notification allows RED to notify remote hosts that their rate exceeds the amount of bandwidth available. Non-ECN capable hosts can only be notified by dropping a packet. If this parameter is specified, packets which indicate that their hosts honor ECN will only be marked and not dropped, unless the queue size hits limit bytes. Recommended.

harddrop

If average flow queue size is above max bytes, this parameter forces a drop instead of ecn marking.

nodrop

With this parameter, traffic that should be marked, but is not ECN-capable, is enqueued. Without the parameter it is early-dropped.

adaptive

(Added in linux-3.3) Sets RED in adaptive mode as described in http://icir.org/floyd/papers/adaptiveRed.pdf

```
Goal of Adaptive RED is to make 'probability' dynamic value between 1% and 50% to reach the target average queue :
(max - min) / 2
```

## QEVENTS
See tc (8) for some general notes about qevents. The RED qdisc supports the following qevents:

early_drop

The associated block is executed when packets are early-dropped. This includes non-ECT packets in ECN mode.

mark

The associated block is executed when packets are marked in ECN mode.

## EXAMPLE
\# tc qdisc add dev eth0 parent 1:1 handle 10: red

limit 400000 min 30000 max 90000 avpkt 1000

burst 55 ecn adaptive bandwidth 10Mbit

## SEE ALSO
tc(8), tc-choke(8)

## SOURCES
o

Floyd, S., and Jacobson, V., Random Early Detection gateways for Congestion Avoidance. http://www.aciri.org/floyd/papers/red/red.html

o

Some changes to the algorithm by Alexey N. Kuznetsov.

o

Adaptive RED : http://icir.org/floyd/papers/adaptiveRed.pdf

## AUTHORS
Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>, Alexey Makarenko <makar@phoenix.kharkov.ua>, J Hadi Salim <hadi@nortelnetworks.com>, Eric Dumazet <eric.dumazet@gmail.com>. This manpage maintained by bert hubert <ahu@ds9a.nl>


tc-route

title: tc-route(8)

summary: route traffic control filter

text:
# tc-route(8)

## NAME
route - route traffic control filter

## SYNOPSIS

tc filter ... route [ from REALM | fromif TAG ] [ to REALM ] [ classid CLASSID ] [ action ACTION_SPEC ]

## DESCRIPTION
Match packets based on routing table entries. This filter centers around the possibility to assign a realm to routing table entries. For any packet to be classified by this filter, a routing table lookup is performed and the returned realm is used to decide on whether the packet is a match or not.

## OPTIONS
action ACTION_SPEC

Apply an action from the generic actions framework on matching packets.

classid CLASSID

Push matching packets into the class identified by CLASSID.

from REALM

fromif TAG

Perform source route lookups. TAG is the name of an interface which must be present on the system at the time of tc invocation.

to REALM

Match if normal (i.e., destination) routing returns the given REALM.

## EXAMPLES
Consider the subnet 192.168.2.0/24 being attached to eth0:

```
ip route add 192.168.2.0/24 dev eth0 realm 2
```

The following route filter will then match packets from that subnet:

```
tc filter add ... route from 2 classid 1:2
```

and pass packets on to class 1:2.

## NOTES
Due to implementation details, realm values must be in a range from 0 to 255, inclusive. Alternatively, a verbose name defined in /etc/iproute2/rt_realms may be given instead.

## SEE ALSO
tc(8), ip-route(8)


tc-sample

title: tc-sample(8)

text:
# tc-sample(8)

## NAME
sample - packet sampling tc action

## SYNOPSIS

tc ... action sample rate RATE group GROUP [ trunc SIZE ] [ index INDEX ]

tc ... action sample index INDEX

## DESCRIPTION
The sample action allows sampling packets matching classifier.

The packets are chosen randomly according to the rate parameter, and are sampled using the psample generic netlink channel. The user can also specify packet truncation to save user-kernel traffic. Each sample includes some informative metadata about the original packet, which is sent using netlink attributes, alongside the original packet data.

The user can either specify the sample action parameters as presented in the first form above, or use an existing sample action using its index, as presented in the second form.

## SAMPLED PACKETS METADATA FIELDS
The metadata are delivered to userspace applications using the psample generic netlink channel, where each sample includes the following netlink attributes:

PSAMPLE_ATTR_IIFINDEX

The input interface index of the packet, if there is one.

PSAMPLE_ATTR_OIFINDEX

The output interface index of the packet. This field is not relevant on ingress sampling

PSAMPLE_ATTR_ORIGSIZE

The size of the original packet (before truncation)

PSAMPLE_ATTR_SAMPLE_GROUP

The psample group the packet was sent to

PSAMPLE_ATTR_GROUP_SEQ

A sequence number of the sampled packet. This number is incremented with each sampled packet of the current psample group

PSAMPLE_ATTR_SAMPLE_RATE

The rate the packet was sampled with

## OPTIONS
rate RATE

The packet sample rate. RATE is the expected ratio between observed packets and sampled packets. For example, RATE of 100 will lead to an average of one sampled packet out of every 100 observed.

trunc SIZE

Upon set, defines the maximum size of the sampled packets, and causes truncation if needed

group GROUP

The psample group the packet will be sent to. The psample module defines the concept of groups, which allows the user to match specific sampled packets in the case of multiple sampling rules, thus identify only the packets that came from a specific rule.

index INDEX

Is a unique ID for an action. When creating new action instance, this parameter allows to set the new action index. When using existing action, this parameter allows to specify the existing action index. The index must 32bit unsigned integer greater than zero.

## EXAMPLES
Sample one of every 100 packets flowing into interface eth0 to psample group 12:

```
tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev eth0 parent ffff: matchall \

     action sample rate 100 group 12 index 19
```

Use the same action instance to sample eth1 too:

```
tc qdisc add dev eth1 handle ffff: ingress
tc filter add dev eth1 parent ffff: matchall \

     action sample index 19
```

## SEE ALSO
tc(8), tc-matchall(8) psample(1)


tc-sfb

title: tc-sfb(8)

summary: Stochastic Fair Blue

text:
# tc-sfb(8)

## NAME
sfb - Stochastic Fair Blue

## SYNOPSIS
tc qdisc ... blue rehash milliseconds db milliseconds limit packets max packets target packets increment float decrement float penalty_rate packets per second penalty_burst packets

## DESCRIPTION
Stochastic Fair Blue is a classless qdisc to manage congestion based on packet loss and link utilization history while trying to prevent non-responsive flows (i.e. flows that do not react to congestion marking or dropped packets) from impacting performance of responsive flows. Unlike RED, where the marking probability has to be configured, BLUE tries to determine the ideal marking probability automatically.

## ALGORITHM
The BLUE algorithm maintains a probability which is used to mark or drop packets that are to be queued. If the queue overflows, the mark/drop probability is increased. If the queue becomes empty, the probability is decreased. The Stochastic Fair Blue (SFB) algorithm is designed to protect TCP flows against non-responsive flows.

This SFB implementation maintains 8 levels of 16 bins each for accounting. Each flow is mapped into a bin of each level using a per-level hash value.

Every bin maintains a marking probability, which gets increased or decreased based on bin occupancy. If the number of packets exceeds the size of that bin, the marking probability is increased. If the number drops to zero, it is decreased.

The marking probability is based on the minimum value of all bins a flow is mapped into, thus, when a flow does not respond to marking or gradual packet drops, the marking probability quickly reaches one.

In this case, the flow is rate-limited to penalty_rate packets per second.

## LIMITATIONS
Due to SFBs nature, it is possible for responsive flows to share all of its bins with a non-responsive flow, causing the responsive flow to be misidentified as being non-responsive.

The probability of a responsive flow to be misidentified is dependent on the number of non-responsive flows, M. It is (1 - (1 - (1 / 16.0)) ** M) **8, so for example with 10 non-responsive flows approximately 0.2% of responsive flows will be misidentified.

To mitigate this, SFB performs performs periodic re-hashing to avoid misclassification for prolonged periods of time.

The default hashing method will use source and destination ip addresses and port numbers if possible, and also supports tunneling protocols. Alternatively, an external classifier can be configured, too.

## PARAMETERS
rehash

Time interval in milliseconds when queue perturbation occurs to avoid erroneously detecting unrelated, responsive flows as being part of a non-responsive flow for prolonged periods of time. Defaults to 10 minutes.

db

Double buffering warmup wait time, in milliseconds. To avoid destroying the probability history when rehashing is performed, this implementation maintains a second set of levels/bins as described in section 4.4 of the SFB reference. While one set is used to manage the queue, a second set is warmed up: Whenever a flow is then determined to be non-responsive, the marking probabilities in the second set are updated. When the rehashing happens, these bins will be used to manage the queue and all non-responsive flows can be rate-limited immediately. This value determines how much time has to pass before the 2nd set will start to be warmed up. Defaults to one minute, should be lower than rehash.

limit

Hard limit on the real (not average) total queue size in packets. Further packets are dropped. Defaults to the transmit queue length of the device the qdisc is attached to.

max

Maximum length of a buckets queue, in packets, before packets start being dropped. Should be slightly larger than target , but should not be set to values exceeding 1.5 times that of target . Defaults to 25.

target

The desired average bin length. If the bin queue length reaches this value, the marking probability is increased by increment. The default value depends on the max setting, with max set to 25 target will default to 20.

increment

A value used to increase the marking probability when the queue appears to be over-used. Must be between 0 and 1.0. Defaults to 0.00050.

decrement

Value used to decrease the marking probability when the queue is found to be empty. Must be between 0 and 1.0. Defaults to 0.00005.

penalty_rate

The maximum number of packets belonging to flows identified as being non-responsive that can be enqueued per second. Once this number has been reached, further packets of such non-responsive flows are dropped. Set this to a reasonable fraction of your uplink throughput; the default value of 10 packets is probably too small.

penalty_burst

The number of packets a flow is permitted to exceed the penalty rate before packets start being dropped. Defaults to 20 packets.

## STATISTICS
This qdisc exposes additional statistics via 'tc -s qdisc' output. These are:

earlydrop

The number of packets dropped before a per-flow queue was full.

ratedrop

The number of packets dropped because of rate-limiting. If this value is high, there are many non-reactive flows being sent through sfb. In such cases, it might be better to embed sfb within a classful qdisc to better control such flows using a different, shaping qdisc.

bucketdrop

The number of packets dropped because a per-flow queue was full. High bucketdrop may point to a high number of aggressive, short-lived flows.

queuedrop

The number of packets dropped due to reaching limit. This should normally be 0.

marked

The number of packets marked with ECN.

maxqlen

The length of the current longest per-flow (virtual) queue.

maxprob

The maximum per-flow drop probability. 1 means that some flows have been detected as non-reactive.

## NOTES
SFB automatically enables use of Explicit Congestion Notification (ECN). Also, this SFB implementation does not queue packets itself. Rather, packets are enqueued to the inner qdisc (defaults to pfifo). Because sfb maintains virtual queue states, the inner qdisc must not drop a packet previously queued. Furthermore, if a buckets queue has a very high marking rate, this implementation will start dropping packets instead of marking them, as such a situation points to either bad congestion, or an unresponsive flow.

## EXAMPLE & USAGE
To attach to interface $DEV, using default options:

\# tc qdisc add dev $DEV handle 1: root sfb

Only use destination ip addresses for assigning packets to bins, perturbing hash results every 10 minutes:

\# tc filter add dev $DEV parent 1: handle 1 flow hash keys dst perturb 600

## SEE ALSO
tc(8), tc-red(8), tc-sfq(8)

## SOURCES
o

W. Feng, D. Kandlur, D. Saha, K. Shin, BLUE: A New Class of Active Queue Management Algorithms, U. Michigan CSE-TR-387-99, April 1999.

## AUTHORS
This SFB implementation was contributed by Juliusz Chroboczek and Eric Dumazet.


tc-sfq

title: tc-sfq(8)

summary: Stochastic Fairness Queueing

text:
# tc-sfq(8)

## NAME
sfq - Stochastic Fairness Queueing

## SYNOPSIS
tc qdisc ... [ divisor hashtablesize ] [ limit packets ] [ perturb seconds ] [ quantum bytes ] [ flows number ] [ depth number ] [ headdrop ] [ redflowlimit bytes ] [ min bytes ] [ max bytes ] [ avpkt bytes ] [ burst packets ] [ probability P ] [ ecn ] [ harddrop ]

## DESCRIPTION
Stochastic Fairness Queueing is a classless queueing discipline available for traffic control with the tc(8) command.

SFQ does not shape traffic but only schedules the transmission of packets, based on 'flows'. The goal is to ensure fairness so that each flow is able to send data in turn, thus preventing any single flow from drowning out the rest.

This may in fact have some effect in mitigating a Denial of Service attempt.

SFQ is work-conserving and therefore always delivers a packet if it has one available.

## ALGORITHM
On enqueueing, each packet is assigned to a hash bucket, based on the packets hash value. This hash value is either obtained from an external flow classifier (use tc filter to set them), or a default internal classifier if no external classifier has been configured.

When the internal classifier is used, sfq uses

(i)

Source address

(ii)

Destination address

(iii)

Source and Destination port

If these are available. SFQ knows about ipv4 and ipv6 and also UDP, TCP and ESP. Packets with other protocols are hashed based on the 32bits representation of their destination and source. A flow corresponds mostly to a TCP/IP connection.

Each of these buckets should represent a unique flow. Because multiple flows may get hashed to the same bucket, sfqs internal hashing algorithm may be perturbed at configurable intervals so that the unfairness lasts only for a short while. Perturbation may however cause some inadvertent packet reordering to occur. After linux-3.3, there is no packet reordering problem, but possible packet drops if rehashing hits one limit (number of flows or packets per flow)

When dequeuing, each hashbucket with data is queried in a round robin fashion.

Before linux-3.3, the compile time maximum length of the SFQ is 128 packets, which can be spread over at most 128 buckets of 1024 available. In case of overflow, tail-drop is performed on the fullest bucket, thus maintaining fairness.

After linux-3.3, maximum length of SFQ is 65535 packets, and divisor limit is 65536. In case of overflow, tail-drop is performed on the fullest bucket, unless headdrop was requested.

## PARAMETERS
divisor

Can be used to set a different hash table size, available from kernel 2.6.39 onwards. The specified divisor must be a power of two and cannot be larger than 65536. Default value: 1024.

limit

Upper limit of the SFQ. Can be used to reduce the default length of 127 packets. After linux-3.3, it can be raised.

depth

Limit of packets per flow (after linux-3.3). Default to 127 and can be lowered.

perturb

Interval in seconds for queue algorithm perturbation. Defaults to 0, which means that no perturbation occurs. Do not set too low for each perturbation may cause some packet reordering or losses. Advised value: 60 This value has no effect when external flow classification is used. Its better to increase divisor value to lower risk of hash collisions.

quantum

Amount of bytes a flow is allowed to dequeue during a round of the round robin process. Defaults to the MTU of the interface which is also the advised value and the minimum value.

flows

After linux-3.3, it is possible to change the default limit of flows. Default value is 127

headdrop

Default SFQ behavior is to perform tail-drop of packets from a flow. You can ask a headdrop instead, as this is known to provide a better feedback for TCP flows.

redflowlimit

Configure the optional RED module on top of each SFQ flow. Random Early Detection principle is to perform packet marks or drops in a probabilistic way. (man tc-red for details about RED)

```
redflowlimit configures the hard limit on the real (not average) queue size per SFQ flow in bytes.
```

min

Average queue size at which marking becomes a possibility. Defaults to max /3

max

At this average queue size, the marking probability is maximal. Defaults to redflowlimit /4

probability

Maximum probability for marking, specified as a floating point number from 0.0 to 1.0. Default value is 0.02

avpkt

Specified in bytes. Used with burst to determine the time constant for average queue size calculations. Default value is 1000

burst

Used for determining how fast the average queue size is influenced by the real queue size.

```
Default value is :
(2 * min + max) / (3 * avpkt)
```

ecn

RED can either 'mark' or 'drop'. Explicit Congestion Notification allows RED to notify remote hosts that their rate exceeds the amount of bandwidth available. Non-ECN capable hosts can only be notified by dropping a packet. If this parameter is specified, packets which indicate that their hosts honor ECN will only be marked and not dropped, unless the queue size hits depth packets.

harddrop

If average flow queue size is above max bytes, this parameter forces a drop instead of ecn marking.

## EXAMPLE & USAGE
To attach to device ppp0:

\# tc qdisc add dev ppp0 root sfq

Please note that SFQ, like all non-shaping (work-conserving) qdiscs, is only useful if it owns the queue. This is the case when the link speed equals the actually available bandwidth. This holds for regular phone modems, ISDN connections and direct non-switched ethernet links.

Most often, cable modems and DSL devices do not fall into this category. The same holds for when connected to a switch and trying to send data to a congested segment also connected to the switch.

In this case, the effective queue does not reside within Linux and is therefore not available for scheduling.

Embed SFQ in a classful qdisc to make sure it owns the queue.

It is possible to use external classifiers with sfq, for example to hash traffic based only on source/destination ip addresses:

\# tc filter add ... flow hash keys src,dst perturb 30 divisor 1024

Note that the given divisor should match the one used by sfq. If you have changed the sfq default of 1024, use the same value for the flow hash filter, too.

Example of sfq with optional RED mode :

\# tc qdisc add dev eth0 parent 1:1 handle 10: sfq limit 3000 flows 512 divisor 16384

redflowlimit 100000 min 8000 max 60000 probability 0.20 ecn headdrop

## SOURCE
o

Paul E. McKenney "Stochastic Fairness Queuing", IEEE INFOCOMM'90 Proceedings, San Francisco, 1990.

o

Paul E. McKenney "Stochastic Fairness Queuing", "Interworking: Research and Experience", v.2, 1991, p.113-131.

o

See also: M. Shreedhar and George Varghese "Efficient Fair Queuing using Deficit Round Robin", Proc. SIGCOMM 95.

## SEE ALSO
tc(8), tc-red(8)

## AUTHORS
Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>, Eric Dumazet <eric.dumazet@gmail.com>.

This manpage maintained by bert hubert <ahu@ds9a.nl>


tc-simple

title: tc-simple(8)

text:
# tc-simple(8)

## NAME
simple - basic example action

## SYNOPSIS

tc ... action simple [ sdata STRING ] [ index INDEX ] [ CONTROL ]

CONTROL := { reclassify | pipe | drop | continue | ok }

## DESCRIPTION
This is a pedagogical example rather than an actually useful action. Upon every access, it prints the given STRING which may be of arbitrary length.

## OPTIONS
sdata STRING

The actual string to print.

index INDEX

Optional action index value.

CONTROL

Indicate how tc should proceed after executing the action. For a description of the possible CONTROL values, see tc-actions(8).

## EXAMPLES
The following example makes the kernel yell "Incoming ICMP!" every time it sees an incoming ICMP on eth0. Steps are:

1)

Add an ingress qdisc point to eth0

2)

Start a chain on ingress of eth0 that first matches ICMP then invokes the simple action to shout.

3)

display stats and show that no packet has been seen by the action

4)

Send one ping packet to google (expect to receive a response back)

5)

grep the logs to see the logged message

6)

display stats again and observe increment by 1

```
  hadi@noma1:$ tc qdisc add dev eth0 ingress

  hadi@noma1:$tc filter add dev eth0 parent ffff: protocol ip prio 5 \
	 u32 match ip protocol 1 0xff flowid 1:1 action simple sdata "Incoming ICMP"

  hadi@noma1:$ sudo tc -s filter ls  dev eth0 parent ffff:

   filter protocol ip pref 5 u32

   filter protocol ip pref 5 u32 fh 800: ht divisor 1

   filter protocol ip pref 5 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1

     match 00010000/00ff0000 at 8
	action order 1: Simple <Incoming ICMP>
	 index 4 ref 1 bind 1 installed 29 sec used 29 sec
	 Action statistics:
		Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
		backlog 0b 0p requeues 0

  hadi@noma1$ ping -c 1 www.google.ca

  PING www.google.ca (74.125.225.120) 56(84) bytes of data.

  64 bytes from ord08s08-in-f24.1e100.net (74.125.225.120): icmp_req=1 ttl=53 time=31.3 ms

  --- www.google.ca ping statistics ---

  1 packets transmitted, 1 received, 0% packet loss, time 0ms

  rtt min/avg/max/mdev = 31.316/31.316/31.316/0.000 ms

  hadi@noma1$ dmesg | grep simple

  [135354.473951] simple: Incoming ICMP_1

  hadi@noma1$ sudo tc/tc -s filter ls  dev eth0 parent ffff:

  filter protocol ip pref 5 u32

  filter protocol ip pref 5 u32 fh 800: ht divisor 1

  filter protocol ip pref 5 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1

    match 00010000/00ff0000 at 8
	action order 1: Simple <Incoming ICMP>
	 index 4 ref 1 bind 1 installed 206 sec used 67 sec
	Action statistics:
	Sent 84 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)
	backlog 0b 0p requeues 0

```

## SEE ALSO
tc(8) tc-actions(8)


tc-skbedit

title: tc-skbedit(8)

text:
# tc-skbedit(8)

## NAME
skbedit - SKB editing action

## SYNOPSIS

tc ... action skbedit [ queue_mapping QUEUE_MAPPING ] [ priority PRIORITY ] [ mark MARK[/MASK] ] [ ptype PTYPE ] [ inheritdsfield ]

## DESCRIPTION
The skbedit action allows to change a packet's associated meta data. It complements the pedit action, which in turn allows to change parts of the packet data itself.

The most unique feature of skbedit is its ability to decide over which queue of an interface with multiple transmit queues the packet is to be sent out. The number of available transmit queues is reflected by sysfs entries within /sys/class/net/<interface>/queues with name tx-N (where N is the actual queue number).

## OPTIONS
queue_mapping QUEUE_MAPPING

Override the packet's transmit queue. Useful when applied to packets transmitted over MQ-capable network interfaces. QUEUE_MAPPING is an unsigned 16bit value in decimal format.

priority PRIORITY

Override the packet classification decision. PRIORITY is either root, none or a hexadecimal major class ID optionally followed by a colon (:) and a hexadecimal minor class ID.

mark MARK[/MASK]

Change the packet's firewall mark value. MARK is an unsigned 32bit value in automatically detected format (i.e., prefix with '0x' for hexadecimal interpretation, etc.). MASK defines the 32-bit mask selecting bits of mark value. Default is 0xffffffff.

ptype PTYPE

Override the packet's type. Useful for setting packet type to host when needing to allow ingressing packets with the wrong MAC address but correct IP address. PTYPE is one of: host, otherhost, broadcast, multicast

inheritdsfield

Override the packet classification decision, and any value specified with priority, using the information stored in the Differentiated Services Field of the IPv6/IPv4 header (RFC2474).

## SEE ALSO
tc(8), tc-pedit(8)


tc-skbmod

title: tc-skbmod(8)

text:
# tc-skbmod(8)

## NAME
skbmod - user-friendly packet editor action

## SYNOPSIS

tc ... action skbmod { [ set SETTABLE ] [ swap SWAPPABLE ] [ CONTROL ] [ index INDEX ] }

SETTABLE := [ dmac DMAC ] [ smac SMAC ] [ etype ETYPE ]

SWAPPABLE := mac CONTROL := { reclassify | pipe | drop | shot | continue | pass }

## DESCRIPTION
The skbmod action is intended as a usability upgrade to the existing pedit action. Instead of having to manually edit 8-, 16-, or 32-bit chunks of an ethernet header, skbmod allows complete substitution of supported elements.

## OPTIONS
dmac DMAC

Change the destination mac to the specified address.

smac SMAC

Change the source mac to the specified address.

etype ETYPE

Change the ethertype to the specified value.

mac

Used to swap mac addresses. The swap mac directive is performed after any outstanding D/SMAC changes.

CONTROL

The following keywords allow to control how the tree of qdisc, classes, filters and actions is further traversed after this action.

reclassify

Restart with the first filter in the current list.

pipe

Continue with the next action attached to the same filter.

drop

shot

Drop the packet.

continue

Continue classification with the next filter in line.

pass

Finish classification process and return to calling qdisc for further packet processing. This is the default.

## EXAMPLES
To start, observe the following filter with a pedit action:

```
tc filter add dev eth1 parent 1: protocol ip prio 10 \
	u32 match ip protocol 1 0xff flowid 1:2 \
	action pedit munge offset -14 u8 set 0x02 \
	munge offset -13 u8 set 0x15 \
	munge offset -12 u8 set 0x15 \
	munge offset -11 u8 set 0x15 \
	munge offset -10 u16 set 0x1515 \
	pipe
```

Using the skbmod action, this command can be simplified to:

```
tc filter add dev eth1 parent 1: protocol ip prio 10 \
	u32 match ip protocol 1 0xff flowid 1:2 \
	action skbmod set dmac 02:15:15:15:15:15 \
	pipe
```

Complexity will increase if source mac and ethertype are also being edited as part of the action. If all three fields are to be changed with skbmod:

```
tc filter add dev eth5 parent 1: protocol ip prio 10 \
	u32 match ip protocol 1 0xff flowid 1:2 \
	action skbmod \
	set etype 0xBEEF \
	set dmac 02:12:13:14:15:16 \
	set smac 02:22:23:24:25:26
```

Finally, swap the destination and source mac addresses in the header:

```
tc filter add dev eth3 parent 1: protocol ip prio 10 \
	u32 match ip protocol 1 0xff flowid 1:2 \
	action skbmod \
	swap mac
```

As mentioned above, the swap action will occur after any smac/dmac substitutions are executed, if they are present.

## SEE ALSO
tc(8), tc-u32(8), tc-pedit(8)


tc-skbprio

title: tc-skbprio(8)

summary: SKB Priority Queue

text:
# tc-skbprio(8)

## NAME
skbprio - SKB Priority Queue

## SYNOPSIS
tc qdisc ... add skbprio [ limit packets ]

## DESCRIPTION
SKB Priority Queue is a queueing discipline intended to prioritize the most important packets during a denial-of-service ( DoS ) attack. The priority of a packet is given by skb->priority , where a higher value places the packet closer to the exit of the queue. When the queue is full, the lowest priority packet in the queue is dropped to make room for the packet to be added if it has higher priority. If the packet to be added has lower priority than all packets in the queue, it is dropped.

Without SKB priority queue, queue length limits must be imposed on individual sub-queues, and there is no straightforward way to enforce a global queue length limit across all priorities. SKBprio queue enforces a global queue length limit while not restricting the lengths of individual sub-queues.

While SKB Priority Queue is agnostic to how skb->priority is assigned. A typical use case is to copy the 6-bit DS field of IPv4 and IPv6 packets using tc-skbedit(8). If skb->priority is greater or equal to 64, the priority is assumed to be 63. Priorities less than 64 are taken at face value.

SKB Priority Queue enables routers to locally decide which packets to drop under a DoS attack. Priorities should be assigned to packets such that the higher the priority, the more expected behavior a source shows. So sources have an incentive to play by the rules.

## ALGORITHM
Skbprio maintains 64 lists (priorities go from 0 to 63). When a packet is enqueued, it gets inserted at the tail of its priority list. When a packet needs to be sent out to the network, it is taken from the head of the highest priority list. When the queue is full, the packet at the tail of the lowest priority list is dropped to serve the ingress packet - if it is of higher priority, otherwise the ingress packet is dropped. This algorithm allocates as much bandwidth as possible to high priority packets, while only servicing low priority packets when there is enough bandwidth.

## PARAMETERS
limit

Maximum queue size specified in packets. It defaults to 64. The range for this parameter is [0, UINT32_MAX].

## SEE ALSO
tc-prio(8), tc-skbedit(8)

## AUTHORS
Nishanth Devarajan <devarajn@uci.edu>, Michel Machado <michel@digirati.com.br>

This manpage maintained by Bert Hubert <ahu@ds9a.nl>


tc-stab

title: tc-stab(8)

summary: Generic size table manipulations

text:
# tc-stab(8)

## NAME
tc-stab - Generic size table manipulations

## SYNOPSIS

```
tc qdisc add ... stab
```

```
[ mtu BYTES ] [ tsize SLOTS ]
[ mpu BYTES ] [ overhead BYTES ]
[ linklayer { adsl | atm | ethernet } ] ...
```

```

```

## OPTIONS
For the description of BYTES - please refer to the UNITS section of tc(8).

mtu

maximum packet size we create size table for, assumed 2048 if not specified explicitly

tsize

required table size, assumed 512 if not specified explicitly

mpu

minimum packet size used in computations

overhead

per-packet size overhead (can be negative) used in computations

linklayer

required linklayer specification.

## DESCRIPTION
Size tables allow manipulation of packet sizes, as seen by the whole scheduler framework (of course, the actual packet size remains the same). Adjusted packet size is calculated only once - when a qdisc enqueues the packet. Initial root enqueue initializes it to the real packet's size.

Each qdisc can use a different size table, but the adjusted size is stored in an area shared by whole qdisc hierarchy attached to the interface. The effect is that if you have such a setup, the last qdisc with a stab in a chain "wins". For example, consider HFSC with simple pfifo attached to one of its leaf classes. If that pfifo qdisc has stab defined, it will override lengths calculated during HFSC's enqueue; and in turn, whenever HFSC tries to dequeue a packet, it will use a potentially invalid size in its calculations. Normal setups will usually include stab defined only on root qdisc, but further overriding gives extra flexibility for less usual setups.

The initial size table is calculated by tc tool using mtu and tsize parameters. The algorithm sets each slot's size to the smallest power of 2 value, so the whole mtu is covered by the size table. Neither tsize, nor mtu have to be power of 2 value, so the size table will usually support more than is required by mtu.

For example, with mtu = 1500 and tsize = 128, a table with 128 slots will be created, where slot 0 will correspond to sizes 0-16, slot 1 to 17 - 32, ..., slot 127 to 2033 - 2048. Sizes assigned to each slot depend on linklayer parameter.

Stab calculation is also safe for an unusual case, when a size assigned to a slot would be larger than 2^16-1 (you will lose the accuracy though).

During the kernel part of packet size adjustment, overhead will be added to original size, and then slot will be calculated. If the size would cause overflow, more than 1 slot will be used to get the final size. This of course will affect accuracy, but it's only a guard against unusual situations.

Currently there are two methods of creating values stored in the size table - ethernet and atm (adsl):

ethernet

This is basically 1-1 mapping, so following our example from above (disregarding mpu for a moment) slot 0 would have 8, slot 1 would have 16 and so on, up to slot 127 with 2048. Note, that mpu > 0 must be specified, and slots that would get less than specified by mpu will get mpu instead. If you don't specify mpu, the size table will not be created at all (it wouldn't make any difference), although any overhead value will be respected during calculations.

atm, adsl

ATM linklayer consists of 53 byte cells, where each of them provides 48 bytes for payload. Also all the cells must be fully utilized, thus the last one is padded if/as necessary. When the size table is calculated, adjusted size that fits properly into lowest amount of cells is assigned to a slot. For example, a 100 byte long packet requires three 48-byte payloads, so the final size would require 3 ATM cells - 159 bytes.

For ATM size tables, 16 bytes sized slots are perfectly enough. The default values of mtu and tsize create 4 bytes sized slots.

## TYPICAL OVERHEADS
The following values are typical for different adsl scenarios (based on [1] and [2]):

```
LLC based:
```

```
PPPoA - 14 (PPP - 2, ATM - 12)
PPPoE - 40+ (PPPoE - 8, ATM - 18, ethernet 14, possibly FCS - 4+padding)
Bridged - 32 (ATM - 18, ethernet 14, possibly FCS - 4+padding)
IPoA - 16 (ATM - 16)
```

```
VC Mux based:
```

```
PPPoA - 10 (PPP - 2, ATM - 8)
PPPoE - 32+ (PPPoE - 8, ATM - 10, ethernet 14, possibly FCS - 4+padding)
Bridged - 24+ (ATM - 10, ethernet 14, possibly FCS - 4+padding)
IPoA - 8 (ATM - 8)
```

```

```

There are a few important things regarding the above overheads:

- IPoA in LLC case requires SNAP, instead of LLC-NLPID (see rfc2684) - this is the reason why it actually takes more space than PPPoA.

- In rare cases, FCS might be preserved on protocols that include Ethernet frames (Bridged and PPPoE). In such situation, any Ethernet specific padding guaranteeing 64 bytes long frame size has to be included as well (see RFC2684). In the other words, it also guarantees that any packet you send will take minimum 2 atm cells. You should set mpu accordingly for that.

- When the size table is consulted, and you're shaping traffic for the sake of another modem/router, an Ethernet header (without padding) will already be added to initial packet's length. You should compensate for that by subtracting 14 from the above overheads in this case. If you're shaping directly on the router (for example, with speedtouch usb modem) using ppp daemon, you're using raw ip interface without underlying layer2, so nothing will be added. For more thorough explanations, please see [1] and [2].

## ETHERNET CARDS CONSIDERATIONS
It's often forgotten that modern network cards (even cheap ones on desktop motherboards) and/or their drivers often support different offloading mechanisms. In the context of traffic shaping, 'tso' and 'gso' might cause undesirable effects, due to massive TCP segments being considered during traffic shaping (including stab calculations). For slow uplink interfaces, it's good to use ethtool to turn off offloading features.

## SEE ALSO
tc(8), tc-hfsc(7), tc-hfsc(8),

[1] http://ace-host.stuart.id.au/russell/files/tc/tc-atm/

[2] http://www.faqs.org/rfcs/rfc2684.html

Please direct bugreports and patches to: <netdev@vger.kernel.org>

## AUTHOR
Manpage created by Michal Soltys (soltys@ziu.info)