SDN Lesson Introduction to Mininet

---

Contents [hide]

• Intro
• What is Software Defined Networking (SDN)?
• Installing and Running Mininet
• SDN Exercise #1

Intro

Welcome to a new series of articles that will be structured as lessons with the target of bringing SDN closer to everyone’s understanding.
Each article will present a topic plus one or more exercises that will show that topic in action. The lessons will wrap up with some questions asking the readers to exercise on their own and provide the answers. As you see, the approach is pretty similar to the networking quizzes, but with SDN ones, I also make an introduction to the topic since all this is relatively new.
When I started my personal SDN journey, it was difficult to find a place to start, so I began reading articles, viewing presentations or listening to different videos, all trying to demonstrate (mostly theoretically) the advantages, the applications or limitations of this new technology.
I am a person who learns best by “doing”, by individual testing, so I have decided to start these articles in order to help other network engineers with their beginnings in SDN.
In parallel, I will continue my series of network quizzes and solutions, hoping that time will allow me to do so…
Having started treating SDN topics clearly shows that I believe in this new approach in networking ! Of course, there are a lot of presentations about SDN and OpenFlow, all discussing their benefits and application in todays networks, but one of the arguments that convinced me was an analogy to the computer industry evolution from vertically integrated, closed, proprietary, relatively slow innovation, specialized-hardware, specialized-feature systems to horizontal, open interface, rapid innovation ones.

[1] Taken from Nick McKeown’s presentation “How SDN will shape networking”

What is Software Defined Networking (SDN)?

SDN (Software Defined Networking) is a network architecture that breaks the vertical integration by separating the control logic (control plane) from the underlying routers and switches that will become simple forwarding elements (data plane).
The key terms to remember about SDN (four pillars) are:[2]

• 1. the control and data planes are decoupled.
• 2. forwarding decisions are flow-based instead of destination-based
• 3. control logic is moved to an external entity, called SDN controller or NOS (Network Operatying System)
• 4. network is programmable through applications running on top of the controller (the fundamental characteristic of SDN)

In order to put all the theory into practice, we will use Mininet, a virtual network environment that runs on a single machine and provides many of the OpenFlow features built-in. Mininet will emulate an entire network of switches, virtual hosts (running standard Linux software), the links between them and, optionally, a SDN controller (I will talk in details about the SDN controller and OpenFlow in future articles).
The switches generated with Mininet will be just simple forwarding devices, without any “brain” of their own (no control plane). The new networking paradigm with SDN is: control plane is separated from the data plane so such switches will only do what they are instructed by an external controller. Whenever a switch (or a forwarding device, generally speaking) does not know how to deal with some packets, it will simply send them to the controller (or contact the controller referrencing some buffer-ids – more on this later on).
Mininet supports research, development, learning, prototyping, testing, debugging, and any other tasks that could benefit from having a complete experimental network on a laptop or other PC.[2]
This may require a little bit of programming knowledge (Python), but you can also get it along the way..

Installing and Running Mininet

The installation of Mininet is pretty straight forward – in summary:

• 1. download the Mininet VM image,
• 2. open it with your favourite virtualization system (Virtual Box, VMware, VMFusion, Qemu or KVM)
• 3. then perform the walkthrough that will teach you how to use it (the entire walkthrough should take under an hour – no need to go though all of it now, just familiarize yourself with the basic commands).

The default run of Mininet sudo mn will create a topology consisting of one controller (c0), one switch (s1) and two hosts (h1 and h2).
To help you start up, here are the most important options for running Mininet:

• --topo=TOPO represents the topology of the virtual network, where TOPO could be:
  • minimal – this is the default topology with 1 switch and 2 hosts
  • single,X – a single switch with X hosts attached to it
  • linear,X – creates X switches connected in a linear/daisy-chain fashion, each switch with one host attached
  • tree,X – a tree topology with X fanout
• --switch=SWITCH creates different type of switches, such as:
  • ovsk – this is the default Open vSwitch that comes preinstalled in the VM
  • user – this is a switch running in software namespace (much slower)
• --controller=CONTROLLER where CONTROLLER can be:
  • ovsc – this creates the default OVS Controller that comes preinstalled in the VM
  • nox – this creates the well-known NOX controller
  • remote – does not create a controller but instead listens for connections from external controllers
