Understanding a trace route

[WILLIAM STEGMAN]

I've looked at a trace route through my Frame Relay network and dont' quite understand why some router Interfaces do not show up and why different results show up when doing a trace only seconds between each other. e.g. from my windows desktop

C:\WINDOWS\SYSTEM32>tracert -d 10.2.0.1

Tracing route to 10.2.0.1 over a maximum of 30 hops

1 3 ms <1 ms <1 ms 10.4.0.84

2 <1 ms <1 ms <1 ms 10.4.0.1

3 15 ms 15 ms 15 ms 159.24.201.205

4 94 ms 97 ms 92 ms 10.2.0.1

Trace complete.

here's the same trace done seconds later

C:\WINDOWS\SYSTEM32>tracert 10.2.0.1

Tracing route to 10.2.0.1 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms 10.4.0.84

2 <1 ms <1 ms <1 ms 10.4.0.1

3 15 ms 92 ms 118 ms 10.2.0.1

Trace complete.

The first trace shows the serial interface of my router that leads to the MCI private IP, frame relay network, but does not show the serial interface of the San Diego router, which I pass through to get to their LAN, 10.2.0.1.

The 2nd trace shows no serial interfaces on either router. I dont' have any security settings prohibiting replies from my router in the trace route path. I doubt the other sites do, but is there something I should look for in the config that would do that? I would expect to see serial interfaces that have the T1s running on them in the path all the time, and if it was a security measure blocking the replies, I would see an * wouldn't I?

[pkhatri]

Howdy,

I suspect the reason for this is that there are multiple paths to your destination within the private IP network. Every time you send a packet there is a dynamic hashing done to determine what path the packet will take when multiple paths are present. That's why you see different nodes in the route at different times...

Hope that helps - pls rate posts that help.

Regards,

Paresh

[mheusinger]

Hi,

besides the IP showing up or not, what makes me wonder is the response time from the second tracert.

How can 10.2.0.1 answer within 15 ms, where it was 95 ms before. What is the response time with unloaded interfaces? Looks like the first WAN router answers with 10.2.0.1 sometimes. Could there be two interfaces and one with this IP? A tracert would stop after receiving an ICMP from the destination IP.

Load sharing across two pathes to the WAN router - like Paresh explained - could lead to this effect, when the WAN router has 10.2.0.1 on an interface.

Second question: is there any tunneling technology in place somewhere?

Hope this helps! Please rate all posts.

Regards, Martin

[WILLIAM STEGMAN]

No tunneling technology present. I'm still confused why I wouldn't see the wan side of a router, when I need to traverse the wan side of the router to get to the ethernet side, 10.2.0.1. Basically my setup is

PC -> fa 0/0 (10.4.0.1) -> serial 0/1/0 (159.24.201.205) -> PIP frame relay network -> serial 0 (159.24.201.102) of remote routers -> fa 0/0 (10.2.0.1)

What confuses me, is I don't always see the serial interfaces, which are in the path of the traceroute. My concern stems from the fact that our Internet connection need to traverse the remote router's fa 0/0 interface, but the path would indicate the ethernet interface is being bypassed. The example above does not illustrate that specific scenario, but does indicate the same behaviour. Is there any reason those serial interfaces wouldn't appear in a traceroute? Load balancing wouldn't be an issue, since all my Internet traffic definately crosses that serial interface.

Thank You,

Bill

[pkhatri]

Hi Bill,

Just a clarification: the 10.4.0.1 and 159.24.201.205 are on the same router, right ? And also the 159.24.201.102 and 10.2.0.1 ?

What device has the 10.4.0.84 address ?

Thanks,

Paresh

[WILLIAM STEGMAN]

That's correct. The 10.4.0.1 and 159.24.201.205 are on the same router, and 159.24.201.102 and 10.2.0.1 are on the same router.

The 10.4.0.84 is my multilayer switch and default gateway for the LAN clients.

[pkhatri]

Howdy,

It does seem a bit odd...

What would really help is if you could also get the output of 'debug ip icmp' on your two WAN-facing routers (the local and the remote) when you do the traceroutes... We could then see what the ICMP time-exceeded messages are saying ....

Paresh.

[WILLIAM STEGMAN]

I tried

debug ip icmp

and

term mon

since I'm telnetting, but I get no debug info appearing on my screen when pinging or doing traceroutes.

I'm lost. I've run the test a few more times, and it still never shows any serial interfaces. I was hoping to blame it on MCI's PIP, but I have a router connected via a point 2 point and get the same results. From a PC, that has a default gateway of 10.4.0.84(the Multilayer switch, which doesn't appear in my trace now)it goes to my router's ethernet interface, doesn't display the serial interface, but does display the serial interface of the router at the other end of the point 2 point, and then skips the ethernet interface of that router and show the host on the remote LAN...my faith in traceroute and/or my understanding or routing is failing.

H:\>tracert 10.4.2.32

Tracing route to CADBASE [10.4.2.32]

over a maximum of 30 hops:

1 <1 ms <1 ms 1 ms 10.4.0.1

2 3 ms 3 ms 3 ms 10.0.4.2

3 3 ms 3 ms 3 ms CADBASE [10.4.2.32]

Trace complete.

[pkhatri]

Hi,

Did you check the output of 'show logging' when you ran the debugs ?

Paresh.

[pkhatri · Accepted solution]

Just another query... what is the subnet mask you are using for your PCs on the 10.4.0.x segment... You seem to be using the same network for your PCs and the link between the multi-layer switch (10.4.0.84) and the router (10.4.0.1) ...I presume you are using different subnets for the two.... If you are using the same subnet for both the links, this could be causing your issues.

Now, theoretically, based on your setup, you should see the following hops when you ping from a PC on the 10.4.0.x segment to 10.2.0.1:

1 - 10.4.0.84

2 - 10.4.0.1

3 - 159.24.201.102

4 - 10.2.0.1

You should not be able to see the serial interface of your first router (159.24.201.205) in the output. This is because when the packet reaches the first router and is dropped due to TTL hitting zero, the ICMP time-exceeded messge will be returned through its ethernet interface so you should see its ethernet interface in the traceroute.. The next packet with the TTL one higher than the last will be dropped by your remote router and the ICMP time-exceeded message through its serial interface so you should see its serial interface in the traceroute. Does that make sense ? So, looking at your first post, the correct traceroute output is the first one.

Based on the above reasoning, the output you included in the last post of yours is totally correct. The key to understanding this is that you will only ever see one IP address from each router when you do a traceroute. And this interface will always be the first interface through which the packet enters the router.. That's why you see the serial interface and not the ethernet interface.

Hope that helps - pls rate posts that help.

Regards,

Paresh

[mheusinger]

Hello,

the source IP of an ICMP reply of a router will be the interface where the router will send the ICMP packet. With symmetric routing this should be the interface on which the packet was received. In case this interface is down, or IP routing at the ICMP cretion time points somewhere else to the destination of the ICMP reply, however it will take ANOTHER IP address in the system. Could you have some LAN interface flaps? Maybe too short to be seen from "show ip interface brief", but are there any interface resets or other errors on the ethernet?

Regards, Martin

[WILLIAM STEGMAN]

That seems to fit, "The key to understanding this is that you will only ever see one IP address from each router when you do a traceroute. And this interface will always be the first interface through which the packet enters the router."

That works for every traceroute I do, only the 1st interface of each router in the path the trace hits is revealed.

Thank you