Using Cloonix: the graph interface

I used the Cloonix open-source network simulator to simulate a very simple network. This helped me understand how to use the “point and click” functionality provided by the graph function to manually build and configure a test network. I also hope that the following procedure would be useful as a simple tutorial for anyone interested in learning to use Cloonix.

NOTE (updated February 26, 2013): The Cloonix development team updates Cloonix every few months and, eventually, they remove links to old releases from their web site. Use the latest version of Cloonix found on the Cloonix web site.

Start Cloonix

Run the commands that enable KVM and start Cloonix:

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

The graph window

The sidebar of the graph window has six objects: lan, vm, tux, t2t, snf, and tap. Some of these objects are configured by right-clicking on them. The grey background of the graph window is also an object, called the canvas, whose properties can be configured by right-clicking on it.

Each object represents an network element that can be dragged onto the graph window. These are discussed in the Cloonix documentation.

I will describe the three objects we will use in this excercise. These elements are:

lan	This is a virtual Ethernet switch. Many VMs can be connected to a lan switch. Cloonix assignes a number to identify each new lan switch you create.
vm	Right-click on this object to configure it. Once configured, this will create a guest if you drag and drop it onto the canvas.
canvas	Right-click anywhere on the grey canvas to access a menu of commands, and right-click on any object created on the graph to access a menu of commands associated with that object.

Configure the vm object

Right-click on the vm object to configure the VM filesystem that will be created by dragging the object onto the canvas. You can also configure the name that Cloonix will create for the VM, the amount of RAM available to the VM, the type of VM, and the number of Ethernet interfaces configured on the VM.

In my case, I downloaded the kvm_squeeze_qcow2 filesystem from the Cloonix Downloads page, so I configured the vm object to use this filesystem.

Then I used the mouse (and the left-click button) to drag-and-drop the vm object three times onto the canvas. Each VM appears on the canvas as a red circle that eventually turns blue when it finishes booting. I waited until each VM was fully started (that is, it turned blue) before creating the next VM.

Create the LAN

I created one switch to which all three VMs will be connected. I dragged the lan object onto the canvas. This created a LAN called, “0101”.

Connect virtual machines to the LAN

To connect VMs to the LAN, Double-click on the lan object, 0101. It will change color. Then, click on the Ethernet port on the VM you want to connect to the LAN. In my case, I connected the Ethernet port “0” on each VM to lan 0101.

I found that the objects you create on the canvas move around once you start connecting them to the lan object. If you want to stop this, right-click on the grey canvas and select the menu item Motion → stop. You can manually move all objects by clicking and dragging.

slirp_admin_lan_tux

Each VM we created has three Ethernet interfaces, represented by small circles attached to each VM. We see that two of these Ethernet ports are colored green and one is colored blue with a blinkling orange dot in the middle of it.

The blue port is the Ethernet port used by Cloonix for administration of the VM. It is actually connected to a hidden lan object called slirp_admin_lan_tux. For this example, we will not concern ourselves with the details of how Cloonix manages the virtual machines. To make the graph window simpler, we can hide the blue Ethernet intefaces by right-clicking on each interface and selecting the Hidden/Visible menu item.

Now you will see only two green Ethernet ports per VM.

Note: If you are interested to see which items are hidden, right-click on an empty spot on the canvas and select the Hidden/Visible menu item. This will open a window that lists all hidden elements. Clear the check box opposite any element you want to make visible. We will not do that in this excercise, though.

Configure each virtual machine

The virtual machines must be configured so they can communicate with each other over the virtual switch. We need to configure the eth0 interface on each VM. If we double-click on a virtual machine, a console window will open that will allow you to enter commands to configure the virtual machine.

For this very simple network, we will have a simple IP address plan. We will use the network address, 192.168.2.0/24. We will assign IP addresses as follows:

VM name	Interface	IP address
Cloon1	eth0	192.168.2.11/24
Cloon2	eth0	192.168.2.12/24
Cloon3	eth0	192.168.2.13/24

Double click on each VM to open the xterm window for each VM. In the xterms, enter the Linux commands required to configure the eth0 interface on each machine.

On Cloon1:

$ ifconfig eth0 192.168.2.11 up

On Cloon2:

$ ifconfig eth0 192.168.2.12 up

On Cloon3:

$ ifconfig eth0 192.168.2.13 up

Run a simple test

Now, let’s test the function of the virtual Ethernet switch represented by lan 0101. We will use the ping command to send some IP packets from Cloon2 to Cloon1. The behavior I expect to see is:

1. Cloon2 will send an Ethernet Frame containing the ICMP Echo Request packet generated by the ping command onto the LAN from its interface, eth0. This first frame sent from Cloon2 will be received by the lan 0101 switch, which will broadcast the frame out all its interfaces except for the interface that received the packet. So, both Cloon1 and Cloon3 will receive the frame. Because it just received an Ethernet frame from Cloon2, the lan 0101 switch will learn that the interface that received that frame from Cloon2 should be the interface to which any frame addressed to Cloon2 should be sent.
2. Cloon1 will respond to the ICMP packet and send an Ethernet frame containing the response packet from its interface, eth0, onto the LAN. Since the lan 0101 switch has already learned which interface is to be used to communicate with Cloon2, the frame will be forwarded to that interface and on to Cloon2 (but not by Cloon3). Because it just received an Ethernet frame from Cloon1, the lan 0101 switch will learn that the interface that received that frame should be the interface to which any frame addressed to Cloon1 should be sent.
3. The next frame sent from Cloon2 to Cloon1 will be received by the switch lan 0101 and forwarded directly to Cloon1, without also being broadcast to Cloon3. This is because the switch has learned which of its interfaces should be used to forward packets to either Cloon2 or Cloon1.
4. The two-way communication between Cloon2 and Cloon1 will continue until the ping command running on Cloon2 is stopped. Cloon3 will not receive any more Ethernet frames.

There are several ways we could test this expected functionality and prove that this is what happens. We can cover those methods in the future. For now, because Cloonix provides some visual indication of packets being sent on interfaces, we can just carefully watch the graph window when we start the ping command on Cloon2.

On your Linux desktop, arrange the Cloonix grap window and the xterm for the Cloon1 virtual machine side-by-side so you can see both windows. then, while carefully watching the graph window, run the following command on the Cloon2 xterm:

$ ping -c10 192.168.2.11

This will send ten “pings”, ICMP Echo Request packets, from Cloon2 to Cloon1, one per second for ten seconds.

We see the blinking orange dots that indicate frames are being sent or received on each interface. When we start the ping command on Cloon2, we see all interfaces blink with an organge dot once, then only the interfaces that are on the path between Cloon2 and Cloon1 have organge blinking dots after that. The orange dot on the interfaces attached to Cloon3 only blinked once and do not blink again.

Since the ping command only sends one packet per second, it is possible to observe this with the human eye.

Conclusion

We completed a very simple test of three PCs, represented by the three virtual machines we created in Cloonix, connected on the same network via a Ethenet switch, represented by the virtual switch, lan 0101. We showed that the PCs could communicate with each other and observed that the virtual switch functions like a normal Ethernet switch in this scenario.

I found that is was easy to set up this scenario using the “drag and drop” functionality provided by the Cloonix graph command.

As an aside, I observed the the tcpdump command is not installed on the default filesystems used for Cloonix. It would be nice to have tcpdump installed on each VM so we could observe the IP packets received on the xterm of each VM during our test. In any event, we could have used the Cloonix sniffer to monitor the Ethernet frames on the LAN, lan 0101.