Application Centric Infrastructure (ACI) is a complete architecture with centralized automation and policy-driven application profiles. ACI provides software flexibility with the scalability of hardware performance that provides a robust transport network for today’s dynamic workloads. ACI is built on a network fabric that combines time-tested protocols with innovations to create a highly flexible, scalable, and resilient architecture of low-latency, high-bandwidth links
Key characteristics of ACI include:
- Simplified automation by an application-driven policy model
- Application Velocity. Any Workload. Anywhere.
- Centralized visibility with real-time, application health monitoring
- Open software flexibility for DevOps teams and ecosystem partner integration
- Investment protection by integrating with the existing fabric infrastructure e.g. Nexus 7000
- Scalable performance and multi-tenancy in hardware
ACI Architecture Elements
Cisco ACI architecture is a combination of high performance Hardware and software innovation and intelligence integrated with two important concepts from SDN solutions; overlays and centralized control. However the ACI utilize different approach and offer capabilities that goes beyond the typical SDN offering or what is known as Openflow based-SDN
Cisco ACI Solution architecture consists of:
- A centralized policy management and Cisco Application Policy Infrastructure Controller (APIC)
- The new Cisco ACI high performance Fabric Hardware
- A Cisco Application Virtual Switch (AVS) for the virtual network edge
- Software and hardware innovations
- Integrated physical and virtual infrastructure
- An open ecosystem of network, storage, management, and orchestration vendors
Cisco Application Policy Infrastructure Controller (APIC)
The Cisco ACI fabric is designed as an application-centric intelligent network. The Cisco APIC policy model is defined from the top down as a policy enforcement engine focused on the application itself and abstracting the networking functionality underneath.
APIC approach within ACI architecture
The Cisco APIC policy use an object-oriented approach based on promise theory. Promise theory is based on declarative, scalable control of intelligent objects, in comparison to legacy imperative models, which can be thought of as heavyweight, top-down management.
With this declarative model, using a centralized policy controller, you can define the policy centrally and push it out and the endpoint should have the intelligence to abide by that policy. Therefore, these network nodes are not treat as dumb devices, because the intelligence solely resides in the controller, instead the controller will tell the network node(s) what it needs to provision, change, delete etc., but not how to be done.
The APIC centrally push policies to the underlying infrastructure using an extensible policy protocol designed to exchange abstract policy between a network controller and a set of smart devices capable of rendering policy called OpFlex. Cisco is proposing OpFlex as an informational RFC to the IETF and plans to lead the standardization process through that forum. At the same time, Cisco is working with the open source community to provide an open source implementation.
ACI Farbic
- ACI Fabric is based on an IP fabric supporting routing to the edge with an integrated overlay for host routing
- All end-host (tenant) traffic within the fabric is carried through the overlay
- Decoupling of endpoint identity, location, and associated policy, all of which are independent from the underlying topology
- Full normalization of the ingress encapsulation mechanism used: 802.1Q VLAN, IETF VXLAN, IETF NVGRE
- Fabric provides a pervasive SVI, which allows for a distributed default gateway
ACI Fabric Hardware Innovation
Cisco is innovating across its Nexus switch portfolio to expand deployment options and help ensure investment protection as networks evolve from traditional deployments to cloud deployments
Portfolio additions include:
- Two new ACI-ready Nexus 9000 series switches: the Nexus 9336PQ fixed switch and the Nexus 9396TX, an enterprise-class Top of Rack switch.
- The Nexus 9336PQ offers advanced scalability in the industry’s smallest spine form-factor, designed for small to medium ACI spine deployments.
- The Nexus 9396TX offers 100M/1G/10G copper-based front panel port connectivity for top-of-rack deployments in both traditional 3-tier network designs and Cisco ACI enabled deployments.
- The N9K-X9736PQ non-blocking line-card enables the Application Centric Modular Spine for the Cisco Nexus 9500 platform. The ACI line-card with 36 non-blocking 40GbE QSFP+ ports will help organizations to create large-scale spine-leaf deployments.
- The Nexus 7000 Series Switches add support for several open source tools and standards enabling programmability and automation/SDN capabilities for virtualized and cloud deployments.
- The Nexus 6004X Switch offers a new chassis that delivers added VXLAN capabilities with the same eight slot form factor and feature set as the current Nexus 6004
Multi-Hypervisor-Ready Fabric
- Integrated gateway for VLAN, VxLAN, and NVGRE networks from virtual to physical
- Normalization for NVGRE, VXLAN, and VLAN networks
- Customer not restricted by a choice of hypervisor
- Fabric is ready for multi-hypervisor
- Automatic virtual endpoint detection and policy placement
- Network policy tracking based on VM mobility
Investment protection with ACI
The Cisco Application Policy Model can be extended to both physical and virtual workloads in existing Nexus infrastructure through the Cisco Application-centric Virtual Switch (AVS), an APIC-enabled Nexus 1000V virtual switch, or by deploying Nexus 9000 switches as a remote leaf within customers’ existing data centers. The Nexus 7000 Series switches and ASR 9000 Router will also be integrated into the ACI fabric.
Some important (recommended) features to enable
Port Tracking : When the number of operational fabric ports on a given leaf node are decreased to the configured threshold or lower, the downlink ports of the leaf node will be brought down so that the external devices can switch over to other healthy leaf nodes.
Enforce Subnet Check: This feature helps to prevent learning of IP addresses that may not belong to the fabric.
IP aging : The IP aging policy tracks and ages unused IPs on an endpoint. Tracking is performed using the endpoint retention policy configured for the BD to send ARP requests (for IPv4) and neighbor solicitations (for IPv6) at 75% of the local endpoint aging interval. When no response is received from an IP, that IP is aged out.
Rogue EP Control : Rogue EP Control detects endpoints that move frequently and disables endpoint learning for the endpoints only.
Enable Strict COOP Policy : COOP data path communication provides high priority to transport using secured connections. COOP is enhanced to leverage the MD5 option to protect COOP messages from malicious traffic injection. COOP is used to communicate the mapping information (location and identity) to the spine proxy.
Enable BFD on Internal Fabric Interfaces : Use Bidirectional Forwarding Detection (BFD) to provide sub-second failure detection times in the forwarding path between ACI fabric border leaf switches configured to support peering router connections.
Enable DOT1P Preservation : APIC enables translating the 802.1P CoS field (Class of Service) based on the ingress DSCP value. 802.1P CoS translation is supported only if DSCP is present in the IP packet and dot1P is present in the Ethernet frames.
Reduce IS-IS metric : It is recommend to change or reduce the IS-IS metric for redistributed routes to lower than the default value of 63. This is to ensure that when a spine switch is rebooting because of an upgrade, the switch is not in the path to external destinations until the entire configuration of the spine switch is completed, at which point the metric is set to the lower metric, such as 32.
Mis-Cabling Protocol (MCP) : Mis-Cabling Protocol (MCP) detects loops from external sources and will err-disable the interface on which ACI receives its own packet. Enabling this feature is a best practice, and it should be enabled globally and on all interfaces, regardless of the end device.