If your company is like most companies large or small, it isn’t a matter of if your remote users will complain that the system is slow, but rather when. And, if part of that system involves reaching across the wide area network (WAN)
While there exists a multitude of ways to evaluate WAN performance, measuring WAN latency -- the amount of time it takes traffic to traverse the WAN -- is an excellent place to start. Simply put, an increase in latency is an increase in the wait time that your user is experiencing. Combined with delay related to other system elements like database access, a significant increase in WAN latency can mean a loss of user productivity or even a halt in operations.
While latency varies, it is common for a round-trip (out-and-back) time in many North American network deployments to be in the range of 35 to 70 milliseconds (ms) -- or well under 1/10th of a second. If latency suddenly jumps to, say, 1,500 ms, then your users will experience an additional second or so of wait time just from the WAN.
When help desk calls about performance degradation come in and you begin your problem isolation, you’ll need a few things:
- a quick-and-easy way to measure the current latency of your WAN; and
- a baseline of “sunny day” WAN latency measurements with which to compare current readings.
The good news is that if you are having WAN issues right now, measuring the current latency of your WAN is a snap. The bad news is that you can’t go back in time to measure latency when your network was trouble-free. So, if your WAN is currently running nicely, take those “sunny day” measurements now so that you have a basis for evaluation should things take a turn for the worse.
To measure the latency of your WAN, all you need is the humble, ubiquitous and free ping network utility. Ping is available on every implementation of TCP/IP so it does not matter whether you are using Windows, Apple OS X or a version of Linux -- the ping utility will be there.
Of course, to measure your WAN's latency, you'll want to ping across the links of your two WAN routers; thus, it makes the most sense to use those devices as the endpoints in your ping command. By default, most routers will respond to a ping, so you can at least get a general idea of WAN latency just by pinging the remote router from your own computer.
Similarly, most routers implement a ping command in their console support. So, one can easily Telnet to a console connection on one router and then ping the far-end router to measure just the link between the two.
Different implementations of ping will likely vary but most implementations will send, by default, four or five echo requests and report back the individual and average round-trip WAN latency as well as any packet loss. Under the hood, ping uses the Internet Message Control Protocol (IMCP) “Echo” command to trigger a response in the target IP system and, ultimately, provide measurement data.
The presence of any packet loss and/or significant variations in the latency of each echo, such as jitter, will immediately be signs that more investigation is required.
Ping can be configured to send different packet sizes and run multiple times; ping can also be configured to run continuously. Most operating systems will provide ways for you to automate running ping on a regular basis and then save the results to log files for possible future reference.
Do realize, however, that running ping produces some load on the network and on the network device responding to the ping. While the load of running ping a few times with typical default settings is trivial, it is best not to run ping nonstop without a valid reason.
In fact, ping can be a source of distributed denial-of-service attacks (DDoS). A device that is being barraged with ping requests spends all of its time processing the echo response rather than routing production data; thus, the useful throughput of the network device is degraded. To users, this could manifest itself as a slowdown in network response time. Because of this, a lot of large networks deliberately disable the echo response function in their routers to avoid being impacted by a ping-oriented DDoS attack.
At the end of the day, if your WAN is overburdened, it could be time for a bandwidth upgrade. Or, if it must carry low-priority, high-volume traffic along with time-sensitive VoIP and interactive traffic, it might be time to look at implementing a dedicated WAN bandwidth optimization solution to provide queuing and traffic management. In any case, the first step is to understand the load on your WAN -- and to do that, you must know how to measure WAN latency.
Read the other tips in this series:
This was first published in November 2011