One of my biggest challenges as a network manager is when users cry “the network is slow”. Some of you may have tools available to you where you can instantly dig in and see what the user might be seeing. There are some vendors out there with application and network monitoring tools. Netscout is one that comes to mind. However, I don’t have tools like that available so I have to work through several layers of data collection methods and tools to get a picture of what might be happening. Maybe you are in the same boat. Getting an answer to “the network is slow” is not a simple or quick activity. How do you deal with this? Following are some ways that I use to try and address the situation.
The number 1 and 2 tools that can find out if there is a potential problem are ping and pathping (Windows XP). To test a network path between a client and host for latency and packet loss use a command something like:
ping -n 100 -l 1000 host.com
The -l is a LOWER case L. This command will send 100 pings of 1000 bytes each to host.com. This will give you latency for larger packets and also if there is any packet loss along the path. To get more details about where along the path packet loss is happening, use the command:
This also does some pings along the path but will inform you of where along a traceroute the pings are getting lost. Note that ICMP must be enabled along the path for these commands to give you the information you may need to resolve the problems.
If the network path and hosts are all on your private network, you may need to capture some additional performance data. This is where network diagrams and service diagrams come into play. In a typical webserver farm environment, there are potentially a lot of “moving” parts along the path between a client and an application. The application path between a client might go something like this:
client -> LAN switch -> router -> WAN link -> router -> LAN switch -> web server -> database/index server
And then return through the same or similar path. This example has 8-9 various connections/hosts that could impact client application performance. This is no longer just a network data traffic issue. I won’t be getting into the LAN switch or the router performance monitoring at this time. I will leave that for another posting. I will also make another entry discussing more about reviewing the server performance issues. Stay tuned.
So for now – share with the other ITKE readers ways that you look at network/application performance. What tools do you use to instrument and diagnose network issues?
Thanks for reading & let’s continue to be good network citizens.