Home > Blogs > OpenStack Blog for VMware > Tag Archives: Neutron

Tag Archives: Neutron

VMware Integrated OpenStack 3.1 GA. What’s New!

VMware announced general availability (GA) of VMware Integrated OpenStack 3.1 on Feb 21 2017. We are truly excited about our latest OpenStack distribution that gives our customers enhanced stability on top of the Mitaka release and streamlined user experience with Single Sign-On support with VMware Identity Manager.   For OpenStack Cloud Admins, the 3.1 release is also about enhanced integrations that allows Cloud Admins to further take advantage of the battle tested vSphere Infrastructure & Operations tooling providing enhanced security, OpenStack API performance monitoring,  brownfield workload migration, and seamless upgrade between central and distributed OpenStack management control planes.






VIO 3.1 is available for download here.  New features include:

  • Support for the latest versions of VMware products. VMware Integrated OpenStack 3.1 supports and is fully compatible with VMware vSphere 6.5, VMware NSX for vSphere 6.3, and VMware NSX-T 1.1.   To learn more about vSphere 6.5, visit here, vSphere 6.3 and NSXT, visit here.
  • NSX Policy Support in Neutron. NSX administrators can define security policies, shared by the OpenStack Cloud Admin with cloud users. Users can either create their own rules, bounded with the predefined ones that can’t be overridden, or only use the predefined, depending on the policy set by the OpenStack Cloud Admin.  NSX Provider policy feature allows Infrastructure Admins to enable enhanced security insertion and assurance all workloads are developed and deployed based on standard IT security policies.
  • New NFV Features. Further expanding on top of VIO 3.0 capability to leverage existing workloads in your OpenStack cloud, you can now import vSphere VMs with NSX network backing into VMware Integrated OpenStack.  The ability to import vSphere VM workloads into OpenStack and run critical Day 2 operations against them via OpenStack APIs enables you to quickly move existing development projects or production workloads to the OpenStack Framework.  VM Import steps can be found here.  In addition full passthrough support by using VMware DirectPath I/O is supported.
  • Seamless update from compact mode to HA mode. If you are updating from VMware Integrated OpenStack 3.0 that is deployed in compact mode to 3.1, you can seamlessly transition to an HA deployment during the update. Upgrade docs can be found here.
  • Single Sign-On integration with VMware Identity Manager. You can now streamline authentication for your OpenStack deployment by integrating it with VMware Identity Manager.  SSO integration steps can be found here.
  • Profiling enhancements.  Instead of writing data into Ceilometer, OpenStack OSprofiler can now leverage vRealize Log Insight to store profile data. This approach provides enhanced scalability for OpenStack API performance monitoring. Detailed steps on enabling OpenStack Profiling can be found here.

Try VMware Integrated OpenStack Today



Advanced Security Services with Neutron, NSX and Palo Alto Next Generation Firewall

Building on the concepts and implementation that I have been working on for the past few weeks around service chaining in Neutron, this post will now focus on how to onboard the Palo Alto Next Generation Firewall platform onto OpenStack.

Palo Alto Networks has one of the most mature and robust integrations with VMware NSX and we also share many joint customers in production. Together, we have seen tremendous success in the market, and that success can now extend to those prospects wanting to do OpenStack, while augmenting their security strategy with the added visibility and protection that Palo Alto offers.

The basic tenets for this integration between Palo Alto Networks and VMware NSX, in the context of an OpenStack deployment, remain the same:

  • The Security/Firewall Team is in complete control of the security lifecycle of the tenant apps.
  • Although not mandatory, Provider Networks are preferred in this context over Tenant Networks.
  • Tenants use the OpenStack API to consume Compute and Storage Services, while Networking and Security remain under the control of the Cloud Admins or Central IT.
  • This model is relatively common in the Enterprise, but not common in the DevOps use case where Tenants control their own network and security workflows.

If the above prerequisites are met, one can safely implement the VMware NSX + Palo Alto integration and overlay OpenStack Neutron on top, offering a complete private Cloud deployment that incorporates advanced security controls for East-West traffic. VMware NetX is the glue holding everything together.

