LLQ — Low Latency Queuing for Voice

A router's output interface is a single pipe — every packet waits its turn in a queue before being transmitted. For bulk data transfers, waiting a few milliseconds is irrelevant. For a VoIP call, a packet that waits 50 ms behind a 1,500-byte file transfer chunk introduces jitter that the receiving phone's jitter buffer must absorb. Enough of these delays and the jitter buffer overflows, packets are discarded, and the call degrades to clipping and silence. Low Latency Queuing (LLQ) solves this by creating a strict-priority queue that is always served before any other queue. VoIP packets never wait — they bypass the normal scheduling and transmit at the first opportunity. See QoS Overview and QoS Queuing for background on queuing mechanisms and Voice VLAN for Layer 2 voice traffic separation.

LLQ is implemented in Cisco IOS by adding the priority command to a class inside an MQC policy-map. The priority class receives strict preemptive service at every scheduling interval. The remaining bandwidth is distributed among other classes by CBWFQ (Class-Based Weighted Fair Queuing), which guarantees minimum bandwidth to each class and fairly shares any remaining capacity. Together, LLQ + CBWFQ forms the standard Cisco WAN QoS architecture for mixed voice-and-data networks. This page builds a complete policy from scratch, explains every bandwidth calculation, and shows exactly how to read the verification output to confirm VoIP is receiving priority treatment at every hop.

LLQ acts on DSCP markings applied at the network edge — for the marking step see DSCP Marking & Classification. For the rate-limiting that protects the priority queue from being saturated see Traffic Policing and Shaping. For the QoS overview that contextualises all queuing steps see MQC QoS Basics, QoS Overview, QoS Queuing, and QoS Marking.

1. Queuing Architecture — Why LLQ Exists

Queuing Models Compared

Model	How It Works	Voice Suitability	IOS Command
FIFO	Single queue — packets dequeued in arrival order. Default on interfaces above 2 Mbps with no QoS policy	Poor — large data packets ahead of VoIP cause unpredictable jitter	(default — no command)
WFQ	Weighted Fair Queuing — automatically creates per-flow queues and allocates bandwidth proportionally by precedence. Default on interfaces below 2 Mbps	Moderate — VoIP gets fair share but no latency guarantee; large flows can still cause bursts of delay	`fair-queue`
CBWFQ	Class-Based WFQ — administrator defines traffic classes and assigns minimum bandwidth guarantees. Excess bandwidth shared fairly among classes	Better — bandwidth guaranteed but still no strict latency bound; voice packets may wait one scheduling cycle behind data	`bandwidth [kbps]` or `bandwidth percent`
LLQ	CBWFQ + a strict priority queue. The priority class is always served before bandwidth classes — zero wait time. Other classes share remaining bandwidth via CBWFQ	Excellent — bounded latency and jitter. The priority queue introduces near-zero additional delay regardless of other traffic	`priority [kbps]` or `priority percent`
PQ (legacy)	Four fixed priority levels — high, medium, normal, low. Higher queues starve lower queues completely if always busy	Good for voice but data starvation risk; replaced by LLQ in modern deployments	`priority-list` (legacy)

LLQ Scheduler — How Priority and CBWFQ Coexist

  Outbound interface scheduler (runs every Tc interval):

  ┌────────────────────────────────────────────────────────────┐
  │  Step 1: Is the PRIORITY QUEUE non-empty?                  │
  │    YES → dequeue one packet from priority queue            │
  │           (repeat until priority queue empty OR            │
  │            priority bandwidth quota consumed this interval) │
  │    NO  → proceed to Step 2                                  │
  ├────────────────────────────────────────────────────────────┤
  │  Step 2: Service CBWFQ classes in weighted round-robin      │
  │    Each class gets bandwidth proportional to its weight     │
  │    (configured kbps or percent allocation)                  │
  │    Unused bandwidth shared among active classes             │
  ├────────────────────────────────────────────────────────────┤
  │  Step 3: class-default gets remaining bandwidth             │
  │    (WFQ within class-default if fair-queue configured)      │
  └────────────────────────────────────────────────────────────┘

  Key constraint: priority kbps + sum of all bandwidth kbps
                  MUST be ≤ 75% of interface bandwidth
                  (IOS reserves 25% for overhead by default)

VoIP Bandwidth Calculation

  Per-call bandwidth requirement (G.711 codec, default packetisation):
  ─────────────────────────────────────────────────────────────────
  Payload:          160 bytes  (20 ms of G.711 at 64 kbps)
  RTP header:        12 bytes
  UDP header:         8 bytes
  IP header:         20 bytes
  Layer 2 header:    18 bytes  (Ethernet — varies by WAN type)
  Total per packet: 218 bytes
  Packets per sec:   50 pps    (1000 ms ÷ 20 ms packetisation)
  Bandwidth/call:   218 × 50 × 8 = 87,200 bps ≈ 87.2 kbps

  G.729 codec (compressed voice — 8 kbps payload):
  Payload:           20 bytes  (20 ms of G.729)
  Headers (same):    58 bytes
  Total per packet:  78 bytes
  Bandwidth/call:    78 × 50 × 8 = 31,200 bps ≈ 31.2 kbps

  Rule of thumb:
    G.711 per call ≈ 87 kbps   (use 90 kbps for margin)
    G.729 per call ≈ 32 kbps   (use 35 kbps for margin)
  Maximum calls formula:
    LLQ priority kbps ÷ per-call kbps = max simultaneous calls
    e.g. priority 512 ÷ 90 = 5 G.711 calls  (with margin)

2. Lab Topology & Bandwidth Plan

  [IP Phones + PCs — 192.168.10.0/24]
         │
    Gi0/1 (LAN — 1 Gbps)
    192.168.10.1/24
  NetsTuts-R1                          NetsTuts-R2
    Gi0/0 (WAN — 8 Mbps contracted) ──── Gi0/0 (WAN)
    10.0.0.1/30                          10.0.0.2/30
                                          Gi0/1 (LAN)
                                          192.168.20.1/24

  WAN interface bandwidth: physically 100 Mbps Ethernet
  ISP contracted CIR:       8 Mbps  (must shape to this)
  QoS budget within 8 Mbps:

  ┌──────────────────────────────────────────────────────────┐
  │ Class           │ DSCP  │ Mechanism │ Bandwidth          │
  ├──────────────────────────────────────────────────────────┤
  │ VoIP RTP        │ EF    │ LLQ       │  512 kbps (6.4%)   │
  │ VoIP Signalling │ CS3   │ CBWFQ     │  128 kbps (1.6%)   │
  │ Interactive Vid │ AF41  │ CBWFQ     │ 2000 kbps (25.0%)  │
  │ Critical Apps   │ AF31  │ CBWFQ     │ 1500 kbps (18.8%)  │
  │ Bulk Data       │ AF11  │ CBWFQ     │  500 kbps (6.3%)   │
  │ class-default   │ BE    │ fair-queue│ remaining ~3360 kbps│
  │─────────────────────────────────────────────────────────|
  │ Total allocated │       │           │ 4640 kbps (58.0%)  │
  │ Reserved (25%)  │       │           │ 2000 kbps          │
  │ Default class   │       │           │~3360 kbps (42%)    │
  └──────────────────────────────────────────────────────────┘
  Note: 512+128+2000+1500+500 = 4640 kbps < 75% of 8000 = 6000 kbps ✓