• --mac set easy-to-read MAC addresses for the devices

For our exercise, we will create a virtual network with one switch and 3 hosts, using the command shown below:

For the moment, we will not touch the topic of SDN controller (that’s for next articles) so our test network will have no controller. For such a switch to be able to forward traffic, it needs to be told how to handle the flows (flows is again a topic for future articles).
In order to “control” the switch (add and view the status of the flows on the switch) we will use an utility called DPCTL that allows direct control and visibility over switch’s flow table without the need to add debugging code to the controller. Most OpenFlow switches have a passive listening port running on TCP 6634 (by default) that can be used to poll flows and counters or to manually insert flow entries. Do not confuse the dpctl utility with a controller (it’s not the same thing)!
You can use this utility directly under the mininet prompt or in a separate console by connecting to the listening port as indicated below:
dpctl COMMAND tcp:127.0.0.1:6634 OPTIONS where COMMAND can be:

• show
• dump-flows
• add-flow

In our first exercise, let’s configure our virtual network in order to make host h1 to successfully ping host h2. Follow these steps:
STEP 1: Start Mininet with a single switch (the default, Open vSwitch = ovsk) and 3 hosts:

mininet@mininet-vm:~$ sudo mn --topo=single,3 --mac --switch=ovsk --controller=remote
*** Creating network
*** Adding controller
Unable to contact the remote controller at 127.0.0.1:6633
*** Adding hosts:
h1 h2 h3
*** Adding switches:
s1
*** Adding links:
(h1, s1) (h2, s1) (h3, s1)
*** Configuring hosts
h1 h2 h3
*** Starting controller
*** Starting 1 switches
s1
*** Starting CLI:
mininet>
mininet> nodes
available nodes are:
c0 h1 h2 h3 s1
mininet>
mininet>
mininet> net
h1 h1-eth0:s1-eth1
h2 h2-eth0:s1-eth2
h3 h3-eth0:s1-eth3
s1 lo:  s1-eth1:h1-eth0 s1-eth2:h2-eth0 s1-eth3:h3-eth0
c0
mininet>
mininet> dump
<Host h1: h1-eth0:10.0.0.1 pid=9730>
<Host h2: h2-eth0:10.0.0.2 pid=9731>
<Host h3: h3-eth0:10.0.0.3 pid=9732>
<OVSSwitch s1: lo:127.0.0.1,s1-eth1:None,s1-eth2:None,s1-eth3:None pid=9735>
<RemoteController c0: 127.0.0.1:6633 pid=9723>
mininet>

Note that I used “nodes” (list of all virtual devices in my topology), “net” (list of all links) and “dump” (Process-IDs and other info) to double-check that everything started correctly.
STEP 2: Open terminals for each host and run tcpdump on each host
Attention: for Windows users, make sure you installed & run Xming, plus you enabled X-forwarding in your putty!
STEP 3: Test connectivity between h1 and h2: on host h1 perform a “ping -c3 10.0.0.2” (the IP address of host h2)

Results:

• ping will fail, because the switch does NOT know what to do with such traffic (and remember, we don’t run any controller)
• checking the list of flows on the switch will show an empty list (again, nobody told the switch how to deal with the flows/traffic)

STEP 4: Manually add flows on the switch to allow connectivity between h1 and h2
Use the dpctl utility to manually install flows on the switch that will allow connectivity between host h1 and host h2.
Attention: we need two rules to achieve a bidirectional connectivity (echo request and echo replies):

>

The 2 commands basically say:

• dpctl add-flow tcp:127.0.0.1:6634 in_port=1,actions=output:2 = everything received on port 1 (in_port) send out on port 2
• dpctl add-flow tcp:127.0.0.1:6634 in_port=2,actions=output:1 = everything received on port 2 (return traffic) send out on port 1

Result:

• ping is successful
• tcpdump on host h2 shows the traffic from/to h1 (ARP and ICMP)
• tcpdump on host h3 does not see anything (not even the ARP which should be broadcast)!

SDN Exercise #1

The first exercise in the SDN series will use the above setup, but with the additional requirement of treating ARP traffic as broadcast:

• ARP requests (no matter input port) are flooded on all switch ports
• ICMP traffic between hosts h1 and h2 is unicasted on the relevant ports

