What Is Policing in Networking?

Imagine you are hosting a party at your house and you have a rule that only 10 people can enter through the front door per minute to avoid a crush. You station a friend at the door with a clicker. Each time a person walks in, the friend clicks the counter. If the count in one minute reaches 10, the friend simply refuses to let any more people in until the next minute starts. That is a form of policing: you are setting a hard limit on the rate of entry, and anything beyond that limit is simply turned away.

In a computer network, policing works in a very similar way. A router or switch is configured with a specific rate limit, say 1 megabit per second (Mbps). As data packets flow through the device, it measures how many bits per second are passing. If the rate exceeds that 1 Mbps limit, the device immediately drops the extra packets. The result is that the traffic never goes above the configured speed. This is different from shaping, which would buffer the extra traffic and send it later when there is free capacity. Policing does not buffer; it enforces the limit by discarding excess packets immediately.

Policing is used in many real-world IT situations. Internet service providers use it to enforce the speeds of the plans they sell to customers. If you have a 100 Mbps plan, the provider’s equipment polices your traffic so that you never get more than that speed. Companies use policing to limit how much bandwidth certain applications, like video streaming or file sharing, can consume so that critical business applications always have enough capacity. It is a simple, effective way to manage bandwidth and ensure fairness across many users.

Because policing drops packets, it can cause performance issues if not configured carefully. For example, if the limit is set too low, legitimate traffic can get dropped, leading to slow network performance and retransmissions. Network administrators must understand policing to set correct limits and to know how it interacts with other quality of service (QoS) mechanisms like shaping and queuing.

Traffic policing is a Quality of Service (QoS) mechanism that limits the rate of incoming or outgoing traffic on a network interface by discarding or marking packets that exceed a configured bandwidth threshold. It operates on a per-packet basis and uses a token bucket or leaky bucket algorithm to measure traffic conformance. The core concept is to enforce a committed information rate (CIR) and, in some implementations, a peak information rate (PIR).

In a typical token bucket implementation, the router maintains a bucket that holds tokens. Tokens are added to the bucket at a constant rate equal to the CIR (e.g., 1 Mbps). Each token represents permission to send a certain number of bytes (often one byte per token). The bucket has a maximum depth, which determines the burst size (committed burst, or Bc). When a packet arrives, the system checks if there are enough tokens in the bucket to cover the packet size. If yes, the packet is conforming, tokens are removed, and the packet is transmitted normally. If not, the packet is considered exceeding and the policing action is applied. The actions can be: drop the packet, mark it with a lower IP precedence or DSCP value (policing with remarking), or pass it but mark it as eligible for dropping later.

Policing is defined in RFC 2475 (An Architecture for Differentiated Services) and is a fundamental building block of Differentiated Services (DiffServ). It is commonly implemented in Cisco IOS using the MQC (Modular QoS CLI) with the `police` command, or in Linux using `tc` (traffic control) with a policer filter. The configuration typically specifies the average rate (bits per second), normal burst size (bytes), and excess burst size (bytes). Some implementations support a two-rate, three-color marker (trTCM) that classifies packets as green (conforming), yellow (exceeding), or red (violating) and applies different actions.

In real IT implementations, policing is used on ingress interfaces to limit traffic entering a network (e.g., from a customer), on egress interfaces to enforce a maximum outbound rate, or as part of a service policy in a provider network. It is stateless in that it does not buffer packets; it either forwards or drops/remarks them immediately. This makes policing efficient but potentially harsh because bursts are not smoothed. It is often combined with shaping (which buffers) in complex QoS designs. Policing can also be applied at Layer 2 (e.g., to limit MAC layer traffic) or Layer 3 (IP traffic) depending on the device.

Common standards and protocols involved include IEEE 802.1p (priority tagging), DiffServ Code Point (DSCP) marking, and various vendor-proprietary extensions. For example, in Cisco Catalyst switches, policing can be done via the `mls qos` commands. In enterprise environments, policing is often used to enforce bandwidth limits per user or per application as part of a QoS policy. Policing can cause TCP global synchronization if aggressive drops occur, because many TCP connections may slow down simultaneously. Therefore, careful configuration of burst sizes and drop policies is essential.

Policing is a fundamental tool for network administrators because it provides a simple, efficient way to enforce bandwidth limits and protect network resources. Without policing, a single aggressive application or user could consume all available bandwidth, starving critical services like VoIP, video conferencing, or database transactions. For example, a large file download could saturate a 100 Mbps link, causing voice calls to break up or web pages to load sluggishly for everyone else. Policing prevents this by capping the bandwidth any single flow or user can use.

In practical IT contexts, policing is used by internet service providers to enforce the terms of service plans. If a customer subscribes to a 50 Mbps plan, the provider’s equipment polices that customer’s traffic to 50 Mbps. If the customer tries to send data at 100 Mbps, the extra packets are dropped. This ensures that customers who pay for higher speeds actually get the bandwidth they are entitled to, and that the provider can allocate capacity fairly among all users.

Within an enterprise, policing helps implement Quality of Service (QoS) policies. For instance, an administrator might police peer-to-peer file-sharing traffic to 5 Mbps while allowing business-critical SAP traffic to flow unrestricted. This ensures that important applications always have enough network capacity. Policing is also used to prevent denial-of-service (DoS) attacks. If an attacker sends a flood of packets, policing can limit the rate of incoming traffic, reducing the impact on legitimate users.