Here is the high level workflow:

  • Integrate VMware NSX and Palo Alto Networks following best practices and recommended software versions for NSX, Panorama and the PAN VM Series. The instructions to do this can be found here.
  • Deploy VMware Integrated OpenStack 3.0 (if it hasn’t been done already) or any OpenStack distribution compatible with the Mitaka release, using VMware vSphere and VMware NSX as the underlying infrastructure components.
  • Identify the Compute clusters that will host your OpenStack workloads and deploy Palo Alto network introspection to those clusters:



  • Ensure the Service VMs (local firewalls) are properly registered and licensed in Panorama:


  • Create an NSX Security Group with a classification criteria that meets your needs. In this example we are using the proverbial example based on VM Name (Name Contains Web in this case):



  • In Panorama, create a Dynamic Address Group for the OpenStack Instances, that corresponds to the NSX Security Group created in the previous step:


  • Then, in Panorama, create the Policy you want to apply to the redirected traffic:


  • Back on NSX, create a redirection policy, or Partner Security Rule, for the interesting traffic that will be subject to inspection (Network Introspection). In this example we are redirecting inbound HTTP/HTTPS traffic for additional security controls:

Note 1: You will also need to create DFW rules to allow the traffic that will be redirected, as these rules are applied prior to the redirection for outbound traffic (VM >> World) and are applied after redirection for inbound traffic (World >> VM). More details on how these flows move through the Hypervisor can be found on the NSX Design Guide.

Note 2: You may need to use the “ApplyTo” Field in NSX to limit the redirection policy to the specific VMs in question.

  • screenshot7Finally, you can use OpenStack Nova to boot Instances (VMs) that satisfy the membership criteria of the appropriate NSX Security Group. It is extremely important that you DO NOT attach a Neutron Security Group to these Instances. We are bypassing self-service security provisioning in OpenStack and delegating all security controls to the Firewall Team.

Note 3: If you are using Horizon (OpenStack GUI), you may need to detach the default Neutron Security Group after you launch your Instance(s).


Note 4: Another approach, not covered in this document, has to do with the manipulation of the policy.json file for Neutron, in order to restrict Security Group changes or additions by anyone other than the Admin. In this case, launching Instances without a Neutron Security Group attachment is not required, as the Neutron Security Group that is used would only be modified by said Admin.

  • Verify your configuration and security policies.

As we can see, the above approach safely integrates value-add security and visibility services into OpenStack today, and showcases the power of NSX as a platform for Private Cloud deployments based on OpenStack.

Follow these links for the previous two articles in our 3-part blog series:

Part 1: Next Generation Security Services in OpenStack

Part 2: Advanced Security Services in OpenStack and Fortinet

VMware and Palo Alto Networks will be discussing this and many other interesting topics at VMworld Europe 2016 in Barcelona, Spain. Don’t forget to swing by the Palo Alto Networks booth in the Solutions Exchange if you need more information.

Apples To Oranges: Why vSphere & VIO are Best Bests for OpenStack Adoption

OpenStack doesn’t mandate defaults for compute, network and storage, which frees you to select the best technology. For many VMware customers, the best choice will be vSphere to provide OpenStack Nova compute capabilities.


It is commonly asserted that KVM is the only hypervisor to use in an OpenStack deployment. Yet every significant commercial OpenStack distro supports vSphere. The reasons for this broad support are clear.

Costs for commercial KVM are comparable to vSphere. In addition, vSphere has tremendous added benefits: widely available and knowledgeable staff, vastly simplified operations, and proven lifecycle management that can keep up with OpenStack’s rapid release cadence.


Let’s talk first about cost. Traditional, commercial KVM has a yearly recurring support subscription price. Red Hat OpenStack Platform-Standard 2 sockets can be found online at $11,611/year making the 3 year cost around $34,833[i]. VMware vSphere with Operations Management Enterprise Plus (multiplied by 2 to match Red Hat’s socket pair pricing) for 3 years, plus the $200/CPU/year VMware Integrated OpenStack SnS is $14,863[ii]. Even when a customer uses vCloud Suite Advanced, costs are on par with Red Hat. (Red Hat has often compared prices using VMware’s vCloud Suite Enterprise license to exaggerate cost differences.)



