TCP/IP Suite Error and Control Messages

Chapter 08 (TCP/IP Suite Error and Control Messages)

Overview
IP is limited because it is a best effort delivery system. It has no mechanism to ensure that data is delivered over a network. Data may fail to reach its destination for a variety of reasons such as hardware failure, improper configuration, or incorrect routing information. To help identify these failures, IP uses the Internet Control Message Protocol (ICMP) to notify the sender of the data that there was an error in the delivery process. This module describes the various types of ICMP error messages and some of the ways they are used.
Because IP does not have a built-in mechanism for sending error and control messages, it uses ICMP to send and receive error and control messages to hosts on a network. This module focuses on control messages, which are messages that provide information or configuration parameters to hosts. Knowledge of ICMP control messages is an essential part of network troubleshooting and is important to fully understand IP networks.


This module covers some of the objectives for the CCNA 640-801, INTRO 640-821, and ICND 640-811 exams. -






Students who complete this module should be able to perform the following tasks:
• Describe ICMP
• Describe ICMP message format
• Identify ICMP error message types
• Identify potential causes of specific ICMP error messages
• Describe ICMP control messages
• Identify a variety of ICMP control messages used in networks
• Determine the causes for ICMP control messages



8.1 Overview of TCP/IP Error Message
8.1.1 ICMP
This page will introduce a protocol that addresses the limitations of IP.


IP is an unreliable method for the delivery of network data. It is known as a best effort delivery mechanism. It has no built-in process to ensure that data is delivered if problems exist with network communication. If an intermediary device such as a router fails, or if a destination device is disconnected from the network, data cannot be delivered. Additionally, nothing in its basic design allows IP to notify the sender that a data transmission has failed. ICMP is the component of the TCP/IP protocol stack that addresses this basic limitation of IP. ICMP does not overcome the unreliability issues in IP. Reliability is provided by upper layer protocols.
The next page will explain how ICMP reports delivery errors.
8.1.2 Error reporting and error correction
This page will explain how ICMP reports errors for IP. When datagram delivery errors occur, ICMP is used to report these errors back to the source of the datagram. Look at the example in Figure . Workstation 1 tries to send a datagram to Workstation 6, but interface Fa0/0 on Router C goes down. Router C uses ICMP to send a message back to Workstation 1. The message indicates that the datagram could not be delivered. ICMP does not correct any network problems that it encounters, it only reports them.


When Router C receives the datagram from Workstation 1, it knows only the source and destination IP addresses of the datagram. It does not know the exact path that the datagram took. Therefore, Router C can only notify Workstation 1 of the failure and no ICMP messages are sent to Router A and Router B. ICMP reports on the status of the delivered packet only to the source device. It does not send information about network changes to other routers.
The next page will explain how ICMP message delivery occurs.
8.1.3 ICMP message delivery
This page will describe the delivery method that is used by ICMP.
ICMP messages are encapsulated into datagrams in the same way any other data is delivered when IP is used. Figure displays the encapsulation of ICMP data within an IP datagram.
Since ICMP messages are transmitted in the same way as any other data, they are subject to the same delivery failures. This creates a scenario where error reports could generate more error reports and cause increased congestion on a network. For this reason, errors created by ICMP messages do not generate their own ICMP messages. Therefore, it is possible to have a datagram delivery error that is never reported back to the sender of the data.


The next page will discuss unreachable networks.
8.1.4 Unreachable networks
This page will explain why some networks are unreachable.
Network communication depends on some basic conditions that must be met. First, the TCP/IP protocol must be properly configured for devices that send and receive data. This includes the installation of the TCP/IP protocol and proper configuration of an IP address and subnet mask. A default gateway must also be configured if datagrams are to travel outside of the local network. Second, intermediary devices must be in place to route the datagram from the source device and its network to the destination network. Routers perform this function. A router also must have the TCP/IP protocol properly configured on its interfaces, and it must use an appropriate routing protocol.


