10 hours 41 minutes
this module. We're gonna go through some basic troubleshooting techniques when it comes to networks.
So network troubleshooting mythology methodology. First, would I identify what the problem is?
Establish a theory for the cause.
I don't wanna test it.
Established Plan of action. Resolve the problem and the solution.
Verify that system's working after even the solution and document the findings. The documentation is very important. I can't tell you how many times I've gone
and fix something.
I didn't document it.
And the same thing happened again. Maybe a year later. And I'm like,
what did I do? And it's like And I ended up having to go through the trouble shooting process all over again because I forgot the document when I did.
First step identify the problem. So first we wanna look at our symptoms.
Is it just down?
Turn it down, or is it just down for certain users
so we can narrow our focus down?
Have we implemented anything new that could affect the Internet?
We put a new switch somewhere. So certain number of users are having problems that because we improvement, we implemented a new switch or we put into new firewall rules. Maybe
after we've asked those questions, we've got us from data. We'll see. Okay, so
these look like the most likely causes of our problem.
So now that we know where most likely causes are, let's let's test them So we could roll the patch back. Or we could undo the firewall rule and see if that fixes the problem.
If that doesn't go the next theory,
once we've determined what the actual problem is,
we establish a plan of action to resolve it.
And this what's gonna be effects of fixing this problem? So in the case of
a new firewall rule, we find out it's a new firewall rule that's causing Internet problems. Well,
what happens when we take that firewall rules out, Why was it originally implemented? Is gonna have a bigger effect,
you know, And is the Did we do it wrong or do we do it right and it's still needed, and we need to find another work around to get our Internet users, so we need to come up with a plan of action.
If we can't come with solution, we may need to elevate it to management, saying, Hey,
this firewall rule we can't find any other way around it.
We've got to go to management and see if they'll just say we don't need this firewall rule
after Eve. So we removed the firewall rule. Want to verify that everything was working correctly, that we're back to the where we were before the problem
talked. All the users make sure they still verify that the problem's gone.
The problem's fixed. It may have been multistage. Problem might have been more than just that one fire rule that caused us
They have the problem
and know this whole
implementation. Make sure you're still documenting everything you're doing, even up to the solution.
When everything's finished, make sure you develop a plan, uh, developed a document that contains all the steps you took to solve the problem.
Who had affected
Make sure that's easily accessible in case someone else has the same problem besides you,
how can we prevent this problem from happening again? When we implemented that new firewall rule, did we not run it by the I T. Guys? Did we not run it by the database guys? It's someone that we forgot to talk to. So the next time we do a new firewall rule, do we need to make sure we include them into our