CompTIA Network+ N10-008 – Module 17 – Troubleshooting Networks

1. 17.0 Troubleshooting Networks

One of the most common things that we’re going to be doing as network professionals is troubleshooting. And instead of just looking at a problem and scratching our head and wondering what we should do next, we’re going to be a lot better off if we have a plan of attack ahead of time. We can more confidently approach any network troubleshooting issue by having a set of procedures and walking through those step by step into this module.

We’re going to take a look look at a seven step troubleshooting strategy that CompTIA recommends. We’ll also go out to some live gear and demonstrate a collection of commands that we can give to glean some information from our network devices and consider some common issues that we might be facing with our wired land, our wireless land, and network services. But let’s begin by walking through that seven step troubleshooting strategy in our next video.

2. 17.1 7-Step Troubleshooting Methodology

Let’s take a look at the seven step troubleshooting methodology that CompTIA tells us we should know for the Network Plus exam. And we want to emphasize that there are seven steps to this model that CompTIA gives us. Those steps might be different than what you read in other literature. For example, Cisco. They have a seven step troubleshooting methodology, but it’s a little different than the one CompTIA gives us. Different methods can be similar, but one method might combine multiple steps into one. One method might expand one step into two or three. The wording might be a bit different. Basically, they’re doing the same thing. But of course, for the exam, I want you to memorize the seven steps we’re going to go through in this video. Let’s take a look at step number one, and that is to identify the problem. When it comes to troubleshooting, a critical step is to be able to clearly articulate what’s going on.

What’s the problem? We don’t want to be too general about this. Also, we don’t want to be overly specific about it. We want to come away with a good definition of the problem. And to do that, we not need to start gathering some information. Maybe we need to go to routers or switches and issues some show commands or some debug commands. Maybe we’re using something like wireshark to do a packet capture and analyze. What sorts of packets do we have crossing the network right now? And it’s really good if we can duplicate the problem.

And it can be a bit more challenging to troubleshoot something if we cannot see what is happening. It’s sort of like when you take your car into the mechanic and you say, well, it’s making this noise when I put it in park, or it makes this other noise when I get up to 55 on the highway, but you’re not able to reproduce it in front of the mechanic. And as a result, they have a bit of an issue trying to figure out what is going on. Same thing with network troubleshooting. It’s a lot easier to troubleshoot an issue that we can see and replicate. And we probably want to question the users that have been impacted by whatever’s going on with the network. We might need to try to determine, does this problem happen all of the time? Does it happen just occasionally? Has it happened the last few weeks? Did it just start on a particular day? Has anything changed in the network? That’s a big question. Does it happen every day of the week? Is Monday worse? Does it happen at a certain time of the day? The users can give us a lot of insight into that because they’re the ones actually experiencing the problem over and over again. And we want to identify specific symptoms of the problem.

We don’t want to say the problem is, for example, the Internet is broken. Really? The Internet is broken? The internet is probably not broken. Maybe we have some other issue going on. The symptom might be that this user cannot get to this particular website on Wednesday. That does not mean the Internet is broken. So let’s identify very specific symptoms of the problem and we want to determine if anything has changed. There are a lot of times when something changes in a network and it has unintended consequences. We can ask users, as I mentioned a moment ago, if they know about anything that has changed. But we don’t want to just rely on user input. We might want to check out the network change logs that hopefully the It staff is maintaining. And sometimes when we’re troubleshooting a problem, we might be in the midst of many trouble tickets that are coming in all at once.

This underlying problem might or might not be generated by the same underlying condition. Let’s say, for example, that the help desk is saying we’re getting a flood of trouble tickets coming in, and we wonder if this new trouble ticket coming in is stemming from the same problem that the previous five trouble tickets stemmed from. But here’s the thing I want you to keep in mind. Just because these are all happening at relatively the same time, it doesn’t necessarily mean they have the same underlying cause. They might, but don’t assume that they do because that can lead us astray. We don’t want to draw an incorrect conclusion, possibly by just assuming they all come from the same problem. So it’s a best practice to approach multiple problems or multiple trouble tickets individually.

Let’s take a look at step two now, and that is to establish a theory of a probable cause. What do we think is going on here? And as we’re coming up with this theory, let’s question the obvious. We might say, well, it’s obvious that we have the switch plugged into this wiring clause, that it has power, maybe there was a power outage, maybe somebody knocked it loose with the broom in the wiring closet. And as we’re coming up with a theory and gathering information, there are some different strategic ways of doing this. Here are a few approaches that I would like us to consider. A couple of approaches are based on the OSI model. We can do a top down approach or a bottom up approach.

For example, we could say that I want to start at the application layer and then sort of work my way down through the OSI stack, gathering information along the way. And hopefully I’m going to come up with a good theory of what’s going on as I do that. And remember, the OSI reference model is not a reverence model. We don’t revere it as being something that everything is going to neatly fit into. So sometimes it can be challenging. Okay, now I’m going to test the presentation layer. Sometimes that’s just not practical to do. But up at the application layer. As an example, we might say, well, our email is not working. Then something you could do at the application layer as you start to work your way down is you might want to check the settings of the application.

Are you pointing to the correct email server? Are you using secure SMTP or non secure? Are you giving correct credentials? You could check those settings and if everything looks good, maybe you could work your way down to the transport layer. You want to make sure that you’re communicating with this SMTP server on TCP port 25 and that’s not blocked somehow. So one option is to work your way down like that. Another option is to start at the bottom and work your way up. You could start at the physical layer and say, for example, I want to take a look at the cabling.

