Comparing SDN Controllers: Open Daylight and ONOS

Overview

Over the last few months, we have been doing testing of the SDN controllers Open Daylight Helium SR3 (mostly via the Brocade Vyatta Controller v1.2) and ONOS Cardinal v1.2.  In this initial article we will start to compare the controllers, focusing on scale, specifically the number of switches that can be handled, by running both OpenFlow 1.0 and 1.3 switches emulated via IXIA and using physical via Pica8 switches.

Note: In the latest version of ONOS (Cardinal) v1.2, there is an issue ONOS handling emulated OpenFlow v1.3 from IXIA, so all scale testing in ONOS was done using OpenFlow 1.0.  Also, in ONOS the term “node” references a copy of ONOS (we run two nodes in our tests) while in Open Daylight, the term “node” refers to a OpenFlow switch.

User Interface

One of the main differences between the ONOS and Open Daylight/BVC is in the controls and information available directly from the Graphical User Interface (GUI).

ONOS

The ONOS GUI has multiple panes including Summary, Node(s) and Controls.

ONOS 1.2

ONOS GUI With 300 Switches

The ONOS GUI displays end hosts in a well defined fashion, you can see them spanning out from the switches.

ONOS-96Hosts

ONOS 96 Hosts Visible

Open Daylight

The default Open Daylight GUI is defined by the features installed and can include features such as a pane to display Nodes, a Yang UI and Yang Visualizer.

Open Daylight

Open Daylight GUI

When attempting to display end hosts, the Open Daylight GUI is not as clean as ONOS as the hosts are interlaced with switches.

ODL Nodes

Open Daylight with 400 Nodes

In the above screen capture of Open Daylight you can see both Nodes (Switches) and Hosts.

Brocade Vyatta Controller

The GUI for the Brocade Vyatta Controller (BVC) is cleaner than the default Open Daylight GUI and in this screen shot has extra modules for their Vyatta vRouter 5600 EMS and their “Path Explorer” application.

BVC 1.2 With EMS 5600

Brocade Vyatta Controller GUI

The current way of displaying Hosts and Switches in Open Daylight/BVC is not easy to work with nor does it scale well.

Scale

In scale testing, we started with 100 Switches and scaled up to 400 Switches, each switch holding 12 hosts.  While Open Daylight (via BVC) was able to scale to 400 switches, ONOS stopped functioning before 400.

Here is BVC with 400 Switches, 800 links and multiple (96 out of 4800) hosts sending traffic to each other.

BVC with 400 Switches

BVC with 400 Switches and Multiple Hosts

BVC 400 Switches Building

BVC 400 Switches Installing Hosts

Here is ONOS when it has reached capacity and is no longer able to handle the number of switches/links/hosts that are being sent to it.

ONOS With 400 Switches

The above screen shot shows two ONOS nodes with 400 switches, 800 links and 0 hosts (we are attempting to send traffic between 48 hosts).  While the devices (switches) are in the database, the hosts are not in the database and the GUI has become unstable and no longer shows any information.

Thoughts

Both ONOS and Open Daylight are solid products when acting as SDN controllers with multiple southbound and northbound interfaces.  The testing done here only focuses on OpenFlow and specifically on scale.  The Brocade version of Open Daylight is well packaged and has some nice extras such as the EMS application which ties in the Brocade Vyatta vRouter 5600.  ONOS continues to focus on providing tools and information in their GUI and 300 switches is a perfectly reasonable amount and certainly more than anyone should put on one or two controllers.

Installing and Using Distributed ONOS

In our work with SDN controllers we concentrate on a few including On.Lab’s ONOS, The OpenDaylight Project and RYU.  In this post we will discuss setting up a distributed ONOS cluster.

First things first, the ONOS wiki pages give a good overview of the requirements:

  • Ubuntu Server 14.04 LTS 64-bit
  • 2GB or more RAM
  • 2 or more processors
  • Oracle Java 8 JRE and Maven installed

For our setup, we used Ubuntu 14.0.4.2 (the latest at the time) installed as an OpenSSH server and we installed Java and Maven from the instructions from the ONOS wiki:

We then installed the required packages on a OSX VM

  • Java 8 JDK
  • Apache Maven (3.0 and later)
  • git
  • Apache Karaf (3.0.3 and later)

Once the dependencies were installed we were able to grab the code from ONOS github page and build it using the “mvn clean install” command using the directions shown on the ONOS wiki

Once built, the process to install the software and get it working properly is not perfectly documented, we ended up suffering issues with websocket failures which were related to the ONOS systems not being setup properly, all of the information is on the ONOS wiki but on different pages.  Here is what we found worked:

