Troubleshooting Networks – CompTIA A+ 220-1101 – 5.7

Our wired and wireless networks include many network devices. In this video, you’ll learn how to troubleshoot connectivity issues, understand the signal to noise ratio, manage latency, and more.

One challenging troubleshooting task on a network is someone trying to communicate with the device but getting no response at all. It seems there’s no connectivity to that remote device. To be able to troubleshoot this, we tend to start with our local device and work our way through the network until we run into a problem.

Our first step should be to check to see if we have any network connectivity at all. Usually there is a link light associated with the ethernet interface, so you should at least be able to see if we have a light from the switch, and if there’s a blinking light showing there’s traffic that’s being sent or received.

Once we know we’re at least connected to the network, we can then begin testing how far we’re able to communicate through that network. We’ll start with our own device. And we’ll ping the loopback IP address, which is the internal IP of our device, which is If our loopback address responds to the ping, then at least we’re able to communicate using the built-in network capabilities inside of our own device. Now we need to start looking further into the network to see if we can find any problems.

Our next step would be to ping the IP address that’s been assigned to our local network adapter. This would let us know if that physical component appears to be working properly. So if we ping our local address, it will check the local configuration of our system, the physical network adapter, and confirm that we are indeed connected to the network.

If all of those come back with a response from our ping, then we should go further into the network and try pinging our default gateway. Every network is going to have a default gateway. And since that’s the critical link between us and the rest of the world, it’s important to know if that device is able to respond back. If we do get a response from our default gateway, then at least we’re sending packets out to our local network and receiving packets back in return.

And if we’re on a network that’s connected to the internet, we might then want to try pinging some device that may be on the internet. One very common choice might be Google’s DNS server at, or the server Quad9, which is aptly If we’re able to ping either of those IP addresses, then we can confirm that we’re able to communicate to the internet and back without any problems.

If we’re on a wireless network and we find that only part of our pings happen to be responding, then we may have a problem with intermittent connectivity on that wireless network. This might be caused by some interference on the wireless network. There may be another access point or other devices nearby that are using exactly the same frequencies as our access point. We might also want to check the signal strength on our device to confirm that we’re close enough to the access point to reliably send information back and forth.

There are many different components that work together to create the signal strength value. So we’ll not only need to look at the signal that we’re sending, but we need to look at the transmitting antenna that we’re using and the receiving antenna that we’re using.

Many access points can be configured to automatically find the best frequency to use for that particular area. You may want to check the frequencies that are configured in your access point and see if they’re configured to be a manual tuning or if they’re set to automatic. You might also want to try manually configuring different channels to see if that improves the overall performance of the wireless network.

These wireless signals tend to bounce around between objects that may be around us. So you may be able to move to a different location or modify the location of your access point to better optimize the communications path between you and the access point.

Ultimately, this problem may be about location. And you need to be as close as possible to the access point to get the best possible performance. If this is a very large area, and you’re a good distance away from the access point, then this intermittent connectivity may just be related to your distance away from the access point. If you’re able to move closer to the access point or move the access point closer to you, you may be able to resolve all of these communications issues.

Your operating system may have built-in utilities that can give you information about the interference that you might be seeing. Or there might be a third-party utility you can install that can give you more details about the difference between the good signal and the bad signal.

Sometimes this interference is something that’s very predictable. If there are fluorescent lights microwave ovens or other devices in your area that use the same frequencies as your access point, then these could all be causing this interference on your network. But sometimes this interference is caused by things that are outside of your control. If you’re in a building with a lot of different tenants, it may be that someone else is using exactly the same frequencies as your wireless network.

One way to evaluate this is by looking at the signal-to-noise ratio, or SNR, of your wireless network. One way to visually see this interference is to use a utility that’s able to calculate SNR, or the signal-to-noise ratio. There might also be views within Performance Monitor in Windows that can also provide you with more details about the signal to noise.

In this utility, the signal is represented as green. This is the signal that we would like to be able to send or receive from our device. The noise, as the name implies, is anything we don’t want on our network. This is often interference that may be coming from other devices or other components. On this diagram, it’s anything in the red is the noise on this network.

There’s always going to be some amount of noise on anybody’s wireless network. But what you’re looking for is a very wide ratio between the good signal and the noise that’s available. If this ratio was 1:1, where there was just as much noise as there was signal, then your wireless network would probably not be operating. Instead, you would like a very large ratio, where there was much more signal to the amount of noise that was also on that same network.

