Cloonix-Net

Table of Contents
1. Constituants
2. Switch Params
3. Connexions
4. Vlan
5. Topology Files
5. Demo Configuration

Constituants

Virtual Machine This machine is based on 2 possible technologies: UML and KVM, both in the linux mainline. UML machines need 2 files, one usually called linux is the binary to be run in the user world and a root file system which is just a big file that has to be mounted to be read. KVM machines need only root the file-system, the binary that launches it is called qemu-kvm. These Virtual Machines have ethernet interfaces plugged to sockets (sun sockets for UML and inet sockets for KVM), those sockets go straight to the uml_cloonix_switch daemon. While running, Virtual Machines do not write on their reference root file-system. When they have to save stuff, they write it in a file called COW for Copy On Write. All virtual machines are in the bulk directory of the cloonix-x.y tree. Virtual Switch implemented by daemon uml_cloonix_switch in the bin_clownix directory of the cloonix-x.y tree. This daemon is the heart of the cloonix-net tool, it does several things: Machine Management: - Chooses an admin ip number for the new machine. - Creates a config file to pass on to the machine it wants to start, this config can contain demo-associated user files. This config will be seen by the machine as a secondary hard disk. (needs to mount, this explains the need to be suid root). - Creates the adapted command-line to launch the machine with the requested parameters such as ethernet interfaces and others. - Launches the machine, gets its pid to be able to kill it, and pings it regularly through the administrative interface. Switch Management: - All sockets of all interfaces of all machines must be switched upon user request, the packets are transmitted as fast as possible from socket to socket. - Process the delay/loss requested by user on the packets. Tap and Brctl: - Can create and use taps, can be used to help in brctl configs. (suid root is necessary for this also). Obeys to xml commands: - Receives The daemon uml_cloonix_switch receives XML messages for real time live configuration. Switch's Clients These are to connect and give configuration orders to the uml_cloonix_switch. The clients are wrapped by scripts, the names are: ctrl, fconf, event, graph. ctrl Command Line Interface, connects, sends a command and closes. fconf Reads a topology file and sends it or receive a running configuration and writes a file. event Monitors things. graph Graphical interface based on GTK.

Switch daemon

./uml_cloonix_switch <port> <tap> <ip> <work> <bulk> <rsa_public> <title>

port: clients such as ctrl use this port to talk to the daemon
tap: num x of tapx used to connect the host to the admin network
ip: tapx is configured with this ip, defines admin prefix network
work: directory for cow files and the virtual machines socket files
bulk: directory where linux and root_fs files are stored
rsa_public: used so that ssh and scp do not need passwords

In start_cloonix_net the following line is used: ./uml_cloonix_switch 5432 0 10.1.1.1 /tmp/cloonix ./bulk /root/.ssh/id_rsa.pub Cloonix-Net-Lab VM Mac addresses follow a rule, it if function of machine number vm and interface number eth_num: MAC= 02:00:(vm/100):(vm%100):00:eth_num
Admin eth of machines in the cloonix network are configured with ip in the same network as the ip given at daemon startup, with netmask 255.0.0.0 If the chosen admin ip is X.Y.Z.T then for machine num vm: IP=X.Y.(vm/100).(vm%100)

Connexions

__________________________________________________________________ | | | ------------- ------------- ------------- | | | | | | | | | | | V M | | V M | | V M | | | | | | | | | | | |eth0 ethx | |eth0 ethx | |eth0 ethx | | | --|-------|-- ---|------|-- ---|------|-- | | | | | | | | | | | | | | | | | | | | | | | | | | --|-------|---------------|------|---------------|------|-- | | | c l o o n i x - s w i t c h - d a e m o n | | | -----------------|-----------------------|----------------- | | | | | |____________________|__HOST USER WORLD______|__________________ | | | HOST KERNEL | | | | | | | | | | | tap0 tap1 eth0 -------- | |_______| | | brctl | |________________________________________________________________|

Vlan

To understand the configuration of the clownix daemon switching action, we must first describe what is called a vlan in the software.
A vlan is just a 4 digit decimal integer. And the switching rule is simply: all interfaces in the same vlan see each-other.
Any number of vlans are attached to a single interface of a machine. This makes the following config possible: __________________________________________________________________ | | | ------------- ------------- ------------- | | | | | | | | | | | V M A | | V M B | | V M C | | | | | | | | | | | | eth1| | eth1 | |eth1 | | | ----------|-- ------|------ ---|--------- | | | | | | | | | | | | |--- vlan 1000 ----|---- vlan 2000 ----| | |________________________________________________________________| A and B see each other, B and C also but A and C do not see each other. The vlan configuration can be modified at any time during run and the action is instantaneous. Delay by 10 millisecond steps and random loss can be configured at any time also. Delay and loss are configured at reception from a defined vlan and for an interface. To have unidirectionnal links, just program the loss for the arrival from a vlan and to an interface to 100%,

Topology Files

