Mininet before version 2.0 did not come with an easy way to reach the Internet through the mininet VM. Mininet 2.0 VM comes by default with connection to the network of the host, overriding this problem.
-Get Mininet image (>2.0)
# Download Mininet 2.0 ubuntu image wget https://github.com/downloads/mininet/mininet/mininet-2.0.0-113012-amd64-ovf.zip # Extract unzip mininet-2.0.0-113012-amd64-ovf.zip
-Prepare Virtualbox and import VM
# Get and install vbox extension pack for vrde support (remote desktop) # Get a version corresponding to your vbox version wget http://download.virtualbox.org/virtualbox/4.2.12/Oracle_VM_VirtualBox_Extension_Pack-4.2.12-84980.vbox-extpack vboxmanage extpack install Oracle_VM_VirtualBox_Extension_Pack-4.2.12-84980.vbox-extpack # Import vm, the name of the vm will be "vm" vboxmanage import mininet-vm.ovf # Turn vrde on vboxmanage modifyvm vm --vrde on # Set authentication using hosts credentials vboxmanage modifyvm --vrdeauthtype external # Start vm with vrde running in port 5001 vboxheadless --startvm vm --vrde config
-Connect through with
rdesktop through Linux client
# Connect to the vm with host IP (126.96.36.199), username and password rdesktop -a 16 -u user -p password -N 188.8.131.52:5001
To connect with the windows client
.rdp should be created which should contain the username and password (help).
# Enable ssh to port 8082 vboxanage modifyvm vm --natpf1 "ssh,tcp,,8082,,22"
Now mininet is ready for remote use through remote desktop or ssh ;-).
The topology used in the tutorial is the following (the controller is external to mininet):
We start the Openflow reference controller with the command:
$ controller ptcp:
This will create the following series of messages to be exchanged.
You can get a copy of a similar capture from here. The capture can be viewed in wireshark using the Openflow Wireshark dissector (Helpful guide).
Continuous communication problem.
Then, the controller and the switch continue exchanging frequently
Echo Request and
Echo Reply messages.
According the Openflow specification :
In the case that a switch loses contact with the controller, as a result of a echo request timeout, TLS session timeout, or other disconnection, it should attempt to contact one or more backup controllers.
This can prove to be a problem for our case. How this is implemented by the different controllers, as well as the frequence and its possible modification in a proactive environent should be explored. The tutorial mentions about
When an OpenFlow switch loses its connection to a controller, it will generally increase the period between which it attempts to contact the controller, up to a maximum of 15 seconds. Since the OpenFlow switch has not connected yet, this delay may be anything between 0 and 15 seconds. If this is too long to wait, the switch can be configured to wait no more than N seconds using the --max-backoff parameter.
Also useful is this post in the ovs-discuss list.
Since the switch flow tables are initially empty a ping command will cause the following message exchange.
You can get a copy of a similar capture from here.
We can see the
Packet Out and
Flow Mod messages.
Flow removal messages do not appear as mentioned in the tutorial. This may be a problem with the OVS version (1.2.2). Additionally, this version does not support the
send_flow_rem flow option in through the
ovs-ofctl tool and neither is this option supported by the
dpctl provided by the OF implementation. Thus, there is no way to check which is the actual problem.
User-space OVS vs kenel-space OVS
Following the tutorial we can see that using kernel-space OVS bandwith (measured with iperf) is arround 190 Mbps while with user-space OVS is arround 23Mbps.
Note: Mininet Internet Connection
By default, the mininet vm comes without connection to the host network. This happens because the guest network is implemented with the virtio paravirtualization driver.
There is going to be a post following, which will contain notes from the rest of the tutorial using POX controller in order to implement L2 and L3 learning.