Hands-On Lab: Configuring Traffic Shaping and Policing

Lab Objective

Configure traffic shaping on one interface limiting outbound rate by buffering excess traffic, configure traffic policing on a separate interface limiting rate by dropping excess traffic outright, and generate traffic exceeding each configured rate to directly observe the behavioral difference between the two mechanisms.

Lab Purpose

The QoS lab covered earlier in this series configured priority queuing for voice traffic but did not address the two primary mechanisms for enforcing a maximum rate on non-priority traffic. Shaping and policing both limit throughput to a configured rate, but their fundamentally different handling of excess traffic — buffer versus drop — makes them suited to different scenarios.

Lab Topology

R1
  Gi0/1 (shaped, toward WAN link A)
  Gi0/2 (policed, toward WAN link B)

Both links have an actual physical
bandwidth of 100 Mbps, but the contracted
rate with the provider is 10 Mbps on each

Task 1: Configure Traffic Shaping on Gi0/1

Configure class-based shaping limiting outbound traffic on Gi0/1 to 10 Mbps.

Task 2: Configure Traffic Policing on Gi0/2

Configure class-based policing limiting outbound traffic on Gi0/2 to 10 Mbps, dropping traffic exceeding this rate.

Task 3: Generate Traffic Exceeding the Rate on Gi0/1

Generate a burst of traffic exceeding 10 Mbps toward Gi0/1 and observe the resulting behavior.

Task 4: Generate Traffic Exceeding the Rate on Gi0/2

Generate the identical burst toward Gi0/2 and observe the resulting behavior.

Task 5: Compare Latency and Loss Between the Two Approaches

Measure and compare the latency and packet loss characteristics of the shaped versus policed traffic during the burst.

Solution and Verification

R1(config)# class-map match-all ALL-TRAFFIC
R1(config-cmap)# match any

R1(config)# policy-map SHAPE-POLICY
R1(config-pmap)# class ALL-TRAFFIC
R1(config-pmap-c)# shape average 10000000

-- Shaping smooths traffic to the configured
-- rate by holding excess traffic in a
-- buffer/queue and releasing it later,
-- rather than discarding it immediately

R1(config)# interface gigabitethernet0/1
R1(config-if)# service-policy output SHAPE-POLICY

R1(config)# policy-map POLICE-POLICY
R1(config-pmap)# class ALL-TRAFFIC
R1(config-pmap-c)# police 10000000 conform-action transmit exceed-action drop

-- Policing enforces a hard rate limit --
-- traffic exceeding it is dropped
-- immediately, with no buffering at all

R1(config)# interface gigabitethernet0/2
R1(config-if)# service-policy output POLICE-POLICY

TrafficGen> [generates a burst of 20 Mbps
             toward Gi0/1 for 10 seconds]

R1# show policy-map interface gigabitethernet0/1

  Service-policy output: SHAPE-POLICY
    Class-map: ALL-TRAFFIC
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 12/0/0
      shape (average) cir 10000000, bc 40000, be 40000
-- Traffic queued (depth 12) rather than
-- dropped -- the burst is smoothed out
-- over a slightly longer period, at the
-- cost of added latency for the delayed
-- packets, but with ZERO drops

TrafficGen> [generates the identical burst
             toward Gi0/2]

R1# show policy-map interface gigabitethernet0/2

  Service-policy output: POLICE-POLICY
    Class-map: ALL-TRAFFIC
      police:
        cir 10000000 bps
        conformed 1250000 bytes; actions:
          transmit
        exceeded 1250000 bytes; actions:
          drop
-- Roughly half the traffic (the portion
-- exceeding 10 Mbps) was dropped
-- immediately -- no queuing delay was
-- introduced, but real data loss occurred

-- Latency/loss comparison:

Gi0/1 (shaped):  0% packet loss, increased
                 latency during the burst
                 (buffered packets delayed)

Gi0/2 (policed): ~50% packet loss during
                 the burst, but no added
                 latency for packets that
                 did get through

Key Takeaway

Shaping trades increased latency for zero loss by buffering excess traffic and releasing it later, making it well-suited to traffic that tolerates delay but not loss (bulk data transfers, for instance), while policing trades occasional loss for consistent, unbuffered latency by dropping excess traffic outright — the correct choice between them depends entirely on whether the specific traffic being managed is more sensitive to delay or to loss, a distinction with no universally correct answer across every traffic type.