ICMP is used by a device, often a router, to report and acquire a wide range of communications-related information. Consider these reasons why a device would have to report or acquire information:
- A router can not find a host computer on a destination network or when a frame has circulated in a routing loop until its Time To Live counter has been decremented to zero then the router discards the message.
- A user sends a message to connect to a non-existent program in a host computer (Telnet to a file-server that doesn’t support Telnet, for example) then the host discards the message.
- A host tries to contact a remote destination but it happens to use the wrong router to get to that remote destination; the router that was contacted must inform the host of the correct path.
In each of these cases, the ICMP protocol has a specific message type that is used to report the error condition back to the originator. ICMP is completely defined in RFC 792 but here is a brief overview of the message types. Those that are discussed in separate topics in this section are linked:
- Echo and Echo Reply: Used to implement the PING command. When an ICMP Echo is received it is responded to with an Echo Reply message.
- Destination Unreachable: There are several reasons why an IP destination may be unreachable and the ICMP message reports the reason. This often indicates a configuration or other communications problem. When the destination is unreachable as a result of the setting of the IP Type Of Servicebyte, the expected behavior is discussed in RFC 1349.
- Source Quench: When a router is being overloaded by a high-powered host, the router can send a Source Quench message and cause the host to stop transmissions for a short period of time during which the router can catch up. You’ll very rarely see this one on a network.
- Redirect: A router can tell a host to use a different target address when sending frames to some remote location. This is a normal action to see one time at the beginning of a new conversation.
- Time Exceeded: A router has received a frame that has had its Time To Live field decremented to one. The router now decrements the field to zero and discards the frame. The Time Exceeded message is used to inform the originator of the frame that the discard action took place.
- Parameter Problem: There was an error (probably a communications software bug!) in the construction of an IP datagram. If you ever see this on your network – call your vendor (or.. call Savvius for consulting help!)
- Timestamp: ICMP can be used by a diagnostic program to time the round-trip delay in a conversation path. You’ll very rarely see this one on a network.
- Address Mask Request and Reply: ICMP can be used by a program to read the Address Mask (the subnet mask) value from another machine. You’ll very rarely see this one on a network.
Additional Topics in this Section:
- RFC 792: This RFC discusses the ICMP protocol including the messages and queries that ICMP can use, the frame header structure for each, and the anticipated behavior.
- RFC 1349: This RFC discusses how ICMP will behave in response to various IP TYPE OF SERVICE configurations.
ICMP: Destination Unreachable
The Destination Unreachable message indicates that a frame was discarded because it could not reach its ultimate destination. This could be the result of a router in the communications path that discarded the frame or, perhaps, the ultimate destination host computer did not have the resources to process the frame. Also, it may have been the case that the program that was being contacted was not available. This would be the case if a user tried to Telnet to a file server that didn’t support Telnet, or tried to mount an NFS file volume on a host that didn’t support NFS. This is the Destination Unreachable message. When a Destination Unreachable message is sent, it indicates that the sender could not reach the specified destination. This provides a wonderful troubleshooting opportunity. The point of failure identifies itself by sending the ICMP Destination Unreachable message.
There are six different reasons why a Destination Unreachable message may be sent. Three of them are common and very significant, three are much less common and not as significant. The reasons are:
- Network Unreachable
- Host Unreachable
- Port Unreachable
- Protocol Unreachable
- Fragmentation Needed and ‘Don’t Fragment’ bit set
- Source Route failed
Let’s talk about the three significant ones first. These are:
- Network Unreachable – Sent by any router.
- Host Unreachable – Sent by the last router in the path to an existing network.
- Port Unreachable – Sent by the destination host on destination network.
When a router sends a Network Unreachable message, it is saying that it has no way to reach the network/subnetwork as specified in the destination IP address in a frame. The destination is the locator portion of the address as calculated by using the address mask parameter configured in the router. Consequently the Network Unreachable message could be the result of a misconfigured mask value in the router. It could be as silly as a user specifying a non-existent network in the command line for an application. If you try to Telnet to 18.104.22.168 when there is no network 22.214.171.124 then you will end up with a Network Unreachable message from the router that finally figures it out. Remember that the frame will be forwarded from Default Gateway to Default Gateway until it figures out that it can’t forward it anywhere else. This last router will send the Destination Unreachable – Network Unreachable message. If a link is down or an interface failed (bad port) the networks that would be reached across the link or through the port are now unreachable (assuming there is no other way to reach them via some alternate path).
Summary: Network Unreachable
- Is the specified destination address a valid network?
- Is the link up from the router sending the Network Unreachable message?
- Is the port in the router configured with the correct address mask value?
When a router sends a Host Unreachable message it is telling you that it believed itself to be the router that was directly connected to the network on which the host was configured. That is, a frame is passed from originator to router, to router, to router, finally ending up at the last router in the path – the one that has the destination network attached to one of its ports. This last router then broadcasts an ARP frame onto the network looking for the data link (DLC) address of the host. The host should answer the ARP and the router can then forward the frame. If, however, the router ARP’s and receives no answer then it sends a Destination Unreachable – Host Unreachable message back to the originator. The significance of this is that a Host Unreachable message implies that the intervening communications infrastructure is working properly. The frame has been forwarded all the way through the interconnected network and has arrived successfully at the last router in the path. This router was able to successfully transmit an ARP command onto the correct network cable. The ARP simply wasn’t answered. The entire communications path, including the final interface and final network segment (or ring) was working properly. The host simply wasn’t there.
A Host Unreachable message could be the result of a user simply typing the wrong IP address. It could be that the host was down or otherwise off-line. It could be that there were a high number of physical errors on the destination network (but this is unlikely since the last router is able to send ARP commands). In any event, the next step in troubleshooting is to move your protocol analyzer to the last network (the one on which the host is located) and see what’s happening there.
Summary: Host Unreachable
- You are assured that the intervening communications infrastructure is working properly.
- Is the specified destination address the correct address for the host?
- Is the host currently on-line and active?
- Are there any physical problems on the destination network.
Unlike the Network Unreachable and Host Unreachable messages which come from routers, the Port Unreachable message comes from a host. The primary implication for troubleshooting is that the frame was successfully routed across the communications infrastructure, the last router ARP’ed for the host, got the response, and sent the frame. Furthermore, the intended destination host was on-line and willing to accept the frame into its communications buffer. The frame was then processed by, say, TCP or, perhaps UDP, RIP, OSPF, or some other protocol. The protocol (TCP or UDP) tried to send the data up to the destination port number (TCP or UDP port) and the port process didn’t exist. The protocol handler then reports Destination Unreachable – Port Unreachable.
One of the most common Port Unreachable errors occurs when an SNMP (Simple Network Management Protocol) console is polling a number of devices on the network. The console has been configured with a list of IP addresses to poll for the acquisition of network management data. The assumption is that each of those managed devices has been configured with an SNMP agent program assigned to a particular port number. One standard SNMP port number is 161. If you see a Port 161 Unreachable then you could reasonably assume that a console was polling a device which didn’t have an SNMP agent configured into it.
If you try to setup a NetBIOS connection (port 513) with a server that doesn’t support NetBIOS (hence, no 513 processing entity) you get a Port Unreachable. Mounting a file volume to a server that doesn’t support NFS results in the same.
When troubleshooting a Port Unreachable error it is necessary to know what is supposed to be at the indicated (unreachable) port. This may be as simple as looking up RFC 1700 (the well known number list) or as complicated as interacting with a vendors development team to figure out the operation of some proprietary application program that is using special port numbers.
One odd error that might be associated with a Port Unreachable message is seen when an otherwise normally operating conversation is interrupted by a Port Unreachable message. When you inspect the conversation you observe that the unreachable port was working without a problem. Frames were going to and from the port number when, suddenly – Port Unreachable. This is indicative of an overload condition or process priority configuration problem in the reporting host. The process in question was swapped out of memory and was not able to swap back in quickly enough to avoid the unreachable indication.
The nice thing about a Port Unreachable message is that it confirms proper operation of the intervening communications infrastructure and the presence of the destination host processor.
Summary: Port Unreachable
- The host and the communications infrastructure are working properly.
- The ICMP Port Unreachable message originates from a host, not a router.
- The indicated port process was either not running or was swapped out. SNMP (Port 161) is a common port to be missing.
- Find out what the port is used for and why it wasn’t available.
The Other ICMP Destination Unreachable Causes
These messages are rare so seeing one of them is cause for concern. Other than the three most common (and most significant) ICMP Destination Unreachable messages there are:
- Protocol Unreachable
- Fragmentation Needed and “Don’t Fragment” bit set
- Source Route failed
A Protocol Unreachable message is the same as a Port Unreachable message except this time the Layer 3 processing entity was unable to locate the specified protocol. For example, an OSPF (Open Shortest Path First) frame was sent to a RIP (Routing Information Protocol) based router. Since the router doesn’t have any Layer 4 OSPF processor, the entire protocol is unreachable. It is necessary to examine the frames to see what protocol was being used in the frame sent to the reporting device. That device, for good or bad, simply didn’t support that protocol.
Remember, a Port Unreachable message says that the process that is using a Port in the Layer 4 protocol is missing, but the protocol itself is working. A Protocol Unreachable message says that a Layer 4 protocol is missing in its entirety.
If a router says that Fragmentation is Needed and the Don’t Fragment bit is set it means that the originating station has set the Don’t Fragment bit in the IP Flag field for some reason known only to the software in that originating station. As the frame moved through the communications infrastructure, it arrived at a router that needed to fragment the frame (probably because the frame was moving from an architecture with a large maximum frame size to an architecture with a smaller maximum frame size) but, because the bit was set to say “No”, fragmentation was not allowed. The frame was discarded and the ICMP message was returned to the originator.
Redirecting Future Transmissions to an Alternate Router
ICMP (Internet Control Message Protocol) has a variety of commands and replies that are used to inform devices of routing related information. One common ICMP command is the ECHO Command and ECHO Reply used by the PING command to determine that a remote station is present. ICMP can request the value of a station’s address mask and it can inform a sender that a destination is unreachable.
At this point in our discussion we are going to focus on the form of the ICMP command called a REDIRECT. An ICMP Redirect Command is used to inform a sender that the IP destination to which a frame was sent is not the right one and to tell the sender where to send frames in the future.
Consider a situation where a number of end-nodes on a single Ethernet segment or single Token-Ring have access to only one router. The Default Gateway parameter in all the stations is set to the IP address of the router. Any frame not destined for the local segment/ ring is simply sent to the only available router which then forwards it on the ultimate destination network.
If this simple network design is expanded so that two routers are attached to the same network as a particular end-node a different situation occurs. Let’s consider a network 126.96.36.199 which is masked as 255.255.0.0. If end-node 188.8.131.52 wants to send a frame to 184.108.40.206 then it broadcasts an ARP frame and sends the frame directly. If 220.127.116.11 wants to send a frame to 18.104.22.168 then it looks in its routing table to see if a route exists. In this example assume that 22.214.171.124 was just turned on and the routing table is empty except for the Default Gateway which we will say is 126.96.36.199, a router on the cable segment. Hence, our end-node will ARP for the data link address of the Default Gateway and forward the frame to that data link destination (to the Default Gateway). Now expand the example to assume that in addition to the Default Gateway there is a second router on the segment. Let’s consider what happens when our end-node wants to send a frame to a remote destination that can only be reached by going through this other router. Let’s call this other router 188.8.131.52.
The end-node now wants to send a frame to remote destination 184.108.40.206 which can only be reached through router 220.127.116.11, the other (non-Default Gateway) router on the segment. The end-node follows the exact logic as before; the frame is sent to the Default Gateway (18.104.22.168). This time, however, the Default Gateway realizes that the other router (22.214.171.124) is the correct router for forwarding of the frame. Two actions occur: 1) The Default Gateway sends an ICMP Redirect message back to the originating end-node telling it to redirect to 126.96.36.199 and 2) the Default Gateway politely forwards the original frame over to 188.8.131.52 precluding the need to have it retransmitted by the end-node.
Let’s summarize this behavior: When the Default Gateway receives a frame that should actually be routed to an IP address other than the Default Gateway then the Default Gateway informs the originator using an ICMP Redirect message. The Redirect, in this case, would tell 184.108.40.206 that when sending frames to network 220.127.116.11 that they should be sent to router 18.104.22.168. The end-node will have to ARP in the normal manner to determine the data link address of 22.214.171.124 but, from then on, frames for 126.96.36.199 will be sent to the other router and not to the Default Gateway.
From the perspective of the ARP Cache and the Routing Table, the effect of an ICMP Redirect is as follows. Initially the routing table only contains the association for the Default Gateway. Assume that 188.8.131.52 is the address of the Default Gateway for a workstation. The Routing Table would say that 0.0.0.0 = 184.108.40.206 (where 0.0.0.0 is the indicator that means ‘the default gateway’). The ARP Cache would initially be empty.
When the station boots up, it ARP’s for the data link address of the Default Gateway. The ARP reply returns this data link address which we will call MAC#1 (using the ‘.1’ from the IP address to associate the two in this text). The MAC (or ‘data link’) address is the physical, hardware address of the network interface card.
When this station receives a redirect for 220.127.116.11 to router 18.104.22.168 it causes the Routing Table to be updated to reflect the following:
0.0.0.0 = 22.214.171.124
126.96.36.199 = 188.8.131.52
The next time a frame is destined to network 184.108.40.206 the Routing Table returns 220.127.116.11 as the correct ‘next hop’ to the destination. But, the workstation can not yet send frames to that ‘next hop’ until it resolves the data link address for 18.104.22.168. It will ARP now for 22.214.171.124 and the ARP Cache will contain:
126.96.36.199 = MAC#1
188.8.131.52 = MAC#201
This behavior continues as the station interacts in the network. While unused entries in the ARP Cache may age-out after a few seconds, the Routing Table may age-out after 20 minutes or so if the route remains unused.
Multiple Subnets On The Same Segment or Ring
As you read the following section, you MUST be aware that in 1995 a new set of RFC’s were established to define the issue of multiple subnets on the same segment or ring. Essentially, they define a set of device behaviors that are considered, today, to be more appropriate that the ones described in this section. So, we can think through the issues described in this first section, titled “The Way It Was”, and then read on to the new RFC descriptions in the section titled “The Way It Is Today”.
In an ideal world a single port on a router is configured and connected to a cable on which stations are all configured with the same address mask. This implies that they are all on the same network and sub network (since the masked bits which define the ‘locator’ portion of the address would be configured to be identical on all stations). This would make life easy for the router. One port would equal one IP net work/ sub network and all stations would be so configured.
It is not, however, an ideal world. It is possible (probable?) that the stations on a segment are configured with different net work/ sub network locators. A segment, in this context, refers to not only a single Ethernet segment or Token-Ring but to a group of physical segments or rings interconnected with repeaters, bridges, or switches. In a very loose sense one could conceive of a network which was configured at random or one that resembled a random configuration. Alternatively, consider a situation where a router has 12 ports, each port configured as a separate IP subnet. This router is replaced with a switch. When a station on the Port #1 segment wants to talk to a station on a Port #5 segment it perceives the destination address as being remote (since the IP addressing and masking were not changed from when the segments were attached to the router). The sender addresses the frame to the data link address of the new Default Gateway (which is, for sake of discussion, attached to the segment on Port #2). The Default Gateway uses a Redirect to inform the originator that the destination is directly reachable. Consider the result of the update to the routing table when 184.108.40.206 now wants to contact 220.127.116.11.
0.0.0.0 = 18.104.22.168
22.214.171.124 = 126.96.36.199
Does this appear strange? The Redirect message said that frames being sent to 188.8.131.52 should be ‘redirected’ to 184.108.40.206; the same IP destination address. Let’s see how this will make the workstation behave when the next frame is to be sent to 220.127.116.11.
18.104.22.168 still thinks the destination is remote. The routing table is consulted to see if 22.214.171.124 (the host-specific route) or 126.96.36.199 (the network route) is in present. This time the destination is found (and is perceived as a host-specific route). 188.8.131.52 understands from the routing table that frames addressed to 184.108.40.206 should be sent to IP destination 220.127.116.11 and so an ARP frame is used to resolve the address 18.104.22.168. Since 22.214.171.124 is actually directly reachable (through the switch) it responds to the ARP and the MAC#123 address (the data link address of 126.96.36.199) is added to the ARP Cache. The frame is now forwarded directly to the destination machine.
If the sending machine were conscious and self-aware it would think that it was forwarding the frame to the data link address of a router. In fact, the Redirect has ‘tricked’ the process into sending to a directly reachable data link destination which is actually that of a destination configured on a different subnet (but physically in the same real location. Multiple subnets are configured on the same logical segment and the ICMP Redirect is used to ‘trick’ the senders into using the true data link destination.
The previous section, “The Way It Was” describes a subnet scenario that violates RFC 1122 and RFC 1812.
RFC 1812 section 188.8.131.52 says:
A Redirect message SHOULD be silently discarded if the new gateway address it specifies is not on the same connected (sub-) net through which the Redirect arrived [INTRO:2, Appendix A], or if the source of the Redirect is not the current first-hop gateway for the specified destination (see Section 3.3.1)
This means that hosts should ignore the redirects described in the “The Way It Was” section.
RFC 1812 section 184.108.40.206 says:
Routers MUST NOT generate a Redirect Message unless all the following conditions are met:
- The packet is being forwarded out the same physical interface from which is was received.
- The IP source address in the packet is on the same Logical IP (sub)network as the next-hop IP address, and
- The packet does not contain an IP source route option.
The source address used in the ICMP Redirect MUST belong to the same logical (sub)net as the destination address. This means that routers must not generate the redirect messages described in the “The Way It Was” section.
Low-End IP Stacks That Don’t Support Redirects
Not every IP implementation (particularly on some lower-performance devices) support the full range of ICMP functionality. While it can be assumed that all IP communicators support ICMP Echo and Echo Reply (for the Ping command) they don’t all support the Redirect functionality. In this case a redirect to an alternative router or directly to a local destination configured on a different subnet would not be redirected. The originating station would continue to send the frames to the router. The router would continue to send Redirects and then forward the frames to the destination. The conversation would work but would require the additional traffic associated not only with the Redirect frames but with the double copy of the original frame (once from originator to router and the second time from the router to the destination). The traffic load on the network would go up unnecessarily and the performance would degrade due to loading and due to the additional propagation delay through the router for each frame.
To compensate for this deficit in some IP stacks router vendors may offer configuration parameters that allow the number of Redirects sent to a station with no effect to be limited. A Cisco router, for example, allows a maximum of 15 redirect frames to a station before it stops sending redirects to that station. The router will still forward the incoming frames to the correct destination but at least the unnecessary, ignored ICMP frames are eliminated. This intelligent option in a router doesn’t fix the problem (because the workstation doesn’t support redirects) but at least it helps prevent the bad situation from becoming even worse (because the unheeded ICMP Redirect frames are shut off).
The real ‘fix’ (ok… the real fix is to get an IP stack that supports redirects; but..) is to turn on Proxy ARP at the workstation and the router. By default, most routers have Proxy ARP active. Some workstations may not support Proxy ARP. With Proxy ARP working the whole ICMP issue is circumvented. All stations ARP for all destinations.
Problems With Address Masking
When a station is configured with an incorrect address mask the effect is to confuse it as to whether a destination is remote or local. Because this incorrectly configured station doesn’t perform the correct masking of a destination address the whereabouts of the destination is judged incorrectly. If a remote destination is perceived to be local then the sender ARP’s and the ARP fails. If a local destination is perceived to be remote then the sender forwards to the Default Gateway with the associated Redirect and (hopefully) adjustment of the routing table. These inappropriate behaviors can be observed with a protocol analyzer.
When Proxy ARP is active in the router there is the effect that the misconfigured address mask values in the workstations are concealed. The station that thinks a remote destination is actually local will ARP incorrectly for the remote destination. The router will simply answer the ARP (the ‘proxy’ response).
The concern with Proxy ARP is that is can conceal a number of misconfigured address masks on the network. Now, this is fine as long as you are willing to accept the network as a misconfigured mess being held together by the Proxy feature in the router. When the day comes to reconfigure the network (tomorrow?) you have a world of problems waiting for you. The inconsistent masking that was being concealed by the Proxy feature in the router comes back to haunt you at the worst possible times (…ten minutes to five on Friday afternoon as you are getting ready to leave for a three-day weekend!).
As an experiment, try turning Proxy ARP off in your routers. Don’t do this if 1) your design calls for no-default-gateway / Proxy-ARP-ON in the workstations or 2) you are running an important application on the network. Be careful. Turning Proxy ARP off may cause catastrophic problems. That’s the idea. If your network design doesn’t call for Proxy ARP to be on then the network should work properly when you turn it off. Try it experimentally to see if you get problems. If you do then you can solve them in a controlled manner rather than waiting for the worst possible time for these ugly monsters to rear their heads.