Asymmetric Links and Jitter

Asymmetric link effects can now be configured using the CORE GUI. A new Unidir. >> button in the Link Configuration dialog (when you double-click a link) will expand to show unidirectional link effects. When collapsed, the specified parameters are used bidirectionally.

Below is a screenshot of the expanded dialog. The parameters on the left are for downstream (e.g. for a link from n1 to n2, traffic going from n2 to n1) and upstream on the right.

Jitter

Also a new jitter parameter has been added. Like delay, this value is in microseconds, and specifies a random variation in delay for each packet. See this netem page for details. If you're curious about which tc netem rules that CORE is using, turn on the "-v" verbose logging option in the daemon:

16276: linkconfig: [['/sbin/tc', 'qdisc', 'replace', 'dev', 'n1.eth0.69', 'root', 'handle', '1:', 'tbf', 'rate', '512000', 'burst', '3000', 'limit', '65535']]

16276: linkconfig: [['/sbin/tc', 'qdisc', 'replace', 'dev', 'n1.eth0.69', 'parent', '1:1', 'handle', '10:', 'netem', 'delay', '45000us', '7000us', '25%', 'loss', '0.0%', 'duplicate', '0.0%']]

Caveats

There are a few caveats with asymmetric link effects. To get unidirectional link effects in a wireless model (using the WLAN), look to the EMANE Comm Effect model. The basic on/off model can only support on/off connectivity and uniform effects for the WLAN network as a whole. The asymmetric effects can be used between layer-3 nodes (router, PC, host, etc.), between hubs/switches, and links with RJ45s -- but not for a link between a hub/switch and another node.

Links between hubs/switches and other nodes only have a downstream effect. The round-trip delay (RTT) in the example above is 5ms between n1 and n2 (not 10ms) and 3ms between n1 and n3. This is because CORE is configuring the netem queue, which is outbound queuing only, on one of the veth pair interfaces, highlighted in yellow in the diagram below.

To get a round-trip delay using a switch, configure half the delay on all of the links to the switch (e.g. use 1.5ms on all links for a 3ms round-trip delay.) This could be fixed in future revisions by adding a netem queue on the outbound interface (e.g. the white veths in the diagram) inside the namespace, or by using inbound netem queuing with IFB devices.

traffic flows using MGEN

A new Traffic Tool has been added to the Tools menu. You can use this tool to create traffic flows between source and destination nodes.
When you click to create or edit a flow, the dialog shown below appears. Clicking on the source node button allows you to choose a node that will send traffic and destination node a node that will listen and log received traffic. IP addresses are automatically entered based on selected nodes, or you can choose addresses from a list. A few preset traffic patterns are defined to help get you started using MGEN.
When the scenario is started, MGEN scripts are generated on each of the nodes. Each flow has a start (and optional stop) time. You can choose to autostart all flows after the emulation is running or manually start and stop them.

To use this feature, you should get MGEN from here. The nightly snapshot for MGEN and protolib are recommended.

distributed emulation with Linux netns

Starting with SVN r133 you can use distributed emulation on Linux for wired networks. For wireless networks (WLANs) you should still use EMANE. GRE tunnels are automatically built between emulation servers.

The Emulation Servers dialog is shown below. This hasn't changed. Be sure to set listenaddr = 0.0.0.0 in your /etc/core/core.conf before starting cored.py (the default listen address is localhost.)

One of the easiest ways to assign nodes to servers is to select a group of nodes and right-click on them, then choose Assign to...
Nodes belonging to different servers need a tunnel between servers to forward data. This is indicated in the GUI with a dashed link line.
The above screenshot shows a gt.42243.61 device added to one of the Linux bridges. This is the GRE tunneling device automatically generated on one of the servers. The gretap device type is used, a gre having a MAC address, so that it may join an Ethernet bridge.

ebtables and 64-bit OpenVZ Linux kernel

CentOS 5.4 doesn't have its own ebtables package, so we use the ebtables package found in the EPEL repository. Unfortunately, when you install the x86_64 OpenVZ kernel onto your 64-bit CentOS 5.4, this ebtables (ebtables-2.0.8-1.el5.x86_64) package doesn't work:

# ebtables -N test -P DROP
The kernel doesn't support a certain ebtables extension, consider 
recompiling your kernel or insmod the extension.
#

And the kernel gives us this message:

# dmesg | tail
Ebtables v2.0 registered
kernel msg: ebtables bug: please report to author: entries_size too small

If you download the latest ebtables source (ebtables-v2.0.9.tar.gz) and do a make && make install you experience the same problem. When you build with make static things appear to work somewhat, but some commands still fail.

The solution is to fall back to the year 2003 and get ebtables-v2.0.6.tar.gz. You'll need the three patches found here: 2.6.20.patch, gcc4.patch, and iets.patch.

Here is how to make it work:

> tar xzf ebtables-v2.0.6.tar.gz
> cd ebtables-v2.0.6.tar.gz
> patch -p1 < ~/2.6.20.patch
patching file include/linux/netfilter_bridge.h
> patch -p1 < ~/gcc4.patch
patching file extensions/ebt_ip.c
patching file extensions/ebt_limit.c
patching file extensions/ebt_vlan.c
> patch -p1 < ~/iets.patch
patching file ebtables.c
> make
> sudo make install

Now you'll have a working ebtables, but with 2003 syntax. This means some commands won't work, such as:
ebtables -N test -P DROP
now must be written as:
ebtables -N test; ebtables -P test DROP
or
ebtables -I FORWARD -j ACCEPT
now requires a rule number:
ebtables -I FORWARD 1 -j ACCEPT

Maybe there is a better solution out there?