Most Common Network Troubleshooting Steps
Most Common Network Troubleshooting Steps
Most Common Network Troubleshooting Steps
When you’re beginning the troubleshooting process, check all your hardware to
make sure it’s connected properly, turned on, and working. If a cord has come
loose or somebody has switched off an important router, this could be the
problem behind your networking issues. There’s no point in going through the
process of troubleshooting network issues if all you need to do is plug a cord in.
Make sure all switches are in the correct positions and haven’t been bumped
accidentally.
Next, turn the hardware off and back on again. This is the mainstay of IT
troubleshooting, and while it might sound simplistic, often it really does solve the
problem. Power cycling your modem, router, and PC can solve simple issues—just
be sure to leave each device off for at least 60 seconds before you turn it back
on.
2. Use ipconfig.
Open the command prompt and type “ipconfig” (without the quotes) into the
terminal. The Default Gateway (listed last) is your router’s IP. Your computer’s IP
address is the number next to “IP Address.” If your computer’s IP address starts
with 169, the computer is not receiving a valid IP address. If it starts with anything
other than 169, your computer is being allocated a valid IP address from your
router.
Try typing in “ipconfig /release” followed by “ipconfig /renew” to get rid of your
current IP address and request a new one. This will in some cases solve the
problem. If you still can’t get a valid IP from your router, try plugging your
computer straight into the modem using an ethernet cable. If it works, the
problem lies with the router.
3. Use ping and tracert.
If your router is working fine, and you have an IP address starting with something
other than 169, the problem’s most likely located between your router and the
internet. At this point, it’s time to use the ping tool. Try sending a ping to a well-
known, large server, such as Google, to see if it can connect with your router. You
can ping Google DNS servers by opening the command prompt and typing “ping
8.8.8.8”; you can also add “-t” to the end (ping 8.8.8.8 -t) to get it to keep pinging
the servers while you troubleshoot. If the pings fail to send, the command
prompt will return basic information about the issue.
You can use the tracert command to do the same thing, by typing “tracert
8.8.8.8”; this will show you each step, or “hop,” between your router and the
Google DNS servers. You can see where along the pathway the error is arising. If
the error comes up early along the pathway, the issue is more likely somewhere
in your local network.
Use the command “nslookup” to determine whether there’s a problem with the
server you’re trying to connect to. If you perform a DNS check on, for example,
google.com and receive results such as “Timed Out,” “Server Failure,” “Refused,”
“No Response from Server,” or “Network Is Unreachable,” it may indicate the
problem originates in the DNS server for your destination. (You can also use
nslookup to check your own DNS server.)
If all of the above turn up no problems, try contacting your internet service
provider to see if they’re having issues. You can also look up outage maps and
related information on a smartphone to see if others in your area are having the
same problem.
Review all your database logs to make sure the databases are functioning as
expected. If your network is working but your database is full or malfunctioning,
it could be causing problems that flow on and affect your network performance.
To best support your end users, you first need to make sure you’re clear on what
the problem is. Collect enough information from both the people who are
experiencing network issues and the network itself, so you can replicate or
diagnose the problem. Take care not to mistake symptoms for the root cause, as
what initially looks like the problem could be part of a larger issue.
2. Customize logs.
Make sure your event and security logs are customized to provide you with
information to support your troubleshooting efforts. Each log should have a clear
description of which items or events are being logged, the date and time, and
information on the source of the log (MAC or IP address).
There’s nothing worse than going to the IT help desk and being directed to
another person, who then directs you to another person, who directs you to yet
another. Have a clear escalation framework of who is responsible for which issues,
including the final person in the chain who can be approached for resolution. All
your end users should know who they can go to about a given issue, so time isn’t
wasted talking to five different people who cannot fix the problem.