Building a BAD Network with Dummynet

Strong Electric Connection

We typically strive to build networks that are fast, error free and introduce minimal latency. However, there is sometimes a need to build something that doesn’t work well. One use case might be to test real world application performance against an SLA being proposed by a service provider. The SLA may include things like a sub-rate bandwidth, maximum latency, or a given percentage of random packet loss. In any case, creating a lab to mimic this behavior may seem challenging. This article introduces a quick and easy way to create a network that predictably misbehaves based on configured parameters.

For this article, the focus will be on creating a two port switch using FreeBSD. Then the forwarding characteristics will be tweaked to accomplish the goal of making the network misbehave. I spent a considerable amount of time working with different platforms and products until I found a combination that worked well for me. I wanted to take the time to document this in enough detail that it can be easily reproduced by others.

BridgedEnet

For my testing, I used FreeBSD version 9.2 in VMWare Fusion. The host operating system used was Mac OS X version 10.9.1. Since this was running on a MBP Retina, I used two Thunderbolt Gigabit Ethernet adapters. These adapters were configured in Bridge mode and dedicated to VMWare Fusion. The interfaces, seen as em0 and em1 on my system, may be named differently if built on a physical host.

The installation of FreeBSD didn’t require anything special. I even skipped the network configuration so I could perform it manually after the installation was complete. This allowed for the manual configuration of the two port Ethernet bridge. My network interfaces, again “em0” and “em1”,  are reflected in the rc.conf.local file below. To create the bridge, a similar file can be created for your particular installation.

Create the /etc/rc.conf.local File

#/etc/rc.conf.local
#BRIDGE CONFIG
cloned_interfaces=“bridge0”
ifconfig_bridge0=“addm em0 addm em1”
ifconfig_em0=“up”
ifconfig_em1=“up”

At this point, it is probably a good idea to confirm the bridge works. The network can be brought online be rebooting or executing the command below.

sh /etc/netstart

At this point, the device should behave as a two port switch. To confirm functionality, we can send some traffic through it with a couple of attached devices.

Test Traffic (between physically attached routers)

R1#ping 192.168.100.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/6/12 ms
R1#

With a functional bridge, we can move forward with the configuration of Dummynet. This requires several steps. I recommend editing all of the configuration files outlined below, then rebooting. Doing so, will keep any dependency issues from occurring due to incorrect execution order.

Create /boot/loader.conf File With Dummynet Enabled

#/boot/loader.conf
dummynet_load=“YES”

Configure Required Parameters in /etc/sysctl.conf

#/etc/sysctl.conf
net.link.bridge.ipfw=1
net.inet.ip.fw.verbose=1
net.inet.ip.fw.verbose_limit=5

Create The IPFW Configuration Script /etc/ipfw.rules

#/etc/ipfw.rules
ipfw -q flush
ipfw add pipe 1 ip from any to any
ipfw pipe 1 config delay 0ms plr 0

Additional Configuration in /etc/rc.conf.local for #IPFW

#/etc/rc.conf.local
#BRIDGE CONFIG
cloned_interfaces=“bridge0”
ifconfig_bridge0=“addm em0 addm em1”
ifconfig_em0=“up”
ifconfig_em1=“up”

#IPFW Config
firewall_enable=“YES”
firewall_type=“open”
firewall_script=“/etc/ipfw.rules”

At this point, a reboot should prepare the Dummynet for use. After rebooting, it probably makes sense to test the unimpeded network function one more time.

R1#ping 192.168.100.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/5/12 ms

Now To Configure Dummynet Parameters

To change the quality of the network and confirm that dummynet is functioning, we can increase the delay.

[email protected]:~ # ipfw pipe 1 config delay 100ms

The delay should be roughly twice the configured value. This is due to the ICMP Echo and Echo Replies having to traverse the link in opposite directions.

R1#ping 192.168.100.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 197/199/202 ms

