Traffic Shaping vs Policing

When traffic exceeds a contracted WAN rate, something must give. Policing enforces the rate at the enforcement point — packets beyond the limit are dropped immediately or re-marked to a lower DSCP value. The sender never slows down; it simply loses packets and TCP retransmits. Shaping takes a gentler approach — excess packets are held in a buffer and released at the contracted rate when tokens become available. Traffic is smoothed rather than clipped. The trade-off is delay: buffered packets wait, increasing latency and jitter for everything in the shaping queue. Understanding when to use each — and when to combine them — is one of the most practical WAN QoS skills in enterprise networking.

Both mechanisms rely on the token bucket model to measure conformance against a committed rate. Policing uses a dual token bucket (CIR + PIR) to classify traffic into three outcomes: conform, exceed, and violate. Shaping uses a single bucket and defers non-conforming packets to a built-in shaping queue. Both are configured using Cisco's MQC (Modular QoS CLI) framework. For the DSCP marking that typically precedes policing and shaping decisions see DSCP Marking & Classification. For queuing policies that work alongside shaping see CBWFQ and LLQ Configuration and MQC QoS Basics. For the broader QoS model see QoS Overview, QoS Marking, QoS Queuing, and QoS Policing & Shaping. For WAN tunnel interfaces where these policies are commonly applied see GRE Tunnel Configuration.

1. Token Bucket — Core Mechanics

How the Token Bucket Works

  Token Bucket Model:
  ─────────────────────────────────────────────────────────────────
  Tokens fill at the CIR rate (e.g. 1 Mbps = 125,000 bytes/sec)
  Each arriving packet consumes tokens equal to its byte size
  If enough tokens exist  → packet CONFORMS → transmit/forward
  If tokens are depleted  → packet EXCEEDS  → drop / remark / buffer

                       Tc (timing interval)
                       ◄──────────────────►
  Tokens added per Tc: Bc = CIR × Tc

  CIR = 1,000,000 bps  (1 Mbps committed rate)
  Bc  =    8,000 bytes  (committed burst — tokens added each Tc)
  Be  =   16,000 bytes  (excess burst — extra tokens for policing)
  Tc  =    8 ms          (token interval: Bc / CIR × 8 = 8ms)

  Bucket capacity:
    Policing: CIR bucket holds up to Bc; PIR bucket holds up to Be
    Shaping:  bucket holds up to Bc + Be (allows controlled burst)

Key Rate Parameters

Parameter	Full Name	Definition	IOS Keyword
CIR	Committed Information Rate	The contracted sustained rate — average traffic must stay at or below this	`police rate [bps]` or `shape average [bps]`
PIR	Peak Information Rate	Maximum rate allowed in policing — traffic between CIR and PIR is "exceeded" but not violated	`police rate [CIR] peak-rate [PIR]`
Bc	Committed Burst Size	Maximum bytes that can be sent at line rate in one Tc interval while conforming. Default = CIR/8 (1 second worth of tokens)	`police rate [bps] bc [bytes]` or `shape average [bps] [Bc]`
Be	Excess Burst Size	Additional bytes beyond Bc — in policing defines the "exceed" window; in shaping allows short bursts above CIR when tokens have accumulated during idle periods	`police rate [bps] bc [Bc] be [Be]` or `shape average [bps] [Bc] [Be]`
Tc	Token Refresh Interval	How often tokens are added to the bucket — calculated as Bc ÷ CIR × 8000 (in ms). Shorter Tc = smoother shaping; longer Tc = burstier	Derived automatically; tunable via Bc in shaping

Shaping vs Policing — Side-by-Side Comparison

Characteristic	Policing	Shaping
Action on excess traffic	Drop or re-mark immediately — packet is discarded or DSCP is lowered	Buffer (defer) — packet waits in shaping queue, sent when tokens available
Effect on latency	No added latency — packets are forwarded or dropped instantly	Adds latency and jitter — buffered packets wait in the shaping queue
Effect on TCP	TCP detects drops and reduces its window (congestion avoidance) — throughput drops but may recover	TCP does not see drops; it sees delay instead — throughput is smooth but latency increases
Typical deployment	Inbound on the ISP/provider edge (rate enforcement); inbound on enterprise WAN ingress; protecting EF class from exceeding priority queue allocation	Outbound on enterprise WAN egress — shaping output to match ISP contracted rate, preventing upstream provider from dropping bursts
Built-in queue	No — drops excess immediately (unless remarked for downstream handling)	Yes — each shape class has its own FIFO or hierarchical child queue
Direction	Typically input (ingress policing); output also valid for egress rate enforcement	Output only — shaping buffers traffic before sending; cannot buffer incoming traffic
Dual token bucket	Yes — CIR bucket (conform) + PIR bucket (exceed); three outcomes: conform, exceed, violate	No — single token bucket; two outcomes: conform (send) or exceed (buffer)
IOS command	`police rate [bps]` inside a policy-map class	`shape average [bps]` inside a policy-map class

2. Lab Topology & Scenario

  [LAN hosts — 192.168.10.0/24]
         │
    Gi0/1 (LAN)
    192.168.10.1/24
  NetsTuts-R1
    Gi0/0 (WAN)        ──────────────► ISP / MPLS Core
    10.0.0.1/30                        10.0.0.2/30

  ISP contracted WAN rate: 2 Mbps CIR
  Physical interface speed: 100 Mbps (FastEthernet)
  Burst above CIR: ISP allows up to 4 Mbps for 250 ms

  QoS objectives on Gi0/0 outbound:
    VoIP RTP   (DSCP EF)   → Police to 256 kbps — protect priority queue
    Video      (DSCP AF41) → Shape to 512 kbps — smooth delivery to ISP
    Bulk data  (DSCP AF11) → Police to 512 kbps, remark exceed to CS1
    All other             → Shape aggregate to 2 Mbps CIR with 4 Mbps burst

3. Step 1 — Configure Traffic Policing

Policing uses the police action inside a policy-map class. The minimum configuration specifies a rate and a conform/exceed action. The full form adds a peak rate for three-outcome (conform/exceed/violate) policing using the dual token bucket model:

Simple Two-Rate Policing — Conform / Exceed

NetsTuts-R1>en
NetsTuts-R1#conf t

! ── Class-maps referencing DSCP markings ─────────────────
class-map match-any CM-VOIP
 match dscp ef
!
class-map match-any CM-VIDEO
 match dscp af41
!
class-map match-any CM-BULK
 match dscp af11
