Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

How to set up WAN simulators to test branch application performance

A wide area network (WAN) simulator is necessary for enterprise IT architects and engineers to ensure acceptable application performance to end users at branch offices. In this tip, learn how to set up any generic WAN simulator to conduct network performance testing.

When deploying applications to branch offices, it is essential for network architects to assure a good user experience...

for WAN-based applications. The best way to do this, of course, is to deploy the application in the actual remote office as a test. Given that this approach is rarely practical for many reasons (i.e., the associated costs of testing a live network; the limitations of manipulating globally dispersed connections), WAN simulators offer network engineers a means to build a very accurate model of the actual branch-to-headquarter network in the lab. In this tip, we’ll learn how to predict branch office application performance using a generic WAN simulator. Below is a series of steps WAN engineers should take in order to properly set up a WAN simulator:


Step 1: Set up the WAN cloud

Whether you use a high-end network simulator -- from vendors like Anue Systems or Shunra Software -- or one of the less sophisticated freeware packages, the simulator representing the WAN cloud will generally be implemented as an appliance or a PC that presents two Ethernet connections -- one representing each “side” of the simulated network.

It is important to designate one side of your test bed to represent the headquarters or main location and the other to represent the remote system. Not only will the applications be different -- with the server at the headquarters and the client at the remote site -- but the bandwidth characteristics will likely vary as well.

What we envision as the WAN cloud is really more like a set of plumbing pipes. And, where traditional dedicated T1 circuits provide the same bandwidth in both directions, that is not the case with Internet broadband connections, which are used more often today.

These connections are almost invariably asymmetrical, because the speeds available for download and upload are different. Thus, when we see a DSL provider advertise a service as “1.5 Mbps / 128 Kbps,” they are telling us that traffic directed to the service location will move at 1.5 Mbps, where traffic emanating from the location will enter the Internet at 128 Kbps -- a traffic rate less than 10% as fast as the download. This will be a critical parameter when the time comes to configure the WAN simulator.


Step 2: Connect your simulated offices into the WAN cloud

You should on having two small switches or hubs available for your test environment. One will be used to provide connectivity for all test computers at your simulated branch office, and one will be used to predict all the test computers at your simulated headquarters location. Connect one port from each switch to one of the two Ethernet ports in your WAN simulator.

The WAN simulator will generally also function as an IP router so that, like in the real world, the headquarter's site and the remote office will exist on different IP sub-networks.

For testing purposes, you need only basic Layer 2 switch/hub functionality, so any small device will work. A hub is frequently a better choice for this kind of test, because with hubs, all traffic can be seen on all ports. This makes it easy to plug in a network analyzer to watch all that is going on at the frame and packet levels of your traffic. Fast Ethernet connectivity is fine for your test; Gigabit Ethernet is not necessary. Just remember, whatever you use, you must provide separate LAN connectivity for each “side” of the connection.


Step 3: Provide visibility into WAN traffic by setting up a network analyzer

It is a good idea to set up a computer with a network analyzer like Wireshark and passively monitor the traffic. This provides additional insights into any problems such as TCP retransmissions triggered by congestion and/or lost packets during your test. A network analyzer also provides good visibility to all traffic traversing both sides of the network.


Step 4: Provision your test applications

With the basic infrastructure in place, it is time to load the applications to be tested. Depending upon your company’s policies, you may be able to simply connect your test bed’s headquarter network switch/hub to an existing test or live server. As long as that resource is on the same campus network, your test will work no matter where the server lies on your headquarter site since the bandwidth between your test bed and the server will likely far exceed the WAN bandwidth settings you’ll use in your test.

On the remote side of your test bed, you’ll need to outfit one or several client machines with the applications you intend to assess, across the simulated WAN. While beyond the scope of this tip, it goes without saying that you’ll need to create application use/traffic levels that are representative of what you expect to see across the network once the application is deployed.


Step 5: Configure WAN simulator parameters

Now all you need to do is configure your WAN emulator, and you are ready to test application performance. As noted earlier, you will need to specify the bandwidth that you want to make available in each traffic direction. (Generally, the headquarter Internet connection will be a high-speed, dedicated link, rather than an asymmetrical broadband link. Thus, our main concern is the traffic rates that the remote office will be presented with.)

Be sure to designate the traffic flowing to the branch office to the higher download speed and the traffic flowing from the branch to the lower upload speed. Use an FTP transfer separately in each direction to confirm that your settings are correct.


Step 6: Validate your WAN simulator settings

From this point, there are at least three ways to validate your WAN settings:

  • The WAN emulator will likely provide a running average of throughput;
  • A network analyzer connected to either side of the network can provide a running average;
  • You can divide the file size of the transferred file by the transfer time to get a rough estimate of the effective speed.

If you configured the WAN simulator correctly, any and all of these numbers should be in range of the settings that you configured

Also, make sure that you are aware of the various broadband speeds at the respective locations where an application can be deployed, as they vary from cable to DSL -- even within each broadband type, there are different levels of services with differing transmission speeds.


Step 7: Explore other WAN simulation settings

After finishing your basic WAN testing, you’ll likely be wondering what to do with all of the other configurable parameters offered by your WAN simulator. After the basic bandwidth settings, I recommend running tests with varying values for latency and packet loss.

Latency is generally low, less than 100 ms, for broadband Internet connections. If, however, your remote office will be reached via satellite, you must run tests that simulate satellite latency times to get a true idea of how your applications will run, since latency of satellite connections tend to be 550 ms -- or half a second.

While packet loss is generally low on Internet connections, it is never a bad idea to run tests at, say, 1, 5 and 10% loss levels to see how your application reacts. Best case, it continues to run -- albeit slowly -- at the higher levels as it re-transmits packets. Worst case, your application just freezes or crashes -- which is something you want to be aware of before it ever happens.

In conclusion, delivering applications to branch offices running across broadband is one of the more challenging requirements for enterprise networking specialists; however, using WAN simulation tools and techniques can provide you with accurate modeling of performance, and ultimately architect branch office solutions that can meet the expectations of your end users.

This was last published in January 2011

Dig Deeper on Network application performance