Other values that can be manipulated include bandwidth and plr (random packet loss). This can all be combined into a single command.

[email protected]:~ # ipfw pipe 1 config delay 100ms bandwidth 10Kbit/s plr 0.1

This command would randomly drop 1 in 10 packets, restrict the bandwidth to 10Kbits per second, and provide one-way delay of 100ms. To confirm the worsening network, we can expand our previous test.

R1#ping 192.168.100.1 repeat 100

Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 192.168.100.1, timeout is 2 seconds:
!!!!!!!!!!!!.!!!!!...!!!!!!.!!!!!.!!!!!!!!!!!!.!!!!!!!!!!.!!!!!!!!.!!!
!!!!.!!!!!!!!!!!!!!!!.!!.!.!!!

Setting any value back to zero, removes associated restriction imposed by dummynet.

[email protected]:~ # ipfw pipe 1 config delay 0ms bandwidth 0Kbit/s plr 0
R1#ping 192.168.100.1 repeat 100

Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 192.168.100.1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/2/4 ms

To gain a bit of insight into the function of dummynet, the following command can be used.

[email protected]:~ # ipfw pipe 1 show

ipfwshow

Dummynet seems to be a relatively stable way to simulate network issues. Combining it with a simulated Ethernet bridge allows very flexible test scenarios to be created. The primary drawback seems to be that it isn’t supported on all of the typical *NIX platforms.

Have you used dummynet or other mechanisms to simulate network performance issues? Share your experiences by commenting below.

 

No related content found.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in How-To. Bookmark the permalink.

8 Responses to Building a BAD Network with Dummynet

  1. Robert Blacquiere says:

    Hi why would you put in the extra overhead of running dummynet in a vm? MacOSX has dummynet support build in. Not everybody knows latest MacOSX has ipfw and pf available for “custom” rules.

    Regards

    • Paul Stewart, CCIE 26009 (Security) says:

      That is a good question. To be completely honest, I started down that path. I had no issues building a bridge in OSX. However, I never successfully imposed limitations using ipfw/dummynet. I know that some people have got this to work on the Mac in the past. So I’m curious to hear the details and may try it again myself in the near future.

      In addition to that, FreeBSD does offer some advantages. The fact that it is openly available to everyone means that anyone can do this. I wasn’t necessarily advocating running this in a VM, but demonstrating the process of creating the solution to tweak link quality. It would be easy to migrate over to physical hardware or even insert in path of an environment in VSphere. The choice would really be made on an as needed basis.

      Great question. Thanks for the comment.

  2. Pingback: Network Link Conditioner - Simulating a BAD Network - PacketU

  3. Christian says:

    Do you have any suggestions for additional resources on this topic? I’m trying to get a box set up to use for some application testing, but I’m struggling to get ipfw/dummynet to actually have any impact on the network traffic. I’m not finding much helpful documentation on the topic of debugging dummynet.

    • Paul Stewart, CCIE 26009 (Security) says:

      When I initially started working on this, I had issues getting it to take effect too. What I found was that rebooting after getting everything configured resolved it. So basically, I recommend rebooting prior rc.conf.local file. Your issues could be different. But I found that to help for me.

      • Christian says:

        The problem appears to be something different between FreeBSD9.2 and 10.0. I initially used 10.0 because I figured this was such a basic setup it should work in 10 as well as in 9 right? Apparently not. I rebuilt the box with 9.2 and it started working right away.

  4. Robert Blacquiere says:

    Debugging ipfw dummynet rules is best done with log statements with the ipfw matching rules and ipfw pipe show, ipfw queue show if i remember correctly. For dummynet rules howto’ s and info take a look at http://info.iet.unipi.it/~luigi/dummynet/ . I think this would help you.

    Regards

    • Christian says:

      Thanks Robert, I had found that site but was having trouble gleaning much from it. Probably just need to spend more quality time with it.

Comments are closed.