and welcome back not every Journey to
the world of troubleshooting ends the
same way some things are easier to
troubleshoot than others and also if you
and I've been working on like one large
Network we know it like the back of our
hand it's a lot easier to troubleshoot
because we know what the subnets are and
the interfaces involved where on the
other hand if we go to a brand new
network or we're doing consulting it may
take some warm-up time to get used to
and to figure out where everything is on
that specific customers Network and when
we're doing troubleshooting again
whether it's our own network that we
know really well or it's a new Network
that we were just introduced to if we
have a certain process or methodology
for troubleshooting we can apply that
methodology across the board so let's
have some fun with this we'll put an
overview of the high level steps
regarding a troubleshooting methodology
and then as we proceed together we'll
actually apply those steps as we
troubleshoot together a network so the
very beginning of this troubleshooting
process it would be to identify the
problem case in point let's imagine that
the user who's sitting at this computer
right here pc10 calls the service desk
or the help desk or whatever they're
calling it in your organization and they
say yeah I've got a problem and then the
service desk says okay tell me more and
if the user says well I can't really
tell you anything well we have to kind
of you know narrow down what the problem
is or at least get what the symptoms are
and that's why one of the very first
steps is to identify the problems so
with the identification of the problem
the user may say I can't access the
internet or they may just say the
network is down at which point we would
ask some additional questions so let's
imagine this user says that I can't
access anything on the internet that
would fall into this category of
identifying the problem is that this
user who normally can access the
internet can no longer access the
internet the Second Step would be to
establish a theory Regarding why that
might be happening and so by leveraging
a topology like this we could ask
ourselves a few questions for example is
this computer powered on uh if the
computer is powered on does it have an
IP address and if it's a DHCP client did
it get the right information regarding a
default gateway and the subnet and all
that good stuff and then regarding this
port is this port on the switch is it
associated with the right VLAN which is
VLAN 10 and regarding the the trunking
that's going down from the axxis layer
switch to the core is trunking working
and is VLAN 10 being allowed and then
from the default gateways perspective
regarding VLAN 10 Who's acting is the
default gateway is it Core 1 or Core 2
or are they using a first toop
redundancy protocol and if so which one
of these two devices is acting as the
active device and does that device
acting as the default gateway have a
route out towards the internet in simple
terms does it know how to forward and
the same thing would hold true for this
router and then this connectivity to our
service provider and also because we're
us rfc1918
addresses perhaps Network address
translation is failing or isn't
implemented correctly so if this user a
pc10 by doing a few tests we verify that
it can ping its default gateway and if
this device in vant up here at
headquarters can ping devices out here
at site 2 and site 3 and has
reachability there that can help
identify what is working and then we
could establish a theory about what may
be specifically causing the problem and
then once we've narrowed it down to what
we think it might be and then the third
step is to test which is to basically go
in and prove your theory if we think the
problem is with router one or if we
think the problem was with the
multi-layer switch or we think the
problem was with the axis layer we want
to do some testing to validate that what
we think may be the problem really is
causing the problem and then once we've
narrowed it down and verified it we then
want to go ahead and solve the problem
now solving the problem uh in an
organization also has many steps
involved with it let's list a few of
those as far as the solution to this
network connectivity problem that the
user is having out to the internet and
let's also imagine based on our testing
that we believe it's an issue with
address translation which could be natat
or Pat but definitely needs to happen at
some point before that traffic goes out
to the Internet so if we've done some
testing and we've narrowed it down that
it is an address translation issue
regarding solving that we' want to
create a game plan on exactly how we are
going to solve that problem perhaps with
network address translation the N device
was set up to support vlen 20 with the
10120 subnet and other networks like
this over here at site 2 and site three
but maybe perhaps not including the
10.10 subnet so we want to make a plan
to correct that and also in corporations
that's going to involve going through
Change Control if we're going to make a
configuration change and then with the
authorization from the Change Control
Board then we're going to go ahead and
implement the change and then when we've
implemented it we also want to verify
that it's working and that verification
would involve a few things number one
that we now have connectivity from this
PC out to the internet also we'd want to
verify that we didn't make any other
changes that would negatively impact our
environment like we want to make sure
everything else still functions as well
v20 and the other sites everything can
still forward out to the internet and
then we'd also want to make sure we
document the solution what we did how we
did it and if we changed the topology in
some fashion we'd want to include that
update in our documentation so the
documentation of what was done and also
the topology if there's been updates
that's super important because let's say
3 or four days go by and we have yet
another problem and we think oh I wonder
if what we changed here injected
additional problems into the network so
we could go back through our paper trail
and identify what happened when it
happened what was changed and that can
help speed up our troubleshooting
because a lot of times uh there are
cabling issues and physical issues and
so forth but a lot of times when
something breaks on the network when
something stops working it's quite often
due to the last change that was made and
so if we go back and take a look at the
last change or two that can help us
reduce our troubleshooting Time by
either confirming that what was done is
not impacting our current problem or by
verifying that what was done indeed is
impacting our current Network and then
the last step here is to go ahead and
repeat this process for the next
problem so the next servers call that
comes in the next issue the next problem
again we're going to follow this logical
plan so what I think would be fun to do
is let's take this network topology
which we've been playing on and off with
throughout these videos and what I'll do
is I will inject a problem somewhere in
this mix and then we can go through
these steps one at a time in this
troubleshooting methodology and as we do
so we'll go into more details on each
one so in the very next video join me as
we take a look at this first stage in
the troubleshooting methodology and that
is identifying the problem which we'll
do in this network topology so I'll see
you in that video in just a moment hey
thanks for watching And subscribe right
here to get the latest information from
CBT Nuggets and if you're new to or
considering a career in the world of it
head on over to CBT Nuggets and sign up
for a free trial