The policy is applied output on Gi0/0, inside a parent shaping policy that shapes the 100 Mbps physical interface down to the 8 Mbps ISP contracted rate. The LLQ + CBWFQ child policy operates within that 8 Mbps shaped budget. Without the parent shaping policy, the 100 Mbps interface would burst traffic at the ISP who would drop anything above 8 Mbps — and all QoS markings would be irrelevant as drops would be random. For traffic shaping and policing details see Traffic Policing and Shaping and QoS Policing & Shaping. For basic interface configuration see Basic Interface Configuration.

3. Step 1 — Define Class-Maps

The queuing policy classifies inbound-marked traffic by DSCP value. Traffic must already be marked at the ingress interface (see DSCP Marking & Classification) before it reaches the egress queuing policy:

NetsTuts-R1>en
NetsTuts-R1#conf t

! ── VoIP RTP — strict priority class ────────────────────
class-map match-any CM-VOIP-RTP
 match dscp ef
!
! ── VoIP signalling (SIP, H.323, SCCP) ──────────────────
class-map match-any CM-VOIP-SIG
 match dscp cs3
!
! ── Interactive video (telepresence, video calls) ────────
class-map match-any CM-VIDEO
 match dscp af41
!
! ── Critical business applications (SAP, ERP) ────────────
class-map match-any CM-CRITICAL
 match dscp af31
!
! ── Bulk data (backups, FTP, email) ──────────────────────
class-map match-any CM-BULK
 match dscp af11
!
! ── Scavenger / low priority ─────────────────────────────
class-map match-any CM-SCAVENGER
 match dscp cs1
!

All class-maps use match dscp rather than ACLs because DSCP matching at the egress queue is far more efficient — the DSCP field is a single byte in the IP header, read in hardware with negligible overhead. ACL matching at the egress queue would re-evaluate every packet against extended ACLs, consuming CPU for each forwarded packet. The ingress marking policy (separate policy-map applied input on the LAN interface) has already classified and stamped the correct DSCP value, so the egress queuing policy simply reads that stamp. This separation of classification (ingress) from queuing (egress) is the recommended MQC design pattern. See DSCP Marking & Classification for full ingress marking configuration and QoS Marking for DSCP value reference.

4. Step 2 — Configure the LLQ + CBWFQ Child Policy

The child policy defines the queuing and scheduling behaviour. The priority command creates the strict priority queue (LLQ); bandwidth commands create CBWFQ queues with guaranteed minimums; class class-default with fair-queue applies WFQ to all remaining traffic:

! ════════════════════════════════════════════════════════
! Child queuing policy — operates within 8 Mbps budget
! ════════════════════════════════════════════════════════
policy-map PM-QUEUE-WAN
 !
 ! ── LLQ: strict priority queue for VoIP RTP ──────────
 ! ── Bandwidth = 512 kbps supports ~5 G.711 calls ─────
 class CM-VOIP-RTP
  priority 512
 !
 ! ── CBWFQ: guaranteed bandwidth for signalling ───────
 class CM-VOIP-SIG
  bandwidth 128
 !
 ! ── CBWFQ: guaranteed bandwidth for video ────────────
 class CM-VIDEO
  bandwidth 2000
 !
 ! ── CBWFQ: guaranteed bandwidth for critical apps ────
 class CM-CRITICAL
  bandwidth 1500
 !
 ! ── CBWFQ: minimum bandwidth for bulk data ───────────
 class CM-BULK
  bandwidth 500
 !
 ! ── Scavenger: minimal guarantee — leftover only ─────
 class CM-SCAVENGER
  bandwidth 8
 !
 ! ── Default: WFQ among all unclassified traffic ──────
 class class-default
  fair-queue
 !
!

The priority 512 command allocates 512 kbps as the strict priority budget. This means up to 512 kbps of EF-marked traffic can be dequeued ahead of everything else. If VoIP traffic exceeds 512 kbps (more calls than planned), the excess is dropped by the built-in priority policer — not queued. This is intentional: protecting all other classes from complete starvation if the priority class is overloaded. The bandwidth [kbps] values represent guaranteed minimums — not maximums. If video is allocated 2,000 kbps and only uses 500 kbps, the unused 1,500 kbps is shared among other active classes. The total explicit allocations (512+128+2000+1500+500+8 = 4,648 kbps) must stay below 75% of the parent shape rate (8,000 × 0.75 = 6,000 kbps), which they do comfortably.

Bandwidth Percent Alternative

! ── Equivalent policy using percentage (easier to scale) ─
policy-map PM-QUEUE-WAN-PCT
 class CM-VOIP-RTP
  priority percent 6
  ! ── 6% of 8 Mbps = 480 kbps (≈ 5 G.711 calls) ────────
 !
 class CM-VIDEO
  bandwidth percent 25
  ! ── 25% of 8 Mbps = 2000 kbps ─────────────────────────
 !
 class CM-CRITICAL
  bandwidth percent 19
 !
 class CM-BULK
  bandwidth percent 6
 !
 class class-default
  fair-queue
 !
!

The percent form calculates bandwidth as a percentage of the interface or parent shape rate. If the WAN rate is later changed (say, upgraded to 20 Mbps), a percent-based policy automatically scales all class allocations without reconfiguration. Absolute kbps values require manual recalculation. The 75% ceiling still applies — sum of all percent values must not exceed 75%. In a hierarchical policy (parent shapes, child queues), the percent is calculated against the parent shape rate, not the physical interface speed.

5. Step 3 — Parent Shaping Policy and Interface Application

The child queuing policy attaches to the parent shaping policy. The parent controls the WAN aggregate rate; the child controls packet ordering within the shaped budget. The combined policy is applied output-only on the WAN interface:

! ── Parent policy: shape to 8 Mbps ISP contracted rate ──
! ── Bc = 100000 bytes → Tc = 100 ms (smooth shaping) ────
policy-map PM-SHAPE-PARENT
 class class-default
  shape average 8000000 100000
  service-policy PM-QUEUE-WAN
 !
!
! ── Apply to WAN egress interface ────────────────────────
interface GigabitEthernet0/0
 description WAN-Uplink-ISP
 ip address 10.0.0.1 255.255.255.252
 service-policy output PM-SHAPE-PARENT
 no shutdown
!
! ── Ingress marking policy on LAN interface ──────────────
! ── (See DSCP Marking lab for full config) ───────────────
interface GigabitEthernet0/1
 description LAN-User-Access
 ip address 192.168.10.1 255.255.255.0
 service-policy input PM-MARK-INBOUND
 no shutdown