When 451 Research[iii] compared distro costs based on a “basket” of total costs in 2015 they found that commercial distros had a cost that was close to regular virtualization. And if VMware Integrated OpenStack (VIO) is the point of comparison, the costs would likely be even closer. The net-net is that cost turns out not to be a significant differentiator when it comes to commercial KVM compared with vSphere. This brings us to the significant technical and operational benefits vSphere brings to an OpenStack deployment.


In the beginning, it was assumed that OpenStack apps would build in the resiliency that used to be assumed from a vSphere environment, thus allowing vSphere to be removed. As the OpenStack project has matured, capabilities such as VMware vMotion and DRS (Distributed Resource Scheduler) have risen in importance to end users. Regardless of the application the stability and reliability of the underlying infrastructure matters.


There are two sets of reasons to adopt OpenStack on vSphere.


First, you can use VIO to quickly (minutes or hours instead of days or weeks) build a production-grade, operational OpenStack environment with the IT staff you already have, leveraging the battle-tested infrastructure your staff already knows and relies on. No other distro uses a rigorously tested combination of best-in-class compute (vSphere Ent+ for Nova), network (NSX for Neutron), and storage (VSAN for Cinder).


Second, only VMware, a long-time (since 2012), active (consistently a top 10 code contributor) OpenStack community member provides BOTH the best underlying infrastructure components AND the ongoing automation and operational tools needed to successfully manage OpenStack in production.


In many cases, it all adds up to vSphere being the best choice for production OpenStack.


[i] http://www.kernelsoftware.com/products/catalog/red_hat.html
[ii] http://store.vmware.com/store/vmware/en_US/cat/ThemeID.2485600/categoryID.66071400
[iii] https://451research.com/images/Marketing/press_releases/CPI_PR_05.01.15_FINAL.pdf

This Article was written by Cameron Sturdevant,  Product Line Manager at VMware

Next Generation Security Services in OpenStack

OpenStack is quickly and steadily positioning itself as a great Infrastructure-as-a-Service solution for the Enterprise. Originally conceived for that proverbial DevOps Cloud use case (and as a private alternative to AWS), the OpenStack framework has evolved to add rich Compute, Network and Storage services to fit several enterprise use cases. This evolution can be evidenced by the following initiatives:

1) Higher number of commercial distributions are available today, in addition to Managed Services and/or DIY OpenStack.
2) Diverse and expanded application and OS support vs. just Cloud-Native apps (a.k.a “pets vs. cattle”).
3) Advanced network connectivity options (routable Neutron topologies, dynamic routing support, etc.).
4) More storage options from traditional Enterprise storage vendors.

This is definitely great news, but one area where OpenStack has lagged behind is security. As of today, the only robust option for application security offered in OpenStack are Neutron Security Groups. The basic idea is that OpenStack Tenants can be in control of their own firewall rules, which are then applied and enforced in the dataplane by technologies like Linux IP Tables, OVS conntrack or, as it is the case with NSX vSphere, a stateful and scalable Distributed Firewall with vNIC-level resolution operating on each and every ESXi hypervisor.

Neutron Security Groups were designed for intra and inter-tier L3/L4 protection within the same application environment (the so-called “East-West” traffic).

In addition to Neutron Security Groups, projects like Firewall-as-a-Service (FWaaS) are also trying to onboard next generation security services onto these OpenStack Clouds and there is an interesting roadmap taking form on the horizon. The future looks great, but while OpenStack gets there, what are the implementation alternatives available today? How can Cloud Architects combine the benefits of the OpenStack framework and its appealing API consumption model, with security services that provide more insight and visibility into the application traffic? In other words, how can OpenStack Cloud admins offer next generation security right now, beyond the basic IP/TCP/UDP inspection offered in Neutron?

The answer is: With VMware NSX.

NSX natively supports and embeds an in-kernel redirection technology called Network Extensibility, or NetX. Third party ecosystem vendors write solutions against this extensibility model, following a rigorous validation process, to deliver elegant and seamless integrations. Once the solution is implemented, the notion is simply beautiful: leverage the NSX policy language, the same language that made NSX into the de facto solution for micro-segmentation, to “punt” interesting traffic toward the partner solution in question. This makes it possible to have protocol-level visibility for East-West traffic. This approach also allows you to create a firewall rule-set that looks like your business and not like your network. Application attributes such as VM name, OS type or any arbitrary vCenter object can be used to define said policies, irrespective of location, IP address or network topology. Once the partner solution receives the traffic, then the security admins can apply deep traffic inspection, visibility and monitoring techniques to it.


How does all of the above relate to OpenStack, you may be wondering? Well, the process is extremely simple:

1) First, integrate OpenStack and NSX using the various up-streamed Neutron plugins, or better yet, get out-of-the-box integration by deploying VMware’s OpenStack distro, VMware Integrated OpenStack (VIO), which is free for existing VMware customers.
2) Next, integrate NSX and the Partner Solution in question following documented configuration best practices. The list of active ecosystem partners can be found here.
3) Proceed to create an NSX Security policy to classify the application traffic by using the policy language mentioned above. This approach follows a wizard-based provisioning process to select which VMs will be subject to deep level inspection with Service Composer.
4) Use the Security Partner management console to create protocol-level security policies, such as application level firewalling, web reputation filtering, malware protection, antivirus protection and many more.
5) Launch Nova instances from OpenStack without a Neutron Security Group attached to them. This step is critical. Remember that we are delegating security management to the Security Admin, not the Tenant. Neutron Security Groups do not apply in this context.
6) Test and verify that your security policy is applied as designed.


This all assumes that the security admin has relinquished control of the firewall from the Tenant and that all security operations are controlled by the firewall team, which is a very common Enterprise model.

There are some Neutron enhancements in the works, such as Flow Classifier and Service Chaining, that are looking “split” the security consumption between admins and tenants, by promoting these redirection policies to the Neutron API layer, thus allowing a Tenant (or a Security admin) to selectively redirect traffic without bypassing Neutron itself. This implementation, however, is very basic when compared to what NSX can do natively. We are actively monitoring this work and studying opportunities for future integration. In the meantime, the approach outlined above can be used to get the best of both worlds: the APIs you want (OpenStack) with the infrastructure you trust (vSphere and NSX).

In the next blog post we will show an actual working integration example with one of our Security Technology Partners, Fortinet, using VIO and NSX NetX technology.

Author: Marcos Hernandez
Principal Engineer, CCIE#8283, VCIX, VCP-NV

OpenStack Summit 2016 Re-Cap – A Guide to Practical OpenStack Network Virtualization using OVN

OVN (pronounced “oven”) is a rapidly growing, open source solution being developed by the Open vSwitch (OVS) community that provides network virtualization for OVS. While OVN isn’t designed to work with VMware Integrated OpenStack, it’s another OpenStack project to which VMware has been devoting time and effort, and definitely worth knowing about.

For a good sense of how OVN is progressing, check out this talk by four OVS community members at the 2016 OpenStack Summit. They explain how OVN works and why it’s worth trying.


VMware OVS developer Ben Pfaff kicks things off with an overview of network virtualization, emphasizing the value of being able to abstract a physical network and of making network provisioning self-service.

Fellow VMware engineer and core OVS and OVN developer Justin Pettit next outlines OVN’s capabilities and stresses its compatibility with the platforms that OVS already works with. When it comes to OpenStack, he reports, “the best integration that we have right now is with OpenStack Neutron but we plan to have it work with other CMSes . . . and you can do everything that you would want through the command line or through data base calls that you can do through Neutron.”


Like OVS, OVN is open source and vendor-neutral, and has quickly gained support from a diverse group of vendors including VMware, IBM, Red Hat, and eBay among others. The goal is to match OVS production quality and keep OVN’s design simple but scalable to 1,000s of hypervisors. “We hope it becomes the preferred method for most people who want to use OVS or networking in general,” Pettit says.

