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.
We have created a simple Border Gateway Protocol (BGP) implementation using Heat and Quagga. Please understand that this is “A way” to do dynamic routing today, not “THE way”. Formal BGP support is imminent in OpenStack. However, in the meantime, you can use the Heat template below and experiment with an independent dynamic routing control plane based on BGP. This can foster a productive conversation with your Network architects regarding cloud infrastructure design:
This template launches a 3-tier app (Web, App, DB) using the default image packaged with VIO. More importantly, this template uses Quagga to create a BGP (eBGP) relationship between the tenant environment and a physical router running BGP as the dynamic routing protocol.
The Quagga VM must sit on the same layer 2 as the Neutron router and the physical router (VLAN 100 in this example). In order to do this, we pre-created, outside of Heat, a VLAN-backed Provider network on the same VLAN as the External Network. We split the IP subnet assigned to that VLAN (10.1.1.0/24 in this example) in two:
- Half of it for Neutron router uplink IPs
- Half for a DHCP scope of the Quagga network
Doing the subnet split allows the Quagga VM and the physical router to be on the same L2, so we can do eBGP without the need of eBGP multi-hop. After that, the template takes dynamic entries. It is as dynamic as we can make it, and it allows the arbitrary configuration of:
- Web Subnet CIDR and gateway
- App Subnet CIDR and gateway
- DB Subnet CIDR and gateway
All tenant subnets are automatically injected in the BGP configuration of Quagga.
Finally, the template also detects the Neutron router external IP and injects it in the Quagga BGP configuration as the next hop for advertised routes (tenant subnets). The cool thing is that starting with a default Ubuntu blank VM, we end up with a fully operational BGP control plane, semi-synchronized to the 3-tier topology.
This is a non-invasive, basic way of doing dynamic routing, which could be interesting in NO NAT topologies. This implementation also illustrates an approach that could be used while we wait for official BGP support in Neutron.
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.