Cisco ACI Overview

Cisco ACI is a spine/leaf network of Nexus 9k switches using the ACI operating system with a management platform. The network management platform called APIC provides a single place from which the network can be managed.

Cisco ACI solutions have the following building blocks:

• Cisco Application Policy Infrastructure Controller (APIC): The infrastructure controller is the main architectural component of the Cisco ACI solution. It is the unified point of automation and management for the Cisco ACI fabric, policy enforcement, and health monitoring. The APIC is not involved in data plane forwarding.
• Cisco Nexus 9000 Series leaf switches: Represent connection points for end devices, including APIC, and are connected to spine switches.
• Cisco Nexus 9000 Series spine switches: Represent the backbone of the ACI fabric and are connected to leaf switches.

Cisco ACI resolves the following challenges of traditional networks:

• Complicated topology: Usually, traditional networks use core distribution access layers. When you add more devices, this topology can be complicated to manage. Cisco ACI uses a simple spine-leaf topology wherein all the connections within the Cisco ACI fabric are from leaf-to-spine switches, and a mesh topology is between them. There is no leaf-to-leaf and no spine-to-spine connectivity.

Figure 8-1 shows a traditional network versus a Cisco ACI spine/leaf architecture.

   

Figure 8-1 Traditional Network vs. Cisco ACI Spine/Leaf Architecture

• Layer 2 loops: Traditional networks rely on the Spanning Tree Protocol (STP) for loop-free topology. Cisco ACI use equal-cost multipath (ECMP), and since there is IP reachability between leaf and spine switches, there is no need for STP, and you do not have to block any port to avoid the Layer 2 loops.

Figure 8-2 shows a traditional network versus Cisco ACI loop avoidance.

   

Figure 8-2 Traditional Network vs. Cisco ACI Loop Avoidance

• Security: From the security perspective, in a traditional network device, all the traffic is allowed by default, and you need to explicitly configure the device to block the traffic. However, in Cisco ACI, an allow-list model is used. By default, everything is blocked, unless you explicitly allow the traffic.

Figure 8-3 shows a traditional network versus the Cisco ACI security model.

   

Figure 8-3 Traditional Network vs. Cisco ACI Security Model

• Device management: In a traditional network, hardware devices are configured using CLI by doing SSH to every device. A lot of copying/pasting is required during the configuration, and it’s harder to scale as the number of devices increases. In a leaf-and-spine topology, there can be tens or hundreds of devices. Instead of using SSH for each and every device to configure and build the Cisco ACI fabric, you can use the centralized controller, called APIC. You can still directly access the leaf-and-spine switches, but you cannot configure anything directly on them. You always configure the Cisco ACI fabric from the Cisco APIC. Cisco APIC enables access to all devices in the fabric via Cisco API. In Cisco ACI, all configurations can be represented by policies and objects. These policies and objects can be stored in XML or JavaScript Object Notation (JSON) format. Policies and objects can be easily accessed via APIs or configured via APIs.

Figure 8-4 shows a traditional network versus Cisco ACI device management.

• Automation: In a traditional network, usually there is no automation, and configuration is done manually and statically. In Cisco ACI, by using REST API calls, it is easy to automate configuration. It is also possible to provide dynamic integrations, where you can dynamically communicate and push the configuration to another vendor’s controller (VMware vCenter server, for example).

    

Figure 8-4 Traditional Network vs. Cisco ACI Device Management

Figure 8-5 shows a traditional network versus Cisco ACI automation.

   

Figure 8-5 Traditional Network vs. Cisco ACI Automation

• Coordination between the network and server team: Typically, the network and server teams are two different teams. They need to cooperate to make sure that, for example, the new service has correct security rules, the correct VLAN, and that the correct VLAN is deployed in the correct place. Sometimes, that communication is not an easy task. By using the dynamic integration, for example, VMware integration, you can dynamically push the configuration to the vCenter Server. Then you can verify that the network (ACI) side has the configuration deployed and also that the server side has the mapped configuration.

Figure 8-6 shows a traditional network versus Cisco ACI coordination between network and server teams.

   

Figure 8-6 Traditional Network vs. Cisco ACI Coordination Between the Network and Server Teams

The main benefits of Cisco ACI include the following:

• Operational simplicity, with common policy, management, and operation models across application, network, and security resources.
• Centralized network management and visibility with full automation and real-time network health monitoring.
• Automation of IT workflows and application deployment agility.
• A cloud-ready SDN solution—through any hypervisor, for any workload, at any location, using any cloud. Cloud automation enabled by integration with VMware vRealize, Microsoft Azure Pack, OpenStack, Red Hat OpenShift, Kubernetes, and Cisco UCS Director.
• Common platform for managing physical and virtual environments.
• Inherent security with a zero-trust allow list model and innovative features in policy enforcement, microsegmentation, and analytics.
• Open APIs and a programmable SDN fabric, with 65+ ecosystem partners.