Once the install finished, we were able to access the ONOS installations at http://192.168.21.129:8181/onos/ui/index.html and http://192.168.21.130:8181/onos/ui/index.html

Distributed ONOS

Once up, we needed to modify a few files on each server and restart the servers:

/opt/onos/config/cluster.json

and /opt/onos/config/tablets.json

Since ONOS will restart automatically, you simply need to do a system:shutdown.

By default ONOS uses 192.168.56.* as the IP address blocks, so we had to modify them to match our setup.

On the switches we set the controllers

And we were then able to ping between our physical hosts connected to ports 1 and 2 on each switch.

Network Function Virtualization and SDN

Network Function Virtualization or NFV for short is a call to action that looks to aggregate resources across networking, compute and storage.

A collaboration of many of the large players in the telecommunications space, the original NFV call to action focused on lowering the amount of proprietary hardware necessary to launch and operate services.  The solution as discussed in the paper, already exists: high-end, virtualized computing resources.

With the addition of SDN, the combination of virtualized computing resources with storage and programmable switches allows Network Operators to add to their solutions portfolios while avoiding vendor lock-in and forced upgrade cycles. Bringing to life Software-led Infrastructure.

Values of the NFV concept.

Some of the values to the NFV concept are speed, agility and cost reduction.  By centralizing designs around commodity server hardware, network operators can:

  • Do a single PoP/Site design based on commodity compute hardware.
    • Avoiding designs involving one-off installs of appliances that have different power, cooling and space needs simplifies planning.
  • Utilize resources more effectively.
    • Virtualization allows providers to allocate only the necessary resources needed by each feature/function.
  • Deploy network functions without having to send engineers to each site.
    • “Truck Rolls” are costly both from a time and money standpoint.

Generic processors can be repurposed.

Another key point brought up in the NFV call to action paper is the availability of network optimizations in current generation CPUs.

The throughput and functionality of software based routers, switches and other high-touch packet processing devices is constrained by having to send each packet through the processor.  With tools such as Intel’s DPDK and the Linux based NAPI, Intel’s Sandy Bridge and Ivy Bridge processors can be optimized to provide high-speed forwarding paths allowing for much higher throughput rates.

Programmable switches can move packets for lower costs

While not called out in the NFV call to action, programmable switches are a gateway to NFV nirvana.

OpenFlow, a standard for programming data paths into networking equipment, provides one way to separate the control and data planes.  OpenFlow allows for the use of commodity hardware for control plane decision making and inexpensive programmable switches for packet forwarding.  Other benefits to the separation of the control and data planes are:

  • The addition of new features and data sources without changing hardware.
    • The availability of northbound APIs in OpenFlow controllers allow you to plug in features as necessary.
  • Ease of scaling the control plane.
    • Since the control plane is run on commodity hardware and has the ability to be virtualized, you can add or subtract resources as needed.
  • Programmable hardware allows for better accuracy in the planning of future features.
    • Programmable hardware allows the end user to design and deploy a feature or function themselves, rather than relying on the roadmap of the equipment provider.

Summary

Network Operators have realized that solutions to their current issues are available today.  The combination of key parts of both SDN and Virtualization allows Network Operators to deploy features and functions in a timely and cost effective manner.  By using commodity hardware,  costs can be managed and resources allocated effectively.

Evaluating Midokura’s MidoNet Solution

This article is the first in a set of articles that will walk through the evaluation of Midokura’s MidoNet product.  In the first article we will discuss Midokura’s solution, what it is made of, how it works and what expectations have been set with regard to performance and the solution it aims to solve.

Midokura Logo

An Overview of Midokura:

SDN Startup Midokura launched this week at the OpenStack conference in San Diego and has gained a lot of attention in the last week or two.  If you are looking for a good write up on Midokura’s Midonet solution check out Shamus McGillicuddy‘s article on TechTarget called “Midokura network virtualization

Ivan Pepelnjak did a nice technical write up back in August titled “Midokura’s Midonet Layer 2-4 Virtual Network Solution

The Testing View:

In order to build a complete test plan we must first understand the parts of the solution.

By reading articles and looking at the Midokura website, we came up with a good idea of what Midokura was doing.

Midokura Midonet offers a way for companies solve complex network scaling issues using commodity PC hardware.  Midonet creates a fully-meshed overlay network on top of an existing IP network.

MidoNet is a collection of different components:

  • The MidoNet Agent, which runs on each node, fully processing packets as they enter the network and making sure they are delivered to the right host.
  • A routing component based to handle L3 packets (something Nicira’s solution does not offer)
  • A fast, distributed database to keep all of the flow, forwarding, filtering and other data needed to create the virtual topology.
  • Tools to keep everything in synchronization and flowing.

Once we finished the paper evaluation, we reached out to Midokura to get more specific information.

