Saturday, October 22, 2011

Troubleshooting Layer 1 using show interfaces



Troubleshooting Layer 1 using show interfaces 
9.3.1 This page will discuss show commands and explain how they are used to troubleshoot Layer 1 issues.
The Cisco IOS contains many 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. The show interfaces command without arguments returns status and statistics on all the router ports. The show interfaces returns the status and statistics of only the named port. To view the status of Serial 0/0, use show interfaces serial 0/0.
The status of two important portions of the interfaces is shown with the show interfaces command. They are the physical, or hardware portion and logical, or 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 can be demonstrated by an example of a serial port on a modular router. The show interfaces serial 0/0 command displays the line and data-link protocol status of serial port one. 
The first parameter refers to the hardware layer and indicates if the interface receives a 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 0/0 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: 
  • Line interruptions due to problems in the service provider network
  • Faulty switch, DSU, or router hardware
If an increasing number of input errors appear in the show interfaces serial 0/0 output, there are several possible sources of those errors. Some common Layer 1 problems are as follows:
  • Faulty telephone company equipment
  • Noisy serial line
  • Incorrect cable or cable length
  • Damaged cable or connection
  • Defective CSU or DSU
  • Defective router hardware
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:
  • Bad line that causes carrier transitions
  • Possible hardware problem at the CSU, DSU, or switch
If carrier transitions and interface resets are increasing or if input errors are high while this occurs, 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 privileged EXEC command to reset the counters to zero. These counters should always be cleared after an interface problem has been corrected. This reset to zero gives a better picture of the current status of the network and will help verify that an issue has been corrected.
The Lab Activity will help students become more familiar with the show interfaces command.
The next page will explain how the show interfaces command is used to troubleshoot Layer 2 problems.

Layer 7 troubleshooting using Telnet

Layer 7 troubleshooting using Telnet 
9.2.7 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 connection to routers that use 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, Telnet from a router and other devices. If a login prompt is not achieved during Telnet, check the following:
  • A reverse DNS lookup may not be found on the client address. Many Telnet servers will not allow connections from IP addresses that have no DNS entry. This is a common problem for DHCP-assigned addresses if the administrator has not added DNS entries for the DHCP pools.
  • It is possible that a Telnet application cannot negotiate the appropriate options and will not connect. On a Cisco router, this negotiation process can be viewed with the debug telnet command.
  • It is possible that Telnet is disabled or has been moved to a port other than 23 on the destination server.
The Lab Activity will allow students to troubleshoot a network with Telnet and the ping command. The Interactive Media Activity will help students become more familiar with Telnet.
This page concludes this lesson. The next lesson will teach students how to troubleshoot router issues. The first page will discuss show commands. 

Layer 1 troubleshooting using indicators / Layer 3 troubleshooting using ping



Layer 1 troubleshooting using indicators
9.2.4 The page will explain how to troubleshoot Layer 1 issues with the help of indicator lights. Most interfaces or NICs have indicator lights that show if there is a valid connection. This light is often called the link light. The interface may also have lights to indicate when traffic is transmitted (TX) or received (RX). If the interface has indicator lights that do not show a valid connection, check for faulty or incorrect cabling. If cabling is correct, power off the device and reseat the interface card.
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 the proper cable is 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 the problem continues after the cable is replaced, replace the transceiver if one is used.
Always check to make sure that the device is powered on. Always check the basics before running diagnostics or attempting complex troubleshooting. 
The next page will describe the ping command.
Layer 3 troubleshooting using ping 
9.2.5 
This page will explain how the ping utility can be used to test network connectivity. Many network protocols support an echo protocol to help diagnose basic network connectivity. Echo protocols are used to determine if protocol packets are 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 ICMP to verify the hardware connection and the logical address of the network layer. This is a very basic way to test network connectivity. Figure shows the ICMP message types. This is a very basic testing mechanism for network connectivity.
In Figure , the ping target 172.16.1.5 responded successfully to all five datagrams sent. Each exclamation point (!) indicates a successful echo. One or more periods (.) indicates that the application on the router timed out before it received a packet echo from the ping target.
The following command activates a diagnostic tool that is used to test connectivity:
Router#ping [protocol] {host | address}
To test network connectivity, the ping command sends ICMP echo requests to a target host and measures how long it takes to reply. The ping command 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 packets to reach the destination and for replies to be received. This information can be used to verify communications between hosts and determine if 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, and press the Enter key. Prompts will appear each time the Enter key is pressed. These prompts provide many more options than with a standard ping
Use the ping command when the network functions properly to see how the command works under normal conditions. This can be used as a comparison, or baseline, when troubleshooting.
The Lab Activity will allow students to use the ping command to send an ICMP echo request.
The next page will describe the Telnet application.

