Your Resource for All Things Apps, Ops, and Infrastructure

Taking Network Virtualization One Step Further with Cisco ACI

As a follow-up to Ryan Alt’s post introducing AHEAD’s Strategy and Roadmap service that helps customers evaluate use cases for software-defined networking (SDN), last week, Tim Carr, Senior Solutions Architect at AHEAD, shared a post that introduced VMware’s NSX virtualized network platform.

In this post, Scott Honey, Senior Technical Architect and one of AHEAD’s CCIEs, takes this one step further and builds a picture of what Cisco Application Centric Infrastructure (ACI) provides as an SDN solution. He discusses the ACI fabric architecture, deployment models, use cases, and finally the programmability of ACI with orchestration and automation tools.

But First… A Brief Overview of ACI

In April 2012, Cisco funded a startup under the radar in order to come up with an answer to the Software-Defined Networking (SDN) wave sweeping the networking industry. In typical “spin-in” fashion, this startup, Insieme Networks, was acquired by Cisco Systems in December 2013, after officially launching in November 2013. Within the approximate 18-month span from initial funding put up by Cisco, Insieme Networks came up with ACI as a solution to the rise of SDN.

ACI Architecture 

Cisco’s ACI architecture relies on two main components: the Application Policy Infrastructure Controller (APIC) and the new Nexus 9000 Series Switches. The Cisco Nexus 9000 Series Switches are purpose-built 40GE and 100GE hardware switches designed around the Cisco ACI software model and understand how to build the ACI network based on instructions sent from the ACI APICs. The APIC builds a policy object model based on promise theory. The APIC controller requests objects within the model to construct and behave in a specific manner without needing to know exactly how each physical component in the fabric needs to be configured; APIC does not issue command-line interface (CLI) commands on the switches. The actual configuration of each object is left to the physical infrastructure component owning that object within the model. This greatly reduces the administrative burden on the APIC when compared to designs built on the imperative control model.

Spine-and-Leaf Fabric

Cisco’s ACI architecture utilizes a spine-and-leaf fabric network where all leaf nodes (nodes that connect to servers) attach to all spine nodes (nodes that connect to other switches in the fabric), typically in an equal-cost multi-path (ECMP) fashion. Leaves are not directly connected to other leaves and spines are not directly connected to other spines. All links between leaves and spines are either 40G or 100G interfaces and provide a fabric where any communication from one leaf to another is one spine hop away. This architecture does extremely well for all network flows whether it’s north-south or east-west traffic.


Cisco Application Virtual Switch (AVS)

The Cisco Application Virtual Switch (AVS) is a derivative of the Cisco Nexus 1000v Switch but incorporates ACI software and is controlled by the APIC. When the ACI fabric includes AVS in the architecture, ACI can control the VM network interface cards directly as if they’re part of the physical fabric. This allows ACI to provide micro-segmentation from a physical hardware standpoint all the way down to the VM and is a major differentiator in competing SDN products. Cisco AVS also supports VMware vSphere and Microsoft Hyper-V allowing ACI to be agnostic when it comes to the hypervisor.

Application-Centric Model

The normal deployment model for ACI is around application policy. A fundamental difference between traditional networks and ACI is that if no policy is defined within ACI, no traffic will flow anywhere. Every application within the data center needs to be defined within an Application Network Profile (ANP). An ANP will consist of Endpoint Groups (EPGs) and contracts that are consumed or provided by the EPGs within the ANP. EPGs typically contain objects representing VMs, IP addresses, or physical access ports off of the fabric. Contracts typically define ACLs that permit traffic from one EPG to another or they can provide more advanced services like load balancing. This deployment model typically requires extensive network discovery to happen during the planning stage in order to map all applications running within a modern data center.

Network-Centric Model

In the network-centric deployment model, migrating an existing data center into ACI requires less application discovery, but requires a complete Layer 2 and Layer 3 map in order to properly define the fabric and access policy. Layer 2 connectivity is required between the existing network infrastructure and the ACI fabric in order to allow a controlled migration of servers and appliances onto ACI fabric access ports. In this deployment model, EPGs and bridge domains map to individual VLANs and the contracts are configured to permit all traffic between EPGs. This whole process is significantly less work than the application-centric model. It also doesn’t prohibit a company from starting in the network-centric model and adding application-centric ANPs on top of it.

