{ "content": [ { "type": "text", "text": "# tc-police(8) (man)\n\n**Summary:** police - policing action\n\n**Synopsis:** tc ... action police [ rate RATE burst BYTES[/BYTES] ] [ pktsrate RATE pktsburst PACKETS] [\nmtu BYTES[/BYTES] ] [ peakrate RATE ] [ overhead BYTES ] [ linklayer TYPE ] [ CONTROL\n]\ntc ... filter ... [ estimator SAMPLE AVERAGE ] action police avrate RATE [ CONTROL ]\nCONTROL := conform-exceed EXCEEDACT[/NOTEXCEEDACT\nEXCEEDACT/NOTEXCEEDACT := { pipe | ok | reclassify | drop | continue | goto chain CHAININDEX\n}\n\n## Examples\n\n- `A typical application of the police action is to enforce ingress traffic rate by dropping ex‐`\n- `ceeding packets. Although better done on the sender's side, especially in scenarios with lack`\n- `of peer control (e.g. with dial-up providers) this is often the best one can do in order to`\n- `keep latencies low under high load. The following establishes input bandwidth policing to`\n- `1mbit/s using the ingress qdisc and u32 filter:`\n- `# tc qdisc add dev eth0 handle ffff: ingress`\n- `# tc filter add dev eth0 parent ffff: u32 \\`\n- `match u32 0 0 \\`\n- `police rate 1mbit burst 100k`\n- `As an action can not live on it's own, there always has to be a filter involved as link be‐`\n- `tween qdisc and action. The example above uses u32 for that, which is configured to effec‐`\n- `tively match any packet (passing it to the police action thereby).`\n\n## See Also\n\n- tc(8)\n- tc(8)\n\n## Section Outline\n\n- **NAME** (2 lines)\n- **SYNOPSIS** (11 lines)\n- **DESCRIPTION** (13 lines)\n- **OPTIONS** (63 lines)\n- **EXAMPLES** (16 lines)\n- **SEE ALSO** (5 lines)\n\n## Full Content\n\n### NAME\n\npolice - policing action\n\n### SYNOPSIS\n\ntc ... action police [ rate RATE burst BYTES[/BYTES] ] [ pktsrate RATE pktsburst PACKETS] [\nmtu BYTES[/BYTES] ] [ peakrate RATE ] [ overhead BYTES ] [ linklayer TYPE ] [ CONTROL\n]\n\ntc ... filter ... [ estimator SAMPLE AVERAGE ] action police avrate RATE [ CONTROL ]\n\nCONTROL := conform-exceed EXCEEDACT[/NOTEXCEEDACT\n\nEXCEEDACT/NOTEXCEEDACT := { pipe | ok | reclassify | drop | continue | goto chain CHAININDEX\n}\n\n### DESCRIPTION\n\nThe police action allows limiting of the byte or packet rate of traffic matched by the filter\nit is attached to.\n\nThere are two different algorithms available to measure the byte rate: The first one uses an\ninternal dual token bucket and is configured using the rate, burst, mtu, peakrate, overhead\nand linklayer parameters. The second one uses an in-kernel sampling mechanism. It can be\nfine-tuned using the estimator filter parameter.\n\nThere is one algorithm available to measure packet rate and it is similar to the first algo‐\nrithm described for byte rate. It is configured using the pktrate and pktburst parameters.\n\nAt least one of the rate and pktrate parameters must be configured.\n\n### OPTIONS\n\nrate RATE\nThe maximum byte rate of packets passing this action. Those exceeding it will be\ntreated as defined by the conform-exceed option.\n\nburst BYTES[/BYTES]\nSet the maximum allowed burst in bytes, optionally followed by a slash ('/') sign and\ncell size which must be a power of 2.\n\npktrate RATE\nThe maximum packet rate or packets passing this action. Those exceeding it will be\ntreated as defined by the conform-exceed option.\n\npktburst PACKETS\nSet the maximum allowed burst in packets.\n\nmtu BYTES[/BYTES]\nThis is the maximum packet size handled by the policer (larger ones will be handled\nlike they exceeded the configured rate). Setting this value correctly will improve the\nscheduler's precision. Value formatting is identical to burst above. Defaults to un‐\nlimited.\n\npeakrate RATE\nSet the maximum bucket depletion rate, exceeding rate.\n\navrate RATE\nMake use of an in-kernel bandwidth rate estimator and match the given RATE against it.\n\noverhead BYTES\nAccount for protocol overhead of encapsulating output devices when computing rate and\npeakrate.\n\nlinklayer TYPE\nSpecify the link layer type. TYPE may be one of ethernet (the default), atm or adsl\n(which are synonyms). It is used to align the precomputed rate tables to ATM cell\nsizes, for ethernet no action is taken.\n\nestimator SAMPLE AVERAGE\nFine-tune the in-kernel packet rate estimator. SAMPLE and AVERAGE are time values and\ncontrol the frequency in which samples are taken and over what timespan an average is\nbuilt.\n\nconform-exceed EXCEEDACT[/NOTEXCEEDACT]\nDefine how to handle packets which exceed or conform the configured bandwidth limit.\nPossible values are:\n\ncontinue\nDon't do anything, just continue with the next action in line.\n\ndrop Drop the packet immediately.\n\nshot This is a synonym to drop.\n\nok Accept the packet. This is the default for conforming packets.\n\npass This is a synonym to ok.\n\nreclassify\nTreat the packet as non-matching to the filter this action is attached to and\ncontinue with the next filter in line (if any). This is the default for exceed‐\ning packets.\n\npipe Pass the packet to the next action in line.\n\n### EXAMPLES\n\nA typical application of the police action is to enforce ingress traffic rate by dropping ex‐\nceeding packets. Although better done on the sender's side, especially in scenarios with lack\nof peer control (e.g. with dial-up providers) this is often the best one can do in order to\nkeep latencies low under high load. The following establishes input bandwidth policing to\n1mbit/s using the ingress qdisc and u32 filter:\n\n# tc qdisc add dev eth0 handle ffff: ingress\n# tc filter add dev eth0 parent ffff: u32 \\\nmatch u32 0 0 \\\npolice rate 1mbit burst 100k\n\nAs an action can not live on it's own, there always has to be a filter involved as link be‐\ntween qdisc and action. The example above uses u32 for that, which is configured to effec‐\ntively match any packet (passing it to the police action thereby).\n\n### SEE ALSO\n\ntc(8)\n\n\n\niproute2 20 Jan 2015 Policing action in tc(8)\n\n" } ], "structuredContent": { "command": "tc-police", "section": "8", "mode": "man", "summary": "police - policing action", "synopsis": "tc ... action police [ rate RATE burst BYTES[/BYTES] ] [ pktsrate RATE pktsburst PACKETS] [\nmtu BYTES[/BYTES] ] [ peakrate RATE ] [ overhead BYTES ] [ linklayer TYPE ] [ CONTROL\n]\ntc ... filter ... [ estimator SAMPLE AVERAGE ] action police avrate RATE [ CONTROL ]\nCONTROL := conform-exceed EXCEEDACT[/NOTEXCEEDACT\nEXCEEDACT/NOTEXCEEDACT := { pipe | ok | reclassify | drop | continue | goto chain CHAININDEX\n}", "flags": [], "examples": [ "A typical application of the police action is to enforce ingress traffic rate by dropping ex‐", "ceeding 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 be‐", "tween qdisc and action. The example above uses u32 for that, which is configured to effec‐", "tively match any packet (passing it to the police action thereby)." ], "see_also": [ { "name": "tc", "section": "8", "url": "https://www.chedong.com/phpMan.php/man/tc/8/json" }, { "name": "tc", "section": "8", "url": "https://www.chedong.com/phpMan.php/man/tc/8/json" } ], "section_outline": [ { "name": "NAME", "lines": 2, "subsections": [] }, { "name": "SYNOPSIS", "lines": 11, "subsections": [] }, { "name": "DESCRIPTION", "lines": 13, "subsections": [] }, { "name": "OPTIONS", "lines": 63, "subsections": [] }, { "name": "EXAMPLES", "lines": 16, "subsections": [] }, { "name": "SEE ALSO", "lines": 5, "subsections": [] } ] } }