Testing by OSI layers

Testing by OSI layers
9.2.3 This page will describe the types of errors that occur at the first three layers of the OSI model.
Layer 1 errors can include the following: 
  • Broken cables
  • Disconnected cables
  • Cables connected to the wrong ports
  • Intermittent cable connection
  • Rollover, crossover, or straight-through cables used incorrectly
  • Transceiver problems
  • DCE cable problems
  • DTE cable problems
  • Devices turned off
Layer 2 errors can include the following: 
  • Improperly configured serial interfaces
  • Improperly configured Ethernet interfaces
  • Improper encapsulation set
  • Improper clockrate settings on serial interfaces
  • Network interface card (NIC) problems
Layer 3 errors can include the following: 
  • Routing protocol not enabled
  • Wrong routing protocol enabled
  • Incorrect IP addresses
  • Incorrect subnet masks
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.
The next page will explain how indicator lights can be used to test a network.

Using a structured approach to troubleshooting

Using a structured approach to troubleshooting 
9.2.2 Troubleshooting is a process that allows a user to find problems on a network. This page explains why an orderly process should be used to troubleshoot a network. This process should be based on the networking standards set in place by a network administrator. Documentation is a very important part of the troubleshooting process. 
The steps in this model are as follows:
Step 1 Collect all available information and analyze the symptoms of the failure.
Step 2 Localize the problem to a particular network segment, module, unit, or user.
Step 3 Isolate the trouble to specific hardware or software within the unit, module, or user network account.
Step 4 Locate and correct the problem.
Step 5 Verify that the problem has been solved.
Step 6 Document the problem and the solution.
Another approach to troubleshooting. These are not the only ways to troubleshoot a network. However, an orderly process is important to keep a network running smoothly and efficiently.
When a structured approach is used, every member of a network support team knows which steps the other team members have completed to troubleshoot the network. 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 be difficult to replicate the solution for similar problems.
The Interactive Media Activity will help students become familiar with the troubleshooting process.
The next page will teach students the types of errors that occur at the first three layers of the OSI model.

Network Testing / Introduction to network testing

Network Testing
>Introduction to network testing
9.2.1 This page will give students an overview of how to test a network.
Basic testing of a network should proceed in sequence from one OSI reference model layer to the next. Begin with Layer 1 and work up to Layer 7, if necessary. At Layer 1, look for simple problems such as power cords plugged in the wall and other physical connections. 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 lesson focuses on network operations at a specific layer of the OSI model. At Layer 3, the commands telnet and ping are used to test the network.
The next page will discuss the troubleshooting process.

Observing multiple paths to destination

Observing multiple paths to destination 
9.1.9 Multi-path algorithms permit traffic over multiple lines, provide better throughput, and are more reliable than single path algorithms.
IGRP supports unequal cost path load balancing, which is known as variance. The variance command instructs the router to include routes with a metric less than n times the minimum metric route for that destination, where n is the number specified by the variance command. The variable n can take a value between 1 and 128, with the default being 1, which means equal cost load balancing.
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 shows the output from show ip route from rt1 before the variance is configured. FastEthernet 0/0 is the only route to 192.168.30.0. This route has an Administrative Distance of 100 and a metric of 8986.
Figure shows the output from show ip route from rt1 after the variance is configured. The preferred route is interface FastEthernet 0/0, but Serial 0/0 will also be used. After the variance command is executed, IGRP will use load balancing between the two links. 
This page concludes this lesson. The next lesson will discuss network testing. The lesson begins with an overview.