QoS Traffic Policing & Shaping

1. What Are Policing and Shaping?

Traffic policing and traffic shaping are both QoS rate-enforcement mechanisms — they enforce a maximum traffic rate on an interface or traffic class. However, they differ fundamentally in what happens to traffic that exceeds the configured rate. Understanding this distinction is one of the most heavily tested QoS topics on the CCNA exam.

Both mechanisms use the concept of a Committed Information Rate (CIR) — the contracted or configured maximum average rate at which traffic is allowed to pass. Traffic at or below the CIR is said to conform. Traffic that exceeds the CIR is said to exceed (or violate in a dual-rate model). What happens to exceeding traffic is the key difference.

Aspect	Traffic Policing	Traffic Shaping
Exceeds-rate action	Drops or re-marks (changes DSCP/CoS) excess traffic immediately	Buffers excess traffic in a queue and sends it later when the rate allows
Delay introduced	None — packets are either forwarded or dropped/marked without waiting	Yes — buffered packets experience additional delay and jitter
Memory requirement	Minimal — no buffer needed for excess traffic	Requires a shaping queue buffer for excess packets
Traffic profile	Bursty — instantaneously enforces the rate ceiling; no smoothing	Smooth — spreads traffic evenly over time to match the rate
Typical application	Service provider ingress (customer-facing); inbound rate enforcement	Enterprise WAN egress; matching traffic rate to SP's CIR
Direction	Both ingress and egress	Egress only
Cisco MQC command	`police`	`shape average`

2. The Token Bucket Model

Both policing and shaping use a mathematical model called the token bucket to measure and enforce the traffic rate. Understanding the token bucket is essential for understanding how bursts are permitted and how the CIR is enforced over time.

