Network Troubleshooting Methodology

Lesson overview.
In this lesson, we will cover:

● The importance of a methodology.

● Seven-step troubleshooting methodology.

The importance of a methodology.

“My methodology is not knowing what I’m doing and making that work for me.”

– Stone Gossard

All networks will require troubleshooting. If you don’t know where to start or haven’t developed a
methodology, you will waste time and resources. The complexity of modern networks means
that there is a lot that can go wrong. Without a troubleshooting methodology, the frustration
levels—of technicians and those they support—is going to rise.

A systematic troubleshooting methodology can significantly reduce the time required to resolve
a problem and close a network trouble ticket—saving both time and other resources.

Seven-step troubleshooting methodology.

Step one: identify the problem.
Step one is to identify the problem. This step involves gathering information to learn what is
actually occurring or not occurring and where (e.g., is the problem extremely local, as in
relegated to the network, or is the problem occurring outside an organization’s control).

When identifying the symptoms, it is important for any technician to remember that the
symptoms are not the problem, they just point toward the underlying issue. Most often, when a
trouble ticket comes in, it will have some of the symptoms, but it will not have identified the
actual problem.

Multiple problems should be approached individually and handled one at a time. When a
technician questions the users, it should be done both politely and firmly. Many problems that
are reported within a network are the result of an end user needing to be educated, or re-
educated, in proper procedures. At the same time, technicians must remember that most end
users do not have their level of technical knowledge, so it is wise to be patient and not
patronizing. Determining if anything has changed will often help in identifying the problem. This
requires a systematic and thorough approach.

Highlights:
● Gather information. Determine what is actually occurring and where it is occurring.
 ● Identify symptoms and remember, the symptoms are not the problem; they just point
toward the underlying issue.
● Approach multiple problems individually.
● Question the users in a polite and firm manner but do not patronize.
● Determine if anything has changed; use a systematic approach and be thorough.

Step two: establish a theory of probable cause.

Step two in the troubleshooting methodology is to establish a theory of probable cause. The
technician should make a list of all of the possible causes of the problem. To develop this list of
possible causes, he or she should consider multiple approaches to the problem, from bottom to
top and then from top to bottom of the OSI model. That is a great way to approach a problem
from multiple directions.

The list of possible causes should then be divided into three ranked sections. They should be
"not likely," "likely," and "most likely." This will provide a great place to start. When establishing
a theory of probable cause, technicians should remember to question the obvious. If the
network printer doesn't work, the first step should be to make sure that it is turned on.

Highlights:
● Make a list of all of the possible causes of the problem.
● Divide the list into three ranked sections of: not likely, likely, and most likely.
● Remember to question the obvious.

Step three: test the theory of probable cause.

The third step is to test the theory of probable cause. If the theory is confirmed, the technician
should move on to the next step. If the theory is proven to be incorrect, then it will be necessary
to reestablish a new theory of probable cause. If all probable causes are tested and eliminated,
or the situation worsens, it may be time to escalate the issue up the troubleshooting chain.

Highlights:
● If the theory is confirmed, move on to the next step.
● If the theory is proven to be incorrect, reestablish a new theory of probable cause.
● If all probable causes are eliminated, or the situation worsens, escalate the issue up the
troubleshooting chain.

Step four: establish a plan of action and identify potential effects.

Once a technician has confirmed a theory of probable cause, the next step is to establish a plan
of action and identify potential effects. A simple problem may require a simple plan, such as, if
the network printer doesn't work, and the probable cause is that it's not turned on, turn on the
network printer. More complex problems will require more complex plans. In some cases, it is a
good idea for a technician to write the plan out step by step in order to determine the best
course of action. This plan should also identify any possible repercussions that the resolution to
the problem may introduce into the network.

Highlights:
● Simple problems may require simple plans.
 ● More complex problems will require more complex plans.
● It is sometimes a good idea to write the plan out step by step in order to determine the
best course of action and identify any possible repercussions.

Step five: implement the plan or escalate.

Step five is to implement the plan or to escalate the problem. If a technician has the authority,
he or she can put the plan into action. If not, the technician should escalate the problem—along
with all of the facts and determinations—up the troubleshooting chain. This is done so that the
next level above the technician does not have to recreate everything that has already been
done.

Highlights:
● If the technician has the authority, he or she can put the plan into action.
● If the technician does not have the authority, the problem should be escalated up the
troubleshooting chain.

Step six: verify full system functionality.

Once the plan has been implemented, step six is to verify full system functionality. Technicians
should not just verify that the original problem has gone away. Sometimes a fix will introduce a
new issue into the system. If a new issue has occurred, it's time to go back to step one, or to
escalate the problem. If a technician has verified full system functionality, it is time to implement
any appropriate preventative measures that could keep the problem from reoccurring.

Highlights:
● Sometimes, a fix will introduce a new issue, so test for full system functionality.
● If a new issue has occurred, it is time to go back to step one or escalate the problem.
● If applicable, implement preventative measures at this step.

Step seven: document findings, actions, and outcomes.

Step seven is to document findings, actions, and outcomes. This will save time if and when the
problem reoccurs. A technician’s documentation may lead to new best practices for an
organization. It's important to document any missteps as well to keep the next technician from
making those same missteps.

Highlights:
● It is important for technicians to document everything when troubleshooting.
● The documentation may lead to new best practices for an organization.
● Documenting missteps is also important; it will keep the next technician from making the
same missteps.

What was covered.

The importance of a methodology.
Problems will occur in every network. A well developed troubleshooting methodology will reduce
the time it takes to recover and will reduce frustration levels.
Seven-step troubleshooting methodology.
The steps are: identify the problem, establish a theory of probable cause, test the theory,
establish a plan (including any effects of the plan), implement the plan, verify full system
functionality, and—as a final step—document everything.