when you're troubleshooting complex
network problems you may find that the
resolution is not as obvious as you
might hope in this video we're gonna
step through a methodology that should
help you troubleshoot any problem you
run into this is the flow chart of that
network troubleshooting methodology and
we're going to step through each section
of this flow and describe how it can
help you solve those really difficult
problems the first thing you want to do
is identify the problem this may not be
as straightforward as you might think we
first need to collect as much
information as possible about the issue
that's occurring in the best possible
scenario you'll be able to duplicate
this problem on demand this will help
later as we go through a number of
testing phases to make sure that we're
able to resolve this issue when a
problem happens on the network it
usually affects more than one device and
sometimes it affects those devices in
different ways you want to be sure to
document all of the symptoms that may be
occurring even if they are very
different between different devices you
may find that a single problem is
causing all of these different systems
across these different devices many
times these issues will be identified by
the end users so they may be able to
provide you with a lot more detail of
what's really happening you should
question your users to find out what
they're seeing and if any error messages
are appearing in this course we've
already discussed the importance of the
change control process and knowing
exactly what is changing in your
environment without some type of formal
change control process someone may be
able to make an unscheduled change that
would affect many different people so
when an error or network problem occurs
you may want to find out what was the
last thing that changed on this network
that could have affected all of these
users there's also going to be times
when you're examining a number of
different problems that may not actually
be related to each other it's always
best to separate all of these different
issues out so that you can approach and
try to resolve each issue individually
now that you've collected as much
information as possible
you can examine all of these details to
begin establishing a theory of what you
think might be going wrong since the
simpler explanation is often the most
likely reason
for the issue that may be a good place
to start but of course you'll want to
consider every possible thing that might
be causing this issue maybe start with
things that aren't completely obvious
you could start from the top of the OSI
model with the way the application is
working and work your way to the bottom
or you may want to start with the bottom
with the cabling and wiring in your
infrastructure and work your way up from
there you'll want to list out every
possible cause for this problem your
list might start with the easy theories
at the top but of course include all of
the more complex theories in this list
as well now that we have a list of
theories on how to resolve this issue we
can now test those theories we may want
to go into a lab and if we are able to
recreate this problem in the lab then we
can apply each theory until we find the
one that happens to resolve the issue if
you tried the first theory you may want
to reset everything and try the second
theory or the third and if you run out
of theories you may want to go back and
think of other things that might be
causing this problem this might be a
good time to bring in an expert who
knows about the application or the
infrastructure and they can give some
theories and possible resolutions to
test in the lab once you've tested a
theory and found that the theory is
going to resolve this issue you can then
begin putting together a plan of action
this is how you would implement this fix
into a production network you want to be
sure that you're able to do this with a
minimum amount of impact to the
production network and sometimes you
have to do this after-hours when nobody
else is working on the network you want
to be able to implement this with a
minimum amount of impact to production
traffic so often you'll have to do this
after hours my best practice is to
document the exact steps that will be
required to solve this particular
problem if it's replacing a cable then
the process will be relatively
straightforward but if you're upgrading
software in a switch a router or a
firewall there may be additional tasks
involved in performing this plan of
action you'll also want some
alternatives if your plan doesn't go as
designed for example you may run into
problems when upgrading the software in
a firewall so you may need an additional
firewall or a way to roll back to the
previous version
now that you
documented your plan of action you can
take that to your change control team
and they can give you a window when you
can implement that change the actual
fixing of the issue is probably going to
be during off-hours during non
production times and you may need to
bring in other people to assist
especially if your window is very small
once you have executed on your plan of
action your job isn't done yet
we need to make sure that all of these
changes actually resolve the problem so
now that the changes have been
implemented we now need to perform some
tests we may want to bring in the end
users who first experienced this problem
so that they can run through exactly the
same scenario to tell you if the problem
is resolved or if the problem still
exists this might also be a good time to
implement some preventive measures that
way we can either be informed that the
problem is occurring or we can provide
alternatives that we can implement if
that problem happens again after the
problem has been resolved this is a
perfect time to document the entire
process from the very beginning to the
very end you'll of course want to
provide as much information as possible
so if somebody runs into this issue
again they can simply search your
knowledgebase find that particular error
that popped up and know exactly the
process you use to solve this last time
many organizations have a help desk with
case notes that they can reference or
you might have a separate knowledgebase
or wiki that you create where you're
storing all of this important
information for the future a document
that was created a number of years ago
but still shows the importance of
keeping this documentation over time is
from Google research where they
documented the failure trends in a large
disk drive population and because they
were keeping extensive data over a long
period of time they were able to tell
when a drive was starting to fail based
on the types of errors that they were
receiving being able to store all of
this important information and being
able to go back in time to see what
happened becomes a very important part
of maintaining a network for the future
let's summarize this troubleshooting
methodology we start with gathering as
much information as possible asking
users about what they're seeing and
documenting any specific error messages
then we want to be able to create a
number of
series that might solve this particular
problem and once we have this list we
want to be able to put it in the lab and
try testing each one of these theories
until we find the one that actually
resolves the issue from there we can
create a plan of action and document any
possible problems that might occur we
can then get a time to implement the
issue and put it into our production
environment and then we can verify and
test and make sure that the entire
system is now working as expected and of
course finally we want to document
everything that we did from the very
beginning of our troubleshooting process
all the way through to the end
you