Hi rene
Can you please expalian me why we need 3 probes for traceroute as we can do it with 1 probe only…
Thqnks
Hello Rosna
I apologize for not responding to this message sooner. It seems to have slipped through the cracks. I will respond now, better late than never.
Traceroute will send UDP datagrams to an invalid port on the destination IP. However, it begins by sending them with a Time To Live (TTL) value of 1 in the IP header. The first router in the path will receive it, will make the TTL value 0 and respond with a Time Exceeded Message (TEM). The TTL on the next set of packets is set to 2, and the same procedure is followed.
When the final set of UDP datagrams are sent, and the actual destination is reached, because the UDP datagrams are sent to a (purposefully) invalid port, the destination device will respond sending back a port unreachable message. This indicates that the packet has indeed reached the destination. Because all of the other intermediate devices that send the TEM messages never get to de-encapsulate to the UDP header and to even examine ports, there are no port unreachable messages sent back by those devices.
I hope this has been helpful!
Laz
Hello Sumant
Traceroute by default sends three probes. Now traceroute can indeed perform its fundamental function correctly with only a single probe, however, it is possible to glean more information such as asymmetric routing from three probes as opposed to one. Additionally, an average value of three probes for response time is more valuable than just a single probe. In general, having more information is beneficial for evaluating and testing the network.
I hope this has been helpful!
Laz
Hello! Why in the capture of R1 request it shows the line “user datagram protocol” and show info about ports if these kind of probe should not work with layer 4? and it does not show Internet control message protocol but R2 and R3 captures do show it. I’m confused. Thank you!
Hello Eliu
Your observation is well taken, and thank you for pointing that out. I should have been clearer in my explanation. You will notice that there is no UDP information in any of the captures that have to do with the ping command while you will see the UDP line as well added to that for any of the captures that have to do with traceroute. Ping does not include layer 4 however, traceroute incorporates layer four, specifically UDP in order to achieve its functionality.
The default implementation of traceroute sends a sequence of UDP packets, with destination port numbers ranging from 33434 to 33534. This is how the Cisco implementation works by default.
However, the implementations of traceroute on other platforms can vary. For example, traceroute shipped with Linux and macOS based operating systems includes an option to use ICMP Echo Request packets instead of UDP, or even any arbitrary protocol such as UDP or TCP using TCP SYN packets. In Windows, traceroute uses ICMP echo requests instead of UDP packets.
So by default, ping uses ICMP on top of IP (layer 3), traceroute uses UDP (layer 4) on top of IP. But ultimately, ICMP still remains a strictly layer three protocol.
I hope this has been helpful!
Laz
2 Likes
Hi Rene,
Suppose I am unable to ping destination address but able to trace it, what might be the reasons. As you mentioned Ping & Trace works on ICMP protocol
Hello Aniket
Although both traceroute and ping use the ICMP protocol, they are employed differently. Let’s say host A pings Host B. Host A will send an ICMP echo request packet to Host B. If received successfully, Host B will send an ICMP echo reply packet to Host A. These are IP packets with the IP addresses of Host A and Host B in the IP header as source and destination addresses as the case may be. Such packets may fail usually because Host B is configured to drop ICMP echo request packets destined for its own IP address.
Now in the above case, , traceroute would succeed. Why? This is because traceroute does not request an echo from the destination, but depends on ICMP error/status messages. The response that you see in the output is actually an error response. This response is specifically a Time To Live exhaustion. Even the final hop of the traceroute, where the ICMP packet reaches the intended destintion, the response is not an echo response but an ICMP message stating TTL = 0 was reached.
(for details about how traceroute works with the TTL value, take a look at the folloing lesson:
Now in the above scenario, traceroute will get a response from the destination Host B, whereas ping would not. This is because only echo request packets that are being dropped. The ICMP messages about TTL are responded to as normal.
This is one scenario where ping may not work and traceroute will. There may indeed be others…
I hope this has been helpful!
Laz
Thanks for the response Lazaros… This is really helpful.
What if I have to block traceroute as well along with ping, how can we achieve this ?
Hello Aniket
If you deny all ICMP packets using an access list this will block both traceroute and ping as well as some other useful services that use ICMP such as MTU path discovery. Access lists can be configured with particular parameters to block some types of ICMP packets and not others. These three access lists for example will block any ping echo request packets, ping echo reply packets and traceroute time exceeded error response packets respectively:
access-list 100 permit icmp 192.168.1.0 0.0.0.255 any echo
access-list 100 permit icmp any 192.168.1.0 0.0.0.255 echo-reply
access-list 100 deny icmp 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 time-exceeded
ICMP has many message types, of which the above access lists will block these three. Use the “?” in the command to see what other ICMP options can be blocked.
I hope this has been helpful!
Laz
A couple of things listed in this Forum I want to make sure I understand…
In the following:
“So by default, ping uses ICMP on top of IP (layer 3), traceroute uses UDP (layer 4) on top of IP. But ultimately, ICMP still remains a strictly layer three protocol.”
Did it intend to say traceroute still remains a strictly layer three protocol?
Also, these statements seem to contradict. I believe the first one is correct that a Cisco tracroute will start with a destination UDP port of 33434 instead of a random port number?
“The default implementation of traceroute sends a sequence of UDP packets, with destination port numbers ranging from 33434 to 33534. This is how the Cisco implementation works by default.”
“You are correct in your understanding Cisco’s use of UDP. Cisco picks a random destination UDP port and once the packet arrives at the intended target, the target replies back with a Type 3 ICMP (Destination Unreachable) because it is likely that the target device does not have the randomly chosen UDP port open.”
Hello Daniel
ICMP is what is known as a supporting protocol of the TCP/IP suite and is considered a Layer 3 protocol. It doesn’t really run “on top of” IP, but it runs within IP. The ICMP header actually starts right after the end of the IPv4 header, and is indicated by a value of 8 in the Protocol field of the IPv4 header. Traceroute however is not a protocol, but it is a utility that uses the ICMP protocol.
As for the actual implementation of traceroute, it really depends on the operating system that is being used. Linux, Cisco IOS, Windows, and other operating systems may have different ways of implementing the utility. You can get a definitive answer to how it functions within Cisco at this Cisco documentation:
I hope this has been helpful!
Laz
Hello Networklessons
What about a test of traceroute that I am performing to a destination 8.8.8.8?
Trough the traveling of the packet, I got * characters response, for instance : 10 * * *
This is because some ISP filter my UPD packets?
The fact that I can not see the entire path it does not mean that I can not ping ( have connectivity ) or get to the destination? Im asking this because sometimes I have ping but the traceroute to some servers on the internet does not show the entire path, even I only receive ****** responses.
Please find attached an example.
Regards.
Hello Rodrigo
What you are experiencing with your traceroutes is common. Remember that traceroute uses ICMP packets to send an echo request to each of the routers in the path between the source and destination. Many of these devices are configured not to respond to ICMP packets for security reasons, because ICMP can be used by attackers to disable or attack these systems. But as you said, this does not mean that the path to the destination is unreachable. Imagine you have the following scenario through the Internet:
Host1—R1—R2—R3—R4—R5—R6—Host2
Here Host1 is sending a traceroute to Host2. Let’s say R4 is configured not to respond to ICMP packets. So traceroute will send an ICMP request to each of the routers in the path using an incremented TTL. (For more info on how traceroute works, take a look at this lesson.) All the routers will respond except for R4, and for that entry you will see the “* * *” responses which is essentially an ICMP timeout.
Even so, R4 will still route packets and thus traceroute will continue to query R5, R6 and will also reach Host2. So connectivity is still achieved.
Now if you are getting timeouts all the way to 30 hops like in your example, this simply means that even the destination host of 8.8.8.8 does not respond to traceroute ICMP packets. This means that traceroute will continue to test connectivity increasing the TTL by 1 every time, but if it never gets a response from the final destination, it will go to the maximum of 30 hops and end there. Note that a host can be configured not to respond to traceroute ICMP packets but to respond to ping ICMP packets. This is why you may be able to ping your destination but not traceroute it…
I hope this has been helpful!
Laz
Excelent! Thanks a lot!
1 Like
Hi @lagapidis
can you explained that more??
“R3 will reply with a type 3 destination unreachable message. Take a close look at the code, it indicates that the port is unreachable. This is because nothing is listening on UDP port 33435. At least R1 now knows that 192.168.23.3 is reachable.”
Thanks
Hi @abrbjy100,
Let me clarify this. I also updated this in the lesson. RFC 792 states this:
If, according to the information in the gateway’s routing tables,
the network specified in the internet destination field of a
datagram is unreachable, e.g., the distance to the network is
infinity, the gateway may send a destination unreachable message
to the internet source host of the datagram. In addition, in some
networks, the gateway may be able to determine if the internet
destination host is unreachable. Gateways in these networks may
send destination unreachable messages to the source host when the
destination host is unreachable.
This means we use a destination unreachable message when we can’t reach the destination host/network. The RFC also states this:
if, in the destination host, the IP module cannot deliver the
datagram because the indicated protocol module or process port is
not active, the destination host may send a destination
unreachable message to the source host.
So, when the destination port is unreachable, it will also use the destination unreachable message.
In the example, R3 replies so the source IP is 192.168.23.3. R1 receives this message, so we know that 192.168.23.3 is “alive”. It’s R3 that tells R1 that the port is unreachable.
Does this make sense?
Rene
Very nice analogy !!Thanks for this very easy example
1 Like
Hello team,
what will be the reasons, if we are getting an inaccurate responses in ping response.
inaccurate means sequence numbers.
Gowtham
Hello Gowthamraj
When an ICMP echo request is sent, it contains an identifier and a sequence number in the ICMP header. The identifier and the sequence number are used to match the ICMP echo reply with the corresponding request. How these values are used depends on the operating system. For example, Linux will create a unique identifier for each ping process and the sequence number is an increasing number within that process. Windows will use a fixed identifier and a sequence number that is incremented for each ping, and is only reset if the device is rebooted.
In any case, there may be various reasons for sequence numbers to be inaccurate. Anything from a bad network connection, to an error in the operating system. The header does have a checksum feature that does check the integrity of the ICMP header, and many such errors may be found, and packets discarded.
These sequence numbers generally are not displayed in the echo requests and replies, unless you view them in packet capturing software like wireshark. Can you give us a more detailed example of inaccurate sequence numbers that you have seen so that we can respond more specifically to your question?
I hope this has been helpful!
Laz
