How to turn your Linux box into a WAN simulator

Version 1


    1. A PC with two network cards.

    2. A Linux distribution with a Linux kernel of 2.6 or higher. (tested with Ubuntu 7.10)

    3. A copy of

    4. A basic understanding of IP routing.

    5. A smart switch (one that can do VLANs), or up to two dumb switches.

    6. A PC to test with.


    Configuring your lab

    To configure your lab you'll need to plug the WAN simulatorthis is PC with the two NICsinto the first VLAN and second VLAN. If don't have a smart switch then plug the WAN simulator into the dumb switch(es). It is important that the WAN simulator's network ports not be plugged into the same broadcast domain.


    Linux Config

    Now you'll want to get Linux running on your WAN simulator. You can either install Linux or use a live CD, it doesn't matter. However, if this will be a permanent setup then I would strongly recommend that you install Linux. Having a permanent configuration will allow you to install other tools on the WAN simulator like MRTG or a web server like Apache.


    IP Config

    Next you'll need to configure an IP addressing scheme for your new WAN lab. I'll discuss two possible configurations you can use standalone and integrated. Standalone means that your test Core Server and clients are not connected to some other network; they are plugged into the single smart switch, or they are plugged into one of the two dumb switches only. Integrated means that the test Core Server and clients communicate to each other through the WAN simulator. So the WAN simulator is routing between the larger network and the WAN test segment to accomplish this.


    Standalone IP

    The standalone configuration is the easiest to setup. In this scenario I assume that your Core Server and client(s) have already been installed and configured. At this point we'll need to make a distinction between the two segments and I have cleverly labeled them Segment A and Segment B. See the following for A’s & B’s configuration:

    Segment A


    Subnet Mask:



    Segment B


    Subnet Mask:



    Because the WAN simulator has two NIC's we'll need to keep them separate and so I will call these two things, Thing One and Thing Two. Wait, those names belong to Dr. Seuss already. We'd better just call them eth0 and eth1 instead. Eth0 will be plugged into Segment A and it will serve as the default gateway for this segment. Eth1 will be plugged into Segment B and it will serve as the default gateway for this segment. The Core Server should be placed into Segment A, and the client will be placed into Segment B. See the following for IP configuration of the Core Server and client:

    Core Sever


    Subnet Mask:





    Subnet Mask:



    Note: For name resolution you'll have to add each machine's name and IP to the other's hosts file.

    Note: The WAN simulator will not be forwarding packets just yet, so don't panic.



    The integrated configuration will require more effort to setup, but is closer to what a production network would look like. I strongly recommend the WAN simulator be integrated with a network used only for testing purposes and NOT your production network. The reason for this is because there will be a few changes to the network infrastructure required for WAN simulator to function correctly.


    The first step is to determine what the IP subnet is going to be for the segment behind the WAN simulator. Now would be a good time to decide if you want DHCP requests to work on this new IP segment. If you do want DHCP to work you'll need to add a DHCP helper module/program to your WAN simulator; consult your distribution's documentation for adding a DHCP helper. Also, this new IP subnet will need to be added to the network's DHCP server.


    The second step is to identify your static IP addresses for the WAN simulator. The first static IP address is for the interface facing the rest of the test network. This IP address will be used to route packets to the new IP subnet which is sitting behind the WAN simulator. The second static IP address is used for the interface connected to the new IP subnet.


    The third step is to configure the network infrastructure so packets can be routed to the new IP subnet. If you are not sure on how to do this then work with your network administrator to get this accomplished.


    The final step is to add your client to the new IP subnet. You'll want to configure this machine with a static IP address if you chose not to enable DHCP forwarding (DHCP helper).


    Note: The WAN simulator will not be forwarding packets just yet, so don't panic.


    Configuring WAN simulation

    The attach perl script ( will help with the rest of the configuration. This script will enable ip_forwarding in the kernel and pass parameters to the tc command. Before you can run you may need to flag it as executable. To flag as executable:

    1. Open a terminal window.

    2. Change directories to the folder containing If you have copied to your home directory then this step shouldn’t be necessary.

    3. Type

      sudo chmod +x ./



    Using to limit bandwidth and increase delay

    Now that is flagged as executable we can us it to configure our WAN simulator. Below is a simple example that sets the bandwidth to 128 Kbps and delay at 200ms.

    sudo ./ DEV eth1 200ms 128000bps


    Note: You can shortcut the speed by adding K|M|G in front of bps


    Undo what did

    Here is an example of how to undo or remove the settings that changed.

    sudo ./ DEV eth1 remove


  help output

  is a perl script that makes it easier to set tc command delay and bandwidth settings.

    Usage: DEV interface [remove] [delay] [bandwidth] [help]

    |DEV|Indicates that a network interface is to be configured.|

    |interface|Specifies the interface to be configured.|

    |[remove]|This will remove WAN simulation settings on DEV|

    |[delay]|Delay in milliseconds of each packet. Note: must end in "ms"|

    |[bandwidth]|Bits per second sent. Note: must end in"bps"|

    |[help]|This message.|