CCNA 1 and 2 Companion Guide, Revised (Cisco Networking Academy Program) part 81 pps

ICMP 769 Detecting Excessively Long Routes Several problem situations can occur in network communication. In one situation, a datagram travels in a circle, never reaching its destination. In another situation, no path exists between the source and the destination that conforms to the limitations of the routing protocol. An example of the first situation arises when two routers contin- ually route a datagram back and forth. In this scenario, each router operates with the understanding that the other router should be the next hop to the destination. One potential cause of this problem is faulty routing information. Routing protocols can also have limits on the distance that a packet is allowed to travel. For example, RIP has a hop limit of 15, which simply means that the packet is allowed to pass through only 15 routers. In each of these cases, an excessively long route exists. Whether the actual path includes too many hops or a circular routing path exists, the packet eventually will reach the end of its life. When a packet reaches the end of its life, it has reached its Time-To-Live (TTL). The TTL value typically matches the maximum hop count defined by the routing protocol. In each datagram, a TTL value is defined. As each router processes the data- gram, it decreases the TTL value by one. When the TTL value of the datagram reaches 0, the packet is discarded. ICMP uses a time exceeded message to notify the source device that the TTL has been exceeded. ICMP Message Format: Echo Messages As with any type of packet, ICMP messages have special formats. Each ICMP message type shown in Table 17-3 has its own unique characteristics. However, all ICMP mes- sage formats start with the following three fields: ■ Type ■ Code ■ Checksum C An ICMP source quench message was received. A device along the path—possibly the destination—might be receiving too much traffic; check input queues. & An ICMP time exceeded message was received. A routing loop might have occurred. Table 17-2 Cisco ping Return Codes (Continued) Code Meaning Possible Cause(s) 1102.book Page 769 Tuesday, May 20, 2003 2:53 PM 770 Chapter 17: TCP/IP Error and Control Messages The Type field indicates the type of ICMP message being sent. The Code field includes further information that is specific to the message type. The Checksum field, as in other types of packets, verifies the integrity of the data. Figure 17-6 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 might be a part of the echo reply or echo request message. Table 17-3 ICMP Message Types ICMP Message Types 0 Echo reply 3 Destination unreachable 4 Source quench 5 Redirect/change request 8 Echo request 9 Router advertisement 10 Router selection 11 Time exceeded 12 Parameter problem 13 Timestamp request 14 Timestamp reply 15 Information request 16 Information reply 17 Address mask request 18 Address mask reply 1102.book Page 770 Tuesday, May 20, 2003 2:53 PM ICMP 771 Figure 17-6 Message Format for Echo Request and Echo Reply ICMP Message Format: Destination Unreachable Message Datagrams cannot always be forwarded to their destinations, as shown in Figure 17-7. Hardware failures, improper protocol configuration, down interfaces, and incorrect routing information are some of the reasons why successful delivery might not be possible. In these cases, ICMP delivers back to the sender a destination unreachable message indicating that the datagram could not be properly forwarded. Figure 17-7 Destination Unreachable Message Figure 17-8 shows an ICMP destination unreachable message header. The value of 3 in the Type field indicates that it is a destination unreachable message. The Code value indicates the reason why the packet could not be delivered. The Code value is 0, indicating that the network was unreachable. Table 17-4 displays Code values and description. 1102.book Page 771 Tuesday, May 20, 2003 2:53 PM 772 Chapter 17: TCP/IP Error and Control Messages Figure 17-8 Destination Unreachable Message Format A destination unreachable message also might 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. Therefore, a destination unreachable message is sent. Destination unreachable messages also can be generated if IP-related services such as FTP or web services are unavailable. To effectively trouble- shoot an IP network, it is necessary to understand the various causes of ICMP destination unreachable messages. Table 17-4 Code Value and Description Code Value Description 0 Network unreachable 1 Host unreachable 2 Protocol unreachable 3 Port unreachable 4 Fragmentation needed and DF set 5 Source route failed 6 Destination network unknown 7 Destination host unknown 8 Source host isolated 9 Communication with data network administratively prohibited 10 Communication with data host administratively prohibited 11 Network unreachable for type of service 12 Host unreachable for type of service 1102.book Page 772 Tuesday, May 20, 2003 2:53 PM TCP/IP Suite Control Messages 773 Miscellaneous Error Reporting Devices that process datagrams might not be capable of forwarding a datagram because of some type of error in the header. This error does not relate to the state of the desti- nation host or network, but it still prevents the datagram from being processed and delivered. In this case, an ICMP Type 12 parameter problem message is sent to the source of the datagram. Figure 17-9 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. Figure 17-9 Parameter Problem Message Format TCP/IP Suite Control Messages Unlike error messages, control messages are not the result of lost packets or error con- ditions that occur during packet transmission. Instead, control messages inform hosts of conditions such as network congestion or the existence of a better gateway to a remote network. Like all ICMP messages, ICMP control messages are encapsulated within an IP datagram. ICMP uses IP datagrams to traverse multiple networks. ICMP uses multiple types of control messages; Table 17-3 listed some of the most common. Many of these control messages are discussed in the following sections. ICMP Redirect/Change Requests A common ICMP control message is the ICMP redirect/change request. This type of message can be initiated only by a gateway. 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 17-10 displays a host connected to a router that has access to the Internet. 08 16 31 Type (12) Code (0-2) Checksum Unused (Must be Zero) Internet Header + First 64 Bits of Datagram Pointer 1102.book Page 773 Tuesday, May 20, 2003 2:53 PM 774 Chapter 17: TCP/IP Error and Control Messages Figure 17-10 Redirect Request After it is configured with the IP address of Fa 0/0 as its default gateway, Host B uses that IP address to reach any network not directly connected to it. Normally, Host B connects to only a single gateway. However, in some circumstances, a host connects to a segment that has two or more directly connected routers. In this case, the host’s default gateway might need to use a redirect/change request to inform the host of the best path to a certain network. Default gateways send ICMP redirects/change requests only 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 (that is, it is not routed from the place from which the data is taken). ■ 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 disables ICMP redirects. The ICMP redirect/change request uses the format shown in Figure 17-11. The request has an ICMP type code of 5. In addition, the request has a code value of 0, 1, 2, or 3. The meanings of these code values with their required actions are shown in Table 17-5. 1102.book Page 774 Tuesday, May 20, 2003 2:53 PM TCP/IP Suite Control Messages 775 Figure 17-11 Redirect Request Message Format The receiver of the redirect should use the gateway Internet address in the ICMP redirect as the router IP address when forwarding packets for a particular network. In the exam- ple shown in Figure 17-10, the ICMP redirect sent from Router A to Host B would have a gateway Internet address of 192.168.12.2, which is the IP address of Router B. Clock Synchronization and Transit Time Estimation The TCP/IP protocol suite allows systems to connect to one another over vast distances through multiple networks. Each individual network provides clock synchronization in its own way. This can result in problems when hosts on different networks try to communicate using software that requires time synchronization. The ICMP timestamp message type is designed to help reduce this problem. The ICMP timestamp request message allows a host to ask for a remote host’s current time. The remote host uses an ICMP timestamp reply message to respond to the request. Figure 17-12 shows the format for an ICMP timestamp request or reply. Figure 17-12 Timestamp Request Table 17-5 Code Value with Required Action Code Value Required Action 0 Redirect datagrams for the network 1 Redirect datagrams for the host 2 Redirect datagrams for the type of service and the network 3 Redirect datagrams for the type of service and the host 1102.book Page 775 Tuesday, May 20, 2003 2:53 PM 776 Chapter 17: TCP/IP Error and Control Messages 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 no addi- tional parameters are available. The ICMP timestamp request contains an originate timestamp, which specifies the time on the requesting host just before the timestamp request was sent. The receive timestamp is the time that the destination host received 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 transit time- stamps. Using these three timestamps, the host that originated the ICMP timestamp request can estimate transit time across the network. By subtracting the originate time from the transit time, the host can try to guess its transit time. However, this is only a guess because the true transit time can vary widely, depending on traffic and conges- tion on the network. Also, using these three timestamps, the host that originated the ICMP timestamp request can estimate the local time of the remote computer. ICMP timestamp messages provide a simple way of estimating time on a remote host and the total network transit time. However, this is not the best way to obtain this information. Instead, protocols such as the Network Time Protocol (NTP), at the higher layers of the TCP/IP protocol stack, perform clock synchronization in a more reliable manner. Information Requests and Reply Message Formats The ICMP information requests and reply messages originally were intended to enable a host to determine the number of the network that it occupied. Figure 17-13 shows the format for an ICMP information request and reply message. Figure 17-13 Information Request and Reply Message Format Two type codes are available in this message. Type 15 code signifies an information request message. Type 16 code identifies an information reply message. This particular ICMP message type is considered obsolete. Other protocols, such as BOOTP and 08 16 31 Type (15 or 16) Code (0) Checksum Identifier Sequence Number 1102.book Page 776 Tuesday, May 20, 2003 2:53 PM TCP/IP Suite Control Messages 777 Dynamic Host Configuration Protocol (DHCP), now are used to allow hosts to obtain their network numbers to which they are attached. Address Mask Requests 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 crucial in identifying network, subnet, and host bits in an IP address. If a host does not know the subnet mask, it might send an address mask request to the local router. If the address of the router is known, this request can be sent as unicast. If the address is not known, this request is sent using broadcast. When the router receives the request, it responds with an address mask reply. This address mask reply identifies 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.3. This host does not know the subnet mask, so it broadcasts an address mask request: Source address 172.16.5.3 Destination address 255.255.255.255 Protocol ICMP = 1 Type Address Mask Request = AM1 Code 0 Mask 0 This broadcast is received by 168.5.5.1, the local router. That router responds with the address mask reply: Source address 172.16.5.1 Destination address 172.16.5.3 Protocol ICMP = 1 Type Address Mask Reply = AM2 Code 0 Mask 255.255.255.0 Figure 17-14 shows the frame format for the address mask request. Table 17-6 lists the ICMP address mask request messages. Notice 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. Figure 17-14 Address Mask Requests 1102.book Page 777 Tuesday, May 20, 2003 2:53 PM 778 Chapter 17: TCP/IP Error and Control Messages Router-Discovery Message The host can learn the available routers through the process of router discovery when the host has not been manually configured with a default gateway. This process begins with the host sending a multicast router-solicitation message to all routers, using the address 224.0.0.2. Figure 17-15 shows the ICMP router-solicitation message. This router solicitation also can be sent using broadcast to include routers that might not be configured for multicasting. RFC 1812 indicates that routers should be capable of supporting the router-discovery process for all the networks that are directly connected. Table 17-6 ICMP Address Mask Request Messages ICMP Field Description Type 17 Address mask request message. Type 18 Address mask reply message. Code 0 Address mask request message. Code 0 Address mask reply message. Checksum The 16-bit 1s complement of the 1s complement sum of the ICMP message starting with the ICMP type. For computing the checksum, the checksum field should be 0. The checksum might be replaced in the future. Identifier An identifier to aid in matching requests and replies. It can be 0. Sequence Number A sequence number to aid in matching requests and replies. It can be zero. Address Mask A 32-bit mask. A gateway receiving an address mask request should return it with the Address Mask field set to the 32-bit mask of the bits identifying the subnet and the network for the subnet on which the request was received. If the request- ing host does not know its own IP address, it can leave the source field 0; the reply then should be broadcast. However, this approach should be avoided if at all possible because it increases the superfluous broadcast lead on the network. Even when the replies are broadcast, there is no need to match requests with replies because there is only one possible address mask for a subnet. The Identifier and Sequence Number fields can be ignored. Type AM1 can be received from a gateway or host. Type AM2 can be received from a gateway, or a host acting in lieu of a gateway. 1102.book Page 778 Tuesday, May 20, 2003 2:53 PM . advertisement 10 Router selection 11 Time exceeded 12 Parameter problem 13 Timestamp request 14 Timestamp reply 15 Information request 16 Information reply 17 Address mask request 18 Address mask reply 11 02. book. was unreachable. Table 17 -4 displays Code values and description. 11 02. book Page 7 71 Tuesday, May 20 , 20 03 2: 53 PM 7 72 Chapter 17 : TCP/IP Error and Control Messages Figure 17 -8 Destination Unreachable. request and the reply. However, an ICMP type number of 17 is assigned to the request, and 18 is assigned to the reply. Figure 17 -14 Address Mask Requests 11 02. book Page 777 Tuesday, May 20 , 20 03 2: 53