You have no items in your shopping cart.
Menu

Why Traceroute Shows Packet Loss on Cisco, Juniper & MikroTik (And Why Your Network May Be Perfectly Healthy

Why Traceroute Shows Packet Loss on Cisco, Juniper, and MikroTik
And Why the End Destination May Still Be Perfectly Healthy

One of the most common mistakes in network troubleshooting is assuming that packet loss shown on an intermediate hop in a traceroute means that hop is dropping customer traffic.

In many cases, that conclusion is wrong. Routers from Cisco, Juniper, MikroTik, and other vendors often deprioritize or rate-limit ICMP responses generated by the router itself. This can make traceroute appear to show packet loss in the middle of the path, while the final destination shows no loss at all.

The Key Rule

Packet loss on an intermediate hop does not automatically mean forwarding loss.

If packet loss does not continue through every hop after it, including the final destination, the loss is usually caused by ICMP rate limiting, control-plane policing, or router CPU prioritization.

How Traceroute Works

Traceroute works by sending packets with increasing TTL values. Each Layer 3 router decrements the TTL. When the TTL reaches zero, the router discards the packet and may generate an ICMP Time Exceeded message back to the sender.

Probe 1: TTL = 1
Probe 2: TTL = 2
Probe 3: TTL = 3
Probe 4: TTL = 4

Traceroute builds the path by collecting those ICMP Time Exceeded replies. The important detail is that the router is no longer forwarding the original packet. It is generating a new diagnostic response from the router control plane.

Forwarding Plane vs Control Plane

Modern routers separate packet forwarding from router-originated processing.

  • Forwarding plane: Handles transit traffic through ASICs, NPUs, FastPath, FastTrack, or hardware offload.
  • Control plane: Handles routing protocols, management traffic, ICMP generation, SNMP, SSH, BGP, OSPF, and other router-local functions.

A router can forward customer traffic at line rate while still choosing not to answer every traceroute probe.

Why Routers Deprioritize ICMP

ICMP replies generated by a router are diagnostic traffic. They are not the same as forwarding customer packets through the router.

Vendors protect the router CPU using mechanisms such as:

  • Control Plane Policing
  • Control Plane Protection
  • ICMP rate limiting
  • CPU scheduler prioritization
  • Exception packet policing

This is intentional. A router should prioritize forwarding production traffic over answering every ping or traceroute probe.

Example: False Packet Loss in the Middle

Hop 1     0% loss
Hop 2     0% loss
Hop 3    42% loss
Hop 4     0% loss
Hop 5     0% loss
Destination 0% loss

Hop 3 is not necessarily dropping transit traffic. If it were, the same loss would continue to Hop 4, Hop 5, and the destination. Since the destination has 0% loss, Hop 3 is most likely rate-limiting or deprioritizing ICMP responses.

Example: Real Forwarding Loss

Hop 1     0% loss
Hop 2     0% loss
Hop 3    10% loss
Hop 4    10% loss
Hop 5    11% loss
Destination 10% loss

This is different. When the loss continues through every downstream hop and the destination, the issue is likely in the forwarding path at or before the first hop where the loss begins.

Cisco Behavior

Cisco platforms commonly use hardware forwarding through CEF, ASICs, or forwarding engines while ICMP replies are generated by the route processor or control plane.

Features such as Control Plane Policing are designed to protect the router CPU. As a result, Cisco routers may show packet loss in traceroute while still forwarding transit traffic normally.

Juniper Behavior

Juniper routers also separate forwarding from control-plane processing. Transit packets may be forwarded by Packet Forwarding Engines, while TTL-expired packets and ICMP responses involve the Routing Engine.

Junos platforms often apply policers and protection mechanisms to keep control-plane traffic from affecting routing stability or packet forwarding.

MikroTik Behavior

MikroTik RouterOS has several forwarding paths depending on the hardware and configuration, including FastPath, FastTrack, bridge hardware offload, switch-chip forwarding, and L3 hardware offload on supported CRS and CCR platforms.

However, TTL-expired packets and router-generated ICMP replies still involve local processing. If the CPU is busy, or if ICMP is being limited, traceroute may show loss at the MikroTik hop even while normal routed or bridged traffic continues without issue.

How to Interpret Traceroute Correctly

  • Do not diagnose loss based only on an intermediate hop.
  • Look for loss that continues through every later hop.
  • Trust the final destination more than the middle of the trace.
  • Remember that ICMP responses are generated by the control plane.
  • Test with multiple protocols when needed: ICMP, UDP, and TCP.
  • Compare traceroute results with actual application performance.

A single hop showing loss does not prove a problem. Consistent loss at the destination is what matters.

Relevant RFCs and Best Current Practices

  • RFC 791: Defines IPv4 and the TTL field.
  • RFC 792: Defines ICMP for IPv4, including diagnostic error messages.
  • RFC 1812: Defines requirements for IPv4 routers, including TTL handling and ICMP Time Exceeded behavior.
  • RFC 4443: Defines ICMPv6 behavior.
  • RFC 4890: Provides recommendations for filtering ICMPv6 messages.
  • BCP 38 / RFC 2827: Covers ingress filtering to reduce spoofed traffic.
  • BCP 84 / RFC 3704: Extends ingress filtering recommendations for multihomed networks.

These documents explain the protocol behavior behind traceroute and ICMP. They do not require routers to prioritize diagnostic ICMP responses equally with transit traffic.

Conclusion

Traceroute is a useful tool, but it is often misunderstood. Cisco, Juniper, MikroTik, and other routers are optimized to forward traffic, not to respond to every diagnostic probe.

If an intermediate hop shows packet loss but the destination does not, the network path is usually healthy. The router is simply protecting its control plane, rate-limiting ICMP, or prioritizing real forwarding work over diagnostic responses.

About Link Technologies

Link Technologies specializes in network design, routing, wireless engineering, troubleshooting, and support for ISPs, WISPs, municipalities, and business networks. With deep experience in MikroTik, Cisco, Juniper, and multi-vendor environments, Link Technologies helps operators build networks that are stable, scalable, and correctly understood.

https://www.linktechs.net

Leave your comment

*
Only registered users can leave comments.