Cisco ACI: A must have for your data center

A few years ago, we started hearing the term, “Software Defined Networking” and with that term, Cisco Introduced us to ACI.  As we were exposed to ACI, the general attitude from the IT data center networking community was to ask why we needed it.  After all, we were doing just great with our SSH connections into each of our Cisco Nexus switches and telling them what we wanted to do.  But is that really the way to go about managing our data center networks?  Let’s take a step back from networking and look at another common IT process.

Imagine that you are tasked with deploying a couple hundred workstations in a new office.  You go to each workstation, insert the Windows install media, install windows, create the user account for the person assigned to that machine, and then configure the appropriate settings and user permissions.  Once that’s done, you move onto the next machine, right… No.  Instead, you connect the workstations to the network and perform a network install push across the entire office deployment.  Then you create the user profiles in Active Directory, add the new users in and assign them to the correct profiles.  When the user logs into their workstation, it pulls the appropriate settings and user permissions from the Active Directory profile using automated processes.  We do this because it’s simple, time saving and automates our processes.

Now imagine that you’re involved in the buildout of a new data center network.  You console onto each switch and run the basic setup on each device until you configure SSH connectivity on every switch in the data center.  Then you go back to your computer and SSH to each device, configure the settings for the switch, VLANs, QoS policies, interface configurations and so on.  When you’re done with one switch, you SSH to the next one on the network and repeat.  You try to speed up the process by having the common elements pre done on a text file that you can copy into the CLI, or once you get one switch configured, you grab its running config, copy into a text editor and edit for the next device.  Why?

Why not automate the process like Active Directory does with the workstations?  Why not use a centralized management system that implements policy-based profiles which can be deployed across your entire network in seconds?  This is why Cisco ACI is the answer for managing your data center network.

ACI Dashboard Interface providing centralized management of your data center network.

Cisco ACI centralizes your network management to a single pane of glass where you create the policy for your network and the systems connected to it.  The way ACI works is that every device connected to your network is assigned to an End Point Group (EPG).  Before any policies are defined, all devices in the same EPG have open communication with each other but cannot communicate with devices in other EPGs.  The policy that you create in ACI is called an Application Profile, or AP (older versions of ACI used the term Application Network Profile, or ANP).  In the AP, you assign contracts to the EPGs, each contract defines the type of network traffic that is allowed pass between the EPGs.

Consider this example; you are hosting a web portal for your business and have an EPG for your web servers, you would create a contract between that EPG and your external internet connection (which is also treated as an EPG in ACI) that allows external traffic on ports 80 (http) and 443 (https) to connect to your web servers.  Now let’s say that you have customers connecting to your web servers and they want to see their customer account data, so your web servers need to connect to an authentication server.  Your Authentication server is in another EPG and you create a contract between your web server EPG and your auth server EPG that allows only the necessary authentication request and verification traffic to pass between the servers.  You would also have your authentication server access a database server that has the customer account data which is in another EPG.

Sample Application Profile in ACI showing EPGs and Contracts

Now let’s say that you are expecting higher traffic, and so you spin up some additional VMs as web servers to handle the increased traffic and to help with load balancing traffic, you place those servers on a separate host server.  In an ACI environment, how much network configuration do you need to do so that the web servers are handling the new traffic load?  None!  As those servers are spun up, they are placed in the web server EPG based on ACI policies and automatically added to the Application profile where the contract policies are applied.  In the time those VMs were provisioned, booted up and accessed their shared storage for web hosting data, they were online and receiving web traffic.

Another great feature with software defined networking through ACI is that it has a built-in security layer.  In the traditional networking environment when you connect all of your switches together and power them on all ports are open and everything can talk to everything.  We then input commands to control traffic by deploying logical blocs such as VLANs, Private VLANs, and Access Control Lists.  ACLs can become very large, overbearing and difficult to edit as the needs of the traffic in your data center changes with the applications you are running, which can lead to security holes as applications are decommissioned, but the ACLs are left alone.  In the ACI environment, the only devices that can inherently talk to other devices are the ones in the same EPG.  You then must build a white-list policy model, referred to as a “contract,” which permits only the traffic that you want to permit between different EPGs.  If there is no contract, or the type of traffic isn’t permitted by existing contracts, the traffic is dropped.  Furthermore, as the needs of the traffic in your data center changes, you can add or remove contracts based on the changes and keep your allowed traffic consistent with what is currently running in your data center.

This is an intro to a series of posts that I’ll be doing about Cisco ACI.  Come back for more updates as I dive into the mechanics of ACI, look under the hood of what’s going on in an ACI environment and take a further deep dive into ACI.