Before diving into the Cisco ACI APIs, we need a brief introduction to the hierarchical structure of its elements.

This article may look intimidating due to its complexity. In reality, it should be used as a reference whenever we need to better understand a detail in order to optimize our automation. Don’t be discouraged, automating a Cisco ACI fabric is actually a very straightforward process.

Promise Theory

Cisco ACI is object-oriented and based on Promise Theory : each object declares the promises it keeps, i.e., it specifies what can be done. Policies establish the relationships between the objects that provide promises and those that consume them:

Let’s take an example related to traffic management between EPGs:

• EPG (Endpoint Group): a group of endpoints promises to provide/accept traffic under specific conditions.
• Contracts: define the interaction rules between EPGs.
• Policy model: declares that two EPGs can communicate according to the rules defined in a given contract.
• At this point, the desired state composed of EPGs, Contracts, and Policy model is pushed down, and objects implement the changes, returning faults when required.

Object Model

Cisco ACI uses a hierarchical model , in which objects located in different branches can still directly interact.

The object model represents the tree of objects and their properties implementing the Cisco ACI fabric. Each Managed Object (MO) has a class and a unique Distinguished Name (DN), formed by its parent name and relative name. The Management Information Model (MIM) describes the structure of the model, the relationships, and the objects. In other words, the object model contains the fabric configuration, implemented according to MIM rules.

The object model is managed by an APIC (Application Policy Infrastructure Controller) cluster. Each switch receives the policies from the APIC and enforces them locally.

Continue reading the post on Patreon .