 |
 |
|
|
|
|
|
|
|
|
|
 |
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
 |
 |
 |
 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
 |
|
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||
|
Close Window | |
|
|
|||
|
|
|
|
|
|
|
|
|
All contents copyright © 2003 Cisco Systems, Inc. All rights reserved. | |
  |
Overview |
|
|
|
9.1 |
|
Examining the Routing Table | |
| 9.1.1 |
|
The show ip route command |
| One of the primary functions of a router is
to determine the best path to a given destination. A router learns paths,
also called routes, from an administrator's configuration or from other
routers by way of routing protocols. Routers store this routing information
in routing tables using on-board dynamic random access memory (DRAM). A
routing table contains a list of the best available routes. Routers use the
routing table to make packet forwarding decisions. The show ip route command displays the contents of the IP routing table. This table contains entries for all known networks and subnetworks, as well as a code that indicates how that information was learned. The following are some additional commands that can be used with the show ip route command:
A routing table maps network prefixes to an
outbound interface.
The example routing table shows four routes for directly connected networks. These routes, labeled with a C, are available to directly connected networks. RTA drops any packet destined for a network that is not listed in the routing table. In order to forward to other destinations the routing table for RTA will have to include more routes. These new routes may be added using one of two methods:
Administratively defined routes are said to
be static because they do not change until a network administrator manually
programs the changes. Routes learned from other routers are dynamic because
they can change automatically as neighboring routers update each other with
new information. Each method has fundamental advantages and disadvantages.
|
|
|
9.1 |
|
Examining the Routing Table | |
| 9.1.2 |
|
Determining the gateway of last resort |
It is not feasible, or even desirable, for a
router to maintain routes to every possible destination. Instead, routers
keep a default route, or a gateway of last resort. Default routes are used
when the router is unable to match a destination network with a more
specific entry in the routing table. The router uses this default route to
reach the gateway of last resort in an effort to forward the packet.
 A key scalability feature is that default routes keep routing tables as lean as possible. They make it possible for routers to forward packets destined to any Internet host without having to maintain a table entry for every Internet network. Default routes can be statically entered by an administrator or dynamically learned using a routing protocol. Default routing begins with the
