hi and welcome to Cyber that I t.
My name's Anthony and I'm your local subject matter expert here for Network Plus and today we're going to be talking about troubleshooting network environments,
So in order to properly troubleshoot our network So in order to properly do troubleshooting in general, we want to follow a couple of steps that we call our troubleshooting theory now are troubleshooting theory allows us to have a systematic way of going through an issue going through a process and being able to eliminate possible
causes, find the actual cause and then test our theories and make sure that we're documenting, documenting and backing up and doing all the appropriate measures that we need to dio. We don't want to just rush headlong head person to a problem and just start removing removing cables and replacing cables and changing settings.
We need to have a systematic way of doing things so that we have a better chance of finding a result.
So let's take a look at our troubleshooting theory in general and then we're gonna break it down into our individual sections. Now are troubleshooting. Theory starts with identifying the problem. Now
this is pretty obvious if we we wouldn't be troubleshooting anything if we didn't notice a problem. But identifying a problem could be a little bit harder than it initially seems.
There we may. There may be some symptoms of an issue that aren't the actual cause are they aren't the actual problem of the issue. So we may say that,
Hey, my Internet's not working
Well, that's an issue, but maybe it's because your computer's on fire. Well, that's the problem.
So we need to be able to identify the problem. We need to be able to learn how to talk with people who may be experiencing computer issues so that we can better identify the problem, especially when we're not actually experiencing the issue ourself. And we have to talk with someone in order to figure out and gather information. We don't want to begin troubleshooting and non existent problem.
We don't want to start trouble shooting something that
isn't what they're talking about. We need to make sure we identify the correct issue,
so that's our identifying the problem.
Next we have establishing a theory of probable cause. This is where we are creating our hypothesis when we're establishing our theory of probable cause. We're going through our checklist and we're saying, OK, what could be the cause here? What's what's causing this issue and we're going through? We're checking our documentation
and we're creating a theory. We're creating our hypothesis.
Then we test our theory.
Once we have established a theory, once we have found a probable cause, we test that cause and maybe do some preliminary testing in order to see if, oh, if we eliminate this or if we change this, then I'll be able to restore connection or be able to have not had issues anymore.
If we're noticing that our network is going down and it seems like we're having, we can't may have some, and we think that we've narrowed it down to one computer that's jabbering a lot and causing a lot of excess traffic on our network. And then we unplug that computer from the network, and the network's fine. We've We've tested our theory,
but just testing our theory and identifying which computer is causing the problem
hasn't fully resolved the issue. Then we need to make them. We need to go to our next step, which were we establish a plan of action and identify effects.
So if we go back going back to our example of our jabbering computer on our network that we've disconnected, we've now identified. We've tested our theory. And yes, this computer is the one that is jabbering on our network. So we need to establish a theory of steps we need to stop with a plan of action
in order to fix that computer and prevent it from jabbering on the network.
Maybe it's a server that we need to have on the network, and we can't just say, Oh, well, this computer is bad and throw it away There's
not many cases where you would want to just say, Oh, this computer that were We encounter an issue and say We'll just get you a new computer.
So even if the computers because we probably want to troubleshoot the issue itself
and we want to identify, we want to identify effects. So if our plan of action is to throw the computer in the dumpster, then our potential effects are that we no longer have that computer or if we say oh, well, let's establish a plan of action.
Let's remove the network interface. Let's remove the network interface card and that'll keep it from jabbering on the network.
Well, yes, but now it no longer has network connectivity unless you replace the network interface card. So we not only want to establish a plan of action, but we want to think about potential effects of what we're doing on the computer, because we may fix one issue that causes another. So we have to keep that in mind as we're troubles as we're going through our troubleshooting theory.
Then we implement or escalate.
So when we implement or escalate
we are starting the process of
a stack of implementing our plan of action.
Maybe we have implemented our solution, but we can't perform all the necessary steps so that we have, so we have to escalate to the next level up. Maybe
our department is responsible for the network, and we've identified the computer, and we've established a plan of action. We've said this computer needs to have maintenance done, so it's not jabbering on the network, so we escalate it to a different department that handles individual computers, that it handles hardware. So that's where why we put here, implement or escalate.
Or if we've gotten to the point where we can't figure out how to fix this now we may want escalate.
Then we verify functionality and take preventative measures. So after we've implemented our solution or have escalated our issue and they had implemented their solution, we need to go back and we need to verify functionality. So are jabbering. Computer has come back from maintenance, or we replace the network interface card, and we're not having our issue anymore.
And we connected back to the network, and the network's still fine.
We let that computer go out to the Internet, start navigating some pages, try to download a couple files from our file server, and everything's good. So we're verifying functionality. We wanna verify functionality, not just of the issue that we were experiencing before. Yes, we want to try to replicate and make sure that it's not causing the same issue, but we also want to make sure that what we did didn't harm any other components.
We want to make sure that when we replace the network interface card,
we didn't unplugged the hard drive by accident or when we replacing network interface card we didn't harm or when we changed the setting on the computer. That setting didn't harm some other component of our computer. So we verify full system functionality,
and we take potential preventative measures. Maybe we want to have some sort of measure that will detect when that computer, if it's starting, had issues again so that we can go and check on it. We may want to put women want to stand up some port mirroring instead of a wire shark so we can check on the traffic once in a while from that computer.
Different preventative measures that can help prevent this issue from caught from happening again
or delaying the next time that this issue would occur. And now we document our findings, actions and outcomes.
So we want to document everything from Step A from a dizzy we want to start from what we noticed when this issue with occurring, what we did in order to troubleshoot and narrow down where this issue was, what we've tested, what worked, what didn't work and then how we fix the problem and the outcomes.
That way, if this problem were to happen again,
a year or multiple years down the road, and it was someone completely different. They could use our documentation in order to solve the same issue.
So that's our trouble shooting theory from identifying our problem to documenting. And now let's go ahead and let's take a closer look at our individual steps in our troubleshooting.