Policing action in tc(8) | Linux | Policing action in tc(8) |
police - policing action
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 }
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.
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).
20 Jan 2015 | iproute2 |