Packet loss and latency rising together on a WAN link creates an immediate diagnostic question: is congestion filling queues, or is a physical failure disrupting the circuit? That observation is the starting condition. Many apparent circuit problems are congestion events, so the answer should guide the next step before a carrier ticket is opened.
A carrier ticket for congestion may return as "no fault found" after traffic subsides, or sit in queue while the issue persists. When congestion is the cause, use traffic shaping, a QoS policy change, or added capacity instead of requesting line maintenance.
How Congestion Produces Both Symptoms
To read packet loss and latency correctly, first understand how they interact when a WAN link is congested.
As a WAN link nears capacity, its buffers fill and packets spend more time waiting before transmission, increasing latency. Once those buffers overflow, packets are discarded, creating loss. Both effects come from the same queue buildup, so congestion naturally produces correlated symptoms.
A physical fault follows another causal path. An impaired optical path, unstable physical layer, or CPE hardware problem can drop packets without buffer saturation. Latency may stay relatively stable, or increase because higher-layer retransmissions add overhead rather than because layer 2 or 3 queues are full. Loss and latency therefore relate differently than they do during congestion.
The distinction helps, but it is not conclusive. Marginal links with high bit error rates can create loss patterns that resemble congestion. Separate the causes with additional signals.
Distinguishing Queue Pressure from Circuit Trouble
Start with time correlation. WAN congestion usually follows traffic volume. Latency and loss that rise during business hours or alongside large application transfers indicate congestion. Random spikes during quiet periods, with no clear traffic relationship, suggest physical degradation.
Next inspect error counters on the WAN endpoint. CRC, input, and framing errors point to physical issues at the local CPE or access link. Clean counters alongside rising loss and latency shift attention to the WAN circuit or traffic volume. Counters that rise with both symptoms implicate the physical layer.
Check utilization at the WAN egress as a third signal. SNMP counters allow most endpoints to calculate bytes in and out between polls. Utilization at 85% or above during the degradation window makes congestion the leading hypothesis. If it is 30% while both metrics rise, investigate elsewhere.
Use continuous ICMP probes to the far end with a consistent packet size and inspect the loss pattern. Congestion often causes bursts: many drops in a short interval, followed by clean transmission, then another burst. Physical-layer loss is more likely to remain steady across a longer period.
Use Traffic Data to Verify Congestion
When the signals indicate congestion, identify the traffic behind it. On the WAN egress, break out interface packet counts by DSCP marking or source prefix. This shows whether one class is responsible or whether traffic has increased broadly.
If one application or source prefix drives the spike, shape or police its maximum egress rate as a short-term measure. If total traffic is growing with the spikes, plan capacity instead. The link is undersized for current demand and will keep degrading without an upgrade.
Examine the QoS behavior directly. On a marked WAN, determine whether the high-priority queue, often voice or critical application data, is dropping independently of best-effort traffic. Clean priority queues with best-effort drops indicate QoS is protecting priority traffic. Drops in both queues mean saturation exceeds what the QoS policy can shield.
Confirming a Physical Problem
If utilization is low, loss is not bursty, and access-interface errors are present, begin the physical investigation at the CPE.
Check WAN interface state, including optical signal levels on fiber handoffs or DSL statistics on DSL circuits. Most CPE devices expose receive and transmit power through SNMP or a local CLI. Receive power below the transceiver sensitivity floor can explain intermittent loss unrelated to traffic volume.
For a leased line or Ethernet handoff, inspect the carrier demarc through its CLI or management interface. Line statistics there can quickly separate circuit trouble from customer equipment trouble. Clean signal levels and physical counters at both the demarc and your CPE place the fault in the WAN path toward the far end, which is the carrier's responsibility.
Include these details in the carrier ticket: the degradation window, utilization during that period, CPE counters showing clean local physical state, and a measured loss result from probes to the far-end CPE address. Precise evidence speeds escalation.
A WAN Congestion Case in the Field
We saw this during a pilot for a mid-market retailer using a 500 Mbps MPLS circuit between two distribution centers. Latency rose from an 18ms baseline to 60-85ms for 5-15 minutes, with simultaneous loss of 2-4%.
The first theory was circuit damage. A carrier maintenance event the month before made the team associate the new symptoms with that work.
Utilization data pointed elsewhere. During every window, WAN egress ran at 91-97% of capacity. A backup job between the sites was unshaped, marked best-effort, and produced 340-380 Mbps of egress traffic. The circuit was healthy. The traffic lacked control.
A shaper limiting the backup source prefix to 150 Mbps removed the latency spikes within one business day. No carrier ticket was needed.
The lesson is to gather evidence before opening a carrier ticket, since that work may resolve the issue or strengthen the escalation. This approach depends on usable utilization and error data; without that visibility, congestion and physical faults may look identical.