!
! ════════════════════════════════════════════════════════
! Policy-map: policing only (simple two-action form)
! ════════════════════════════════════════════════════════
policy-map PM-POLICE-SIMPLE
 !
 ! ── VoIP: police to 256 kbps ─────────────────────────
 class CM-VOIP
  police rate 256000 bps
   conform-action transmit
   exceed-action  drop
 !
 ! ── Bulk: police to 512 kbps, remark exceed to CS1 ───
 class CM-BULK
  police rate 512000 bps
   conform-action transmit
   exceed-action  set-dscp-transmit cs1
 !
 class class-default
  !
!

The police rate command accepts bps (bits per second) values. 256000 bps is 256 kbps. Alternative units: 256 kbps, 256000 (unitless defaults to bps), or percent of interface bandwidth with police rate percent 10. The conform-action transmit forwards the packet unchanged. The exceed-action set-dscp-transmit cs1 lowers the DSCP to CS1 (scavenger) and forwards — the packet is not dropped but is marked as low priority, allowing downstream queuing policies to deprioritise or drop it under congestion. This re-marking approach (also called "markdown") is often preferred over hard dropping because it gives congested downstream links a chance to discard the packet rather than forcing the drop at the policing point.

Three-Rate Policing — Conform / Exceed / Violate

! ════════════════════════════════════════════════════════
! Policy-map: three-rate policing with explicit Bc and Be
! CIR = 512 kbps, PIR = 1 Mbps
! Bc  = 64000 bytes  (~1 sec of CIR tokens)
! Be  = 128000 bytes (~1 sec of PIR tokens)
! ════════════════════════════════════════════════════════
policy-map PM-POLICE-3RATE
 class CM-BULK
  police rate 512000 bps bc 64000 byte be 128000 byte
   conform-action  transmit
   exceed-action   set-dscp-transmit af13
   violate-action  drop
 !
 class class-default
  police rate 1000000 bps
   conform-action transmit
   exceed-action  drop
 !
!

The three-rate policer uses two token buckets in parallel. The CIR bucket (bc 64000) fills at 512 kbps and holds up to 64,000 bytes — traffic drawing from this bucket conforms. The Be bucket (be 128000) provides an additional burst window — traffic consuming tokens from the Be bucket exceeds the CIR but has not yet violated the PIR. The violate condition occurs when both buckets are empty. The exceed action set-dscp-transmit af13 forwards the packet but raises the drop precedence within the AF1 class from low (AF11 = DSCP 10) to high (AF13 = DSCP 14) — downstream WRED queuing will preferentially discard these packets first under congestion, while conforming AF11 packets are protected.

Policing Actions Reference

Action Keyword	Effect	Typical Use
`transmit`	Forward the packet unchanged — DSCP preserved	Conform action for all classes; occasionally exceed action when soft limits are acceptable
`drop`	Discard the packet — no forwarding, no notification to sender	Violate action; exceed action on strict rate enforcement (VoIP protection, SLA enforcement)
`set-dscp-transmit [value]`	Overwrite DSCP field with specified value, then forward	Exceed action — markdown from AF11 → AF13, or from AF41 → AF43; allows downstream to handle gracefully
`set-prec-transmit [value]`	Set IP Precedence (3-bit legacy field) and forward	Legacy networks using IP Precedence instead of DSCP
`set-clp-transmit`	Set ATM Cell Loss Priority bit and forward	ATM environments — rarely seen in modern labs
`set-qos-transmit [group]`	Set QoS group (internal marker, not visible in IP header) and forward	Multi-stage QoS pipelines where the mark must pass between features without modifying the IP header

4. Step 2 — Configure Traffic Shaping

Shaping uses the shape average command inside a policy-map class. Unlike policing, shaping has no explicit conform/exceed action syntax — excess packets are automatically buffered in the shaping queue. The average keyword targets the average rate equal to CIR; the less common peak keyword allows the average to exceed CIR by using Be tokens more aggressively:

Basic Output Shaping to CIR

! ════════════════════════════════════════════════════════
! Policy-map: output shaping on WAN interface
! Shape all traffic to 2 Mbps CIR
! ════════════════════════════════════════════════════════
policy-map PM-SHAPE-WAN
 class class-default
  ! ── Shape to 2 Mbps CIR ────────────────────────────
  shape average 2000000
 !
!
! ── Apply to WAN egress ───────────────────────────────
interface GigabitEthernet0/0
 service-policy output PM-SHAPE-WAN
!

shape average 2000000 limits the output rate to 2,000,000 bps (2 Mbps). IOS automatically calculates Bc and Tc: Bc defaults to CIR/8 = 250,000 bytes, Tc defaults to Bc/CIR×8000 = 1000 ms. A 1-second Tc means shaping is evaluated once per second — in the first second all 250,000 bytes (2 Mbps worth) can burst at line rate, then shaping defers remaining packets. For smoother shaping with less bursty behaviour, reduce Bc by specifying it explicitly: shape average 2000000 25000 sets Bc to 25,000 bytes giving Tc = 100 ms — tokens are added every 100 ms for much smoother pacing.

Shaping with Explicit Bc and Be (Burst Control)

! ════════════════════════════════════════════════════════
! Shape to 2 Mbps CIR, allow burst to 4 Mbps for ~125 ms
! CIR = 2,000,000 bps
! Bc  = 25,000 bytes  (Tc = 100 ms — smooth shaping)
! Be  = 250,000 bytes (can burst 250,000 extra bytes when
!                      tokens have accumulated while idle)
! ════════════════════════════════════════════════════════
policy-map PM-SHAPE-BURST
 class class-default
  shape average 2000000 25000 250000
 !
!

The Be parameter in shaping works differently from Be in policing. In shaping, accumulated unused tokens (when the link is idle) fill both the Bc bucket AND can overflow into a Be bucket up to the specified Be value. This allows a burst above CIR after an idle period — the router can send up to Bc + Be = 275,000 bytes in a single Tc before being rate-limited back to CIR. This is the correct model for ISP contracts that allow short bursts above the committed rate — configure Be to match the ISP's stated burst allowance in bytes.

Hierarchical Shaping with Child Queuing Policy

The most powerful shaping deployment is hierarchical (parent/child): the parent policy shapes the aggregate WAN output rate; the child policy implements LLQ/CBWFQ queuing within the shaping queue so that when traffic is being shaped, high-priority classes (VoIP) are still served first within the buffer:

! ── Child queuing policy ─────────────────────────────
policy-map PM-QUEUE-CHILD
 !
 class CM-VOIP
  ! ── LLQ: VoIP gets strict priority within the shaper ─
  priority 256
 !
 class CM-VIDEO
  bandwidth 512
 !
 class class-default
  fair-queue
 !
