Real-World Cisco Troubleshooting: Voice Calls Breaking and Applications Running Slow During WAN Congestion

Category: Network Troubleshooting | Cisco | Enterprise WAN | QoS
Level: Intermediate to Advanced
Reading Time: 10–12 Minutes
Published: October 24, 2026

Introduction

Imagine receiving a high-priority incident from the service desk:

"Users at the branch office are experiencing choppy voice calls, frozen Microsoft Teams meetings, and extremely slow business applications. Internet connectivity is working, but performance becomes poor during peak hours."

The network monitoring dashboard shows that all router interfaces are up, routing neighbors are stable, and no major network outage has occurred.

So why are applications failing?

This is a common enterprise networking challenge. A network can be reachable while its applications are performing poorly.

In this troubleshooting case study, we investigate a realistic Cisco WAN performance issue caused by sustained congestion, missing application-aware queuing, and an unmanaged provider bandwidth limit.

This is a representative production scenario created for training. The command outputs and measurements are illustrative, not records of an actual customer incident.

1. Incident Overview

Network Environment

A company operates a branch office connected to its Data Center through a service provider's MPLS WAN.

The environment includes:

• Cisco IOS XE WAN router at the branch.

• 1 Gbps physical WAN interface.

• 20 Mbps contracted MPLS service.

• Enterprise voice and video conferencing.

• Business-critical applications hosted at the Data Center.

• Scheduled backup traffic running during business hours.

Reported User Impact

Users report three major symptoms:

1. Voice calls become choppy, with intermittent audio loss.

2. Microsoft Teams meetings freeze or experience audio delay.

3. Business applications become slow whenever large backup jobs run.

Interestingly, basic ping tests remain successful.

This indicates that network reachability is not necessarily the same as acceptable application performance.

2. Network Topology

The affected traffic follows this path:

Key Observation

The branch router has a 1 Gbps physical interface, but the service provider permits only 20 Mbps under the contracted service profile.

If the branch transmits bursts beyond the provider allowance, the provider may drop packets through policing.

3. Troubleshooting Step 1 — Verify Interface Health

The first step is to determine whether the WAN connection is physically healthy.

Command:

show interfaces GigabitEthernet0/0/0

Sample Output

GigabitEthernet0/0/0 is up, line protocol is up

  MTU 1500 bytes, BW 1000000 Kbit/sec
  Full Duplex, 1000Mbps

  5 minute input rate 8500000 bits/sec
  5 minute output rate 19000000 bits/sec

  0 input errors
  0 CRC
  0 frame
  0 output errors

Analysis

The interface is operational and shows no physical errors.

However, two values require attention:

Physical Interface Speed: 1000 Mbps
Current Output Rate:        19 Mbps
Contracted Service Rate:    20 Mbps

The output rate is approaching the contracted WAN capacity.

What We Learned

There is no evidence of a physical-layer problem from these counters.

The WAN may still be experiencing congestion because the service rate is much lower than the physical interface speed.

Important: A five-minute average of 19 Mbps does not exclude short bursts above 20 Mbps.

4. Troubleshooting Step 2 — Check Network Latency

Next, verify latency to the Data Center.

Command:

ping 10.20.20.1 repeat 20

Sample Output During Normal Traffic

Success rate is 100 percent (20/20)

round-trip min/avg/max = 18/22/28 ms

Sample Output During Backup Activity

Success rate is 95 percent (19/20)

round-trip min/avg/max = 25/110/240 ms

Analysis

Under normal conditions, average RTT is approximately 22 ms.

During heavy backup traffic, average RTT increases to 110 ms, with a maximum of 240 ms.

This suggests increased delay during periods of high network utilization.

However, ICMP results alone cannot prove that WAN queue congestion is the root cause. The ICMP traffic may receive different treatment from application traffic.

Additional investigation is required.

5. Troubleshooting Step 3 — Investigate Jitter

Voice and video applications are particularly sensitive to packet-delay variation.

A supported Cisco IP SLA UDP jitter operation, or an equivalent voice-monitoring tool, can help measure this behavior.

Command:

show ip sla statistics 10

Illustrative Measurement Comparison

Analysis

The measurements show substantial degradation during backup activity.

Higher jitter means packets are experiencing inconsistent delay, which can interfere with real-time media playback.

At this stage, the evidence points toward a congestion-related performance problem, but the QoS configuration and provider statistics must be investigated before confirming the cause.

6. Troubleshooting Step 4 — Check Existing QoS Configuration

The next step is to verify whether application-aware QoS is configured on the branch WAN interface.

Command:

