Home > Blogs > OpenStack Blog for VMware

OpenStack Networking with VMware NSX, Part 1

Today’s blog post is the start of a series by Marcos Hernandez, one of the OpenStack specialists in VMware’s Networking & Security Business Unit (NSBU). Part 2 and Part 3 will be published in the upcoming weeks. So, check back for more on this topic!

As OpenStack becomes more ubiquitous in the industry, cloud architects are looking for ways to provide enterprise-grade network and security services to their consumers without compromising the primary objectives of an OpenStack-based private cloud, which include:

  • Vendor-neutral APIs.
  • Infrastructure choice and flexibility.
  • A public cloud experience with on-premises infrastructure.

Neutron, the networking project in OpenStack, has come a long way in the last few years, adding powerful capabilities at a very fast pace while enabling rich network workflows and a variety of use cases. According to the latest user survey data, Neutron is favored over Nova networking in ~60% of the production OpenStack deployments, which suggests an increased interest to move off flat (VLAN-based) topologies. There is general consensus in the OpenStack community that a cloud that lacks rich network functionality is a mediocre cloud.

As more features are added to Neutron, its architecture becomes more complex (a universal perception amongst OpenStack users). As of the Kilo release, the Neutron community has wisely decided to “decompose” Neutron. The general idea is that Neutron will remain focused on core L2 and L3 services, while L4-L7 services will be “pluggable” and abide by a well-known extensible data model. For vendors like VMware, this is great news. We now have a reference architecture to develop against, promote our value-add, and expose the unique capabilities of NSX.  We can do this and still honor a consumption model that prioritizes the desirable northbound OpenStack APIs.

With all that said, it is important to note (and know) that Neutron core is developed using a reference implementation based on open source components, including:

  • Open vSwitch – hypervisor-level networking.
  • dnsmasq – DHCP/DNS services.
  • Linux iptables – for security groups.
  • L3-agent – routing services.
  • HAProxy – load balancing.

In a scaled-out production deployment, the reference implementation typically encounters challenges. As a result, OpenStack operators will either scale back the features deployed in an attempt to gain stability, or they will utilize a software-defined network provider.  This is widely recognized as factual and comes at no surprise once you understand how Neutron core is developed and tested.

The community is doing a great job at defining the core APIs and the extensibility model, while many vendors have also taken it upon themselves to test the scalability, reliability and upgradeability of an OpenStack-based solution using their own “productized” distributions. Often, as it is the case with VMware NSX, vendors will replace the reference open source components with their own technology. OpenStack consumers don’t notice the difference; they still interact with the northbound Neutron APIs by means of plugins and drivers, which “translate” the Neutron API calls into private, southbound calls targeted at the vendor’s infrastructure. In the case of VMware NSX Optimized for vSphere, such interactions look like this:


Neutron services leverage a VMware-developed plugin that makes API calls to NSX Manager, which is the API provider and management plane of NSX.  This Neutron plugin is itself an open source project and can be used with ANY OpenStack implementation (DIY and/or off-the-shelf). VMware offers its own OpenStack distribution, VMware Integrated OpenStack, which natively integrates the NSX-Neutron plugin, in addition to other plugins and drivers that connect OpenStack compute and storage services to vSphere.  Leveraging enterprise-grade server virtualization with vSphere and enterprise-grade networking with NSX, customers will enjoy an enterprise-grade OpenStack infrastructure layer, while leveraging the vSphere skillset and tools (vMotion, host maintenance mode, DRS, etc.) which typically are available in IT groups today.

In this post, we will double-click on the Neutron-NSX interactions and will describe how NSX ultimately brings stability to Neutron. You can also see a recorded version of this content that was presented at the OpenStack Summit in Vancouver.

Basic Neutron Workflows and NSX Equivalents
Neutron consists of a number of basic network workflows that are considered “table stakes”. These include:

  • L2 services: Ability for tenants to create and consume their own L2 networks.
  • L3 services: Ability for tenants to create and consume their own IP subnets and routers. These routers can connect intra-tenant application tiers and can also connect to the external world via NATed and non-NATed topologies.
  • Floating IPs: A “Floating IP” is nothing more than a DNAT rule, living on the Neutron router, that maps a routable IP sitting on the external side of that router (External network) to a private IP on the internal side (Tenant network). This floating IP forwards all ports and protocols to the corresponding private IP of the “instance” (VM) and is typically used in cases where there is IP overlap in tenant space.
  • DHCP Services: Ability for tenants to create their own DHCP address scopes.
  • Security Groups: Ability for tenants to create their own firewall policies (L3/L4) and apply them directly to an instance or a group of instances.
  • Load Balancing as-a-Service (LBaaS): Ability for tenants to create their own load balancing rules, virtual IPs and load balancing pools.

The picture below shows these basic workflows and their situation as it relates to the application, as well as the corresponding NSX element that is leveraged each time. For more information about NSX, please visit the official VMware NSX product page.


In Part 2 of this article series, we will dig deeper into the inner workings of the Neutron plugin implementation for NSX. In the meantime, check out our revamped VMworld Hands-on Lab (HOL-1620) featuring VMware Integrated OpenStack and NSX Optimized for vSphere.

Marcos Hernandez is a Staff Systems Engineer in the Network and Security Business Unit (NSBU). He is responsible for supporting large Global Enterprise accounts and providing technical guidance around VMware’s suite of networking and cloud solutions, including NSX and OpenStack. Marcos has a background in datacenter networking design and expert knowledge in routing and switching technologies. Marcos holds the CCIE (#8283) and VCIX certifications, and he has a Masters Degree in Telecommunications from Universidad Politécnica de Madrid.

This entry was posted in Technical and tagged , , on by .
Trevor Roberts Jr.

About Trevor Roberts Jr.

Trevor Roberts, Jr. is the Senior Technical Marketing Manager for OpenStack at VMware and the lead author of the VMware Press title, “DevOps for VMware Administrators". He enjoys speaking to customers and partners about the benefits of using OpenStack with VMware technologies. In his spare time, Trevor shares his insights on data center technologies via the VMware Blogs and on Twitter (@VMTrooper). His contributions to the IT community have garnered recognition by his designation as a VMware vExpert, Cisco Data Center Champion, and EMC Elect.

3 thoughts on “OpenStack Networking with VMware NSX, Part 1

  1. Pingback: Subnet Pools with VMware NSX - OpenStack Blog for VMware - VMware Blogs

  2. Pingback: VMware Integrated OpenStack (VIO) and NSX - Free webinar - OpenStack Blog for VMware - VMware Blogs

  3. Pingback: VMware Integrated OpenStack (VIO) and NSX – Free webinar - CNARENA - Social Media | Content Sharing | Social Bookmarking

Leave a Reply

Your email address will not be published.