0:00:00.120,0:00:02.560
and welcome back not every Journey to

0:00:02.560,0:00:04.279
the world of troubleshooting ends the

0:00:04.279,0:00:05.960
same way some things are easier to

0:00:05.960,0:00:07.799
troubleshoot than others and also if you

0:00:07.799,0:00:09.719
and I've been working on like one large

0:00:09.719,0:00:11.240
Network we know it like the back of our

0:00:11.240,0:00:13.440
hand it's a lot easier to troubleshoot

0:00:13.440,0:00:14.839
because we know what the subnets are and

0:00:14.839,0:00:16.800
the interfaces involved where on the

0:00:16.800,0:00:17.920
other hand if we go to a brand new

0:00:17.920,0:00:19.920
network or we're doing consulting it may

0:00:19.920,0:00:21.960
take some warm-up time to get used to

0:00:21.960,0:00:24.000
and to figure out where everything is on

0:00:24.000,0:00:26.000
that specific customers Network and when

0:00:26.000,0:00:27.279
we're doing troubleshooting again

0:00:27.279,0:00:28.599
whether it's our own network that we

0:00:28.599,0:00:30.240
know really well or it's a new Network

0:00:30.240,0:00:31.759
that we were just introduced to if we

0:00:31.759,0:00:33.520
have a certain process or methodology

0:00:33.520,0:00:35.360
for troubleshooting we can apply that

0:00:35.360,0:00:37.760
methodology across the board so let's

0:00:37.760,0:00:38.840
have some fun with this we'll put an

0:00:38.840,0:00:40.160
overview of the high level steps

0:00:40.160,0:00:41.960
regarding a troubleshooting methodology

0:00:41.960,0:00:43.800
and then as we proceed together we'll

0:00:43.800,0:00:45.680
actually apply those steps as we

0:00:45.680,0:00:48.039
troubleshoot together a network so the

0:00:48.039,0:00:49.360
very beginning of this troubleshooting

0:00:49.360,0:00:51.920
process it would be to identify the

0:00:51.920,0:00:53.719
problem case in point let's imagine that

0:00:53.719,0:00:55.320
the user who's sitting at this computer

0:00:55.320,0:00:57.559
right here pc10 calls the service desk

0:00:57.559,0:00:58.640
or the help desk or whatever they're

0:00:58.640,0:01:00.359
calling it in your organization and they

0:01:00.359,0:01:02.440
say yeah I've got a problem and then the

0:01:02.440,0:01:04.439
service desk says okay tell me more and

0:01:04.439,0:01:05.799
if the user says well I can't really

0:01:05.799,0:01:08.360
tell you anything well we have to kind

0:01:08.360,0:01:10.240
of you know narrow down what the problem

0:01:10.240,0:01:12.080
is or at least get what the symptoms are

0:01:12.080,0:01:13.200
and that's why one of the very first

0:01:13.200,0:01:14.920
steps is to identify the problems so

0:01:14.920,0:01:16.240
with the identification of the problem

0:01:16.240,0:01:18.280
the user may say I can't access the

0:01:18.280,0:01:19.560
internet or they may just say the

0:01:19.560,0:01:21.159
network is down at which point we would

0:01:21.159,0:01:23.040
ask some additional questions so let's

0:01:23.040,0:01:24.840
imagine this user says that I can't

0:01:24.840,0:01:26.840
access anything on the internet that

0:01:26.840,0:01:28.200
would fall into this category of

0:01:28.200,0:01:29.479
identifying the problem is that this

0:01:29.479,0:01:31.280
user who normally can access the

0:01:31.280,0:01:32.960
internet can no longer access the

0:01:32.960,0:01:34.880
internet the Second Step would be to

0:01:34.880,0:01:37.280
establish a theory Regarding why that

0:01:37.280,0:01:39.000
might be happening and so by leveraging

0:01:39.000,0:01:41.240
a topology like this we could ask

0:01:41.240,0:01:43.040
ourselves a few questions for example is

0:01:43.040,0:01:45.719
this computer powered on uh if the

0:01:45.719,0:01:47.119
computer is powered on does it have an

0:01:47.119,0:01:49.479
IP address and if it's a DHCP client did

0:01:49.479,0:01:51.079
it get the right information regarding a

0:01:51.079,0:01:52.880
default gateway and the subnet and all

0:01:52.880,0:01:54.880
that good stuff and then regarding this

0:01:54.880,0:01:56.840
port is this port on the switch is it

0:01:56.840,0:01:58.360
associated with the right VLAN which is

0:01:58.360,0:02:00.360
VLAN 10 and regarding the the trunking

0:02:00.360,0:02:01.640
that's going down from the axxis layer

