TRACEROUTE QUESTION

[stevennowell]

Got a traceroute question? When you see output from a traceroute that has ip?s from multiple interfaces on the same device, like the one below, can you tell me what would cause that? In the case below the first and third address under each hop is the same ip?

I am suspecting that each probe took a different route, but am confused by what the effect would be on subsequent hops. Thanks.

Success rate is 100 percent (5/5), round-trip min/avg/max = 64/65/68 ms

RT852CR01#trace 10.111.1.5

Type escape sequence to abort.

Tracing the route to 10.111.1.5

1 10.112.2.141 0 msec

10.112.2.10 0 msec

10.112.2.141 4 msec

2 10.112.2.148 0 msec

10.112.2.17 0 msec

10.112.2.148 4 msec

3 10.119.250.113 [AS 64512] 0 msec 0 msec 0 msec

4 10.119.250.101 [AS 64512] 68 msec 64 msec 64 msec

5 10.119.250.98 [AS 64512] 64 msec 64 msec 64 msec

6 10.111.2.245 [AS 65132] 64 msec 64 msec 64 msec

[Richard Burts]

Steve

To answer your question lets start with a brief review about traceroute. The normal traceroute sends 3 probes with TTL of 1. It gets to the first hop and expires and sends back the expired message and we know what was the second hop. Increment the TTL by one and do it again. Keep doing the 3 probes, increment the TTL until either you get the response that you reached the destination (which is actually a port unreachable error) or till you get to max hops.

So you did a traceroute to 10.111.1.5. Your router has two paths in the routing table to that destination. The router is going to send 3 probes with TTL of 1 (indicated by 1 in the listing). The first packet went out one interface and got a response from 10.112.2.141. The second packet went out the other interface and got a response from 10.112.2.10. The third packet went out the first interface and got a response from 10.112.2.141. Then a similar thing happened with TTL of 2. A packet went out one interface and got a response from 10.112.2.148. The second packet went out the other interface and got a response from 10.112.2.17. The third packet went out one interface and got a response like the first one did. After TTL of 2 it looks like the paths through the network converged because you are no longer getting different response addresses with each increment of TTL.

HTH

Rick

[stevennowell]

Thanks for the well exlained response! That was great.

I still have a couple additional questions, and its possible you exlained it above and I just didnt get it.

When I have multiple paths given, can I assume that they are equal cost, by virtue of it being displayed?

Also, when I see multiple divergent paths that transit different devices and eventually reconverge at my target IP, how is what is actually printed to the screen in the traceroute output determined by the router? Is the shortest, or least cost path shown (guessing here). When my router saw multiple paths to my target in the example I put in my original post, how was the next hop path determined when there was multiple options shown?

[stevennowell]

I should also add that in my example all ip's given at each hop are interfaces in a singular device. Would it be possible to display multiple egress options at a given hop and have them be on separate devices?

(when i say how was the path determined above, i didnt mean from a routing perspective, i meant from the perspective of what traceroute output that would be chosen to print to the screen)

[Richard Burts · Accepted solution]

Steve

I have read your follow-up posts and will attempt to answer them.

Let me start by emphasizing that traceroute packets are regular routed IP packets (if it of interest traceroute from *nix boxes and Cisco boxes are UDP packets and tracert from Windows is ICMP packets) and a lot of the answers to your questions depend on the behavior of regular routed IP packets.

So, yes if you see multiple paths in traceroute that is because the ip routing table had multiple entries of how to get to the destination. And if the routing table has multiple entries of how to get to the destination then that means that they were equal cost.

I am less sure of how to answer your next question about how what is actually printed determined by the router. So let me review what happens and hopefully that will be an adequate answer. Your router sends packets toward the destination and manipulates the TTL. As the packets go through the network (processed by normal routing logic) they get to a router where the TTL expires. The router at which they expire will discard your packet and send back an ICMP packet indicating the error. Your router is able to determine the path through the network hop by hop from these ICMP error messages. The source address of the error packet will be the interface address of the router which discarded your packet. So what your router prints is the hop count, the address of the router generating the ICMP error, if it can resolve it the name of the router, and the time that it took to receive the error message.

I believe that the other part of your question here is how your router chooses the path when there are multiple paths possible. Packets generated by the router are inherently process switched. And when the router is process switching it will take turns over all the available paths. After your router makes the decision about how to route to the first hop, then it becomes a routing decision for the next router how to route the second hop, and so forth.

And for the last part of your question: in your example the multiple path responses may have come from a singular device, but it is quite possible that the responses could come from multiple devices.

HTH

Rick

[stevennowell]

Rick, thanks a million for the time you invested in helping me. You thoroughly covered my questions and I very much appreciate it. Take care.

[Richard Burts]

Steve

I am glad that my answers were helpful. Thanks for using the rating system to indicate that your issue was resolved. (and thannks for the rating) It makes the forum more useful when people can read questions and know that they will find answers that successfully answered the question. I encourage you to continue your participation in the forum.

HTH

Rick

[harindhafdo]

Hi All,

Is there a way to configure a Cisco Router to reply to the TTL message only with its loopback ip rather than the interface ip? if yes, can you provide the configuration to acheive it?

Thanks & Rgds

Harin

[ITexpert]

@Richard Burts  @balaji.bandi 

what does  *    *   *  in traceroute means ?

Please see attached picture ?

[Richard Burts]

The * in traceroute output indicates a probe packet for which you did not receive a response packet and the probe timed out. It may help understanding if we remember that traceroute works by sending probe packets and manipulating the Time To Live. And that Cisco traceroute typically sends 3 probe packets for each TTL. 

so 1 * * * means that for TTL = 1 all 3 probe packets timed out

2 * * * means that for TTL = 2 all 3 probe packets timed out

etc

HTH

Rick

[ITexpert]

Hello @Richard Burts, my ping is working but traceroute is coming like that, do i need to worry for this ?

[Richard Burts]

If you think about it, both ping and traceroute attempt to give information about connectivity to some remote IP address. In that view both ping and traceroute agree that there is successful connectivity between your IP address and the remote IP address.

And if you think a bit further ping only cares about end to end connectivity but traceroute attempts to provide information about the step by step path toward the destination. So what do you really want from traceroute? If you are looking to verify end to end connectivity then do not worry about the traceroute results. If you are looking for hop by hop identification of the path then perhaps you need to worry because traceroute can not provide information for several hops. So why are you really using traceroute?

HTH

Rick

[ITexpert]

@Richard Burts  I dont know what was the reason, I just reconfigure the IGP (eigrp ) aand it looks ok now but unable to find the cause.

[Richard Burts]

Glad to know that you reconfigured eigrp and that traceroute looks ok now. We do not know for sure why it has that behavior but my best guess is that when you reconfigure eigrp that the traceroute takes a somewhat different path through the network and that all the devices along this path do respond about TTL expired.

HTH

Rick