Steps for Network Troubleshooting

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