Strange traceroute result (2nd hop equals to final destination)

[virgo]

Hi All,

I'm stumped by this weird traceroute result within our network.

Since we migrated our core router to an ASR-1001x, the traceroute result becomes somewhat strange.

2nd hop of traceroute used to be gateway IP address, however now it's replaced by the IP address of the final destination.

E.g:

C:\Users\User>tracert 1.1.1.1

Tracing route to one.one.one.one [1.1.1.1]
over a maximum of 30 hops:

1 * * * Request timed out.
2 3 ms 2 ms 3 ms one.one.one.one [1.1.1.1]
3 2 ms 2 ms 2 ms xx.xx.xx.xx [gateway ip address]
4 4 ms 3 ms 3 ms 14-201-91-85.static.tpgi.com.au [14.201.91.85]
5 4 ms 3 ms 3 ms 203-220-216-45.tpgi.com.au [203.220.216.45]
6 3 ms 3 ms 3 ms 27-32-160-4.static.tpgi.com.au [27.32.160.4]
7 3 ms 4 ms 3 ms 162.158.0.2
8 3 ms 3 ms 3 ms one.one.one.one [1.1.1.1]

Trace complete.

Any idea where to start looking?

I guess it's only a minor annoyance, the rest of the hops information are still useful, however it stops network utilities that relies on traceroute path (e.g. pingplotter, pathping) to work properly, since it will just stop on hop 2, thinking it has reached its final destination.

[Richard Burts]

This is strange. We do not have enough information to be able to understand the issue or to give good advice.

- what device is this PC connected to?

- if the PC is connected to a switch, is the switch operating as layer 2 only or as layer 2 and layer 3?

- do you have any switch or other network device other than the ASR? If so does traceroute from those devices have the same behavior?

- if the issue started when you migrated to the ASR it would be helpful if you would post the config of the ASR (disguising any Public IP and passwords).

[Giuseppe Larosa]

Hello @virgo ,

please post the following

show version

show inventory

attach the configuration file as txt file.

It might be the result of a new security feature, a cosmetic bug or the result of ethernet service instance with IRB active and your false positive hop might be the result of the way the control plane processes the ICMP probe with TTL set to 1.

The false positive can be the result of this scenario the L2 instance answers back with final destination like a flipper,  but a copy of the packet is sent to the main CPU for process switching and so the final destination is reached.

Once you have posted the above in text format we will be able to assist you

>>

I guess it's only a minor annoyance, the rest of the hops information are still useful, however it stops network utilities that relies on traceroute path (e.g. pingplotter, pathping) to work properly, since it will just stop on hop 2, thinking it has reached its final destination.

• Labels:
• ASR 1000 Series
• Routing Protocols

ok you need to check the documentation of those utilities pingplotter, pathping) to see if they can adapt to this scenario.

If not you can easily write down your own scripts in PERL or Python to handle this execption

Hope to help

Giuseppe

[Giuseppe Larosa]

I guess it's only a minor annoyance, the rest of the hops information are still useful, however it stops network utilities that relies on traceroute path (e.g. pingplotter, pathping) to work properly, since it will just stop on hop 2, thinking it has reached its final destination.

[virgo]

Hi All,

I found the cause of the issue and managed to fix it.

So it turned out that the network is pretty much like this:

PC (PPPOE client) -> ASR1001 as PPPOE server -> ASR1001 as BGP router -> peering partners

In PPPOE server, someone previously configured the interface using "ip unnumbered".

!

interface Virtual-Template1

 no ip address

 ip unnumbered Loopback0

!

interface Loopback0

 no ip address

!

Assigning an IP address to Loopback0 fixed the issue.

So my traceroute looks pretty much like this now:

1 * * * Request timed out.
2 3 ms 2 ms 3 ms xx.xx.xx.xx [pppoe server ip address]
3 2 ms 2 ms 2 ms xx.xx.xx.xx [gateway ip address]
4 4 ms 3 ms 3 ms 14-201-91-85.static.tpgi.com.au [14.201.91.85]
5 4 ms 3 ms 3 ms 203-220-216-45.tpgi.com.au [203.220.216.45]
6 3 ms 3 ms 3 ms 27-32-160-4.static.tpgi.com.au [27.32.160.4]
7 3 ms 4 ms 3 ms 162.158.0.2
8 3 ms 3 ms 3 ms one.one.one.one [1.1.1.1]

[Richard Burts]

Thanks for the update. Glad to know that you found and fixed the issue. +5 for sharing identification of the problem and how you fixed it.