Openstack Advanced Services in Neutron provides configuration APIs for Load Balancer, Firewall and VPN services. Configuration can also be automated using Heat templates. However, one of the challenges is the need to specify deployment variance such as network context to automate the provisioning of network services using templates. This becomes unmanageable and error prone in a large deployment. This blog explains how Openstack Group-Based Policy (GBP) Services framework addresses this challenge and how the One Convergence Network Services Delivery Platform (NSD) integrates with Cisco Application Centric Infrastructure to simplify lifecycle management of network services.
GBP Service Overview
OpenStack GBP is a community driven intent-based policy model and implementation project in which One Convergence is an active contributor. The policy model allows for declarative definition of application, network and network services intent. Apart from the L2/L3 networking model and functionality, it also provides the following rich functionality for network services.
- Service agnostic insertion, chaining and composition model
- Service agnostic pluggable architecture. It provides an architecture to plugin any network service beyond those defined by Neutron Advanced Services
- Service agnostic lifecycle management framework. It provides a mechanism to integrate vendor service orchestration solutions, such as One Convergence NSD
One Convergence NSD Overview
One Convergence NSD brings the programmability of SDN to Networking L3-L7. NSD enables complete automation of L3-L7 services for the cloud via community driven open architecture policy model. The following is a brief summary of NSD capabilities.
- Lifecycle management of network services.
- Provisions rich set of network services both open source such as VyOS and HaProxy and vendor services such as ASAv, F5.
- Flexible deployment options - Neutron/ML2 and GBP APIs
- Network service assurance / High availability
- Network service operational visibility and analytics
Cisco Application Centric Infrastructure
Cisco Application Centric Infrastructure (ACI) provides application-centric, policy-based automation using the Cisco APIC and Nexus 9000. In the OpenStack environment, ACI offers a distributed virtual networking solution by leveraging both the physical network fabric and Open vSwitch managed through the OpFlex Agent. It renders L2 and L3 context of GBP policy on ACI fabric and provides the following functionality for GBP Services.
- Primitives to insert and chain any type of Network Service - Tap, Transparent L-2, L-3.
- Policy driven model to simplify the deployment of Network Services for
- Cloud Operator
- End user
- Operate networking infrastructure at scale for Network Services and Openstack clouds at large.
We discuss below how GBP auto derives service context for each of the three neutron advanced services. For the sake of this discussion, we use neutron heat template for service configuration. It is important to note that GBP doesn't limit the configuration to being only a heat template.
The network context required to launch a neutron lbaas template needs to include parameters such as VIP IP address, CIDR block of pool subnet, a list of IP addresses for pool servers. A template devoid of this variable information makes the template generic and therefore can be shared by any load balancer service, simplifying the automation process.
This context specific configuration is derived at the time of load balancer service instantiation and passed on to service orchestration solution provided by NSD.
- CIDR block of pool subnet is derived from the implicitly created neutron subnet for the corresponding GBP group.
- A neutron VIP port is created on the implicitly created neutron network for the corresponding GBP group.
- Pool members are the IP addresses of members of the corresponding GBP group.
NSD uses this derived context, rebuilds the heat template and passes other required information as parameter values and launches the template. Additionally when a new member is added to a GBP group, policy engine notifies NSD which updates the stack. Thus it also helps adapt the network service to changes in the environment.
The network context required to launch a fwaas template includes the CIDR block of source and destination. The user creates a fwaas template with firewall rules without specifying the source and destination CIDRs. As consumers and providers are added to this service, source CIDR is derived from consumer group and destination CIDR is derived from provider group. This context is passed to NSD which rebuilds the template in case of initial instantiation or updates the stack in case of a running instance.
The network context required to launch a vpnaas template includes local CIDR, local gateway IP, remote CIDR and remote gateway IP. The local context is auto derived and the remote information can be parameterized even though it cannot be derived. Ipsec and IKE policy definitions make VPN service template complex. An operator could simplify the deployment of a VPN service by publishing a common security template devoid of this network context, which can be auto derived or parameterized.
As we have seen in the previous section, network context in *aas templates can be auto derived and NSD makes use of this derived information either to rebuild a template or update a running stack. A template devoid of this run time variance can be reused for the deployment of the network service in any context and this makes automation easier. Auto derivation of network context eliminates the need for manual configuration of IP/CIDR data or a complex automation processes to enable the deployment