If successful, OVN will expand OVS, help improve Neutron’s functionality, and significantly reduce the development burden on Neutron for OVS integration. Add an improved architecture built around ‘logical flows’ and configuration coordinated through databases, and it’s set to outperform existing OVS networking plugins, Pfaff argues.


The same goes for security, adds Ryan Moats of IBM – OVN now uses a connection tracker, letting OVS manage state-full connections itself and speeding security group throughput significantly. Its L3 security group design also does all L3 processing in OVS, further improving performance.

The fourth speaker, Han Zhou of eBay, outlines how the group overcame a series of bottlenecks to scale the OVN control plane to 2,000 hypervisors, 20,000 VIF ports and 200 and logical switches operating at once.

The team then highlights ongoing scale improvements and profiles the OVN Neutron plugin. “We will run this in our public cloud,” says IBM’s Moats before outlining OVN deployment and what to look for in the upcoming OVN release. Finally, all four speakers invite their audience to contribute to OVN, and try it out for themselves.

VMware Integrated OpenStack is also available for testing in VMware’s Hands-on Lab. Or download it for a free with a current license for vSphere Enterprise Plus, vSphere Operations Management, or NSX with vSphere Standard.

No Dynamic Routing in OpenStack? No Problem!

Today’s blog post discusses how VMware NSX can enable dynamic routing for VMware Integrated OpenStack (VIO) deployments. This article was written by Marcos Hernandez, one of the OpenStack specialists in VMware’s Networking & Security Business Unit (NSBU).

One of the main concerns that we hear from customers when explaining the native capabilities of OpenStack Neutron is its lack of dynamic routing support. This is especially serious when we consider that many Enterprises implementing OpenStack are not delegating IP subnetting to their tenants, but instead prefer to remain in control of the IP allocation, mainly due to the fact that their applications will often sit on routable IP address space. This is one of the assertions that both Wells Fargo and VMware will be presenting at the OpenStack Summit in Austin. There is also a comprehensive superuser article on the topic: Provider Networks vs Tenant Networks.

We can typically get away with just using static routing, but if a customer really wanted to use dynamic routing, Neutron does not currently offer native capabilities to do so. Continue reading

VMware @ OpenStack Summit Austin 2016

OpenStack Summit Austin Logo

The OpenStack Summit is returning to the city where it began: Austin! The VMware Integrated OpenStack team will be on hand to share customer testimonials as well as information about the work we’ve done in our distribution and drivers since the Tokyo Summit.

We look forward to seeing you in Austin at the VMware booth!

Here is a list of the summit sessions where you can hear more from our customers and team members:

Monday, April 25

Tuesday, April 26

Thursday, April 28

See you at the Summit!

Subnet Pools with VMware NSX

Today’s blog post discusses how VMware NSX supports Neutron Subnet Pools. This article was written by Marcos Hernandez, one of the OpenStack specialists in VMware’s Networking & Security Business Unit (NSBU).

Neutron, the OpenStack networking project, continues to evolve to support use cases that are relevant for the Enterprise. Early on, OpenStack networking was focused on delivering overlapping IP support for tenant subnets. Over time, more complex topologies have been added to Neutron. In some cases, the network administrators may want to be in charge of the IP scheme used by the consumers of an OpenStack private cloud. These and other options, are discussed in a recent SuperUser article published by Wells Fargo, as well as in the Neutron-NSX integration documentation.

Continue reading

OpenStack Networking with VMware NSX, Part 3

Today’s blog post is the final entry in a series by Marcos Hernandez, one of the OpenStack specialists in VMware’s Networking & Security Business Unit (NSBU). Part 1 discussed the basics of the Neutron integration for VMware NSX. Part 2 discussed foundational integrations for L2 and L3 network services.

Security Groups

Neutron Security Groups have historically implemented either Linux IPTables or Open vSwitch stateless matches to filter traffic at the hypervisor level. Both approaches have presented challenges to operations teams there is serious work underway aimed at improving the experience (VMware is a contributor to these efforts).

