Demystifying Application Centric Infrastructure (ACI)
Posted by Thomas Magill on Jun 25, 2019 10:00:00 AM
There are a lot of new terms these days around data center networking. Software-defined-this and that-as-a-service are among the leaders. Neither of these are new concepts in technology, but emphasize a new way of looking at how data centers work. Networks have already been “software-defined” and virtualized for an incredibly long time, but now the emphasis is on abstracting the intent from the configuration and treating the entire network as a system. Cisco’s entry into software-defined networking (SDN) is its Application Centric Infrastructure (ACI). ACI has a lot of new concepts and terminology, especially around the abstraction mentioned earlier, but that will not be our current focus.
In this blog, we’re going to focus on what isn’t new about ACI. The comparison can be made to that of a typical chassis-based switch, such as a Catalyst 6500 or a Nexus 7000 (7K), which will be used here. The major components of a Nexus 7000 are the supervisors, line cards, fabric modules, and backplane. There are only three types of components in ACI, the Application Policy Infrastructure Controller (APIC), the spine switches, and the leaf switches.
Line Card vs. Leaf Switch
The endpoint-facing ports in the 7K all live on the line cards. Line cards are inserted in the chassis and that is how they communicate with the other components. In ACI, this function is provided by a standalone switch called a leaf. The leaves have either 40G or 100G uplinks that connect them to the spines.
Fabric Module vs. Spine Switch
In the 7K, the line cards are all connected to fabric modules via the backplane. The fabric modules are simply high-speed devices that forward packets to their destination. The ACI equivalent is called a spine. Spines do very few things, so they can do them fast. In a traditional ACI deployment, every leaf switch connects to every spine switch, spine switches only connect to leaf switches, and leaf switches do not connect to other leaf switches. As ACI has evolved, it has branched past the topology described as traditional, but that is beyond the scope of this writing.
Backplane vs. IP
In any chassis switch, the backplane is fixed circuitry that provides interconnectivity between the components. In ACI, this is much less fixed. Every leaf has one or more uplinks that act as IP-based point-to-point links. This is referred to as the underlay network and is a Clos spine-leaf design controlled by the intermediate system to intermediate system (IS-IS) routing protocol. IS-IS allows every leaf to have reachability to every other leaf, via the spines. Multi-protocol border gateway protocol (MP-BGP) provides the overlay control, which allows for network virtualization and multi-tenancy. If all of those letters sound scary, they aren’t because ACI automatically configures the protocols.
Supervisor vs. APIC
The supervisors in a 7K provide switch and port control, along with the administration front-end for the switch. In ACI, the APICs fill the same roles, though there are a few differences in the way these roles are handled. For administration, the 7K relies on a command-line interface (CLI) to modify a running configuration that lives on the supervisor and controls behavior. The APICs are built a little differently in that they host an object-modeled management database, which is exposed only through an application programming interface (API). Through this API, any number of interfaces can be created, but out of the box, the APICs have a CLI and a graphical user interface (GUI). As a note, the 7K does have an API, but it is not native. It is strictly a mechanism to communicate with the running-configuration, just like the CLI.
One major difference to call out between the supervisor and APIC is that while neither are technically in the data path, the supervisor is required for the data plane to function. In ACI, if you remove all three APICs, there is no impact to the data plane; traffic will continue to flow, though no configuration changes can be made. Do not remove all of the supervisors in a 7K to see if that happens.
Why Make the Switch to SDN?
To keep it short, SDN provides powerful and programmable centralized management in a distributed system that behaves as one switch. The same centralized management that drives chassis-based switches can now accommodate end-of-row, top-of-rack, multiple data center, and even public cloud requirements with automation-friendly API-based controls. As management tools evolve—in some cases using machine learning or other artificial intelligence processes—they can learn to interact with these systems to provide resources faster and more securely than any human process so engineers can focus on building new systems instead of “caring and feeding” old ones.
[WEBINAR]
THE ABCs OF APPLICATION BUILDING + CUSTOMIZATION
THURSDAY, JULY 11, 2019 | 1:00 P.M. ET (10:00 A.M. PT)
In this webinar, we'll explore the Cisco ACI App Center, where custom Application Policy Infrastructure Controller (APIC) applications can be downloaded for installation. We will then present a custom application that ConvergeOne developed and is making available for free in the Cisco ACI App Center. This is the webinar for you if you are interested in realizing the full potential of software-defined networking for your data center with the use of custom applications!
Topics: Data Center