Emulating WANs with WANem

I recently noticed someone on Twitter asking for software to emulate WAN connections for lab purposes. WAN emulation introduces artificial delay, bandwidth restrictions, and other impediments for the purpose of benchmarking applications and protocols against real-world conditions. I suggested WANem, having read a bit about it, but realizing that up that point I had never actually used it. What a great topic for a blog article!

Unfortunately, WANem version 2.2 does not appear to support IPv6, so at just two weeks into the new year I already have to bend my resolution.

Preparing the Network

We'll be using the following simple topology to emulate a WAN in our lab.

Note that although having two physically separate routed interfaces on the WANem server is ideal, WANem can also be used with a single interface.

Booting the ISO

WANem runs entirely from a bootable CD based on Knoppix and does not need to be installed permanently. Burn the WANem ISO to a CD or DVD and then boot the device to be used as the WANem server from that disc. It will take a minute or two for the boot process to complete, at which point you will be asked whether you want to use DHCP to configure the WANem interfaces. Answer no.

You will be presented a simple configuration screen listing all of the interfaces detected by WANem. Each can be configured to operate using DHCP or simple static configuration (IPv4 address, subnet mask, and default gateway). Save the configuration when you are satisfied.

WANem will start the Apache and SSH services (for remote administration) and then prompt you to set a password for the user perc. Enter a password of your choice, and again to confirm. At this point you should be dropped into the WANem CLI, a minimal command line interface to the server from which you can perform basic tasks such as reconfiguring interfaces or rebooting the server. Type help for a list of available commands. If needed, the command exit2shell will drop out of the WANem CLI to the Linux CLI as user root.

Endpoint Configuration

Address the two endpoints appropriately, specifying the WANem server as the default gateway for both. If using a single subnet for testing, add a static host route pointing to the WANem server on either host for the other. Ping to verify reachability between the endpoints through the WANem server.

WANem Configuration

WANem configuration is accomplished primarily through its web interface, reachable at http:///WANem/. Two modes of configuration are available: basic and advanced. Basic configuration is limited to specifying bandwidth and delay.

Advanced configuration provides far more extensive options, including jitter, loss, packet duplication, and packet corruption. Advanced rules are applied per interface, and can be configured to match only specific packets (similar to an access list).

For a detailed discussion of these options, consult the WANem documentation.

The save/restore option in the navigation menu allows for the export and restoration of WANem configurations. WANem also includes a tool dubbed WANalyzer which I have not played with.

Testing

Now that we're all set up, let's simulate some WANs. First let's give basic mode a try, just to verify that WANem is indeed operational. We'll limit eth1 to 1.544 Mbps to simulate a T-1 link. There is an option in the pull-down list for T-1 bandwidth; however, this sets the bandwidth to 1581 Kbps, apparently due to a conversion error. Set the bandwidth to 1544 Kbps by hand using the box at right. We'll also assign a delay of 50msec. After clicking "apply settings," you should see a message at the top of the page which reads "WANem is running."

We can run a ping from the client to verify the latency times:

Client$ ping 10.0.1.1
PING 10.0.1.1 (10.0.1.1) 56(84) bytes of data.
64 bytes from 10.0.1.1: icmp_seq=1 ttl=63 time=51.5 ms
64 bytes from 10.0.1.1: icmp_seq=2 ttl=63 time=53.0 ms
64 bytes from 10.0.1.1: icmp_seq=3 ttl=63 time=51.8 ms
64 bytes from 10.0.1.1: icmp_seq=4 ttl=63 time=53.0 ms
64 bytes from 10.0.1.1: icmp_seq=5 ttl=63 time=51.8 ms

On a more complex network, we might opt to run traceroute to verify that the latency is occurring at the WANem hop as expected:

Client$ traceroute -n 10.0.1.1
traceroute to 10.0.1.1 (10.0.1.1), 30 hops max, 60 byte packets
 1  10.0.2.1  0.380 ms  0.359 ms  0.351 ms
 2  10.0.1.1  52.624 ms  52.614 ms  52.602 ms

So far, so good. Now let's move on to the advanced configuration. We'll create a rule for interface eth1 specifying the following parameters:

• Bandwidth: 1544 Kbps
• Delay: 60 msec
• Jitter: 15 msec
• Loss: 2%
• Packet reordering: 2%

Leave all other settings at their default values. After applying these settings, we can use a tool such as mtr to verify our WANem settings. Let mtr run for a few minutes to collect a broad enough sample.

We can see from the output of mtr that WANem appears to be working, mostly. The average loss is calculated at 2.5% and the average delay at 61.5 msec, not far off from our targets. The worst delay noted is right around 75 msec (78.9 msec) as was to be expected, however there is some anomaly concerning the least delay: the "best" time reads only 0.2 msec, indicating that either mtr or WANem has not been doing its job correctly. These artificially low pings account for the standard deviation (StDev) of 11.2 msec, which should be closer to 15 msec (our jitter setting).

Finally, let's test our bandwidth limitation using iperf. The client options passed below instruct iperf to run for 30 seconds using 4 parallel tests. (iperf was started on the server using the command iperf -s with no options.)

Client$ iperf -c 10.0.1.1 -t 30 -P 4
------------------------------------------------------------
Client connecting to 10.0.1.1, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  4] local 10.0.2.2 port 55455 connected with 10.0.1.1 port 5001
[  6] local 10.0.2.2 port 55456 connected with 10.0.1.1 port 5001
[  3] local 10.0.2.2 port 55454 connected with 10.0.1.1 port 5001
[  5] local 10.0.2.2 port 55458 connected with 10.0.1.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0-30.3 sec  1.55 MBytes    431 Kbits/sec
[  3]  0.0-30.4 sec  1.52 MBytes    420 Kbits/sec
[  4]  0.0-30.5 sec  1.17 MBytes    323 Kbits/sec
[  6]  0.0-30.7 sec  1.27 MBytes    346 Kbits/sec
[SUM]  0.0-30.7 sec  5.52 MBytes  1.51 Mbits/sec

iperf confirms that our bandwidth limitation, after factoring in the 2% loss, is right on track.

I encourage readers to play around with WANem and see how accurate its results are. Another application named wanbridge, similar to WANem, has also been recommended but I haven't yet set it up. Anyone else want to give it a shot and report back?