By Garrett Seeley and Cameron Larks
One of the things we have yet to cover in this series are techniques for troubleshooting a network. There are several different styles and approaches to troubleshooting networks. Here is a mash up of our techniques. We prefer utilizing the first 3 steps of the OSI model, the physical layer, data link layer, and network layer. These are foundational to most network troubleshooting.
Check the physical cabling and the data link layer at the same time. To do this, check the link lights. NIC cards should have lights by the ethernet ports. Not all will, but if they do, the flashing light indicates that packets are going to the next device. Sometimes a solid light will indicate a connection, but on a two-light port, a blinking light indicates chatter. That means that the NIC is communicating to the switch. Most switches have a two-light configuration and will follow this pattern. No lights on the device means you do not have a connection. No lights on the switch usually means it is powered down. If the switch has lights but the specific port is not lit, then the cable may not be terminated correctly. This is the MAC address connection, or layer 2 connection of a LAN. To troubleshoot cable issues, a network connectivity cable tester should be used. To utilize this device, plug one side of the ethernet cable into the wall port and one side of the cable into the device. Once the device is on, it will verify if there is connectivity to a switch. If there is connectivity to a switch, the device will provide the switch information. If there is no connectivity, ensure the cable is plugged into the switch. This will activate the wall port. If the switch is responding correctly and connectivity to the network still fails, switch out the ethernet cable.
If the network is still not working, move to troubleshooting the network layer. Do this by breaking it up into two parts. First, check your IP settings. Use ipconfig/all. Ipconfig is a text command that lists the computer IP. It is hands down the easiest way to get the current IP settings of a Windows computer. It is not the only way, but it is the most convenient for a technician. Since it is a text command, ipconfig must run through the command prompt or PowerShell. These are the command line interfaces for a Windows machine. Command line is a way of controlling a computer through text. It is accessed through the “CMD” command through the “Type here to search” prompt in most Windows systems. Conversely, right click on a computer that you have administrative access to, select either Command Prompt or Windows PowerShell. These commands will work in either of these windows.
Using ipconfig will list the current IP settings for the system. Note: if a computer ever lists its IP as 169.255.???.??? (? Means any number). That is a dummy IP, called an APIPA IP address. This is Windows giving the NIC an IP just so the programs that require an IP to work can function. If there is no link light, this IP will be in the system. Verify step #1 is OK. If it is, verify the DHCP server or router is on for the subnet that you are on. Verify the system has an IP that works for the subnet. This brings us to the next essential tool.
If the IP is set correctly, troubleshoot it using ping. There is a way to check each of the standard network’s settings, IP, Subnet, Gateway, and DNS, using three pings. This is performed through command line using the ping command, ex. “ping 192.168.0.1”. Using Ipconfig from step #2, get the IP of the computer ethernet adaptor, its subnet, gateway, and DNS. Make sure to read previous articles on these settings for familiarity on these numbers and what they mean.
Ping #1 – Ping the gateway IP to verify that the computer has access to the subnet. This will verify that the IP is in the correct range for that subnet. If there is a time out, the IP and subnet settings need to be inspected to make sure the computer is in the correct network for your local LAN. Honestly, look for duplicate IPs at this point. A common mistake is to use another machine’s IP instead of a unique IP. Again, read up on these settings in the TCP/IP networking notes for more information.
Ping #2 – Try pinging a known IP outside of the subnet or LAN. This can be, for example, a PACS server or even an Internet IP such as 8.8.8.8. This verifies the path your subnet takes to leave its LAN and talk to the larger hospital intranet or the Internet. The use of this command will look like “ping 8.8.8.8.” If this fails, there is a problem leaving the current LAN to the next LAN. In this case, the problem is most likely past your router and in the connection to the next router. Keep in mind that if your LAN was intended to be separate from the Internet, this will verify that there is no connectivity to the Internet. Confused? Stay tuned for future articles on VLAN troubleshooting.
Ping #3 – Ping a name of an Internet site that is allowed on your network, such as www.bing.com. This may also be as simple as pinging your hospital’s web page or intranet site. If this does not work, your DNS is either powered off or you do not have access to a DNS. It’s not a big issue if your network does not use a DNS, but more and more hospitals do use their own DNS. Note that pinging a name should give a reply from a number. The purpose of a DNS is to convert from a name to a number. For example, pinging “amazon.com” may result in an response from 54.239.28.85. If the response says, “destination host unreachable,” the DNS could be off-line, incorrectly set or even unplugged.
These steps are the foundations of troubleshooting. Remember to follow the OSI model layers. They are a great model for understanding where things can go wrong. Check them in order: check the cabling and link layer, the local settings on the system, and the overall connectivity using ping.
After years in the field, it is still surprising to us how many times the answer is just as simple as an unplugged cable. These even happen in a networking closet that was supposed to be secured. It’s proof that we all need to keep in mind the basics, because those skills are the foundation of any troubleshooting.