show running-config interface GigabitEthernet0/0/0

Sample Output

interface GigabitEthernet0/0/0
 description MPLS-WAN-TO-ISP
 ip address 172.16.10.2 255.255.255.252
 no shutdown

Analysis

No output QoS policy is attached to the WAN interface.

Now verify the operational QoS state.

show policy-map interface GigabitEthernet0/0/0

In this illustrative incident, no service policy appears.

Finding

The branch router is not applying an egress shaping and application-aware queuing policy to the affected WAN interface.

This means that the router is not locally scheduling voice, video, and business traffic according to the intended enterprise QoS requirements.

The actual forwarding behavior still depends on the router's default queueing architecture.

7. Troubleshooting Step 5 — Identify the Traffic Consuming Bandwidth

Interface utilization alone does not reveal which applications are consuming network capacity.

To identify traffic sources, network engineers can use:

• NetFlow or Flexible NetFlow.

• Application performance monitoring.

• Firewall traffic analytics.

• Router interface telemetry.

• Existing NMS bandwidth and flow reports.

Findings from Flow Analysis

During the incident, the branch generated approximately:

The contracted WAN capacity is only 20 Mbps.

Analysis

The branch is generating 28 Mbps of demand over a service designed for 20 Mbps.

The backup application is the largest contributor, representing approximately 54% of total offered traffic.

Because no appropriate WAN egress QoS policy is configured, real-time and business-critical traffic are not receiving the intended application-specific queuing treatment at the branch.

The flow analysis establishes a strong correlation between backup traffic and congestion.

8. Troubleshooting Step 6 — Verify Service Provider Policing

The enterprise network team contacts the MPLS service provider and requests policing statistics for the affected circuit.

The provider confirms:

Contracted CIR       : 20 Mbps
Policing             : Enabled
Excess Traffic       : Discard
Policer Drop Counters: Increasing

The provider reports that bursts exceeding the allowed service profile are causing packet drops.

Root Cause Identified

The incident has two contributing factors:

Primary Cause — WAN Oversubscription

The branch generates sustained traffic demand above the 20 Mbps service capacity.

Secondary Cause — Missing Local QoS Control

The branch router does not have an appropriate parent shaping and child queuing policy.

As a result, traffic can encounter the provider's rate enforcement without first receiving the intended application-aware treatment at the branch.

This explains why backup activity correlates with increased delay, jitter, and packet loss.

9. Resolution — Implement Hierarchical QoS

The network team plans a controlled change to apply a parent shaping policy and child queuing policy.

Before implementation, the engineers confirm that the router supports the required IOS XE MQC features, the traffic markings are trustworthy, and the change can be rolled back if necessary.

Step 1 — Classify Application Traffic

configure terminal

class-map match-any CM-VOICE
 match dscp ef
!
class-map match-any CM-VIDEO
 match dscp af41
!
class-map match-any CM-BUSINESS
 match dscp af21
!

These class maps assume the applications have already been marked correctly at a trusted network boundary.

Step 2 — Create Child Queuing Policy

policy-map PM-WAN-CHILD
 class CM-VOICE
  priority 2000
 !
 class CM-VIDEO
  bandwidth 6000
 !
 class CM-BUSINESS
  bandwidth 5000
 !
 class class-default
  fair-queue
!

Policy Explanation

Voice — LLQ

Voice receives strict-priority scheduling with a configured 2 Mbps priority rate.

Video — CBWFQ

Video receives a minimum 6 Mbps allocation during congestion.

Business Applications — CBWFQ

Business traffic receives a minimum 5 Mbps allocation during congestion.

Default Traffic

Unmatched traffic is serviced according to the default queueing policy.

Step 3 — Create Parent Shaping Policy

policy-map PM-WAN-PARENT
 class class-default
  shape average 20000000
  service-policy PM-WAN-CHILD
!

The parent policy shapes traffic toward the contracted service rate.

In a real deployment, the configured rate and burst behavior must be validated against provider overhead accounting and policing rules. A nominal 20 Mbps shape may need adjustment.

Step 4 — Apply QoS on the WAN Interface

interface GigabitEthernet0/0/0
 service-policy output PM-WAN-PARENT
!
end

Only the parent policy is directly attached to the interface.

The child policy operates beneath the parent shaper.

Implementation Note: This is illustrative MQC syntax for supported Cisco IOS XE routing platforms. Exact feature support and queueing behavior depend on the hardware and software release.

10. Post-Change Verification

After implementation, the network engineer verifies the active policy.

Command:

show policy-map interface GigabitEthernet0/0/0

