Linux Solutions

Welcome to the tutorial guide. The guide will provide a user with advise and guidance on how to police the filters.

If a user wants to police at 4mbit/s, but 5mbit/s of traffic is present, then he or she 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, then a user can drop a packet, reclassify it, or see if another filter will match it.
There are two different ways to police the filter. For example, if a user 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 for policing the filter is through a Token Bucket Filter, this time living within his/her filter. Please note that the TBF only matches traffic up to a users configured bandwidth, if more is offered, only the excess is subject to the configured overlimit action.
Policing with 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 a users 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 the bandwidth which makes it less sensitive to short bursts.
Policing with Token Bucket Filter
A user has a choice to use the following parameters:
• burst/buffer/maxburst
• mtu/minburst
• mpu
• rate
A user should be aware that if he/she sets the mtu of a TBF policer too low then no packets will pass, whereas the egress TBF qdisc will just pass them slower.

Overlimit actions
If a users filter decides that it is overlimit, it can take actions. Currently, four 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.
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.
Please have a look at this example:
Limit incoming icmp traffic to 2kbit, drop packets over the limit:
tc filter add dev $DEV parent ffff: \
protocol ip prio 20 \
u32 match ip protocol 1 0xff \
police rate 2kbit buffer 10k drop \
flowid :1
Limit packets to a certain size (i.e. all packets with a length greater than 84 bytes will get dropped):
tc filter add dev $DEV parent ffff: \
protocol ip prio 20 \
u32 match tos 0 0 \
police mtu 84 drop \
flowid :1
This method can be used to drop all packets:
tc filter add dev $DEV parent ffff: \
protocol ip prio 20 \
u32 match ip protocol 1 0xff \
police mtu 1 drop \
flowid :1
It actually drops icmp packets greater-than 1 byte. While packets with a size of 1 byte are possible in theory, a user will not find these in a real network.
If you followed this tutorial guide then you would have learnt about policing the filters.