Cloonix network simulator v24: what’s new

The cloonix development team recently updated the cloonix network simulator to version 24. This post describes the changes in cloonix v24 compared to cloonix v19, which we reviewed in a previous post.

Version 24 simplifies the setup of guest virtual machines, improves the link performance emulation tool, and adds new interface types designed to improve packet throughput performance. Users familiar with the cloonix graph GUI will have no problems using this new version, but shell scripts with cloonix ctrl commands may need to be updated, because the ctrl CLI has changed.

Please read on to see a detailed description of the changes.

Installation

We described how we installed cloonix v24 in a previous post. We installed cloonix in a folder named Netsims. In the examples below, the cloonix path is: ~/Netsims/cloonix-24.11/. We also downloaded and placed the Debian jessie filesystem in the ~/Netsims/cloonix-24.11/bulk directory so we can use it to create the nodes in the simulation.

Start cloonix v24

Cloonix v24 starts the same way as v19. We ensure KVM is set up properly, then we run the cloonix startup script.

$ sudo modprobe kvm-intel nested=1
$ sudo chmod 666 /dev/kvm
$ ~/Netsims/cloonix-24.11/start_cloonix_net
$ ~/Netsims/cloonix-24.11/graph

This starts the cloonix graph graphical user interface. You may alternatively use the cloonix command-line interface (CLI), ctrl.

Immediately, we see some differences compared to cloonix v19. There are some new interface types in the toolbar.

New interface types

Compared to earlier versions of the cloonix graph interface, there are some new objects available in the tool bar. The c2c, ulan, and utap objects are new in v24. Also, the VM object now has an optional “ueth” interface.

The c2c object is a new feature.

The new “u” objects, ulan and utap, and the new ueth interface inside the VM object are intended to provide better packet-forwarding performance. They use multi-threaded methods to support transfer of packets between virtual machines while using less system resources on the host computer.

The c2c link

The c2c object is the inter-cloonix link. It provides a connection to a remote cloonix simulation running on another computer. This supports distributed simulation, allowing for much larger simulated networks to be created by using a cluster of computers. Since we are using only one computer, we will not test the c2c feature.

The ulan switch

The ulan is a virtual Ethernet switch. It operates the same as the lan switch. The ulan seems to be an experimental feature that is intended to improve performance of packet flows between virtual nodes. A ulan switch must connect to a ueth interface on a guest VM or to a utap interface on the host computer.

The ueth interface on the VM

The VM configuration window now offers the option of configuring one or more Ethernet interfaces as an “ueth” interface. A ueth interface is required to connect a VM to the new ulan switch.

The utap interface

The utap is a tap interface on the host Linux computer that is compatible with the ulan switch. Just as the ulan switch must connect to a ueth interface on a VM, it must also connect to a utap instead of a normal tap interface.

Before we can use a utap interface in cloonix v24, we need to up the correct permissions on the host computer:

$ sudo chown root bin_cloonix/muswitch_bin/cloonix_mutap
$ sudo chmod 04755 bin_cloonix/muswitch_bin/cloonix_mutap

If we did not set the permissions correctly, and we try to drag the utap object onto the cloonix graph, we will see a warning telling us to set the permissions as shown above.

Technical details

The cloonix developers provide some technical information about the new ulan, ueth, and utap implementations in the README file ((From the README file: “A new lan implementation exists: a mueth inside qemu is switched by a muswitch displayed on the graph by a ulan and can be connected to another mueth or to a mutap. This can replace the switching done by uml_cloonix_switch in the usual architecture. Based on shared memory and futex, this should be a faster way to transmit packets, the performance gain is not as large as we hoped. Launched by the usual cloonix master uml_cloonix_switch, the cloonix_muswitch function is simple: give all packets arriving through one “client” (a qemu-kvm mueth or a mutap) to all other “clients” without any more copy of the packet than the one that puts it in the shared memory. The futex is used to wake threads that have new work in the shared memory area. A patch in qemu does the first copy from the virtio queue to the shared memory.”)). They use kernel resources such as shared memory and futex to more efficiently move packets from one virtual machine to another in the simulation ((More information about futex: see the article on Futex Programming at Ulrich Drepper’s web site)).

