Troubleshooting a network issue can be a challenge for any technologist. In this video, you’ll learn about troubleshooting lack of connectivity, intermittent wireless connections, high jitter values, poor VoIP quality, port flapping, high latency, and more.
When you’re troubleshooting a network problem, there are a series of steps that can give you a baseline of what might be working and what might not be working. The first thing you might want to check is to see if you have a link light. This is a light that’s on the ethernet connection that you’re using. So this would be for a wired connection to the network. If you’re plugged in and you see a light, then you’re at least communicating and sending a signal to the device that’s on the other end.
If you don’t see a light then you might not have a good connection or you might have a bad cable. You then might want to ping the loopback address of the device that you’re using. So you would simply ping 127.0.0.1 and see if you get a response back. It may seem odd that you’re pinging a device that you’re physically sitting in front of, but this is really checking to see if the IP stack that’s in your system is operating normally.
If there’s any problem with the internal network configuration of your operating system, then you will not receive a ping back from this loopback address. From there, you might want to ping your local IP address. This would be the IP address that was assigned to your device from a DHCP server, or perhaps it’s an address that you configured manually. In either case, you should ping that IP address to see if you get a response.
This would verify that you indeed have a link light and you are connected to the rest of the network. Now let’s try pinging a device that is somewhere else on our local network. And since most local networks have a default gateway, that’s a perfect IP address to try. So check the IP address configuration of your computer, where it says default gateway, and try pinging that IP address. That will at least confirm that you’re able to ping from your device to another device on your local network and receive the response.
If all of that is working, it’s time to try pinging a device that is outside of your local network. If you happen to know another IP address that’s outside of your local network, you could try that one. Or you could try some of the more popular addresses on the internet, such as Quad 8, Quad 9, or Quad 1.
If you’re having intermittent connectivity on your wireless network, then the problem may be associated with the channel or the frequencies that you’re using, so you may be able to avoid interference from other devices by simply changing the configuration of your access point. Of course, our wireless connectivity expects that we’ll be able to send and receive enough signal to be able to communicate. This means we may want to get closer to our access point so we have a stronger signal.
You might want to try different antennas on your access point to see if you can communicate over a wider distance, and many devices support the ability to plug in an external antenna to their laptop or desktop computer. Many access points can evaluate other frequencies that may be in use in your area. It will then automatically choose an access point that minimizes any interference with other devices. You’re also able to set that channel manually on your access point.
That might be a good way to try different frequencies to see which one works best for you. Some access points have problems receiving multiple signals that have bounced off of things that may be around us. We refer to this as multipath interference. Sometimes flat surfaces can cause a problem on wireless networks when there’s an excessive amount of multipath interference, and sometimes the access point is simply too far away. By moving that access point to a centralized area, you’re effectively increasing the signal strength for everyone who’s using that access point.
It’s obviously difficult to be able to see the packets as they’re moving through the network or going across our wireless network. For that reason, when things start to have a problem on a computer, one of the most common complaints is that the network is slow. In reality, the problem might be with the CPU or memory inside of their local device. It could be with the application server.
There might be an issue with the database server, and it may have nothing to do with the network, but it’s up to you as the network administrator to determine if the problem is on those external devices, or if the problem really is a network issue. An easy test would be to perform a ping from one end of the network to the other, and be able to evaluate the response times that we’re getting back. This is something you could also validate by performing a speed test.
If you can get very good numbers on a speed test across the internet, then you probably are not having a significant network issue. You then might want to look at every hop along the way to determine what type of performance you might be seeing. So you might want to look at network utilization on each one of those network links, evaluate the number of errors, see how much throughput you might have through each one of those connections, and then determine if there’s any filtering, firewalling, or ACLs that might be in place.
And ultimately, you may need to take a packet capture from multiple points on the network. This will give you undeniable information on whether the slowdown is occurring on the network, or if it’s with the application. Windows provides ongoing network information in the system tray of the operating system, but occasionally, you might see an alert that says limited or no connectivity, or it might say no internet access. You can start troubleshooting this problem by looking at the local IP address of your device.
If you’ve received an IP address from a DHCP server or this address was configured statically, then you should be able to communicate outside of your local subnet. But if there is a problem with the DHCP server, you may have received an automatic private IP address that is an APIPA address. This is one that will only have local connectivity on your subnet, and you will not be able to communicate outside of your local subnet.
If that’s the case, you will certainly see a message saying limited or no connectivity or a message that says no internet access. If you do have a good IP address, then you should try communicating outside of your local subnet, try your local gateway, and then try pinging a remote IP address that’s on the other side of that local gateway. As you move further and further through the network, you will eventually find a place where you’re no longer able to ping, and that should be the point where you can apply all of your troubleshooting efforts to solve this limited or no connectivity issue.
These days, we perform a lot of real-time communication on our networks. It might be a real-time conference call with video, or it may be a voice over IP communication. When you’re in these video calls or you’re listening on a phone call, you’re expecting to always be receiving information so that you can see that the video is changing, and you can always hear what’s happening on the other side. If you were to lose data during the middle of this real-time communication, you can’t rewind that communication and go back to what was missed.
You simply lose that information and you continue on with your call. One of the ways that we’re able to measure how often this data is being transmitted through the network is through a metric known as jitter. Jitter is a measurement of how much time exists between different data frames that we’re receiving. Hopefully we’re able to get a consistent amount of data coming through the network.
But if there are significant delays between these packets, you’ll see that these jitter numbers begin to increase. What we’re hoping to see is, over time, we will see a consistent amount of data being received by our workstation, and that data is coming in at regular intervals. There’s not significant gaps between any one of these, therefore, these jitter values will be relatively small. If there’s some type of network congestion or any errors, you may find that it is not a consistent amount of data that we’re receiving.
We might see a group of data and then a longer gap between, then another grouping of data and then a longer gap between there, and so on. In this case, there’s a significant amount of jitter between these particular frames, and it will probably cause our video to freeze or our phone call to be very choppy. These applications are expecting you to be able to send data through the network and have very low latency as it’s moving from one part of the network to the other.
Any time you’re running a real time application, it will be very demanding and you’ll know immediately, either on the screen or listening to the audio, that you’re having problems communicating with this real-time communication. If you’re communicating across the internet, you may want to run a speed test. This will tell you overall how much information you’re able to transfer over what period of time. This might help you identify links that may be too slow for this real time application.
With an older installation, it may be that the equipment simply can’t handle the demands of these modern applications, and you may want to consider performing a router or a switch upgrade. And if you have a packet capture, you will have a detailed overview of exactly what was going on on that network, and you’ll be able to determine if the issue is related to the amount of traffic, how quickly we’re receiving the traffic, or if the problem may be related to something else.
Port flapping is when you have a link light on your ethernet connection and then you don’t have a link light, and then you have a link light again, and then you don’t have a link light. And that interface continues to go up and down and up and down. Many times, this is a physical problem, and it may be associated with the cable that you’re using. By replacing the cable or putting on a new connector, you may find that you’re able to resolve this port flapping problem.
The problem could also be the physical interface on the switch that you’re connecting to. So if you move your ethernet cable to a different port on that switch, you’ll be able to determine if the problem follows the cable or if the problem is resolved. And ultimately, you may find that it is related to the cable. If this is a simple patch cable, it might be relatively easy to swap out, or you may need to bring in a crew to run a new cable across the entire length of the building.
Latency is defined as the delays between the request and the response. Any time we have a measurement of those two, we can identify how quick or how slow our network might be performing. There’s of course, going to be some latency on the network, because we have to send this information to another device. That information has to be received, processed, and then the answer has to be sent back. Sometimes we can measure that latency in microseconds.
Other times, it might be measured in seconds or even minutes. It would be useful to know what the response times are during each hop along the way. This may require you to have multiple measurements or to be able to have multiple devices, all measuring at the same time. This would allow you to look at a packet capture and be able to calculate the total response time across the network, and then how much latency might also be included by the application itself.
One of the challenges we have with wireless networks is there may be other devices around us that are creating interference. Sometimes these are devices you weren’t really expecting to cause a problem with your wireless network. For example, fluorescent lights, microwave ovens, cordless telephones, and other high power sources can create quite a bit of interference that can certainly create performance problems on a wireless network.
And sometimes you may have no control over this interference. Especially if you’re in a building with many tenants, they may have their own wireless networks and their own microwave ovens, and you may have no control over how and when they use those devices. One way that you can visually see how much signal you’re receiving and how much interference you’re receiving is by looking at a signal to noise ratio.
Many operating systems can provide you with an overview of signal to noise ratios, and create a graph over time so that you can get an idea of just how much interference may be in the air around you. With a signal to noise ratio measurement or an SNR, we, of course, want to know how much signal we’re receiving, and then we want to compare that to how much noise or interference we’re getting on that same network. If we’re broadly looking at a signal to noise ratio like this one, we’re able to get a breakdown of that signal and noise.
Although we’re not sure where the noise may be coming from, we can certainly measure the impact it’s having on our devices. We obviously want the signal to noise ratio to be a very large ratio. You certainly don’t want a one-to-one relationship between signal and noise. That means you have just as much noise as you do signal. Ideally, you would have much more signal and very little noise. Here’s a graph of signal to noise ratio, where we see quite a bit of noise, and then we only have a little bit of signal on top of that.
The ratio here is almost a one-to-one with this particular wireless network. What we would prefer to see is a little bit of noise at the bottom and much more signal, and someone who’s using this network is having a much better wireless experience. Sometimes our problems are not associated with the network, and in many ways not associated with the application. Instead, it might be that we don’t have permission to access the resources that we’re trying to access.
In those cases, we might have an authentication issue where we need to provide our username, our password, and any other type of authentication factor. It may be that we authenticated previously to that resource, but now that authentication has timed out and now we need to refresh that connection to be able to log in again. Or it may be part of a background process where we provide a username and password that that service will use. Because this is running in the background, we may not see any error messages or get any feedback if that authentication doesn’t work.
And of course, a packet capture will show you everything about this connection. So if we see in the packet capture that we requested a resource and immediately got a denied permission, then our problem might be related to an authentication issue. Some of the most difficult network problems to troubleshoot are those that are intermittent. This means sometimes the network is working normally, and other times, it isn’t. To be able to properly troubleshoot this, we need to be looking at the problem when it’s happening.
And that may be a challenge if it’s only happening at certain times of the day. Some of the things you can do is to set an ongoing ping, like the one I have here, where I’m constantly pinging a device every second to see the connectivity that I’m getting. You could also run a traceroute to a known location, or run speed tests occasionally to see what the performance might be on the network. If the intermittent problem that you’re seeing is one that is going to a third party, then you may have to work directly with that third party to help troubleshoot where this problem is occurring.
This may add more complexity to troubleshooting the problem, so you want to be sure to have as much information as possible to help with the troubleshooting process. And if you are working with a third party, you may want to check your contract for your service level agreement. This will give you information on what the expectation of uptime and availability might be for that third party, and it might also tell you what the response time is for getting support.