0:02:01.640,0:02:04.079
switch to the core is trunking working

0:02:04.079,0:02:05.960
and is VLAN 10 being allowed and then

0:02:05.960,0:02:07.880
from the default gateways perspective

0:02:07.880,0:02:09.879
regarding VLAN 10 Who's acting is the

0:02:09.879,0:02:11.840
default gateway is it Core 1 or Core 2

0:02:11.840,0:02:13.080
or are they using a first toop

0:02:13.080,0:02:15.000
redundancy protocol and if so which one

0:02:15.000,0:02:16.959
of these two devices is acting as the

0:02:16.959,0:02:18.879
active device and does that device

0:02:18.879,0:02:20.560
acting as the default gateway have a

0:02:20.560,0:02:22.599
route out towards the internet in simple

0:02:22.599,0:02:24.239
terms does it know how to forward and

0:02:24.239,0:02:25.480
the same thing would hold true for this

0:02:25.480,0:02:27.920
router and then this connectivity to our

0:02:27.920,0:02:29.599
service provider and also because we're

0:02:29.599,0:02:31.120
us rfc1918

0:02:31.120,0:02:33.160
addresses perhaps Network address

0:02:33.160,0:02:34.959
translation is failing or isn't

0:02:34.959,0:02:37.000
implemented correctly so if this user a

0:02:37.000,0:02:39.680
pc10 by doing a few tests we verify that

0:02:39.680,0:02:41.640
it can ping its default gateway and if

0:02:41.640,0:02:43.080
this device in vant up here at

0:02:43.080,0:02:45.040
headquarters can ping devices out here

0:02:45.040,0:02:46.480
at site 2 and site 3 and has

0:02:46.480,0:02:48.120
reachability there that can help

0:02:48.120,0:02:50.040
identify what is working and then we

0:02:50.040,0:02:51.480
could establish a theory about what may

0:02:51.480,0:02:53.440
be specifically causing the problem and

0:02:53.440,0:02:54.879
then once we've narrowed it down to what

0:02:54.879,0:02:56.840
we think it might be and then the third

0:02:56.840,0:02:58.879
step is to test which is to basically go

0:02:58.879,0:03:00.680
in and prove your theory if we think the

0:03:00.680,0:03:03.120
problem is with router one or if we

0:03:03.120,0:03:04.120
think the problem was with the

0:03:04.120,0:03:05.519
multi-layer switch or we think the

0:03:05.519,0:03:07.120
problem was with the axis layer we want

0:03:07.120,0:03:09.080
to do some testing to validate that what

0:03:09.080,0:03:10.840
we think may be the problem really is

0:03:10.840,0:03:12.599
causing the problem and then once we've

0:03:12.599,0:03:14.319
narrowed it down and verified it we then

0:03:14.319,0:03:16.760
want to go ahead and solve the problem

0:03:16.760,0:03:19.319
now solving the problem uh in an

0:03:19.319,0:03:21.920
organization also has many steps

0:03:21.920,0:03:23.599
involved with it let's list a few of

0:03:23.599,0:03:25.879
those as far as the solution to this

0:03:25.879,0:03:27.239
network connectivity problem that the

0:03:27.239,0:03:29.239
user is having out to the internet and

0:03:29.239,0:03:31.560
let's also imagine based on our testing

0:03:31.560,0:03:32.879
that we believe it's an issue with

0:03:32.879,0:03:35.239
address translation which could be natat

0:03:35.239,0:03:37.560
or Pat but definitely needs to happen at

0:03:37.560,0:03:39.480
some point before that traffic goes out

0:03:39.480,0:03:41.120
to the Internet so if we've done some

0:03:41.120,0:03:42.400
testing and we've narrowed it down that

0:03:42.400,0:03:44.120
it is an address translation issue

0:03:44.120,0:03:45.959
regarding solving that we' want to

0:03:45.959,0:03:48.720
create a game plan on exactly how we are

0:03:48.720,0:03:50.640
going to solve that problem perhaps with

0:03:50.640,0:03:52.439
network address translation the N device

0:03:52.439,0:03:54.959
was set up to support vlen 20 with the

0:03:54.959,0:03:57.519
10120 subnet and other networks like

0:03:57.519,0:03:59.200
this over here at site 2 and site three

0:03:59.200,0:04:01.200
but maybe perhaps not including the

0:04:01.200,0:04:03.760
10.10 subnet so we want to make a plan

0:04:03.760,0:04:05.720
to correct that and also in corporations

0:04:05.720,0:04:06.879
that's going to involve going through

0:04:06.879,0:04:08.519
Change Control if we're going to make a

0:04:08.519,0:04:10.439
configuration change and then with the

