Mininet Assignment

For this project you are to install a Mininet virtual machine, and complete two of the experiments below. Neither involves "serious" programming, but you will have to use Python as a configuration language, and maybe be able to do some basic shell scripting.

I've placed a zipped 64-bit virtual-machine disk image in OneDrive, at https://loyolauniversitychicago-my.sharepoint.com/:u:/g/personal/pdordal_luc_edu/EelOc-rKkjdFtQRhmqAmsW8BRXyxT_hmsIyIdzMD9DvirQ?e=yleJPq. You will need to be logged in to your Loyola account to access this; there's probably a two-factor-authentication step too. Unzipped, it is 2.9 GB. To make this into a working VM, do the following:

The VirtualBox Guest Additions have been installed.

The login account/password is mininet/mininet. Once you're logged in, use the command startx, which takes ~30 seconds to start because of some issue with the .Xauthority file. This starts the lxde graphical environment.

When you're done with your session, just click "close" on your virtual machine and you should be asked if you want to save the machine state. If you click "yes", then you can just resume where you left off (with the lxde environment still running).

The directory "loyola" has several python files. Open a terminal window (press cntl-alt-T) to run them. You will need to be root to do this, so use the command sudo bash. I recommend having multiple terminal tabs (use cntl-shift-T to open a new one), with only one of them as root.

Lxde supports two "desktops" out of the box; so if all your windows went away, you probably switched to the other desktop. Use the desktop icons at the lower middle-left, or else cntl-shift-left_arrow/right_arrow.

The editor is leafpad. Start it from the terminal with leafpad &; the ampersand allows you to then continue to use that terminal while leafpad is open.

Demo

For this demo, I will start Mininet with the topology below, and watch a TCP connection using WireShark.

    h1 ---- r1 ---- r2 ---- h2

We get this topology by running (as root) the command

    python routerline -N 2

in the loyola subdirectory.

At the mininet> prompt, we can run simple commands, like links and nodes. We can also run h1 ping h2, which runs the command "ping h2" on h1. Finally, if we run h1 ifconfig or h2 ifconfig, we can find the IPv4 addresses of h1 and h2. We will need these below, because the names h1 and h2 do not work in general.

For this demo, we can open an xterm terminal window on each of h1, r1 and h2 with xterm h1 r1 h2 at the mininet> prompt. Three black terminal windows should open up.

In the h2 window, we will run netcat -l 5432, which sets up netcat as a "listener" on port 5432.

On r1 we will start Wireshark, using the command wireshark. Have it listen on interface r1-eth0. 

Finally, on h1, run netcat 10.0.2.10 5432 (the 10.0.2.10 should be the IPv4 address of h2). You should see the three-way handshake. Type a couple data lines, such as "hello" or "floccinaucinihilipilification". Then press cntl-D to exit. You should see the strings printed on h2; you should also be able to see the data in the tcpdump output. Finally, you should see the closing handshake.

Experiments

You should expect to complete two of these.

1. TCP Simultaneous Open

For this project, you are to arrange so that you can view and record TCP simultaneous open. Here is a suitable network configuration:

h1 ---- R ---- h2

The main purpose of the router R is to have a place where you can monitor the traffic, using tcpdump or wireshark.

Start xterms (x-terminals) on each of h1, h2, and R. I will assume that h1's IPv4 address is 10.0.0.10 and h2's is 10.0.1.10; these are the assignments if you run python routerline.py -N 1. Then run the following:

But this doesn't get you a simultaneous open. To do that, you'll have to run netcat -p 5432 ip-address 5432 on both h1 and h2 simultaneously. The -p 5432 specifies the source port; you can also do netcat -p 2000 h2 3000 on h1, and netcat -p 3000 h1 2000 on h2, for example.

To run the two commands simultaneously is impossible, of course. However, you can add some delay to the h1--R and R--h2 links, at least 1000 ms worth. You will probably also want to use ssh from, say, R to h1 and h2, to run the commands in quick succession.

To set the delay, see the file competition2.py, which unfortunately I did not get pre-installed in the virtual machine (use ssh or scp to transfer, or copy/paste if you are able to get that working, or just open a browser within the virtual machine and download it from this page). I've set DELAY='250ms' in the file, and, if mininet is running and I type h1 ping h3, I get

PING 10.0.3.10 (10.0.3.10) 56(84) bytes of data.
64 bytes from 10.0.3.10: icmp_seq=1 ttl=63 time=250 ms
64 bytes from 10.0.3.10: icmp_seq=2 ttl=63 time=250 ms
64 bytes from 10.0.3.10: icmp_seq=3 ttl=63 time=250 ms

which is exactly what it is supposed to be.

2. TCP Reno vs Cubic

The goal is to compare the total throughput for the two TCP congestion mechanisms. For this example, the relevant Python file is competition.py. TCP Reno and TCP Cubic are both available.

Choose a time interval, eg 10 seconds (maybe less for trial runs), and compare the throughput of two connections sharing a link. Do a few runs to get an idea of how consistent your results are.

I recommend comparing Reno to Cubic and also, as a control, Reno to Reno.

It is important to try different RTTs, eg 50 ms, 100 ms and 200 ms (for the basic tests, you can implement delay on the common link; be careful whether it is bidirectional or not).

You might also try different delays on the two paths. TCP Cubic is supposed to handle this reasonably well for cubic-to-cubic competition.But this is optional.

3. Bandwidth limits

Set up a topology like this, based on the competition.py file:

    h1-----+
           |
    h2-----R-----h4
           |
    h3-----+

Run htb on R, and set separate classes for traffic from h1/h2/h3 to h4. Run sender.py on each of h1/h2/h3, and a receiver on h4 (I'm still working on that; dualreceive.py only receives from two and that should be good enough to get started while I work out a more general solution).

Set appropriate bandwidth limits for each of h1/h2/h3, and show that they are obeyed.

Experiment with a large burst for h1, but not h2/h3. What happens?

Can you change the bandwidth while traffic is being sent, and see a change in the received bandwidth?