A router is suspected to be underperforming when users experience slow or intermittent connectivity, a WAN link degrades, packet loss increases, or monitoring raises CPU, memory, interface, or routing alerts. These are only symptoms, and they do not explain the cause: it could be the router's processing capacity, an issue with traffic handling, or routing misbehavior.
This is what makes router troubleshooting difficult, especially in a large network: different fault domains can produce similar symptoms.
The efficient response: Narrowing the investigation systematically through four fault domains.
- Capacity: Can the router handle the workload?
- Traffic handling: Can it move that traffic through its interfaces effectively?
- Routing: Is routing behaviour affecting the traffic path?
- Hardware: Is a physical component affecting the router's operation?
Evidence at each level helps an admin establish one of two things: the fault domain causing the symptom, or that the investigation should move forward.
The goal is to reach the most likely cause with the fewest unnecessary checks—and then verify that the corrective action resolves the original problem.
In this article, you'll learn how to:
- establish the scope and baseline of a router performance problem;
- determine whether router capacity, traffic handling, or routing is responsible;
- correlate the evidence to confirm the likely cause; and
- apply the appropriate fix and verify that the original problem is resolved.
For the broader monitoring framework, see Router monitoring: A complete overview.
Establish the symptom, scope, and baseline
Before checking individual metrics, establish what is happening, where it is happening, when it started, and how the router normally behaves.
| What to establish | What to determine |
|---|---|
| Symptom | Slow, intermittent, unavailable, high latency, packet loss, or another observable problem |
| Scope | Affected users, applications, sites, interfaces, links, or paths |
| Timeline | When the problem began and whether it is continuous, intermittent, or recurring |
| Baseline | How the router normally behaves compared with its current condition |
For example:
- Symptom: Users at a branch report intermittent access to applications hosted in the data center.
- Scope: Only traffic through the primary WAN path is affected.
- Timeline: The problem began shortly after a significant increase in traffic.
- Initial evidence: WAN utilization is substantially higher than its normal pattern, while router CPU and memory remain within their usual ranges.
That evidence already narrows the investigation. Resource pressure is less likely to be the immediate cause, while traffic handling and WAN capacity warrant closer examination.
Investigate cleared or intermittent incidents through historical data
If the problem has already cleared, current metrics may no longer show the condition that caused it. Shift the investigation to historical data from the incident window.
- Compare the affected period with adjacent normal periods.
- Check capacity, traffic handling, and routing data across the same window.
- For recurring problems, preserve a confirmed normal period as the comparison baseline for the next occurrence.
- Retain enough granular history to cover the likely recurrence interval; 30—90 days can be substantially more useful than seven days for intermittent problems.
1. Router capacity: Is the device under resource pressure?
The first fault domain is the router's own processing capacity. CPU and memory provide the primary evidence, but neither metric is a problem simply because it is high.
Check for sustained CPU or memory pressure
Compare current resource behavior with the router's normal operating range.
| Evidence | What it suggests |
|---|---|
| CPU materially above normal | Possible processing pressure |
| Memory pressure or declining available memory | Possible memory constraint |
| Short-lived resource spike | Less likely to explain a persistent problem |
| Resource pressure coinciding with the incident | Strengthens the capacity hypothesis |
For CPU, check whether a particular process or router function is consuming an unusual share of processing capacity. For memory, look for sustained pressure rather than simply a high utilization percentage.
For example:
- Symptom: Intermittent connectivity begins at 10:15.
- Evidence: CPU rises sharply at 10:14 and remains well above its normal range. A routing process accounts for most of the increase.
That makes resource pressure a plausible contributor, while the routing activity provides a direction for further investigation. Resource pressure becomes relevant when it is abnormal for the router, persists, and coincides with the incident.
What if CPU and memory remain within their normal ranges while the problem persists?
Then capacity is less likely to be the immediate fault domain.
2. Traffic handling: Is the router moving traffic effectively?
If the router has sufficient processing and memory capacity, investigate whether the problem lies in traffic demand, interface capacity, or traffic delivery.
Check whether traffic demand is unusually high
Compare interface utilization with its normal behavior and available capacity.
Look for:
- sustained high utilization rather than short traffic bursts;
- utilization materially above the interface's normal pattern;
- traffic consistently approaching interface capacity;
- a change in utilization that coincides with the performance problem.
High utilization is not, by itself, evidence of a fault. The distinction is whether the interface can still deliver traffic normally at that load.
Check whether the interface is delivering traffic properly
Examine errors, discards, packet loss, throughput, and link state.
| Finding | What it suggests |
|---|---|
| High utilization + clean delivery | Investigate what is consuming the available capacity |
| High utilization + packet loss/discards | Investigate interface or link capacity and delivery |
| Normal utilization + persistent performance problem | Traffic capacity is less likely to explain the symptom |
For example:
- Symptom: Users experience intermittent access to applications.
- Evidence: WAN utilization remains near capacity while output discards and packet loss increase during the same period.
So the interface is not simply busy; traffic delivery is being affected.
If utilization is high but errors, discards, and packet loss remain normal, investigate the traffic consuming the capacity before treating the interface itself as the problem.
Identify what is consuming the available bandwidth
When capacity is the concern, use flow data to identify:
- top sources and destinations;
- high-volume applications;
- dominant protocols;
- unusual traffic patterns;
- newly introduced traffic.
For example:
If an interface has moved from its normal 40% utilization to 90%, flow data can establish whether the increase comes from a legitimate application workload, a backup process, a new traffic flow, or an unexpected source.
This distinguishes traffic demand from traffic-delivery problems.
If neither interface behavior nor traffic data explains the symptom, investigate whether routing behavior is affecting the path.
3. Routing behavior: Is it affecting the traffic path?
If router capacity and traffic handling do not explain the problem, examine whether routing is changing how traffic reaches its destination.
Check for route or routing-peer instability .
Look for:
- route flapping or repeated route changes;
- unstable BGP or other routing-protocol peers;
- repeated adjacency changes;
- unexpected additions or removals of routes;
- unusual routing activity around the time the problem began.
A single routing-table change is not necessarily a problem. The important question is whether the change was unexpected, persistent, or associated with the observed performance issue.
Check whether traffic is taking the expected path
Compare the current path with the expected path for the affected traffic.
Look for:
- traffic being redirected through another router or WAN link;
- loss of a preferred route;
- repeated changes between paths;
- traffic being sent through a link with less available capacity;
- asymmetric or otherwise unexpected routing behavior.
An otherwise healthy router can still be involved in a performance problem if routing decisions send traffic through a path that cannot handle the workload effectively.
Determine whether routing explains the symptom
For example:
- Symptom: Connectivity becomes intermittent at 14:20.
- Evidence: A BGP peer repeatedly changes state from 14:18 onward, while affected prefixes move between paths.
Routing instability is a plausible explanation for the connectivity problem.
If routing remains stable and the traffic path is unchanged, routing is less likely to be the immediate cause.
4. Hardware conditions: Is the physical device causing the problem?
If capacity, traffic handling, and routing appear normal, investigate the router's physical components and hardware health.
Look for:
- SFP or transceiver degradation: interface errors or link instability without unusually high utilization.
- Fan or thermal problems: rising temperature or thermal protection that can reduce device performance before a clear thermal alarm appears.
- ASIC or packet-processing pressure: hardware forwarding resources becoming constrained under high packet-rate workloads even when aggregate bandwidth is not unusually high.
- Power-supply events: power faults or redundancy changes that can cause instability without immediately appearing as a CPU, memory, or routing problem.
Hardware faults can produce symptoms that resemble other fault domains. Interface errors can look like a traffic-delivery problem; CPU or forwarding-performance changes can look like resource pressure. When the software and traffic evidence does not explain the symptom, physical hardware becomes the next fault domain to test.
Confirm the cause before applying a fix
An abnormal metric is evidence, not a diagnosis. Before changing the configuration or infrastructure, establish that the suspected cause actually explains the incident.
Test the suspected cause against the incident
| Test | Question |
|---|---|
| Timing | Did the suspected condition appear when the problem began? |
| Scope | Does it affect the same users, applications, interfaces, or paths? |
| Supporting evidence | Do related metrics point to the same explanation? |
| Alternative explanations | Does another fault domain explain the evidence better? |
Check for configuration changes around the time the problem began
A recent configuration change can explain a change in router behavior that the metrics alone cannot. Check configuration history around the incident for changes to interfaces, routing policies, QoS, ACLs, routing protocols, or other settings relevant to the affected traffic.
Timing matters. A configuration change that occurred shortly before the symptom began is stronger evidence than an unrelated historical change. If the change also affects the same interface, route, traffic class, or router function implicated by the other evidence, it becomes a stronger candidate for the cause.
For example:
- Symptom: Users experience intermittent access to data-center applications.
- Abnormal behavior: WAN utilization is consistently near capacity.
- Supporting evidence: A new high-volume traffic source is consuming the additional bandwidth, while packet loss increases when utilization peaks.
- Configuration evidence: A recent QoS change altered how the affected traffic was prioritized.
- Likely cause: The configuration change may have altered traffic handling, while increased traffic demand is contributing to the resulting performance problem.
The earlier investigation should also establish what isn't causing the problem. Normal CPU and memory weaken the capacity hypothesis. Normal utilization, errors, discards, and packet loss weaken the traffic-handling hypothesis. Stable routing peers and paths weaken the routing hypothesis.
The most credible diagnosis is the fault domain that best explains the symptom, timing, scope, supporting evidence, and relevant configuration changes together.
Apply the fix and verify the result
Once the fault domain is established, address the underlying condition rather than simply the abnormal metric.
| Confirmed cause | Corrective direction | Verify |
|---|---|---|
| Capacity pressure | Address the resource-intensive workload, redistribute load, or assess device capacity | Resource behavior and the original symptom return to normal |
| Traffic/interface problem | Address excessive traffic, capacity constraints, errors, discards, or link conditions | Traffic is delivered correctly and the symptom clears |
| Routing problem | Correct unstable peers, unexpected routes, or problematic path selection | Routes stabilize and affected traffic follows the expected path |
| Configuration-related problem | Review, revert, or correct the configuration change responsible for the behavior | The affected behavior returns to normal and the original symptom clears |
Validate the original problem, not just the metric
CPU returning to normal does not prove that an incident is resolved. Interface utilization falling does not prove that connectivity has recovered.
Return to the problem that initiated the investigation and confirm that:
- the original connectivity or performance issue has cleared;
- the abnormal metrics have returned toward their expected behavior;
- related symptoms have also resolved;
- the router is operating normally after the change.
A corrective action is successful only when the evidence shows that the suspected cause was addressed and the original problem was actually resolved.
Router monitoring at enterprise scale
For organizations looking for comprehensive router monitoring as part of broader network monitoring operations,ManageEngine OpManager brings router availability, device health, interface performance, and traffic visibility into a unified network monitoring platform. Powered by adaptive thresholds, alert correlation, and IT operations integrations, it helps teams identify network issues and manage performance from a single console.
Frequently asked questions about troubleshooting routers
What should I check first when only one branch or site is reporting router problems?
Start by comparing the affected site's router, WAN interface, and traffic path with a healthy site. This helps distinguish a local router or link problem from a wider network condition.
How do I troubleshoot a router problem that comes and goes?
What should I check when the router looks healthy but users are still experiencing poor performance?
Monitor router availability, performance, traffic, and health with our network monitoring solution
ManageEngine OpManager
Download nowBy Javith Razvi,
ManageEngine Team