t2t can now shape traffic

the t2t object may now be configured to shape traffic (previous versions allowed for only delay and data loss) so we should be able to do some more interesting quality of service simulations in Cloonix.

To create a t2t, drag it into the graph canvas. Then, connect it to two lan objects to make it part of a network. In the example below, a t2t is set up between two guest virtual machines.

The t2t is bi-directional with separate properties for each direction: A to B, and B to A. To configure t2t properties in one direction, right-click on the blue circle of the t2t and select one of the directions, such as A2B Conf, from the contextual menu.

The t2t configuration window provides the ability to configure properties that affect quality of service such as delay, packet loss rate, and token-bucket shaping properties.

The Delay field show the transit delay in milliseconds. The Loss field is expressed in 1/100ths of a percent data loss. For example: a Loss value of 250 is 2.5% data loss; a Loss value of 1 is 0.01% data loss; and a Loss value of 10,000 is 100% data loss.

The graph shows the metrics such as total enqueues — data throughput — over time. We can zoom into the graph by moving the bottom yellow cursors and double-clicking on them. A double click elsewhere zooms out.

KVM

Cloonix v24 primarily supports KVM. Cisco root filesystems are still supported but not fully tested or documented. Cloonix no longer supports LXC containers or user-mode linux (UML). This simplifies the setup of guest virtual machines.

Updated VM object

The cloonix v24 VM configuration panel contains new options and parameters.

Ballooning is a feature in KVM that allows the user to oversubscribe memory assigned to a group of guest virtual machines. The VMs will use only the memory they need but an individual VM may “balloon” its memory usage to the maximum value configurted if it needed it.

Full virt is useful only when running Windows on a guest VM. Do not use it for a Linux guest VM ((The full virt option is not to be used for Linux guest VMs. The full virt option tells the guest VM not to use the “para” virtualized drivers, and to use only hardware emulation. Windows has drivers for those hardware emulation but not for the paravirtualization. The Linux kernel has drivers for paravirtualization but not for hardware emulation so the *full virt” option would result in poorer performance on a Linux guest VM.)).

We can configure the number of virtual CPU cores used by each guest VM (the maximum is thirty-two) and the amount of memory assigned to the VM. We also configure the root filesystem in this window — in this example, we use jessie.qcow2. The root filesystem must be in the cloonix bulk directory, unless the static_rootfs option is set.

At the bottom of the VM configuration window we see the check boxes to configure Ethernet ports as ueth so the port is compatible with the new ulan object.

New method to connect to virtual machines

In the older version 19, cloonix automatically added a management interface to each guest VM and connected it to a hidden LAN object, cloonix_slirp_admin_vlan, called the “slirp interface”. All virtual machines were managed via an SSH client connecting to the slirp interface.

In version 24, cloonix communicates directly with each VM. The “slirp interface” is not needed, except in cases where a VM must communicate with the internet (an internet connection is required when we want to install new software on a VM).

Opening a terminal on guest VMs in cloonix v24

In normal use, the user would not immediatly notice this new feature in the graph interface. Accessing a VM running in cloonix v24 is the same as in v19: double-click on that VM in the cloonix graph interface.

Alternatively, we can use a CLI command to connect to a guest VM. Version 24 uses the dropbear SSH client so, to connect to a cloonix guest VM, use the following command on the host computer. In this example, vmname is the name of the guest VM to which we want to connect.

$ ~/Netsims/cloonix-24.11/dbssh root@vmname

The root password on each VM provided by the cloonix project is: rootroot.

Technical details