Simplified Illustrative Output

GigabitEthernet0/0/0

 Service-policy output: PM-WAN-PARENT

 Class-map: class-default
   Shape (average) cir 20000000

   Service-policy: PM-WAN-CHILD

     Class-map: CM-VOICE
       Match: dscp ef
       Priority: 2000 kbps
       Total drops: 0

     Class-map: CM-VIDEO
       Match: dscp af41
       Bandwidth: 6000 kbps

     Class-map: CM-BUSINESS
       Match: dscp af21
       Bandwidth: 5000 kbps

     Class-map: class-default
       Fair-queue

What Needs to Be Verified?

• Parent shaping policy is active.

• Shaping rate is consistent with the provider service profile.

• EF-marked voice traffic matches the priority class.

• AF41 video traffic matches the correct class.

• Business applications match AF21.

• Priority drops are not increasing unexpectedly.

• Queue statistics reflect the actual traffic load.

• Provider policing drops decrease under comparable load conditions.

Cisco documents show policy-map interface as a primary method for examining QoS policy operation and class statistics.

11. Before and After — Performance Validation

The network team runs a controlled traffic test that reproduces the original incident conditions.

The following values illustrate a plausible successful test outcome.

Analysis

With the hierarchical QoS policy:

• The branch router manages congestion locally.

• Voice traffic receives priority treatment.

• Business applications receive minimum bandwidth allocations.

• Backup traffic no longer competes on equal scheduling terms with critical traffic.

• Provider-side policing drops can be reduced.

The backup application may take longer because it uses only the capacity available under the active QoS scheduling policy.

That is an intentional trade-off to protect business-critical services.

Important: These figures represent illustrative test outcomes. Actual improvements depend on traffic demand, classification accuracy, WAN conditions, and device capabilities.

12. What If the Issue Still Exists?

Implementing QoS does not guarantee that every application problem is resolved.

If users continue reporting poor performance, investigate the following:

Incorrect DSCP Marking

Verify whether voice packets actually carry EF (46) before entering the WAN queue.

LLQ Drops

Check whether voice traffic exceeds its configured priority rate.

Incorrect Parent Shaping Rate

Confirm that the configured rate aligns with the provider's service profile and overhead accounting.

Excessive Queue Buffering

A shaper can introduce additional latency when queues become deep.

Congestion in the Return Direction

The branch's output QoS policy controls only that output direction.

The reverse path may require a separate QoS policy at the Data Center or another relevant bottleneck.

Physical or Transport Problems

Investigate interface errors, link failures, asymmetric paths, and packet loss unrelated to QoS.

Platform Limitations

Verify that the deployed hardware supports the desired queueing and shaping features, including the required hardware counters.

13. Production Troubleshooting Checklist

When troubleshooting a slow enterprise WAN, follow this sequence:

1. Confirm user impact: Identify affected applications, locations, and incident timing.

2. Check interface health: Verify physical state, CRC errors, drops, and traffic rates.

3. Measure latency and jitter: Compare normal and impacted periods.

4. Identify top talkers: Determine which applications consume bandwidth.

5. Verify the contracted WAN capacity: Do not confuse physical port speed with service bandwidth.

6. Inspect QoS classification: Confirm traffic matches the intended DSCP classes.

7. Verify parent and child policies: Review shaping rates, priority allocations, and bandwidth guarantees.

8. Examine QoS counters: Analyze queue depth, packet drops, and policing statistics.

9. Compare provider measurements: Validate CIR, bursts, and service-provider drops.

10. Retest applications: Confirm that the original user symptoms have been resolved under comparable load.

Conclusion

Enterprise network troubleshooting is not always about restoring a failed link or fixing a routing adjacency.

Sometimes every device is reachable, routing works correctly, and interfaces remain operational — yet users still experience severe application performance problems.

In this scenario, the underlying issue was WAN congestion combined with insufficient application-aware QoS treatment at the branch.

By examining interface statistics, latency, jitter, application traffic demand, existing QoS policies, and service-provider policing counters, the network team identified the cause and implemented an appropriate hierarchical QoS design.

The biggest lesson: Don't stop troubleshooting when ping succeeds. Always investigate how the network handles application traffic under real operating conditions.

Continue Learning — Network Guide Academy

Explore Cisco CCNA, CCNP, enterprise networking, routing, switching, QoS, and practical troubleshooting guides.

Learn with real-world scenarios, Cisco configurations, verification commands, and structured technical explanations.

Website: https://networkguideacademy.com/

Learn Networking. Build Skills. Troubleshoot with Confidence.