tc-mirred

title: tc-mirred(8)

text:
# tc-mirred(8)

## NAME
mirred - mirror/redirect action

## SYNOPSIS

tc ... action mirred DIRECTION ACTION [ index INDEX ] TARGET

DIRECTION := { ingress | egress }

TARGET := { DEV | BLOCK }

DEV := dev DEVICENAME

BLOCK := blockid BLOCKID

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. When mirroring to a tc block, the packet will be mirrored to all the ports in the block with exception of the port where the packet ingressed, if that port is part of the tc block. Redirecting is similar to mirroring except that the behaviour is to mirror to the first N - 1 ports in the block and redirect to the last one (note that the port in which the packet arrived is not going to be mirrored or redirected to).

## 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 or block.

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.

blockid BLOCKID

Specify the tc block 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: clsact
# tc filter add dev eth0 ingress 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: clsact
# tc filter add dev eth0 ingress 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: clsact
# tc filter add dev eth0 ingress u32 \
	match u32 0 0 \
	action mirred egress redirect dev ifb0
```

## LIMITATIONS
The kernel restricts nesting to four levels to avoid the chance of nesting loops.

Do not redirect for one IFB device to another. IFB is a very specialized case of packet redirecting device. Redirecting from ifbX->ifbY will cause all packets to be dropped.

## 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)

branch: sisyphus


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 ... ] [ fp FP0 FP1 FP2 ... ]

## 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. You cannot have more classes than queues

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. The default value of this parameter is 1

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. Supported only when the 'shaper' argument is set to 'bw_rlimit'.

max_rate

Maximum value of bandwidth rate limit for a traffic class. Supported only when the 'shaper' argument is set to 'bw_rlimit'.

fp

Selects whether traffic classes are express (deliver packets via the eMAC) or preemptible (deliver packets via the pMAC), according to IEEE 802.1Q-2018 clause 6.7.2 Frame preemption. Takes the form of an array (one element per traffic class) with values being 'E' (for express) or 'P' (for preemptible). Multiple priorities which map to the same traffic class, as well as multiple TXQs which map to the same traffic class, must have the same FP attributes. To interpret the FP as an attribute per priority, the 'map' argument can be used for translation. To interpret FP as an attribute per TXQ, the 'queues' argument can be used for translation.

Traffic classes are express by default. The argument is supported only with 'hw' set to 1. Preemptible traffic classes are accepted only if the device has a MAC Merge layer configurable through ethtool(8).

## SEE ALSO
ethtool(8)

## EXAMPLE
The following example shows how to attach priorities to 4 traffic classes ("num_tc 4"), and then how to pair these traffic classes with 4 hardware queues with mqprio, with hardware coordination ("hw 1", or does not specified, because 1 is the default value). Traffic class 0 (tc0) is mapped to hardware queue 0 (q0), tc1 is mapped to q1, tc2 is mapped to q2, and tc3 is mapped q3.

```
# tc qdisc add dev eth0 root mqprio               num_tc 4               map 0 0 0 0 1 1 1 1 2 2 2 2 3 3 3 3               queues 1@0 1@1 1@2 1@3               hw 1
```

The next example shows how to attach priorities to 3 traffic classes ("num_tc 3"), and how to pair these traffic classes with 4 queues, without hardware coordination ("hw 0"). Traffic class 0 (tc0) is mapped to hardware queue 0 (q0), tc1 is mapped to q1, tc2 and is mapped to q2 and q3, where the queue selection between these two queues is somewhat randomly decided.

```
# tc qdisc add dev eth0 root mqprio               num_tc 3               map 0 0 0 0 1 1 1 1 2 2 2 2 2 2 2 2               queues 1@0 1@1 2@2               hw 0
```

In both cases from above the priority values from 0 to 3 (prio0-3) are mapped to tc0, prio4-7 are mapped to tc1, and the prio8-11 are mapped to tc2 ("map" attribute). The last four priority values (prio12-15) are mapped in different ways in the two examples. They are mapped to tc3 in the first example and mapped to tc2 in the second example. The values of these two examples are the following:

┌────┬────┬───────┐ ┌────┬────┬────────┐

│Prio│ tc │ queue │ │Prio│ tc │ queue │

├────┼────┼───────┤ ├────┼────┼────────┤

│ 0 │ 0 │ 0 │ │ 0 │ 0 │ 0 │

│ 1 │ 0 │ 0 │ │ 1 │ 0 │ 0 │

│ 2 │ 0 │ 0 │ │ 2 │ 0 │ 0 │

│ 3 │ 0 │ 0 │ │ 3 │ 0 │ 0 │

│ 4 │ 1 │ 1 │ │ 4 │ 1 │ 1 │

│ 5 │ 1 │ 1 │ │ 5 │ 1 │ 1 │

│ 6 │ 1 │ 1 │ │ 6 │ 1 │ 1 │

│ 7 │ 1 │ 1 │ │ 7 │ 1 │ 1 │

│ 8 │ 2 │ 2 │ │ 8 │ 2 │ 2 or 3 │

│ 9 │ 2 │ 2 │ │ 9 │ 2 │ 2 or 3 │

│ 10 │ 2 │ 2 │ │ 10 │ 2 │ 2 or 3 │

│ 11 │ 2 │ 2 │ │ 11 │ 2 │ 2 or 3 │

│ 12 │ 3 │ 3 │ │ 12 │ 2 │ 2 or 3 │

│ 13 │ 3 │ 3 │ │ 13 │ 2 │ 2 or 3 │

│ 14 │ 3 │ 3 │ │ 14 │ 2 │ 2 or 3 │

│ 15 │ 3 │ 3 │ │ 15 │ 2 │ 2 or 3 │

└────┴────┴───────┘ └────┴────┴────────┘

example1 example2

Another example of queue mapping is the following. There are 5 traffic classes, and there are 8 hardware queues.

```
# tc qdisc add dev eth0 root mqprio               num_tc 5               map 0 0 0 1 1 1 1 2 2 3 3 4 4 4 4 4               queues 1@0 2@1 1@3 1@4 3@5
```

The value mapping is the following for this example:

┌───────┐

tc0────┤Queue 0│◄────1@0

├───────┤

┌─┤Queue 1│◄────2@1

tc1──┤ ├───────┤

└─┤Queue 2│

├───────┤

tc2────┤Queue 3│◄────1@3

├───────┤

tc3────┤Queue 4│◄────1@4

├───────┤

┌─┤Queue 5│◄────3@5

│ ├───────┤

tc4──┼─┤Queue 6│

│ ├───────┤

└─┤Queue 7│

└───────┘

## 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 one 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 ] [ SEED ]

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 ]

SEED := seed VALUE

## DESCRIPTION
The netem queue discipline provides Network Emulation functionality for testing protocols by emulating the properties of real-world networks.

The queue discipline provides one or more network impairments to packets such as: delay, loss, duplication, and packet corruption.

## OPTIONS
limit COUNT

Limits the maximum number of packets the qdisc may hold when doing delay.

delay

TIME [ JITTER [ CORRELATION ]]]

Delays the packets before sending. The optional parameters allow introducing a delay variation and a correlation. Delay and jitter values are expressed in milliseconds; Correlation is set by specifying a percent of how much the previous delay will impact the current random value.

distribution TYPE

Specifies a pattern for delay distribution.

uniform

Use an equally weighted distribution of packet delays.

normal

Use a Gaussian distribution of delays. Sometimes called a Bell Curve.

pareto

Use a Pareto distribution of packet delays. This is useful to emulate long-tail distributions.

paretonormal

This is a mix of pareto and normal distribution which has properties of both Bell curve and long tail.

loss MODEL

Drop packets based on a loss model. MODEL can be one of

random PERCENT

Each packet loss is independent.

state P13 [ P31 [ P32 [ P23 P14 ]]]

Use a 4-state Markov chain to describe packet loss.

P13 is the packet loss. Optional parameters extend the model to 2-state P31, 3-state P23, P32 and 4-state P14. The Markov chain states are:

1

good packet reception (no loss).

2

good reception within a burst.

3

burst losses.

4

independent losses.

gemodel PERCENT [ R [ 1-H [ 1-K ]]]

Use a Gilbert-Elliot (burst loss) model based on:

PERCENT

probability of starting bad (lossy) state.

R

probability of exiting bad state.

1-H

loss probability in bad state.

1-K

loss probability in good state.

ecn

Use Explicit Congestion Notification (ECN) to mark packets instead of dropping them. A loss model has to be used for this to be enabled.

corrupt PERCENT

modifies the contents of the packet at a random position based on PERCENT.

duplicate PERCENT

creates a copy of the packet before queuing.

reorder PERCENT

modifies the order of packet in the queue.

gap DISTANCE

sends some packets immediately. The first packets (DISTANCE - 1) are delayed and the next packet is sent immediately.

rate RATE [ PACKETOVERHEAD [ CELLSIZE [ CELLOVERHEAD ]]]

Delays packets based on packet size to emulate a fixed link speed. Optional parameters:

PACKETOVERHEAD

Specify a per packet overhead in bytes. Used to simulate additional link layer headers. A negative value can be used to simlate when the Ethernet header is stripped (e.g. -14) or header compression is used.

CELLSIZE

simulate link layer schemes like ATM.

CELLOVERHEAD

specify per cell overhead.

Rate throttling impacted by several factors including the kernel clock granularity. This will show up in an artificial packet compression (bursts).

slot MIN_DELAY [ MAX_DELAY ]

allows emulating slotted networks. Defer delivering accumulated packets to within a slot. Each available slot is configured with a minimum delay to acquire, and an optional maximum delay.

slot distribution

allows configuring based on distribution similar to distribution option for packet delays. These slot options can provide a crude approximation of bursty MACs such as DOCSIS, WiFi, and LTE.

Slot emulation 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.

seed VALUE

Specifies a seed to guide and reproduce the randomly generated loss or corruption events.

## LIMITATIONS
Netem is limited by the timer granularity in the kernel. Rate and delay maybe impacted by clock interrupts.

Mixing forms of reordering may lead to unexpected results. For any method of reordering to work, some delay is necessary. If the delay is less than the inter-packet arrival time then no reordering will be seen. Due to mechanisms like TSQ (TCP Small Queues), for TCP performance test results to be realistic netem must be placed on the ingress of the receiver host.

Combining netem with other qdisc is possible but may not always work because netem use skb control block to set delays.

## EXAMPLES

```
# tc qdisc add dev eth0 root netem delay 100ms
```

Add fixed amount of delay to all packets going out on device eth0. Each packet will have added delay of 100ms ± 10ms.

```
# tc qdisc change dev eth0 root netem delay 100ms 10ms 25%
```

This causes the added delay of 100ms ± 10ms and the next packet delay value will be biased by 25% on the most recent delay. This isn't a true statistical correlation, but an approximation.

```
# tc qdisc change dev eth0 root netem delay 100ms 20ms distribution normal
```

This delays packets according to a normal distribution (Bell curve) over a range of 100ms ± 20ms.

```
# tc qdisc change dev eth0 root netem loss 0.1%
```

This causes 1/10th of a percent (i.e 1 out of 1000) packets to be randomly dropped. An optional correlation may also be added. This causes the random number generator to be less random and can be used to emulate packet burst losses.

```
# tc qdisc change dev eth0 root netem duplicate 1%
```

This causes one percent of the packets sent on eth0 to be duplicated.

```
# tc qdisc change dev eth0 root netem loss 0.3% 25%
```

This will cause 0.3% of packets to be lost, and each successive probability depends is biased by 25% of the previous one.

There are two different ways to specify reordering. The gap method uses a fixed sequence and reorders every Nth packet.

```
# tc qdisc change dev eth0 root netem gap 5 delay 10ms
```

This causes every 5th (10th, 15th, …) packet to go to be sent immediately and every other packet to be delayed by 10ms. This is predictable and useful for base protocol testing like reassembly.

The reorder form uses a percentage of the packets to get misordered.

```
# tc qdisc change dev eth0 root netem delay 10ms reorder 25% 50%
```

In this example, 25% of packets (with a correlation of 50%) will get sent immediately, others will be delayed by 10ms.

Packets will also get reordered if jitter is large enough.

```
# tc qdisc change dev eth0 root netem delay 100ms 75ms
```

If the first packet gets a random delay of 100ms (100ms base - 0ms jitter) and the second packet is sent 1ms later and gets a delay of 50ms (100ms base - 50ms jitter); the second packet will be sent first. This is because the queue discipline tfifo inside netem, keeps packets in order by time to send.

If you don't want this behavior then replace the internal queue discipline tfifo with a simple FIFO queue discipline.

```
# tc qdisc add dev eth0 root handle 1: netem delay 10ms 100ms
# tc qdisc add dev eth0 parent 1:1 pfifo limit 1000
```

Example of using rate control and cells size.

```
# 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 bytes.

It is possible to selectively apply impairment using traffic classification.

```
# tc qdisc add dev eth0 root handle 1: prio
# tc qdisc add dev eth0 parent 1:3 handle 30:    tbf rate 20kbit buffer 1600 limit  3000
# tc qdisc add dev eth0 parent 30:1 handle 31:    netem delay 200ms 10ms distribution normal
# tc filter add dev eth0 protocol ip parent 1:0 prio 3 u32    match ip dst 65.172.181.4/32 flowid 1:3
```

This example uses a priority queueing discipline; a TBF is added to do rate control; and a simple netem delay. A filter classifies all packets going to 65.172.181.4 as being priority 3.

## 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.

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)

## AUTHOR
Netem was written by Stephen Hemminger at Linux foundation and was inspired by NISTnet.

Original 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 | decrement | 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/decrement 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 one 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 one 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.

decrement

Decrease the addressed data by one. This operation is supported only for ip ttl and ip6 hoplimit.

preserve

Keep the addressed data as is.

retain RVAL

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

CONTROL

The following keywords allow one 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 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 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 one to set the new action index. When using existing action, this parameter allows one 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 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

```
  $ tc qdisc add dev eth0 ingress

  $ 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"

  $ 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

  $ 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

  $ dmesg | grep simple

  [135354.473951] simple: Incoming ICMP_1

  $ 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 one to change a packet's associated meta data. It complements the pedit action, which in turn allows one 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 | ecn } [ 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. Action must be one of set, swap and ecn. set and swap only affect Ethernet packets, while ecn only affects IP packets.

## 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.

ecn

Used to mark ECN Capable Transport (ECT) IP packets as Congestion Encountered (CE). Does not affect Non ECN-Capable Transport (Non-ECT) packets.

CONTROL

The following keywords allow one 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
```

To swap the destination and source mac addresses in the Ethernet 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
```

Finally, to mark the CE codepoint in the IP header for ECN Capable Transport (ECT) packets:

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

Only one of set, swap and ecn shall be used in a single command. Trying to use more than one of them in a single command is considered undefined behavior; pipe multiple commands together instead.

## 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)


tc-taprio

title: tc-taprio(8)

summary: Time Aware Priority Shaper

text:
# tc-taprio(8)

## NAME
TAPRIO - Time Aware Priority Shaper

## SYNOPSIS
tc qdisc ... dev dev parent classid [ handle major: ] taprio num_tc tcs map P0 P1 P2 ... queues count1@offset1 count2@offset2 ... base-time base-time clockid clockid sched-entry <command 1> <gate mask 1> <interval 1> sched-entry <command 2> <gate mask 2> <interval 2> sched-entry <command 3> <gate mask 3> <interval 3> sched-entry <command N> <gate mask N> <interval N> [ max-sdu <queueMaxSDU[TC 0]> <queueMaxSDU[TC 1]> <queueMaxSDU[TC N]> ] [ fp <adminStatus[TC 0]> <adminStatus[TC 1]> <adminStatus[TC N]> ]

## DESCRIPTION
The TAPRIO qdisc implements a simplified version of the scheduling state machine defined by IEEE 802.1Q-2018 Section 8.6.9, which allows configuration of a sequence of gate states, where each gate state allows outgoing traffic for a subset (potentially empty) of traffic classes.

How traffic is mapped to different hardware queues is similar to mqprio(8) and so the map and queues parameters have the same meaning.

The other parameters specify the schedule, and at what point in time it should start (it can behave as the schedule started in the past).

## 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. See mqprio(8) for more details.

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.

base-time

Specifies the instant in nanoseconds, using the reference of clockid, 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;

clockid

Specifies the clock to be used by qdisc's internal timer for measuring time and scheduling events. This argument must be omitted when using the full-offload feature (flags 0x2), since in that case, the clockid is implicitly /dev/ptpN (where N is given by ethtool -T eth0 | grep 'PTP Hardware Clock' ), and therefore not necessarily synchronized with the system's CLOCK_TAI.

sched-entry

There may multiple sched-entry parameters in a single schedule. Each one has the sched-entry <command> <gatemask> <interval>

format.

<command> support the following values:

S for SetGateStates

H for Set-And-Hold-MAC

R for Set-And-Release-MAC

These commands follow the IEEE 802.1Q-2018 definition (Table 8-7).

<gate mask> is a bitmask where each bit is associated with a traffic class, so bit 0 (the least significant bit) being "on" means that traffic class 0 is "active" for that schedule entry.

<interval> is a time duration, in nanoseconds, that specifies for how long that state defined by <command> and <gate mask> should be held before moving to the next entry.

flags

This is a bit mask which specifies different modes for taprio.

0x1

Enables the txtime-assist feature. In this mode, taprio will set the transmit timestamp depending on the interval in which the packet needs to be transmitted. It will then utililize the etf(8) qdisc to sort and transmit the packets at the right time. The second example can be used as a reference to configure this mode.

0x2

Enables the full-offload feature. In this mode, taprio will pass the gate control list to the NIC which will execute it cyclically in hardware. When using full-offload, there is no need to specify the clockid argument. The txtime-assist and full-offload features are mutually exclusive, i.e. setting flags to 0x3 is invalid.

txtime-delay

This parameter is specific to the txtime offload mode. It specifies the maximum time a packet might take to reach the network card from the taprio qdisc. The value should always be greater than the delta specified in the etf(8) qdisc.

max-sdu

Specifies an array containing at most 16 elements, one per traffic class, which corresponds to the queueMaxSDU table from IEEE 802.1Q-2018. Each array element represents the maximum L2 payload size that can egress that traffic class. Elements that are not filled in default to 0. The value 0 means that the traffic class can send packets up to the port's maximum MTU in size.

fp

Selects whether traffic classes are express or preemptible. See tc-mqprio(8) for details.

## EXAMPLES
The following example shows how an traffic schedule with three traffic classes ("num_tc 3"), which are separated different traffic classes, we are going to call these TC 0, TC 1 and TC 2. We could read the "map" parameter below as: traffic with priority 3 is classified as TC 0, priority 2 is classified as TC 1 and the rest is classified as TC 2.

The schedule will start at instant 1528743495910289987 using the reference CLOCK_TAI. The schedule is composed of three entries each of 300us duration.

```
# tc qdisc replace dev eth0 parent root handle 100 stab overhead 24 taprio \

              num_tc 3 \

              map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 \

              queues 1@0 1@1 2@2 \

              base-time 1528743495910289987 \

              sched-entry S 01 300000 \

              sched-entry S 02 300000 \

              sched-entry S 04 300000 \

              clockid CLOCK_TAI
