HOWTO Use CORE to test ns-3 protocols

From Nsnam
Jump to: navigation, search

Main Page - Current Development - Developer FAQ - Tools - Related Projects - Project Ideas - Summer Projects

Installation - Troubleshooting - User FAQ - HOWTOs - Samples - Models - Education - Contributed Code - Papers

The Common Open Research Emulator (CORE) is a framework for managing Linux LXC containers, aimed at network experimentation. CORE can be used to manage virtual machines that can be used to interact with ns-3 nodes. Specifically, ns-3 can be run in emulation mode from within one of the containers. This HOWTO walks through the configuration of one such example, by starting a CORE emulation, reconfiguring a network device in one of the containers, and then running an ns-3 program from within the container.

The main use cases described here are how to use CORE to perform interoperability testing of ns-3 protocol implementations with Linux implementations. There are some other possible use cases involving the use of ns-3 as an underlying wireless model for CORE.


This section mainly points at existing documentation for CORE and ns-3. We recommend reading at least the first two chapters of the CORE manual and trying to install and run CORE independently of ns-3.

If you have not done so, we recommend going over HOWTO make ns-3 interact with the real world to review emulation options, as well as the manual chapter on the FdNetDevice.

This HOWTO is focused on Linux, a prerequisite for ns-3 FdNetDevice and CORE.

Firewall configuration

Most Linux distributions have default firewall policies that, when enabled, make it difficult to use CORE and ns-3 in emulation. These rules can be observed by running the following command:

 sudo iptables -L

It is recommended to either delete the rules or stop the firewall service while running experiments as described below. However, do not forget to re-enable them when you are done, and be aware of the hacking that you may expose yourself to if running in a public network (which is not advised for this HOWTO).

For example, a graceful way to perform this operation in Ubuntu is:

 sudo ufw disable

and then when you are done experimenting:

 sudo ufw enable

If you are good at firewall config, you may instead prefer to punch holes in the existing policy configuration to enable your experiments. This is clearly safer than deleting all rules, but a tutorial on that is beyond the scope of this HOWTO.

Testing your CORE installation

If you think you have CORE installed successfully, try a two-node ping test. First, ensure that the core-daemon is running in the background:

 sudo /etc/init.d/core-daemon status

if it doesn't display

 * core-daemon is running

then it must be started with

 sudo /etc/init.d/core-daemon start

If anything goes wrong, try looking at the file /var/log/core-daemon.log.

Then start the gui by calling


Using the GUI, lay down a two-node network interconnected by a single point-to-point link. The IP addresses should autoconfigure as shown in the below figure.

CORE has some basic link effects implemented by Linux netem by default. Let's configure a 1 second delay (in each direction) between node 1 and node 2. Right click on the link and enter 1000000 us in the dialog box, then Apply and close the box.


Then start the emulation by hitting the green Go button. The button should turn red and the emulation should be running as shown below.


Next, obtain a shell on node 'n1' by double-clicking the node. It should start a shell as shown below:


This can be also done on node 'n2'. The home directory for this shell is the directory /tmp/pycore.nnnnn/n1, where nnnnn is the CORE session ID. Note that this is a transient directory; it and its contents will disappear when the emulation stops.

One can ping across the topology as follows. Try pinging from node 'n1' to node 'n2'. One should see round trip times of about 2 seconds (the first one may be longer due to ARP delay).

At this point, we can start to experiment with CORE by running ns-3 in emulation mode. The two-node topology is useful for simple testing of an ns-3 host protocol against a similar protocol running on the Linux container (e.g. TCP testing). Of course, it may be difficult to run the real application that stimulates the protocol in the ns-3 context (unless Direct Code Execution mode is used). A three node chain topology where ns-3 runs in the middle node can be the starting point for testing ns-3 forwarding behavior and comparing it to that of a real router (e.g. queue discipline testing).

Tomh 15:45, 12 August 2014 (UTC)