administrator. Before routers can dynamically exchange information, an
administrator must configure at least one router with a default route.
Depending on the desired results, an administrator can use either of the
following commands to statically configure a default route:
The
ip default-network
command establishes a default route in networks using dynamic routing
protocols.
The global command
ip default-network 192.168.17.0
defines the Class C network 192.168.17.0 as the destination path for packets
that have no routing table entries. For every network configured with
ip default-network,
if a router has a route to the network, that route is flagged as a candidate
for the default route.
Creating an
ip route
to 0.0.0.0/0 is another way to configure a default route.
After configuring a default route or default network, the command show ip route will show the following:
|
|
|
9.1 |
|
Examining the Routing Table | |
| 9.1.3 |
|
Determining route source and destination |
| For traffic going through a network cloud,
path determination occurs at the network layer. The path determination
function enables a router to evaluate the available paths to a destination
and to establish the preferred handling of a packet. Routing services use
network topology information when evaluating network paths. This information
can be configured by the network administrator or collected through dynamic
processes running in the network.
The network layer provides best-effort,
end-to-end, packet delivery across interconnected networks. The network
layer uses the IP routing table to send packets from the source network to
the destination network. After the router determines which path to use, it
takes the packet from one interface and forwards it to another interface or
port that reflects the best path to the packet's destination.
|
|
|
9.1 |
|
Examining the Routing Table | |
| 9.1.4 |
|
Determining L2 and L3 addresses |
| While network layer addresses are used to
get packets from source to destination, it is important to understand that a
different type of address is used to get packets from one router to the
next. For a packet to get from the source to the destination, both Layer 2
and Layer 3 addresses are used. As shown in Figure
,
at each interface, as the packet moves across the network, the routing table
is examined and the router determines the next hop. The packet is then
forwarded using the MAC address of that next hop. The IP source and
destination headers do not change, at any time.
The Layer 3 address is used to route the packet from the source network to the destination network. The source and destination IP addresses remain the same. The MAC address changes at each hop or router. A data-link layer address is necessary because delivery within the network is determined by the address in the Layer 2 frame header, not the Layer 3 packet header.
|
|
|
9.1 |
|
Examining the Routing Table | |
| 9.1.5 |
|
Determining the route administrative distance |
| A router can discover routes using dynamic
routing protocols, or routes can be configured manually on the router by an
administrator. After the routes are discovered or configured, the router
must choose which routes are the best routes to given networks. The administrative distance of the route is the key information that the router uses in deciding which is the best path to a particular destination. The administrative distance is a number that measures the trustworthiness of the source of the route information. The lower the administrative distance, the more trustworthy the source. Different routing protocols have different
default administrative distances.
|
|
|
9.1 |
|
Examining the Routing Table | |
| 9.1.6 |
|
Determining the route metric |
| Routing protocols use metrics to determine
the best route to a destination. The metric is a value that measures the
desirability of a route. Some routing protocols use only one factor to
calculate a metric. For example, RIP version 1 (RIP v1) uses hop count as
the only factor to determine the metric of a route. Other protocols base
their metric on hop count, bandwidth, delay, load, reliability, ticks delay,
maximum transmission unit (MTU), and cost.
Each routing algorithm interprets what is best in its own way. The algorithm generates a number, called the metric value, for each path through the network. Typically, the smaller the metric number, the better the path. Factors such as bandwidth and delay are
static because they remain the same for each interface until the router is
reconfigured or the network is redesigned. Factors such as load and
reliability are dynamic because they are calculated for each interface in
real-time by the router.
The more factors that make up a metric, the greater the flexibility to tailor network operations to meet specific needs. By default, IGRP uses the static factors bandwidth and delay to calculate a metric value. These two factors can be configured manually, allowing precise control over what routes a router chooses. IGRP may also be configured to include the dynamic factors, load and reliability, in the metric calculation. By using dynamic factors, IGRP routers can make decisions based on current conditions. If a link becomes heavily loaded or unreliable, IGRP will increase the metric of routes using that link. Alternate routes may present a lower metric than the downgraded route and would be used instead. IGRP calculates the metric by adding the weighted values of different characteristics of the link to the network in question. In the following example the values bandwidth, bandwidth divided by load, and delay, are weighted with the constants K1, K2, and K3. Metric=K1 *Bandwidth + (K2 * Bandwidth)/256-load) + K3 * Delay The default constant values are K1=K3=1 and K2=K4=K5=0 so:
|
|
|
9.1 |
|
Examining the Routing Table | |
| 9.1.7 |
|
Determining the route next hop |
| Routing algorithms fill routing tables with
a variety of information. Destination/next hop associations tell a router
that a particular destination can be reached optimally by sending the packet
to a particular router. This router represents the next hop on the way to
the final destination.
When a router receives an incoming packet, it
checks the destination address and attempts to associate this address with a
next hop.
|
|
|
9.1 |
|
Examining the Routing Table | |
| 9.1.8 |
|
Determining the last routing update |
Use the following commands to find the last
routing update:
|
|
|
9.1 |
|
Examining the Routing Table | |
| 9.1.9 |
|
Observing multiple paths to destination |
| Some routing protocols support multiple
paths to the same destination. Unlike single path algorithms, these
multi-path algorithms permit traffic over multiple lines, provide better
throughput, and are more reliable. Rt1 has two routes to network 192.168.30.0. The variance command will be set on Rt1 to ensure that both paths to network 192.168.30.0 are utilized. Figure
Figure
The preferred route is interface FastEthernet 0/0, but Serial 0/0 will also be used. To verify load balancing, ping 192.168.30.1. After the
ping
is executed the preferred route is using interface Serial 0/0. IGRP will use
load balancing between the two links.
|
|
|
9.2 | Network Testing | ||
| 9.2.1 |
|
Introduction to network testing |
| Basic testing of a network should proceed in
sequence from one OSI reference model layer to the next.
It is best to begin with Layer 1 and work to Layer 7 if necessary. Beginning
with Layer 1, look for simple problems such as power cords plugged in the
wall. The most common problems that occur on IP networks result from errors
in the addressing scheme. It is important to test the address configuration
before continuing with further configuration steps. Each test presented in this section focuses on network operations at a specific layer of the OSI model. The commands telnet and ping are two important commands that are used for testing a network.
|
|
|
9.2 |
|
Network Testing | |
| 9.2.2 |
|
Using a structured approach to troubleshooting |
| Troubleshooting is a process that allows a
user to find problems on a network. There should be an orderly process to
troubleshooting based on the networking standards set in place by an
administration. Documentation is a very important part of the
troubleshooting process.
The steps in this model are:
Figure
Using a structured approach to troubleshooting, every member of a network support team can know what steps each member of the team has completed to solve a problem. If a variety of troubleshooting ideas are tried with no organization or documentation, problem solving is not efficient. Even if a problem is solved in the non-structured environment, it will probably be impossible to replicate the solution for similar problems in the future.
|
|
|
9.2 |
|
Network Testing | |
| 9.2.3 |
|
Testing by OSI layers |
| Testing should begin with Layer 1 of the OSI
model and work to Layer 7 if necessary.
Layer 1 errors can include:
Layer 2 errors can include:
Layer 3 errors can include:
If errors appear on the network, the process of testing through the OSI layers should begin. The ping command is used at Layer 3 to test connectivity. At Layer 7 the telnet command may be used to verify the application layer software between source and destination stations. Both of these commands will be discussed in detail in a later section.
|
|
|
9.2 |
|
Network Testing | |
| 9.2.4 |
|
Layer 1 troubleshooting using indicators |
| Indicator lights are a useful tool for
troubleshooting. Most interfaces or NICs will have indicator lights that
show whether there is a valid connection. Often this light is called the
link light. The interface may also have lights to indicate whether traffic
is being transmitted (TX) or received (RX). If the interface has indicator
lights that do not show a valid connection, power off the device and reseat
the interface card. A faulty or incorrect cable could also cause a link
light to indicate a bad connection or no link. Check to make sure that all cables are connected to the appropriate ports. Make sure that all cross-connects are properly patched to the correct location using the appropriate cable and method. Verify that all switch or hub ports are in the correct VLAN or collision domain, and have appropriate options set for spanning tree and other considerations. Verify that the proper cable is being used. A crossover cable may be required for direct connections between two switches or hubs, or between two hosts such as PCs or routers. Verify that the cable from the source interface is properly connected and is in good condition. If there is doubt that the connection is good, reseat the cable and ensure that the connection is secure. Try replacing the cable with a known working cable. If this cable connects to a wall jack, use a cable tester to ensure that the jack is properly wired. Also check any transceiver in use to ensure that it is the correct type, is properly connected, and is properly configured. If replacing the cable does not resolve the problem, try replacing the transceiver if one is being used. Always check to make sure that the device is
powered on. Always check the basics before running diagnostics or attempting
complex troubleshooting.
|
|
|
9.2 |
|
Network Testing | |
| 9.2.5 |
|
Layer 3 troubleshooting using ping |
| The
ping
utility is used to test network connectivity. As an aid to diagnosing basic
network connectivity, many network protocols support an echo protocol. Echo
protocols are used to test whether protocol packets are being routed. The
ping
command sends a packet to the destination host and then waits for a reply
packet from that host. Results from this echo protocol can help evaluate the
path-to-host reliability, delays over the path, and whether the host can be
reached or is functioning. The
ping output displays the minimum,
average, and maximum times it takes for a ping packet to find a specified
system and return. The ping
command uses Internet Control Message Protocol (ICMP) to verify the hardware
connection and the logical address of the network layer. Figure
is a table showing the various ICMP message types. This is a very basic
testing mechanism for network connectivity.
In Figure
The
ping command tests network
connections by sending ICMP echo requests to a target host and times
replies. When testing a connection, ping tracks the number of packets sent,
the number of replies received, and the percentage of packets lost. It also
tracks the amount of time required for the packets to reach the destination,
and for replies to be received. This information allows verification of
communication between a workstation and other hosts, and whether information
was lost.
The ping command can be invoked from both user EXEC mode and privileged EXEC mode. The ping command can be used to confirm basic network connectivity on AppleTalk, ISO Connectionless Network Service (CLNS), IP, Novell, Apollo, VINES, DECnet, or XNS networks. The use of an extended ping command directs the router to perform a more extensive range of test options. To use extended ping, type ping at the command line, then press the Enter key without entering an IP address. Prompts will appear each time the Enter key is pressed, allowing the specification of many more options than with standard ping. It is a good idea to use the ping command when the network is functioning properly to see how the command works under normal conditions and so that there is something to compare against when troubleshooting.
|
|
|
9.2 |
|
Network Testing | |
| 9.2.6 |
|
Layer 7 troubleshooting using Telnet |
| The telnet utility is a virtual terminal
protocol that is part of the TCP/IP protocol suite. It allows verification
of the application layer software between source and destination stations.
This is the most complete test mechanism available. The telnet utility is
normally used to connect remote devices, to gather information, and to run
programs. The Telnet application
provides a virtual terminal for connection to routers running TCP/IP. For
troubleshooting purposes, it is useful to verify that a connection can be
made using Telnet. This proves that at least one TCP/IP application is able
to connect end-to-end. A successful Telnet connection indicates that the
upper-layer application and the services of lower layers are functioning
properly.
If an administrator can Telnet to one router but not to another router, verify lower layer connectivity. If connectivity has been verified, it is likely that the Telnet failure is caused by specific addressing, naming, or access permission problems. These problems can exist on the administrator's router or on the router that failed as a Telnet target. If the Telnet to a particular server fails from one host, try connecting from a router and several other devices. When trying to Telnet, if a login prompt is not achieved, check the following:
|
|
|
9.3 |
|
Troubleshooting Router Issues Overview | |
| 9.3.1 |
|
Troubleshooting Layer 1 using show interfaces |
| The Cisco IOS contains a rich set of
commands for troubleshooting. Among the more widely used are the
show
commands. Every aspect of the router can be viewed with one or more of the
show
commands. The show
command used to check the status and statistics of the interfaces is the
show interfaces
command. Variations of this command can be used to check the status of the
different types of interfaces. To view the status of the FastEthernet
interfaces, use show interfaces
FastEthernet. The command may also be
used to view the status of one particular interface. To view the status of
Serial 0/0, use show interfaces
serial0/0. The status of two important portions of the interfaces is shown with the show interfaces command. They are the physical (hardware) portion and logical (software) portion. These can be related to the Layer 1 and the Layer 2 functions. The hardware includes cables, connectors, and interfaces showing the condition of the physical connection between the devices. The software status shows the state of messages such as keepalives, control information, and user information that are passed between adjacent devices. This relates to the condition of a Layer 2 protocol passed between two connected router interfaces. These important elements of the
show interfaces serial
command output are displayed as the line and data-link protocol status.
The first parameter refers to the hardware layer and essentially reflects whether the interface is receiving the Carrier Detect (CD) signal from the other end of the connection. If the line is down, a problem may exist with the cabling, equipment somewhere in the circuit may be powered off or malfunctioning, or one end may be administratively down. If the interface is administratively down it has been manually disabled in the configuration. The
show interfaces serial
command also provides information to
help diagnose other Layer 1 issues that are not as easy to determine. An
increasing number of carrier transitions counts on a serial link may
indicate one or more of the following problems:
If an increasing number of input errors appear in the show interfaces serial output, there are several possible sources of those errors. Some of these related to Layer 1 problems are:
Another area to examine is number of interface resets. These are the result of too many missed keepalives. The following Layer 1 problems could be a cause of interface resets:
If carrier transitions and interface resets are increasing or if input errors are high while interface resets are increasing, the problem is likely to be a bad link or defective CSU or DSU. The number of errors should be interpreted
relative to the amount of traffic that the router has processed and the
amount of time that the statistics have been captured. The router tracks
statistics that provide information about the interface. The statistics
reflect router operation since it was started or since the last time the
counters were cleared.
If the show interfaces output shows the last clearing of the counters as never, use the show version command to find out how long the router has been functional. Use the clear counters command to reset the counters to zero. These counters should always be cleared after an interface problem has been corrected. Starting from zero gives a better picture of the current status of the network and will help verify that the issue has indeed been corrected.
|
|
|
9.3 |
|
Troubleshooting Router Issues Overview | |
| 9.3.2 |
|
Troubleshooting Layer 2 using show interfaces |
| The
show interfaces
command is perhaps the single most important tool to discover Layer 1 and
Layer 2 problems with the router. The first parameter (line) refers to the
physical layer. The second parameter (protocol) indicates whether the IOS
processes that control the line protocol consider the interface usable. This
is determined by whether keepalives are successfully received. Keepalives
are defined as messages sent by one network device to inform another network
device that the virtual circuit between the two is still active. If the
interface misses three consecutive keepalives, the line protocol is marked
as down.
When the line is down, the protocol is always down, because there is no useable media for the Layer 2 protocol. This will be true when the interface is down due to a hardware problem and when it is administratively down. If the interface is up and the line protocol is down, a Layer 2 problem exists. Among the possible causes are:
The show interfaces serial command should be used after configuring a serial interface to verify the changes and that the interface is operational.
|
|
|
9.3 |
|
Troubleshooting Router Issues Overview | |
| 9.3.3 |
|
Troubleshooting using show cdp |
| Cisco Discovery Protocol (CDP) advertises
device information to its direct neighbors, including MAC and IP addresses
and outgoing interfaces. The output
from the show cdp neighbors
command displays information about directly connected neighbors.
If the physical layer is properly functioning, then all other directly connected Cisco devices should be displayed. If no known device appears, a Layer 1 problem likely exists. One area of concern with CDP is security. The
amount of information CDP provides is so extensive that it can be a
potential security hole.
|
|
|
9.3 |
|
Troubleshooting Router Issues Overview | |
| 9.3.4 |
|
Troubleshooting using traceroute |
| The
traceroute
command is used to discover the routes that packets take when traveling to
their destination. Traceroute can also be used to help test the network
layer (Layer 3) on a hop-by-hop basis and provide performance benchmarks. The output of the traceroute command generates a list of hops that were successfully reached. If the data successfully reaches the intended destination, then the output indicates every router that the datagram passes through. This output can be captured and used for future troubleshooting of the internetwork. Traceroute output will also indicate the specific hop at which the failure is occurring. For each router in the path a line of output is generated on the terminal indicating the IP address of the interface that the data entered. If an asterisk (*) appears, the packet failed. By obtaining the last good hop from the traceroute output and comparing it to a diagram of the internetwork, the problem area can be isolated. Traceroute also provides information
indicating the relative performance of links. The round trip time (RTT) is
the time required to send an echo packet and get a response.
Notice that the device receiving the traceroute also has to know how to send the reply back to the source of the traceroute. In order for the traceroute or ping data to successfully make the round trips between routers, there have to be known routes in both directions. A failed response is not always an indication of a problem because ICMP messages could be rate-limited or filtered at the host site. This is especially true across the Internet. Traceroute sends out a sequence of User Datagram Protocol (UDP) datagrams from the router to an invalid port address on the remote host. For the first sequence of three datagrams sent, a Time-To-Live (TTL) field value is set to one. The TTL value of 1 causes the datagram to time out at the first router in the path. This router then responds with an ICMP Time Exceeded Message (TEM) indicating that the datagram has expired. Three more UDP messages are now sent, this time with the TTL value set to 2. This causes the second router to return ICMP TEMs. This process continues until the packets actually reach the other destination. Since these datagrams are trying to access an invalid port at the destination host, ICMP Port Unreachable Messages are returned instead of the ICMP Time Exceeded Message. This indicates an unreachable port and signals the traceroute program, terminating the process.
|
|
|
9.3 |
|
Troubleshooting Router Issues Overview | |
| 9.3.5 |
|
Troubleshooting routing issues |
| The
show ip protocols
and show ip route
commands display information about routing protocols and the routing table.
The output from these commands can be used to verify the routing protocol
configuration. The
show ip route
command is perhaps the single most important command for troubleshooting
routing issues. This command displays the contents of the IP routing table.
The output from the show ip
route command shows the entries for
all known networks and subnetworks, and how that information was learned.
If there is a problem reaching a host in a particular network, then the output of the show ip route command can be used to verify that the router has a route to that network. If the output of the show ip route command does not show the expected learned routes or no learned routes, then the problem is possibly that routing information is not being exchanged. In this case, use the show ip protocols command on the router to check for a routing protocol configuration error. The
show ip protocols
command displays values about IP routing protocol information on the entire
router. This command can be used to confirm which protocols are configured,
which networks are being advertised, which interfaces are sending updates,
and the sources of routing updates. The
show ip protocols
output also shows timers, filters, route summarization, route
redistribution, and other parameters that are specific to each routing
protocol that is enabled on the router. When multiple routing protocols are
configured, the information about each protocol is listed in a separate
section.
The show ip protocols command output can be used to diagnose a multitude of routing issues, including identifying a router that is suspected of delivering bad router information. It may be used to confirm the expected protocols, advertised networks, and routing neighbors are present. As with any troubleshooting process, identifying the problem is difficult if not impossible if there is not documentation indicating the expected.
|
|
|
9.3 |
|
Troubleshooting Router Issues Overview | |
| 9.3.6 |
|
Troubleshooting using show controllers serial |
| Very often, configuration and
troubleshooting on routers is done remotely when it is not possible to
physically inspect the router connections. The
show controllers serial
command is useful to determine the type of cable connected without
inspecting the cables.
By examining the show controllers serial command output, the type of cable that the controller detects can be determined. This is useful for finding a serial interface with no cable, the wrong type of cable, or a defective cable. The show controllers serial command queries the integrated circuit (chip) that controls the serial interfaces and displays information about the physical interface. This output varies from controller chip to controller chip. Even within a router type, different controller chips may be used. Regardless of the controller type, the show controllers serial command produces a tremendous amount of output. Other than the cable type, most of this output is internal technical detail regarding the controller chip status. Without specific knowledge of the integrated circuit, this information is of little use.
|
|
|
9.3 |
|
Troubleshooting Router Issues Overview | |
| 9.3.7 |
|
Introduction to debug |
The
debug
commands assist in the isolation of protocol and configuration problems. The
debug
command is used to display dynamic data and events. Since the
show
commands only display static information, they provide a historical picture
of the router operation. Using the
debug
command output gives more insight to the current events of the router. These
events could be traffic on an interface, error messages generated by nodes
on the network, protocol-specific diagnostic packets, and other useful
troubleshooting data.
The dynamic output of the debug
command comes at a performance cost, producing high processor overhead that
may disrupt normal router operation. For this reason,
debug
should be used conservatively. Use
debug commands to examine specific
types of traffic or problems after likely problems have been narrowed a few
causes. debug
should be used isolate problems and not to monitor normal network operation.
By default, the router sends the debug output and system messages to the console. If a telnet session is being used to examine the router, then the debug output and system messages can be redirected to the remote terminal. This is done through the telnet session by issuing the terminal monitor command. Extra caution should be used when selecting the debug commands from a telnet session. No command should be selected that will cause the debug output to create additional traffic that creates debug output. If this occurs, the telnet session will rapidly saturate the link with traffic or the router will exhaust one or more resources. A good rule to follow to prevent this recursion of traffic is “Never debug any activity on the port where the session is established”. The output of the different
debug
commands varies. Some may frequently generate many lines while others
produce a line or two of output every few minutes.
Another IOS software service that will enhance the usefulness of the debug output is the timestamps command. This command will put a timestamp on a debug message. This information provides the time when the debug event occurred and the duration of time between events. The following command configures a timestamp that will show the hour:minute:second of the output, the amount of time since the router was last powered up, and when a reload command was executed:
The no debug all command or the undebug all command turn off all diagnostic output. To disable a particular debug command, use the “no” form of the command. For example, if debug for monitoring RIP was enabled with the command debug ip rip, it can be disabled with no debug ip rip. To view what is currently being examined by a debug command, use show debugging.
|
|
|
Summary |
An understanding of the following key points
should have been achieved:
|
Web Links