If these conditions are not met, then network communication cannot take place. For instance, the sending device may address the datagram to a non-existent IP address or to a destination device that is disconnected from its network. Routers can also be points of failure if a connecting interface is down or if the router does not have the information necessary to find the destination network. If a destination network is not accessible, it is said to be an unreachable network.
Figures and show a router that receives a packet that cannot be delivered. The packet is undeliverable because there is no known route to the destination. Because of this, the router sends an ICMP host unreachable message to the source.














The next page will teach students how to test network reachability.
8.1.5 Use ping to test destination reachability
This page will explain how the ping command can be used to test the reachability of a network.
The ICMP protocol can be used to test the availability of a particular destination. Figure shows ICMP being used to issue an echo request message to the destination device. If the destination device receives the ICMP echo request, it formulates an echo reply message to send back to the source of the echo request. If the sender receives the echo reply, this confirms that the destination device can be reached using the IP protocol.
The echo request message is typically initiated with the ping command as shown in Figure . In this example, the command is used with the IP address of the destination device. The command can also be entered with the IP address of the destination device as shown in Figure . In these examples, the ping command issues four echo requests and receives four echo replies. This confirms IP connectivity between the two devices.
As seen in Figure , the echo reply includes a time-to-live (TTL) value. TTL is a field in the IP packet header used by IP to provide a limitation on packet forwarding. As each router processes the packet, it decreases the TTL value by one. When a router receives a packet with a TTL value





















of 1, it will decrement the TTL value to 0 and the packet cannot be forwarded. An ICMP message may be generated and sent back to the source machine, and the undeliverable packet is dropped.
The next page will discuss excessively long routes.
8.1.6 Detecting excessively long routes
This page will explain how excessively long routes are created.
Situations can occur in network communication where a datagram travels in a circle, never reaching its destination. This might occur if two routers continually route a datagram back and forth between them, thinking the other should be the next hop to the destination. When there are several routers involved, a routing cycle is created. In a routing cycle, a router sends the datagram to the next hop router and thinks the next hop router will route the datagram to the correct destination. The next hop router then routes the datagram to the next router in the cycle. This can be caused by incorrect routing information.







The limitations of the routing protocol can result in unreachable destinations. The hop limit of RIP is 15, which means that networks that are greater than 15 hops will not be learned through RIP.
In either of these cases, an excessively long route exists. Whether the actual path includes a circular routing path or too many hops, the packet will eventually exceed the maximum hop count.
The next page will discuss ICMP messages.
8.1.7 Echo messages
This page will provide information about ICMP messages.


As with any type of packet, ICMP messages have special formats. Each ICMP message type shown in Figure has its own unique characteristics. All ICMP message formats start with the same three fields:
• Type
• Code
• Checksum
The type field indicates the type of ICMP message being sent. The code field includes further information specific to the message type. The checksum field, as in other types of packets, is used to verify the integrity of the data.


Figure shows the message format for the ICMP echo request and echo reply messages. The relevant type and code numbers are shown for each message type. The identifier and sequence number fields are unique to the echo request and echo reply messages. The identifier and sequence fields are used to match the echo replies to the corresponding echo request. The data field contains additional information that may be a part of the echo reply or echo request message.
The Interactive Media Activity will test the ability of students to place the ICMP message fields in the correct order.
The next page will explain why destination unreachable messages occur.
8.1.8 Destination unreachable message
This page will explain what a destination unreachable message is and why it occurs.


Datagrams cannot always be forwarded to their destinations. Hardware failures, improper protocol configuration, down interfaces, and incorrect routing information are some of the factors that prevent successful delivery. In these cases, ICMP sends the sender a destination unreachable message, which indicates that the datagram could not be forwarded.














Figure shows an ICMP destination unreachable message header. The value of 3 in the type field indicates it is a destination unreachable message. The code value indicates the reason the packet could not be delivered. Figure has a code value of 0, which indicates that the network was unreachable. Figure shows the meaning for each possible code value in a destination unreachable message.





