Mastering Traceroute and Ping for Network Diagnostics

Ping and traceroute are the first tools most engineers reach for when something breaks. The problem is that most engineers stop at the surface level: run a ping, see packet loss, escalate. At the CCNP level, you need to extract every bit of diagnostic value from these tools and correlate what you see with what is actually happening in the control and data plane. This post covers advanced usage patterns, output interpretation, and the scenarios where these tools will mislead you if you do not understand their mechanics.

Ping: Beyond Basic Reachability

On Cisco IOS, the extended ping gives you control over parameters that matter in real-world diagnostics. Use it when a simple ping passes but users are still reporting issues, or when you need to simulate specific traffic patterns to isolate a fault.

R1# ping
Protocol [ip]: ip
Target IP address: 10.10.50.1
Repeat count [5]: 1000
Datagram size [100]: 1400
Timeout in seconds [2]: 2
Extended commands [n]: y
Source address or interface: Loopback0
Type of service [0]: 0
Set DF bit in IP header? [no]: yes
Validate reply data? [no]: yes
Data pattern [0xABCD]: 0xABCD
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]: n

Key parameters and why they matter in an enterprise context:

• Datagram size: setting this to 1400 bytes with df-bit set will expose MTU issues on the path. A high ping success rate at 100 bytes with failures at 1400 bytes is almost always an MTU or Path MTU Discovery (PMTUD) black hole problem.
• Source address: always specify a source interface or loopback when testing routing symmetry or verifying that a specific routing policy is being applied correctly.
• Repeat count: use at least 500-1000 packets when hunting intermittent packet loss. Sporadic issues will not show in a 5-packet ping.
• Validate reply data: enables payload verification, useful when suspecting bit-error-rate issues on a physical link.

When analyzing ping output, the !, ., U, and M characters tell different stories. A . means timeout. A U means an ICMP unreachable was received, which tells you a device somewhere on the path actively rejected the packet. An M means ICMP "fragmentation needed" was returned, confirming an MTU mismatch when DF-bit is set. If you are seeing alternating ! and . patterns, you likely have a routing asymmetry or ECMP hash issue causing packets to alternate between a good path and a broken path.

Traceroute: Reading the Output Correctly

The standard traceroute mechanics are well-known: incrementing TTL, ICMP Time Exceeded responses. What matters at this level is interpreting latency patterns and understanding where the tool lies to you.

R1# traceroute 10.10.50.1 source Loopback0 probe 5 numeric
Type escape sequence to abort.
Tracing the route to 10.10.50.1

  1 10.0.12.2 [MPLS: Label 1001 Exp 0] 2 msec 2 msec 2 msec 2 msec 2 msec
  2 10.0.23.3 [MPLS: Label 1002 Exp 0] 3 msec 3 msec 4 msec 3 msec 3 msec
  3 10.0.34.4 35 msec 34 msec 36 msec 35 msec 35 msec
  4 10.10.50.1 36 msec 36 msec 36 msec 35 msec 36 msec

Notice hop 3 shows a sudden jump from approximately 3ms to 35ms. This is a latency increase of roughly 32ms. The critical diagnostic skill here is recognizing that a latency spike at a single hop that persists consistently across all subsequent hops indicates that the delay was introduced at that hop and carried forward. If subsequent hops return to lower latency, the spike was caused by ICMP rate limiting on that device's control plane, not actual forwarding delay in the data plane. Do not confuse control plane processing time with data plane forwarding latency.

MPLS Traceroute and the Invisible Hops Problem

In MPLS networks, intermediate LSRs that are not the egress PE do not decrement IP TTL unless mpls ip propagate-ttl is enabled. If TTL propagation is disabled (common in service provider cores to hide topology), you will see hops disappear from the traceroute output. The path appears to jump directly from the ingress PE to the egress PE. This is expected behavior, not a problem, but it will confuse junior engineers and should be considered when interpreting output in a provider-managed or MPLS-enabled enterprise WAN.

Use traceroute mpls ipv4 for LSP-specific testing:

R1# traceroute mpls ipv4 10.10.50.1/32 source 10.0.0.1

This sends LSP ping probes through the actual MPLS data plane rather than relying on IP TTL expiry, which gives you accurate hop-by-hop visibility within the label-switched path.

Network Latency and Packet Loss: Separating the Causes

When diagnosing network latency or packet loss, the measurement tool itself can be the source of misleading data. Consider these scenarios:

• QoS policing on ICMP: many enterprise and service provider devices police or de-prioritize ICMP in hardware. You will see inflated latency and artificial packet loss in traceroute that does not reflect actual application traffic behavior. Always supplement with TCP-based probes (traceroute tcp on supported platforms) when ICMP results are suspect.
• Asymmetric paths: ICMP requests and replies may traverse different paths. A 50ms round-trip in your ping output could be a 10ms forward path and 40ms return path. Without running traceroutes in both directions (from both endpoints), you cannot determine where the latency is introduced.
• Intermittent packet loss vs. sustained packet loss: run extended pings with a high repeat count and track the distribution of losses. Losses clustered in bursts suggest a routing flap or interface error event. Evenly distributed losses suggest a congested link or a failing physical interface. Check interface error counters with show interfaces to correlate.

Practical Troubleshooting Workflow

In a structured diagnostics workflow, use these tools in sequence rather than in isolation:

1. Run a high-count extended ping with DF-bit set and a large datagram size to identify both reachability and MTU issues simultaneously.
2. Run traceroute with increased probe count (probe 5) to improve statistical confidence on each hop's latency measurement.
3. Identify the hop where latency increases and verify whether it is consistent across subsequent hops.
4. Cross-reference with show interfaces, show ip route, and show mpls forwarding-table at the suspected problem hop.
5. If ICMP results are inconsistent, use IP SLA with TCP probes or an application-level test to validate findings.

On IOS-XE, IP SLA extends these troubleshooting tools into a continuous monitoring framework. A basic UDP jitter probe provides latency, jitter, and packet loss measurements that are far more representative of real application traffic than a manual ping test:

ip sla 10
 udp-jitter 10.10.50.1 5000 source-ip 10.0.0.1 source-port 5001 num-packets 100
 frequency 60
ip sla schedule 10 life forever start-time now

Verify with show ip sla statistics 10 for ongoing visibility without manual intervention.

What's Next

With ping, traceroute, and IP SLA in your toolkit for reactive and proactive diagnostics, the next logical step is understanding how to implement structured monitoring at scale. The next post covers Cisco IP SLA in depth, including threshold-based alerting, tracking objects, and how IP SLA integrates with routing policy through object tracking to enable automated path failover. These are the building blocks of a self-healing network that responds to path degradation without manual intervention.

Tools and resources for this topic

• CCNP ENCOR 350-401 Official Cert Guide — The definitive ENCOR study resource by Brad Edgeworth. Covers enterprise infrastructure, virtualisation, and automation.