{"id":2780,"date":"2022-12-20T15:17:17","date_gmt":"2022-12-20T18:17:17","guid":{"rendered":"http:\/\/lode.uno\/linux-man\/index.php\/2022\/12\/20\/policing-action-in-tc-man8\/"},"modified":"2022-12-20T15:17:17","modified_gmt":"2022-12-20T18:17:17","slug":"policing-action-in-tc-man8","status":"publish","type":"post","link":"https:\/\/lode.uno\/linux-man\/2022\/12\/20\/policing-action-in-tc-man8\/","title":{"rendered":"Policing action in tc (man8)"},"content":{"rendered":"

Policing action in tc<\/h1>\n

NAME<\/a>
SYNOPSIS<\/a>
DESCRIPTION<\/a>
OPTIONS<\/a>
EXAMPLES<\/a>
SEE ALSO<\/a> <\/p>\n

\n

NAME <\/a> <\/h2>\n

police – policing action<\/p>\n

SYNOPSIS <\/a> <\/h2>\n

tc<\/b> … action police [ rate<\/b> RATE<\/i> burst<\/b> BYTES<\/i>[\/<\/b>BYTES<\/i>] ] [ pkts_rate<\/b> RATE<\/i> pkts_burst<\/b> PACKETS<\/i>] [ mtu<\/b> BYTES<\/i>[\/<\/b>BYTES<\/i>] ] [ peakrate<\/b> RATE<\/i> ] [ overhead<\/b> BYTES<\/i> ] [ linklayer<\/b> TYPE<\/i> ] [ CONTROL<\/i> ]<\/p>\n

tc<\/b> … filter<\/b> … [ estimator<\/b> SAMPLE AVERAGE<\/i> ] action police avrate<\/b> RATE<\/i> [ CONTROL<\/i> ]<\/p>\n

CONTROL<\/i> := conform-exceed<\/b> EXCEEDACT<\/i>[\/<\/b>NOTEXCEEDACT<\/i><\/p>\n

EXCEEDACT\/NOTEXCEEDACT<\/i> := { pipe<\/b> | ok<\/b> | reclassify<\/b> | drop<\/b> | continue<\/b> | goto chain CHAIN_INDEX<\/b> }<\/p>\n

DESCRIPTION <\/a> <\/h2>\n

The police<\/b> action allows limiting of the byte or packet rate of traffic matched by the filter it is attached to.<\/p>\n

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<\/b>, burst<\/b>, mtu<\/b>, peakrate<\/b>, overhead<\/b> and linklayer<\/b> parameters. The second one uses an in-kernel sampling mechanism. It can be fine-tuned using the estimator<\/b> filter parameter.<\/p>\n

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<\/b> and pkt_burst<\/b> parameters.<\/p>\n

At least one of the rate<\/b> and pkt_rate<\/b> parameters must be configured.<\/p>\n

OPTIONS <\/a> <\/h2>\n

rate<\/b> RATE<\/i><\/p>\n

The maximum byte rate of packets passing this action. Those exceeding it will be treated as defined by the conform-exceed<\/b> option.<\/p>\n

burst<\/b> BYTES<\/i>[\/<\/b>BYTES<\/i>]<\/p>\n

Set the maximum allowed burst in bytes, optionally followed by a slash (\u2019\/\u2019) sign and cell size which must be a power of 2.<\/p>\n

pkt_rate<\/b> RATE<\/i><\/p>\n

The maximum packet rate or packets passing this action. Those exceeding it will be treated as defined by the conform-exceed<\/b> option.<\/p>\n

pkt_burst<\/b> PACKETS<\/i><\/p>\n

Set the maximum allowed burst in packets.<\/p>\n

mtu<\/b> BYTES<\/i>[\/<\/b>BYTES<\/i>]<\/p>\n

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\u2019s precision. Value formatting is identical to burst<\/b> above. Defaults to unlimited.<\/p>\n

peakrate<\/b> RATE<\/i><\/p>\n

Set the maximum bucket depletion rate, exceeding rate<\/b>.<\/p>\n

avrate<\/b> RATE<\/i><\/p>\n

Make use of an in-kernel bandwidth rate estimator and match the given RATE<\/i> against it.<\/p>\n

overhead<\/b> BYTES<\/i><\/p>\n

Account for protocol overhead of encapsulating output devices when computing rate<\/b> and peakrate<\/b>.<\/p>\n

linklayer<\/b> TYPE<\/i><\/p>\n

Specify the link layer type. TYPE<\/i> may be one of ethernet<\/b> (the default), atm<\/b> or adsl<\/b> (which are synonyms). It is used to align the precomputed rate tables to ATM cell sizes, for ethernet<\/b> no action is taken.<\/p>\n

estimator<\/b> SAMPLE AVERAGE<\/i><\/p>\n

Fine-tune the in-kernel packet rate estimator. SAMPLE<\/i> and AVERAGE<\/i> are time values and control the frequency in which samples are taken and over what timespan an average is built.<\/p>\n

conform-exceed<\/b> EXCEEDACT<\/i>[\/<\/b>NOTEXCEEDACT<\/i>]<\/p>\n

Define how to handle packets which exceed or conform the configured bandwidth limit. Possible values are:
continue<\/p>\n

Don\u2019t do anything, just continue with the next action in line.<\/p>\n\n\n\n\n\n
<\/td>\n\n

drop<\/p>\n<\/td>\n

<\/td>\n\n

Drop the packet immediately.<\/p>\n<\/td>\n<\/tr>\n

<\/td>\n\n

shot<\/p>\n<\/td>\n

<\/td>\n\n

This is a synonym to drop<\/b>.<\/p>\n<\/td>\n<\/tr>\n

<\/td>\n\n

ok<\/p>\n<\/td>\n

<\/td>\n\n

Accept the packet. This is the default for conforming packets.<\/p>\n<\/td>\n<\/tr>\n

<\/td>\n\n

pass<\/p>\n<\/td>\n

<\/td>\n\n

This is a synonym to ok<\/b>.<\/p>\n<\/td>\n<\/tr>\n<\/table>\n

reclassify<\/p>\n

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 packets.<\/p>\n\n\n
<\/td>\n\n

pipe<\/p>\n<\/td>\n

<\/td>\n\n

Pass the packet to the next action in line.<\/p>\n<\/td>\n

 <\/td>\n<\/tr>\n<\/table>\n

EXAMPLES <\/a> <\/h2>\n

A typical application of the police action is to enforce ingress traffic rate by dropping exceeding packets. Although better done on the sender\u2019s 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<\/b> qdisc and u32<\/b> filter:<\/p>\n

# tc qdisc add dev eth0 handle ffff: ingress
# tc filter add dev eth0 parent ffff: u32 <\/p>\n\n\n\n
<\/td>\n\n

match u32 0 0 <\/p>\n<\/td>\n<\/tr>\n

<\/td>\n\n

police rate 1mbit burst 100k<\/p>\n<\/td>\n<\/tr>\n<\/table>\n

As an action can not live on it\u2019s own, there always has to be a filter involved as link between qdisc and action. The example above uses u32<\/b> for that, which is configured to effectively match any packet (passing it to the police<\/b> action thereby).<\/p>\n

SEE ALSO <\/a> <\/h2>\n

tc<\/b>(8)<\/p>\n

\n","protected":false},"excerpt":{"rendered":"

police – policing action <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[5,52,4,134],"class_list":["post-2780","post","type-post","status-publish","format-standard","hentry","category-8-administracion-del-sistema","tag-5","tag-administracion","tag-man8","tag-tc-police"],"gutentor_comment":0,"_links":{"self":[{"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/posts\/2780","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/comments?post=2780"}],"version-history":[{"count":0,"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/posts\/2780\/revisions"}],"wp:attachment":[{"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/media?parent=2780"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/categories?post=2780"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/tags?post=2780"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}