A destination unreachable message may also be sent when packet fragmentation is required to forward a packet. Fragmentation is usually necessary when a datagram is forwarded from a Token Ring network to an Ethernet network. If the datagram does not allow fragmentation, the packet cannot be forwarded, so a destination unreachable message will be sent. Destination unreachable messages may also be generated if IP-related services such as FTP or Web services are unavailable. To effectively troubleshoot an IP network, it is necessary to understand the various causes of ICMP destination unreachable messages.
The next page introduces parameter problem messages.
8.1.9 Miscellaneous error reporting
This page will explain what a parameter problem message is and why it occurs.
Devices that process datagrams may not be able to forward a datagram due to an error in the header parameter. This error does not relate to the state of the destination host or network but still prevents the datagram from being processed and delivered, and because of that, the datagram is discarded. In this case, an ICMP type 12 parameter problem message is sent to the source of the datagram. Figure shows the parameter problem message header.
The parameter problem message includes the pointer field in the header. When the code value is 0, the pointer field indicates the octet of the datagram that produced the error.


This page concludes this lesson. The next lesson will describe TCP/IP suite control messages. The first page will provide an overview of control messages.
8.2 TCP/IP Suite Control Messages
8.2.1 Introduction to control messages
This page will provide an overview of TCP/IP control messages.
ICMP is an important part of the TCP/IP protocol suite. All IP implementations must include ICMP support. The reasons for this are simple. Since IP does not guarantee delivery, it cannot inform hosts when errors occur. Second, IP has no built-in method to provide informational or control messages to hosts.
Unlike error messages, control messages are not the results of lost packets or error conditions that occur during packet transmission. Instead, they are used to inform hosts of conditions such as network congestion or the existence of a better gateway to a remote network. ICMP uses the basic IP header to travel through multiple networks.


Multiple types of control messages are used by ICMP. Some of the most common are shown in Figure . Many of these are discussed in this lesson.
The next page will describe ICMP redirect requests.
8.2.2 ICMP redirect/change requests
This page will introduce the ICMP redirect request, which is a common ICMP control message. This type of message can only be initiated by a gateway, which is a term commonly used to describe a router. All hosts that communicate with multiple IP networks must be configured with a default gateway. This default gateway is the address of a router port connected to the same network as the host. Figure displays a host connected to a router that has access to the Internet. After Host B is configured with the IP address of FastEthernet 0/0 as its default gateway, it uses that IP address to reach any network that is not directly connected. Normally, Host B is connected to a single gateway. However, a host may be connected to a segment that has two or more directly connected routers. In this case, the default gateway of the host may need to use a redirect/change request to inform the host of the best path to a certain network.



Figure shows a network where ICMP redirects would be used. Host B sends a packet to Host C on network 10.0.0.0/8. Since Host B is not directly connected to the same network, it forwards the packet to its default gateway, Router A. Router A finds the correct route to network 10.0.0.0/8 by looking into its route table. It determines that the path to the network is back out the same interface the request to forward the packet came from. It forwards the packet and sends an ICMP redirect/change request to Host B. The request instructs Host B to use Router B as the gateway to forward all future requests to network 10.0.0.0/8.

Default gateways only send ICMP redirect/change request messages if the following conditions are met:
• The interface on which the packet comes into the router is the same interface on which the packet gets routed out.
• The subnet/network of the source IP address is the same subnet/network of the next-hop IP address of the routed packet.
• The datagram is not source-routed.
• The route for the redirect is not another ICMP redirect or a default route.
• The router is configured to send redirects. By default, Cisco routers send ICMP redirects. The interface subcommand no ip redirects will disable ICMP redirects.


The ICMP redirect/change request uses the format shown in Figure . It has an ICMP type code of 5. In addition, it has a code value of 0, 1, 2, or 3.