Each VM filesystem provided by the cloonix developers is configured to create a “backdoor” tty console interface that can connect to the cloonix daemon ((From the README file: “All virtual machines used in cloonix must have a /dev/hvc0 auto-login root tty giving a ‘backdoor’ root access to the uml_cloonix_switch daemon. The uml_cloonix_switch injects and runs a script starting cloonix_agent inside the VM, this infiltered agent communicates with the uml_cloonix_switch daemon to allow the host computer to communicate with the guest VM using the dropbear open source SSH client”)). Cloonix uses a patched version of the Dropear SSH client, dbssh, to communicate with the VM using a unix socket instead of a TCP port (such as port 22) so it does not require the user to set up IP networking on each guest VM or on the host computer.

New format for filesystems

Compared to v19, cloonix v24 no longer requires that the guest VM be modified to work with cloonix ((From the cloonix mailing list May 2014: The new goal for this cloonix version is “zero-config, network-less access”. Cloonix guests should not contain cloonix-specific configs and the host-to-guest communication that cloonix uses for its “./ssh” and “./scp” should not pollute the guest’s ip stack. All communications host to guests would go through virtual serial devices. The guests ip stack would be untouched.”)). Any root filesystem that is compatible with KVM will now work in cloonix v24.

The cloonix project still provides prepared guest VM root filesystems that provide a basic set of software packages. Users will need to install the specific software they need in each guest VM before they run a network simulation. We must connect the guest virtual machine to the web using the slirp interface (see below) and then download and install the software we need.

Use the slirp interface to connect a cloonix VM to the internet

Cloonix guest VMs are isolated from the IP networking stack on the host computer. To connect a cloonix guest VM to the internet we use the hidden LAN object, cloonix_slirp_admin_vlan. The cloonix_slirp_admin_vlan is a special LAN switch that emulates tcp/udp connections in the guest and connects to the IP networking stack on the host computer to get out to the internet. It also supports DHCP so it can assign IP networking configurations to a guest VM interface connected to a slirp interface. The cloonix_slirp_admin_vlan operates the same way as a NAT network connection in VirtualBox or VMWare.

The cloonix README file recommends using the highest-numbered Ethernet interface on the guest VM to connect to the slirp interface. Use the graph interface to connect the slirp interface to the VM’s ethernet interface:

1. If the cloonix_slirp_admin_vlan object is not visible in the graph interface, right-click on a blank part of the graph interface and choose the Hidden/Visible option from the drop-down menu.

   

2. In the window that pops up, clear the check-box next to the cloonix_slirp_admin_vlan so it becomes visible.
3. Double-click on the cloonix_slirp_admin_vlan object, then click on the highest-numbered Ethernet interface on the VM.

   

4. Then, login to the VM by double-clicking on it and execute the dhclient command on the highest-numbered Ethernet interface. In this example, we assume it is eth2:

   # dhclient eth2
   

Test the connection between the VM and the internet

Because of the way cloonix is designed to run exclusively in the user namespace (so it avoids problems we see in other network simulators that use Linux kernel resources), a guest VM connected to the internet via the slirp interface cannot successfully use the ping command to test connectivity to a remote server. Programs such as wget and aptitude, that use normal user-level sockets, will work.

Test the guest VM’s connection to the internet by updating the list of package repositories. The update should work if the VM’s connection to the internet is working:

# apt-get update

Add software to the guest VM

Now that the guest VM can connect to the internet, download useful networking software. The required software will be different depending on the type of network functions being simulated. Here is an example of installing the XFCE desktop and a basic set of networking software on a guest Linux VM.

# apt-get --allow-unauthenticated -y install xfce
# apt-get --allow-unauthenticated -y install quagga \
  openssh-client openssh-server isc-dhcp-server \
  vsftpd apache2 tcpdump radvd ucarp openvpn \
  ipsec-tools racoon traceroute wireshark tshark \
  iperf

Static and non-static root filesystems