!
NetsTuts-R1(config)#end
NetsTuts-R1#wr
Building configuration...
[OK]

The service-policy PM-QUEUE-WAN inside the parent class-default attaches the child queuing policy to the shaping queue. When the shaper holds excess packets, the child policy determines the order in which they are released — VoIP in the priority class is always dequeued first, regardless of how much video or bulk data has accumulated in the shaping buffer. Without this hierarchy, the shaping queue would be FIFO — VoIP and bulk data would be released in arrival order, completely defeating the purpose of the priority queue. The Bc of 100,000 bytes gives a Tc of 100 ms (100,000 × 8 ÷ 8,000,000 × 1000 = 100 ms) — smooth 100 ms scheduling intervals with minimal burst peaks. After completing configuration run wr or see Saving & Managing Cisco Configurations for persistence best practices.

Verify Policy Attachment

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

 GigabitEthernet0/0

  Service-policy output: PM-SHAPE-PARENT

    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 Limit  SUSTAIN  bytes/int  EXCESS  bytes/int
        8000000/8000000  100000      800000   100000     1000000 100000

      Service-policy : PM-QUEUE-WAN

        Class-map: CM-VOIP-RTP (match-any)
          0 packets, 0 bytes
          Priority: 512 kbps, burst bytes 12800, b/w exceed drops: 0
          Match: dscp ef (46)

        Class-map: CM-VOIP-SIG (match-any)
          0 packets, 0 bytes
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          bandwidth 128 kbps
          Match: dscp cs3 (24)

        Class-map: CM-VIDEO (match-any)
          0 packets, 0 bytes
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          bandwidth 2000 kbps
          Match: dscp af41 (34)

        Class-map: CM-CRITICAL (match-any)
          0 packets, 0 bytes
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          bandwidth 1500 kbps
          Match: dscp af31 (26)

        Class-map: CM-BULK (match-any)
          0 packets, 0 bytes
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          bandwidth 500 kbps
          Match: dscp af11 (10)

        Class-map: class-default (match-any)
          0 packets, 0 bytes
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0
          bandwidth remaining ratio 1
          Match: any

Before traffic flows all counters are zero — this output confirms the hierarchical policy is correctly attached. The Priority: 512 kbps line under CM-VOIP-RTP confirms LLQ is active; note there is no "queue limit" line for the priority class because the priority class does not queue — it transmits immediately or drops. The burst bytes 12800 is the built-in priority burst allowance (512 kbps × 25 ms / 1000 × 1000 = 12,800 bytes by default — approximately 25 ms worth of priority bandwidth). All CBWFQ classes show queue limit 64 packets — the default tail-drop limit for each class's FIFO queue.

6. Step 4 — Verification with Live Traffic

show policy-map interface — With All Classes Active

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

 GigabitEthernet0/0

  Service-policy output: PM-SHAPE-PARENT

    Class-map: class-default (match-any)
      312450 packets, 468675000 bytes
      5 minute offered rate 7820000 bps, drop rate 0000 bps
      Match: any
      Traffic Shaping
        Target/Average   Byte Limit  SUSTAIN  bytes/int  EXCESS   bytes/int  Interval  Increment
        8000000/8000000  100000      800000   100000     1000000  100000     100        100000

        Adapt   Queue   Packets   Bytes       Packets  Bytes   Shaping
        Active  Depth   Delayed   Delayed     FECN     BECN
           -      8     14820     22230000       0        0      yes

      Service-policy : PM-QUEUE-WAN

        Class-map: CM-VOIP-RTP (match-any)
          18420 packets, 29472000 bytes
          5 minute offered rate 248000 bps, drop rate 0000 bps
          Match: dscp ef (46)
            18420 packets, 29472000 bytes
          Priority: 512 kbps, burst bytes 12800, b/w exceed drops: 0

        Class-map: CM-VOIP-SIG (match-any)
          342 packets, 68400 bytes
          5 minute offered rate 2800 bps, drop rate 0000 bps
          Match: dscp cs3 (24)
            342 packets, 68400 bytes
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          bandwidth 128 kbps

        Class-map: CM-VIDEO (match-any)
          28140 packets, 50652000 bytes
          5 minute offered rate 1984000 bps, drop rate 0000 bps
          Match: dscp af41 (34)
            28140 packets, 50652000 bytes
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 2/0/0
          bandwidth 2000 kbps

        Class-map: CM-CRITICAL (match-any)
          12820 packets, 20512000 bytes
          5 minute offered rate 1492000 bps, drop rate 0000 bps
          Match: dscp af31 (26)
            12820 packets, 20512000 bytes
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 1/0/0
          bandwidth 1500 kbps

        Class-map: CM-BULK (match-any)
          8410 packets, 12615000 bytes
          5 minute offered rate 492000 bps, drop rate 12000 bps
          Match: dscp af11 (10)
            8410 packets, 12615000 bytes
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/48/0
          bandwidth 500 kbps

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

Reading the live output systematically reveals the health of every class. CM-VOIP-RTP: b/w exceed drops: 0 — the priority queue is not being overloaded; all VoIP traffic is being served immediately. The offered rate (248 kbps) is safely below the 512 kbps budget. CM-VIDEO queue depth: 2 — two packets are currently waiting in the video CBWFQ queue; this is normal under load and confirms the shaper is active. CM-BULK: total drops 48 — 48 packets have been tail-dropped from the bulk queue because it reached its 64-packet limit. This is expected and acceptable — bulk TCP flows will retransmit. The drop rate of 12,000 bps confirms active congestion management for the lowest-priority classified traffic. Shaping: yes confirms the parent shaper is actively smoothing output to 8 Mbps.

show policy-map interface — Priority Class Detail

NetsTuts-R1#show policy-map interface GigabitEthernet0/0 output class CM-VOIP-RTP

 GigabitEthernet0/0

  Service-policy output: PM-SHAPE-PARENT

    Service-policy : PM-QUEUE-WAN

      Class-map: CM-VOIP-RTP (match-any)
        18420 packets, 29472000 bytes
        5 minute offered rate 248000 bps, drop rate 0000 bps
        Match: dscp ef (46)
          18420 packets, 29472000 bytes
        Priority: 512 kbps, burst bytes 12800, b/w exceed drops: 0

        Output Queue: Conversation 264
        (pkts matched/bytes matched) 18420/29472000
        (depth/total drops/no-buffer drops) 0/0/0

Isolating the priority class with the class [name] suffix shows the most critical voice QoS metric: b/w exceed drops: 0. This counter increments when VoIP traffic exceeds the 512 kbps priority bandwidth budget — the built-in priority policing drops the excess. Zero drops here means every VoIP packet has been forwarded with strict priority treatment. A non-zero value indicates either more VoIP calls than planned (call admission control needed) or VoIP is being mismarked at EF when it should not be (rogue EF traffic consuming the priority budget). The depth: 0 confirms no VoIP packets are queued — they are dequeued immediately on arrival, exactly as LLQ is designed to work.

