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