Traceroute works by sending out three ICMP packets towards the destination IP. Each of those three packets has a TTL of 1 so that they will only reach the first hop. When they reach the first hop, that router will send an ICMP response. The three times you see in milliseconds is the round trip time of each of those three packets sent.
Next, traceroute sends out another three ICMP packets towards the destination IP with a TTL of 2, so that they reach the second hop in the path, which responds with the round trip time.
Traceroute will continue to increase the TTL until it gets a response from the actual final destination. Then it will stop and it will say âTrace complete.â
Now routers on the Internet can be configured not to respond to ICMP packets. This is often done for security purposes. During traceroute, if packets reach such a router, the default timeout of 2 seconds elapses, and traceroute considers that hop timed out. It then responds with â*â in the place of times and it states âRequest timed outâ. However traceroute does not end there. It will continue to send the next set of three packets with an increased TTL.
Each time you see * * * Request timed out. it means that the particular router is configured not to respond to ICMP packets.
Now if the final destination is also configured not to respond to ICMP packets, then it may be that the traceroute will never be complete. Traceroute allows for a maximum of 30 hops. Anything higher is considered unreachable, so it doesnât even try. In the output you are showing above, the actual destination does respond, and once it does, the trace is complete. If it does not, traceroute will continue to attempt the trace, increasing the TTL until 30 hops are reached, where it considers the trace inconclusive.
(You can increase this default maximum hops of 30 to anything up to 255, but anything beyond 30 on the Internet is considered for all intents and purposes unreachable).
This is output from the response to a ping request. A ping is an ICMP echo request that is sent to a particular destination. If the response is âDestination Host Unreachableâ then this response comes from a router somewhere on the path to the destination, and most likely the last hop router, or the router to which the particular subnet in which the destination IP is found is directly connected.
So if you have pinged 192.168.100.2 for example, and your ping reaches the router that is connected to the 192.168.100.0/24 subnet, if that router canât find the host, it will respond with the âDestination Host Unreachableâ message.
so does it mean âhost sends packet by increasing the TTL by 1 every time upto 30 thrice (to take average time) which is maximum hops (this can be increased to 255) no matter how many routers passed is my destinationâ, please correct me if i am wrong
Yes, this is the case. The maximum will be 30 hops even if your destination is found more hops than that, but you can always increase the number of hops in traceroute.
However, over the Internet, you will rarely find a path take more than 30 hops. This is kind of an unwritten rule, that there should be no more than 30 hops to reach any destination on the Internet from any destination, so it is unlikely that you will be required to increase that limit.
By increasing the TTL each time, you are increasing the number of hops that the echo request will travel. This keeps going until you reach the destination. This image depicts this very well:
I have a question, If I want to test with router to router using the traceroute command, how can I take a packet capture on the router and send it to the PC ? so we can analyze with wireshirk tool.
Thank you!
In order to capture packets that traverse the network that donât have a PC as a source or destination (such as a traceroute between routers), you must use a feature of Cisco switches called Switch Port Analyzer (SPAN). This feature allows you to copy packets that traverse one port on a switch to a second âmonitoringâ port on that switch. You can then connect a PC with Wireshark to that monitoring port to capture the packets.
More information about this feature and how you can make it work can be found at the following lesson:
Now if you have two routers connected to each other and you are performing traceroute between them, and you want to capture the packets being sent and received, you must place a switch between those two routers and configure it with SPAN. Review the lesson above to see more details of how you can do this.
By default, the traceroute command will only trace a path up to 30 hops away. If the destination is more than 30 hops, it will simply stop at 30. In your above output, if you let it continue, it would stop by itself at 30. This is because most destinations on the Internet will most likely not be more than 30 hops away. You can change this parameter to a value up to 255 by using the -h option in the Windows command prompt:
C:\Users\user>tracert
Usage: tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout]
[-R] [-S srcaddr] [-4] [-6] target_name
Options:
-d Do not resolve addresses to hostnames.
-h maximum_hops Maximum number of hops to search for target.
-j host-list Loose source route along host-list (IPv4-only).
-w timeout Wait timeout milliseconds for each reply.
-R Trace round-trip path (IPv6-only).
-S srcaddr Source address to use (IPv6-only).
-4 Force using IPv4.
-6 Force using IPv6.
Hi Team, I have a question in Traceroute, I am connected via VPN and when I trace to any destination , for some reason it is displaying the same hops as equal as destination. why is this so ?
If you are tracing the path to various destinations and you find that all of those destinations have the same number of hops, then according to traceroute, they are indeed the same number of hops away. There is nothing mysterious about it.
Also, when you use traceroute over a VPN, remember that the path between the termination points of the VPN is only one hop. Your VPN might traverse the whole Internet and go through 15 routers to get from you to your corporate network, but even so, the traceroute takes place via the VPN tunnel, and the path through the VPN tunnel is seen as a single hop.
Lets say I am connecting to a RDP machine which is in 10.2.x.x. Now when I trace to a destination server which is in 192.167.5.6. I am getting 192.167.5.6 in all my hops. Why is this so ?
When you see the same IP address in many hops in a traceroute, this can indicate that there is a routing loop. What is actually happening depends upon if the traceroute successfully reaches the destination or not, and it also depends on what other information is contained within the whole trace. Can you share some output of the whole trace of some examples that you see? That way weâll be able to respond more specifically to your questionâŚ
Please see the below pasted tracert result from my system . I am connected to office network via VPN and when I am trying to trace one of the office server , the below is what I am getting.
Tracing route to 10.153.200.6 over a maximum of 30 hops
1 97 ms 98 ms 97 ms 10.153.200.6
2 98 ms 98 ms 97 ms 10.153.200.6
3 111 ms 105 ms 102 ms 10.153.200.6
4 181 ms 233 ms 182 ms 10.153.200.6
5 184 ms 184 ms 185 ms 10.153.200.6
6 186 ms 183 ms 184 ms 10.153.200.6
7 179 ms 178 ms 178 ms 10.153.200.6
This is indeed an interesting situation. It seems that the destination IP is routing to itself, and you can see the response times rising as if it is going through multiple hops. Without knowing more about your topology, Iâd like to ask the following questions:
What device has this IP address? Is it a server within the office network or a networking device? If itâs a networking device, it would be interesting to see what its routing table looks like.
What kind of VPN do you have installed? Does it use an ASA? It seems that the ASA has an interesting behaviour when tracerouting over a VPN link. The ASA will actually avoid decrementing the TTL, so it may be that without one decrement, the tracroute process reaches the destination, but the TTL is not 0 on its return, so it keeps sending packets. It turns out traceroute cannot accurately measure hop count through an ASA VPN tunnel unless it is configured appropriately.
Some interesting links that may help you in your troubleshooting include:
Let us know of your progress so we can continue to help you.
Hi Laz,
the destination device is network device. Also Am connected via Any connect VPN .And as you say that ASA might have this kind of behaviour where it avoids decrementing the TTL, Can you tell or show me the best configurations to overcome this situation ?
If this is indeed the problem, the fact that the ASA will not decrement the TTL, then you will need to modify that default behaviour. This is done using the following command:
set connection decrement-ttl
This should be implemented on the global policy map as below (or in a specific policy map that is applied to the appropriate interfaces).
policy-map global_policy
class class-default
set connection decrement-ttl
The following command line reference describes this feature.
The usage guidelines shed some light on its purpose like so:
This command, along with the icmp unreachable command, is required to allow a traceroute through the ASA that shows the ASA as one of the hops.
If you decrement time to live, packets with a TTL of 1 will be dropped, but a connection will be opened for the session on the assumption that the connection might contain packets with a greater TTL. Note that some packets, such as OSPF hello packets, are sent with TTL = 1, so decrementing time to live can have unexpected consequences.
1)In Given traceroute commands could you explore about probes:
R1#traceroute 192.168.3.1 probe 1
Type escape sequence to abort.
Tracing the route to 192.168.3.1
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.12.2 0 msec
2 192.168.23.3 4 msec
3 192.168.3.1 0 msec
R1#traceroute 3.3.3.3
Type escape sequence to abort.
Tracing the route to 3.3.3.3
VRF info: (vrf in name/id, vrf out name/id)
1 * * *
2 * * *
3 * * *
Actually as per topic by default traceroute send 3 probes so in first one we have mentioned to use single probe but output of both seems ( forget about destination no reachable), i just want to know probe concept in both cases?
I am also confused about TTL, actually the eg you used to explain this in which windows/Linux PC do ping for destination so as per first scenario where TTL=1 in ip packet sent by PC but R1 reply with TTL of 255 as well as when packet reaches to destination where we use TTL=4 & destination PC reply with TTL=125 how? I think it must reply with TTL=1 so my concern is that how is this happening and is TTL configurable b/c by default windows TTL is 128.
