Filter Actions

The tc filter framework provides the infrastructure to another extensible set of tools as well, namely tc actions. As the name suggests, they allow to do things with packets (or associated data). (The list of) Actions are part of a given filter. If it matches, each action it contains is executed in order before returning the classification result. Since the action has direct access to the latter, it is in theory possible for an action to react upon or even change the filtering result - as long as the packet matched, of course. Yet none of the currently in-tree actions make use of this.

The Generic Actions framework originally evolved out of the filters' ability to police traffic to a given maximum bandwidth. One common use case for that is to limit ingress traffic, dropping packets which exceed the threshold. A classic setup example is like so:

# 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

The ingress qdisc is not a real one, but merely a point of reference for filters to attach to which should get applied to incoming traffic. The u32 filter added above matches on any packet and therefore limits the total incoming bandwidth to 1mbit/s, allowing bursts of up to 100kbytes. Using the new syntax, the filter command changes slightly:

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

The important detail is that this syntax allows to define multiple actions. E.g. for testing purposes, it is possible to redirect exceeding traffic to the loopback interface instead of dropping it:

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

The added parameter conform-exceed pipe tells the police action to allow for further actions to handle the exceeding packet.

Apart from police and mirred actions, there are a few more. Here's a full list of the currently implemented ones:

bpf

Apply a Berkeley Packet Filter program to the packet.

connmark

Set the packet's firewall mark to that of it's connection. This works by searching the conntrack table for a matching entry. If found, the mark is restored.

csum

Trigger recalculation of packet checksums. The supported protocols are: IPv4, ICMP, IGMP, TCP, UDP and UDPLite.

ipt

Pass the packet to an iptables target. This allows to use iptables extensions directly instead of having to go the extra mile via setting an arbitrary firewall mark and matching on that from within netfilter.

mirred

Mirror or redirect packets. This is often combined with the ifb pseudo device to share a common QoS setup between multiple interfaces or even ingress traffic.

nat

Perform stateless Native Address Translation. This is certainly not complete and therefore inferior to NAT using iptables: Although the kernel module decides between TCP, UDP and ICMP traffic, it does not handle typical problematic protocols such as active FTP or SIP.

pedit

Generic packet editing. This allows to alter arbitrary bytes of the packet, either by specifying an offset into the packet or by naming a packet header and field name to change. Currently, the latter is implemented only for IPv4 yet.

police

Apply a bandwidth rate limiting policy. Packets exceeding it are dropped by default, but may optionally be handled differently.

simple

This is rather an example than real action. All it does is print a user-defined string together with a packet counter. Useful maybe for debugging when filter statistics are not available or too complicated.

skbedit

Edit associated packet data, supports changing queue mapping, priority field and firewall mark value.

vlan

Add/remove a VLAN header to/from the packet. This might serve as alternative to using 802.1Q pseudo-interfaces in combination with routing rules when e.g. packets for a given destination need to be encapsulated.