200-301: Cisco Certified Network Associate (CCNA) Certification Video Training Course

200-301: Cisco Certified Network Associate (CCNA) certification video training course by prepaway along with practice test questions and answers, study guide and exam dumps provides the ultimate training package to help you pass.

The Cisco Troubleshooting Methodology

1. Introduction

In this section, you'll learn about the Cisco troubleshooting methodology. So that's the official Cisco methodology, or framework, for how you should carry out troubleshooting. We're not really going to go too deep into troubleshooting examples because I'll be doing that for all of the different functions and features on your Cisco routers and switches throughout the other sections. So we're just going to really cover the methodology here. I'll also talk about some of the more common troubleshooting commands to test connectivity. And we'll have a little example in the lab as well.

2. The Cisco Troubleshooting Methodology

So this is the official Cisco troubleshooting methodology diagram. And this is the recommended way for Cisco to work through troubleshooting a problem. Now, to be honest, as you get more experienced, you'll be able to troubleshoot just naturally, really, without having to think about it or use a diagram like this. But it's quite useful, if you're new to networking, to lay out in a logical fashion the steps that you can follow to figure out what's causing a problem.

pSo, starting at the top, the first thing to do is to define a problem and specify exactly what the problem is. Once you've done that, youths move into gathering information. So find out information about the problem. For example, let's say that we've got a connectivity problem. We would check to see if we can ping from the source to the destination. If not, we would find out: is it just affecting that one host, or is it affecting other hosts in the same area? If it's only affecting that one host, the problem is probably with that host. If it's affecting everybody on the IP subnet, then it's probably not a problem at the host level.

It's probably something between the host and the destination. So we would then find out other information, like asking, "Has anything changed recently if it was working before?" So if it was working before and now it's not, find out what's changed, and that's probably going to tell you what the problem is. The next thing you do is analyse that information. So ask all the relevant questions, not just asking questions of people but also using show and debug commands on your devices to get the information, then analyse that information and look for clues about what's causing the problem.

You can then move on to eliminating potential causes. So, if we're troubleshooting a connectivity issue from a source to a destination and there are several routers between the source and the destination, if we check the first top router and the configuration, and everything looks good there, we can rule that out as the cause and then check the next hop router along the path. The next thing to do is to propose a hypothesis. So, taking all the information into account, you will determine what appears to be the most likely cause of the issue. Then you test the hypothesis by actually putting in the commands or doing the thing that would fix that problem. Then, if the problem is fixed, you've solved the problem.

We're at the bottom now. The last thing to do is document the solution. Now, this is something that's not fun to do, but it's important to do it. And if you do get into the habit of doing it, you'll thank me later. Because sooner or later, you will encounter a problem that has already been encountered by someone else. If you've got proper documentation in place in your organization, it should be very easy and quick for you to find a solution because somebody's documented that problem. And the solution, if you're not doing any documentation, is that if it took an hour to fix it the first time, it's going to take you an hour to fix it this time as well. Whereas if you have documentation, maybe it's only going to take a few minutes.

Also, this isn't just for other people who may encounter the same issue as you later. It's for yourself too. Maybe you run into the same problem a year later and can't remember exactly what the issue was. But if you've got the documentation there, you'll be able to quickly look it up and quickly find a solution. Okay, so that's a standard way to troubleshoot from start to the end. But you'll notice there are some other arrows going in different directions here as well. As a result, we can sometimes skip straight from gathering information to proposing hypotheses. If this is a problem that you've seen before and you're pretty confident it's the same thing again, you don't have to spend time gathering additional information. Just put in the solution that you think is going to work and see if it works or not.

Also, often, we can move back to an earlier stage if we don't manage to fix the problem the way that we thought we were going to. Okay, so that is the Cisco troubleshooting methodology for troubleshooting methods. Again, experience is really going to help you here. Sometimes it makes sense to do a top-down approach, sometimes a bottom-up approach, and sometimes divide and conquer. And what I'm talking about here relates to the OSI stack. Some issues are simply more logically solved by starting at the application layer and working down through the layers. Other times it's easier to do it the other way around, where you start troubleshooting at the physical layer and then work your way up through the layers. And other times, again, you can divide and conquer.

For example, if you see a problem, like a connectivity problem, that you've seen similar problems with before and that's always been caused by an issue at the network layer, you could go straight to the network layer and start troubleshooting there based on what you find. You could then move up or down through the OSI stack. And remember, as we said before, having a good understanding of how IP networking works, as we covered in the life of a packet section, and also how the OSI model works, is going to really help you understand what's going on.

And when you understand what's going on, that makes it easier to troubleshoot problems. Some methods we can use in our troubleshooting—the first one here is comparing configurations—include When configuring routers and switches in an organization, you will frequently use templates. There are already routers and switches in place in an existing organization. So rather than doing a new configuration from scratch, you'll do it based on a template. So if you are doing this and there's a problem that you think is on a particular router, you can compare it with another router that should have a similar configuration and look for any differences there.

Maybe you've got a typo, or maybe a mission command. By comparing it with a new and good configuration, this can help you find a problem more quickly. For connectivity issues, what we're usually going to do is trace the path, and as a network engineer, a lot of your day-to-day job is going to be troubleshooting connectivity problems. So you will do this very, very often. The best way to troubleshoot connectivity problems and chase the path is to start at the source and work your way towards the destination. On the next slide, we'll cover some of the commands that we're going to use here. The last one mentioned here is swapping out components. If you think you've narrowed the problem down to a specific device but can't see a configuration error on it, you can confirm it by swapping out with some known good hardware; the problem could be at the physical level or something else, or it could just be something you're missing. So, for example, a really simple one would be a cable. If you think it's possibly a cable issue because all the configuration appears okay but there's some kind of physical layer problem, just swap out the cable and see if that fixes it.

Okay, so I just mentioned some of the common commands that we will use to troubleshoot connectivity. Ping, which checks connectivity between two devices, is a very common command to use. When you send out a ping, it uses ICMP and sends a packet from the source to the destination. The destination will then send a ping reply back again. So ping verifies two-way connectivity. If you've got connectivity from the source to the destination but the return path from the destination back to the source isn't working, then the ping will not work either. So this verifies two-way connectivity between a source and a destination, and this is often one of the first commands that we'll use.

If we've got what looks to be a network connectivity issue, the next command we'll probably use after a ping if a ping fails is a trace route. If you've got multiple routers between the source and the destination, what you can do is troubleshoot it from source to destination. Assume we have routers R1, R2, R3, and R4. You could start with R one. If everything looks good, you proceed to R2, then R3, and so on. Well, a trace route can sometimes speed this up a bit. A trace route does a ping hop by hop from the source to the destination, and it will often indicate which router along the path has the problem. And finally, we can use telnet. Telnet is normally used for managing your network infrastructure devices, like your routers and switches. We can use that to get onto the command line on the device. But another thing that it can be used for is checking to see if a port is open at a destination. Rather than using telnet to the default part of 23, we could, for example, teleport to port 80. That will verify if Part 8 is open and receiving communications at the destination. Okay, so next up, let's have a look at this in the lab. And I'll do so in the following using this topology.

3. Cisco Troubleshooting Methodology - Lab Example

continues the Cisco troubleshooting methodology And here we're going to have a look at how to do some connectivity troubleshooting using the commands ping, trace route, and telnet. So the scenario we have here is that we've got the network topology over on the right, and there is a user on a PC that is behind the R1 router. And he's complained that DNS isn't working. And in this example, the DNS server is our R3 router.

So, in real life, the first thing to do is to not believe a user who reports a problem; instead, double-check it. I have spent hours troubleshooting problems that turned out not to be problems at all. The thing was actually working. It's just that the user made an error, maybe a typo or something like that. So let's verify if DNS is working or not. So on R one, I'm going toping R three by its host name. So I used the command pingr 3, and I discovered that my domain server is ten dot, three dot, one, which is R 3. So that's good. But it says "unrecognised host address" or "protocol not running." So we do have an issue here. DNS is not working. So if we suspected that this was an IP connection to the ASU, the next thing that we would do is do a ping from the source to the destination. So in R 1, I'm going to ping 10, 10, 31. I'll ping it using its IP address. This takes DNS out of the equation, and I can see that the ping is failing. It is unreachable.

So I've got a little Connecticut. The problem with R 1 and R 3 Now, what I could do is go hop by hop, checking to see where the problem is. I could check that R1 has connectivity to R two. Then R 2 was linked to the E to R 3, and so on. But a command I can use that will save a bit of time sometimes is trace route.

So I'll trace the route to 10 dots, 10 dots, and 30 dots, in that order. Now, what the trace route command does is it sends a pin, but it sends the pin with a time-to-live value of one, then two, then three, and so on. So because the time to live is set to a low value, if a router sees a packet and the time to live gets down to zero, then the router will drop that packet. It is a loop prevention mechanism that we can use with trace routes by sending the first ping with a time to live with one.

So it will get to the first router, then send a time to live of two, get to the second router, then send a TTL of three, and so on. So what this does is map out the entire path from the source to the destination. And if there is a break in connectivity somewhere along that path, then the traceroute should get as far as that router. As a result, it aids us in determining which router is causing the issue. So let's try the trace route, and we can see that the first hop was getting to R-2 on 1010-2, and then that's as far as it got. So R 2 was the final route it took. So the problem is most likely there. So let's just jump straight onto Route 2 and see what we can see there. Okay, so here I am on R. On page two At 10:10:31, I'll ping R3. And the ping I can see isn't working.

So the next step is to ensure that device two does not have an interface that is directly connected to the 1010-30 network. So it would need a route to get there. Don't worry about routing too much right now because we'll get to COVID later. But for now, I can check the routing table with the show IP route command. So I do this, and I can see that, yes, there is no route to 1010-30.

So I'm going to fix that. So I went to command configuration T to get to global configuration, and the command to enter a static route is IP route. Then the network I want to get to is 1010 30; the subnet mask is 255-255-5251 dot O. And the next hop address to get there, for which I need an interface on the same subnet, is 1010 21 on R 3. So I'll try that, and then, to get back to the enable prompt, I'll ping 10 dot 30 dot 1, and I can see that the ping is successful. So if I now go back onto our one, then hopefully the ping will work okay from here, too. So here's me back on RPG1010, and the ping is successful now. So I fixed my connectivity problem.

Okay, so that was a demonstration of how to use ping and trace routes. The other command we can use here is telnet. So ping and trace will help troubleshoot layer three issues. You can use telnet to help with layer four and above columns. You can use telnet to send that to a specific part. So from R1, I'm going to telnet to Ten. I'm going to telnet to port 53, which is the DNS port.

And this should tell me if DNS is running on R3 or not. And there, I can see that port 53 is open. So R3 is running DNS. So that looks good. Just to double-check this, I'll check that DNS is working. I will ping R3 by its hostname. And I can see that it has been resolved. When I did the telnet, it was 1010, 31 and the ping worked. If it did not see the part as being open, then that would indicate that the service is not running on that particular destination. That concludes the fundamentals of IP connectivity troubleshooting. And that wraps up this section. see you in the next one.

Prepaway's 200-301: Cisco Certified Network Associate (CCNA) video training course for passing certification exams is the only solution which you need.