When using NSX and vSphere, we deploy a stateful firewall on each and every ESXi host. That means that every hypervisor will protect the microcosm of virtual machines that it hosts, providing the notion of a distributed data plane. We call this a distributed firewall, or DFW. The NSX DFW runs in the kernel of ESXi and enables granular security controls at the VM vNIC level. When using Neutron Security Groups, the NSX DFW is configured, via the plugin integration. Neutron Security Groups are mapped to instances, meaning the NSX DFW will protect the VM unit.



Running an actual firewall on each hypervisor within your OpenStack cloud has the following benefits:

The NSX firewall scales as your ESXi footprint grows. The mere act of increasing your compute capacity due to the organic growth of your business, automatically means you are also adding security and compliance to your virtual infrastructure.

It is important to note that Neutron Security Groups and NSX micro-segmentation can be used standalone, without adopting L2 overlays and L3 virtualization. While not as flexible as a full network virtualization implementation, the micro-segmentation use case is very popular with our customers and provides a great on ramp for customers to introduce OpenStack and NSX without disrupting whatever VLAN operational model may already be in place.

Load Balancing

As of the Kilo version of the NSX plugin, Neutron LBaaS v1.0 support was incorporated. The workflow includes the following capabilities:

  • Tenants are able to create application pools (initially empty).
  • Tenants add several members to the pool (instance IP address).
  • Tenants create one or several health monitors.
  • Tenants associate the health monitors with the pool.
  • The tenant finally creates a virtual IP (VIP) with the pool.
  • Supported protocols: TCP, HTTP and HTTPS.


As with other network services in our implementation, we leverage the NSX Edge Services Gateway (ESG) as an inline load balancer as well as a Neutron router. The NSX load balancer is very feature-rich, and it is ready to support the Neutron LBaaS 2.0 API spec in a future version of the plugin.

Summary – Supported Topologies

The table below summarizes the topologies supported by the NSX-Neutron plugin:

Use Case Comments
VLAN-backed L2, no L3 services Micro-segmentation only No overlays. Security Groups leverage Distributed Firewall policies
VLAN-backed L2, L3 services, LBaaS optional Leverage VLANs for L2, NSX Edge for L3 No overlays. L3 provided by NSX Edge. No distributed routing support. Static routes only
L2/L3 overlays, no NAT, LBaaS optional Enterprise customers that don’t need overlapping IP addresses Can use distributed router and/or NSX Edge. No overlapping IPs allowed. Static routes only. Very efficient. Preferred enterprise model
L2/L3 overlay, NAT, LBaaS optional Enterprise customers that need overlapping IPs Can use distributed router and/or NSX Edge. Static routes only. Very efficient. Cloud provider/service provider preferred model

Conclusion – Why NSX-v with OpenStack Neutron?

The benefits of NSX align with the requirements of a robust OpenStack private cloud implementation, which are:

  • Agility – Networking at the speed of apps.
  • Mobility – Provision anywhere, move anywhere.
  • Security – Micro-segment, detect anywhere, detect early
  • Multi-tenancy – Share hardware across multiple tenants.
  • Simplified operations – Centrally manage, monitor everywhere.

By leveraging the NSX Neutron Plugin for vSphere developed by VMware, cloud administrators can introduce NSX into their OpenStack environment and offer their users and developers the open APIs they require, all without compromising uptime, stability and scalability.

This concludes the series discussing OpenStack Neutron integrations with VMware NSX. You can get some hands-on experience with VMware Integrated OpenStack with our revamped VMworld Hands-on Lab (HOL-1620) featuring VMware Integrated OpenStack and NSX Optimized for vSphere. You can also check out Part 1 and Part 2 of this blog series to read more about NSX integrations with OpenStack.

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.

OpenStack Networking with VMware NSX, Part 2

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

L2 Services

As we discussed in our previous article, when a tenant creates a Neutron network (or networks), the plugin signals NSX Manager to provision a logical switch (or switches), which are overlay constructs that utilize VXLAN to create L2 segments over L3 physical networks. VXLAN is an industry standard, co-developed by VMware and others and supported across the board. Over the past couple of years, VXLAN overlays have been largely demystified and the initial objections (like performance, lack of visibility, etc.) have given way to more practical concerns (like changes in operational processes, automation, etc.). Customers and vendors are getting more educated about each other’s vision and together are making VXLAN, and Software Defined Networking for that matter, a reality in their environments.

