Network problems particularly those related to speed and performance can be extremely difficult to diagnose. Unfortunately they can also cause the most impact as anyone who has ever worked in a besieged IT department will have experienced if their network is running slow. One of the main issues that a high network latency rarely gets better, as the problems start multiplying as error controls of protocols like TCP and application issues start to increase as the speed falls. Even something like retransmissions can cause a huge impact on overall network performance if not solved quickly.
However there is an important task that you can complete even if everything is running smoothly on your network, in fact this can make troubleshooting any future issues an awful lot easier. It’s called creating a network baseline, a critical piece of information that can literally save hours of effort in fixing problems like a slow network.
It consists of something quite straight forward, yet invaluable – a selection of snapshots of your normal network traffic. These can be created with any packet sniffer, simply download a copy of Wireshark for example if you don’t want to spend any money. Load it on to your laptop and then set it running creating a series of traffic captures from various points in your network. Select a few strategic hub or switches, use span ports if possible to get the most complete picture and then carefully label and store each file somewhere. Many people also save this information with their Disaster Recovery information as it can be invaluable if you have issues in a DR situation.
The idea is to create a baseline of ‘normal traffic’ on your network, a list of used protocols alongside a list of active devices (including servers and clients) using them. It’s sounds quite simple but this information is invaluable if things are going wrong and you need to distinguish what’s going wrong on something like a slow network. It’s a basis of comparison, a list of what your network looks like when things are all working. Sometimes a fix might be obvious, like when you discover that because of Netflix blocking VPN services that everyone’s started using the companies proxy to watch box sets from work! It’s amazing how useful this information can be when troubleshooting.
Take for example a situation where you see multiple clients on a network working very slowly when trying to access a vital company web based application. Run a current packet trace and look at the traffic and everything might look ok, but if you compare with the baseline you might see something instantly – perhaps a series of external US DNS requests such as these which didn’t occur in the baseline. This could be the cause of the issues, why is an application server heading out to the internet for name resolution? It could be an error in the code, or perhaps an internal DNS server is not operational – either of these could affect application performance.