Openstack Networking

In this blog, I will cover the following aspects of Openstack Networking.

  • Evolution from Nova-network to Neutron
  • Neutron plugin model
  • ML2 plugin
  • Openstack + ODL integration

Evolution from nova-network to Neutron

When Openstack project was initially started, the networking component was integrated along with the compute component Nova. With nova-network, only a flat network using vlan can be created. As Cloud technologies evolved, there was a need for the following:

  • Multi-tier network with overlapping IP address space.
  • Better isolation approach compared to security groups between the application tiers of the network.
  • Avoid scalability issues with vlan based network and ability to use tunneling technologies.
  • Programmatic creation of networks that allows for “Networking as a service”.
  • Capability to use multiple different disparate technologies and physical and virtual switches in the same network.

Openstack networking service was initially called as Quantum, later renamed to Neutron. Currently Neutron is a core project in Openstack. Following picture illustrates different layers in Cloud Networking perspective and where Neutron fits in: openstack_network3

Some notes from above picture:

  • Bottommost layer is device layer and this can be either physical or virtual devices. Physical devices can be Cisco Nexus, Juniper Qfabric and Virtual devices can be Open vswitch, linux bridge, Cisco n1k etc.
  • Management layer consists of different technologies to connect networks like VLAN, VXLAN, NVGRE.
  • Controller layer is the SDN controller layer that can be either opensource or proprietary controllers.
  • Neutron can talk to Network devices either through direct device plugins or can offload that task to SDN controller. Both models are possible.

Neutron provides better isolation between tiers of application using logical routers. Also, it provides support of Overlay mechanism. Neutron provides scalable Enterprise networking support.

Neutron plugin model:

Following picture illustrates the Neutron plugin model: openstack_network1

Neutron API is the API layer that is device agnostic. Plugin layer takes care of converting device agnostic API to device specific configuration. Each device will have a plugin agent that talks to the plugin layer in Neutron. Both the plugin and plugin agent are provided by the corresponding device vendor. API extensions can be vendor proprietary or something which is not a core functionality. Some of the popular plugins are Openvswitch, linux bridge, Cisco nexus, Nicira nvp etc. Following picture illustrates a simple Openstack deployment model with Neutron service. openstack_network2

In the above example, Controller node, Compute node and Network node are deployed on 3 separate machines.

  • Neutron server runs in controller node and it also contains the device plugin.
  • Plugin agent runs in compute node and talks to the Neutron server.
  • Network node provides services like dhcp, l3 and it also runs plugin agent.
  • There is a separate Data and Management network. Data network allows for VMs to talk to each other as well as to Network node. Management network allows for all Openstack components to talk to each other.

ML2 plugin:

The per device plugin architecture caused lot of duplicate code and the maintenance of plugins became a nightmare. ML2 plugin approach was proposed which separated the type driver from the mechanism driver. The type driver consists of vlan, vxlan, nvgre and the mechanism driver consists of drivers to access various devices. ML2 plugin allows for heterogenous deployments. Following picture illustrates ML2 plugin detail. openstack_network4

Openstack + ODL integration:

ODL is an Opensource SDN controller. I have covered more details on ODL in my previous blogs. Following picture illustrates the Openstack+ODL networking model. openstack_network5

Neutron ML2 plugin is mostly a proxy and calls the Opendaylight REST APIs. This model allows for Openstack to offload Networking components to ODL. As per what I read, this model improves scalability, I have not completely understood why that is the case. It could be because ODL already has lot of Network intelligence and different mechanisms to talk to devices and this need not be duplicated in Openstack. For more information on Network Virtualization, please refer to my previous blog. To try out Openstack+ODL, please refer here. I will try to do a live demo of Openstack Networking functionality in the next set of blogs.


Pictures used in the above blog are from the references.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s