Internet Control Message Protocol (ICMP)


ICMP is one of the most important management protocols and one of the most used in today's TCP/IP networks for troubleshooting problems. ICMP is TCP/IP's delivery service for error messages in the form of IP datagrams. ICMP is even simpler than UDP, because it doesn't contain any port numbers in its header. Port numbers are not needed when directing an ICMP message.

There are many times when a router or switch may need to deliver a message to a sending device in order to deliver bad news. ICMP is used to deliver such messages in the following situations:

  • If a datagram reaches the maximum number of hops assigned to it before reaching its destination, it will be deleted by the router on its last hop. This router then uses ICMP to send a time-exceeded message informing the sender of the deleted datagram.

    graphics/note_icon.gif

    An in-depth discussion of how ICMP works is found in Chapter 5, "Windows Troubleshooting," under the "Ping Command" section.


  • When a router receives a datagram with a destination network that is unknown to it ”meaning that it is not listed in its routing table ”the router will send a message to the sender via ICMP stating "Destination unreachable." In this situation, a default gateway is not configured, as we discussed in the last section.

  • A router's memory buffer can hold only a certain amount of data, and when this limit is reached, the router uses ICMP to send a source quench message.

Routers advertise addresses of their interfaces periodically with router advertisements. An ICMP router discovery message is independent of a specific routing protocol. Routers become aware of their neighboring routers simply by listening to these advertisements. A router that just started up may also send a router solicitation, which forces immediate router advertisements. Routers that are not being advertised because a link is down will eventually be discovered when the link comes back up, because routers also send unsolicited periodic advertisements.

ping and trace Commands

The ping and trace commands are tools that use the ICMP protocol to test for node connectivity. These two tools work together. When you suspect there is a problem with a connection, you can ping the IP address of the device to see if that device exists. If you are resolving NetBIOS names or Fully Qualified Domain Names (FQDN), either through a static entry or a configured DNS server, there is a good chance that you can ping the host name or FQDN name in the place of the IP address.

Let's look at the results of trying a ping using an IP address, host name, and an FQDN. We'll also look at an example of a failed ping. This first example is the results of the ping command using an IP address.

 RTR>  enable  Password: ****** RTR#  ping 10.1.2.7  Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.2.7, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms RTR# 

The exclamation marks in the preceding example indicate a successful ping. Here's an example of using the Ping command with a FQDN:

 RTR#  ping data6.digitalcrawlspaces.com  Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.2.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms RTR# 

The above shows an example of pinging the FQDN address of data6.digitalcrawlspaces.com, which is a real Web server on the Internet. Next, take a look at an example of a ping using a statically entered host name. In this example, I first configure the host name of DataServer1 in Global Configuration mode before I ping the node.

 RTR(config)#  ip host dataserver1 10.1.2.1 ?  A.B.C.D  Host IP address   <cr> RTR(config)#  ip host jtscom1 10.1.2.1  RTR(config)#  exit  RTR#  ping dataserver1  Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.2.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms RTR# 

The above shows the hostname of Dataserver1 configured on the router and the process of pinging the address by the host name configured on the router. The ping to Dataserver1 was successful, as shown by the exclamation marks. For the exam you may need to know what a failed ping looks like. Let's take a look at the following output:

 RTR#  ping dataserver1  Translating "dataserver1"...domain server (10.1.2.25) (206.13.31.12) % Unrecognized host or address, or protocol not running. RTR# 

In the output above we see that the router has no listing in its host table and tries contacting the DNS servers configured for a resolution that never came. What happens is resolvable through DNS servers or is listed in the router's host table. Let's look at the output below:

 RTR#  ping dataserver1  Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.2.2.200, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) RTR# 

In the output above we see the failure indicated by periods, which indicates 5 attempts to send ICMP packets that failed to return. Successfully pinging a device does not indicate that there is not a problem with the network. The path that a packet takes to its destination may not be the most optimal path. Many times there are more than one path or link to a destination. One may be a high speed link, the other a slower path. Frequently, there are ISDN lines or other more expensive slower links to a destination used as a backup in case the high speed path is not functioning. You may also want to see where a failure occurs in the transit of a packet. The trace command allows you to see each hop to a destination device. This allows you to see the path the ICMP packets take and the latency of the packet in milliseconds . If there is a link down in the path to the destination, the output will stop with the last device that successfully replied with an ICMP reply. Let's take a look at the output from the router.

 RTR#  trace 10.2.2.1  Type escape sequence to abort. Tracing the route to 10.2.2.1   1 10.1.1.1 4 msec 4 msec 4 msec   2 10.2.1.1 4 msec 4 msec 8 msec   3 10.2.2.1 4 msec 4 msec 4 msec RTR# 

The above output was a successful trace to the target IP address. Here is a result of a trace that was able to go one hop to the default gateway but unable to complete the trace after that. The astrisks indicate a failure uncovered by the trace command.

 RTR#  trace 10.4.1.1  Type escape sequence to abort. Tracing the route to 172.16.50.2   1 10.1.1.1 4 msec 4 msec 4 msec   2 * * *   3 * * *   ^C RTR# 

Notice in the above output that the trace command stopped after the first hop and displayed only asterisks . This is because the trace failed and no reply was sent from the second hop device. For the exam you should know the following characters which may appear in the trace command output:

  • msec ” The round trip time in milliseconds.

  • * ” A timed out request.

  • ? ” An Unknown packet type.

  • Q ” A source quench message was received.

  • P ” The protocol is unreachable.

  • N ” The network is not reachable .

  • U ” The port is not reachable.

  • H ” A designated host is not reachable.



CCNP CIT Exam Cram 2 (642-831)
CCNP CIT Exam Cram 2 (Exam Cram 642-831)
ISBN: 0789730219
EAN: 2147483647
Year: 2003
Pages: 213
Authors: Sean Odom

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net