Emulating WANs with WANem
By stretch | Wednesday, January 12, 2011 at 2:28 a.m. UTC
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.
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 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.
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?
Posted in WAN
January 12, 2011 at 5:31 a.m. UTC
Nice post. What kind of commercial alternatives are available. Would they be more accurate? Guess you might need some special hardware to increase accuracy. Good tool for trying different window sizes etc for different RTTs I would guess.
January 12, 2011 at 7:52 a.m. UTC
I use wansim (http://code.google.com/p/wansim/), not as sofisticated perhaps, but it does what I want.
January 12, 2011 at 11:35 a.m. UTC
another good solution is: http://www.linuxfoundation.org/collaborate/workgroups/networking/netem
January 12, 2011 at 1:11 p.m. UTC
You can also use directly the Net:Netem module of the Linux 2.6+ kernel. I have written a post on my blog (in french but easy to translate...):
January 12, 2011 at 3:03 p.m. UTC
Thanks for the post. Think I'll check this and some of the others commented out.
January 12, 2011 at 3:07 p.m. UTC
FreeBSD's netgraph is pretty powerful for this as well. And you can run IPv6 over it (as I imagine you could with Netem on Linux).
January 12, 2011 at 3:39 p.m. UTC
hi jeremy, i thought you know GNS3, didnt you? so what do you think about this network simulator, isn't just a bit more real world than this WANem thing? huh?!!!!
January 12, 2011 at 4:19 p.m. UTC
The goals of each WANem and GNS3 are different: GNS3 is an IOS simulator for learning IOS and simulating configurations. WANem allows you to put a server in a real lab network to test different WAN performances for applications. I can tell you, testing latency for applications is good knowledge if the guys doing the coding or SQL queries arent taking WAN performance into account.
Does anyone have any experience on running this in a VM and if the performance is comparable to a physical machine?
January 12, 2011 at 7:52 p.m. UTC
http://www.dummycloud.com/ is another option.
January 19, 2011 at 3:05 p.m. UTC
I have used Monowall for WAN Emulation with good success. It is marketed as a firewall but has features for adjusting Bandwidth, delay, packet loss, etc.
The feature list claims it supports IPv6, but I have not tried that myself.
January 19, 2011 at 7:33 p.m. UTC
Shunra, a commercial offering (http://www.shunra.com) is also good.
January 24, 2011 at 6:19 p.m. UTC
January 25, 2011 at 10:47 a.m. UTC
great post - will need to have a play with it
January 28, 2011 at 11:16 a.m. UTC
The latest distribution of vyatta has a GUI build around the netem simulator. It works ok, and saves you time building a command string. I'm going to test the WANem, keep you updated with the results,
February 20, 2011 at 8:30 p.m. UTC
Yes, WANem can be run as a VM box using Virtualbox. You can setup a couple of Slitaz boxes, define virtual adapters for them using GNS and then simulate a WAN link complete with host to host data transmission across the virtual WAN link.
August 2, 2012 at 10:23 p.m. UTC
I used the WANem Software about 2 years ago and I compared it to the ANUE network impairment tool. The anue product is more sofisticated product but at a 15K price point. The WANem was about the cost of the download. Both performed for me well. If you are doing periodic wan emulation that needs to test software then wanem can't be beat. but If you want to provide to the customer (US gov't)metrics and show that you followed specific guidelines when setting up an environment for systems under test then Anue is the only way to go.
March 10, 2015 at 11:43 p.m. UTC
I use WANem for testing adverse network conditions for WebRTC apps. I have it bridged to a router and use it extensively.
It's quite useful but there can be discrepancies, especially in the way it imposes jitter on packets... it's good for adverse testing but doesn't seem to really simulate anything close to real-world jitter on audio/video packets.