What are the relevant dpctl add-flow commands to achieve this?[4]

Post your answer in the ‘Comments’ section below and subscribe to this blog to get more interesting SDN lessons and quizzes.
After completing this exercise, you should be able to see this:

– ARP request from host h1 are received by both h2 and h3 (highlighted in green)
– ICMP echo requests from host h1 to h2 are only seen by h2 (highlighted in yellow)
References:

• [1] Nick McKeown’s presentation “How SDN will shape networking”
• [2] Software-Defined Networking: A Comprehensive Survey
• [3] Mininet Overview
• [4] dpctl command reference

- See more at: http://www.costiser.ro/2014/08/07/sdn-lesson-1-introduction-to-mininet/#What_is_Software_Defined_Networking_SDN

(http://www.costiser.ro/)

1.14. Importing and exporting virtual machines

VirtualBox can import and export virtual machines in the industry-standard Open Virtualization Format (OVF).^[6]

OVF is a cross-platform standard supported by many virtualization products which allows for creating ready-made virtual machines that can then be imported into a virtualizer such as VirtualBox. VirtualBox makes OVF import and export easy to access and supports it from the Manager window as well as its command-line interface. This allows for packaging so-called virtual appliances: disk images together with configuration settings that can be distributed easily. This way one can offer complete ready-to-use software packages (operating systems with applications) that need no configuration or installation except for importing into VirtualBox.

Note

The OVF standard is complex, and support in VirtualBox is an ongoing process. In particular, no guarantee is made that VirtualBox supports all appliances created by other virtualization software. For a list of known limitations, please see Chapter 14,Known limitations.

Appliances in OVF format can appear in two variants:

1. They can come in several files, as one or several disk images, typically in the widely-used VMDK format (see Section 5.2, “Disk image files (VDI, VMDK, VHD, HDD)”) and a textual description file in an XML dialect with an .ovf extension. These files must then reside in the same directory for VirtualBox to be able to import them.
2. Alternatively, the above files can be packed together into a single archive file, typically with an .ova extension. (Such archive files use a variant of the TAR archive format and can therefore be unpacked outside of VirtualBox with any utility that can unpack standard TAR files.)

To import an appliance in one of the above formats, simply double-click on the OVF/OVA file.^[7] Alternatively, select "File" -> "Import appliance" from the Manager window. In the file dialog that comes up, navigate to the file with either the .ovf or the .ova file extension.

If VirtualBox can handle the file, a dialog similar to the following will appear:

This presents the virtual machines described in the OVF file and allows you to change the virtual machine settings by double-clicking on the description items. Once you click on "Import", VirtualBox will copy the disk images and create local virtual machines with the settings described in the dialog. These will then show up in the Manager's list of virtual machines.

Note that since disk images tend to be big, and VMDK images that come with virtual appliances are typically shipped in a special compressed format that is unsuitable for being used by virtual machines directly, the images will need to be unpacked and copied first, which can take a few minutes.

For how to import an image at the command line, please see Section 8.10, “VBoxManage import”.

Conversely, to export virtual machines that you already have in VirtualBox, select "File" -> "Export appliance". A different dialog window shows up that allows you to combine several virtual machines into an OVF appliance. Then, select the target location where the target files should be stored, and the conversion process begins. This can again take a while.

For how to export an image at the command line, please see Section 8.11, “VBoxManage export”.

Note

OVF cannot describe snapshots that were taken for a virtual machine. As a result, when you export a virtual machine that has snapshots, only the current state of the machine will be exported, and the disk images in the export will have a "flattened" state identical to the current state of the virtual machine.

Install Teamviewer on Ubuntu

How do I install TeamViewer on my Ubuntu system?

To install TeamViewer on your Ubuntu system, follow these steps:

1. Download the TeamViewer full version under http://www.teamviewer.com/download.
2. Open the teamviewer_linux.deb file with a double click.
   • The TeamViewer installation package will open in the Ubuntu Software Center.
3. Click on the Install button.
   • The Authenticate dialog box will open.
4. Enter the administrative password.
5. Click on the Authenticate button.
   • TeamViewer will be installed.
   • The status within the Ubuntu Software Center changes to Installed.
6. TeamViewer is installed on your Ubuntu system