As a team, we felt it necessary to start providing some ACI cheat sheets for our students and clients. We find that learning Application Centric Infrastructure (ACI) over a week is a wealth of information all at once and can be very daunting at times, so we feel it is critical to provide concepts that can be reviewed and help the visual mind. One of our teammates, Brett Teel, has created a series of documents to help with Cisco ACI Basics, concrete and logical models.
Understanding ACI Basics
First in the series is ACI Basics which gives an overall glimpse of ACI compared to a legacy networking architecture. Unlike the three-tiered traditional model of Core/Distro/Access, ACI consists of a spine/leaf architecture. Spines reside in the infrastructure space while leaf switches reside in the userspace. All spines and leaf switches connect via full mesh providing low latency ECMP (40-100GB Uplinks), predictability (one/two hops away), and allowing horizontal scale; more uplinks add a spine, additional user ports add a leaf switch. ACI also removes the need for spanning-tree with all connections being layer three using VXLAN across the fabric.
The fabric is controlled by a single point of truth called the APIC controllers (cluster). APICs do not reside in the control or data path and contains the management configuration and policy repository for the fabric itself. This allows us zero-provisioning when adding a new switch to the fabric, one source of truth to manage all. APICs have a minimum requirement of three servers in every fabric which provides N+2 redundancy. Lumos recommends all APIC servers are connected to different leaf pairs if available.
Making Sense of CISCO ACI Basics Concepts
One of the key concepts here is ACI operates as an object-based model which is totally different from what we know with NXOS. The switches running in ACI mode are only programmable via an object-based Policy Engine operating in the APIC controller. The controller now becomes an integrated part of the network and holds the profiles containing the policies for programming the switches centrally. The switches themselves do not hold a CLI configuration file as previously used in NXOS based systems. The configuration is held on the APIC and is an object-oriented schema written in XML/JSON and stored in a profile to implement the policies. The policy itself consists of application-centric information for connectivity, L1-3 IDs, L4-7 services.
Stay Tuned for More
In future posts, we will discuss in more depth the concrete and logical models and how they pertain to legacy architecture. At Lumos, we want you to have a concrete grasp of the ACI Basic concepts so you can better streamline and simplify your IT solutions. Keep an eye out for our future posts and don’t hesitate to reach out if you have questions.
The file can be downloaded here: https://lumoscloud.com/documents/aci-basics/