The Router Internet Address field in the ICMP redirect is the IP address that should be used as the default gateway for a particular network. In the example in Figure , the ICMP redirect sent from Router A to Host B would have a Router Internet Address field value of 172.16.1.200, which is the IP address of E0 on Router B.
The next page will describe clock synchronization.
8.2.3 Clock synchronization and transit time estimation
This page explains how ICMP timestamps are used to solve clock synchronization issues.
The TCP/IP protocol suite allows systems to connect to one another over vast distances through multiple networks. Each network provides clock synchronization in its own way. As a result, hosts on different networks who attempt to communicate with software that requires time synchronization can encounter problems. The ICMP timestamp message type is designed to help alleviate this problem.
The ICMP timestamp request message allows a host to ask for the current time according to the remote host. The remote host uses an ICMP timestamp reply message to respond to the request.


The type field on an ICMP timestamp message can be either 13 for a timestamp request or 14 for a timestamp reply. The code field value is always set to 0 because there are no additional parameters available. The ICMP timestamp request contains an originate timestamp, which is the time on the requesting host just before the timestamp request is sent. The receive timestamp is the time that the destination host receives the ICMP timestamp request. The transmit timestamp is filled in just before the ICMP timestamp reply is returned. Originate, receive, and transmit timestamps are computed in milliseconds elapsed since midnight Universal Time (UT).
All ICMP timestamp reply messages contain the originate, receive, and transmit timestamps. Using these three timestamps, the host can determine transit time across the network by subtracting the originate time from the receive time. Or it could determine transit time in the return direction by subtracting the transmit time from the current time. The host that originated the timestamp request can also estimate the local time on the remote computer.
While ICMP timestamp messages provide a simple way to estimate time on a remote host and total network transmit time, this is not the best way to obtain this information. Instead, more robust protocols such as Network Time Protocol (NTP) at the upper layers of the TCP/IP protocol stack perform clock synchronization in a more reliable manner.
The next page will discuss ICMP information request and reply messages.
8.2.4 Information requests and reply message formats
This page will describe the format of ICMP information request and reply messages.
The ICMP information request and reply messages were originally intended to allow a host to determine its network number. Figure shows the format for an ICMP information request and reply message.


Two type codes are available in this message. Type 15 signifies an information request message and type 16 is an information reply message. This particular ICMP message type is considered obsolete. Other protocols such as BOOTP, Reverse Address Resolution Protocol (RARP), and Dynamic Host Configuration Protocol (DHCP) are now used to allow hosts to obtain their network numbers.
The next page will describe address mask request and reply messages.
8.2.5 Address mask requests
This page will explain address mask request messages and how they are used.
When a network administrator uses the process of subnetting to divide a major IP address into multiple subnets, a new subnet mask is created. This new subnet mask is important to identify network, subnet, and host bits in an IP address. If a host does not know the subnet mask, it may send an address mask request to the local router. If the address of the router is known, this request may be sent directly to the router. Otherwise, the request will be broadcast. When the router receives the request, it will respond with an address mask reply. This address mask reply will identify the correct subnet mask. For example, assume that a host is located within a Class B network and has an IP address of 172.16.5.2. This host does not know the subnet mask so it broadcasts an address mask request:
Source address: 172.16.5.2
Destination address: 255.255.255.255
Protocol: ICMP = 1
Type: Address Mask Request = AM1
Code: 0
Mask: 255.255.255.0
This broadcast is received by 172.16.5.1, the local router. The router responds with the address mask reply:
Source address: 172.16.5.1
Destination address: 172.16.5.2
Protocol: ICMP = 1
Type: Address Mask Reply = AM2
Code: 0
Mask: 255.255.255.0


The frame format for the address mask request and reply is shown in Figure . Figure shows the descriptions for each field in the address mask request message. Note that the same frame format is used for both the address mask request and the reply. However, an ICMP type number of 17 is assigned to the request and 18 is assigned to the reply.















The next page will introduce the ICMP router discovery message.
8.2.6 Router discovery message
This page will explain what the router discovery message is and how it is used.


