Overview

Just recently finished writing my Master thesis on aspects of open SDN applications and since then had some spare time to play lil’ bit more with it. In this post I want to share quick aftermath and two examples I found useful when starting with SDN (especially as a noob, thus SDN101). One is FlowMaker app by Northbound Networks and the other is sdn-loadbalancing script that pushes flow updates to create paths.

What is SDN again?

Well, it is already 2017 and by now SDN took many turns in various people’s definitions of what SDN represents. Thus, I will go with the popular opinion that SDN is an umbrella term that can take characteristics of several visions such as:

{:start=“1”} 1. Open SDN: defined by Open Networking Foundation where SDN is basically physical separation of network control plane from the forwarding plane where controllers such as OpenDaylight, Floodlight, ONOS, NOX, POX and others manage network devices from centralized location.

SDN via overlays: seen as a virtual network overlayed across physical network using protocols such as VxLAN and NvGRE. One of the examples include VmWare’s NSX, acquired by purchasing Mr. Martin Casado’s company Nicira, and Nuage Networks where primary aspects are put on high-scalability, multi-DC and multi-hypervisor environment demands.
Brite-Box/White-Box: seen as an approach to invest money into purchase of low-end, independent-manufacturer switches instead of proprietary hardware, OS or features. Some of the examples include Pica8, Cumulus Networks and to some degree Facebook’s Open Switching System.
SDN via API’s: this fourth vision is seen as a method of enriching interfaces for direct programmability of configuration instead of traditional use of CLI. Some of the examples include use of REST, YANG and NETCONF APIs.
SDN using ASICs: seen as an approach to intentionally attach networks architecture to specific hardware via ASIC chips. Example would include CISCO’s SDN solution named ACI that runs on OpFlex protocol where attachment lies with the inevitable use of their Nexus product line.
Cloud automation: mainly seen in the use of OpenStack project where the goal is to manage all networking devices, servers, storage and other from a single console.
NFV vision: this vision is based on an approach that nowadays servers are completely virtualized and thus question being asked is why not transfer over this whole approach to networking area where we would have virtualized firewalls, routers, switches and others. Examples of this vision would be Cisco CSR, HPVSR, OVS etc.

Using cool stuff (Mininet)

Mininet is a network emulator that runs a collection of end-hosts, switches, routers, and links on a single Linux kernel. It uses lightweight virtualization to make a single system look like a complete network, running the same kernel, system, and user code. A Mininet host behaves just like a real machine; you can ssh into it (if you start up sshd and bridge the network to your host) and run arbitrary programs (including anything that is installed on the underlying Linux system.)

In few scenarios that I ran, I found simple tree-topology sufficient for experimenting. The best way is to create a custom topology:

class fatTreeTopo(Topo):

    "Fat Tree Topology"

    def __init__(self):
        "Create Fat tree Topology"

        Topo.__init__(self)

        #Add hosts
        h7 = self.addHost('h7', cls=Host, ip='10.0.0.7', defaultRoute=None)
        h8 = self.addHost('h8', cls=Host, ip='10.0.0.8', defaultRoute=None)
        h1 = self.addHost('h1', cls=Host, ip='10.0.0.1', defaultRoute=None)
        h2 = self.addHost('h2', cls=Host, ip='10.0.0.2', defaultRoute=None)
        h4 = self.addHost('h4', cls=Host, ip='10.0.0.4', defaultRoute=None)
        h3 = self.addHost('h3', cls=Host, ip='10.0.0.3', defaultRoute=None)
        h5 = self.addHost('h5', cls=Host, ip='10.0.0.5', defaultRoute=None)
        h6 = self.addHost('h6', cls=Host, ip='10.0.0.6', defaultRoute=None)

        #Add switches
        s10 = self.addSwitch('s10', cls=OVSKernelSwitch)
        s3 = self.addSwitch('s3', cls=OVSKernelSwitch)
        s17 = self.addSwitch('s17', cls=OVSKernelSwitch)
        s4 = self.addSwitch('s4', cls=OVSKernelSwitch)
        s18 = self.addSwitch('s18', cls=OVSKernelSwitch)
        s1 = self.addSwitch('s1', cls=OVSKernelSwitch)
        s11 = self.addSwitch('s11', cls=OVSKernelSwitch)
        s21 = self.addSwitch('s21', cls=OVSKernelSwitch)
        s22 = self.addSwitch('s22', cls=OVSKernelSwitch)
        s2 = self.addSwitch('s2', cls=OVSKernelSwitch)

        #Add links
        self.addLink(h1, s1)
        self.addLink(h2, s1)
        self.addLink(h3, s2)
        self.addLink(h4, s2)
        self.addLink(h5, s3)
        self.addLink(h6, s3)
        self.addLink(h7, s4)
        self.addLink(h8, s4)
        self.addLink(s1, s21)
        self.addLink(s21, s2)
        self.addLink(s1, s10)
        self.addLink(s2, s10)
        self.addLink(s3, s11)
        self.addLink(s4, s22)
        self.addLink(s11, s4)
        self.addLink(s3, s22)
        self.addLink(s21, s17)
        self.addLink(s11, s17)
        self.addLink(s10, s18)
        self.addLink(s22, s18)

topos = { 'mytopo': (lambda: fatTreeTopo() ) }

HPE VAN SDN Controller

HP acquired Aruba networks few years ago, and since the latter is offering its SDN controller for free trial download which is great considering that HP has an App Store for SDN applications, some of which can be installed for free and others paid for.

App

The one I suggest getting first is FlowMaker Deluxe by NorthBound Networks. You can get it here. FlowMaker is basically the easiest way to create flow entries directly at controller and push them to switches. It is all done through WEB UI, no REST APIs and no complications.

Note: There is an issue with installing apps with HP VAN controller that are not signed. These can’t be verified and it is needed to add one line to “dmk.sh” script and restart the controller. More info here

Floodlight Controller

One of the most popular open source SDN controllers with continuous development and improvements in features and performance. Floodlight’s architecture is based on Big Network Controller (BNC), the company’s commercial offering. Applications written for Floodlight Controller by any developer can be made available for certification and qualification with BNC. Hence, as Floodlight is one of the core elements of the Big-Switch’s product(s), it would be fair to assume that the company will support it.

Loadbalancer Github Repo

I came across this cool repository and gave it a try. It works as a charm, has a implementation explanation but is little bit dated. For running loadbalancer.py script you need to pull Floodlight v1.2 and in case of using REST API such as getting switches ports information:

curl http://<controller-ip>:8080/wm/core/controller/port-desc/json

I found out that this is supported only by running OpenFlow v1.3

Halftime

I will most certainly try some other SDN-related stuff in the upcoming weeks, and as soon as I get something interesting to share, this post will get an update.

Manipulating SDN traffic