The topology file is a simple way to describe your network structure and connections, the best way to learn how to write one is through examples. Here is the topology file for the OSPF demo: ############################################################################# # VIRTUAL MACHINES # #---------------------------------------------------------------------------- UML ROUTER1 64 linux_openwrt openwrt_uml (0002) (0003) (0001) UML ROUTER2 64 linux_openwrt openwrt_uml (0003) (0004) UML ROUTER3 64 linux_openwrt openwrt_uml (0002) (0004) (0006) UML HOST1 64 linux_openwrt openwrt_uml (0001) UML HOST2 64 linux_openwrt openwrt_uml (0006) #---------------------------------------------------------------------------- ############################################################################# # TAP # #---------------------------------------------------------------------------- TAP 1 (0002,0003,0004) This file will give the following topology: _________ ___________ ___________ _________ | HOST1 | | ROUTER1 | | ROUTER3 | | HOST2 | | eth0___1___eth2 eth0___2___eth0 eth2___6___eth0 | |_______| |__ eth1__| |__ eth1__| |_______| | | | ___________ | | | ROUTER2 | | |___eth0 eth1___| |_________| The topology file is simple: UML is to say you want an UML Virtual Machine TAP is to say you want a tap. UML is followed by the machine's name, used to identify your machine for afterwards commands through ctrl. The maximum ram used by the VM, the linux binary to be used (only for UML), the root fs to be used. linux_openwrt and openwrt_uml have to be in the bulk directory. After the machine's name, each time a parenthesis opens, there is one more interface created. The number of interfaces cannot be changed after machine boot only the vlan connections can be changed dynamically. Just like a real machine, you can plug/unplug cables while it is running, but you have to stop it to put a new ethernet card. The 4 digit numbers inside the parenthesis are vlans, just imagine that a defined vlan number is a defined lan cable. In this example, (ROUTER1, eth0) is connected to (ROUTER3, eth0) and also to tap1 through vlan 0002. The uml_cloonix_switch adds one interface, and uses it for admin purposes, the administrative connections are mandatory and do not appear in the topology file. The administrative network prefix should not be used in the network demos. Its interface is always the defined max interface + 1, for example, ROUTER1 will have eth3 as admin, and ROUTER2 will have eth2. Here is the topology file for the OLSR demo: ############################################################################# # VIRTUAL MACHINES # #---------------------------------------------------------------------------- UML ROUTER1 64 linux_openwrt openwrt_uml (0001,0002) UML ROUTER2 64 linux_openwrt openwrt_uml (0002,0004) UML ROUTER3 64 linux_openwrt openwrt_uml (0004,0005) UML ROUTER4 64 linux_openwrt openwrt_uml (0005,0006) UML ROUTER5 64 linux_openwrt openwrt_uml (0006,0007) UML ROUTER6 64 linux_openwrt openwrt_uml (0007,0001) #---------------------------------------------------------------------------- ############################################################################# # TAP # #---------------------------------------------------------------------------- TAP 1 (0002,0001,0004,0005,0006,0007) This file will give the following topology: ___________ ___________ | ROUTER2 | | ROUTER3 | |___eth0__| |__ eth0__| |_________4__________| / \ / \ 2 5 ___________ / \ ___________ | ROUTER1 |___/ \__| ROUTER4 | |______eth0 \ / eth0______| \ / 1 6 \ / \ __________7__________/ | | ____eth0___ ___eth0____ | ROUTER6 | | ROUTER5 | |_________| |_________| With interfaces connected to a radio transmitter, it is possible to have 2 machines that do not see each-other and both can see a third machine. This is what we have here: all routers have only 1 interface (eth0). ROUTER1 can see ROUTER2 (through vlan 0002) and ROUTER2 can see ROUTER3 (through vlan 0004) but ROUTER1 cannot see ROUTER3 (no common vlans). Notice that you can spy on tap1 with wireshark.

Demo Configuration

The file containing the topology, if it is in a directory with other files and directories with particular names, those other files and directories are read and used in the config of the target VM. The particular file name is: files_to_delete_from_all_targets The particular directories are: files_to_add_in_all_targets files_to_add_in_<VM_NAME_FOUND_IN_TOPOLOGY>> In the file files_to_delete_from_all_targets, you must put script commands, such as: "rm -f /etc/rc.d/S60quagga" These commands will be executed before VM boot. All directories, files and links in files_to_add_in_all_targets will be copied in all the VM targets of the demo before boot. All directories, files and links in files_to_add_in_My_VM will be copied in the VM called My_VM before VM boot. Here is a sample of the ospf demo shipped with cloonix-x.y: The chosen names are not very meaningfull, but in ROUTERS, /etc/rc.d/S80_ospf_interface_conf will configure interfaces and start quagga in HOSTS, /etc/rc.d/S80_ospf_interface_conf will configure interfaces ./topology ./files_to_delete_from_all_targets ./files_to_add_in_all_targets ./files_to_add_in_all_targets/etc ./files_to_add_in_all_targets/etc/quagga ./files_to_add_in_all_targets/etc/quagga/zebra.conf ./files_to_add_in_all_targets/etc/init.d ./files_to_add_in_all_targets/etc/init.d/commun_startup ./files_to_add_in_all_targets/etc/rc.d ./files_to_add_in_all_targets/etc/rc.d/S87_update_host_file ./files_to_add_in_ROUTER1 ./files_to_add_in_ROUTER1/etc ./files_to_add_in_ROUTER1/etc/quagga ./files_to_add_in_ROUTER1/etc/quagga/ospfd.conf ./files_to_add_in_ROUTER1/etc/init.d ./files_to_add_in_ROUTER1/etc/init.d/ospf_interface_conf ./files_to_add_in_ROUTER1/etc/rc.d ./files_to_add_in_ROUTER1/etc/rc.d/S80_ospf_interface_conf . . . ./files_to_add_in_HOST1 ./files_to_add_in_HOST1/etc ./files_to_add_in_HOST1/etc/init.d ./files_to_add_in_HOST1/etc/init.d/ospf_interface_conf ./files_to_add_in_HOST1/etc/rc.d ./files_to_add_in_HOST1/etc/rc.d/S80_ospf_interface_conf . . .