!
! ── Parent shaping policy references child ────────────
policy-map PM-SHAPE-PARENT
 class class-default
  shape average 2000000
  ! ── Attach child queuing policy to shaping queue ────
  service-policy PM-QUEUE-CHILD
 !
!
! ── Apply parent to WAN interface (output only) ───────
interface GigabitEthernet0/0
 service-policy output PM-SHAPE-PARENT
!

Without a child policy, the shaping queue is FIFO — VoIP packets that arrive during a burst sit behind bulk data packets in the buffer, defeating the purpose of EF marking. The hierarchical model corrects this: the parent policy controls the outbound rate (smoothing to ISP CIR), and the child policy determines the order in which packets exit the shaping queue. VoIP in the priority class is always dequeued first, even while the shaper is holding back video and bulk traffic. This is the recommended architecture for any WAN interface where both rate limiting and traffic prioritisation are required simultaneously.

5. Step 3 — Combined Policing and Shaping on WAN Interface

Real deployments typically combine both mechanisms: policing per traffic class (to protect critical classes from individual over-senders) inside a shaped aggregate (to smooth the total output to the ISP contracted rate). This is implemented as a hierarchical policy where the parent shapes the WAN aggregate and the child polices individual classes:

! ════════════════════════════════════════════════════════
! Complete WAN QoS policy:
! Parent: shape aggregate output to 2 Mbps CIR
! Child:  police per-class, queue by priority
! ════════════════════════════════════════════════════════
!
! ── Class-maps (matching on DSCP from inbound marking) ─
class-map match-any CM-VOIP
 match dscp ef
class-map match-any CM-VIDEO
 match dscp af41
class-map match-any CM-BULK
 match dscp af11
!
! ── Child policy: per-class policing + queuing ─────────
policy-map PM-WAN-CHILD
 !
 ! VoIP: LLQ priority + police to prevent starvation ───
 class CM-VOIP
  priority 256
  police rate 256000 bps
   conform-action transmit
   exceed-action  drop
 !
 ! Video: guaranteed bandwidth + police to 512 kbps ────
 class CM-VIDEO
  bandwidth 512
  police rate 512000 bps
   conform-action transmit
   exceed-action  set-dscp-transmit af43
 !
 ! Bulk: minimal bandwidth, police + remark exceed ─────
 class CM-BULK
  bandwidth 128
  police rate 512000 bps
   conform-action transmit
   exceed-action  set-dscp-transmit cs1
 !
 ! Default: remaining bandwidth ────────────────────────
 class class-default
  fair-queue
 !
!
! ── Parent policy: aggregate shaping + child policy ───
policy-map PM-WAN-PARENT
 class class-default
  shape average 2000000 25000
  service-policy PM-WAN-CHILD
 !
!
! ── Apply to WAN egress interface ─────────────────────
interface GigabitEthernet0/0
 description WAN-Uplink-to-ISP
 ip address 10.0.0.1 255.255.255.252
 service-policy output PM-WAN-PARENT
 no shutdown
!
NetsTuts-R1(config)#end
NetsTuts-R1#wr
Building configuration...
[OK]

The priority 256 inside the child policy reserves 256 kbps (in the context of the 2 Mbps parent shape) as a strict priority queue for VoIP — this is Low Latency Queuing. The police rate 256000 within the same class caps VoIP at exactly that rate, preventing a burst of VoIP traffic from consuming the entire shaping budget. The bandwidth 512 commands guarantee minimum bandwidth allocation within the shaped budget for video and bulk classes during congestion. The parent shaping rate (2 Mbps) is the ceiling for the entire policy — no traffic can exit faster than 2 Mbps regardless of which class it belongs to. This combined architecture is Cisco's recommended WAN QoS design for MPLS or broadband services with contracted CIR. For interface configuration prerequisites see Basic Interface Configuration. Save with write memory.

6. Step 4 — Observing Burst Behaviour

Token Bucket State During Burst Traffic

  Policing — CIR 512 kbps, Bc 64000 bytes, Be 128000 bytes
  ────────────────────────────────────────────────────────────────
  Time 0:   Bucket full (idle period) — 64000 tokens (CIR bucket)
                                      + 128000 tokens (Be bucket)
  Burst arrives at 10 Mbps (line rate):
    T=0–50ms:  Consuming CIR bucket — 64000 tokens → CONFORM
    T=50–100ms: CIR bucket empty, consuming Be bucket — EXCEED
                (set-dscp-transmit af13 or drop depending on config)
    T=100ms+:  Both buckets empty — all packets VIOLATE → DROP
    T=101ms:   Tokens refill at 512 kbps rate = 512 bytes per ms
  Result: Hard cliff — traffic above rate is immediately dropped

  Shaping — CIR 512 kbps, Bc 64000 bytes, Be 128000 bytes
  ────────────────────────────────────────────────────────────────
  Time 0:   Bucket full — 64000 + 128000 = 192000 tokens available
  Burst arrives at 10 Mbps:
    T=0–50ms:  Using CIR tokens — transmit at line rate
    T=50ms+:   CIR bucket empty — excess packets enter shaping queue
               Packets drained from queue at 512 kbps
  Result: Smooth ramp-down — no drops, but buffered packets
          experience increasing delay (queue latency)

Shaping Queue Depth During Burst — What Latency Looks Like

  1500-byte packets arriving at 10 Mbps, shape rate 512 kbps:
  Arrival rate: 10,000,000 / (1500×8) = 833 packets/sec
  Drain rate:      512,000 / (1500×8) =  42 packets/sec

  Queue grows at: 833 - 42 = 791 packets/sec
  After 1 second: ~791 packets queued
  Queuing delay:  791 × (1500×8)/512000 = ~18.5 seconds!

  This illustrates why shaping is INAPPROPRIATE for real-time traffic
  like VoIP — even with EF marking, shaped VoIP packets can wait
  hundreds of milliseconds behind bulk data in the shaping queue.
  Hierarchical shaping with LLQ child policy prevents this:
  VoIP is always dequeued first from the shaping buffer.

7. Verification

show policy-map interface — Policing Counters