show policy-map interface — Monitoring Over Time

! ── Check specific counters during a call ────────────────
NetsTuts-R1#show policy-map interface Gi0/0 output | include exceed
            Priority: 512 kbps, burst bytes 12800, b/w exceed drops: 0

! ── Monitor queue depth for all classes (repeat every 5 sec) ──
NetsTuts-R1#show policy-map interface Gi0/0 output | include depth
        (queue depth/total drops/no-buffer drops) 0/0/0
        (queue depth/total drops/no-buffer drops) 2/0/0
        (queue depth/total drops/no-buffer drops) 1/0/0
        (queue depth/total drops/no-buffer drops) 0/48/0
        (queue depth/total drops/no-buffer drops) 0/0/0

! ── Watch drop rate on priority class ────────────────────
NetsTuts-R1#show policy-map interface Gi0/0 output | include drop rate
          5 minute offered rate 248000 bps, drop rate 0000 bps
          5 minute offered rate   2800 bps, drop rate 0000 bps
          5 minute offered rate 1984000 bps, drop rate 0000 bps
          5 minute offered rate 1492000 bps, drop rate 0000 bps
          5 minute offered rate  492000 bps, drop rate 12000 bps

! ── Clear counters to get a fresh measurement ────────────
NetsTuts-R1#clear counters GigabitEthernet0/0
Clear "show interface" counters on this interface [confirm]

The | include filter technique is essential for monitoring specific metrics across all classes simultaneously without scrolling through the full output. The

drop rate
    12000 bps

on the bulk class (last line) confirms the CBWFQ is actively managing congestion for lower-priority traffic while drop rate 0000 bps on VoIP, signalling, video, and critical apps confirms those classes are receiving their guaranteed bandwidth. Run clear counters before a QoS test to reset cumulative drop and packet counters, then measure for a known time period to get accurate rates. For general interface counters and error statistics see show interfaces and show ip interface brief.

Simulating a VoIP Call — Verify Priority Behaviour

! ── Generate background bulk traffic to create congestion ─
! ── (from a second host on the LAN) ──────────────────────

! ── From R1, ping the remote phone with small packets ────
! ── to simulate VoIP-sized packets during congestion ─────
NetsTuts-R1#ping 192.168.20.10 repeat 1000 size 218 df-bit
Type escape sequence to abort.
Sending 1000, 218-byte ICMP Echos to 192.168.20.10, timeout 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (1000/1000), round-trip min/avg/max = 1/2/4 ms

! ── Compare with bulk transfer sized packets ─────────────
NetsTuts-R1#ping 192.168.20.10 repeat 100 size 1400 df-bit
Type escape sequence to abort.
Sending 100, 1400-byte ICMP Echos to 192.168.20.10, timeout 2 seconds:
!!!!!!!!!!!!!.!.!!!.!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 94 percent (94/100), round-trip min/avg/max = 1/8/47 ms

The ping test simulates the QoS difference under congestion. Small 218-byte packets (VoIP-sized) achieve 100% success rate with 1/2/4 ms round-trip times — zero jitter. Larger 1,400-byte packets (bulk-sized) show 6% packet loss (tail-drop from the bulk queue) and significantly higher latency (max 47 ms) — the congestion management is working. In production, use a VoIP quality testing tool (Cisco IP SLA with jitter probes) rather than ping to measure actual call metrics.

7. Step 5 — IP SLA Jitter Probe for VoIP Quality Validation

Cisco IP SLA creates synthetic UDP jitter probes that simulate VoIP RTP streams and measure the exact quality metrics that determine call quality — latency, jitter, and packet loss. For full IP SLA configuration and scheduling see IP SLA Configuration & Tracking and IP SLA Syslog Alerting:

! ════════════════════════════════════════════════════════
! On NetsTuts-R2 (responder end) — enable IP SLA responder
! ════════════════════════════════════════════════════════
NetsTuts-R2#conf t
ip sla responder
!
! ════════════════════════════════════════════════════════
! On NetsTuts-R1 (sender) — configure jitter probe
! ════════════════════════════════════════════════════════
NetsTuts-R1#conf t

ip sla 1
 udp-jitter 192.168.20.1 16384 codec g711ulaw
 ! ── Destination: R2 LAN IP, port 16384 (RTP range) ────
 ! ── Codec: G.711 — sets packet size and pps automatically
 tos 184
 ! ── ToS 184 decimal = 0xB8 = DSCP EF (46) in ToS byte ─
 frequency 60
 ! ── Run probe every 60 seconds ─────────────────────────
!
ip sla schedule 1 life forever start-time now
!
! ── Wait 60 seconds then check results ───────────────────
NetsTuts-R1#show ip sla statistics 1

IPSLAs Latest Operation Statistics

IPSLA operation id: 1
        Latest RTT: 2 milliseconds
Latest operation start time: 14:32:18.421 UTC Thu Mar 12 2026
Latest operation return code: OK
RTT Values:
        Number Of RTT: 1000         RTT Min/Avg/Max: 1/2/4 milliseconds
Latency one-way time:
        Number of Latency one-way Samples: 500
        Source to Destination Latency one way Min/Avg/Max: 1/1/3 milliseconds
        Destination to Source Latency one way Min/Avg/Max: 1/1/2 milliseconds
Jitter Time:
        Number of SD Jitter Samples: 999
        Number of DS Jitter Samples: 999
        Source to Destination Jitter Min/Avg/Max: 0/1/3 milliseconds
        Destination to Source Jitter Min/Avg/Max: 0/0/2 milliseconds
Packet Loss Values:
        Loss Source to Destination: 0        Loss Destination to Source: 0
        Out Of Sequence: 0     Tail Drop: 0      Late Arrival: 0
Voice Score Values:
        Calculated Planning Impairment Factor (ICPIF): 0
        MOS score: 4.40

The IP SLA jitter probe provides definitive VoIP quality evidence. The critical metrics are: Jitter Avg: 1 ms (excellent — ITU G.114 recommends <30 ms jitter); Loss: 0 (zero packet loss for EF-marked traffic); MOS score: 4.40 (Mean Opinion Score on a 1–5 scale — scores above 4.0 indicate toll-quality voice; 4.40 is excellent). The tos 184 command sets DSCP EF (decimal value 184 in the ToS byte = 46 × 4 = 184) so the probe traffic is handled by the priority queue, accurately reflecting actual VoIP conditions. A MOS score below 3.6 or jitter above 30 ms indicates the LLQ policy needs review — either priority bandwidth is insufficient, the priority queue has exceeded drops, or the DSCP marking is not reaching the egress policy. For MPLS-based WAN QoS with EXP bit marking see MPLS. For DMVPN overlay QoS see DMVPN Phase 1, 2 & 3.

8. Troubleshooting LLQ and CBWFQ