Now, we might assume that the cable is not going to just unplug itself or somehow disappear, but it’s often a good idea to start at that physical layer just to make sure things are working and connected as anticipated. And a lot of problems can actually be resolved by unplugging something and plugging it back in by resetting the power on a network device. That cures a lot of issues. And one issue at the physical layer is cabling.

Cabling is not just something that we put in place, and it works forever, necessarily. Personal example I remember I was working with an administrative assistant who kept having problems getting to the Internet. I would say, all right, I’ll come by your office later. And a little bit later, before I got there, they would call back and say, oh, never mind, it’s all good now. But this would happen over a period of weeks. The Internet would stop working. But before I went to their office, they would call me back and say, never mind, it’s all working now.

But this issue kept happening. So eventually I thought, I’m just going to go into their office and test everything because obviously something is not right. I went into their office and I decided to start at the physical air. I was going to check the network cabling, and I noticed that the cable coming from the computer, it ran under one of those chair mats that sit on top of carpet. Those chair mats, they have these very sharp plastic spikes in them to dig into the carpet so it doesn’t slide. And her network cable, it was running the gauntlet of all those spikes underneath the chair mat. And there were several spikes that were actually penetrating the network cable. And also they had rolled their chair back and forth on that chair mat so many times. That cable was very, very flat.

It was in bad shape. That was a physical air issue. And I resolved the issue by simply replacing her network cable. And obviously, I didn’t run it again under the chairman. I found a different way that was a bit more safe for the cable. So you could go top down on this OSI model or bottom up. But personally, my favorite approach, rather than doing top down or bottom up, is to do what I call a divide and conquer approach. You see, we could start sort of in the middle. What we could do as an example is Ping, an IP address that we’re trying to reach. And if I can reach that IP address with the ping, then I know that I’m good on layers one, two, and three.

Because Ping uses the protocol called ICMP. It’s a layer three protocol. So if ping works, I know that I’m good at the physical layer, the data link layer, and the network layer. If ping does not work, I know I need to start my focus on those three layers. But if it does work, I know I need to start my focus on the upper four layers. And that’s my personal preference about how to use the OSI model to do troubleshooting. Now, in step three, what we want to do is to have a theory established, and we want to test our theory and make sure that we’ve properly determined the underlying cause of what’s going on here. Of course, when we test a theory, it could turn out in a couple of different ways. It could be that, hey, our theory is confirmed. And if that’s the case, great. Let’s determine what our next step is going to be. For example, are we going to create a maintenance window to fix whatever is wrong? Is it an emergency that we need to fix right now? Or if the theory turns out not to be correct, we might need to come up with another theory, or it might be a situation where we need to turn the issue over to somebody else within the organization. But once we do have a theory that has proved out, we’re pretty sure we know what’s going on here. In step number four, we’re going to establish a plan of action to resolve the problem and then identify any potential effects. Sure, I can resolve the problem by unplugging the switch, but that’s going to affect maybe 48 users connected to that switch right now. Maybe I don’t want to do that in the middle of a work day.

So let’s think about who else is going to be impacted and how severe the condition is. Does this need to be resolved right now? What is the trade off of user impact versus urgency of the issue? And if we do decide to schedule a time later to resolve the issue, we schedule a maintenance window. Remember, let’s be diligent about our change management notification.

Let’s make sure that other It staff know what we’re going to do and when to see if that’s going to impact anything they’re doing. Now, in step number five, we’re going to implement the solution that we defined. We might need to escalate it as necessary. And after we implement the solution, let’s see if it did anything, did it fix our issue or not? In other words, we want to verify full system functionality and if it’s possible or applicable, we want to implement some preventative measures to make sure that this particular issue does not happen again. For example, the Cabling issue that I was telling you about, going under the chair mat to make sure it didn’t happen again.

As I mentioned, I rerouted the cable somewhere other than underneath the chairmat to prevent it from happening again. And as a final step, step number seven, we want to document our findings, our actions, our outcomes. And honestly, I don’t think this is the fun part of Troubleshooting. If there is a fun part of Troubleshooting, and a lot of It professionals, including myself, not big fans of doing a lot of post mortem reports, as they’re called, but I can tell you they can be incredibly valuable. Personally, I have been in situations where I think, why would I want to document this? Because it was so painful to fix. It took this many hours or this many days to fix in some cases. I went through so much pain and suffering to figure this out, there’s no way I’m ever going to forget what happened. And I’ve already forgotten exactly what the underlying issue was, exactly what command I typed in to fix it.

So we really want to have good documentation, not just for ourselves, but for our coworkers as well. So those are the seven steps that CompTIA wants us to memorize. And I’ll put them all up on screen for you. And you might want to spend some time here creating some flashcards. I want you to memorize each of these steps, not just for the exam, but when you’re Troubleshooting in the real world. Personally, I find having a troubleshooting methodology. I’m going into a situation, and I think it could be this. Should I try this? What about this? If I realize, wait a minute, I’ve got a step by step troubleshooting methodology that I can go through if I just take it step by step? Yeah, that’s a lot less stress on me. I don’t have to think about the exact right thing to do right now.

I’m going to start by clearly identifying the problem and then work my way on to the next step and the next to the next. So personally, I think these Troubleshooting steps are not just great to know for the exam, they’re great to know for the real world.

• Category: Uncategorized