network until the possible cause of the problem is
found. It is a requirement to document each conclusion and
possibility. The challenge is to determine which devices to
start with. In many cases, problems within the first four
layers can be determined by entering a ping or
traceroute command. If the connection is successful,
then the cause is likely at the application level. Otherwise, a
closer look at the lower levels will be needed to locate the
problem. Verify that Internet control message protocol (ICMP)
echo request and echo reply are enabled on the network in order
for commands such as ping and traceroute to
work. This action should include authorization from the network
administrator and documentation of that authorization. If
ping has been disabled on the network, it is a result of
the implementation of policy. Document in a station log or your
personal work log that ping, or any command that was
initially disabled, was enabled for network testing and
subsequently disabled. This is important should there be an
unauthorized intrustion into the network while you are
troubleshooting the network. If disabled, the failure of a
ping or traceroute command can easily be mistaken
for a loss of connectivity.
Content 2.2
Troubleshooting Approaches 2.2.3 Top-down
When applying a top-down approach towards troubleshooting a
networking problem, the end user application is examined first.
Then work down from the upper-layers of the OSI model until the
cause of the problem has been identified. When a troubleshooter
selects this approach, the applications of an end system are
tested before tackling the more specific networking pieces. A
troubleshooter would most likely select this approach for
simpler problems or when the troubleshooter thinks that the
problem is with a piece of software. The disadvantage to
selecting this approach is that it requires checking of every
network application until the possible cause of the problem is
found. It is a requirement to document each conclusion and
possibility. Like the bottom-up approach, the challenge is to
determine which application to start with.
Content
2.2 Troubleshooting Approaches 2.2.4
Divide and conquer When the divide and conquer approach
is applied towards troubleshooting a networking problem, a
layer is selected and tested in both directions from the
starting layer. The divide and conquer approach is initiated at
a particular layer. The layer is based on troubleshooter
experience level and the symptoms gathered about the problem.
Once the direction of the problem is identified,
troubleshooting follows that direction until the cause of the
problem is identified. If it can be verified that a layer is
functioning, it is typically a safe assumption that the layers
below it are functioning as well. If a layer is not functioning
properly, gather symptoms of the problem at that layer and work
downward to lower layers.
Content 2.2
Troubleshooting Approaches 2.2.5 Guidelines for
selecting and approach When selecting an effective
troubleshooting approach to solve a network problem, the
problem is usually resolved in a quicker, more cost-effective
manner. Consider the following when selecting an effective
troubleshooting approach. Determine the scope of the
problem
A troubleshooting approach is often selected
based on its complexity. A bottom-up approach typically works
better for complex problems. Using a bottom-up approach for a
simple problem may be overkill and inefficient. Typically, if
symptoms come from users then a top-down approach is used. If
symptoms come from the network, a bottom-up approach will
likely be more effective. Apply previous experiences
If a particular problem has been experienced previously,
then the troubleshooter may know of a way to shorten the
troubleshooting process. A less experienced troubleshooter will
likely implement a bottom-up approach, while a skilled
troubleshooter may be able to jump into a problem at a
different layer using the divide and conquer approach.
Analyze the symptoms
The more known about a problem,
the better the chance that it can be solved. It may be possible
to immediately correct a problem simply by analyzing the
symptoms. Example
Two IP routers have been
identified in a network that have connectivity, but are not
exchanging routing information. Before attempting to solve the
problem, a troubleshooting approach needs to be selected.
Similar symptoms have been seen previously, which point to a
likely protocol issue. Since there is connectivity between the
routers, it is not likely to be a problem at the physical or
data link layer. Based on this past experience knowledge, it is
decided to use the divide and conquer approach, and the
troubleshooter begins testing the TCP/IP-related functions at
the network layer.
Content 2.3 Gathering
Symptoms 2.3.1 Gathering symptoms for a network
problem Following are the stages for gathering symptoms for
a network problem:Stage 1
The troubleshooter
analyzes symptoms gathered from the trouble ticket, users, or
end systems affected by the problem to form a definition of the
problem. Stage 2
If the problem is in the
troubleshooter’s system, it will be necessary to move on to
stage 3. If the problem is outside the boundary of the
troubleshooter’s control, it will be necessary to contact an
administrator for the external system before gathering
additional network symptoms. Stage 3
The
troubleshooter determines if the problem is at the core,
distribution or access layer of the network. At the identified
layer use an analysis of existing symptoms and knowledge of the
network topology to determine which piece or pieces of
equipment are the most likely cause. Stage 4
Using a
layered troubleshooting approach, the troubleshooter gathers
hardware and software symptoms from the suspect devices. The
technician starts with the most likely possibility and uses
knowledge and experience to determine if the problem is more
likely a hardware or software configuration problem. Stage
5
Document any hardware or software symptoms. If the
problem can be solved using the documented symptoms, a
troubleshooter will solve the problem and document the
solution. If the problem cannot be solved, the technician
begins the isolating phase of the general troubleshooting
process. Be prudent with use of the debug command on a network.
It generates enough console message traffic that the
performance of a network device can be noticeably affected. Be
sure to disable debugging when its capabilities are no longer
needed.
Content 2.3 Gathering
Symptoms 2.3.2 Gathering symptoms from an
end-user: hardware When gathering symptoms for perceived
hardware problems, a troubleshooter should physically inspect
or ask for physical inspection of the devices using the senses
of hearing, sight, smell, and touch. Physical symptoms may be
related, but not limited, to the following:
- Electromagnetic Interference (EMI) from radio and
television transmitters, or the introduction of portable
devices that create EMI to the area
- Indicator lights
of a NIC or networking device
- Cable connections, the
crimping of connectors and the physical state of connection
sockets
- Incorrect seating of modules and cards
- Burning smells from insulative material which has melted,
or of burnt out components
- Overheating due to cooling
fan malfunction
Content 2.3
Gathering Symptoms 2.3.3 Gathering symptoms
from an end-user: software When gathering symptoms for
probable software configuration problems, a troubleshooter
should start at the last known point where the network
functioned correctly. If an end-user station can successfully
ping the gateway but not the DNS server on another network
segment, then an entire set of potential problems associated