Here’s a better view of my network. This is showing a bit of noise down at the bottom. But you can see there is much more signal coming through. And on this network, everything is performing exactly as expected.

Windows is very good about giving you information in the system tray that can help you with troubleshooting. If you’re looking at the system tray and Windows says there is limited or no connectivity, or in some cases, no internet access, then you certainly have an issue with communicating out to the internet.

The first thing we should check is the IP address that’s been assigned to our device. This should ideally be an IP address that has been assigned by a DHCP server, or it’s one that you’ve manually configured on that device. If we see an automatic private IP address in this configuration, then it’s possible that the DHCP server that we were expecting to receive an IP address from is not available, and our system has created our own private IP address.

Unfortunately, APIPA addresses are link local addresses and can only communicate to other devices on our local network. This would certainly cause Windows to show an error, such as “Limited or no connectivity” and “No internet access.” If the IP address on our device has been assigned by the DHCP server, then we can begin the normal ping process we spoke of earlier to check our local machine, our default gateway, and then a connection on the internet so that we can find where in this path we happen to be losing connectivity.

If you do any type of voiceover IP or media streaming on your network, then you know that you’re very sensitive to any type of delays that may be occurring. If you’re on a voice call and you’re having network problems, then you’ll probably have a robotic noise or sound like people are underwater when they’re trying to talk to you.

The challenge with this is that all of this is real-time communication. If data doesn’t get through the network, there’s no way to rewind the conversation and rescind all of that data. The only thing we can do is to continue with the conversation and hope that all of the subsequent packets are able to get through without any problems.

Fortunately, there are some statistics we can evaluate to see how well our network may be performing with these real-time protocols. One of these is the jitter statistic. Jitter is defined as the amount of time between each individual frame on the network.

We would like these frames to come through the network at regular intervals. And as long as we have a consistent, regular interval, then we have a phone call that precedes without any problems. But if we happen to have larger intervals between each of these frames, then we might find that our voice calls become choppy or difficult to understand.

This is what we would like to see on our network. As time is going by, we would like there to be regular intervals from one frame to the other. If we’re having some type of delay or latency on our network, we could have large gaps appear between these frames. And this could certainly cause problems with the quality of our phone calls.

For all of this to work properly, we need a high-speed network, and we need very low latency. This is going to allow us to transfer as much information as possible in a very short period of time. We also want to check how much bandwidth is available on our internet link. If someone is using all of the bandwidth available, then we’re certainly going to have very bad latency and difficulty making any of these voice calls.

It’s also possible that we’re using very old equipment that’s not able to maintain the high speeds that we need for some of these networks. So if you have an old router or something that was not designed to perform at this rate, you may need to replace that piece of equipment. And ultimately, if you need to prove anything on a network, you need to see the packets themselves. So performing a packet capture can give you more details about where the actual problem may be occurring.

We define latency as the amount of time it takes between a request and a response. That latency value is going to help determine how much information we’re able to transfer between two devices. We would certainly expect some latency as we’re sending information back and forth because it does take time to send all of that information to one side of the network and receive a response.

Where we start to see problems is where there may be a step along the way that exceeds what’s normally expected for latency. To really examine this, we would need to see each network between both of these devices and be able to understand what types of latencies are normal for those networks.

One of the best ways to measure latency is with packet captures. Being able to grab every packet going back and forth can help you understand exactly how much time is occurring from one frame to another. And you can get details down to the microsecond so that you can really understand what the differences might be between good latency and bad latency.

If you’re connected to a wired ethernet network and you notice that your link light is solid, and then turns off, and then turns back on again, and then turns off again, you may be having a case of port flapping. Port flapping is usually related to some type of physical issue between two devices and being able to maintain that link light.

The first place you should check with these types of problems is the physical media itself. If you have a cable tester or some type of advanced testing tool, you may want to connect it to that cable and confirm that it’s able to support the speeds and the ethernet standards that you’re using.

But the problem may not be with the cable but instead with the hardware that you’re using. You may want to move to a different physical interface on that switch to see if the port flapping problem is resolved or if it moves when you move the cable.

If the flapping is resolved when you move to a new switch port, then it’s probably something related to the original switch port on that device. If the flapping still continues, then the problem may be associated with your device, and you may want to change out your computer or the network interface card on your device.