Manual

Channel Emulator using Netem

(Draft)

Muhammad Muhammad

February 1𝑠𝑡 2010

Contents
1 Introduction 2
1.1 Who should read this manual . . . . . . . . . . . . . . . . . . . . 2

2 Testbed 2
2.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Channel Emulator: Examples and Tests 6

3.1 Correlated Error Loss . . . . . . . . . . . . . . . . . . . . . . . . 7

1
1 Introduction
In this manual, we present a complete guide on how to build a testbed to sim-
ulate a close to reality scenarios for packets transmission over a wired/wireless
channels. Figure 1, shows a blueprint of the scenarios where the transmitter is
used to inject packets into the channel that delivers/drop these data segments
to the receiver connected to the other end of the link.

- Satellite Channel
- Mobile Channel
- Terrestrial Link
... Receiver

Transmitter

Figure 1: Testbed blueprint

1.1 Who should read this manual

This manual is forwarded for tele/communications engineers and/or computer
scientists dealing with network simulations. This means that, in order to un-
derstant what’s going on here, you should have a background in the previously
mentioned domains or explicitly in computer networks.

2 Testbed
In this section we introduce the testbed that as an end product will allow us
to emulate a channel. First, we will introduce the hardware needed to build-
ing it. Then, we will present the required software and finally a step-by-step
configuration procedure will take place.

Tx Router Rx

Figure 2: Testbed environment

Figure 2 illustrates that the packets are routed from the transmitter 𝑇𝑥 to the
receiver 𝑅𝑥 through the router. Rules for dropping the packets are implemented
for this direction, on the outgoing network card of the router, can also be done
for the return channel (but usually is not the case).

2
2.1 Hardware
In this section, we setup our testbed from three components, namely; the trans-
mitter, the receiver and the channel emulator.
Figure 3 represents the real testbed (our end product) after being put to-
gether. For this, we need some hardware:
Three PCs with Linux operating system (OS) installed on them. Distri-
bution is of no great deal, we recommend the usage of either Opensuse [1]
or Ubuntu [2].
Hint: Opensuse is more stable than Ubuntu, since it is developed for en-
dusers while the latter is used for development.
A minimum of 4 Ethernet cards (1 for the 𝑇𝑥 , 1 for the 𝑅𝑥 and 2 for the
router, which we will call it from now on 𝑅)
An extra Ethernet card can be used on each PC to connect to the Internet
(Recommended - for software updates), for that you need a normal cat5
[Network] cables, the dotted blue ones in Figure 3.
Two cross cables (to connect the 𝑇𝑥 and the 𝑅𝑥 to the 𝑅). The red cables
in Figure 3.

eth1
Internet

eth0
eth
2

Lin

Network 1
Network 0

ux
eth1

eth1

eth0
eth0

Router

Transmitter Receiver

Figure 3: The testbed

2.2 Software
After setting up the testbed as shown in Figure 3, we have to install some
software packages inorder to make our system’s parts able to communicate with
each other.
We need the following packages (please, bear in mind that these may have
already been automatically installed with the OS):

3
 ifconfig: to manually assign static IP addresses to the Ethernet cards.
route: to make routes from one Ethernet card to a network through a
gateway.
iproute2: contains the traffic control tc command (netem is included) that
will emulate the channel and handle packets from the 𝑇𝑥 .
Assuming that you can access the package install manager and install these
packages, Figure 3 shows that the transmitter is in Network 0 whereas the
receiver is in Network 1. This leads us to the configuration of the Ethernet
cards on every PC. In this manual, we will ignore the Network cards connected
to the Internet, you can simply use the GUI to make each of them require an
IP address from the Internet modem dynamically.

2.3 Configuration
For both transmitter and receiver, we will use eth0 as the card to connect to
𝑅. First, login to the 𝑇𝑥 and open a terminal, (use the admin account) and type:

 ifconfig

and a list of the network interfaces will appear such as: eth0, eth1, lo, etc...
This will allow us to check whether the network cards are functioning. Next,
we will configure our card:

 ifconfig eth0 down

 ifconfig eth0 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255
 ifconfig eth0 up

On 𝑅𝑥 (also with admin previliges):

 ifconfig eth0 down

 ifconfig eth0 192.168.1.2 netmask 255.255.255.0 broadcast 192.168.1.255
 ifconfig eth0 up

As you can see that the 3𝑟𝑑 Octet in the IP addresses given are different for
every PC i.e. the 𝑇𝑥 and the 𝑅𝑥 . This allows us to identify the end-nodes in
two different networks i.e. Network 0 and Network 1, repectively. Building on
this, now, we have to configure the two Network Interface Cards (NICs) in the
channel emulator.

