traceroute path normalized ?

[Justin-]

Hi all,

I'm running a topology inside GNS3 with routers (c3640) and end-devices (VPCs). Each router acts as an ASBR and, thanks to BGP, some routes are announced between ASes. So far, so good. When I use "trace" on an end-device to another, I can see the good path. The problem is, I don't see anything about the "other" path. I mean, from let's say U1 to U2, the response doesn't take the same path as the request, which is fine because this is what I configured. Still, there is nothing about it in the trace, even if the behavior is as expected (checked in the routes of the router, and traffic on its interfaces with Wireshark). So, the ICMP time-exceeded messages sent by my router are sent to a router on the "other" path, and I should see the address of the interface connected to this "other" router in the trace. But I don't. How can you explain that ? Is there some sort of traceroute normalization for the output ?

Thanks,

Justin

[Georg Pauwen]

Hello,

can you post the configurations of your routers so we can recreate the lab in GNS3 ?

[Peter Paluch · Accepted solution]

Hello Justin,

At least for Cisco IOS-based routers, if a router needs to send out an ICMP TTL Exceeded message for a packet, the ICMP message will be sourced from the address of the interface where the original expiring packet was received. It does not matter what interface the ICMP TTL Exceeded message is sent out from. This is the reason why you see the traceroute show you the path from U1->U2 even though the responses are sent back on an asymmetrical path U2->U1.

This behavior makes most sense because it allows you to understand the path through which the original packet arrived to a router that discarded it. If the router used any other address, you would know which router discarded the packet, but you would no longer be able to tell on what path the packet arrived, and whether that path is the expected one, so the usefulness of the ICMP TTL Exceeded message would be much smaller.

Please feel welcome to ask further!

Best regards,
Peter

[Justin-]

Peter,

Very interesting, thanks for your reply. Indeed, this was the explanation. I didn't know that specificity for IOS-based routers. I agree it's more coherent, even if it doesn't respect the RFC. Now I understand why.

Thanks again.

Justin