ACI—Some lesser known features

I am a consultant at a Cisco partner and I get to see a lot of different networks. Most of the networks are Cisco, but there are a few that are not. From time to time, I get network assessment projects. I love these types of projects as they are an exploration of  uncharted networks to see what can be discovered. Personally I like to have my network consistent, orderly, and precise. The common components of the configurations on all device should be identical. These network assessments usually do not conform to these standards. Syslog configured on some devices pointing to a device that no longer exists while not configured on other devices at all. SNMP strings configured with the defaults of private and public. Local user accounts that have a wide variety of passwords. There ends up being very little that is common between all network devices.

Most of the time, the only place any security that is done is on a firewall at the Internet edge of the network. All devices inside the network have full access to all of the servers in the data centers. There maybe a web or front-end app server, but the database server is sitting right out there with full network access to the user community.

#Some ACI features
Two of the features that I am really looking forward to with ACI (Application Centric Infrastructure) is keeping the configurations of the network devices consistent and the almost forced security on servers, especially with tiered applications.

As a partner I was able to do a lab with an early version of the APIC (Application Policy Infrastructure Controller) simulator. Adding the Nexus 9000s to the controller was a simple process. It reminded me of using CDP (Cisco Discovery Protocol) to discover the neighbor devices as I would go throughout a network. With the APIC central controller, I built the configurations for the network devices and they were pushed out to each network device. This will help keep all of the configurations in sync between the devices. No longer will you have to worry about if you mis-configured syslog on a device or missed a device all together with that SNMP change you needed to do.

As for security, basic access list type security is almost forced. I say almost because the default policy is similar to the implicit deny in an access list in that nothing is allowed by default. You must configure access from the clients to the server and server to server. Yes, you can create generic policies similar to a ‘permit ip any any’ and open up the entire network.

#ACI WebUI
For network administrators that don’t want to get too deep in networking or just don’t have the time to learn the gritty details can use the Web interface to configure the entire network. Network administrators will need to learn some new concepts like BD (Bridge Domains), EPG (Endpoint Group), and contracts. When these are build you have to give them a name. This is similar to ASAs (Adaptive Security Appliance), especially recent versions, that require the extensive use of group objects. Every time I work on an existing ASA, there is never a standard naming of the groups. These object groups get duplicated, intensionally or not, with vastly different names, but the same objects inside. I can foresee this happening in APIC if you don’t develop and use a standard naming convention. Maybe it’s just me and my OCD.

#ACI API/CLI
APIC has the API that allows you to pull information or push configurations to the entire fabric. In this lab, after we built everything manually using the GUI, we deleted it all with a Python script. Then we proceeded to rebuilt everything via a Python script and a set of configuration files. It took longer to read the output from the script than it took the script to run. Yes, the scripts were already written, but that is the beauty of automating something that is repeatable. You invest a little time in the beginning and not only do you speed up any future changes that are similar, but you get the same consistent configuration and result. We can do the same thing repeatedly and expect the same result.

#My Opinion
For the initial setup and connection to vCenter or Hyper-V Manager I would use the WebUI. Once that is done, then write a script once to add the applications, Bridge Domains, Endpoint Groups, contracts, etc as necessary via the API. Everyone doesn’t have to write the same script. Just one person needs to write it and publish it for the community to use.

Something else that will be nice to speed up administration is the application profiles that manufacturers will create that you can just import and make the necessary changes for your environment. Download the application profile for software X, import to APIC, answer and few question specific to your environment and presto, a multi-tiered application all configured on the network and much more secure than on most traditional networks.

**References:**

* [Endpoint Group] (http://www.cisco.com/en/US/prod/collateral/netmgtsw/ps13004/ps13460/white-paper-c11-729906_ns1261_Networking_Solutions_White_Paper.html)
* [Bridge Domain] (http://www.cisco.com/web/learning/le21/le39/docs/tdw_213_qa.pdf)
* [Contracts] (http://www.cisco.com/en/US/prod/collateral/netmgtsw/ps13004/ps13460/white-paper-c11-729906_ns1261_Networking_Solutions_White_Paper.html)

Share