We want to connect 𝑅’s eth0 to 𝑇𝑥 and its eth1 to 𝑅𝑥 . In other words, eth0 in
𝑅 should be addressed in Network 0 and eth1 should be connected to Network 1.

4
 From a Terminal in superuser or root mode on 𝑅, we check whether all NICs
are active by:

 ifconfig

then,

 ifconfig eth0 down

 ifconfig eth0 192.168.0.1 netmask 255.255.255.0 broadcast 192.168.0.255
 ifconfig eth0 up

and for eth1:

 ifconfig eth1 down

 ifconfig eth1 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255
 ifconfig eth1 up

A significant role to be done by the router is to be able to forward IP packets,

i.e. acting like a gateway (GW), that is to take these data or control packets
from one card and flush them to the other where rules from tc will be applied.
To do this, we want to turn ip forward flag on by:

 echo 1 > /proc/sys/net/ipv4/ip forward

The default is 0. However, this command will allow the flag to be reseted
after rebooting. We can avoid this is by altering the Linux kernel config file:
/etc/sysctl.conf, by setting the following value, using any text editor:

 net.ipv4.ip forward = 1

Even though, at this point, it is believed that 𝑇𝑥 can contact only eth0 on
𝑅, and so for 𝑅𝑥 connection can only be established with eth1 on 𝑅. However,
in order to make 𝑇𝑥 and 𝑅𝑥 communicate, 𝑅 has to route the packets from its
eth0 to eth1 and vise versa on the return channel (RT) for Acknowledgments,
for example.

Here comes the role of the route packet. At this point, we will tell 𝑇𝑥 to
connect to Network 1 through the gateway (gw) eth0 on 𝑅. This is done through
the following command:

 route add net 192.168.1.0 netmask 255.255.255.0 gw 192.168.0.1

On the other hand, 𝑅𝑥 will connect to 𝑇𝑥 i.e. Network 0 through the gate-
way on 𝑅 i.e. eth1 by:

5
 route add net 192.168.0.0 netmask 255.255.255.0 gw 192.168.1.1

Now, with a simple ping command, from the 𝑇𝑥 to the 𝑅𝑥 , we can verify the
connection establishment between the two entities through a channel emulator.
Try on 𝑇𝑥 :

 ping 192.168.1.2

It should provide with information about the ping messages sent and their
round-trip times in milliseconds (ms). At this stage, the amount of delay should
be very low.

3 Channel Emulator: Examples and Tests

In this Section, we will focus on the command tc and netem as the channel
emulator. NetEm functions as a channel emulator to emulate links such as, but
not limited to, Local Area Network (LAN), Wide Area Network (WAN), etc.. It
can emulate delay with some variations, random packet loss (correlated packet
loss does not function properly in the current version), duplication of packets
and packets re-ordering.

In order aquire a precise clock resolution and very good delay results you
have to recompile the kernel with 1000 HZ clock.

NetEm is a part of the 2.6.x Linux kernel and you can find it already in-
stalled with Linux distributions running these kernel versions such as Opensuse,
Ubuntu, Debian...

Access to netem functionalities is done through the tc command which is a

part of the iproute2 package.

Now, we will present some basic ideas about the usage of the command.
However, to get a complete understanding of the tc command and NetEm ex-
amples, you have to read [3] and [4], respectively.

Hint: always add the commands to the outgoing interface.

To add a fixed delay of 50 ms from 𝑇𝑥 to 𝑅𝑥 , login to 𝑅 as a superuser and:

 tc qdisc add dev eth1 root netem 50 ms

Now a simple ping as the one done in the last section will show that the
packets are delayed by 50 ms. If you want to change this delay to 75 ms and
include a 10 ms deviation, you simply do this:

6
 tc qdisc change dev eth1 root netem 75 ms 10 ms

Note: in the last example we simply substituted the add parameter with
change, since we already added the dev eth1.

You can also add delay as a distribution or correlation etc.. To add random
packet loss to the delay above, simply type:

 tc qdisc change dev eth1 root netem 75 ms 10 ms loss 10%

This command will delay every packet for 75 ms 10 ms variations and 10
percent of the packets will be lost, more or less.

3.1 Correlated Error Loss

As mentioned earlier, in Section 3, correlated error loss is wrongly implemented
in NetEm. However, some guys from the University of Rome fixed this by
implementing the NetEm Correlated Loss Generator (NetemCLG) [5] project
which is a patch meant to fix the problem.

References
[1] Opensuse http://www.opensuse.org/en/
[2] Ubuntu http://www.ubuntu.com/
[3] Netem Manual http://tcn.hypert.net/tcmanual.pdf
[4] Netem Examples http://www.linuxfoundation.org/collaborate/workgroups/networking/netem
[5] NetemCLG http://netgroup.uniroma2.it/twiki/bin/view.cgi/Main/NetemCLG