How to troubleshoot a slow network

[Music] before we get started let's take another look at Paul's ticket as you may remember paul's computer is ipv4 only now nothing about Paul's ticket flat-out screams that there's a network latency problem in fact it looks a lot like the other tickets we've looked at but remember what we said earlier don't get into the habit of assuming that two different problems are similar just because they look the same on the surface sometimes Network latency can present as a network failure if the network is slow enough it can cause some applications to timeout and just stop trying so they fail to the end-user this looks like something is just broken and in fact even if we ask really good questions we usually cannot determine whether there's a network latency issue or just an outright failure just by talking to the end user we have to actually get on Paul's computer to find out what's really going on so let's do that right now here we can see the page can't be displayed here that Paul reported but notice also that the status icon on the tab is spinning indicating that Internet Explorer is still trying to load the page up to this point we've been using the Windows command prompt to diagnose and troubleshoot but I want to show you another alternative the windows powershell it's available on all windows 7 and later operating systems and you can get to it by going to the Start menu and just searching for power show the commands we're going to use are exactly the same as we would use at the windows command prompt in fact all of the commands we're using are part of the Windows operating system and are not tied to either the command prompt or power show let's start out by pinging and our ping the default gateway will do a ping 10 10 1.2 54 and that looks good ARP dash a shows the correct dynamic ARP entry for the Gateway so we know that layers 1 & 2 are good now let's ping the intranet site ping Internet net Lexia comm and we get a response initially followed by a request timed out another response and then another request timed out if you look at the ping statistics you'll see that it reports a 50 percent packet loss now this is just over 4 pings this could just be a temporary blip in the network or it could be part of a larger pattern but we can't tell which it is with just 4 pings so what do we do well we could set the ping command to ping over and over again but then we'd have to sit there and constantly watch it which would take us away from other things we could be doing to troubleshoot the issue instead there's another program I want to show you called coalesce off to ping tool this is a third-party program that is not part of Windows so you will need to download it and I'll give you the link in a moment ping tool gives you a visual representation of ping response times over time so you can easily spot patterns without having to wait a long time you can also leave it running in the background while you do other troubleshooting and then come back to it later to review the results you can see that we're getting the same 50% packet loss and it's very consistent what do we make of consistent 50% packet loss well we can make several guesses and there's nothing wrong with guessing but we still have another tool at our disposal we clearly have a layer 3 issue on our hands so we'll use traceroute to try to find out where the packets are getting dropped okay now what's going on here it goes from switch 1 to R 2 to R 3 to switch 4 and you don't have to take my word for it we'll look at the topology diagram in a minute so why does the internet IP address 10 that 11.0 11 show up four different times well this has to do with the way traceroute works I wish I could tell you that traceroute actually just traces an individual packet from its source to its destination but that's not actually how it works traceroute sends a series of packets and under normal circumstances all of those packets will get a response but in this case because we have 50% packet loss not all of those packets are getting a response the asterisks you see scattered around here indicate a response that went unanswered in other words a packet that was lost now if you count the number of asterisks or lost packets there are eight but in total there are twelve requests now this is more than 50% loss it's actually about 67% why is this well remember we're still running a continuous ping in the background using the kola soft pink tool so that's going to skew the results a little bit and that's okay but we still don't know what's causing the intermittent packet loss so what do we do well we're gonna run another trace route now why are we doing this well the first trace route gave us some pretty strange results by running a second one we can compare the two to see what if anything is different remember there's no magic bullet when it comes to network troubleshooting in other words there's no defined set of commands to run that will always tell you the cause of the problem or even where it's located now that the second trace route is done let's go through and compare it line by line with the first one we have switch 1 followed by our two followed by our three but look at the fourth hop on the first trace route it switched four but on the second it switched three it looks as if the packets are taking two different paths let's take a look at the topology diagram to get a better view of what's going on the packet goes from Paul's computer to switch one from there it goes to R 2 and then 2 R 3 on the first trace route the next hop was switch 4 but on the subsequent trace route it was switched 3 so it appears based on our trace route output that the packet is taking two different paths sometimes it takes the path through switch 3 and sometimes it takes the path through switch 4 assuming that one of these two paths is not working that would explain why we're getting 50% packet loss so we've definitely isolated the problem to a layer 3 issue but as yet we don't know the cause but before we get too far ahead let's take a step back and review what we've done so far with Paul's problem initially we observed that Paul was experiencing 50% packet loss while pinging the intranet site we use the kola soft ping tool to visualize the packet loss and ping response times from Paul's computer to the intranet site ping tool is a great tool for when you're dealing with a network latency issue or when you just want to monitor performance over a period of time after we discovered the 50% packet loss using ping tool we ran a trace route which showed us that the packet was taking two different paths but it didn't tell us which path was failing I'm not going to get into the technical details of how trace route works but suffice it to say that the trace route does not always tell the whole story what this means is that you cannot always use a trace route output alone to conclusively determine the cause of a problem this is one of those cases where we have to be very wary of what trace route is telling us

Channel: Ben Piper

Views: 118,079

Keywords: networking, troubleshooting, ipv4, latency, switch, route

Id: -dZ4-mTNRs8

Length: 7min 36sec (456 seconds)

Published: Thu Dec 28 2017