Troubleshooting A Computer Network

Troubleshooting A Computer Network

Troubleshooting a network is not hard but requires a little bit of forethought. In this article I cover the most popular methods and scenarios to watch out for.

 

 

Introduction

 

Identifying the problem is the first course of action. Don't take other users words for it either. Network issues often need to be seen first hand. If your new, document everything that you find. This will help you make better decisions. Documenting issues is also very useful to veterans. You will want to do it for troubleshooting and any disaster recovery that might come up. If you are in a large organization you will not be able to remember everything.

Good knowledge of your operating system is vital here. You need to know the quirks and messages that it will give. Understanding of this information will quickly help you solve your issue much of the time. communicating with the user is also very important. You do not want them upset because they are not in the loop. Letting them know, in a general sense, is respectful to them and shows that you are professional in how you handle their problems. 

Another good source of information is a network topology map. I won't give any recommendations here but you can do an internet search in your favorite search engine for that term and pick something your comfortable with. I would start with something opensource and not just free, as you don't want to introduce any other problems into your network. Once going, this type of software can show you what is connected to your network and other information about all the devices. This is also vital for your network security.


Duplicate the Problem

 

Duplicating the issue at hand will be one of your first tasks. It can either be you or the user. How often it happens is useful information and will point you in the right direction. After you have duplicated the issue, see if there are conflicts with other processes running on that system.

Once you see the issue a good first step is just to restart the device. It does not matter whether it is a computer or printer. Sometimes things just go wrong with the software we use and a restart will help things greatly.

Another useful piece of information is whether the problem is affecting only this user or many others at the same time. Problems that affect lots of people at once are often connection issues. So, start by making sure your cabling and ports are in good shape. 



Looking for Changes


This is an important detail. Often, things will be working splendidly for a long time, then a program will just stop. This is usually because of a system change. Since users will not likely have admin credentials, it is often an operating system change. This could be a change by your department or by an update that changed a lot. 

Related to this area are your applications. Dramatic slowdowns or unusual behavior could be a sign that something is wrong. This is part of the change I mentioned above. Your applications could certainly just need updates but you want to gather as much information as possible, keep it organized, and monitor performance. You should have a good idea of how fast applications and their various tasks work.



Testing Your Fix


Once you have figured out something that has changed and that might be the reason for your problem, it is time to test it out. Doing this means on another, if possible, so that you do not cause more damage yourself. It is even better if you can do it in a virtual machine. By the way, you should always have an up to date virtual machine that is used for testing out issues.

It is a good tool to have. After you test, you can give it some time to make sure there are no unintentional issues that pop up. You will notice I am being overly cautious here and that is for inexperienced staff. 



Issues To Look Out For


A long time ago, routing loops used to be a thing. This was the purpose of the spanning tree protocols. They would help prevent and fix these kind of situations. However, if a network was set up right this should not ever be an issue. These problems included things like switching loops, routing loops and packets that could not find the right route.

Port errors can also be a problem. Since ports can be configured in different ways, sometimes an administrator would forget to allow it to send data through. An example of this is where a port would not let printer traffic through because it was on a separate vlan. Wrong network settings can also be a cause of problems. This includes subnet masks and gateway addresses. These will be different for each organization so make sure they are correct for your business.

The last one I will mention is dns errors. If this seems to be the case, you can flush the dns settings to see if that helps. That is trivial to look up so I won't go into it here. There can be many other issues but the above ones I listed are the most common in my experience. they apply to laptops, desktops, and printers.



Documenting What Happened


Whether you fixed it or not, documenting is part of the process. Putting the problem down in words helps you and those who come after you. This can in the form of a wiki, text notes, separate files in a shared drive, or an online editor. Whichever the case, be consistent and never stop doing it. I have a network essentials document for this purpose myself. You can even put this information into a public repository for your users so they can search and read articles of interest. It will save you from a few work tickets by doing this. 

 

Tools

 

There are many ways to gather information about a network issue. Here are of the most common.

ping 1.1.1.1

The ping command from a shell will give you basic connectivity information. It tells if the connection is successful and how long it took. However, sometimes the issues are intermittent and you need a bit more information from the ping command. That is when you try this.

ping -t 1.1.1.1

This option will ping continuously. This is good when you want to see if your intervals suddenly spike very high and then go back to normal. This can let you know there is indeed an issue to investigate more thoroughly.

tracert 1.1.1.1

This command stands for trace route. It shows you the path a packet took to get to its destination. The destination is the address after the command. It can be an IP address or a dns name. One thing this does is let you know if it took the correct path to its destination. You should do it occasionally so you know what path it usually takes. Then, if you are having issues, you will be able to see there is a problem if you are redirected somewhere else before the packet gets home. A packet can be redirected if a router is down somewhere in between, for example.

ipconfig

This is also a very popular command. It pulls the network information where you are at. It will let you know your ip address, subnet, and gateway address. With the /all option, it shows you different adapters you are using and mac addresses. It is a very handy utility.

 

Methods

 

The first thing you will want to do is check your hardware. This includes your machine, the network cable, and the network port on the wall your connected to. At your machine, make sure the cable is attached firmly and you can see blinking lights at the connector. Then make sure the cable is still in one piece and not overly twisted somewhere along the way. At the wall port, make sure it also is connected securely into the wall jack.

Next, use the commands I mentioned above. These include ping, tracert, and ipconfig. It is a good idea to use these regularly so you will have a baseline as to what the usual output looks like if you do not already know. That way, when it is different, you will be able to recognize it.  In case you are getting an IP address that starts with 169, that means you are not getting a valid one from your router. If that is the case then try this:

ipconfig /release

then

ipconfig /renew

These two lines have solved many network issues. I hope that it will be that simple for you when it happens.

If everything looks normal so far I would then check dns. The easiest way to check this is with the <nslookup> command.

nslookup

It should be pointing to your dns server. If you get errors here then you have probably identified your problem.

Subscribe

* indicates required