Problem	Symptom	Cause	Fix
Priority queue exceed drops non-zero	`show policy-map interface` shows `b/w exceed drops: [N]` on the priority class; VoIP calls experiencing degraded quality despite LLQ configuration	VoIP is generating more traffic than the priority bandwidth allows — too many simultaneous calls, oversized codec (G.711 where G.729 was planned), or non-VoIP traffic being mismarked as EF 46 and consuming the priority budget	Increase `priority [kbps]` to accommodate actual call volume (recalculate: calls × per-call bandwidth). Audit EF-marked traffic sources — a PC marking all its traffic as EF consumes priority budget. Add call admission control at the CUCM or CUBE to limit simultaneous calls. Check ingress marking policy is enforcing `set dscp default` on class-default to erase fraudulent EF markings
IOS rejects policy-map — bandwidth exceeds 75%	`% Cannot add more bandwidth: [total] kbps is more than max threshold [max] kbps` error when configuring bandwidth classes	Sum of all `priority` + `bandwidth` allocations exceeds 75% of the interface or parent shape bandwidth — IOS enforces this ceiling to reserve 25% for overhead and class-default	Reduce individual class bandwidth allocations. Recalculate: sum of all class kbps must be ≤ 0.75 × interface or parent shape rate. If using a parent shape policy, IOS calculates the 75% against the shape rate, not the physical interface speed. Use `bandwidth percent` to make the ceiling easier to manage — total percentages must not exceed 75%
CBWFQ queue drops causing application timeouts	`show policy-map interface` shows non-zero total drops on a critical application class (CM-CRITICAL); application users report session timeouts and performance issues	Critical application class bandwidth allocation is insufficient for the actual traffic load; or the class queue limit (default 64 packets) is too small causing tail-drop before CBWFQ can serve the queue	Increase the `bandwidth [kbps]` allocation for the critical class. Increase the queue limit with `queue-limit [packets]` inside the class to allow more buffering. Consider WRED with `random-detect dscp-based` instead of tail-drop to more gracefully manage queue depth for TCP flows
Queuing policy has no effect — FIFO behaviour observed	All traffic classes show zero queue depth and identical latency; VoIP experiences same jitter as bulk data during congestion	Service-policy applied in the input direction (queuing policies must be output); parent shaping policy missing (physical interface is not congested — queuing only activates when a queue builds, which requires a congestion point); or policy-map not attached to the interface	Confirm `service-policy output [name]` on the WAN interface. Verify the parent shaping policy is present and shaping: `show policy-map interface [intf] output \| include Shaping` should show "yes" during traffic. Without a parent shaper on a high-speed physical interface, the output queue rarely builds and CBWFQ/LLQ have no effect — traffic exits faster than it arrives
Video class starving bulk class completely	Bulk data transfers showing near-zero throughput; video class offered rate matches or exceeds its bandwidth allocation; `show policy-map interface` shows bulk class drops but video class queue depth zero	Video bandwidth allocation (2,000 kbps) plus other classes consuming most of the 8 Mbps budget, leaving insufficient bandwidth for class-default and bulk. CBWFQ guarantees minimums but if total allocations are near the 75% ceiling, little remains for class-default and under-allocated classes	Review bandwidth allocation percentages — ensure the sum leaves adequate bandwidth for lower-priority classes and class-default. Add a maximum bandwidth cap on the video class with `bandwidth max [kbps]` (on newer IOS) to prevent video from consuming excess bandwidth. Alternatively, add policing within the video class to cap it at its allocated rate even when spare bandwidth exists
VoIP works but MOS score remains below 4.0	IP SLA shows zero LLQ exceed drops, zero packet loss, but MOS score 3.4–3.8; jitter is low but one-way latency is 80–120 ms	LLQ is functioning but the end-to-end propagation delay is too high — likely a WAN circuit with high inherent latency (satellite, long-haul MPLS). LLQ reduces queuing delay but cannot reduce propagation delay. Alternatively, the Tc (shaping interval) is too large, adding shaping delay that appears as latency to the VoIP stream	Reduce the shaping Bc value for a shorter Tc (e.g. Bc = 10,000 bytes → Tc = 10 ms) to minimise shaping-induced latency. Verify with `show ip sla statistics` one-way latency values — propagation delay is fixed; queuing and shaping delay are controllable. For very latency-sensitive paths consider a dedicated QoS class at the ISP level (MPLS EXP bits)
Child policy bandwidth total accepted but voice still impacted	Policy-map configured without errors; `show policy-map` shows correct values; but during congestion voice quality degrades similarly to pre-QoS	Ingress marking policy not applied — traffic arriving at the egress queuing policy is unmarked (DSCP 0) so all packets land in class-default and are treated as best-effort. LLQ and CBWFQ classify by DSCP — if packets arrive unclassified, the class-maps match nothing	Verify the ingress marking policy: `show policy-map interface [LAN-intf] input` — check EF class "Packets marked" counter is incrementing. Confirm `service-policy input [mark-policy]` is applied to the LAN interface. Test by checking `show policy-map interface [WAN-intf] output` — if all traffic lands in class-default, marking is not reaching the egress policy

Key Points & Exam Tips

LLQ is CBWFQ + a strict priority queue. The priority [kbps] command creates the priority class; bandwidth [kbps] creates CBWFQ classes. Both exist in the same policy-map.
The priority class is always served first — packets in the priority queue are dequeued before any CBWFQ class receives service. This is what eliminates queuing delay for VoIP.
The priority class has a built-in policer — if EF traffic exceeds the configured kbps, excess packets are dropped immediately to prevent the priority queue from starving all other classes. Monitor b/w exceed drops to detect oversubscription.
CBWFQ bandwidth guarantees are minimums, not maximums. Unused bandwidth from any class is shared proportionally among all active classes. A class with bandwidth 500 may transmit at 2,000 kbps if other classes are idle.
The sum of all priority + bandwidth kbps values must not exceed 75% of interface (or parent shape) bandwidth. IOS enforces this ceiling to reserve capacity for class-default and overhead.
Queuing policies must be applied output on the interface where congestion occurs. On a high-speed physical interface with no parent shaping, queuing rarely activates — traffic flows faster than it arrives and no queue builds. A parent shaping policy creates the artificial congestion point that forces the queuing policy to operate.
The hierarchical policy is the complete WAN QoS solution: parent shape average [CIR] controls the WAN rate; child LLQ + CBWFQ controls packet ordering within the shaped rate. Without hierarchy, the shaping queue is FIFO and VoIP waits behind bulk data.
VoIP bandwidth per call: G.711 ≈ 87 kbps, G.729 ≈ 32 kbps (including all headers). Calculate the priority kbps as: max simultaneous calls × per-call bandwidth + 10% margin.
Verify with show policy-map interface [intf] output: check priority class b/w exceed drops: 0 (no overload), CBWFQ classes total drops appropriate for class priority, and queue depth reflects real-time congestion state.
For the CCNP exam: know that LLQ is enabled by the priority command (not bandwidth); know the 75% bandwidth ceiling rule; know that the priority queue has a built-in policer; and know that queuing is meaningless without a congestion point (parent shaping or low-speed WAN interface).

Next Steps: LLQ + CBWFQ is the queuing layer — it depends on traffic being correctly marked upstream. For the DSCP marking policy that feeds this queuing policy see DSCP Marking & Classification. For the parent shaping policy that creates the WAN rate constraint that activates queuing see Traffic Policing and Shaping. To extend QoS across a DMVPN overlay and ensure LLQ operates correctly inside tunnels see DMVPN Phase 1, 2 & 3. For the full QoS design framework that positions LLQ in context see QoS Overview, QoS Queuing, and QoS Policing & Shaping. For measuring VoIP quality with IP SLA see IP SLA Configuration & Tracking. For voice VLAN configuration on the access layer see Voice VLAN Configuration.

TEST WHAT YOU LEARNED

1. What is the fundamental difference between the `priority` command and the `bandwidth` command in an MQC policy-map, and why does this difference matter for VoIP?

A. Both commands guarantee the same amount of bandwidth — priority is simply the newer syntax that replaces bandwidth for real-time traffic classes B. priority allocates bandwidth as a percentage; bandwidth allocates in absolute kbps. VoIP requires percentage allocation to scale with interface speed changes C. priority creates a strict-preemptive queue — packets in the priority class are always dequeued before any other class receives service, regardless of how many packets are waiting in other queues. This bounds the queuing delay to near-zero. bandwidth creates a CBWFQ class that is served in weighted round-robin with other classes — it guarantees a minimum bandwidth share but packets may wait one full scheduling cycle, introducing variable latency. VoIP requires the bounded latency of priority; bandwidth alone cannot eliminate jitter D. priority applies to inbound traffic; bandwidth applies to outbound traffic. VoIP uses priority because VoIP traffic primarily flows inbound from the WAN

Correct answer is C. This is the most important conceptual distinction in LLQ. The priority command places the class into a strict priority queue that preempts all other queues — when the scheduler runs, it first checks the priority queue and serves all waiting packets (up to the bandwidth limit) before considering any CBWFQ class. The result is that a VoIP packet arriving at any point in the scheduling cycle is dequeued at the next scheduling interval with near-zero wait. bandwidth creates a CBWFQ queue that participates in weighted round-robin scheduling — the scheduler visits each CBWFQ class in proportion to its weight, meaning a packet may wait through one full cycle of all other classes being served. Under congestion, a CBWFQ class with 512 kbps bandwidth allocation might see 10–40 ms of scheduling delay before its queue is served. For G.711 voice packets at 50 pps with a 30 ms jitter budget, even a single scheduling cycle of delay can consume the entire jitter allowance. The strict preemption of priority is the only mechanism that truly eliminates this variable delay.

2. A policy-map has `priority 512` for VoIP and `bandwidth 2000` for video on an 8 Mbps shaped WAN interface. An engineer tries to add `bandwidth 4000` for a new critical apps class. IOS rejects the command. Why?

A. The sum of all priority + bandwidth allocations would be 512 + 2000 + 4000 = 6,512 kbps, which exceeds 75% of the 8 Mbps parent shape rate (6,000 kbps). IOS reserves 25% of interface bandwidth as an absolute ceiling — this ensures class-default always has capacity and prevents the scheduler from being over-committed. Reduce the critical apps bandwidth to ≤ 3,488 kbps or reduce other class allocations to bring the total under 6,000 kbps B. Only one bandwidth class and one priority class are allowed per policy-map — adding a third class requires a hierarchical child policy C. The bandwidth allocation must be in multiples of the interface CIR divided by 8 — 4000 kbps is not a valid multiple for an 8 Mbps interface D. bandwidth 4000 exceeds the individual class limit of 3000 kbps — each class may not receive more than 3/8 of the interface bandwidth

Correct answer is A. IOS enforces a hard ceiling that the sum of all priority and bandwidth class allocations cannot exceed 75% of the interface (or parent shape) bandwidth. For an 8 Mbps shaped interface: 8,000 × 0.75 = 6,000 kbps maximum. With priority 512 + bandwidth 2,000 + proposed bandwidth 4,000 = 6,512 kbps — 512 kbps over the limit. The 25% reservation exists for two reasons: class-default must have some bandwidth available (otherwise unclassified traffic would receive nothing), and the scheduler itself requires overhead. The error message IOS displays is typically "% Cannot add more bandwidth: [current total] kbps is more than max threshold [max] kbps." The fix is to reduce one or more existing allocations. Using bandwidth percent rather than absolute kbps makes it easier to stay within the 75% ceiling — simply ensure the sum of all percentages stays at or below 75%.

3. `show policy-map interface` shows b/w exceed drops: 2840 on the priority class. VoIP calls are experiencing packet loss. What does this indicate and how should it be resolved?

A. The priority class queue is full — increase the queue limit from 64 to 256 packets to give VoIP more buffer space B. The CBWFQ classes are consuming too much bandwidth — reduce bandwidth allocations on video and critical apps classes to free up more capacity for the priority queue C. The parent shaping rate is too low — increase shape average to allow more bandwidth for the priority class to operate within D. EF-marked traffic is exceeding the configured 512 kbps priority budget — the built-in priority policer is dropping the excess. This means either more simultaneous VoIP calls than planned (calculate: drops rate ÷ per-call kbps = excess calls), non-VoIP traffic is being mismarked as EF (check ingress marking policy), or the priority bandwidth is under-provisioned. Resolution: increase priority [kbps] to match actual call capacity, audit EF-marked traffic sources with show ip nbar protocol-discovery, and verify the ingress marking policy drops fraudulent EF markings via class class-default → set dscp default

Correct answer is D. The b/w exceed drops counter on the priority class is unique to LLQ — it has no equivalent on CBWFQ classes. This counter increments when the EF-marked traffic rate exceeds the configured priority kbps value. The priority class has a built-in policer that enforces the bandwidth limit by dropping excess packets — this prevents the priority queue from consuming 100% of the interface and starving all other classes (the "voice starvation" problem of legacy pure priority queuing). The drops are not from a queue filling up (the priority class has no queue — it transmits or drops immediately) but from the rate limiter. Diagnostic sequence: (1) check show policy-map interface output | include offered for the VoIP class — if offered rate approaches or exceeds 512 kbps, capacity is insufficient; (2) check the ingress marking policy for unintended EF-marked traffic; (3) calculate whether the actual call count matches the priority allocation. A common cause is G.711 calls being planned as G.729 during capacity design — the codec negotiates upward and each call consumes nearly 3x more priority bandwidth than planned.

4. A router has an LLQ + CBWFQ policy applied to its WAN interface. During a period with zero VoIP calls (priority class traffic = 0 bps), the video class is transmitting at 3,000 kbps despite having only `bandwidth 2000`. Is this correct behaviour, and why?

