Network Troubleshooting Processes

00:00

ladies and gentlemen, look at us. We've made it to the last module of our network. Plus course, we're on module seven, which is network troubleshooting and tools.

00:11

In this chapter, we're going to talk about the process of troubleshooting how we move through the various steps. That way we can isolate the problem, get to the root cause and ideally, correct the problem to get back up and running.

00:22

We have a set of hardware tools and we have a set of software tools at our disposal, and frequently we need both of them to troubleshoot issues.

00:30

We also have command line tools, which are software based tools, but you will be expected to know some things like trace route and path pain that we run from the command line.

00:40

Last but not least, we will talk about cable issues and all the things that can impact cable and the signal that Travers is it.

00:47

We're going to start off by talking about the troubleshooting process

00:51

anytime. Comp t I A. Lays out a process or a set of steps. You want to make sure that you have this memorized because it's likely to come up

00:58

and especially huge part of a network technician job is simply troubleshooting and figuring out why we don't have connectivity.

01:06

The very first step is to figure out what's going on. What is the problem itself?

01:11

Don't jump right into the solution. Figure out what the problem is. Gather information. Talk with the user, individual or group that reported the problem. Find out what's going on.

01:21

One of the questions I'd love to ask is, When was the last time it functioned properly?

01:26

What happened? What's it doing now?

01:29

Something along the way has changed. And if a user can say, Oh, yeah, it was running great until we ran this patch. That lets me know that the patch is probably the problem. So we start by gathering information.

01:40

If I can duplicate the problem, I want to. If I can cause the problem, then that will give me an indication of maybe what the sources. But it can also let me see exactly what the user is seen.

01:51

What error message did you get? I can't remember.

01:53

That doesn't help me much, so if I can recreate the problem, I can see the message for myself and the behavior of the system

02:01

identify your symptoms or those things that are not operating as they should

02:06

again figure what's changed because something has. It was working yesterday. It's not today. What's going on?

02:13

Another point that I think is really good is if you have multiple problems, is to fix one problem at a time.

02:19

We want to be able to say, Okay, here was the first problem. Step one. Step two, Step three

02:24

That corrected problem one that we did these steps for problem, too.

02:29

We want to be able to pass along our knowledge and our experience to the next technician that's going to run into that same issue

02:36

after the problem is identified. We take that information, think it over and look at what we see is the problem and what we change to figure out a theory,

02:45

we start to say, Okay, well, maybe this patch was the problem. Or maybe the modification of the DNS address has caused this connectivity issue.

02:53

Question the obvious. There's something called Occam's razor, which states, if all things are equal, it's as likely to be the easiest solution as anything else. Never be too proud,

03:02

is it plugged in? Is it turned on

03:06

and not it just is it plugged in? But is it plugged in securely on both ends? Sometimes things get moved around. Connections get disconnected a little bit.

03:15

What are the indications? Are all the lights flashing? Do I hear the same noises that I hear when this system normally boots up?

03:23

We can think about troubleshooting from the top down or at the bottom of the overseas I model.

03:29

Let's think about that a little bit

03:30

from the top down the very top layer of the OSI model's applications.

03:35

Let's see. Can I use http to connect to a Web server?

03:38

If not, what's likely to be the next issue?

03:42

Can I get DNS resolution?

03:44

Can I DNS or Ping the name of the server

03:46

continue going down the OSC model like that?

03:50

I can start at the bottom and I can say Okay, can you ping the I p address of a host? That's local? Okay, well, my network card to my cable is okay.

03:58

Can I ping the interface of the router? Okay, well, the riders on my network can I ping the remote interviews to the router. Can I ping a remote host?

04:06

We're kind of walking back up the OSI model

04:10

for me. I like to start at the bottom and work up. That just feels like a more efficient way for me. But people have their own preferences.

04:17

Once we have a theory, test it. I can ping a server by I p address. I cannot connect to that server with http and I cannot pick up my name. So my theory is the DNS services either not working or it's mis configured.

04:31

I might configure a different DNS server to use on that client and see if it can access the site without using the traditional DNS server.

04:39

So that's going to tell me how your theory was right? It was a problem with DNS. Or maybe it's not on the right network, So I'm going to do an I P con fig.

04:48

I see it's got a 169.254 address that tells me how Maybe you're a D H. C P server is down.

04:56

Once we get the theory, we test it out.