Static filesystems and non-static filesystems are not new features in cloonix v24 but, given that the way root filesystems have changed in v24, we think it is suitable to describe them in this post.

Static root filesystems

If we configure a guest VM with the “static” flag set and define an absolute path to the root filesystem then any changes made to that filesystem are preserved. A static guest is never erased and saves all modifications done within its file-system.

Non-static root filesystems

A non-static guest is erased when the guest virtual machine is halted. All modifications are lost. It may seem like a waste to lose your configurations after halting a simulation but in some cases, such as where simplicity and portability are important, it is preferable to use non-static filesystems. We may install software and create configuration files on each guest VM as we build a new simulation scenario. We can also script the procedure so it executes automatically (by creating a shell script that runs cloonix ctrl commands).

We can also save a non-static root filesystem and later use the saved copy as a static root filesystem. To save a copy of the root filesystem, right-click on the guest VM in the graph and choose the save rootfs with cp command from the contextual menu.

New terminal application

Cloonix v24 now uses the RXVT terminal application instead of xterm. RXVT offers the same functionality as xterm but uses less system resources. You must install the rxvt-unicode package as part of the prerequisite software that supports cloonix (see the Install cloonix v24 post).

New command line interface

The cloonix command-line interface, ctrl, can be helpful when creating scripts and when debugging issues in cloonix. In cloonix v24 the commands have changes so that there is now a tree hierarchy of commands. The help functions in the command-line interface help you learn each command and its subcommands.

To explore the options available in the command-line interface, run a command without parameters. It will show you the list of possible subcommands in that context. For example:

$ ./ctrl

The ctrl command shows all the cloonix CLI commands

|-------------------------------------------------------------------------|
| ./ctrl                                                                  |
|-------------------------------------------------------------------------|
|    -k              : Destroys all objects, cleans and kills switch      |
|    -d              : Destroys all cloonix objects                       |
|    topo            : Manage a set of cloonix objects                    |
|    add             : Add one cloonix object to topo                     |
|    del             : Del one cloonix object from topo                   |
|    vm              : Virtual machine actions                            |
|    t2t             : T2t configuration                                  |
|    snf             : Pcap Sniffer actions                               |
|    layout          : Layout modifications on canvas                     |
|    sys             : Cloonix system monitor                             |
|-------------------------------------------------------------------------|

To see the available subcommands or parameters for any cloonix command, execute the subcommand with no parameters. For example:

$ ./ctrl t2t

The t2t subcommand show the options available:

|-------------------------------------------------------------------------|
| ./ctrl t2t                                                              |
|-------------------------------------------------------------------------|
|    delay           : Insert delay in t2t                                |
|    loss            : Insert loss in t2t                                 |
|    qsize           : tx queue size                                      |
|    bsize           : token bucket size                                  |
|    brate           : token bucket rate                                  |
|    stats           : statistics                                         |
|-------------------------------------------------------------------------|

Keep working down the command tree until you see the parameters required. Then you know the full syntax for this specific cloonix command. For example:

$ ./ctrl t2t delay

The delay option shows the parameters required:

./ctrl t2t delay  <t2t_name> <A2B or B2A> <nb (in ms)>

example:

./ctrl t2t delay  t2t1 A2B 100

In this example, we discovered how to change the delay of a specific link in the simulation.

Conclusion

The cloonix development team continued to deliver updates and improvements on a regular basis. Cloonix v24 offers a lot of improvements to the infrastructure that supports cloonix network simulations.

Cloonix continues to be a strong network simulation tool, suitable for researchers who need the heavy-duty virtualization provided by KVM virtual machines and who prefer to avoid interferance with the system resources provided by the Linux host computer ((Cloonix runs most of its processes in user space)).

Some features in cloonix we have not investigated are: nested cloonix (cloonix in cloonix) and the c2c (cloonix to cloonix) distributed simulation. These features benefit advanced users of the tool.

Notes: