In this section, you’ll learn how to troubleshoot network connectivity issues. Usually the first way that you find out about these issues is when users complain that they can’t access the Internet or an internal company application over the network. The main tools that we have to troubleshoot these issues are ping and trace. Right? And those are the two tools that we’re going to be focusing on in this section.
2. Basic Connectivity Troubleshooting
In this lecture, you’ll learn about basic connectivity and troubleshooting. So let’s take a closer look at the ping and trace route tools. And then I’ll summaries the layer-one and layer-two troubleshooting tools that we covered in earlier lectures. So, first, ping; ping uses ICMP, which is similar to TCP, UDP, IP, and so on. makes up part of the TCP/IP suite. ICMP stands for the Internet Control Message Protocol, and it’s used for testing connectivity. So, when we do a ping, for example, as shown in the slide, I’m going to ping from Ronen to the 100.1 IP address on R3. R One will send out an ICMP echo request using the exit interface as the resource IP and whatever I configured it to send to as the destination IP that will get to R Three, all being well on the network, and R Three will then send an ICMP echo reply back to R One. So ping tests two-way connectivity. A, it verifies that the source can reach the destination and that the reply can return from the destination to the source.
If the ping is successful on a Cisco router, you will see exclamation marks. So the example here is that we’ve got one dot indicating the first ping field and then four exclamation marks, which say that it succeeded. This is quite normal. It’s quite normal for the first ping to fail if the router is updating its ARP cache at the time. So if we got a success rate of 80%, four out of five pings would be good. That would mean that we do have connectivity. If you see five dots, though, that is bad; that indicates that the ping has failed. So this could be because the router does not have a corresponding route or the destination IP address is not responding. Less common is when you can see it being used, indicating that it is inaccessible.
That happens if the router discards the packet. For example, if it’s being blocked by an access control list, we’ll talk about our access control list, which is our security feature, later on. The next thing I’ll tell you about is the extended ping command. So, if you look at the scenario here, and I’ve put the diagram on the same slide as the text because I want you to be able to see everything and follow along on the one slide here, you’ll see that So hopefully the diagram is big enough that you can see it. So, in our scenario, a user on PC One in the upper right corner complains that they can’t access PC Three. And then you go to R1 to test it, and you pay PC3 $10,210. But what’s causing the actual issue is that our router does not have a route back to PC One at 100/1, whereas in our scenario it does have a route back to R One at 100 one.
When you perform a ping from a router, Whenever you send any traffic that originates on the router itself, it uses the outgoing interface as the source IP address. So, if we go into our one and ping 102-1210, it will use 100-1 as the source IP address because that is the IP address and interface from which it came. So as long as we’ve got connectivity from right to left, that will reach PC Three. PC Three will send a reply back. And because our forward does have a route to the ten-dot network, the ping will succeed. And that’s going to really confuse you because the user is saying that connectivity isn’t working. So what you need to do is actually send a ping from the same subnet as PC One.
So you can do it on PC One itself. But if it’s not possible for you to get on PC One, what you need to do is send it from R One, but from a source address of 100-1-1, the same subnet that the user is in. and the way you do that is with an extended ping. So the next slide shows when we have a problem, so the PC One, we do a ping from there, and we can see it’s failing because of a timeout. But then when we do just a normal ping from R1, it succeeds because it’s coming from the IP address of the X interface, which is four and has a path back to it. So the way that we need to test it is to do this in the real world as well. If you’re ever doing a ping from a router because the users have complained of connectivity issues, do the paying with the same source address on the same sub nett.
So, to instigate an extended pain, simply type “ping” and press “enter.” It will then go through a wizard that will ask you what options you want to set for the pin. So the first thing to ask is: do you want to use IP as a protocol? That’s always going to be a yes. So you can just hit Enter to accept the default IP. You then enter the target IP address. It will then ask you for the repeat count, so you can send more than the default of five pings if you want. This can be useful if you’ve got an intermittent issue and you want to just keep sending pins to see if it’s sometimes going up and down. So in that case, you could set, for example, a repeat count of 1000, and it would keep sending 1000 pins before it stopped. Diagram Size: This is useful to troubleshoot a suspected MTU issue.
If the MTU—the maximum transmission unit—is causing a problem, then you can set the packet to be different sizes to check that. You can also set a time out.We normally just leave that at the default of two, and then the one we’re interested in here is we want to set the source address. To get there, you have to say yes when it asks, “Do you want to go into the extended commands?” So we say yes there.
The first thing that will be asked is: what do you want to use as a source address? Then we can see the IP address that the actual client that’s having a problem is at, and then just keep hitting Enter to accept the defaults for everything else. And now we can see that the ping from our end is failing because the destination does not have a path back to the ten dot one dot one IP address. So that’s extended payment. very useful command as well. Next up, we have trace routes. Trace Route is very similar to Payment, and it’s also used for checking connectivity. What Trace Route does is trace the path that traffic is taking when it’s going across the network. And you see here that we’ve done a traceroute from R 1 to R 3.
It uses ICMP echo requests as well. But the difference between a trace route and a normal thing is that the Treasury also takes advantage of the TTL field, which is in the IP header. TTL is “time to live.” The TTL is used as a route loop prevention mechanism. Every time that a router passes a packet from one interface to another, it decreases the TTL by one. So say we had a loop between R One and R Two, where R One was sending traffic to R Two, and we had an issue where R Two thought it had to send that traffic back to R One again. However, the traffic would flow from R1 to R2, then from R1 to R2, and so on. It would just keep bouncing back and forth. And if we were generating more traffic, that would eventually cause so much traffic on the link that it would congest and really bring our network down.
TTL stops that from happening because, let’s say that we sent the packet with a TTL of 15, it would get to R Two, decrement it by one to 14, and send it back to R One. One would reduce it to 13 and send it on again. Eventually, we would get down to zero, and R-2 or R-1, whichever one it ended up on, would drop the packet. When it does drop the packet, it sends back a time exceeded message to the sender to let it know that it was dropped because the TTL was exceeded. So Trace Route takes advantage of this. What Trace Route does is work like a normal ping, but when we send the first ping, it gets sent with a TTL of 1, so that will reach the first hop, which will then drop it and then send a time-exceeding reply. So you see that happening here; we are doing a trace route from R One to the 10101 interface, which is on R Three. However, we send it as a trace route. So it goes out with a TTL of one.
The packet will reach R2 because it’s the first hop. R 2 will decrease the TTL by one. It gets to zero, so it drops it and will send a time-out message back to R One.As a result, R One discovers that R Two’s IP address, 100 2, was the first hop. R One will then send another packet, this time with a TTL of two. So that will get us as far as the second hop. In this example, our traffic is going only to hops in this example.So that is the final destination. So R Three will send back an echo-reply, and then the tree route has been completed. If we were sending something maybe ten hops away, then R1 would send the first packet with a TTL of 1, then a TTL of 2, then a TTL of 3, and so on. And by doing that, it’s able to map out the path that the traffic is taking. hop by hop all the way across to the destination. If the traceroute is successful, the output will look like this. So we did a count of ten, one, two, one.
We see the first hop is at 100 two.The second hop is 10 12, and it finally arrived at the destination, 10 12. Now, if a ping succeeds and the ATrace route fails, don’t worry about it. The traffic is working. Sometimes the last hop will fail on a trace route. Additionally, firewalls will occasionally droptrace route traffic. They will normally do that. Okay, in this example, I can see that the packet is getting as far as ten and one. It hit the first hop at 100 two.Then it got to the second hop at ten dot one, dot dot one, and it failed. It’s not often that you arrive at your destination—dot one, dot two, dot one. So in a scenario where this would happen, let’s say that we pay ten one two one and the ping fails. The next step is to perform a trace route to ten one two one to determine how far the packet has traveled.
If the packet gets as far as router ten 10 1 and then fails, the problem is most likely on that router. So we would then go into the command line on that router, do a show ip route, and it’s probably missing the route. If it’s not missing the route in the routing table, there’s going to be another issue with that router. This saves us a lot of time by not having to go hot-by-hot all the way from the source to the destination. It quickly shows us where the problem is most likely to be. So it’s a time-saving technique. Now, when the trace route does fail, you can save time because what will happen is you’ll have to sit there for ages waiting for it to time out. By pressing CTRL Shift Six, you can abort and break out the command. So hold down the keys and simultaneously control Shift and Sixall to exit the Trace route command. Okay, so that was the ping-and-trace route.
Some other tools that we can use for basic connectivity troubleshooting are the ones that we covered earlier in the layer one and layer two lectures. So I’m just going to recap them for you here. This is a reminder if you come back to watch this lecture because you do have troubleshooting connectivity issues and want to list them all in one place. So I’m not going to COVID our layer one troubleshooting tools, Show IP Interfacebrief and Show Interface, because you saw them earlier. Other commands we can use to troubleshoot layer 2 issues are Show ARP and the Mac address table. On our switches To troubleshoot layer 4, we can telnet to the destination IP address and the port number, and that will tell us if it’s answering on that port or not. And finally, for troubleshooting DNS, we can do an NS look up.We can also ping the FQDN to see if a DNS server is able to resolve that name. Okay, so that was based on connectivity.