ICMP - Echo / Echo Reply (Ping) and request

Introduction As mentioned in the previous page, an Echo is simply what most people call a 'ping'. The Echo Reply is the 'ping reply'. ICMP Echos are used mostly for troubleshooting. When there are 2 hosts which have communication problems, a few simple ICMP Echo requests will show if the 2 hosts have their TCP/IP stacks configured correctly and if there are any problems with the routes packets are taking in order to get to the other side. The 'ping' command is very well known, but the results of it are very often misunderstood and for that reason I have chosen to explain all those other parameters next to the ping reply, but we will have a look at that later on. Let's have a look at what an ICMP-Echo or Echo Reply packet looks like: If the above packet was an ICMP Echo (ping), then the Type field takes a value of 8. If it's an ICMP Echo Reply (ping reply) then it would take a value of 1. The picture below is a screen shot I took when doing a simple ping from my workstation: Okay, now looking at the screen shot above, you can see I 'pinged' www.firewall.cx. The first thing my workstation did was to resolve that URL to an IP address. This was done using DNS. Once the DNS server returned the IP address of www.firewall.cx, the workstation generated an ICMP packet with the Type field set to 8. Here is the proof: The picture above is a screenshot from my packet sniffer the same time this experement was taking place. The packet displayed is one of the 4 packets which were sent from my workstation to the webserver of firewall.cx Notice the ICMP type=8 Echo field right under the ICMP Header section. This clearly shows that this packet is being sent from the workstation and not received. If it was received, it would have been an 'Echo Reply' and have a value of 1. The next weird thing, if anyone noticed, is the data field. Look at the screen shot from command prompt above and notice the value there and the value the packet sniffer is showing on the left. One says 32 Bytes, and the other 40 Bytes ! The reason for this is that the packet sniffer is taking into account the ICMP header files (ICMP type, code, checksum and identifier), and I'll prove it to you right now. Look at the top of this page where we analysed the ICMP headers , you will notice that the lengths (in Bits) of the various fields are as follows: 8, 8, 16, 16, 16. These add up to a total of 64 Bits. Now 8 Bits = 1 Byte, therefore 64 Bits = 8 Bytes. Take the 32 Bytes of data the workstation's command prompt is showing and add 8 Bytes .... and you have 40 Bytes in total. To view the full screen image shot of the packet sniffer, please click here. And that just about does it for these two ICMP messages !  ICMP - Destination Unreachable Message Analysis Introduction The 'ICMP Destination unreachable' message is quite interesting, because it doesn't actually contain one message, but infact six! This means that the ICMP Destination unreachable futher breaks down into 6 different messages. This article will analyse all six destination unreachable messages and explain which occasions each message is used. The table below shows an brief summary of the available messages and their code value contain in the ICMP header: To make sure you don't get confused, keep one thing in mind: The ICMP Destination unreachable is a generic ICMP message, the different code values or messages which are part of it are there to clarify the type of "Destination unreachable" message was received. It goes something like this: ICMP Destination unreachable. The ICMP - Destination net unreachable message is one which a user would usually get from the gateway when it doesn't know how to get to a particular network. The ICMP - Destination host unreachable message is one which a user would usually get from the remote gateway when the destination host is unreachable. If, in the destination host, the IP module cannot deliver the packet because the indicated protocol module or process port is not active, the destination host may send an ICMP destination protocol / port unreachable message to the source host. In another case, when a packet received must be fragmented to be forwarded by a gateway but the "Don't Fragment" flag (DF) is on, the gateway must discard the packet and send an ICMP destination fragmentation needed and DF set unreachable message to the source host. These ICMP messages are most useful when trying to troubleshoot a network. You can check to see if all routers and gateways are configured properly and have their routing tables updated and synchronised. Let's look at the packet structure of an ICMP destination unreachable packet: Please read on as the following example will help you understand all the above. The Analysis When you open a DOS command prompt and type "ping 200.200.200.200", assuming that your workstation is NOT part of that network, then it would forward the ICMP Echo request to the gateway that's configured in your TCP/IP properties. At that point, the gateway should be able to figure out where to forward the ICMP Echo request. The gateway usually has a "default route" entry, this entry is used when the gateway doesn't know where the network is. Now, if the gateway has no "default route" you would get an "ICMP Destination net unreachable" message when you try to get to a network which the gateway doesn't know about. When you're connected to the Internet via a modem, then your default gateway is the modem. In order for me to demonstrate this, I set up my network in a way that should make it easy for you to see how everything works. I have provided a lot of pictures hoping to make it as easy as possible to understand. I will analyse why and how you get an "ICMP - Destination net unreachable" message. In the example above, I've setup my workstation to use the Linux server as a default gateway, which has an IP of 192.168.0.5. The Linux server also has a default gateway entry and this is IP: 192.168.0.1 (the Windows 2000 Server). When my workstation attempts to ping (send an ICMP Echo request) to IP 200.200.200.200, it realises it's on a different network, so it sends it to the Linux server, which in turn forwards it to its default gateway (the Win2k server) so it can then be forwarded to the Internet and eventually I should get a ping reply (ICMP Echo reply) if the host exists and has no firewall blocking ICMP echo requests. Here is the packet which I captured and its analysis on the right: When looking at the decoded packet you can see in the ICMP header section that the ICMP Type is equal to 8, so this confirms that it's an ICMP Echo (ping). As mentioned earlier, we would expect to receive an ICMP echo reply. Check out though what happens when the default gateway entry is removed from the Linux server: Now what I did was to remove the default gateway entry from the Linux server. So when it gets a packet from my workstation, it wouldn't know what to do with it. This is how you get the gateway to generate an "ICMP Destination net unreachable" message and send it back to the source host (my workstation). Here is a screen shot from the command prompt: As you can see, the Linux server has returned an "ICMP Destination net unreachable". This is one of the six possible 'ICMP Destination Unreachable' messages as listed at the beginning of this page. The Linux server doesn't know what to do with the packet since it has no way of getting to that 200.200.200.0 network, so it sends the "ICMP Destination net unreachable" message to my workstation, notifiying it that it doesnt know how to get to that network. Let's now take a look what the packet sniffer caught :   The decoded packet on the right shows that the Linux server (192.168.0.5) sent back to my workstation (192.168.0.100) an ICMP Destination unreachable message (look at the ICMP type field, right under the ICMP header) but if you also check out the ICMP Code (highlighted field), it's equal to 0, which means "net unreachable". Scrolling right at the top of this page, the first table clearly shows that when the code field has a value of 0, this is indeed a "net unreachable" message. It is also worth noticing the "Returned IP header" which exists within the ICMP header. This is the IP header of the packet my workstation sent to the Linux server when it attempted to ping 200.200.200.200, and following that is 64 bits (8 bytes) of the original data. This completed our discussion on the ICMP 'Destination Unreachable' generated packets. ICMP - Source Quench Message Analysis Introduction The ICMP - Source quench message is one that can be generated by either a gateway or host. You won't see any such message pop up on your workstation screen unless you're working on a gateway which will output to the screen all ICMP messages it gets. In short, an ICMP - Source quench is generated by a gateway or the destination host and tells the sending end to ease up because it cannot keep up with the speed at which it's receiving the data. Analysis Now let's get a bit more technical: A gateway may discard internet datagrams (or packets) if it does not have the buffer space needed to queue the datagrams for output to the next network on the route to the destination network. If a gateway discards a datagram, it may send an ICMP - Source quench message to the internet source host of the datagram. Let's have a look at the packet structure of the ICMP - Source quench message: A destination host may also send an ICMP - Source quench message if datagrams arrive too fast to be processed. The ICMP - Source quench message is a request to the host to cut back the rate at which it is sending traffic to the internet destination. The gateway may send an ICMP - Source quench for every message that it discards. On receipt of an ICMP - Source quench message, the source host should cut back the rate at which it is sending traffic to the specified destination until it no longer receives ICMP - Source quench messages from the gateway. The source host can then gradually increase the rate at which it sends traffic to the destination until it again receives ICMP - Source quench messages. The gateway or host may also send the ICMP - Source quench message when it approaches its capacity limit rather than waiting until the capacity is exceeded. This means that the data datagram which triggered the ICMP - Source quench message may be delivered. That pretty much does it for this ICMP message. ICMP - Redirect Message Analysis Introduction The ICMP - Redirect message is always sent from a gateway to the host and the example below will illustrate when this is used. Putting it simply (before we have a look at the example) the ICMP - Redirect message occurs when a host sends a datagram (or packet) to its gateway (destination of this datagram is a different network), which in turn forwards the same datagram to the next gateway (next hop) and this second gateway is on the same network as the host. The second gateway will generate this ICMP message and send it to the host from which the datagram originated. There are 4 different ICMP - Redirect message types and these are: The format of this ICMP message is as follows: ICMP - Redirect (0, 1, 2, 3 or 4) message. Our example: The gateway (Win2k Server) sends a redirect message (arrow No. 3) to the host in the following situation: Gateway 1 (the linux server), receives an Internet datagram (arrow No. 1) from a host on the same network. The gateway checks its routing table and obtains the address of the next gateway (hop) on the route to the datagram's Internet destination network and sends the datagram to it (arrow No. 2). Now, gateway 2 receives the datagram and, if the host identified by the Internet source address of the datagram (in other words, it checks the source IP of the datagram, which will still be 192.168.0.100), is on the same network, a redirect message (arrow No. 3) is sent to the host. The redirect message advises the host to send its traffic for the Internet network directly to gateway 2 as this is a shorter path to the destination. The gateway then forwards the original datagram's data (arrow No. 1) to its Internet destination (arrow No.4). For datagrams (or packets) with the IP source options and the gateway address in the destination address field, a redirect message is not sent even if there is a better route to the ultimate destination than the next address in the source route. Analysis Let's have a look at the structure of an ICMP - Redirect message: That's all about ICMP - Redirect messages ! ICMP - Time Exceeded Message Analysis Introduction The ICMP - Time exceeded message is one which is usually created by gateways or routers. In order to fully understand this ICMP message, you must be familiar with the IP header within a packet. If you like you can go to the Download - Documents section and grab a copy of the TCP/IP in a Ethernet II Frame file which breaks down the IP header nicely. When looking at an IP header, you will see the TTL and Fragment Flag fields which play a big part in how this ICMP message works. Please make sure you check them out before attempting to continue ! The ICMP - Time exceeded message is generated when the gateway processing the datagram (or packet, depending on how you look at it) finds the Time To Live field (this field is in the IP header of all packets) is equal to zero and therefore must be discarded. The same gateway may also notify the source host via the time exceeded message. The term 'fragment' means to 'cut to pieces'. When the data is too large to fit into one packet, it is cut into smaller pieces and sent to the destination. On the other end, the destination host will receive the fragmented pieces and put them back together to create the original large data packet which was fragmented at the source. Analysis Let's have a look at the structure of an ICMP - Time exceeded message: If a host reassembling a fragmented datagram (or packet) cannot complete the reassembly due to missing fragments within its time limit it discards the datagram and it may send an ICMP - time exceeded message. If fragment zero is not available then no ICMP - time exceeded message is needed to be sent at all. Code 0 may be received from a gateway and Code 1 from a host. So, summing it up, an ICMP - Time exceeded message can be generated because the Time to live field in the IP header has reached a value of zero (0) or because a host reassembling a fragmented datagram cannot complete the reassembly within its time limit because there are missing fragments (Fragment reassembly time exceeded the allocated time).