```

Following is an example to enable the txtime offload mode in taprio. See etf(8) for more information about configuring the ETF qdisc.

```
# tc qdisc replace dev eth0 parent root handle 100 stab overhead 24 taprio \

              num_tc 3 \

              map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 \

              queues 1@0 1@0 1@0 \

              base-time 1528743495910289987 \

              sched-entry S 01 300000 \

              sched-entry S 02 300000 \

              sched-entry S 04 400000 \

              flags 0x1 \

              txtime-delay 200000 \

              clockid CLOCK_TAI
# tc qdisc replace dev $IFACE parent 100:1 etf skip_skb_check \

              offload delta 200000 clockid CLOCK_TAI
```

The following is a schedule in full offload mode. The base-time is 200 ns and the cycle-time is implicitly calculated as the sum of all sched-entry durations (i.e. 20 us + 20 us + 60 us = 100 us). Although the base-time is in the past, the hardware will start executing the schedule at a PTP time equal to the smallest integer multiple of 100 us, plus 200 ns, that is larger than the NIC's current PTP time. In addition, the MTU for traffic class 5 is limited to 200 octets, so that the interference this creates upon traffic class 7 during the time window when their gates are both open is bounded. The interference is determined by the transmit time of the max SDU, plus the L2 header length, plus the L1 overhead (determined from the size table specified using tc-stab(8)).

```
# tc qdisc add dev eth0 parent root stab overhead 24 taprio \

              num_tc 8 \

              map 0 1 2 3 4 5 6 7 \

              queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \

              max-sdu 0 0 0 0 0 200 0 0 \

              base-time 200 \

              sched-entry S 80 20000 \

              sched-entry S a0 20000 \

              sched-entry S 5f 60000 \

              flags 0x2
```

## SEE ALSO
tc-stab(8)

## AUTHORS
Vinicius Costa Gomes <vinicius.gomes@intel.com>