Cisco ACI Management and Automation

There are a number of fundamental differences between the operations of traditional networking hardware and a Cisco 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 the following:

• Single point of management controller-based architecture
• Stateless hardware
• Desired state-driven eventual consistency model

In the ACI architecture, Cisco APIC provides the single point of management and access to all configuration, management, monitoring, and health functions. Cisco APIC can be configured using a graphical user interface (GUI), command-line interface (CLI), and API. 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 results in a clean and predictable transition between the interfaces with no risk of inconsistency between the various data interfaces.

Figure 9-9 illustrates various ACI fabric management access methods.

Figure 9-9 ACI Fabric Management Access Methods

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, not from the serial number of the chassis or 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 the 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, as dictated by the managing controller.