| Made possible by PowerDNS | ||
|---|---|---|
| Prev | Chapter 12. Advanced filters for (re-)classifying packets | Next |
To make even more complicated setups possible, you can have filters that only match up to a certain bandwidth. You can declare a filter either to entirely cease matching above a certain rate, or not to 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.
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.
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.
Uses the following parameters:
burst/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 hold it in order to delay it.
If your filter decides that it is overlimit, it can take 'actions'. Currently, four actions are available:
Causes this filter not to match, but perhaps other filters will.
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 on traffic ok. Might be used to disable a complicated filter, but leave it in place.
Most often comes down to reclassification to Best Effort. This is the default action.
The only real example known is mentioned in the 'Protecting your host from SYN floods' section.
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 :1Limit 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, you will not find these in a real network.