OpenStack Integration
OpenStack defines a flexible software architecture for creating cloud-computing environments. The reference software-based implementation of OpenStack allows for multiple Layer 2 transports, including VLAN, GRE, and VXLAN. The Neutron project within OpenStack can also provide software-based Layer 3 forwarding. When OpenStack is used with ACI, the ACI fabric provides an integrated Layer 2/3 VXLAN-based overlay networking capability that can offload network encapsulation processing from the compute nodes to the top-of-rack or ACI leaf switches. This architecture provides the flexibility of software overlay networking in conjunction with the performance and operational benefits of hardware-based networking.
Extending OpFlex to the Compute Node
OpFlex is an open and extensible policy protocol designed to transfer declarative networking policies such as those used in Cisco ACI to other devices. By using OpFlex, you can extend the policy model native to ACI all the way down into the virtual switches running on OpenStack Nova compute hosts. This OpFlex extension to the compute host allows ACI to use Open vSwitch (OVS) to support common OpenStack features such as source Network Address Translation (SNAT) and floating IP addresses in a distributed manner.
The ACI OpenStack drivers support two distinct modes of deployment. The first approach is based on the Neutron API and Modular Layer 2 (ML2), which are designed to provide common constructs such as network, router, and security groups that are familiar to Neutron users. The second approach is native to the group-based policy abstractions for OpenStack, which are closely aligned with the declarative policy model used in Cisco ACI.
ACI with OpenStack Physical Architecture
A typical architecture for an ACI fabric with an OpenStack deployment consists of a Nexus 9000 spine/leaf topology, an APIC cluster, and a group of servers to run the various control and compute components of OpenStack. An ACI external routed network connection as a Layer 3 connection outside the fabric can be used to provide connectivity outside the OpenStack cloud. Figure 6-10 illustrates OpenStack infrastructure connectivity with ACI.
)
OpFlex Software Architecture
The ML2 framework in OpenStack enables the integration of networking services based on type drivers and mechanism drivers. Common networking type drivers include local, flat, VLAN, and VXLAN. OpFlex is added as a new network type through ML2, with an actual packet encapsulation of either VXLAN or VLAN on the host defined in the OpFlex configuration. A mechanism driver is enabled to communicate networking requirements from the Neutron servers to the Cisco APIC cluster. The APIC mechanism driver translates Neutron networking elements such as a network (segment), subnet, router, or external network into APIC constructs in the ACI policy model.
The OpFlex software stack also currently utilizes OVS and local software agents on each OpenStack compute host that communicates with the Neutron servers and OVS. An OpFlex proxy from the ACI leaf switch exchanges policy information with the agent OVS instance in each compute host, effectively extending the ACI switch fabric and policy model into the virtual switch. Figure 6-11 illustrates the OpenStack architecture with OpFlex in ACI.
)
OpenStack Logical Topology
The logical topology diagram in Figure 6-12 illustrates the connections to OpenStack network segments from Neutron/controller servers and compute hosts, including the distributed Neutron services.
)
){kind=link}
){kind=link}
){kind=link}
Mapping OpenStack and ACI Constructs
Cisco ACI uses a policy model to enable network connectivity between endpoints attached to the fabric. OpenStack Neutron uses more traditional Layer 2 and Layer 3 networking concepts to define networking configuration. The OpFlex ML2 driver translates the Neutron networking requirements into the necessary ACI policy model constructs to achieve the desired connectivity. The OpenStack Group-Based Policy (GBP) networking model is quite similar to the Cisco ACI policy model. With the Cisco ACI unified plug-in for OpenStack, you can use both ML2 and GBP models on a single plug-in instance.
Table 6-1 illustrates the OpenStack Neutron constructs and the corresponding APIC policy objects that are configured when they are created. In the case of GBP deployment, the policies have a direct mapping to the ACI policy model. Table 6-2 shows the OpenStack GBP objects and their corresponding ACI objects.
Table 6-1 OpenStack Neutron Objects and Corresponding APIC Objects
Neutron Object |
APIC Object |
|---|---|
(Neutron Instance) |
VMM Domain |
Project |
Tenant + Application Network Profile |
Network |
EPG + Bridge Domain |
Subnet |
Subnet |
Security Group + Rule |
N/A (Iptables rules maintained per host) |
Router |
Contract |
Network:external |
L3Out/Outside EPG |
Table 6-2 OpenStack GBP Objects and Corresponding APIC Objects
GBP Object |
APIC Object |
|---|---|
Policy Target |
Endpoint |
Policy Group |
Endpoint Group (fvAEPg) |
Policy Classifier |
Filter (vzFilter) |
Policy Action |
-- |
Policy Rule |
Subject (vzSubj) |
Policy Ruleset |
Contract (vzBrCP) |
L2 Policy |
Bridge Domain (fvBD) |
L3 Policy |
Context (fvCtx) |
Prerequisites for OpenStack and Cisco ACI
Keep in mind the following prerequisites for OpenStack and Cisco ACI:
▪ Target audience: It is important to have working knowledge of Linux, the intended OpenStack distribution, the ACI policy model, and GUI-based APIC configuration.
▪ ACI Fabric: ACI fabric needs to be installed and initialized with a minimum APIC version 1.1(4e) and NX-OS version 11.1(4e). For basic guidelines on initializing a new ACI fabric, see the relevant documentation. For communication between multiple leaf pairs, the fabric must have a BGP route reflector enabled to use an OpenStack external network.
▪ Compute: You need to have a controller and servers connected to the fabric, preferably using NIC bonding and a VPC. In most cases the controller does not need to be connected to the fabric.
▪ L3Out: For external connectivity, one or more Layer 3 Outs (L3Outs) need to be configured on the ACI.
▪ VLAN mode: For VLAN mode, a non-overlapping VLAN pool of sufficient size should be allocated ahead of time.
Guidelines and Limitations for OpenStack and Cisco ACI
The following sections describes the guidelines and limitations for OpenStack and Cisco ACI.
Scalability Guidelines
There is a one-to-one correlation between the OpenStack tenant and the ACI tenant, and for each OpenStack tenant, the plug-in automatically creates ACI tenants named according to the following convention:
convention_apic_system_id_openstack_tenant_name
You should consider the scalability parameters for supporting the number of required tenants.
It is important to calculate the fabric scale limits for endpoint groups, bridge domains, tenants, and contracts before deployment. Doing so limits the number of tenant/project networks and routers that can be created in OpenStack. There are per-leaf and per-fabric limits. Make sure to check the scalability parameters for the deployed release before deployment. In the case of GBP deployment, it can take twice as many endpoint groups and bridge domains as with ML2 mode. Table 6-3 and Table 6-4 list the APIC resources that are needed for each OpenStack resource in GBP and ML2 configurations.
Table 6-3 OpenStack GBP and ACI Resources
GBP Resource |
APIC Resources Consumed |
|---|---|
L3 policy |
One context |
L2 policy |
One bridge domain One endpoint group Two contracts |
Policy group |
One endpoint group |
Ruleset |
One contract |
Classifier |
Two filters (forward and reverse) Note: Five overhead classifiers are created |
Table 6-4 OpenStack ML2 and ACI Resources
ML2 Resource |
APIC Resources Consumed |
|---|---|
Network |
One bridge domain One endpoint group |
Router |
One contract |
Security groups |
N/A (no filters are used) |
Availability Guidelines
For redundancy, you can use bonded interfaces (VPCs) by connecting two interfaces to two leaf switches and creating a VPC in ACI. You should deploy redundant OpenStack controller nodes to avoid a single point of failure. The external network should also be designed to avoid a single point of failure and service interruption.
NAT/External Network Operations
The OpFlex driver software can support external network connectivity and Network Address Translation (NAT) functions in a distributed manner using the local OVS instance on each OpenStack compute node. This distributed approach increases the availability of the overall solution and offloads the central processing of NAT from the Neutron server Layer 3 agent that is used in the reference implementation. You can also provide direct external connectivity without NAT or with a mix of NAT and non-NAT external connectivity.
Subnets Required for NAT
Unlike with the standard Neutron approach, three distinct IP subnets are required to take full advantage of external network functionality with the OpFlex driver:
▪ Link subnet: This subnet represents the actual physical connection to the external next-hop router outside of the fabric to be assigned to a routed interface, subinterface, or SVI.
▪ Source NAT subnet: This subnet is used for Port Address Translation (PAT), allowing multiple virtual machines to share an outside-routable IP address. A single IP address is assigned to each compute host, and Layer 4 port number manipulation is used to maintain unique session traffic.
▪ Floating IP subnet: With OpenStack, the term floating IP is used when a virtual machine instance is allowed to claim a distinct static NAT address to support inbound connections to the virtual machine from outside the cloud. The floating IP subnet is the subnet assigned within OpenStack to the Neutron external network entity.
Optimized DHCP and Metadata Proxy Operations
The OpFlex driver software stack provides optimized traffic flow and distributed processing to provide DHCP and metadata proxy services for virtual machine instances. These services are designed to keep processing and packet traffic local to the compute host as much as possible. The distributed elements communicate with centralized functions to ensure system consistency. You should enable optimized DHCP and metadata services when deploying the OpFlex plug-in for OpenStack.
Physical Interfaces
OpFlex uses the untagged fabric interface for an uplink trunk in VLAN mode. This means the fabric interface cannot be used for PXE because PXE usually requires an untagged interface. If you require PXE in a VLAN mode deployment, you must use a separate interface for PXE. This interface can be connected through ACI or an external switch. This issue is not present in VXLAN mode since tunnels are created using the tagged interface for an infrastructure VLAN.
Layer 4 to Layer 7 Services
Service insertion in OpenStack is done through a physical domain or device package. You should check customer requirements and the plug-in mode (GBP or ML2) to plan how service insertion/chaining will be done. The OpenStack Neutron project also defines Layer 4 to Layer 7 extension APIs, such as LBaaS, FWaaS, and VPNaaS. The availability of these extensions depends on the device vendor. Check the vendor for the availability of these extensions.
Blade Servers
When deploying on blade servers, you must make sure there is no intermediate switch between the fabric and the physical server interfaces. Check the OpenStack ACI plug-in release notes to make sure a particular configuration is supported. At this writing, there is limited support for B-Series blade servers, and the support is limited to VLAN mode only.
Verifying the OpenStack Configuration
Follow these steps to verify the OpenStack configuration:
Step 1. Verify that a VMM domain was created for the OpenStack system ID defined during installation. The nodes connected to the fabric that are running the OpFlex agent should be visible under Hypervisors. The virtual machines running on the hypervisor should be visible when you select that hypervisor. All networks created for this tenant should also be visible under the DVS submenu, and selecting the network should show you all endpoints connected to that network.
Step 2. Look at the health score and faults for the entity to verify correct operation. If the hypervisors are not visible or appear as being disconnected, check the OpFlex connectivity.
Step 3. Verify that there is a tenant created for the OpenStack tenant/project. All the networks created in OpenStack should show up as endpoint groups and corresponding bridge domains. Choose the Operational tab for the endpoint group to see all of the endpoints for that endpoint group.
Step 4. Check the Health Score tab and Faults tab to make sure there are no issues.
Configuration Examples for OpenStack and Cisco ACI
The following sections provide configuration examples for OpenStack and Cisco ACI.
Optimized Metadata and DHCP
In the configuration file, optimized DHCP is enabled by default in the OpFlex OpenStack plug-in. To disable optimized DHCP, add the following line:
enable_optimized_dhcp = False
In the configuration file, the optimized metadata service is disabled by default. To enable the optimized metadata, add the following line:
enable_optimized_metadata = True
External Network/NAT Configuration
You can define external network connectivity by adding an apic_external_network section to the configuration file, as in this example:
[apic_external_network:DC-Out] preexisting=True external_epg=DC-Out-EPG host_pool_cidr=10.10.10.1/24
In this example, host_pool_cidr defines the SNAT subnet. You define the floating IP subnet by creating an external network in Neutron or an external policy in GBP. The name of the external network or policy should use the same name as apic_external_network that is defined in the file (in this case, DC-Out).
It is possible to disable NAT by adding enable_nat = False in the apic_external_network section. You can have multiple external networks using different Layer 3 Outs on ACI, and you can have a mix of NAT and non-NAT external networks.
In GBP deployment, network subnets for policy groups are carved out of the default_ip_pool setting defined in the plug-in configuration file, as in this example:
[group_policy_implicit_policy] default_ip_pool = 192.168.10.0/16
This pool is used to allocate networks for created policy groups. You must make sure that the pool is large enough for the intended number of groups.