Cisco ACI and Software Defined Networking – Part 2

This month’s blog post is a continuation of last October’s post on Cisco ACI and Software Defined Networking – Part 1. In part 1, I gave some history on traditional networking and discussed how networking is evolving to accommodate the next generation data center and cloud computing with Software Defined Networking or SDN. This month we dive into Cisco’s approach to SDN – Cisco Application Centric Infrastructure or ACI.

At first glance

Cisco ACI is made up of two components. First, the Application Policy Infrastructure Controller or APIC is management software component for ACI. Its responsibility is to manage and apply network policy on the fabric.  The APIC is an appliance or UCS 2240 M3 (Frist Gen) or 2240 M4 (Second Gen) which is a 1U rack mount servers. They are typically in a clustered configuration for added resiliency. Second, the Nexus 9000 is the hardware component. They can run in traditional nexus mode or ACI mode. In ACI mode, all the management and configuration happens at the APIC level. In Nexus mode, management happens at the individual switch level.

Here is a list of ACI compatible hardware.

Object Model, Tenants and Contexts

The Object Model is the foundation of ACI and where it truly derives its power. For those who are familiar to programming. The Object Model that ACI uses operates like an Object in Object Operating programming. The object has a set of attributes that can be modified and shared across the entire model. This is a huge departure from how we managed switches in the past individually using a flat configuration file. In programming terms, the old way of configuring switches was a lot a procedural program. Each line in the startup configuration file was read into memory and becomes the running configuration.

The ACI Object model is made up of tenants which can be used by different customers, business units, or departments within an organization. When ACI is first turned on it creates a default Tenant. From there, additional Tenants can be created based on the needs of the organization.

Tenants are broken up into contexts which are different IP spaces or subnets with their own Virtual Routing and Forwarding (VRF) instance(s). Contexts are very similar to VLANs but are much more configurable and less limited than the traditional VLAN.

Endpoint Groups and Policies

Endpoint Groups or (EPGs) are a grouping of endpoint devices that share the same set of network services and that ultimately represent an application or business unit. An EPG can be a physical NIC, Virtual NIC, Port Group, IP Address, VLANs, VXLANs or DNS name. EPGs allow the network engineer to logically segregate a network based on the application. In the past, this would typically be done with VLAN(s) which would logically segment the network to Isolate for performance or security reasons. This can cause additional complexity which isn’t necessary needed. By default, a device can’t communicate on the network. This rule operates more like Fiber Channel SAN and less like an Ethernet LAN.

A policy consists of a Source EPGs (sEPG) and a destination EPGs (dEPG). Polices can be ingress and egress rules that can be used for Access Control, Quality of Service (QoS), or other network related services. Once you are in an Endpoint group you can communicate as long as you have IP reachability. A policy allows you to create an application group (web, app, and database servers and control the network communication between each. A policy essentially defines a security zone for a particular application. A policy enforcement matrix used to group sEPG(s) and dEPG(s) in a grid and where they meet is where policies are enforced.

Contracts and Filters

Contracts define how EPGs communicate with each other. Similar to a contract that you sign the defines an agreed upon outcome. In the ACI world, a contract is a set of rules that defines how the network will operate within a policy. Contracts can either be provided or consumed by an EPG. Filters are used to permit and deny traffic at Layer 2, 3 and 4. Filters are applied to both inbound and outbound interfaces. A Filter is essentially a Access Control List or (ACL) on the network.

Application Network Profiles

An Application Network Profile groups everything together (EPGs, contracts and filters) and that dictates how that traffic behaves on the network fabric for a specific application. For those that are familiar with UCS platform. An application network profile is very much like a service profile is to a server. It gives the network hardware an identity once defined.

Private Networks, Bridge Domains and Subnets

A private network is simply a L3 forwarding domain. When added to a context is acts just like a VRF in the traditional network world which can allows for a private network to have overlapping IP addresses without conflict. Bridge Domains or simply BDs are responsible for L2 forwarding like a VLAN. The difference is that you aren’t subject to the limitations of a VLANs on a traditional network like the 4096 VLAN limit. A subnet is defined under a Bridge Domain and creates a gateway. Much like a Switch Virtual Interface or SVI. A gateway is a logical interface that can exist on multiple nodes in the fabric.

In this post, I just scratched the surface on Cisco’s ACI by covering some basic concepts and terminology. Cisco’s ACI and SDN in general are changing the way Network Administrators and Engineers approach the design and administration of networks. New skills like basic scripting and programming will be required for Network Engineers as software takes more predominate role in the data center.

Leave a Reply

Your email address will not be published. Required fields are marked *