There are a number of fundamental differences between the operations of traditional networking hardware and an Cisco Application Centric Infrastructure (ACI) fabric. These differences serve to simplify the management greatly, reduce the number of touch points, and decouple the switching hardware from the desired configuration intent. These changes include:
Single point of management controller-based architecture
Desired state-driven eventual consistency model
The single point of management within the ACI architecture is known as the Application Policy Infrastructure Controller (APIC). This controller provides access to all configuration, management, monitoring, and health functions. Having a centralized controller with an application programming interface (API) means that all functions configured or accessed through the fabric can be uniformly approached through a graphical user interface (GUI), command line interface (CLI), and API, with no risk of inconsistency between the various data interfaces. This results in a clean and predictable transition between the interfaces. The underlying interface for all access methods is provided through a REST-based API, which modifies the contents of a synchronized database that is replicated across APICs in a cluster and provides an abstraction layer between all of the interfaces.
This controller-based architecture also makes possible a stateless configuration model that decouples the hardware from the configuration running on it. This translates to an APIC cluster that manages individual fabric nodes of leaf and spine switches that derive their identity from what the controller defines as being the desired intent, and not from the serial number of the chassis, nor from a configuration file residing on the devices. Each node receives a unique node identifier, which allows for the device to download the correct configuration attributes from the controller. The device can also be substituted in a stateless fashion, meaning that hardware swaps can be faster, topology changes are less impactful, and network management is simplified.
The desired state model for configuration further complements these concepts of controller-based management and statelessness by taking advantage of a concept known as declarative control-based management, based on a concept known as the promise theory. Declarative control dictates that each object is asked to achieve a desired state and makes a "promise" to reach this state without being told precisely how to do so. This stands in contrast with the traditional model of imperative control, where each managed element must be told precisely what to do, be told how to do it, and take into account the specific situational aspects that will impact its ability to get from its current state to the configured state. A system based on declarative control is able to scale much more efficiently than an imperative-based system, since each entity within the domain is responsible for knowing its current state and the steps required to get to the desired state, dictated by the managing controller.
For information about new APIC features, see the Cisco Application Policy Infrastructure Controller Release Notes for your release of the software: