and welcome back not every Journey to the world of troubleshooting ends the same way some things are easier to troubleshoot than others and also if you and I've been working on like one large Network we know it like the back of our hand it's a lot easier to troubleshoot because we know what the subnets are and the interfaces involved where on the other hand if we go to a brand new network or we're doing consulting it may take some warm-up time to get used to and to figure out where everything is on that specific customers Network and when we're doing troubleshooting again whether it's our own network that we know really well or it's a new Network that we were just introduced to if we have a certain process or methodology for troubleshooting we can apply that methodology across the board so let's have some fun with this we'll put an overview of the high level steps regarding a troubleshooting methodology and then as we proceed together we'll actually apply those steps as we troubleshoot together a network so the very beginning of this troubleshooting process it would be to identify the problem case in point let's imagine that the user who's sitting at this computer right here pc10 calls the service desk or the help desk or whatever they're calling it in your organization and they say yeah I've got a problem and then the service desk says okay tell me more and if the user says well I can't really tell you anything well we have to kind of you know narrow down what the problem is or at least get what the symptoms are and that's why one of the very first steps is to identify the problems so with the identification of the problem the user may say I can't access the internet or they may just say the network is down at which point we would ask some additional questions so let's imagine this user says that I can't access anything on the internet that would fall into this category of identifying the problem is that this user who normally can access the internet can no longer access the internet the Second Step would be to establish a theory Regarding why that might be happening and so by leveraging a topology like this we could ask ourselves a few questions for example is this computer powered on uh if the computer is powered on does it have an IP address and if it's a DHCP client did it get the right information regarding a default gateway and the subnet and all that good stuff and then regarding this port is this port on the switch is it associated with the right VLAN which is VLAN 10 and regarding the the trunking that's going down from the axxis layer switch to the core is trunking working and is VLAN 10 being allowed and then from the default gateways perspective regarding VLAN 10 Who's acting is the default gateway is it Core 1 or Core 2 or are they using a first toop redundancy protocol and if so which one of these two devices is acting as the active device and does that device acting as the default gateway have a route out towards the internet in simple terms does it know how to forward and the same thing would hold true for this router and then this connectivity to our service provider and also because we're us rfc1918 addresses perhaps Network address translation is failing or isn't implemented correctly so if this user a pc10 by doing a few tests we verify that it can ping its default gateway and if this device in vant up here at headquarters can ping devices out here at site 2 and site 3 and has reachability there that can help identify what is working and then we could establish a theory about what may be specifically causing the problem and then once we've narrowed it down to what we think it might be and then the third step is to test which is to basically go in and prove your theory if we think the problem is with router one or if we think the problem was with the multi-layer switch or we think the problem was with the axis layer we want to do some testing to validate that what we think may be the problem really is causing the problem and then once we've narrowed it down and verified it we then want to go ahead and solve the problem now solving the problem uh in an organization also has many steps involved with it let's list a few of those as far as the solution to this network connectivity problem that the user is having out to the internet and let's also imagine based on our testing that we believe it's an issue with address translation which could be natat or Pat but definitely needs to happen at some point before that traffic goes out to the Internet so if we've done some testing and we've narrowed it down that it is an address translation issue regarding solving that we' want to create a game plan on exactly how we are going to solve that problem perhaps with network address translation the N device was set up to support vlen 20 with the 10120 subnet and other networks like this over here at site 2 and site three but maybe perhaps not including the 10.10 subnet so we want to make a plan to correct that and also in corporations that's going to involve going through Change Control if we're going to make a configuration change and then with the authorization from the Change Control Board then we're going to go ahead and implement the change and then when we've implemented it we also want to verify that it's working and that verification would involve a few things number one that we now have connectivity from this PC out to the internet also we'd want to verify that we didn't make any other changes that would negatively impact our environment like we want to make sure everything else still functions as well v20 and the other sites everything can still forward out to the internet and then we'd also want to make sure we document the solution what we did how we did it and if we changed the topology in some fashion we'd want to include that update in our documentation so the documentation of what was done and also the topology if there's been updates that's super important because let's say 3 or four days go by and we have yet another problem and we think oh I wonder if what we changed here injected additional problems into the network so we could go back through our paper trail and identify what happened when it happened what was changed and that can help speed up our troubleshooting because a lot of times uh there are cabling issues and physical issues and so forth but a lot of times when something breaks on the network when something stops working it's quite often due to the last change that was made and so if we go back and take a look at the last change or two that can help us reduce our troubleshooting Time by either confirming that what was done is not impacting our current problem or by verifying that what was done indeed is impacting our current Network and then the last step here is to go ahead and repeat this process for the next problem so the next servers call that comes in the next issue the next problem again we're going to follow this logical plan so what I think would be fun to do is let's take this network topology which we've been playing on and off with throughout these videos and what I'll do is I will inject a problem somewhere in this mix and then we can go through these steps one at a time in this troubleshooting methodology and as we do so we'll go into more details on each one so in the very next video join me as we take a look at this first stage in the troubleshooting methodology and that is identifying the problem which we'll do in this network topology so I'll see you in that video in just a moment hey thanks for watching And subscribe right here to get the latest information from CBT Nuggets and if you're new to or considering a career in the world of it head on over to CBT Nuggets and sign up for a free trial