12-03-2013 06:26 AM - edited 03-04-2019 09:45 PM
Heloo
I was wondering why a regular traceroute to Google dns (8.8.8.8) fails to go past first hop, but an extended traceroute to google dns (8.8.8.8)
gets all the way to hop (1) before dropping?
Solved! Go to Solution.
12-03-2013 06:29 AM
It would help if you would tell us what options you chose in extended traceroute. If the behavior was different then something changed. Perhaps it was an option that you chose in extended traceroute. Or perhaps it was something that changed in the network. Did you try both a couple of times to verify that the issue is repeatable and therefore something about extended traceroute rather than some external thing?
HTH
Rick
12-03-2013 07:31 AM
Thanks for the additional information. I believe that it does show us why the behavior was different. By default the Cisco device will use the IP address of the outgoing interface as the source address for the traceroute. In the extended traceroute you specified an IP address for the source address (and I am assuming that it was not the address of the outgoing interface). When the source address was the outgoing interface the traceroute did not work and when the source address was 10.42.21.101 then it did work.
We can not say at this point what causes the regular traceroute to fail, but it could easily be that the specified address is being translated and the outgoing interface address is not. Or it might be a security policy that is denying the address of the outgoing interface. Or it might be something else.
HTH
Rick
12-03-2013 06:29 AM
It would help if you would tell us what options you chose in extended traceroute. If the behavior was different then something changed. Perhaps it was an option that you chose in extended traceroute. Or perhaps it was something that changed in the network. Did you try both a couple of times to verify that the issue is repeatable and therefore something about extended traceroute rather than some external thing?
HTH
Rick
12-03-2013 07:04 AM
Rick
Thank you for the reply
Here is the process I used. I have repeated this with same result.
Site_1#traceroute 8.8.8.8
Type escape sequence to abort.
Tracing the route to 8.8.8.8
VRF info: (vrf in name/id, vrf out name/id)
1 10.254.0.9 [AS 64531] 60 msec 60 msec 60 msec
2 * * *
3 * *
Site_1#traceroute
Protocol [ip]:
Target IP address: 8.8.8.8
Source address: 10.42.21.101 - LAN interface ip address on WAN router
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to 8.8.8.8
VRF info: (vrf in name/id, vrf out name/id)
1 10.254.0.9 [AS 64531] 60 msec 60 msec 64 msec
2 10.44.41.1 [AS 64554] 64 msec 60 msec 60 msec
3 66.195.148.1 [AS 64531] 60 msec 60 msec 60 msec
4 207.250.147.249 [AS 64531] 64 msec 64 msec 64 msec
5 66.192.243.142 [AS 64531] 72 msec 72 msec 72 msec
6 72.14.212.199 [AS 64531] 72 msec 72 msec 72 msec
7 209.85.254.130 [AS 64531] 72 msec
209.85.254.122 [AS 64531] 72 msec
209.85.254.130 [AS 64531] 96 msec
8 209.85.254.238 [AS 64531] 72 msec
72.14.237.130 [AS 64531] 100 msec 72 msec
9 72.14.238.106 [AS 64531] 100 msec 100 msec
72.14.232.141 [AS 64531] 116 msec
10 216.239.43.217 [AS 64531] 96 msec
216.239.46.191 [AS 64531] 96 msec
216.239.43.217 [AS 64531] 96 msec
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
12-03-2013 07:31 AM
Thanks for the additional information. I believe that it does show us why the behavior was different. By default the Cisco device will use the IP address of the outgoing interface as the source address for the traceroute. In the extended traceroute you specified an IP address for the source address (and I am assuming that it was not the address of the outgoing interface). When the source address was the outgoing interface the traceroute did not work and when the source address was 10.42.21.101 then it did work.
We can not say at this point what causes the regular traceroute to fail, but it could easily be that the specified address is being translated and the outgoing interface address is not. Or it might be a security policy that is denying the address of the outgoing interface. Or it might be something else.
HTH
Rick
12-03-2013 12:22 PM
Richard
Thank you for the response.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide