Module 9: Basic Router Troubleshooting

Module 9: Basic Router Troubleshooting

Overview A router uses a dynamic routing protocol to learn about routes to destination networks. Most routers use a combination of dynamic routing and manually configured static routes. Regardless of the method used, when a router determines that a route is the best path to a destination, it installs that route in its routing table. This module will describe methods that are used to examine and interpret the contents of the routing table.
Network testing and troubleshooting are perhaps the most time consuming components of every network administrator’s job. Efficient testing and troubleshooting must be done in a logical, orderly, and well-documented fashion. Otherwise, the same problems will reoccur, and the network administrator will never truly understand the network. This module describes a structured approach to network troubleshooting and provides some tools to use in the troubleshooting process.
Routing problems are among the most common and difficult for network administrators to diagnose. There are many tools that make it easier to identify and solve routing problems. This module will introduce several of the most important of these tools and provide practice in their use.
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:

• Use the show ip route command to gather detailed information about the routes installed on the router
• Configure a default route or default network
• Understand how a router uses both Layer 2 and Layer 3 addressing to move data through the network
• Use the ping command to perform basic network connectivity tests
• Use the telnet command to verify the application layer software between source and destination stations
• Troubleshoot by sequential testing of OSI layers
• Use the show interfaces command to confirm Layer 1 and Layer 2 problems
• Use the show ip route and show ip protocol commands to identify routing issues
• Use the show cdp command to verify Layer 2 connectivity
• Use the trace route command to identify the path packets take between networks
• Use the show controllers serial command to ensure the proper cable is attached

Use basic debug commands to monitor router activity 

Module 8 : Summary

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.

Router solicitation message / Congestion and flow control messages

Router solicitation message 
8.2.7 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.Congestion and flow control messages
8.2.8 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.

Router solicitation message

Router solicitation message
8.2.6 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.

Address mask requests

Address mask requests
8.2.5 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.

Information requests and reply message formats

Information requests and reply message formats 
8.2.4 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.

Clock synchronization and transit time estimation

Clock synchronization and transit time estimation 
8.2.3 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.