NetsTuts-R1#show policy-map interface GigabitEthernet0/0 output

 GigabitEthernet0/0

  Service-policy output: PM-WAN-PARENT

    Class-map: class-default (match-any)
      250180 packets, 375270000 bytes
      5 minute offered rate 1980000 bps, drop rate 0000 bps
      Match: any
      Traffic Shaping
        Target/Average   Byte Limit  SUSTAIN  bytes/int  EXCESS  bytes/int  Interval  Increment
        2000000/2000000  62500       250000   62500       500000  62500      125       31250

        Adapt  Queue  Packets   Bytes     Packets   Bytes     Shaping
        Active Depth  Delayed   Delayed   FECN      BECN
          -    12     1824      2736000    0         0          yes

      Service-policy : PM-WAN-CHILD

        Class-map: CM-VOIP (match-any)
          18420 packets, 29472000 bytes
          5 minute offered rate 248000 bps, drop rate 0000 bps
          Match: dscp ef (46)
            Priority: 256 kbps, burst bytes 6400, b/w exceed drops: 0
          police:
              rate 256000 bps, bc 8000 byte, be 8000 byte
            conformed   18420 packets, 29472000 bytes; actions: transmit
            exceeded        0 packets,         0 bytes; actions: drop
            conformed 248000 bps, exceeded 0000 bps

        Class-map: CM-VIDEO (match-any)
          8210 packets, 14778000 bytes
          5 minute offered rate 492000 bps, drop rate 12000 bps
          Match: dscp af41 (34)
            bandwidth 512 (kbps), BW exceed drops: 0
          police:
              rate 512000 bps, bc 64000 byte
            conformed    7800 packets, 14040000 bytes; actions: transmit
            exceeded      410 packets,   738000 bytes; actions: set-dscp-transmit af43
            conformed 480000 bps, exceeded 12000 bps

        Class-map: CM-BULK (match-any)
          4120 packets, 6592000 bytes
          5 minute offered rate 320000 bps, drop rate 0000 bps
          Match: dscp af11 (10)
            bandwidth 128 (kbps)
          police:
              rate 512000 bps, bc 64000 byte
            conformed   4120 packets, 6592000 bytes; actions: transmit
            exceeded       0 packets,       0 bytes; actions: set-dscp-transmit cs1
            conformed 320000 bps, exceeded 0000 bps

        Class-map: class-default (match-any)
          219430 packets, 330241000 bytes
          5 minute offered rate 920000 bps, drop rate 0000 bps
          Match: any
            0 packets, 0 bytes

Reading the hierarchical output requires understanding its structure. The outermost policy (PM-WAN-PARENT) shows the shaping statistics: Queue Depth: 12 means 12 packets are currently held in the shaping buffer; Packets Delayed: 1824 is the cumulative count of packets that have been held in the shaping queue since the policy was applied; Shaping: yes confirms the shaper is actively rate-limiting. Inside the child policy (PM-WAN-CHILD), the policing block for each class shows three critical counters: conformed (packets sent within rate), exceeded (packets at or above CIR), and violated (packets above PIR — only in three-rate policing). For CM-VIDEO, 410 packets were exceeded and re-marked to AF43, while 7,800 conformed at the full AF41 marking — the video source is slightly over its 512 kbps budget.

show policy-map interface — Shaping Detail

NetsTuts-R1#show policy-map interface GigabitEthernet0/0 output class class-default

 GigabitEthernet0/0

  Service-policy output: PM-WAN-PARENT

    Class-map: class-default (match-any)
      Traffic Shaping
        Target/Average   Byte Limit  SUSTAIN      EXCESS       Interval  Increment
        2000000/2000000  62500       250000        500000       125       31250

        Adapt    Queue    Packets   Bytes       Packets  Bytes   Shaping
        Active   Depth    Delayed   Delayed     FECN     BECN
           -       0      21840     31752000       0        0      no

The shaping table decodes as follows. Target/Average 2000000/2000000 confirms the CIR and the target rate are both 2 Mbps (shape average). Byte Limit 62500 is the Bc in bytes (25,000 bits ÷ 8 = no — this is IOS's internal shaping bucket size). SUSTAIN 250000 is the max tokens held (Bc = 250,000 bits at this rate setting). Queue Depth 0 means no packets are currently waiting — the shaper is not active at this moment. Packets Delayed 21,840 is the cumulative total of packets that have been buffered since the policy was applied — even though the queue is empty now, 21,840 packets experienced shaping delay at some point. Shaping: no means the shaper is not actively holding packets in the current Tc interval.

show policy-map interface — Before and After Burst

! ── Before burst (idle link) ─────────────────────────────
NetsTuts-R1#show policy-map interface Gi0/0 output | include Delayed
        Packets Delayed: 0    Bytes Delayed: 0

! ── During a 10 Mbps burst ───────────────────────────────
NetsTuts-R1#show policy-map interface Gi0/0 output | include Delayed
        Packets Delayed: 1240   Bytes Delayed: 1860000

! ── Check queue depth during burst ───────────────────────
NetsTuts-R1#show policy-map interface Gi0/0 output | include Depth
        Queue Depth: 84

! ── Policing drop counters during burst ──────────────────
NetsTuts-R1#show policy-map interface Gi0/0 output | include exceeded
            exceeded  2840 packets,  4260000 bytes; actions: set-dscp-transmit af43

During a sustained burst the shaping queue depth climbs (84 packets shown), confirming packets are being buffered rather than dropped. Concurrently, the policing counter shows 2,840 packets were exceeded for the video class — these were re-marked to AF43 and forwarded. If the burst were hitting a policing-only policy without shaping, the counter would show drop instead of a re-marking action, and the source would receive TCP retransmits. The shaping queue absorbs the burst smoothly while the policing enforces per-class limits within the shaped budget.

Verification Command Summary

Command	Shows	Key Fields
`show policy-map interface [intf] output`	Full hierarchical output policy — shaping stats + per-class policing counters	Queue Depth, Packets Delayed (shaping); conformed/exceeded/violated byte counts (policing)
`show policy-map interface [intf] input`	Input policy — typically marking or ingress policing counters	conformed/exceeded/violated counters with rates in bps
`show policy-map [name]`	Policy-map definition — all classes, actions, and configured rates without live counters	Verify CIR values, Bc/Be, and action keywords before applying to interface
`show traffic-shape [intf]`	Legacy shaping display — shows CIR, Bc, Be, queue depth for legacy Generic Traffic Shaping (GTS)	Use for legacy GTS; for MQC shaping use `show policy-map interface`
`show traffic-shape statistics`	Per-interface shaping statistics — packets shaped, delayed, dropped	Cumulative counters useful for trend analysis; reset with `clear traffic-shape statistics`
`show interfaces [intf]`	Interface-level output queue drops — indicates congestion even without QoS policy	Output drops incrementing confirms interface congestion that QoS is meant to address

8. Troubleshooting Shaping and Policing

Problem	Symptom	Cause	Fix
Policing drops all traffic immediately	All classes show high violated/drop counters immediately after policy application; throughput drops to near zero	Police rate configured in wrong unit — specifying `police rate 2000000` means 2 Mbps bps (correct), but `police rate 2000` means 2000 bps (2 kbps, far too low). CIR and interface speed units are easy to confuse	Verify the rate value: `show policy-map [name]` shows the configured rate. Confirm units: bps is the default. To police at 2 Mbps use `police rate 2000000 bps` or `police rate 2 mbps`. Check `show policy-map interface` conformed rate — should be close to the intended CIR when traffic is below the limit
VoIP quality poor despite EF marking and shaping	VoIP jitter and latency high; `show policy-map interface` shows VoIP packets Delayed count incrementing; priority queue drops occurring	Shaping is applied without a child queuing policy — VoIP EF packets are queued in FIFO behind bulk data inside the shaping buffer. Shaping delay is additive to network latency	Add a hierarchical child policy with `priority [kbps]` for the VoIP class. Ensure VoIP bandwidth allocation in the child policy matches the police rate for EF traffic. Verify with `show policy-map interface` — Priority class should show zero delayed packets while bulk classes absorb the shaping delay
Shaping not active — all packets forwarded at line rate	`show policy-map interface` shows Shaping: no and zero Packets Delayed despite traffic above CIR; traffic passes at full interface speed	Service-policy applied input instead of output — shaping is only supported in the output direction; input shaping silently falls back to no shaping on most platforms	Confirm `show policy-map interface [intf] output` shows the policy. Remove and re-apply with `no service-policy input [name]` then `service-policy output [name]`. Shaping must be output
Cannot nest child policy inside parent shaping policy	`% service-policy configuration failed` or `% Child policy cannot have shaping` error when configuring hierarchical policy	Child policy contains a `shape` command — IOS does not allow shaping inside a child policy; shaping is only valid in the parent. Or the child policy is already attached to another interface	Move the `shape average` command to the parent class-default. Ensure the child policy contains only queuing commands (`priority`, `bandwidth`, `police`, `fair-queue`) but no `shape`
Exceed counter high but traffic not being slowed	Police exceed counter climbs rapidly; traffic throughput remains at line rate rather than being constrained to CIR	Exceed action is `transmit` (either explicitly or by default on older IOS) — exceeded packets are forwarded unchanged. The counter shows the rate was measured as exceeding but no action is being taken to reduce it	Change the exceed action to `drop` or `set-dscp-transmit [lower-value]`. Verify: `show policy-map [name]` shows the exceed-action. Note that `transmit` on exceed is valid for "measure and mark" scenarios but does not limit throughput
Shaping queue growing indefinitely — memory exhaustion	Router memory climbing; `show policy-map interface` shows Queue Depth in thousands; eventually packets are tail-dropped from the shaping queue	Input traffic rate far exceeds CIR for a sustained period — the shaping queue drains much slower than it fills. Without a queue limit the buffer grows until memory is exhausted or a system limit is reached	Reduce the source traffic rate (upstream policing at the sender) or increase CIR. Add WRED to the shaping queue to probabilistically drop lower-priority packets before the queue fills: add `random-detect dscp-based` to the class-default in the child policy. Alternatively police the aggregate inbound rate before the shaper to prevent over-subscription
Three-rate policing actions not triggering correctly	Expected exceed action (remark) not occurring; or violate action (drop) firing when traffic is only slightly above CIR	Bc and Be values too small — small burst sizes cause rapid bucket depletion. Or PIR not configured — without explicit PIR only CIR and Bc exist, making every exceedance a violate rather than an exceed	Configure explicit Bc and Be values appropriate for the traffic profile: `police rate [CIR] bc [Bc-bytes] be [Be-bytes]`. As a starting point, Bc = CIR/8 (1 second of tokens), Be = 2×Bc. Verify bucket sizes with `show policy-map [name]`

Key Points & Exam Tips

Policing drops or re-marks excess traffic immediately at the rate limit. No additional latency is added to conforming traffic. TCP detects drops and reduces its sending rate. Use policing for strict rate enforcement, protecting priority queues, and ingress rate limiting.
Shaping buffers excess traffic and releases it at the CIR rate when tokens become available. No packets are dropped (until the shaping queue itself fills), but latency and jitter increase for buffered packets. Use shaping on WAN egress to smooth output to the ISP contracted rate.
Both mechanisms use the token bucket model: tokens fill at the CIR rate; conforming packets consume tokens; excess packets are dropped (policing) or queued (shaping). CIR, Bc (committed burst), and Be (excess burst) define the bucket parameters.
Policing uses a dual token bucket producing three outcomes: conform (within CIR bucket), exceed (beyond CIR bucket, within Be bucket), violate (both buckets empty). Each outcome has an independent action: transmit, drop, or set-dscp-transmit.
Shaping only supports output direction. Policing supports both input and output. An interface can have one input and one output service-policy simultaneously.
shape average [bps] targets the average rate equal to CIR. Explicitly specify Bc for smoother shaping: smaller Bc = shorter Tc = more frequent token additions = smoother output at the cost of slightly higher overhead.
The hierarchical policy (parent shapes aggregate, child queues per-class) is the recommended WAN QoS architecture. Without a child LLQ policy inside the shaper, VoIP packets wait in the shaping FIFO queue behind bulk data — DSCP EF marking alone does not protect against shaping delay.
The exceed action set-dscp-transmit [higher-drop-precedence] implements markdown — AF11 → AF13, AF41 → AF43 — forwarding excess traffic with a higher drop probability rather than dropping it immediately. Downstream WRED queuing then preferentially discards marked packets under congestion.
Key show policy-map interface fields: conformed/exceeded/violated packet counts for policing; Queue Depth and Packets Delayed for shaping; Shaping: yes/no for current shaping state. Shaping: yes during a burst confirms the mechanism is actively buffering.
For the CCNA/CCNP exam: know that shaping adds delay (buffering) while policing adds drops; know the three policing outcomes; know that shaping is output only; know that hierarchical policies combine shaping and queuing; and know that DSCP marking must precede any policy that classifies by DSCP.

Next Steps: Policing and shaping act on traffic after it has been classified and marked. For the DSCP marking step that typically precedes these policies see DSCP Marking & Classification. For the queuing and scheduling policies that complement shaping in the hierarchical child policy see CBWFQ and LLQ Configuration. For the broader QoS design model that places marking, policing, shaping, and queuing in context see QoS Overview and QoS Policing & Shaping. For preserving DSCP markings across WAN tunnels (important when a shaping policy needs to classify by DSCP on a GRE or IPsec interface) see DMVPN Phase 1, 2 & 3 and GRE Tunnel Configuration. For threshold-based monitoring that complements QoS enforcement see IP SLA Configuration & Tracking.

TEST WHAT YOU LEARNED

1. A router is configured with a policing policy on a WAN interface. During a burst, a large file transfer sending at 10 Mbps hits a 2 Mbps police rate. What happens to the TCP file transfer, and how does this differ from a shaping policy at the same rate?

A. With policing, TCP detects the lower rate and immediately reduces its window to exactly 2 Mbps, maintaining a steady flow. With shaping, TCP detects buffering delays and also reduces its rate — the outcome is identical B. With policing, packets beyond 2 Mbps are dropped immediately. TCP interprets the drops as congestion signals and reduces its congestion window (slow start/congestion avoidance). Throughput drops sharply then recovers in a sawtooth pattern as TCP probes the available bandwidth. With shaping, excess packets are buffered rather than dropped — TCP sees increased latency but no drops, so it does not reduce its window. The buffer absorbs the burst and TCP throughput remains smooth (but with added latency) until the shaping queue fills C. With policing, the file transfer is paused and resumes at the next Tc interval. With shaping, the file transfer is rate-limited transparently with no effect on TCP behaviour D. Both policing and shaping send an ICMP Source Quench message to the sender telling it to reduce its rate — the only difference is that shaping buffers packets while waiting for the acknowledgement

Correct answer is B. This question captures the fundamental behavioural difference between policing and shaping from the perspective of the application. Policing is a hard gate — packets arriving when the token bucket is empty are discarded without mercy. TCP's congestion detection relies on packet loss as a signal: when TCP detects drops (missing ACKs, triple duplicate ACKs), it enters slow start and halves its congestion window, causing a characteristic sawtooth throughput pattern. Throughput alternates between high (probing) and low (after drop detection). Shaping converts drops into delay — excess packets wait in the buffer and emerge at the shaped rate. TCP's retransmit timers do not expire because ACKs do arrive (just more slowly due to buffering), so TCP does not detect congestion and does not reduce its window. The result is smoother throughput with higher latency. The shaping queue can grow indefinitely if the burst is sustained long enough, eventually triggering tail-drop which then does cause TCP to reduce its window.

2. What is the purpose of the Tc (token interval) in traffic shaping, and how does reducing Bc affect the smoothness of shaped output?

A. Tc controls how often the shaping queue is checked for packets — a smaller Tc means more frequent checks but has no effect on burst behaviour B. Tc determines the maximum single burst size — a larger Tc allows bigger bursts at line rate, while a smaller Tc enforces strictly smooth output with no bursting above CIR at any point C. Tc is fixed at 125 ms on all Cisco platforms regardless of CIR or Bc configuration — only the Bc and Be values can be adjusted to control burst behaviour D. Tc is derived as Bc ÷ CIR × 8000 (in milliseconds). Each Tc interval, Bc bytes of tokens are added to the bucket, and the shaper releases up to Bc bytes at line rate before deferring further packets. A larger Bc produces a longer Tc — the shaper sends a bigger burst at full speed then pauses for a longer interval, creating an on/off sawtooth output. A smaller Bc produces shorter, more frequent Tc intervals with smaller bursts — the output is smoother and more consistent at the CIR rate, at the cost of slightly higher scheduling overhead

Correct answer is D. The Tc formula is: Tc (ms) = Bc (bytes) × 8 ÷ CIR (bps) × 1000. For a 1 Mbps CIR with Bc = 125,000 bytes: Tc = 125,000 × 8 ÷ 1,000,000 × 1000 = 1000 ms. This means once per second the shaper releases 125,000 bytes (1 Mbps worth) at line rate. A source sending 10 Mbps fills the bucket in 12.5 ms, then waits nearly 1 second before the next token addition — very bursty. With Bc = 12,500 bytes (10× smaller): Tc = 100 ms — the shaper releases tokens every 100 ms, allowing only 12,500 bytes (0.1 Mbps) per interval at line rate. This produces much smoother output resembling a constant 1 Mbps stream. For applications sensitive to jitter (like VoIP passing through the shaping queue without a child LLQ), a smaller Bc significantly reduces the variability in delivery timing. The practical minimum Tc is typically around 8–10 ms to avoid excessive scheduling overhead.

3. In a three-rate policing policy with CIR 512 kbps and PIR 1 Mbps, what triggers the violate action, and how does this differ from the exceed action?

A. The dual token bucket has a CIR bucket (fills at 512 kbps, capacity Bc) and a Be bucket (additional capacity). A packet conforms if the CIR bucket has sufficient tokens; it exceeds if the CIR bucket is empty but the Be bucket has tokens. It violates when both buckets are completely empty — the packet arrival rate has exceeded both the CIR and the PIR for long enough to drain all available tokens. Violate packets are typically dropped immediately; exceed packets are typically re-marked to a higher drop precedence and forwarded B. Violate occurs when the burst exceeds Bc by more than double; exceed occurs when the burst exceeds Bc by up to double. Both are drop actions — the only difference is the severity of the drop condition C. Violate and exceed are identical — IOS uses them interchangeably. The three-rate policer only has two distinct outcomes: conform or not-conform D. Violate occurs on UDP flows only because UDP has no congestion control; exceed occurs on TCP flows. The policer detects the transport protocol to determine which action to apply

Correct answer is A. The three-rate (dual token bucket) policer is the standard model for MPLS and broadband services that offer a CIR with a burst option. The mechanics work as follows: tokens fill the CIR bucket at 512 kbps up to Bc bytes. Any tokens that would overflow Bc spill into the Be bucket up to Be bytes. When a packet arrives: if the CIR bucket has enough tokens, consume them and mark as CONFORM. If the CIR bucket is short but the Be bucket has tokens, consume Be tokens and mark as EXCEED. If both buckets lack sufficient tokens, mark as VIOLATE. The intended action hierarchy is: CONFORM → transmit at full quality (AF31, EF, etc.); EXCEED → markdown (AF31 → AF33, AF41 → AF43) and forward — the packet gets through but is marked as expendable under downstream congestion; VIOLATE → drop — the traffic has genuinely overrun both committed and burst allowances and must be discarded to protect other flows.

4. Why is shaping only supported in the output direction on Cisco IOS, and what is used instead to rate-limit inbound traffic?

A. Shaping requires bidirectional buffering — it buffers outbound traffic in hardware transmit queues that only exist on the output side. Input queues are too small to implement shaping and IOS enforces this with a configuration restriction B. IOS does support input shaping on newer platforms — configure service-policy input with a shape command. On older platforms, input shaping is emulated by dropping inbound packets at the conform rate using a hidden FIFO buffer C. Shaping works by holding excess packets in a local buffer and releasing them when tokens become available. Inbound traffic has already arrived at the interface — the router cannot hold it "before it arrives." Buffering inbound traffic would require a separate receive buffer per interface and would not actually slow the remote sender. Inbound rate-limiting uses policing instead — which drops excess packets, causing the remote sender (TCP) to reduce its rate. Use service-policy input with a police action to rate-limit inbound traffic D. Shaping in the input direction is supported only for Frame Relay and ATM circuits using the legacy frame-relay traffic-shaping command — it is not available for Ethernet WAN interfaces

Correct answer is C. The fundamental reason shaping cannot work on inbound traffic is physical: by the time a packet has been received by the interface and processed by IOS, it has already arrived — the bandwidth to carry that packet has already been consumed on the inbound link. Buffering it locally would not slow the sender or prevent subsequent packets from arriving. The only way to control inbound rates is to influence the sender's behaviour — and policing (with drops) is the mechanism that does this indirectly: TCP detects the drops, reduces its congestion window, and sends less. UDP-based applications have no such feedback mechanism, which is why policing inbound UDP is less effective than policing inbound TCP. For truly preventing inbound overrun, the policing must be configured at the remote sender's outbound interface — or at the service provider's network boundary — before the traffic reaches the local WAN interface. This is the basis for the standard recommendation: "police inbound (at remote end), shape outbound (at local end)."

5. A `show policy-map interface` output shows Shaping: no and Queue Depth: 0 even though traffic is flowing at 150% of the shaped CIR. What is the most likely cause?

A. The shaping policy was applied correctly but the shaper has disabled itself because the traffic is too bursty — shaping automatically deactivates when the burst ratio exceeds 1.5x CIR B. The physical interface speed is already at or below the CIR — IOS only activates shaping when the physical rate exceeds the shaped rate, and in this case they are equal C. The Be value is large enough to absorb the entire burst — all traffic is being sent within the Bc + Be token budget so the shaper never needs to activate a queue D. The service-policy was applied in the input direction instead of the output direction. IOS does not reject the configuration but shaping is not applied for inbound policies — traffic passes through uninhibited. show policy-map interface [intf] output would show the policy is actually on the input: check show running-config interface [intf] for service-policy input [name] and change it to service-policy output [name]

Correct answer is D. When service-policy input is configured with a policy containing a shape average command, IOS on many platforms does not reject the command but the shaping functionality silently does nothing — traffic passes through at line rate. The show policy-map interface output shows the policy structure but with no shaping activity (Shaping: no, Queue Depth: 0) because the shaping engine is never invoked for input-direction processing. Option C is plausible but incorrect for 150% of CIR — unless the Tc interval is very long and the Be bucket very large, sustained traffic at 150% of CIR would eventually drain the accumulated tokens and trigger shaping. The definitive diagnostic is to check the running configuration on the interface: if service-policy input PM-SHAPE appears, move the policy to the output direction. Always use show running-config interface [intf] to confirm policy attachment direction.

6. What is the markdown technique in policing, and why is it often preferred over dropping exceeded traffic?

A. Markdown means reducing the packet's IP TTL by 1 for every exceed event — this gracefully routes the packet along a longer path to reduce priority, eventually causing it to time out at a distant hop if it continues to exceed B. Markdown is the exceed action set-dscp-transmit [higher-drop-precedence] — the packet is forwarded but its DSCP is lowered to indicate higher drop eligibility (e.g. AF41 → AF43 or AF11 → AF13). The packet reaches the destination unless a downstream congested queue drops it first. This is preferred over hard dropping because it allows the network to carry the traffic when capacity is available, only discarding it at points of genuine congestion — preserving goodput when the network is not fully loaded while still protecting critical traffic under congestion C. Markdown converts exceeded packets to DSCP CS1 (scavenger) — this automatically places them in the scavenger queue at every downstream router, ensuring they only use leftover bandwidth D. Markdown is a shaping technique — exceeded packets are buffered and released at a lower rate (the "marked down" rate), which is Bc/2 of the original CIR

Correct answer is B. Markdown is a traffic management strategy that forwards excess packets but signals their lower priority by increasing the DSCP drop precedence within the same AF class. The key insight is that congestion is not always present — during off-peak periods, a link may have spare capacity and there is no benefit to dropping packets that exceed a per-session rate limit if the link is underutilised. Hard policing (drop on exceed) wastes that capacity. Markdown preserves the packets and forwards them at the slightly higher drop precedence — downstream WRED (Weighted Random Early Detection) queuing mechanisms will preferentially discard AF43 packets before AF41 when queue depth rises, achieving the rate control exactly where it is needed (at the congested hop) rather than universally at the marking point. This approach is common in MPLS DiffServ environments where the edge PE router marks exceeding traffic as AF*3 and core P routers implement WRED that drops AF*3 before AF*1 — the edge enforces the CIR conceptually while the core enforces it physically only under actual congestion.

7. A hierarchical policy has a parent `shape average 2000000` and a child policy with `priority 256` for VoIP. The link is congested. An engineer observes VoIP jitter despite the priority queue. What should be checked first?

A. Check whether the VoIP police rate in the child policy matches the priority bandwidth — if VoIP is generating more than 256 kbps, the priority police drops the excess VoIP packets, causing jitter. Also verify the child policy's priority bandwidth plus other class bandwidths do not exceed the parent shape rate — over-subscription within the shaped budget causes priority queue starvation. Run show policy-map interface output and check priority class offered rate vs the 256 kbps limit B. Increase the shape average rate — the 2 Mbps shape rate is insufficient for VoIP which requires at minimum 4 Mbps for priority queuing to function correctly C. Change the shaping type from shape average to shape peak — peak shaping allows VoIP packets to bypass the token bucket and transmit immediately D. The priority queue cannot be used inside a hierarchical shaping policy — reconfigure the policy as a flat (non-hierarchical) LLQ without the parent shaping

Correct answer is A. VoIP jitter inside a hierarchical shaping + LLQ policy has two common root causes. First: the VoIP source is generating more traffic than the priority bandwidth allocation — if 256 kbps is configured but VoIP calls are using 300 kbps, the priority police drops 44 kbps of VoIP traffic, causing packet loss and jitter. This is visible as exceeded drops on the priority class in show policy-map interface. Second: the total bandwidth allocated by the child policy (priority 256 + bandwidth 512 + bandwidth 128 + class-default) must not exceed the parent shape rate (2000 kbps). If it does, the scheduler over-commits within the shaped budget, and all classes including priority experience unpredictable service — the priority guarantee breaks down. The correct check sequence is: (1) verify the priority offered rate is at or below the configured kbps, (2) verify child policy total allocations ≤ parent CIR, (3) confirm the parent Tc is small enough that shaping granularity does not introduce jitter in the priority queue (smaller Bc = shorter Tc = lower priority queue delay variability).

8. `show policy-map interface` shows a policing class with conformed 1200 bps, exceeded 800000 bps. The police rate is configured as 1 Mbps. What does this reveal?

A. The policing is working correctly — 1200 bps conforms and 800 kbps exceeds, which is typical when the source is sending at 801.2 kbps against a 1 Mbps limit B. The CIR bucket is too small — the Bc is set to only 150 bytes causing excessive exceed events even for well-behaved traffic. Increase Bc to CIR/8 = 125,000 bytes C. The conformed rate of 1,200 bps is far below the 1 Mbps police rate — if the source were sending less than 1 Mbps, almost all traffic should conform. The exceeded rate of 800 kbps suggests the Bc value is extremely small (likely the default Bc was calculated incorrectly or the rate units are wrong). The most likely cause is the police rate was configured as police rate 1000 bps (1000 bits per second, not 1 Mbps) — the actual enforced rate is 1 kbps, so virtually all traffic exceeds it. Verify with show policy-map [name] to check the actual configured rate value D. This is expected output for the conform action transmit — the 1,200 bps represents control plane traffic and the 800 kbps represents data plane traffic which takes a separate forwarding path

Correct answer is C. This question tests the ability to recognise an impossible counter relationship. If the police rate is genuinely 1 Mbps, and the source is sending traffic at any rate up to 1 Mbps, virtually all packets should conform — the conformed counter should be close to the actual traffic rate, and exceeded should be low or zero. A conformed rate of only 1,200 bps (1.2 kbps) while 800 kbps exceeds the rate is only consistent with one scenario: the actual enforced rate is approximately 1.2 kbps — not 1 Mbps. The most common cause is a unit error during configuration: police rate 1000 without a unit specifier defaults to bps on some IOS versions, enforcing 1000 bps (1 kbps). The intended command was police rate 1000000 bps or police rate 1 mbps. The diagnostic is to run show policy-map [policy-name] which displays the configured rate, and compare it to the intended value. This type of unit confusion (kbps vs bps vs Mbps) is the single most common policing configuration error.

9. An ISP charges a customer based on a 2 Mbps CIR. The customer's WAN router physically connects at 100 Mbps Ethernet. Without any QoS policy, what happens when the customer sends traffic at 10 Mbps?

A. The 100 Mbps physical interface automatically limits output to the contractual 2 Mbps CIR — the interface speed negotiation between the customer router and ISP CPE enforces the contract B. The ISP's router sends TCP RST packets to terminate connections that exceed the CIR, enforcing the rate limit from the remote end C. The customer router queues the excess traffic internally at the WAN interface output queue and only forwards 2 Mbps — the ISP link speed is auto-negotiated to 2 Mbps during the MPLS handshake D. The customer router sends all 10 Mbps onto the 100 Mbps physical link without restriction. The ISP's edge router receives the burst and applies its own policing — dropping everything above 2 Mbps. The customer experiences random packet loss, TCP retransmits, poor throughput, and no QoS differentiation between voice and data. Configuring output shaping at 2 Mbps on the customer's WAN interface prevents this: the customer router buffers excess traffic and smoothly delivers 2 Mbps to the ISP, preventing upstream drops and allowing per-class queuing within the shaped rate

Correct answer is D. This question illustrates the fundamental motivation for WAN output shaping. A 100 Mbps physical Ethernet interface has no inherent rate enforcement for contractual commitments — it transmits whatever is in its output queue at 100 Mbps line rate. When a customer sends 10 Mbps toward a 2 Mbps contracted service, the frames leave the customer router at 100 Mbps and arrive at the ISP's CPE or PE router. The ISP enforces the 2 Mbps CIR with their own ingress policing — dropping everything above 2 Mbps without discrimination. The customer sees random packet drops affecting all traffic classes equally, destroying VoIP quality and degrading application performance. The solution is to configure shape average 2000000 on the customer WAN interface output — the customer router buffers all traffic above 2 Mbps locally and delivers a smooth 2 Mbps stream to the ISP. This eliminates ISP-side drops, and combined with a hierarchical child queuing policy, ensures VoIP and critical traffic are prioritised within the 2 Mbps budget. This is the canonical use case for WAN output shaping.

10. When would you choose policing over shaping for an outbound WAN policy, despite the fact that shaping avoids drops?

A. Always — shaping is never appropriate for outbound WAN because the added latency always outweighs the benefit of avoiding drops regardless of the application mix B. When the WAN link is fibre — shaping is only appropriate for legacy copper DSL/ADSL circuits where the line rate may vary C. Outbound policing is preferred over shaping when the traffic being rate-limited is real-time (VoIP RTP, interactive video) — shaping adds latency and jitter to buffered packets, which is worse than the packet loss that policing causes for these applications. VoIP handsets handle small amounts of packet loss gracefully (via FEC and jitter buffers) but cannot tolerate the 50–500 ms queuing delays that shaping may introduce. Policing the EF class to its bandwidth allocation (e.g. 256 kbps for VoIP) immediately drops any excess, preventing a build-up of queuing delay that would degrade every call D. Outbound policing is chosen when memory is limited — shaping requires large packet buffers which are unavailable on low-end routers, while policing only requires a small token counter with negligible memory usage

Correct answer is C. The "shaping avoids drops" advantage is only an advantage for applications that tolerate latency better than they tolerate loss — which is primarily bulk data (file transfers, backups) where TCP's retransmit mechanism handles drops gracefully and added latency is irrelevant. For real-time applications, the priority ordering is reversed: latency/jitter is more damaging than loss. A VoIP codec experiencing 20% packet loss can still produce intelligible audio through FEC (Forward Error Correction) and concealment algorithms. The same codec experiencing 200 ms of buffering delay will produce audio that is 200 ms out of sync with the speaker — perceived as a severe echo or lag. This is why policing (not shaping) is used to enforce the VoIP EF class rate limit: excess VoIP packets (which theoretically should not exist if the call count is managed) are dropped immediately without adding queuing delay to conforming packets. For the aggregate WAN rate (constraining all traffic to the ISP contracted CIR), shaping remains appropriate — the latency it introduces is acceptable for bulk data. The combination — shaped aggregate with policed per-class real-time traffic inside a hierarchical child policy — gives the best of both mechanisms.

Back to Home