A. No — this indicates a misconfiguration. bandwidth 2000 is a hard cap; the video class must never transmit above 2,000 kbps. Add a police rate 2000 kbps within the class to enforce the ceiling B. Yes — bandwidth [kbps] in CBWFQ is a guaranteed minimum, not a maximum. When the priority class has no traffic, its 512 kbps allocation is unused. CBWFQ distributes unused bandwidth among active classes proportionally to their weights. The video class, having the largest allocation (2,000 kbps), receives the largest share of the unused priority bandwidth — resulting in effective throughput above 2,000 kbps. This is expected and desirable behaviour that maximises link utilisation C. No — the video class should not be able to exceed its allocation regardless of other class activity. This behaviour indicates the policy-map was applied in the wrong direction D. Yes, but only because the WAN link is below 50% utilisation — CBWFQ only enforces bandwidth limits when total utilisation exceeds 50% of the interface rate

Correct answer is B. CBWFQ bandwidth allocations are minimum guarantees — they define the floor for each class during congestion, not a ceiling. When a class has no traffic (like the priority class in this scenario), its allocated bandwidth slots go unused. CBWFQ redistributes these unused slots among active classes in proportion to their configured weights. Since video has the largest weight (2,000), it receives the largest share of unclaimed bandwidth. This behaviour is correct and beneficial — it prevents wasted link capacity when some classes are idle. The "when we need it, we get it; when we don't, others can use it" principle is a core CBWFQ design goal. If you need a hard ceiling on a class (e.g. to prevent video from consuming backup bandwidth even when the link is otherwise idle), add a police rate [max-kbps] within that class — the combination of a minimum bandwidth guarantee (CBWFQ) and a maximum rate cap (policing) gives full control over both floors and ceilings.

5. Why does LLQ only activate (begin providing latency benefit) when the interface is congested, and what creates the congestion point on a high-speed Ethernet WAN interface?

A. LLQ always provides latency benefit regardless of congestion level — the priority queue is always served first even when the link is underutilised B. LLQ requires minimum 50% link utilisation to activate — below this threshold IOS uses FIFO queuing and LLQ is suspended C. LLQ activates automatically on all interface types except Gigabit Ethernet — GigE interfaces require legacy PQ instead of LLQ for VoIP D. Queuing only has effect when multiple packets are waiting for the same output interface — if the interface can transmit packets faster than they arrive, there is no queue and every packet is served immediately regardless of class. On a 100 Mbps physical WAN interface carrying 8 Mbps of traffic, packets pass through in microseconds with no queuing delay. To create the congestion point where LLQ matters, a parent shape average 8000000 policy artificially limits output to 8 Mbps — the shaping queue builds when traffic bursts above 8 Mbps, and the LLQ child policy then determines the order packets leave the shaping queue

Correct answer is D. This is one of the most commonly misunderstood aspects of QoS deployment. A QoS queuing policy is only effective when there is competition for the interface — when more packets arrive than the interface can immediately transmit. On a 100 Mbps physical interface carrying 8 Mbps of traffic, the interface is only 8% utilised. Every packet exits within microseconds of arrival; there is no queue depth and no scheduling decision required. LLQ, CBWFQ, FIFO — they all produce identical results because there is nothing to prioritise. The congestion point is manufactured by the parent shaping policy: shape average 8000000 creates a virtual 8 Mbps gate — when traffic bursts above 8 Mbps, the shaper holds packets in a queue. This shaping queue is where the LLQ child policy operates. Without the parent shaper (or without a physical WAN link that is itself at or near capacity), LLQ is configured but inactive. This is why real-world WAN QoS deployments always combine parent shaping with child queuing rather than applying the queuing policy alone.

6. An engineer configures `bandwidth percent 25` for video and `priority percent 10` for VoIP inside a child policy of a parent `shape average 8000000`. What are the absolute kbps values for each class, and against what rate is the percentage calculated?

A. In a hierarchical policy the percentage is calculated against the parent shape rate (8,000 kbps). VoIP priority: 10% × 8,000 = 800 kbps. Video bandwidth: 25% × 8,000 = 2,000 kbps. The physical interface speed (100 Mbps) is irrelevant — the child policy operates within the shaped 8 Mbps budget. This is why percent-based allocation is preferred for hierarchical policies: if the parent shape rate changes, all child allocations scale automatically B. The percentage is calculated against the physical interface speed (100 Mbps). VoIP: 10 Mbps. Video: 25 Mbps. These values far exceed the shape rate and IOS will warn about over-allocation C. The percentage is calculated against the remaining bandwidth after the parent shape overhead is reserved. Parent shaping reserves 25% of 8 Mbps = 2 Mbps. Available bandwidth = 6 Mbps. VoIP: 10% × 6,000 = 600 kbps. Video: 25% × 6,000 = 1,500 kbps D. Percentage is not supported inside a child policy of a hierarchical shaping configuration — only absolute kbps values are valid in child policies

Correct answer is A. In a hierarchical MQC policy, the child policy's bandwidth percentage is always calculated against the rate at which the parent class releases traffic — which is the parent shape rate (8,000 kbps for shape average 8000000). The physical interface rate is irrelevant because the child policy's context is the shaping queue, which is bounded by the shape rate. This is the primary advantage of percent-based allocation in hierarchical policies: when the parent shape rate changes (e.g. WAN upgrade from 8 Mbps to 20 Mbps), the child class allocations automatically recalculate in absolute kbps without any policy reconfiguration. VoIP will get 2,000 kbps (10% of 20 Mbps) automatically, and the 75% ceiling check also scales — no manual adjustment needed. Compare this to absolute kbps values: bandwidth 2000 for video would be 25% of the old 8 Mbps rate but only 10% of the new 20 Mbps rate, meaning video is now under-provisioned relative to its intended share of the WAN budget. For this reason, percent-based policies are strongly recommended for any deployment where WAN rates may change.

7. The IP SLA jitter probe shows MOS: 3.3 and jitter avg: 2 ms with zero packet loss. The LLQ priority class shows zero exceed drops. What is the most likely cause of the poor MOS score?

A. Zero packet loss and low jitter are impossible simultaneously with a MOS of 3.3 — the IP SLA probe result is invalid and should be re-run B. The MOS calculation is broken on this IOS version — upgrade to a newer release to fix the IP SLA MOS computation algorithm C. MOS is calculated from the combination of packet loss, jitter, AND one-way latency. Zero loss and low jitter but a MOS of 3.3 indicates high one-way latency — likely above 100–150 ms. Check show ip sla statistics for the one-way latency field. High latency is caused by WAN propagation delay (unrelated to LLQ) or by a large Tc shaping interval introducing shaping-buffering delay. LLQ eliminates queuing jitter but cannot reduce propagation delay D. The jitter probe codec is mismatched — G.711 was configured but the actual calls use G.729. Run the probe with codec g729r8 to get an accurate MOS reading