When a host on the network boots, and the host has not been manually configured with a default gateway, it can learn of available routers through the process of router discovery. This process begins when the host sends a router solicitation message to all routers and uses the multicast address 224.0.0.2 as the destination address. Figure shows the ICMP router discovery message. The router discovery message can also be broadcast to include routers that are not configured for multicasts. If a router discovery message is sent to a router that does not support the discovery process, the solicitation will go unanswered.







When a router that supports the discovery process receives the router discovery message, a router advertisement is sent in return. The router advertisement frame format is shown in Figure and an explanation of each field is shown in Figure .
The next page will describe the router solicitation message.
8.2.7 Router solicitation message
This page will explain why router solicitation messages are used.
A host generates an ICMP router solicitation message in response to a missing default gateway. This message is sent using multicast and it is the first step in the router discovery process. A local router will respond with a router advertisement that identifies the default gateway for the local host. Figure identifies the frame format and Figure gives an explanation of each field.
The next page will discuss source quench messages.












8.2.8 Congestion and flow control messages
This page will explain how source quench messages are used to solve problems related to network congestion.
If multiple computers try to access the same destination at the same time, the destination computer can be overwhelmed with traffic. Congestion can also occur when traffic from a high speed LAN reaches a slower WAN connection. Dropped packets occur when there is too much congestion on a network. ICMP source quench messages are used to reduce the amount of data lost. The source quench message asks senders to reduce the rate at which they transmit packets. Congestion will usually subside after a short period of time and the source will slowly increase the transmission rate if no other source quench messages are received. Most Cisco routers do not send source quench messages by default, because the source quench message may add to the network congestion.
A small office, home office (SOHO) is a scenario where ICMP source quench messages might be used effectively. A SOHO could consist of four computers that are networked with CAT-5 cable and have a shared Internet connection over a 56K modem. The 10-Mbps bandwidth of the SOHO LAN could quickly overwhelm the 56K bandwidth of the WAN link, which would result in data loss and retransmissions. The gateway host can use an ICMP source quench message to request that the other hosts reduce their transmission rates to prevent continued data loss. A network where congestion on the WAN link could cause communication problems is shown in Figure .


This page concludes this lesson. The next page will summarize the main points from this module.
Summary
This page summarizes the topics discussed in this module.


IP is an unreliable method for delivery of network data. ICMP is an error reporting protocol for IP. When datagram delivery errors occur, ICMP is used to report these errors back to the source of the datagram. ICMP echo request and echo reply messages allow the network administrator to test IP connectivity to aid in the troubleshooting process.
Network communication depends on the proper configuration of TCP/IP for both sending and receiving devices. A router also must have the TCP/IP protocol properly configured on its interfaces, and it must use an appropriate routing protocol. To test the availability of a destination use the ICMP ping command.
Incorrect routing information can cause a datagram to travel in a circle. The datagram will not reach its destination within the maximum hop count defined by the routing protocol. This is also known as the TTL. The ICMP message format starts with the type, code, and checksum fields. The type field indicates the type of ICMP message being sent. The code field includes further information specific to the message type. The checksum field, as in other types of packets, is used to verify the integrity of the data.
Destination unreachable messages are delivered to the sender when a datagram cannot be forwarded. Codes in the message header provide information about the problem. When a datagram is not forwarded due to an error in the header, an ICMP type 12 parameter problem message is sent to the source of the datagram.
Control messages inform hosts of conditions such as network congestion or the existence of a better gateway to a remote network. The ICMP redirect/change request is a common control message. It is initiated by a gateway, which is a term commonly used to describe a router.
The following situations will cause default gateways to send ICMP redirect/change request messages:
• A packet enters a router and leaves from the same interface.
• The subnet/network of the source IP address is the same as the subnet/network of the next-hop IP address of the routed packet.
• The datagram is not source-routed.
• The route for the redirect is not another ICMP redirect or a default route.
All ICMP timestamp reply messages contain the originate, receive, and transmit timestamps. The host can subtract the originate time from the transit time to estimate transit time across the network. Transit time will vary based on traffic and congestion on a network.