OpenStack Networking – an introduction

I continue the series on virtual networking with an overview of OpenStack networking concepts. OpenStack is an open source project with an aim to create a scalable cloud operating platform. The primary goal of this software platform is to help build public and private clouds. Specifically it allows users to build and operate infrastructure as a service or IaaS clouds.

So what does networking have to do with OpenStack?

The real idea behind IaaS is to help users create a collection of virtual machines along with the network connectivity between the virtual machines.

Traditionally, to bring up a new application, the IT team will order some physical servers and networking devices such as switches, firewall etc. The physical servers are connected using these physical networking devices into a topology that meets the requirements of the application.

In a virtualized environment, using IaaS clouds, it is possible to setup the same application using virtual machines. In addition, virtual networking can be used to connect these virtual machines. Moreover, the virtual machines are themselves running on physical servers (hypervisor servers) and those hypervisor servers are in turn connected to physical network device.

Therefore, platforms such as OpenStack have the capability to support virtual networking as well as physical networking configurations. This means that in addition to supporting technologies like Linux bridge or VMware virtual switches for virtual networking, OpenStack should also have hooks to provision the physical networks.

An IaaS must allow different users to create isolated network of virtual machines. But these virtual machines and the networks will be instantiated on the shared physical devices. These concepts can be understood using a picture.

In the diagram above, two OpenStack users (also referred to as Tenants), create virtual machines for their own purposes. The VMs for each tenant are color coded. In order to keep their virtual network traffic isolated, they are assigned different VLANs by OpenStack. And these VLANs must be provisioned on both physical and virtual networks to provide full isolation of traffic. Note: OpenStack supports several other techniques for isolation of traffic, in addition to VLAN.

How OpenStack supports physical and virtual network configuration?

Lets take a quick look at the steps an OpenStack user takes to create a network and few virtual machines.

• Step 1 - User logs into the OpenStack GUI (Horizon Dashboard).
• Step 2 - User creates a network. The OpenStack Network is a software entity that represents the whole network of virtual machines.
• Step 3 - User creates an instance. The instance is a term used to represent virtual machines. During this step, the user is asked to choose the network that he would like to associate with the virtual machines.

If you notice, the user is not asked to choose the hypervisor host or the physical switch or the VLANs for traffic isolation. In order to handle the above user actions, different OpenStack services interact behind the screen.

Networking in OpenStack is supported by the ‘Neutron’ service. The creation and booting up of virtual machine is carried out by Nova service. Let us know look at how these services interact to configure the physical and virtual networks.

In Step 2, the user creates a Network. The UI Service (Horizon) forwards the request to Neutron which creates the entries in the database and also associates a VLAN for this network.

In Step 3, the user creates one or more virtual machines. The Horizon service sends the request to Nova which looks at different compute nodes and creates the VM on the least loaded compute server. Nova then sends a message to create port on the network for each virtual machine. Nova also sends the network name as part of this message. This ‘create port’ action is equivalent to plugging a network cable between a server and the adjacent switch.

Note: as part of this step, the VLANs have to be configured on the virtual switches as well as the physical switches.

Neutron supports the concept of plugins (in newer release the terminology has changed) which eventually handle all the provisioning requests. These plugins are capable of supporting different virtual networking technologies such as Linux bridge or Open vSwitch (OVS).

In addition, different physical networking vendors have developed their own plugins, which can be used to configure the physical network with VLANs etc.

The ‘create network’ and ‘create port’ are the most important OpenStack networking API calls. There are many other important APIs and objects in Neutron. We will go deeper into OpenStack networking in subsequent blogs.

Conclusion

We have seen the need for cloud platforms such as OpenStack to support physical and virtual network configurations in order to support IaaS functionality. Since a cloud system can be built with networking equipment from different vendors, OpenStack networking service (Neutron) supports the concept of plugins. With plugins, Neutron can focus on provide crucial IaaS related networking functionality and delegate vendor-specific configurations to plugins.