Customer might see delay in the traceroute option even for some directly connected peer.

Ping between end-to-end device is working fine without any drops.

Only found delay in traceroute option and that delay also vary at each time.

RE0> traceroute 10.233.44.4 no-resolve source 10.233.32.69

traceroute to 10.233.44.4 (10.233.44.4) from 10.233.32.69, 30 hops max, 52 byte packets

1 * * *

2 * * *

3 * * *

4 10.233.44.4 0.973 ms 0.865 ms 0.874 ms

RE0> traceroute 10.233.44.4 no-resolve source 10.233.32.69

traceroute to 10.233.44.4 (10.233.44.4) from 10.233.32.69, 30 hops max, 52 byte packets

1 * * *

2 * * *

3 * * *

4 * * *

5 * * *

6 * * *

7 * * *

8 10.233.44.4 0.973 ms 0.865 ms 0.874 ms

Sometimes, we may get one or more stars from a router in the output of traceroute. If we observe one or two stars, this usually means that the particular router is overloaded and didn’t respond to some of the traceroute probes. To verify this, we repeat the traceroute command. If the router appears without stars, we can say they were the result of a temporary transitory overload.

If they remain, further stars appear, or we don’t see this particular router in repeated outputs, it’s probably under heavy load conditions.

A sequence of three-star hops that persists in repeated traceroute probes even if we increase TTL indicates that the routers don’t respond because their owners forbade them to.

So, since repeated traceroute probes, gave the expected result, we can confirm that the overload peer router may be too busy to respond to the traceroute probe, which it considers a low-priority event.