SDN part 2: Building an SDN playground on the cloud using Open vSwitch and OpenDaylight

Introduction

In the previous article of these series, I explained the concept of Software-defined Networking and why it matters. In this post, we will go through building an actual SDN lab using open source building blocks which can be used to get hands-on experience with SDN and OpenFlow.

For the purpose of this tutorial, we used Google Cloud’s Compute platform (IaaS) but that is not necessary in any way for following this tutorial. All the VMs in this tutorial are running Ubuntu 16.04 LTS with Linux 4.15 kernel.

Step 1: Build a switch!

What is a switch? It’s a network device that forwards packets between its interfaces based on some logic given to it through its configuration. Note that in SDN, generally, a switch is not necessarily an L2-switch. It operates in all layers. An OpenFlow switch can decide on how to forward frames and packets based on their attributes. Those attributes might be the frame’s source/destination MAC addresses, IP packet’s header fields, ICMP flags, UDP/TCP port number, and a lot more. The switch forwards flows and network flows can be defined based on any set of attributes.

Luckily, there are software implementations of an OpenFlow compatible switch i.e. one that is able to receive commands using the OpenFlow protocol (which is the most widely used south-bound protocol in SDNs and If you don’t know what any of these mean, just read part 1 already). Open vSwitch (OvS) is one of these software switches.

To create a switch machine, we create a VM and install Open vSwitch on it:

To run OvS, we have to run two processes: OvS database and OvS switch.

Note that we’re running the processes in the background using screen (if you don’t know what screen is, I strongly recommend that you take a moment to learn how it works, you will thank me later).

And there it is! You can attach to the screens to see the output. The OvS process’ output should look like this:

Now that OvS is running, create a bridge with an internal interface:

Now this is a sad lonely switch, with no hosts nor other switches connected to it which is as useless as a switch can be. So, go ahead and make another VM and re-do all these steps for it, and proceed to step 2 which is connecting these two switches.

Step 2: Connect the switches using VXLAN

Now we have two virtual machines but how do we connect them i.e. how do we create a link between our switches. Sure, one way is to use complicated VM hypervisor’s bridging features or use the cloud API to do it for us but that’s all too difficult and inflexible.

VXLAN is a technology used to create virtual overlay links between network endpoints. In a VXLAN tunnel, the two endpoints emulate having a link between them by basically wrapping Ethernet frames inside UDP packets and sending it to each other. So it’s as if an actual physical Ethernet link existed between the endpoints, but under the hood, it’s just sending Ethernet frames as UDP payloads.

VXLAN Overview: Layer-2 frames are sent in the payload of UDP packets between two endpoints, emulating a physical link between them.

Using VXLAN, we can easily create or destroy virtual links between our machines. Each VXLAN link has a key which is a number that differentiates it from the other links between the same two endpoints. Two create the link, each direction of the communication should be set-up separately. On switch VM 1 run:

And on the second switch VM run:

Replacing <SWITCH-IP> and <SWITCH2-IP> with proper values. Also note that 2000 is an arbitrary value for the key here and it can be replaced with anything less than 2²⁴ as long as it’s the same value for both commands. You can always recheck the configuration of created links using ovs-vsctl show .

Step 3: Add the hosts

Now it’s time to create the hosts that are connected using this switches. For the purpose of this tutorial, we use OvS on the hosts too, not for its switching features, but solely for creating a VXLAN link between the host and the switch. This obviously isn’t the only way to achieve this and certainly not the most efficient one, but since we already know how to do it, what’s the harm.

Create two VMs, h1 and h2, and install OvS on them by following step 1 instructions. Make a VXLAN link from h1 to switch 1.

ovs-vsctl add-port br0 vx1 - set interface vx1 type=vxlan options:remote_ip=<SWITCH1_IP> options:key=2001

And the reverse direction, by running on switch1:

ovs-vsctl add-port br0 vx2 - set interface vx2 type=vxlan options:remote_ip=<HOST1_IP> options:key=2001

And the same for h2 and switch2.

Step 4: Creating an OpenDaylight controller

For the SDN controller, there are quite a few options. OpenDaylight is indeed the most popular one, but ONOS, NOX, and Ryu are also very good alternatives each having their own strengths and weaknesses.

Create another VM for the controller, and install OpenDaylight (ODL) as follows:

Now Karaf (main ODL process) is running in the screen. You can check on it using screen -r karaf and after the loading is finished it should look like this:

Now it’s time to install some OpenDaylight features. You can access the Karaf shell via the screen (as above) and run the commands directly, or you can use SSH to access the shell. The Karaf shell commands are:

feature:repo-refresh
feature:install odl-dluxapps-applications odl-restconf odl-dluxapps-applications odl-openflowplugin-southbound odl-l2switch-all

To run them using SSH, simply do:

After the commands are done running, ODL will have activated its HTTP interface, OpenFlow integration, and automatic layer-2 switching.

Step 5: Set controller for the switches

Of course, the switches wouldn’t magically find out about the controller. You will have to set the controller on switch-1 and switch-2:

Replacing <CONTROLLER_IP> with its proper value.

After running this, the controller should be aware of the switches. You can verify this using OpenDaylight’s web interface. Go to http://<CONTROLLER_IP>:8080/index.html . A login page should appear. The username and password both are admin . (amazing security, huh? don’t worry, just Google how to change this later)

After logging in, click the upper-right burger icon and navigate to topology from the left menu bar that just appeared. You should find a fancy visualization of the network here. If the hosts haven’t appeared yet, don’t worry.

Step 6: Test everything!

All that remains now is to test this set-up by setting overlay IP addresses to the hosts and doing a ping. By overlay network, we mean this logical network that we have built using VXLAN links and OvS switches on top of our network. The hosts are certainly part of this network, so we should as well assign new IP addresses to them for this network. On h1, we run:

ifconfig br0-int 100.0.0.101 mtu 1400 up

And on h2:

ifconfig br0-int 200.0.0.102 mtu 1400 up

Now from h1, try pinging h2:

ping 200.0.0.102

And if your ping messages got replied, congratulations! You just set-up your first SDN network. The sky is the limit because now you can use the OpenDaylight REST API to start programming the network.

Source

If you are familiar with Ansible, you can use these two playbooks for installing Open vSwitch and Open Daylight.

Where to next?

You can now start browsing the materials for SDN programming or start playing around with OpenFlow rules. In the next part, I will explain setting up VTNs (Virtual Tenant Networks) on top of the SDN.