OpenStack and Software Defined Networking

John Belamaric

February 15th, 2016

One of the key benefits of OpenStack is the ability to control and integrate with Software Defined Networking (SDN) controllers. Let’s take a look at what SDN is, and how OpenStack makes it accessible.

SDN in Detail

SDN allows you to create and configure networking in software, rather than through manual intervention. An SDN solution consists of network devices combined with a software-based controller. This is simply a separate software component that may be running on a specialized platform or, more typically, on commodity hardware (usually running a Linux variant). The network devices themselves may also be either specialized devices with high-performance ASICs, or simple low-cost Linux boxes.

Software-defined networking controllers can use either an imperative model or a declarative model, or a combination of both. In an imperative model, the controller responds to commands to make changes to the network. For example, an external actor could call a create VLAN function on the controller, which would render that on the network by configuring the various underlying devices properly with the new VLAN.

The imperative model is necessary, but not sufficient, to realize the main goal of SDN – fully automated network configuration. For that goal, we need to move to a declarative model. In this model, the user defines the desired end-state of the network, and the controller takes responsibility for rendering that end-state. Take the simple create VLAN call discussed earlier. In the imperative model, the user made the call, the VLAN was configured, and that was it. In the declarative model, the controller would store the fact that the user requested such a VLAN. It would render it on the network, but would retain the knowledge that the VLAN should exist. It will monitor and maintain the configuration of the VLAN until the specification is changed.

For a simple command, this is not a big difference. But for complex networks, this is a dramatic change from the traditional device-by-device configuration of a network. In the declarative model, the controller has a complete model of the network in a central location, and guarantees the network will be rendered as such (typically in an eventually consistent manner, rather than a transactional manner).

In the discussion above, we talk about the SDN controller rendering the configuration on “network devices”. In fact, generally the configuration needs to be rendered on the hypervisor nodes and perhaps on some network devices. Consider the typical deployment architecture of a datacenter cloud, with compute nodes attached to top-of-rack switches, and many VMs on each compute node. In this layout, often VMs that exist on the same compute node must interact with one another. We really want to avoid having traffic exit the compute node and needing to “hairpin” through the top-of-rack switch. To prevent this, we require a local switching service for virtual machines on the compute node – that is, we need the node to run a vSwitch of some sort. The controller is responsible for configuring this vSwitch for proper connectivity between VMs.

The configuration of the physical switches may come into play when we want to control traffic between VMs sitting on different compute nodes. In that case, we can utilize SDN solutions that include a hardware component (for example, Cisco ACI), or we can go with a pure software solution that does not reconfigure the networking gear. Instead, these solutions typically use tunneling protocols such as GRE or VxLAN, to encapsulate the packets that live in the tenant network, transmit them over the physical network, and unpack them on the other end.

OpenStack Neutron

So, how does this relate to OpenStack Neutron? In fact, Neutron provides a uniform interface into SDN controllers and a reference SDN implementation itself. Neutron consists of a uniform API (with optional extensions that may be vendor specific) that is used to create the declarative model, which is stored in the Neutron database.

The rendering of the specification onto the network itself is the responsibility of the core plugin. This is what realizes the vendor-neutral Neutron network model on the actual network gear. In fact, Neutron has many different types of plugins that provide different types of services; however, for this discussion we are referring to those that provide the basic switching (Layer 2) and routing (Layer 3) network functions. These types of plugins can be either monolithic, in which case they implement the complete Neutron core plugin interface, or they may use the Modular Layer 2 (ML2) and/or the L3 service plugin frameworks to implement only a subset of the core functionality. For example, switch vendors can implement an ML2 mechanism driver, while leaving L3 up to the Neutron reference implementation or another solution.

The default reference implementation uses the ML2 plugin with the Open vSwitch (OVS) mechanism driver, and implements the Layer 3 service with the Neutron L3 Agent, which uses the Linux routing stack with network namespaces and iptables to implement virtual router functionality. This means that each compute node will run the Open vSwitch service which provides the actual switching service, and the Neutron Open vSwitch agent, which renders the Neutron network specification onto the configuration of the Open vSwitch service.

Similarly, there is a Neutron L3 agent, which utilizes calls to basic Linux system utilities such as ip and iptables to implement the Neutron virtual routers. Together, the L2 and L3 solutions provide a working reference implementation of an SDN controller.

Discover even more essential OpenStack skills with our blog on how to implement efficient networking and security on your latest deployment.

About the author

John Belamaric is a software and systems architect with nearly 20 years of software design and development experience, his current focus is on cloud network automation. He is a key architect of the Infoblox Cloud products, concentrating on OpenStack integration and development. He brings to this his experience as the lead architect for the Infoblox Network Automation product line, along with a wealth of networking, network management, software, and product design knowledge. He is a contributor to both the OpenStack Neutron and Designate projects. He lives in Bethesda, Maryland with his wife Robin and two children, Owen and Audrey.