12.3. Policing filters
To make even more complicated setups possible, you can have filters that
only match up to a certain bandwidth. You can declare a filter to entirely
cease matching above a certain rate, or only to not match only the bandwidth
exceeding a certain rate.
So if you decided to police at 4mbit/s, but 5mbit/s of traffic is present,
you can stop matching either the entire 5mbit/s, or only not match 1mbit/s,
and do send 4mbit/s to the configured class.
If bandwidth exceeds the configured rate, you can drop a packet, reclassify
it, or see if another filter will match it.
12.3.1. Ways to police
There are basically two ways to police. If you compiled the kernel
with 'Estimators', the kernel can measure for each filter how much traffic
it is passing, more or less. These estimators are very easy on the CPU, as
they simply count 25 times per second how many data has been passed, and
calculate the bitrate from that.
The other way works again via a Token Bucket Filter, this time living within
your filter. The TBF only matches traffic UP TO your configured bandwidth,
if more is offered, only the excess is subject to the configured overlimit
action.
12.3.1.1. With the kernel estimator
This is very simple and has only one parameter: avrate. Either the flow
remains below avrate, and the filter classifies the traffic to the classid
configured, or your rate exceeds it in which case the specified action is
taken, which is 'reclassify' by default.
The kernel uses an Exponential Weighted Moving Average for your bandwidth
which makes it less sensitive to short bursts.
12.3.1.2. With Token Bucket Filter
Uses the following parameters:
buffer/maxburst
mtu/minburst
mpu
rate
Which behave mostly identical to those described in the Token Bucket Filter
section. Please note however that if you set the mtu of a TBF policer too
low, *no* packets will pass, whereas the egress TBF qdisc will just pass
them slower.
Another difference is that a policer can only let a packet pass, or drop it.
It cannot delay hold on to it in order to delay it.
12.3.2. Overlimit actions
If your filter decides that it is overlimit, it can take 'actions'.
Currently, three actions are available:
- continue
Causes this filter not to match, but perhaps other filters will.
- drop
This is a very fierce option which simply discards traffic exceeding a
certain rate. It is often used in the ingress policer and has limited uses.
For example, you may have a name server that falls over if offered more than
5mbit/s of packets, in which case an ingress filter could be used to make
sure no more is ever offered.
- Pass/OK
Pass on traffic ok. Might be used to disable a complicated filter, but leave
it in place.
- reclassify
Most often comes down to reclassification to Best Effort. This is the
default action.
12.3.3. Examples
The only real example known is mentioned in the 'Protecting your host
from SYN floods' section.
FIXME: if you have used this, please share your experience with us