ACI Use Cases

Multi-Tenant Infrastructure

Cisco’s ACI incorporates multi-tenancy at its core. This allows logical isolation between tenants running on the common physical fabric. This tenant isolation can provide for a few powerful use cases. The most common use case would be DMZ/internal isolation, as well as -production/development isolation. For service providers, this multi-tenancy can create a highly scalable tenancy infrastructure with flexibility on how to sub-divide a tenant further. As CISOs become more accepting to cloud-based architecture, extensive cost savings can be realized by providing a common fabric with security services layered. Traditional core/aggregation/access architectures with air gapped isolation between security zones is slowly being phased out because of the enormous cost involved and because multi-tenant architectures have begun to prove themselves as efficient.

One Controller for [Mostly] Everything

Cisco ACI has a growing ecosystem of companies collaborating to provide a common controller and get closer to what SDN is supposed to be. Firewalls like Cisco ASA, Check Point, or Fortinet can be managed in fabric, as well as load balancers by F5 Networks, Citrix, or A10 Networks, which can also be managed in fabric. For anything that doesn’t have a device package for managing in fabric, it’s still possible to have the ACI fabric steer traffic into those ACI unmanaged appliances. The ecosystem keeps growing, and as ACI adoption keeps picking up steam, manufacturers will experience more pressure to support SDN.


With Cisco ACI, it’s possible to provide complete micro-segmentation. Whether that’s physical to physical, physical to virtual, or virtual to virtual, ACI can protect it all within the same broadcast domain. Today’s threat vectors against servers are driving the heavy demand for micro-segmentation since once a single server is compromised, every other server on the same broadcast domain can become a potential target. If the attack goes unnoticed, the potential data loss can be massive. Micro-segmentation can shrink the attack vector to a more manageable size while working in conjunction with anti-virus, malware, and intrusion prevention technologies.

Using Orchestration and Automation to Get the Most out of ACI

With any SDN solution to truly be software-defined, orchestration and automation software needs to be programming the network policy. If your network engineers switch from configuring the network from the CLI to configuring the network from the ACI APICs, you’re not really realizing the primary benefits of what ACI really is: software-defined networks. That’s not to say that ACI doesn’t provide some massive benefits over the traditional way to manage data centers. The point is, when incorporating orchestration and automation tools into ACI, the turnaround time for new application deployments starts to become on par with public cloud providers like Amazon Web Services and Microsoft Azure. If you’re not trying to compete with the cloud providers’ time to delivery, you may not have much of a data center in a few years.

Cisco UCS Director

Cisco UCS Director can integrate ACI functions directly into any workflow and can provide consistent network policy whether the workflow is for a physical server or a VM. When you couple the potential for the recent CliQr acquisition, the power ACI can provide becomes even greater.

VMware vRealize Suite

Cisco ACI provides an APIC plug-in for use with VMware vRealize Orchestrator. Any good SDN solution will provide a REST API in order to allow any orchestration and automation layer to run on top. If you’re running the vRealize Suite today, ACI will bolt right in as part of the existing cloud strategy.

SDN: The Future of the Data Center 

I’m having less and less conversations about traditional network architectures and more about SDN-based architectures. There are alternatives spine-and-leaf architectures based off of Cisco FabricPath or VXLAN. Cisco FabricPath is a solid network architecture and greatly reduces the spanning tree influence in the data center. VXLAN-based architectures can be highly complex and incredibly scalable. Cisco Nexus Fabric Manager (NFM) can help manage your VXLAN-based networks by bringing that highly complex environment down to a more manageable level. However, FabricPath and VXLAN (with NFM) don’t provide the operational savings that ACI provides long term. Those legacy architectures can’t come close to the self-provisioning infrastructure that ACI creates, let alone the programmability of SDN. After seeing what the ACI brings to the table, I welcome the change.

For more information about software-defined networking or Cisco ACI, contact AHEAD today to schedule a meeting with our experts in the AHEAD Lab and Briefing Center. Don’t forget to ask us about AHEAD’s Strategy and Roadmap Service for software-defined networking where AHEAD’s subject matter experts help to define both use case and deployment methodologies for various SDN technologies.

AHEAD Lab and Briefing Center

Watch On-Demand Sessions from our Spring Summit, Automation @Scale!

Subscribe to the AHEAD i/o Newsletter