The Logical Structure of Cisco ACI Networks

The software defined networking infrastructure of Cisco ACI requires that we take a different approach to the logical hierarchy of the network.  ACI contains six logical elements that you need to understand when building out your data center network.  They are as follows:

• Tenant
• VRF
• Bridge domain
• Application Profile
• End Point Group

When you understand each of these components in the ACI hierarchy, you will have a solid grasp of what is happening in your software defined networking infrastructure and a better understanding of Cisco ACI as a whole.  First to configure these elements, you need to access the APIC and there are three ways to do so.  The first and most common method is the APIC GUI which is an HTML 5 interface in a web browser. To access the GUI, point a web browser at the IP Address of one of the APICs.  The second method of accessing an APIC is to use the command line interface through SSH, and the final method is to utilize the REST APIs for APIC automation.  If you want to access via the APIs, there is a wealth of resources available at Cisco DevNet.

Tenant

In ACI, a Tenant is a logical container separator that allows for administrative domain level control.  This could be the separation of accounts for a managed services provider, or a separation of departments such as placing the applications and services for accounting in one tenant and placing HR into another tenant.  An organization can also use tenants to segment different groups of policies.  What is placed in one tenant cannot be seen or accessed by anything in another tenant, unless specific configuration is performed to allow for cross-tenant communication.  When you start up ACI, you will find three tenants already created, which are: infra, mgmt, and common.  Anything placed in the common tenant is accessible from other tenants.  The mgmt tenant is where ACI places objects for managing the fabric, such as OOB access.  As for the infra tenant, it’s best to pretend that it doesn’t exist and never touch it, unless directed to by Cisco or a Cisco document (multi-pod & multi-site configurations).  All tenant names must be globally unique.

VRF

The VRF in ACI is identical to a VRF in traditional networking.  It contains layer 3 routing instances, tables, and IPs.  VRFs must have a unique within their tenant, but do not need to be globally unique.  VRF’s are joined to the tenant in which they are created and cannot be separated from their tenant.  A ‘show vrf’ command in the ACI CLI will show all of the VRFs and which tenant they are in.  If you are reviewing ACI documentation, keep in mind that VRFs were under different names in previous versions, such as “Contexts” or “Private Networks”.

Bridge Domain

Far too often when in a discussion about ACI, the Bridge Domains are often referred to as being “like a VLAN” and this is close, but not entirely accurate.  They are like a VLAN in that they contain layer 2 broadcast domains or unique subnets.  However, the more accurate term for an ACI Bridge Domain is that it is a VXLAN VNID segment with an assigned multicast group.  You must populate a bridge domain with at least one IP subnet, but can add more than one subnet to a bridge domain.

Application Profile

The application profile is the logical container for your policies in ACI.  The AP contains the End Point Groups and the contracts & filters that define the traffic allowed in your ACI fabric.  You must have one Application Profile in a bridge domain but can have more than one.  It’s likely that there will be more than one AP in your bridge domain to utilize ACI’s micro-segmentation features.

End Point Group

An end point group is a collection of the end points in your network such as, bare-metal servers, virtual servers, switches, routers, firewalls, load balancers, and IP based storage appliances.  The end points within an EPG will have the same policy applied to them.  End points can be defined by physical ports, VMware vNICs, subnets and several other options.  All end points within an EPG can freely communicate with each other.  There must be one EPG within an application profile, but there can and likely will be more than one.

Contracts

Contracts allow communication within your Application Profile.  EPGs cannot communicate with each other unless there is an established contract between them.  A contract is similar to an access list in traditional networking but uses a white-list model for permitting traffic as opposed to the black-list model that ACLs use.  When creating a contract, you will assign one EPG as the provider (server side) and another EPG as the consumer (client side), then you need to define the permitted traffic between those two EPGs.  For example, if you have a web server EPG that needs to get information from a Database server EPG, you would set up the contract with the database side as the provider and the web side as the consumer.  Then you would allow TCP traffic on port 1433 and UDP traffic on port 1434.  This contract will not permit any other traffic across this connection, you wouldn’t even be able to ping from one EPG to the other (unless you added a second line to the contract that allows ICMP traffic).

Understanding these elements of the Cisco ACI configuration will help you to clearly see what is going on in your software defined networking environment.  Keep in mind that this article scratches the surface and if you need to deploy ACI in your environment, I would highly recommend seeking an ACI technical deep dive or an ACI focused class such as Cisco’s CACND (ACI in the Nexus Data Center) or DCACIO (Cisco Application Centric Infrastructure Operations and Troubleshooting).