The police action allows to limit bandwidth of traffic matched by the
filter it is attached to. Basically there are two different
algorithms available to measure the packet 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.
The maximum traffic rate of packets passing this action. Those
exceeding it will be treated as defined by the conform-exceed
Set the maximum allowed burst in bytes, optionally followed by
a slash ('/') sign and cell size which must be a power of 2.
This is the maximum packet size handled by the policer (larger
ones will be handled like they exceeded the configured rate).
Setting this value correctly will improve the scheduler's
precision. Value formatting is identical to burst above.
Defaults to unlimited.
Set the maximum bucket depletion rate, exceeding rate.
Make use of an in-kernel bandwidth rate estimator and match
the given RATE against it.
Account for protocol overhead of encapsulating output devices
when computing rate and peakrate.
Specify the link layer type. TYPE may be one of ethernet (the
default), atm or adsl (which are synonyms). It is used to
align the precomputed rate tables to ATM cell sizes, for
ethernet no action is taken.
estimator SAMPLE AVERAGE
Fine-tune the in-kernel packet rate estimator. SAMPLE and
AVERAGE are time values and control the frequency in which
samples are taken and over what timespan an average is built.
Define how to handle packets which exceed or conform the
configured bandwidth limit. Possible values are:
Don't do anything, just continue with the next action
drop Drop the packet immediately.
shot This is a synonym to drop.
ok Accept the packet. This is the default for conforming
pass This is a synonym to ok.
Treat the packet as non-matching to the filter this
action is attached to and continue with the next filter
in line (if any). This is the default for exceeding
pipe Pass the packet to the next action in line.
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 fil‐
ter 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).
This page is part of the iproute2 (utilities for controlling TCP/IP
networking and traffic) project. Information about the project can
be found at
If you have a bug report for this manual page, send it to
email@example.com, firstname.lastname@example.org. This page was obtained
from the project's upstream Git repository
on 2017-03-13. If you discover any rendering problems in this HTML
version of the page, or you believe there is a better or more up-to-
date source for the page, or you have corrections or improvements to
the information in this COLOPHON (which is not part of the original
manual page), send a mail to email@example.com
iproute2 20 Jan 2015 Policing action in tc(8)