Another important reason policing matters is that it is lightweight on router resources compared to shaping. Because policing simply drops packets rather than buffering them, it uses little CPU and memory. This makes it suitable for high-speed interfaces where buffering would cause significant delays. However, because it drops packets, it can cause performance issues if misconfigured, such as excessive retransmissions. Therefore, understanding policing is crucial for balancing network performance and fairness. In short, policing is a key mechanism for implementing control, fairness, and protection in modern networks.

In certification exams, policing questions typically fall into these patterns:

1. Definition and comparison questions: These ask you to select the correct description of policing or to differentiate it from shaping. For example: "Which of the following best describes traffic policing?" with options like "buffers excess traffic" (wrong), "drops excess traffic" (correct), or "prioritizes traffic" (mostly wrong). Another variant: "Traffic shaping vs. policing: which one uses a buffer?"

2. Token bucket algorithm questions: These may present a numeric scenario and ask how many packets are dropped. For instance: "A router is configured with a CIR of 2 Mbps, Bc of 8000 bytes, and burst size of 8000 bytes. If the bucket currently has 4000 tokens and a 3000-byte packet arrives, what happens?" Answer: the packet is conforming and transmitted. Or a question might ask: "After a period of inactivity, the token bucket is full. What is the maximum burst size?"

3. Configuration interpretation questions: The exam shows a snippet of MQC configuration, such as: policy-map LIMIT class WEB police 1000000 8000 8000 conform-action transmit exceed-action drop Then ask: "What is the effect of this policy?" Options might describe the rate limit, burst, and action. You must recognize that 1,000,000 bps is 1 Mbps, Bc is 8000 bytes, and exceeding traffic is dropped.

4. Scenario-based troubleshooting: You are given a description of a problem: "After implementing a QoS policy on a link, users report that large file transfers time out but web browsing is fine. The policy used policing. What is the most likely cause?" Answer: The policing rate is too low for the file transfers, causing drops and TCP retransmission timeouts.

5. Design questions: "You need to limit outbound traffic from a branch office to 10 Mbps, but temporary bursts up to 15 Mbps should be allowed for up to 100 ms. Which QoS tool should you use?" The answer is policing with careful burst settings, or possibly shaping if bursts are to be smoothed. The exam expects you to know that policing can allow bursts via burst size configuration.

6. Advanced questions (CCNP level) may combine policing with marking (e.g., set dscp af41 on conforming traffic, set dscp 0 on exceeding traffic). You might need to understand multi-actions applied in a single police command.

7. Some questions ask about the impact of policing on TCP. For example: "Aggressive policing on a link carrying many TCP connections can cause global synchronization. Why?" Answer: Because many TCP sessions experience drops simultaneously, all reduce their window sizes at the same time, creating an on-off pattern of low utilization.

When preparing, practice interpreting police configurations and calculating token bucket values. You can use the formula: Tc = Bc / CIR (where Tc is the time interval in seconds). But most exam questions are conceptual rather than heavy math.

Policing is a critical tool for a network professional to master because it provides a deterministic way to enforce bandwidth limits. In practice, you configure policing using a policy map in Cisco IOS or using a firewall filter in Juniper Junos. The configuration must be precise: you have to choose the correct rate, burst sizes, and actions. A common real-world scenario is limiting guest Wi-Fi traffic. You create a class that matches all traffic from the guest VLAN, then apply a police policy that limits the total guest bandwidth to, say, 10 Mbps, with a burst of 4 MB (megabytes). This ensures that guests do not saturate the corporate internet link.

One nuance of policing is the choice of burst size. If the burst size is too large, a rogue device could send a huge burst that consumes all the bandwidth for a short moment, potentially impacting other users. If the burst size is too small, even legitimate traffic like a video stream might get dropped because the initial burst of a video request can be larger than the bucket. In practice, a good rule of thumb is to set the burst size to 1.5 times the maximum segment size (MSS) multiplied by the number of expected concurrent flows, but this is often tuned empirically. Tools like Wireshark or SNMP monitoring can help assess if drops are happening.

Another practical aspect is the interaction between policing and TCP. When policing drops TCP packets, the sender receives duplicate ACKs or timeouts and reduces its window. This can cause a sawtooth pattern of throughput. If many TCP flows are policed together, they can synchronize, leading to underutilization. To mitigate this, some implementations support random early detection (RED) or weighted random early detection (WRED) before police drops, but this is a separate mechanism. Also, consider the direction: policing on the ingress interface is often used for traffic coming from customers, while shaping is more common on egress for traffic leaving a slow WAN.

Configuration examples: In Cisco IOS, a basic police config looks like: policy-map GUEST_QOS class GUEST police 10000000 4000000 conform-action transmit exceed-action drop This limits to 10 Mbps with burst 4 MB. In Juniper, a policer is defined as: policer GUEST_LIMIT { if-exceeding { bandwidth-limit 10m; burst-size-limit 4m; } then discard; } and then applied to a firewall filter term.

What can go wrong? If you apply policing to a tunnel interface (like GRE) that has overhead, you must account for the tunnel header size. Otherwise, the actual user throughput will be less than expected. Also, some hardware (like Cisco Catalyst 6500) uses hardware-based policing that has granularity restrictions (e.g., rate must be a multiple of 8 kbps). If you set an unsupported rate, the hardware may round down, causing unexpected drops. Always verify with `show policy-map interface` to see actual drop counters.

Professionals also use policing for rate limiting on specific protocols. For example, to limit ICMP traffic to prevent ping floods: `class ICMP police 100000 8000 conform-action transmit exceed-action drop`. This prevents a DoS attack from overwhelming the router CPU. Policing is a precise, efficient, but unforgiving QoS tool that requires careful configuration and monitoring.