Discussion with Midokura:

We were lucky to be able to grab about 30 minutes of Ben Cherian’s (CSO of Midokura) time on Friday night, only two days before the 2012 OpenStack conference.  As our ultimate goal is to test the MidoNet product, we need a good understanding of MidoNet.  From our discussion we learned the following:

Lab tests have shown a fully utilized 10GE Interface driven by a single core from a multi-core processor.

In MidoNet, Midokura uses some well known Open Source products.  For routing, Midokura uses Quagga.  For the databases Apache Cassandra.  The underlying vSwitch is Open vSwitch and Apache Zookeeper is used to keep everything in sync.

GRE was given as an example in the virtual network overlay as it has been tested and is known to work.  Other protocols could and probably are supported but have not had enough lab time to be called supported.

Evaluating MidoNet Part 1:

As we break down MidoNet’s design we can surmise that as new flows enter the network, the lookup on the first packet should take the longest. Once the first packets have been processed and a flow created, other packets matching the same flow should have a lower latency.

As all inbound packets must pass through the edge, the test plan should look at the time it takes for new packet flows to be inspected, looked up and installed into the flow table. This can be done by measuring the latency of packets crossing the system and comparing the first packet to the later ones once the latency has stabilized. Initially no features should be enabled.

Once a base measurement has been taken and verified, features such as packet filtering should be enabled.  The features should be applied and extended, for example with packet filtering it would start with simple IP destination address filtering.  IP source address, source port, destination port, window size and other knobs should be enabled and measurements taken to see how each new addition affects the lookup time and possibly forwarding performance.

After the base and IP filtering tests are complete you can evaluate the results to build more specific test cases that push MidoNet.

In the next article we will talk more about the MidoNet design what we know about its underlying components and how to test scale.

Network Hardware and SDN

How Does SDN Fit Into The Virtual Data Center?

One thing that needs to be cleared up is the definition of  Network or Networking Hardware.  In the definition of SDN from ONF they discuss the decoupling of the Control and Data Plane with the Data Plane being defined as Network Hardware.  Here is where things can get confusing.

What is Network Hardware?

Wikipedia says the following :

Networking hardware or networking equipment typically refers to devices facilitating the use of a computer network. Typically, this includes gatewaysroutersnetwork bridgesswitcheshubs, and repeaters. Also, hybrid network devices such as multilayer switchesprotocol convertersbridge routersproxy serversfirewallsnetwork address translatorsmultiplexersnetwork interface controllerswireless network interface controllersmodemsISDN terminal adaptersline driverswireless access pointsnetworking cables and other related hardware.”

Essentially anything that is not a end system is network hardware.  The current reality of SDN is that it tends to mean Programmable Switches when it says Network Hardware.  Switches are generally made built on fabrics that allow ports to transmit traffic to and from other ports.

If we were to be true to the current SDN message, we would only look at Programmable Switches.  Reality is there are other ways you can create a Data Plane i.e. Network Hardware.  One of these ways is using a Network Processor (which I covered in the earlier article on Vyatta).

A Computer with a few (or many) Interfaces and a Network Processor is what a Router is.  We can easily see this by looking at the design of Juniper Networks Routers.

This is one of the interesting things I see in the SDN space: Companies that can take advantage of generic hardware and add value.   These companies will create more tools for the architects and operators to use when pushing packets.

We plan to cover as many SDN related topics as possible here at SDN Testing, those that exist today and those that will come in the future.

The Vyatta Cloud Router Story

Vyatta and their approach to Cloud Routers

A few weeks ago I had the pleasure of speaking with Scott Sneddon, Cloud Solutions Architect at Vyatta Inc.  I’ve known Scott since the late 1990’s when he and I both worked for Exodus Communications.

Vyatta is one of the few full featured software based routing vendors in the market today.  Their product is a mix of OpenSource and proprietary software combined together creating a router that can not only live in the cloud but will in the future be able to utilize some of the hardware such as Intel’s Sandy Bridge (and later generation Ivy Bridge) processors as Network Processors.

Network Processors are key to hardware forwarding routers such as the Juniper T series and the Cisco Carrier Routing System allowing them to perform forwarding and features at line rate, something that routers using software based forwarding struggle with.  To get a better picture of software vs hardware forwarding you can read Router Analysis’ Enterprise Edge Router Upgrade Guide where I discuss the Cisco 7200 which uses a software forwarding engine and compare it with higher performance routers with hardware forwarding capabilities.

Vyatta offers a full featured router solution by including VPN, Firewall and other features normally found in hardware locked solutions in their software product.  I feel that Vyatta has a jump on other vendors in the True Virtual Data Center space.  One of the most important parts of the Virtual Data Center is the router and it’s ability to perform equal to or greater than the hardware based router it is replacing.  Using software forwarding alone Vyatta claims to be able to handle up to 2Mpps, which depending on packet size can easily be multiple gigabits of traffic.  In testing Vyatta is seeing up to 11Mpps using an Intel Sandy Bridge processor as a network processor.

A quick note about integrated firewalls: While software firewalls contained within the same hardware as the routers, switches and/or hosts are very useful, they are not a replacement for hardware firewalls.  In security (which I do not claim to be an expert at) the separation of networks using physical links is key.  There is some great information available in this thread on the Cisco support forums where they are discussing the ASA 1000V.

Vyatta keeps a tight relationship with the OpenSource community by hosting Vyatta.org where you can find free versions of Vyatta’s Core Software along with community support, documentation and forums.

SDN Testing, the software defined side of Router Analysis plans to put the Vyatta product through rigorous testing in the coming weeks.

The Virtual Data Center Reality

Virtual Data Centers start to become reality.

Previously posted on Router Analysis

With the recent announcement of the CSR 1000v from Cisco, there are now two commercial Virtual Data Center stories (three if we look at the VMWare vCNS products and use one of the other vendors products for a router) Cisco and Vyatta.

What is a Virtual Data Center?  There will be a lot of different answers but in my view it consists of the following:

  • A pair of redundant Routers with multiple provider uplinks
  • A pair of redundant Firewalls
  • A pair of Load Balancers
  • Front and Backend Servers

In my previous life designing and building Internet Data Centers we would have build this entire setup out of separate parts taking up an entire rack or two.  Now it could be done in a single blade server with multiple redundant power supplies or a pair of highly spec’d servers.

Now, I want to be clear here: I don’t think that the software based Firewalls are up to the task of the hardware based ones.  I think most security companies/consultants would agree that there is a danger when you host both your servers and your firewall on the same shared hardware.  You could design the setup in a way that the ASA is only hosted on it’s own blade(s) but there is still the inherent risk of a misconfiguration or privilege escalation hack allowing someone to bypass the firewall.

Sadly the way around the security issue is to put a physical firewall in the line.  This can be easily done, so it’s mainly just a CapEx issue.

For routers at this time, we only have Cisco and Vyatta commercially.  They both are offering strong products but Cisco’s CSR 1000v is more feature rich supporting many protocols and features that come from using the previously designed and coded Cisco code base.

In the coming weeks and months I am going to be writing about the products available in the space and what limitations still need to be overcome.  I will be working with Cisco, Vyatta, VMWare and others to try and compile as much information as possible.

Summary: The Virtual Datacenter is here.  It’s not perfect, but all of the parts exist from multiple vendors.  The world of Virtualization just got a lot more interesting.

What are your thoughts?

What is SDN and What are we Testing?

SDN Testing

SDN stands for “Software Defined Network”, a simple name with thousands of different meanings.  As defined by WikiPedia “SDN separates the control plane from the data plane in network switches and routers. Under SDN, the control plane is implemented in software in servers separate from the network equipment and the data plane is implemented in commodity network equipment.”

The most important aspect of SDN is the separation of the control and data planes.  This decoupling allows end users (Service Providers, Enterprises) to use commodity hardware to build and expand their networks.

Some of the major players in the SDN space are Vyatta, Cisco, Big Switch and Nicira.  Nicira was recently purchased by VMWare and is being merged into VMWares core product offerings.

Vyatta offers a Quagga based software router with firewall and VPN support.  I recently talked with Vyatta and found their vision and commitment to the Open Source community great.  Vyatta is currently the top player when it comes to software defined routers.

Cisco offers many of the parts needed to create SDNs but some parts have not been released yet.  Cisco has released the Nexus 1000v software switch, the ASA 1000v software firewall and has announced the CSR 1000v IOS XE based software router.  Once Cisco gets the full solution out, they have a chance to leapfrog over the competition due to their history and ability to re-use their current software features.

Big Switch offers an SDN Controller.  Currently they are offering Floodlight, a Open Source version of their product with promises of a commercial version coming soon.

The last company I will cover is Nicira.  Nicira provides what they call NVP, or the Nicira Virtualization Platform.  They combine their software with the Open Source OpenVSwitch to provide a fully software controlled and forwarded network.

Testing the Virtual Datacenter

SDN Testing

One of the goals of the SDN Testing is to test SDN concepts such as the Virtual Datacenter Replacement.  A True Virtual Data Center consists of a few pieces:

A software based router with the ability to connect multiple uplinks and use a routing protocol to load-balance between them.

A software based switch with industry standard features and a good control interface.

A software based firewall with the ability to separate the front and backend systems safely.

The front and back-end systems themselves.