These L2 segments, overlays as they may be, are just that: L2 segments. Without a router to connect them together or to other networks, they are completely isolated from each other. An OpenStack Cloud administrator can control, via quotas, the number of Neutron networks allowed per tenant.

L3 Services

Tenants in OpenStack are allowed, by default, to create their own IP subnets and routers. We will cover some of the NSX capabilities available with the Neutron plugin. Before we do that though, just a quick parenthesis about self-service in general: As OpenStack gains more traction in the Enterprise, we are learning that these self-service capabilities may not be desirable. Admins may want to remain in control of the IP subnetting, for example, especially if the use case calls for routable IP address space everywhere. OpenStack lacks the necessary controls to enforce this type of restrictions, so short of forbidding API access to specific functions or simply relying on the good-old honor system, customers have little to no choice when it comes to the built-in OpenStack governance. Projects like OpenStack Congress are attempting to bridge this gap, and some commercial products are already providing the controls that IT requires. vRealize Automation (vRA) is a VMware platform that offers comprehensive, scalable governance and could potentially leverage extension packages to drive provisioning workflows in OpenStack.


Back to the L3 services discussion, we stated that a tenant could create Neutron routers. The NSX-Neutron plugin will translate this provisioning request and signal NSX Manager to create an NSX Edge Services Gateway, or ESG. The ESG is a network appliance that supports a vast number of network features (not all of which are visible by OpenStack, by the way) and that is broadly used in our integration.


Once the Neutron router is created, our previously provisioned Web and App Neutron networks (L2 segments) can be connected to it and routing between them will be available.

The uplink of a Neutron router can be connected to an External network. This is also known as setting the gateway. This External network must sit on routable IP address space within the organization and is also the network where floating IPs reside. If the tenant networks sit on RFC1918 space, then the Neutron router must do Network Address Translation, or NAT (source NAT for internal to external access and DNAT for floating IPs). If the tenant networks sit on routable subnets, then the router does not have to do NAT.

The tenant networks can also be VLAN-backed, instead of VXLAN-backed. If the tenant wants to or has to use VLANs instead of VXLANs, then the admin must create these networks on behalf of the tenant.

Tenant routers can be exclusive (defined at provisioning time using an API extension) or shared (default behavior). Depending on your performance and scalability expectations, you will choose one or the other.

When using NSX, the Neutron L3 services may include a distributed router, which is a very powerful capability in NSX that allows for the optimization of East-West traffic in routed topologies. This is a good example of an enterprise-grade capability of NSX and differentiator from the reference implementation, which can be leveraged without compromising the basic tenet of OpenStack in keeping the API open. A distributed router sends traffic from the source hypervisor to the destination hypervisor without hairpinning the packets through an NSX ESG or a physical router SVI. This increases performance significantly and streamlines traffic engineering within the data center. 04-fig-2-02

Finally, Neutron only supports static routing, which means that when using NSX with your OpenStack implementation, dynamic routing is not an option. NSX supports both OSPF and BGP, but until Neutron supports either one, tenants won’t be able to use dynamic routing. Efforts to implement a BGP speaker in OpenStack began during the Juno cycle and are still ongoing. When this work is complete, the NSX platform, due to its native support of BGP, will be ready to support dynamic routing once the Neutron plugin has been updated.

The picture below shows the basic topologies supported  by the NSX-Neutron plugin:


DHCP Services

In our implementation of DHCP, we replace the dnsmasq process that is used by the reference implementation with an NSX Edge Services Gateway configured with static DHCP bindings. This approach has proven to be very reliable at scale (thousands of VMs).

There is logic in the NSX-Neutron plugin that will automatically determine how to use an Edge Services Gateway for DHCP services. Depending on the use case (overlapping IPs vs. non-overlapping IPs) the same ESG may be reused for multiple tenant networks, as the picture below shows: 06-fig-2-04


In Part 3 of this article series, we will discuss the implementation of critical Neutron services such as security groups and Load-Balancing-as-a-Service. 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.