Introduction
A few weeks ago I started a new path in my career. I’m now working for Cisco as a Technology Evangelist. Specifically I’m concentrating on Application Centric Infrastructure (ACI) and the Nexus 9000 series switches. As software defined networking becomes more popular and even necessary, I’ll be writing about my journey learning ACI and other solutions.
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. This gets us into promise theory which is what ACI is based on, but we’ll save diving into that for another article.
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.
Figure 1: Taken from cisco.com
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.
Figure 2: Taken from Cisco.com
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.
Figure 3: Taken from Cisco.com
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.
Conclusion
This is really only the tip of the iceberg 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. For more information 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.