0:04:10.439,0:04:12.079
authorization from the Change Control

0:04:12.079,0:04:13.519
Board then we're going to go ahead and

0:04:13.519,0:04:15.319
implement the change and then when we've

0:04:15.319,0:04:16.880
implemented it we also want to verify

0:04:16.880,0:04:18.560
that it's working and that verification

0:04:18.560,0:04:20.000
would involve a few things number one

0:04:20.000,0:04:21.519
that we now have connectivity from this

0:04:21.519,0:04:24.040
PC out to the internet also we'd want to

0:04:24.040,0:04:26.240
verify that we didn't make any other

0:04:26.240,0:04:28.360
changes that would negatively impact our

0:04:28.360,0:04:29.759
environment like we want to make sure

0:04:29.759,0:04:31.320
everything else still functions as well

0:04:31.320,0:04:33.479
v20 and the other sites everything can

0:04:33.479,0:04:35.000
still forward out to the internet and

0:04:35.000,0:04:36.199
then we'd also want to make sure we

0:04:36.199,0:04:38.960
document the solution what we did how we

0:04:38.960,0:04:41.039
did it and if we changed the topology in

0:04:41.039,0:04:42.880
some fashion we'd want to include that

0:04:42.880,0:04:45.039
update in our documentation so the

0:04:45.039,0:04:46.840
documentation of what was done and also

0:04:46.840,0:04:48.520
the topology if there's been updates

0:04:48.520,0:04:50.600
that's super important because let's say

0:04:50.600,0:04:52.720
3 or four days go by and we have yet

0:04:52.720,0:04:54.720
another problem and we think oh I wonder

0:04:54.720,0:04:57.280
if what we changed here injected

0:04:57.280,0:04:58.919
additional problems into the network so

0:04:58.919,0:05:00.360
we could go back through our paper trail

0:05:00.360,0:05:02.240
and identify what happened when it

0:05:02.240,0:05:03.960
happened what was changed and that can

0:05:03.960,0:05:05.120
help speed up our troubleshooting

0:05:05.120,0:05:07.520
because a lot of times uh there are

0:05:07.520,0:05:09.080
cabling issues and physical issues and

0:05:09.080,0:05:10.880
so forth but a lot of times when

0:05:10.880,0:05:12.560
something breaks on the network when

0:05:12.560,0:05:14.919
something stops working it's quite often

0:05:14.919,0:05:17.520
due to the last change that was made and

0:05:17.520,0:05:18.800
so if we go back and take a look at the

0:05:18.800,0:05:20.520
last change or two that can help us

0:05:20.520,0:05:22.400
reduce our troubleshooting Time by

0:05:22.400,0:05:23.919
either confirming that what was done is

0:05:23.919,0:05:26.360
not impacting our current problem or by

0:05:26.360,0:05:28.759
verifying that what was done indeed is

0:05:28.759,0:05:30.520
impacting our current Network and then

0:05:30.520,0:05:32.880
the last step here is to go ahead and

0:05:32.880,0:05:35.639
repeat this process for the next

0:05:35.639,0:05:37.880
problem so the next servers call that

0:05:37.880,0:05:40.280
comes in the next issue the next problem

0:05:40.280,0:05:41.880
again we're going to follow this logical

0:05:41.880,0:05:43.680
plan so what I think would be fun to do

0:05:43.680,0:05:45.800
is let's take this network topology

0:05:45.800,0:05:47.160
which we've been playing on and off with

0:05:47.160,0:05:48.840
throughout these videos and what I'll do

0:05:48.840,0:05:50.800
is I will inject a problem somewhere in

0:05:50.800,0:05:52.440
this mix and then we can go through

0:05:52.440,0:05:53.880
these steps one at a time in this

0:05:53.880,0:05:55.960
troubleshooting methodology and as we do

0:05:55.960,0:05:57.720
so we'll go into more details on each

0:05:57.720,0:05:59.800
one so in the very next video join me as

0:05:59.800,0:06:01.600
we take a look at this first stage in

0:06:01.600,0:06:03.400
the troubleshooting methodology and that

0:06:03.400,0:06:05.240
is identifying the problem which we'll

0:06:05.240,0:06:07.400
do in this network topology so I'll see

0:06:07.400,0:06:10.000
you in that video in just a moment hey

0:06:10.000,0:06:11.599
thanks for watching And subscribe right

0:06:11.599,0:06:13.440
here to get the latest information from

0:06:13.440,0:06:15.520
CBT Nuggets and if you're new to or

0:06:15.520,0:06:17.440
considering a career in the world of it

0:06:17.440,0:06:19.280
head on over to CBT Nuggets and sign up

0:06:19.280,0:06:22.840
for a free trial