As software defined networking becomes more popular and even necessary, Cisco ACI changes the way we’ve traditionally thought about networking. Traditional networking uses an imperative model which basically means we control what the network devices do. We give them commands and expect them to follow them as “written.” ACI uses a declarative control system where we specify what we want the end result to be and the network devices interpret it and do what they need to return that result.
Application Centric Infrastructure (ACI) in the data center is a holistic architecture with centralized automation and policy-driven application profiles. ACI delivers software flexibility with the scalability of hardware performance.
Cisco ACI consists of:
- The new Cisco Nexus 9000 Series Switches
- A centralized policy management and Cisco Application Policy Infrastructure Controller (APIC)
- 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
Key characteristics of ACI include:
- Simplified automation by an application-driven policy model
- Centralized visibility with real-time, application health monitoring
- Open software flexibility for DevOps teams and ecosystem partner integration
- Scalable performance and multi-tenancy in hardware
Spine and Leaf Structure
ACI is built on a Clos network. There are spine nodes and leaf nodes as shown in the figure below. Every leaf is connected to the spines in a mesh fashion. This design addresses that increase in East-West traffic in most modern data centers due to the increase in virtual servers on top of physical hosts.
In between the spine and leaf devices is an IP network (layer 3) that uses an optimized IS-IS routing protocol as of the first release. Other routing protocols may be added in future releases, but this isn’t something the administrator will need to really do much with as it’s all behind the scenes. Since this is all layer 3 there is no need for Spanning Tree Protocol, which we’ve all had problems with over the past several years. Though STP addressed problems with broadcast storms, it could also slow the network down and took a lot of time to plan properly. Adding or removing network switches could create problems with STP as well. These concerns no longer exist with ACI.
Hosts, or EndPoints, of all kinds (network devices, physical servers, virtual servers, etc.) are then connected to the leaf ports, never the spine ports. Both the spine and leaf nodes consist of Cisco Nexus 9000 series switches, though there are ways to integrate other Nexus switches to migrate from your current network to this new ACI model.
Application Policy Infrastructure Controller
ACI uses what Cisco calls an APIC, or Application Policy Infrastructure Controller, to implement the ACI model. Currently the APIC is a hardware appliance that is essentially a UCS C220 M3 with a locked down image which is completely encrypted. At least three APICs are required to ensure high availability, but more can be added to ensure scalability. The APIC provides a Web UI for admins to configure the various constructs that go into creating the ACI network. All of the packet forwarding is handled by the Nexus switches as that’s what they do best. The configuration and telemetry is handled by the APIC, but the APIC does not handle the actual traffic. Within the APIC we can create policies, EndPoint Groups, Contracts, Application Network Profiles, and tenants among other things. So let’s dive into what some of those configurations do.
Policy Model
ACI uses white-list policy model which means that no packets are allowed to flow between applications until it’s been specifically allowed access. In ACI we can set up EndPoint Groups for basically any construct, such as applications, virtual port groups, VLANs, etc. Generally we would set these up to accommodate a 3-tier app model that is found in many data centers. The 3-tier app is usually a web tier, application tier, and database tier. We could have many virtual machines and physical machines within each of these tiers for each application. After EPGs are set up we can create policies to allow certain kinds of traffic to flow between them. For example, if we wanted to allow bi-directional access between the database and app tiers for certain traffic we can do that, unlike with access control lists which only offer unidirectional permissions. Of course, unidirectional access may also only be permitted.
Service Graphs
Sometimes there’s still the need for more traditional network hardware and software in the traffic flow as well. For example we may need load balancers, firewalls, or even some sort of anti-virus or other security solution between our tiers. Using a new protocol called OpFlex (as well as device packages) we’re able to take advantage of that declarative model referred to above with all sorts of Cisco and 3rd-party applications and appliances. This makes it really easy to insert security between tiers as well as create constructs that can be copied and changed more easily making automation even more possible.
Application Network Profile
After we’ve set up EPGs, policies, and service graphs we create Contracts between the tiers. The EPGs will act as either a provider or consumer of these contracts which essentially connect the policies to the tiers with which they should be associated. All of this comes together to become an Application Network Profile. This Application Network Profile can provide us with not only layered security, but again reusable constructs that administrators can apply anywhere within the network.
Tenants
To provide even more micro-segmentation within the ACI model we can assign EPGs to tenants if we like. Multi-tenancy provides complete isolation between tenants. This can be separated however you feel necessary. For example you could have dev/qa in a totally separate tenant than production. The really great thing about doing it this way is you can completely match the tenants so they look identical. We can actually copy the Application Network Profiles from our dev tenant and apply them to our production tenant within a couple of clicks. Of course, we can also separate departments, customers, etc.
This is really really a small part of tips for Cisco ACI when it comes to ACI and how it works. ACI addresses not only fulfill the need for network virtualization but also hardware abstraction to create a stateless network in the entire data center. This network will make it easier for network administrators to not only communicate better with application administrators, but also create powerful networks that offer great performance in less time than traditional networks because of things like automation and repeatable processes.
More RELATED: For more information related to Cisco ACI there are several YouTube videos found here. There are also several overviews such as this one. The Nexus 9000 series switches that make up the spine and leaf infrastructure are available today and the APIC appliance were made available in early August for purchase.
More about Cisco Nexus 9500 ACI Switch
The Nexus 9500 can run in one of two modes, depending on the operating system loaded and the line cards installed: standalone, or NX-OS mode, which is what Cisco is shipping and what we sort-of tested, and ACI mode.
Most, but not all, of the components of the Nexus 9508 chassis are common to both NX-OS and ACI mode: the chassis, the supervisor cards, power supplies, and fabric modules. But the line cards are different in a critical way: they add custom Cisco chips (Application Leaf Engines, or ALE) that bring both additional smarts and additional buffering to the NX-OS line cards. (Cisco says that ACI-mode line cards can also be used in NX-OS mode, but the additional capabilities of the cards will not be accessible to NX-OS.)
Cisco Nexus 9508 ACI Switch
Cisco Nexus 9500 Platform ACI-Enabled Line Card
Cisco Nexus 9500 Platform in a Leaf-and-Spine Architecture
More about Cisco Nexus 9500 Platform ACI Switches you can visit: https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/datasheet-c78-732088.html
For additional Cisco ACI details, please visit https://www.cisco.com/go/aci.
Reference from https://www.virtualizationadmin.com/articles-tutorials/general-virtualization-articles/cisco-application-centric-infrastructure-overview.html
More Related Cisco Nexus 9000 Switch Topics
Cisco Nexus 9000 Series Switches Overview
