ICMP (Internet Control Message Protocol)

Hello TAIMOOR

First of all there is no such thing as a stupid question. Secondly, yes, you are correct. R1 and R3 must have some sort of routing (either static or dynamic) to be able to find each other’s networks.

I hope this has been helpful!

Laz

19 posts were merged into an existing topic: ICMP (Internet Control Message Protocol)

Hi Laz,

Thank you for your explanation. It really helped me to understand how encapsulation happens. But I have a slightly different question. Can we start a communication from Layer-2? Just as we created ICMP packet from Layer-3 is there any way we can create a Frame from Layer-2 directly?

Thank you.

Hi Rene,

Thank you for your amazing tutorials. I have few doubts and I am sorry if I have missed it in your explanation. You have mentioned that Cisco router will try multiple probes and we are restricting to one by mentioning probe =1.

  1. Does probe means the number of attempts?
    I did a “tracert 8.8.8.8” on cmd and it showed a list of hops to google’s dns server.

  2. Why R3 replies port 33435 as unreachable? Why is the port number increased on each attempt of traceroute? Same port number can exist on all hosts.

Hello Rosna

There are protocols that “live” at Layer 2 and do not go any higher on the OSI model. STP uses BPDUs which are layer 2 frames that are exchanged for the functionality of spanning tree protocol. ARP is an exclusively layer 2 protocol. Cisco Discovery Protocol (CDP) is also a layer 2 protocol. PPP and L2TP are also layer 2 protocols that exchange frames at layer 2 to function. All of these initiate communication at layer 2 and do not go higher on the OSI model.

I hope this has been helpful!

Laz

Hello again Rosna

In traceroute, a probe is the number of ICMP echo requests sent to each individual hop. So if a traceroute has 7 hops to the destination, the Cisco device will send three probes, or three ICMP echo requests to each of the 7 hops for a total of 21 ICMP echo requests. If you select one probe, a single ICMP request will be sent to each hop. You won’t actually see a difference in the traceroute output.

By default, Cisco begins its traceroute on port 33434. Each hop that it traverses, it increments the destination port by one. This is how the traceroute command has been designed. You can adjust the default starting destination port by using the extended traceroute commands.

You can find out more information about the traceroute command on Cisco devices at this Cisco documentation

I hope this has been helpful!

Laz

Thank you, Laz. I understood now.

Hi Liz, One last question on working of Traceroute. How the initial host (which generates icmp/ udp packets) knows that it has found the target? I mean what is special in a “Port Unreachable” message which makes it think that the packet has reached the destination. ( i. the corresponding port is not active on the destination ii. The packet is intended for it. Hence it sends port unreachable message, do I make sense???)

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.

Unknown