Understanding ACI and the APIC [Part 1]

ACI is for the data center. it’s a fabric that will span data centers using OTV or similar, overlay technologies, but it’s not for the WAN. we will implement an identical level of programmability on our WAN links through APIC-EM (Application Policy Infrastructure Controllers Enterprise Module),
which uses ISR or ASR series routers, alongside the APIC-EM virtual machine to regulate and program them. APIC and APIC-EM are very similar, just the thing of their focus is different. APIC-EM is outside of the scope of this book, as we’ll be watching data center technologies.

The APIC is our frontend. Through this, we will create and manage our policies, manage the fabric, create tenants, and troubleshoot. most significantly, the APIC isn’t related to the info path. If we lose the APIC for any reason, the fabric will still forward the traffic.

To give you the technical elevator pitch, ACI uses a variety of APIs (Application Programming Interfaces) like REST (Representational State Transfer) using languages like JSON (JavaScript Object Notation) and XML (eXtensible Markup Language), also because the CLI and therefore the GUI, to manage the material and other protocols such OpFlex to provide the policies to the network devices. the primary set (those that manage the fabric) is mentioned as “northbound” protocols.

Northbound protocols allow lower-level network components to ask higher-level ones. OpFlex may be a “southbound” protocol. Southbound protocols (such as OpFlex and OpenFlow, which is another protocol you’ll hear in reference to SDN) allow the controllers to push policies right down to the nodes (the switches).