2.1 How the Token Bucket Works

  Conceptual model:

  ┌─────────────────────────────────────────────────────────────────────┐
  │  Imagine a bucket that is filled with TOKENS at a constant rate    │
  │  equal to the CIR (Committed Information Rate).                    │
  │                                                                     │
  │  Tokens arrive:  CIR bits/sec (e.g., 1,000,000 tokens/sec = 1 Mbps│
  │  Bucket depth:   Bc (Committed Burst Size) = max tokens at one time│
  │                                                                     │
  │  When a packet arrives:                                             │
  │    ► Packet size ≤ tokens available → SEND the packet              │
  │       and consume that many tokens from the bucket                 │
  │    ► Packet size > tokens available → packet EXCEEDS the rate      │
  │       → policing: DROP or RE-MARK                                  │
  │       → shaping: BUFFER the packet until enough tokens accumulate  │
  └─────────────────────────────────────────────────────────────────────┘

  Token refill rate  =  CIR
  Maximum tokens     =  Bc  (bucket depth / committed burst)
  Excess burst       =  Be  (available only in dual-token model)

2.2 Key Token Bucket Parameters

Parameter	Full Name	Definition
CIR	Committed Information Rate	The contracted average rate in bits per second; the rate at which tokens are added to the bucket (e.g., 1 Mbps)
Bc	Committed Burst Size	The maximum number of bits (or tokens) the bucket can hold; how large a burst is permitted at the committed rate (e.g., 8,000 bytes = 64,000 bits)
Be	Excess Burst Size	An additional bucket used in the dual-token model; allows a second level of burst beyond Bc; traffic from Be is marked as "exceed" and may be dropped or re-marked (used in dual-rate / two-rate policing)
PIR	Peak Information Rate	Used in dual-rate policing (two-rate three-colour); the maximum rate the second token bucket allows — above PIR all traffic is "violate"
Tc	Committed Time Interval	Time interval over which Bc bits can be sent; Tc = Bc ÷ CIR (e.g., 64,000 bits ÷ 1,000,000 bps = 64 ms)

2.3 Token Bucket Burst Behaviour

  Why bursts are allowed:

  If traffic is quiet for a period, tokens accumulate in the bucket
  up to the Bc limit. When a burst of traffic arrives, it can use the
  accumulated tokens — allowing a short burst above the instantaneous
  rate without violating the average CIR.

  Example:
    CIR = 1 Mbps (1,000,000 bits/sec)
    Bc  = 125,000 bytes = 1,000,000 bits

  Scenario: No traffic for 1 second → bucket fills to Bc (1,000,000 tokens)
  Burst arrives: 1,000,000 bits in 0.1 second (10 Mbps instantaneous)
  All 1,000,000 tokens consumed → burst passes ✓ (average CIR honoured)

  After the burst: bucket is empty → no more tokens
  Next traffic must wait for tokens to refill at CIR rate (1 Mbps)

3. Traffic Policing in Detail

Traffic policing measures traffic against the CIR and takes an immediate action on conforming, exceeding, or violating traffic. There is no buffering — packets are either forwarded as-is, re-marked with a different DSCP/CoS value, or dropped at the moment of arrival.

3.1 Single-Rate Two-Colour Policing

The simplest policing model uses one token bucket with two traffic states: conform (at or below CIR) and exceed (above CIR).

  Single-Rate Two-Colour Model:

  Token bucket:  CIR = 1 Mbps,  Bc = 8,000 bytes

                    ┌─────────────┐
  Tokens added ────►│   Bucket    │ max = Bc tokens
  at CIR rate       │  (tokens)   │
                    └──────┬──────┘
                           │ packet arrives
                    ┌──────▼──────────────────┐
                    │  tokens ≥ packet size?  │
                    └──────┬────────┬─────────┘
                         YES       NO
                           │        │
                    CONFORM         EXCEED
                    (transmit)   (drop or re-mark)

3.2 Single-Rate Three-Colour Policing

Adds a second token bucket for the excess burst (Be), creating three traffic states: conform, exceed, and violate. This maps to RFC 2697 (srTCM — single-rate three-colour marker).

  Single-Rate Three-Colour (srTCM):

  Two buckets:  Bc bucket (committed)  +  Be bucket (excess)

  Packet arrives:
    Tokens in Bc bucket ≥ packet size  →  CONFORM  (transmit, mark green)
    Bc empty but Be tokens ≥ size       →  EXCEED   (transmit, mark yellow / re-mark DSCP)
    Both Bc and Be empty               →  VIOLATE  (drop or mark red)

3.3 Dual-Rate Three-Colour Policing

Uses two independent token buckets at different rates: CIR and PIR (Peak Information Rate). This maps to RFC 2698 (trTCM — two-rate three-colour marker), and is the model used by Cisco's police rate cir pir command.

  Dual-Rate Three-Colour (trTCM):

  Bucket 1: CIR (committed rate)
  Bucket 2: PIR (peak rate — always ≥ CIR)

  Packet arrives:
    Within CIR (tokens in CIR bucket ≥ size)  →  CONFORM  (transmit, green)
    Between CIR and PIR (PIR bucket has tokens) →  EXCEED   (transmit or re-mark, yellow)
    Above PIR (no tokens in either bucket)     →  VIOLATE  (drop, red)

  Example:
    CIR = 1 Mbps, PIR = 2 Mbps
    Traffic at 0.5 Mbps  → CONFORM  ✓
    Traffic at 1.5 Mbps  → EXCEED   (forward but mark lower DSCP)
    Traffic at 2.5 Mbps  → VIOLATE  (drop)

  This model is widely used by Service Providers to enforce SLA tiers.

3.4 Policing Actions

Traffic State	Common Action	Description
Conform	`transmit`	Forward the packet unchanged — it is within the committed rate
Exceed	`drop` or `set-dscp-transmit`	Drop the packet immediately, or re-mark its DSCP to a lower value (e.g., AF11 → AF12) and forward — allows downstream devices to drop it during congestion
Violate	`drop`	Drop the packet — traffic is well above the peak rate; no tolerance

Re-marking vs dropping: Re-marking exceeding traffic (changing DSCP to a lower-priority value) instead of dropping it is called policing with re-colouring. The packet is forwarded but tagged as eligible for dropping under congestion. This is preferred for data traffic where some elasticity is acceptable — video streaming that might tolerate occasional packet loss differently than interactive voice which should always be dropped cleanly above rate.

4. Traffic Shaping in Detail

Traffic shaping enforces the CIR by buffering packets that exceed the rate rather than dropping them. Excess packets are held in a shaping queue and released when the token bucket refills — smoothing the output traffic profile to match the CIR over time.

4.1 How Shaping Works

  Traffic Shaping Mechanism:

  ┌─────────────────────────────────────────────────────────────────────┐
  │  Packet arrives → Token check                                       │
  │                                                                     │
  │  Tokens available ≥ packet size?                                    │
  │    YES → Transmit immediately (consume tokens)                      │
  │    NO  → Place packet in SHAPING QUEUE (FIFO by default)           │
  │          Wait for token bucket to refill at CIR rate               │
  │          When enough tokens → dequeue and transmit                  │
  └─────────────────────────────────────────────────────────────────────┘

  Traffic profile comparison:

  Input traffic:  ████████████████▄▄▄▄▄▄▄▄████████████████  (bursty)
                       ↑ spike above CIR

  After policing: ████████████                    ████████  (spikes dropped)

  After shaping:  ██████████████████████████████████████    (smoothed to CIR)
                  (delayed but preserved — no packet loss)

4.2 Shaping Queue Behaviour

The shaping queue is a separate buffer specifically for traffic held back by the shaper. The size of this queue determines how much bursty traffic can be absorbed before packets are tail-dropped. The shaping queue can itself be scheduled by a queuing mechanism (e.g., CBWFQ or LLQ) to prioritise different traffic classes within the shaped stream.

  Shaping Queue Operation:

  Time 0:   1 Mbps CIR,  traffic burst arrives at 5 Mbps for 100 ms
  Tokens allow: 1 Mbps × 100 ms = 100,000 bits transmitted immediately
  Excess:   (5 Mbps - 1 Mbps) × 100 ms = 400,000 bits queued

  Time 100ms – 500ms: No new traffic arrives
  Shaper drains queue at 1 Mbps: 400,000 bits ÷ 1 Mbps = 400 ms to drain
  Packets delivered late but NOT dropped (assuming queue has space)

  If queue fills up (tail-drop):
  └── Packets ARE dropped even with shaping — queue depth matters!
      Configure adequate queue depth for expected burst size.

4.3 Shape Average vs Shape Peak

Shaping Type	Cisco Command	Behaviour	When to Use
Shape Average	`shape average <CIR>`	Smooths traffic to the average CIR over time; uses token bucket with Bc and Be; the standard shaping method	Matching egress traffic to an SP's contracted CIR — most common use
Shape Peak	`shape peak <CIR>`	Allows traffic to burst above CIR up to a peak rate; uses a larger effective token size	When the SP allows occasional bursting above the contracted CIR

5. Where Policing and Shaping Are Applied

Choosing the right mechanism depends entirely on the use case and the direction of traffic flow. The table below covers the standard deployment scenarios tested on the CCNA exam and encountered in real enterprise and SP networks.

Use Case	Mechanism	Direction	Reason
SP enforcing customer contract	Policing	Ingress (on SP PE router, customer-facing)	SP does not want to buffer customer traffic — excess is dropped or re-marked at the boundary immediately
Enterprise matching SP CIR on WAN egress	Shaping	Egress (on CE router, WAN-facing interface)	Enterprise does not want packets dropped by the SP; shaping keeps traffic within the SP's committed rate before it hits the SP boundary
Limiting a specific application or user	Policing	Ingress or egress (access layer)	Drops or re-marks bulk traffic (e.g., file transfers, P2P) to protect bandwidth for critical applications
Video conferencing rate control	Policing (with re-mark)	Egress	Re-marks video flows that exceed their class rate; preserves priority for real-time traffic rather than buffering it (buffering adds latency which is worse for video)
Frame Relay / ATM legacy WAN	Shaping	Egress	Frame Relay CIR enforcement; shaping queues prevent SP from discarding frames when customer bursts above CIR
Inter-site MPLS traffic management	Shaping (CE) + Policing (PE)	Both	CE shapes to match MPLS CIR; PE polices inbound from CE as contractual enforcement — a common dual-layer approach

5.1 Key Placement Rule

  ┌──────────────────────────────────────────────────────────────────────┐
  │  Enterprise (CE)                  Service Provider (PE)             │
  │                                                                      │
  │  WAN Interface (egress)  ────────►  Ingress of SP                   │
  │  └── SHAPING applied here         └── POLICING applied here        │
  │      (smooths to CIR so              (drops/re-marks excess         │
  │       SP never sees excess)           that arrives above CIR)       │
  │                                                                      │
  │  Rule:                                                               │
  │  Shape BEFORE traffic enters the SP to avoid SP-side policing drops │
  │  Police at INGRESS to protect local resources from external bursts  │
  └──────────────────────────────────────────────────────────────────────┘

Shaping is egress-only: Traffic shaping can only be applied in the egress direction — packets must be in a queue to be held back, and queues exist on the output side of an interface. Policing can be applied in both directions. Applying shaping at ingress is not supported by Cisco IOS.

6. Cisco MQC Configuration

Both policing and shaping are configured using the Cisco Modular QoS CLI (MQC) framework, which uses three building blocks: a class-map (what traffic to match), a policy-map (what to do with matched traffic), and a service-policy (where to apply the policy).

6.1 Traffic Policing Configuration

  ! ══════════════════════════════════════════════════════════════════
  !  Scenario: Police HTTP traffic to 512 kbps on ingress
  !  Conform: transmit  |  Exceed: re-mark DSCP AF12  |  Violate: drop
  ! ══════════════════════════════════════════════════════════════════

  ! Step 1 — Classify traffic
  class-map match-any HTTP-TRAFFIC
   match protocol http
   match protocol https

  ! Step 2 — Define policing policy
  policy-map WAN-INGRESS-POLICY
   class HTTP-TRAFFIC
    police rate 512000 bps
     conform-action transmit
     exceed-action  set-dscp-transmit af12
     violate-action drop

   class class-default
    police rate 1000000 bps
     conform-action transmit
     exceed-action  drop

  ! Step 3 — Apply to interface (ingress)
  interface GigabitEthernet0/1
   service-policy input WAN-INGRESS-POLICY

  ! ── Alternative: two-rate policing (CIR + PIR) ──
  policy-map DUAL-RATE-POLICY
   class BULK-DATA
    police rate 500000 bps peak-rate 1000000 bps
     conform-action  transmit
     exceed-action   set-dscp-transmit af21
     violate-action  drop

6.2 Traffic Shaping Configuration

  ! ══════════════════════════════════════════════════════════════════
  !  Scenario: Shape ALL egress traffic to 1 Mbps CIR (WAN link)
  ! ══════════════════════════════════════════════════════════════════

  ! Step 1 — No class-map needed if shaping all traffic
  !          OR define a class for specific traffic to shape

  ! Step 2 — Define shaping policy
  policy-map WAN-EGRESS-SHAPING
   class class-default
    shape average 1000000           ! 1 Mbps — units in bps

  ! Step 3 — Apply to WAN interface (egress only)
  interface Serial0/0/0
   service-policy output WAN-EGRESS-SHAPING

  ! ── Shape with nested policy (CBWFQ inside the shaping queue) ──
  ! This is hierarchical QoS (HQoS) — the parent policy shapes overall
  ! bandwidth; the child policy prioritises traffic inside the shaped stream

  policy-map CHILD-QUEUING
   class VOICE
    priority percent 30            ! LLQ — strict priority for voice
   class VIDEO
    bandwidth percent 25
   class class-default
    fair-queue

  policy-map PARENT-SHAPING
   class class-default
    shape average 1000000          ! Limit to 1 Mbps CIR
    service-policy CHILD-QUEUING   ! Apply queuing inside the shaper

  interface Serial0/0/0
   service-policy output PARENT-SHAPING

Hierarchical QoS (HQoS): Nesting a queuing policy inside a shaping policy is called Hierarchical QoS. The outer (parent) policy controls the overall bandwidth with shaping; the inner (child) policy applies CBWFQ or LLQ to prioritise traffic within the shaped stream. This is the standard enterprise design for WAN QoS — shape to match the SP CIR, then prioritise voice and video within that limited bandwidth.

7. Verification Commands

Command	What It Shows
`show policy-map interface <intf>`	Per-interface policy statistics — packets/bytes matched per class, conform/exceed/violate counters for policing, shaping queue depth and delay statistics
`show policy-map interface <intf> input`	Statistics for the service-policy applied in the input direction on the specified interface
`show policy-map interface <intf> output`	Statistics for the service-policy applied in the output (egress) direction — shaping queue depth, tokens, delay visible here
`show class-map`	All defined class-maps and their match criteria
`show policy-map`	All defined policy-maps and their configured actions (police/shape rates, queuing parameters)
`show traffic-shape`	Summary of shaping configurations on all interfaces — CIR, Bc, Be, queue depth
`show traffic-shape statistics`	Shaping statistics — packets shaped, queue depth, tokens available, packets delayed vs dropped

7.1 Sample Output – show policy-map interface Serial0/0/0

  Router# show policy-map interface Serial0/0/0

  Serial0/0/0
    Service-policy output: PARENT-SHAPING

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

        Traffic Shaping
          Target/Average   Byte   Sustain   Excess    Interval  Increment
            Rate           Limit  bits/int  bits/int  (ms)      (bytes)
          1000000/1000000  15000  8000      8000      64        1000

          Adapt  Queue  Packets   Bytes     Packets   Bytes     Shaping
          Active Depth  Delayed   Delayed   Dropped   Dropped   Active
          -      0      142       178736    0         0         yes

        Service-policy : CHILD-QUEUING
          Class-map: VOICE (match-any)
            12443 packets, 1991264 bytes
            5 minute offered rate 26000 bps, drop rate 0000 bps
            Priority: 30% (300000 bps), burst bytes 7500
            Priority packets dropped: 0

          Class-map: class-default (match-any)
            8722 packets, 1394732 bytes
            5 minute offered rate 18000 bps, drop rate 0000 bps
            Fair-queue: per-flow queue limit 64 packets

8. Troubleshooting Policing and Shaping

Symptom	Likely Cause	Fix
All traffic being dropped — even at low rates	CIR configured too low (e.g., 8000 bps instead of 8,000,000 bps); units are in bps — easy to miscalculate	Verify CIR value in `show policy-map interface`; Cisco IOS `police rate` uses bps — 1 Mbps = 1000000, not 1000
Shaping configured but traffic still being dropped by SP	Shaping applied to wrong interface or wrong direction (input instead of output); or shape rate set above SP's actual CIR	Verify with `show traffic-shape`; shaping must be `service-policy output` on the WAN-facing interface; confirm CIR with SP contract
Voice quality poor even with QoS policies applied	Shaping introduces additional delay and jitter; voice traffic being placed in the shaping queue rather than given strict priority via LLQ	Use HQoS: apply LLQ/priority queue inside the shaping policy via a child policy-map; ensure voice is in a `priority` class, not the default queue
Policing counters show zero conform and all drops	Class-map not matching the correct traffic; protocol classification or ACL in the class-map is wrong	Check `show class-map` and test matching with `debug ip packet`; verify ACL or NBAR match criteria
Shaping queue fills up and packets are dropped	Sustained burst is too large for the queue depth or duration is too long for the shaped rate to drain	Increase queue depth (`shape average <CIR> <Bc> <Be>`); or consider policing as an alternative if buffer delay is unacceptable for the application
Policy applied but `show policy-map interface` shows no matched packets	Service-policy applied to the wrong interface or wrong direction; or traffic is not reaching that interface	Verify with `show run interface <intf>` that `service-policy` is present; confirm traffic path with `traceroute`

9. Key Terms Quick Reference

Term	Definition
Traffic Policing	A QoS rate-enforcement mechanism that immediately drops or re-marks packets that exceed the CIR — no buffering; can be applied ingress or egress
Traffic Shaping	A QoS rate-enforcement mechanism that buffers excess packets and releases them when the rate allows — smooths traffic to the CIR; egress only; introduces delay
Token Bucket	The mathematical model used by both policing and shaping; tokens are added at the CIR rate and consumed by passing packets — available tokens allow bursting
CIR	Committed Information Rate — the contracted average rate; tokens are refilled at this rate; traffic at or below CIR conforms
Bc	Committed Burst Size — the maximum bucket depth; how large a burst can be transmitted instantly at the committed rate
Be	Excess Burst Size — a second token bucket that allows traffic beyond Bc to be transmitted or marked as exceed rather than immediately dropped
PIR	Peak Information Rate — used in dual-rate policing; the upper bound above which all traffic is violate; traffic between CIR and PIR is exceed
Conform	Traffic state for packets at or below the CIR; default action is transmit unchanged
Exceed	Traffic state for packets above CIR but within the excess burst allowance; default action is drop or re-mark DSCP
Violate	Traffic state in three-colour policing for packets above both the CIR and PIR/Be — default action is drop
Re-marking	Changing a packet's DSCP or CoS value in the policing exceed action instead of dropping it — marks the packet as lower priority for downstream congestion management
MQC	Modular QoS CLI — Cisco's three-step QoS configuration framework: class-map (match) → policy-map (action) → service-policy (apply)
Shape Average	The standard Cisco shaping command; smooths traffic to the average CIR using the token bucket; the most common shaping type
HQoS	Hierarchical QoS — nesting a child queuing policy (LLQ/CBWFQ) inside a parent shaping policy to apply traffic prioritisation within a rate-limited stream

10. QoS Policing & Shaping – Practice Quiz

1. What is the fundamental difference between traffic policing and traffic shaping when a packet exceeds the configured CIR?

A. Policing buffers excess packets in a queue; shaping drops or re-marks them immediately B. Policing drops or re-marks excess packets immediately without buffering; shaping buffers excess packets and releases them later at the allowed rate C. Policing applies only to ingress traffic; shaping applies only to egress traffic, but both drop excess packets D. They are functionally identical — both smooth traffic to the CIR using a token bucket

Correct answer is B. This is the most fundamental QoS distinction on the CCNA exam. Policing takes immediate action — packets exceeding the CIR are dropped or re-marked with no delay. Shaping holds exceeding packets in a buffer (shaping queue) and transmits them later when the token bucket refills — this preserves the packets at the cost of additional delay and jitter. Policing = drop/mark. Shaping = buffer/delay.

2. An enterprise router connects to an SP via a 10 Mbps physical link, but the SP contract is for a 2 Mbps CIR. The SP polices inbound traffic at 2 Mbps and drops excess. What should the enterprise configure on the WAN interface to prevent packet loss?

A. Policing at 2 Mbps egress — drop enterprise traffic that exceeds 2 Mbps before it reaches the SP B. Policing at 10 Mbps ingress — limit what the SP can send back C. Shaping at 2 Mbps egress — buffer any traffic above 2 Mbps before it reaches the SP, smoothing the output to match the contracted CIR D. No action needed — the SP's policer handles rate enforcement automatically

Correct answer is C. When an SP polices inbound traffic at 2 Mbps, any enterprise traffic above 2 Mbps is dropped by the SP — causing random packet loss. To prevent this, the enterprise applies egress shaping at 2 Mbps on the WAN interface. The shaper buffers bursts and releases them at a smooth 2 Mbps, so the SP never sees excess traffic. Option A (policing) would also enforce the rate but would drop the excess packets on the enterprise side — wasting them rather than delivering them slightly late. Shaping is preferred where packet preservation matters.

3. In the token bucket model, what does the Bc parameter represent?

A. The committed burst size — the maximum number of bits (tokens) the bucket can hold at one time, determining how large a burst can be transmitted at the CIR without exceeding B. The committed information rate — the rate at which tokens are added to the bucket C. The bandwidth ceiling — the maximum physical line rate of the interface D. The burst counter — the number of packets in the shaping queue at any moment

Correct answer is A. Bc (Committed Burst Size) is the depth of the token bucket — the maximum number of bits/tokens it can accumulate. If traffic is quiet for a period, tokens accumulate up to Bc. When a burst arrives, it can use these stored tokens to transmit up to Bc bits instantaneously without violating the CIR average. The CIR determines the token refill rate. Bc determines how much burst capacity can accumulate during idle periods.

4. Traffic shaping can be applied in which direction on a Cisco IOS interface?

A. Input (ingress) only B. Both input and output C. Neither — shaping is a platform-level feature not applied per-interface D. Output (egress) only — packets must be in a queue to be delayed, and queues exist only on the output side of an interface

Correct answer is D. Traffic shaping can only be applied in the egress direction. The fundamental mechanism of shaping is buffering — excess packets are held in a shaping queue. Queues exist on the output side of an interface (packets waiting to be transmitted). There is no equivalent input queue for holding and delaying incoming packets before they enter the router. Policing, in contrast, can be applied in both directions because it requires no buffer — it simply acts on packets as they arrive or leave.

5. A policing policy is configured with `conform-action transmit`, `exceed-action set-dscp-transmit af12`, and `violate-action drop`. A packet arrives at 1.5× the CIR. What happens?

A. The packet is buffered until the rate drops below CIR B. The packet is forwarded but its DSCP value is changed to AF12 — the exceed action re-marks it as lower priority rather than dropping it C. The packet is dropped because it is above the CIR D. The packet triggers the violate action because 1.5× CIR is above the PIR

Correct answer is B. At 1.5× CIR, the traffic exceeds the CIR but the exceed action (not violate) is triggered. The exceed action here is set-dscp-transmit af12 — the packet is forwarded but its DSCP is re-marked to AF12, which is a lower drop precedence than AF11. This makes the packet eligible to be dropped by downstream congestion mechanisms without wasting it immediately. The violate action (drop) would only trigger if a third threshold (PIR or the Be bucket being empty) was exceeded.

6. Which Cisco MQC command applies traffic shaping to the default class at 2 Mbps?

A. police rate 2000000 bps conform-action transmit B. bandwidth 2000 C. shape average 2000000 inside a policy-map class D. rate-limit output 2000000 conform-action transmit

Correct answer is C. The Cisco MQC shaping command is shape average <rate-in-bps>, entered inside a policy-map class block. shape average 2000000 shapes traffic to a 2 Mbps average CIR. The police rate command (option A) is for policing, not shaping. The bandwidth command allocates queuing bandwidth, not rate limiting. rate-limit is the legacy CAR (Committed Access Rate) policing command, not MQC shaping.

7. Why does traffic shaping introduce additional latency compared to traffic policing?

A. Shaping buffers excess packets in a queue and holds them until the token bucket refills — the time spent waiting in the queue adds delay and jitter to the traffic flow B. Shaping requires more CPU processing to calculate the token bucket, adding processing delay per packet C. Shaping re-marks packets with a new DSCP value, and this re-marking process takes additional processing time D. Shaping applies to ingress traffic which must traverse the routing table twice, adding forwarding delay

Correct answer is A. Shaping latency is directly caused by buffering. When a packet cannot be sent immediately (because the token bucket is empty), it sits in the shaping queue. The time between when the packet arrived and when it is finally transmitted is the shaping delay. For bursty TCP data this is acceptable. For real-time traffic (voice, video conferencing) this delay is problematic — which is why shaping is used for data/WAN rate matching, not for voice, and why LLQ inside HQoS is used to exempt voice from the shaping queue.

8. What is Hierarchical QoS (HQoS) and why is it used on WAN interfaces?

A. HQoS applies policing at the core layer and shaping at the access layer to create a hierarchy of rate limits across the network B. HQoS uses multiple class-maps nested inside each other to match traffic based on multiple criteria simultaneously C. HQoS applies DSCP marking at Layer 3 and CoS marking at Layer 2 simultaneously on the same interface D. HQoS nests a child queuing policy (LLQ/CBWFQ) inside a parent shaping policy — the parent limits overall bandwidth to the SP CIR; the child prioritises voice, video, and data within that limited bandwidth

Correct answer is D. Hierarchical QoS is the standard design for enterprise WAN interfaces where bandwidth must be both limited (to match the SP CIR) and prioritised (to protect voice and video within that limited budget). The parent policy-map uses

shape
                  average

to enforce the CIR. The child policy-map applies priority (LLQ) for voice and bandwidth (CBWFQ) for other classes. Without HQoS, shaping alone would queue everything equally, and voice would suffer delay from waiting behind bulk data.

9. In dual-rate three-colour policing, traffic arrives at a rate between the CIR and the PIR. What traffic state is this, and what is the typical action?

A. Conform — the traffic is within the committed range and is transmitted unchanged B. Exceed — the traffic is above CIR but below PIR; it is typically forwarded with a lower DSCP re-mark to indicate it is eligible for dropping under downstream congestion C. Violate — traffic between CIR and PIR is always dropped in dual-rate policing D. Burst — there is a fourth state called burst for traffic between the two rates

Correct answer is B. In dual-rate three-colour policing (trTCM — RFC 2698), there are three states: conform (≤ CIR, green, transmit), exceed (between CIR and PIR, yellow, re-mark and transmit), and violate (above PIR, red, drop). Traffic between CIR and PIR uses the exceed action — typically forwarded but re-marked with a lower DSCP (e.g., AF21 instead of AF22) to indicate it is the first to be dropped if congestion occurs downstream. This is widely used by service providers to provide a tiered SLA: guaranteed at CIR, best-effort up to PIR.

10. A network engineer applies a shaping policy at 1 Mbps on a WAN interface. During peak hours, users report intermittent packet loss even though the shaped rate is set correctly. What is the most likely cause?

A. Shaping does not work on serial interfaces — only on Ethernet B. The CIR is set too high — reducing it will stop the packet loss C. The shaping queue is filling up and tail-dropping packets — sustained bursts above 1 Mbps are longer than the queue can absorb; the shaping queue has finite depth and drops packets when full D. Shaping and policing cannot coexist on the same interface — remove any policing policy to fix the drops

Correct answer is C. Shaping prevents packet loss only as long as the shaping queue has space. If a sustained burst is significantly above the CIR for an extended period, the queue fills up and the tail-drop mechanism kicks in — dropping packets just as policing would. The fix is to either increase the shaping queue depth (to absorb larger bursts) or investigate why sustained traffic is consistently above 1 Mbps — which may indicate the CIR needs renegotiation with the SP, or that application traffic needs to be policed or rate-limited upstream before reaching the WAN interface.

← Back to Home