CNS Tech Blog

Extending your Cisco ACI Fabric to Microsoft Azure

—

par

Benoit GONCALVES
dans , , ,

If you are managing a private ACI Fabric and your company is beginning to send some workloads to Microsoft Azure, it can make sense to extend the current Tenants/VRFs between your data centers and the public clouds while keeping the same logical architecture for your applications. Let’s explore the key components, requirements and prerequisites for an extension to the Cloud.

Why extending ACI to the Cloud ?

You may want to have a consistent segmentation policy within a site and between sites, whether physical or cloud. It is adapted to application failover scenarios in the event of an outage (Active/Active redundancy between sites or Disaster Recovery Plan). I’m also thinking about the possibility to use your compute on-premise (always on), and benefiting from the compute elasticity of the cloud providers (add/delete compute whenever you need it) while maintaining the same network/security policies of your applications.

A bit of history

Beginning since the version 4.1 of the Cisco APIC (Application Policy Infrastructure Controller), Cisco ACI was able to use the Cloud APIC to extend a Multi-Site fabric to Amazon AWS, and the version 4.2 allowed the extension to Microsoft Azure.

What do you need ?

I suppose you already have a « classic » Cisco ACI fabric with two pods in a Multi-Pod architecture, you already have a few Spines and Leafs, an APIC cluster and an IPN (Inter-Pod Network). They are the key components for a private ACI Fabric.

Now in order to extend your ACI Fabric to Microsoft Azure, you will have to add the following components, in Green, on the picture below:

Licensing

Before talking about real components, lets talk about licensing 🙂 If your leafs are not already using an Advantage license, you will have to invest in an upgrade license from Essential to Advantage, for each leaf of your ACI fabric. Your current Spine and Leafs should not be too old (Spine 9332C in 14.1 or later, and leafs 9K EX/FX in 14.1 or later). The APIC will have to run a version 4.2 or later and the MSO will have to be in release 2.2 or later.

Multi-Site Orchestrator (MSO)

You will need another « controller », the Multi-site Orchestrator (MSO) which is mainly deployed as a cluster of three virtual machines. The Multi-Site Orchestrator will manage the existing policies from your APIC Cluster and extend them to the Cisco Cloud APIC on the other side. The good news is that since a few weeks, Cisco changed the licensing model for MSO who is now included in the Advantage License of your Leafs.

Inter-Pod Network (switches) and IPsec devices

The two other key components that you should already have are the IPN switches, as well as a cluster of IPsec capable devices of any kind/vendor, allowing you to build an IPsec tunnel between your private environment and the public cloud. Even if the internet is represented in a simple way in the previous diagram, it’s recommended to establish « Direct Connect » peerings if you can, or at least size your links accordingly for the migration/use of the private/public workloads, in addition to your current internet usages.

Azure, CSR100V and Cloud APIC

On the other side, into the cloud, you will need an Azure account with a subscription and at least a tenant. 2x Cisco CSR 1000V deployed as VMs (with the right Azure VM size depending on the CSR throughput needed) to terminate the IPsec tunnels of your private environment, and a number of Cisco Cloud APIC (cAPIC) licenses (based on the number of VMs planned to be deployed on the cloud environment).

The CSR 1000V licensing is based on the bandwidth needed (500Mb, 1Gb…), and the Cusci Cloud APIC licenses are based on your cloud environment, you will need a cAPIC Advantage on multi-tenant architectures, and cAPIC Essential on mono-tenant architectures. For example, if you are planning to deploy 100 VMs on 1 Azure tenant, you will need 100 cAPIC Essential licenses, and if you are planning to deploy 100 VMs accross 3 Azure tenants, you will need 100 cAPIC Advantage licenses.

OK, I have everything ready, what are the required steps to extend ACI to Azure ?

When you have your Cisco ACI Fabric with the right level of licenses, deployed an MSO cluster and linked it to your APIC Cluster, you are ready to go to Azure and deploy a Cisco Cloud APIC, initialize it and add the Azure environment to MSO.

The next step is to configure the infrastructure for ACI and cAPIC, build connectivity from on-premises to Azure. Then create a Tenant/Schema from MSO (or reuse your existing tenants), configure some site-local properties and deploy your workloads !

The detailed steps will be detailed in another blog post.

Most of the configuration is automatic, MSO and the cAPIC are managing most of the configuration aspects. As soon as the required parameters are set, MSO generates the IPsec configuration to copy/paste to the CSR1000v and all the Azure configuration is automated through the cAPIC abstraction.

Policy Terminology between ACI and Azure

Cisco Cloud APIC is translating the ACI policy to the native constructs of the public cloud.The table below list the equivalences between Cisco ACI policy objects and Microsoft Azure objects

Cisco ACI
Azure
Tenant (Region, VRF)
Resource group
Virtual Routing and Forwarding (VRF)
Virtual network
BD subnet
Subnet
Contract, filter
Outbound rule, inbound rule
EP-to-EPG mapping
Application Security Group (ASG), 
Network Security Group (NSG)
Endpoint
Network adapter on VM instances

Sources & Useful Ressources to go further