the network core, modifying the bandwidth parameter in a routing protocol could also cause a router to favor alternate routes over the local link, resulting in suboptimal network performance. Other misconfigurations which are directly related to the physical layer are:

Serial links re-configured as asynchronous instead of synchronous
Incorrect clock rate
Incorrect clock source
Interface shutdown

Switchport duplex configuration mismatches can cause collisions or port shutdown to occur. Although the current state of auto-negotiation can often negate this type of problem, at least one of the attached devices needs to be capable of link speed and duplex negotiation.

Content 3.4 Identifying Physical Layer Problems 3.4.8 CPU overload The following list describes common symptoms of high CPU utilization. If any of these symptoms are noticed, follow the troubleshooting steps below to alleviate the problem.

High percentages in the show processes cpu command output
Input queue drops
Slow performance
Services on the router fail to respond, for instance:

Slow response in Telnet or unable to telnet to the router
Slow or no response to ping
Router does not send routing updates

The output of a show processes cpu command from a Cisco device, can be used by Output Interpreter to display potential issues and fixes. The show processes cpu command can be used to check if CPU utilization is high due to interrupts. If it is not, check which process is loading the CPU. The main cause of CPU interrupts is the fast switching of traffic. Interrupts are also generated any time a character is output from the console or auxiliary ports of a router. However, Universal Asynchronous Receiver/Transmitters (UARTs) are slow, compared to the processing speed of the router, so it is not likely that console or auxiliary interrupts can cause a high CPU utilization on the router. There are several reasons for high CPU utilization due to interrupts:

Voice ports are configured on the router, even if there is no traffic, software continues to monitor channel associated signaling (CAS).
There are active Asynchronous Transfer Mode (ATM) interfaces on the router, the ATM interfaces continually send out null cells (per ATM standards) and continue to use CPU resources.
An inappropriate switching path is configured on the router.
The CPU is performing memory alignment corrections, if %ALIGN-3-CORRECT messages are logged, then the high CPU utilization is caused by memory alignment corrections, which indicates that bugs in the version of the Cisco IOS used.

If the router is overloaded with traffic, the show interfaces and show interfaces switching commands provide information about which interfaces are overloaded. Output of the show interfaces command can be used to examine the load and number of throttles on interfaces. Throttles are a good indication of an overloaded router. They show the number of times the receiver on the port has been disabled, possibly due to buffer or processor overload. Together with high CPU utilization on an interrupt level, throttles indicate that the router is overloaded with traffic. Output from the show interfaces switching command can be used to see what kind of traffic, protocol, and switching path, is going through the overloaded interface. If some interfaces are too overloaded with traffic, consider redesigning the traffic flow in the network or upgrading the hardware. A single device may be generating packets at an extremely high rate and overloading the router. In this case the Media Access Control (MAC) address of that device can be isolated by adding the ip accounting mac-address {input|output} interface configuration command to the configuration of the overloaded interface. The show interfaces [type number] mac-accounting or show interfaces mac commands display the collected information. Once the source device's MAC address is found, the corresponding IP address can be found by checking the output of the show arp privileged exec command. A last possibility is that there might be a bug in the Cisco IOS Software version running on the device. Once all the previous steps in this list have been performed, check the Bug Navigator, registered customers only, for a bug that reports similar symptoms in a similar environment.

Content 3.5 Isolating Physical Layer Problems 3.5.1 Methodology To isolate networking problems that occur at the physical layer an effective and systematic technique must be used to reach a successful outcome. To isolate problems at the physical layers do the following:

Check for bad cables or connections.
Verify that the cable from the source interface is properly connected and is in good condition. When doubting the integrity of a cable, swap suspect cables with a known working cable.
If in doubt that the connection is good, remove the cable, do a physical inspection of both the cable and the interface, and then reseat the cable. Use a cable tester with suspect wall jacks to ensure that the jack is properly wired. A glowing link light will also be an indicator of a successful connection.
Check that the correct cabling standard is adhered to throughout the network.
Verify that the proper cable is being used. A crossover cable may be required for direct connections between some devices.
Ensure the cable is correctly wired.
Check to make sure that all cables are connected to their correct ports or interfaces. Make sure that any cross-connects are properly patched to the correct location.
Verify proper interface configurations.
Check that all switch or hub ports are set in the correct VLAN or collision domain, and that Spanning Tree, speed, and duplex settings are correctly configured. Confirm that any active ports or interfaces are not shut down.
Check operational statistics and data error rates.
Use Cisco show commands to check for statistics such as collisions, input, and output errors. The characteristics of these statistics will vary depending on the protocols used on the network.

Content 3.5 Isolating Physical Layer Problems 3.5.2 Tools for the job There are two primary categories of physical layer analyzer products.

Cable testers
Handheld network testers (hybrid)

Other common tools that are used for trouble shooting at OSI Layers 2 to 7 are Protocol Analyzer and Network Management Tools. Cable testers are used as much for maintenance as they are for new installations. Handheld network analyzers were created to bridge the skills gap between the senior network support staff and the Help Desk staff. They generally include the most commonly used features from the other testing tool categories, but do not eliminate the need for these other categories. The focus is to validate or troubleshoot end-to-end connectivity up through OSI Layer 3. In the interest of restoring network service as quickly as possible, this category is best used as a first-in tool when a problem is reported. While they are often able to help locate and eliminate the source of a network problem, they can be just as effective in quickly eliminating many possible sources of the problem so that the other tools and staff may be deployed more effectively.

Content 3.5 Isolating Physical Layer Problems 3.5.3 Bad cabling Before troubleshooting a failing cable, verify the tester configuration. This step is critical to obtaining accurate test results, as testers capable of Category 5e and higher performance utilize a wide selection of cable interface adapters and may have somewhat complicated test configurations. At a minimum, verify that the correct test specification and