The Vision and Reality of ACI Anywhere

After working with early alpha and beta field trials for ACI in 2014, WWT has watched the concept and vision of ACI Anywhere come to fruition over the last five years. A lot of the early buzz around ACI centered on its ability to use overlay protocols (i.e., VXLAN — virtual extensible local area network) to allow any physical or virtual workload to exist anywhere in the network. This meant it was possible to extend data center networking virtually anywhere.

Use cases

What business use cases could this be useful for? Quite a few:

• Single-pane-of-glass control: We could use it to simplify operations and give our network operations teams a single point of visibility and control.
• End-to-end security: We could use it to offer end-to-end security anywhere, from containers to the cloud and everything in between.
• Analytics and automation: We could use it to combine analytics, automation and policy-driven security to build agile networks.
• Multicloud and container ease of use: As customers increasingly adopt multicloud and containers, we could use it to offer a familiar way of creating connectivity between these environments and their on-premise data centers.

While these are some very interesting use cases, they started as just backroom conversations with the Cisco ACI product team regarding what ACI could become.

ACI multi-pod

In the first few versions of ACI, all leaf switches had to connect to all the spines. This meant the ACI fabric had to be co-located in a single data center. Later versions allowed users to segment spines into sets of leaf switches, which allowed for stretched fabrics and transit leaf designs located in multiple data centers. However, these designs were limited by a need for 40GB connections between sites.

When ACI multi-pod came out in early 2016, it was the real leap toward fully extending data center networks because it let users extend Layer 2 data center connectivity to multiple pods. The extension was initially limited to 10 ms before subsequent code releases extended it to 50 ms.

ACI multi-pod used a Layer 3 network called an IPN to connect the spines in multiple ACI fabrics from a routing standpoint. It then creates a VXLAN overlay between these spines to extend Layer 2. Multi-pod also used a new BGP Extension called MP-BGP EVPN to advertise endpoint MAC and host addressing for reachability between the ACI pods. 

While multi-pod had distance limitations and only a single availability zone, it worked well for a large number of our clients looking to extend their data centers and offer a single point of visibility and control from a business use case.

ACI multi-site, multi-site orchestrator, remote leaf and vPOD

Cisco released version 3.0 of ACI in the summer of 2017, which featured multi-site and the multi-site orchestrator (MSO). These enhancements offered users the ability to extend ACI sites anywhere in the world through localized availability zones.

Multi-site featured several key improvements over multi-pod. Notably, multi-site increased the distance limitation to 1000 ms, offered multiple availability zones and did not require multicast in the ISN network connecting the sites. Moreover, the introduction of MSO allowed users to create connectivity between sites as well as configure multiple sites from a single pane of glass.

Shortly thereafter, ACI version 3.1 introduced the concept of the remote leaf. This capability allowed users to extend ACI policy to any ACI capable leaf switch with Layer 3 connectivity and manage it like any other blade in our giant ACI switch. 

Next Cisco also introduced ACI virtual POD (vPOD), which allowed users to can create virtual spines and virtual leaf switches, and then create a VXLAN overlay on top of any network.

At this point, all the pieces were there to extend ACI to any part of the data center — they just were not yet holistically integrated.

ACI Anywhere

Around this time, Cisco announced its plan to extend ACI into the public cloud domain, coining the phrase "ACI Anywhere!" in the process. This meant that key attributes of the ACI solution — such as unified security policy, single-pane-of-glass management and visibility — would soon be available in public cloud environments (e.g., AWS, Google Public Cloud, Microsoft Azure). This would give customers the flexibility to run applications across multiple datacenters, container platforms, virtual environments, generic networks with ACI policy on top (vPOD) and, of course, ACI extensions to the public cloud.

The vision for ACI Anywhere is to enable customers to build agile data center networks for scale, availability, security and operational simplicity anywhere. While the pieces, parts and concepts were all there at the time of this announcement, they were not yet a fully integrated solution. 

Fast forward to early 2019 when WWT performed some early ACI 4.1 EFT testing on AWS integration and the introduction of the ACI Cloud APIC (cAPIC). The cAPIC allows customers to use the MSO to easily connect on-premise ACI sites via VXLAN to public cloud providers. It also offers security and connectivity using native cloud provider constructs. In 4.1.1, remote leaf integration with multi-site was supported; and 4.2 saw support for Azure cloud integration with ACI was introduced.

Moreover, Cisco's introduction of analytics products like Tetration, Network Assurance Engine (NAE) and Network Insight Resources (NIR) offers never before end-to-end visibility — no matter if your workload is on a container, in an on-prem cloud or in a public cloud.

How can you use ACI Anywhere?

At this point, the ACI vision has come full circle — from early backroom conversations to fully supported integrated solutions. Our four business outcomes (1) a single-pane-of-glass control, (2) end-to-end security, (4) analytics and automation and (4) multicloud and container ease of use are now a reality. 

So what are WWT customers doing now that Cisco ACI Anywhere is finally here?

• Upgrading: Many of our organizations with existing Generation 1 spines and leaf switches are looking at migrating to newer spines for multi-site support and -FX leaf switches for micro-flow-based analytics using NIR.
• Analytics: Many organizations are also looking at the new Services Engine and premier licensing to get NAE and NIR to offer better visibility in their data-centers.
• Big data: Financials and other companies that need high-speed big data application and Hadoop clusters are looking at the new 400GB -GX line of switches, which were introduced in the 4.2 code version last month for high-speed, high-bandwidth applications.
• Public cloud: Organizations are using ACI for an easier way to connect multi-site environments to the public cloud. We're also seeing customers in carrier-neutral facilities with low latency public cloud connectivity (such as Equinix) connect multi-site pods directly into the public cloud using cAPIC. This gives customers the previously unavailable ability to extend to, apply consistent policy to and obtain visibility to the public cloud.

The future of ACI

So what does WWT think is next for Cisco ACI?

What's next for ACI, and frankly networking in general, is a concept known as intent-based networking (IBN). IBN can transform a manual network built around hardware into a network built around a controller that captures business intent and turns it into automated policy that can be applied across the network.

For example, consider someone in HR (application consumer) whose business intent is to access certain HR applications (application provider); then consider IT's intent that only HR consumers have access such applications. IBN will use a software-defined networking (SDN) controller to create a policy that's then applied to SDN-capable networking devices to control both the business and IT intent. This is the way ACI Anywhere, SD-WAN and SD-Access networking domains work.

What has changed is that now there are assurance engines for these three domains that compare the business and IT intent with what is actually programmed into the devices to alert and resolve any potential issues in a feedback loop-type mechanism. Also flow-based analytics, previously unavailable, are now possible through new application specific integrated circuits (ASIC) that feed large data lake analytics engines.

Finally, we're seeing policy being exchanged between the ACI Anywhere, SD-WAN and SD-Access domains for an end-to-end policy control.

Conclusion

When WWT looks into the crystal ball of the art of the possible, we foresee a master domain orchestration platform that sits above the three domains of ACI Anywhere, SD-WAN, and SD-Access that can apply a single point of operations and control. Along with this single point of control, there will be hooks into assurance engines in the three domains as well as visibility into analytics engines.

We also see the possibility of a natural language search engine to make sure that the business and IT intent of securely connecting consumers with the providers of applications is applied to all three domains. This will allow users to observe whether traffic is being impaired anywhere between the application consumers and providers by querying the analytics engines. 

Just like the concept of ACI Anywhere being discussed back in 2017, WWT sees the same opportunity for Cisco to integrate all three domains and their respective assurance and analytics engines. The pieces and parts are already there, so it's simply a question of when it will it become a reality, just like with ACI Anywhere.

Want to try ACI?

Our labs are on-demand, include easy to follow step-by-step instructions and there is no charge to use them. Learn more about a few of our ACI offerings: Cisco ACI Basics and Deploying an ACI Multisite Fabric Module 1 of 4.