Routing Control Plane for OpenStack
Release Date: August 01, 2016
This Fling augments the capabilities of OpenStack Neutron, providing an easy way to integrate an existing OpenStack environment into a corporate network that uses routable IP addresses for the Tenants, specifically with VMware Integrated OpenStack and NSX. Without this Fling, customers have to enter static IP routes in certain places of the network every time a new Tenant application is provisioned. This process is time consuming, error prone, and outdated. The Fling facilitates all of that by automating the routing peering process.
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”.
This template launches a 3-tier app (Web, App, DB) using the default image packaged with VMware Integrated OpenStack, but it can be used with any OpenStack distribution that supports Heat Orchestration. 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. In order to do this, we will need to create, 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, for 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. 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).
Prerequisites for this Fling
- Internet connectivity (Quagga VM needs to pull installers from public repositories using the metadata definitions).
- Connection to the Metadata service: The Quagga VM pulls its configuration from Nova Metadata using the cloud-init agent. Both are mandatory for the automatic installation to operate correctly.
- vSphere 5.5 or 6.0.
- NSX vSphere version 6.2.x or above.
- NSX Transformers (multi-hypervisor) - Bumblebee release OpenStack Heat Engine compatible with Icehouse and/or Kilo versions of OpenStack.
- Physical/virtual enterprise router with BGP support.
- Create an External Network in Neutron and note the UUID for it. An External Network connects the uplink of the Neutron router(s). Make sure there is a corresponding Neutron External subnet, with an IP range allocation that will be used to address the uplink interface of your Neutron routers, including the ones that will be created automatically by the Heat template. The default gateway for this External Subnet should correspond to the IP address of your physical router. Note: NSX supports both VXLAN and VLAN-backed External Networks.
- Create a Provider Network (VXLAN or VLAN backed) and note the UUID for it. This provider network MUST be on the same VXLAN or VLAN as the External Network created earlier. The Quagga VM will be launched on this network and it requires L2 adjacency with the physical Enterprise router running BGP. Make sure there is a corresponding Neutron Provider Subnet on the same IP subnet as the External Subnet, but using a different IP range. The default gateway for this External Subnet should correspond to the IP address of your physical router. Having the Quagga VM on the same L2 as the physical router allows for a simpler eBGP relationship that does not require eBGP multihop configurations.
- Launch the Heat template from OpenStack Horizon or using CLI/API tools. Replace the default values, including UUIDs for the External and Provider Networks, Tenant subnets that will be advertised by the Quagga BGP VM, BGP Autonomous System numbers (Local and Remote) and the password to access the Quagga BGPD process. You can also select your own Glance image for the Tenant VMs and/or the Quagga VM. The default image used in the Heat Template works out of the box with VMware Integrated OpenStack (VIO), and it is based on Ubuntu Linux, 14.04.
- Once the Quagga VM is up and running, note its IP address and use it to configure as a BGP neighbor on your physical router, using of course the correct AS number and timers.
- At this point, your physical router should be seeing the BGP routes advertised by Quagga and corresponding to the Tenant Networks sitting behind the Neutron router (which has NAT disabled).
- VMware NSX: https://www.vmware.com/products/nsx
- Quagga Tutorial: https://wiki.quagga.net/wiki/index.php/Main_Page
- Neutron Networks, Tenant, Provider, External: http://superuser.openstack.org/articles/tenant-networks-vs-provider-networks-in-the-private-cloud-context
- VMware Integrated OpenStack: https://www.vmware.com/products/openstack
No similar flings found. Check these out instead...
Resource-Efficient Supervised Anomaly Detection Classifier
Resource-Efficient Supervised Anomaly Detection Classifier is a scikit-learn classifier for resource-efficient anomaly detection that augments either Random-Forest or XGBoost classifiers to perform well in a resource-constrained setting.
Horizon Collector for Mac
Horizon Collector for Mac automates the collection and archiving of Horizon View Client logs, eliminating the need to manually identify and gather relevant log files. Horizon Collector also simplifies the process for enabling complete DEBUG logging, and can upload the logs to VMware Support for you. In addition to the application logs, this script will collect PCoIP, USB, RTAV, and ThinPrint logs. Recommended users of this script: VDI Administrators and end-users alike.
vCloud Director REST API Shell (RAS)
vCloud Director REST API Shell (RAS) provides an alternative interface for interacting with vCloud Director. Rather than using a web browser, this Fling allows you to interact with vCloud Director through the command-line using a small python script.