Correct answer is C. The ITU E-model used to calculate MOS (and its simplified form, ICPIF — Calculated Planning Impairment Factor) incorporates three independent impairment factors: packet loss, inter-arrival jitter, and one-way delay. Each factor degrades MOS independently. A path with zero packet loss and 2 ms jitter but 150 ms one-way delay will produce a MOS of approximately 3.2–3.5 depending on the codec — users perceive the conversation as stilted because each speaker must wait 300 ms (150 ms each way) to hear a response. This symptom is characteristic of long-haul WAN circuits (intercontinental MPLS, satellite links) where propagation delay is inherent to the physical medium and no amount of QoS tuning can reduce it. The diagnostic is to examine the one-way latency values in show ip sla statistics [id]. If one-way latency exceeds 80 ms, the MOS degradation is from propagation delay, not queuing. Solutions include reducing codec packetisation interval (10 ms instead of 20 ms reduces codec-introduced delay), enabling MPLS TE with traffic engineering for optimal path routing, or accepting the limitation as a physical constraint of the geography.

8. What happens to CBWFQ bandwidth class traffic if the class queue limit (default 64 packets) is reached, and how does this differ from the priority class behaviour when its limit is reached?

B. When a CBWFQ bandwidth class queue reaches its 64-packet limit, new arriving packets for that class are tail-dropped — discarded from the rear of the queue. TCP detects the drops and reduces its window. The total drops counter in show policy-map interface increments. The priority class works differently — it has no queue at all. Priority packets are either transmitted immediately or dropped by the built-in bandwidth policer if the rate exceeds the configured kbps. There is no "priority queue full" condition — excess priority traffic is rate-limited, not queued A. Both the bandwidth class and priority class use tail-drop when their queues fill — the queue limit for the priority class defaults to 32 packets (half the CBWFQ default) C. When a CBWFQ queue fills, new packets are held by the WAN interface hardware queue until the software queue drains — no drops occur until both hardware and software queues are full simultaneously D. Both classes use the same mechanism — packets are dropped when the queue fills. The only difference is that bandwidth class drops increment a different counter (no-buffer drops) while priority class drops increment b/w exceed drops

Correct answer is B. This distinction is architecturally important. CBWFQ classes maintain a finite queue (FIFO within the class by default, or WRED if configured) with a configured maximum depth. When the depth is reached, arriving packets are tail-dropped. This is the normal congestion management mechanism — drops signal TCP to slow down. The queue depth can be observed in real-time with show policy-map interface and the cumulative tail-drop count appears in the total drops counter. The priority class (LLQ) is fundamentally different: it has no queue. A priority packet arriving at the interface is immediately placed in transmission — it does not wait. If the arrival rate exceeds the configured priority kbps, the built-in rate limiter drops the packet before it even enters any queue structure. This is visible as b/w exceed drops — a rate-limiting drop, not a queue-overflow drop. Increasing queue-limit on a CBWFQ class reduces tail-drop at the cost of higher latency for queued packets. No equivalent tuning exists for the priority class — the only control is the configured kbps bandwidth allocation.

9. An enterprise has 20 Mbps WAN and plans to support 50 simultaneous G.729 VoIP calls. What priority bandwidth should be configured and what percentage of the WAN does this represent?

A. 50 calls × 8 kbps (G.729 payload only) = 400 kbps — configure priority 400, which is 2% of 20 Mbps B. 50 calls × 64 kbps (G.711 equivalent) = 3,200 kbps — always provision at G.711 rates regardless of deployed codec to provide headroom C. 50 calls × 32 kbps (G.729 with headers) = 1,600 kbps with no margin — configure priority 1600, which is 8% of 20 Mbps D. G.729 per-call bandwidth with full headers ≈ 32 kbps. Add a 10% engineering margin: 32 × 1.1 = 35.2 kbps per call. 50 calls × 35.2 = 1,760 kbps — round up to priority 1800 for a clean value. This is 1,800 ÷ 20,000 = 9% of the WAN. Verify the 75% ceiling: all class allocations must total ≤ 15,000 kbps (75% of 20 Mbps). With 1,800 kbps for VoIP, 13,200 kbps remains for CBWFQ classes and overhead

Correct answer is D. VoIP bandwidth calculation requires including all protocol headers, not just the codec payload. G.729 produces 20 bytes of audio payload every 20 ms. The full packet structure is: 20 (payload) + 12 (RTP) + 8 (UDP) + 20 (IP) + 18 (Ethernet, or substitute the appropriate Layer 2 header for the WAN type — PPP/MPLS will differ) = 78 bytes per packet. At 50 packets per second (20 ms packetisation): 78 × 50 × 8 = 31,200 bps ≈ 32 kbps per call. The G.729 "8 kbps codec" is a common trap — 8 kbps is the compressed audio data rate, not the actual network bandwidth. Adding 10% margin accounts for retransmits, codec negotiation overhead, and the fact that real-world RTP streams are slightly irregular. The margin is important: the priority class's built-in policer has no buffer — if actual traffic exceeds the configured kbps by even 1 bps, drops begin immediately. Option A is wrong because 8 kbps is the payload rate only (headers represent 75% of the actual bandwidth for G.729). Option C is correct in methodology but omits the engineering margin, which is a design risk for production deployments.

10. After applying an LLQ + CBWFQ policy, `show policy-map interface` shows all traffic landing in `class-default` with zero packets in any named class. What is the most likely cause?

A. The egress queuing policy is being applied before the ingress marking policy on the same interface — apply the queuing policy last B. The DSCP values in the class-map match statements do not match any standard DSCP name — use numeric values instead of names (e.g. match dscp 46 instead of match dscp ef) C. The ingress DSCP marking policy is not applied or not functioning — all traffic is arriving at the egress queuing policy with DSCP 0 (class-default catches all unmatched traffic; DSCP 0 does not match ef, cs3, af41, af31, or af11). Verify with show policy-map interface [LAN-intf] input — if the marking policy shows all traffic in class-default with zero packets in named classes, the marking policy itself has a classification problem. Also check whether DSCP is being reset somewhere between the LAN ingress and WAN egress D. The MQC policy is a newer configuration format that requires ip cef to be enabled — CEF is not enabled on this router so class-map matching falls back to class-default for all traffic

Correct answer is C. When all traffic lands in class-default at the egress queuing policy, the class-maps are matching nothing — meaning the DSCP values in the arriving packets do not match any class-map criteria. The most common cause is that traffic arrives at the WAN egress interface with DSCP 0 (unmarked). This happens when: (1) the ingress marking policy was never applied to the LAN interface (service-policy input missing); (2) the ingress marking policy is applied but its class-maps match nothing (check marking policy counters); (3) DSCP is being reset between interfaces — e.g. a NAT translation that inadvertently clears the ToS byte on some IOS versions; (4) the LAN interface and WAN interface are on different IOS feature sets that handle DSCP differently. The definitive diagnosis is to check the DSCP value on packets at the WAN interface: show policy-map interface [WAN-intf] output | section class-default showing high packet counts while all named classes show zero is the signature. Then trace backward: does the marking policy show correct marking counts? If yes, the DSCP is being lost in transit between LAN ingress and WAN egress — use Embedded Packet Capture to confirm DSCP values at each stage.

Back to Home