Cisco ACI Policies

Introduction

This post exposes my study notes on ACI Policies. We first distinguish the types of policies in ACI. Then we learn the different fabric access policies.

Types of ACI policies

We can summarize the types of ACI policies in three categories:

Tenant Policies

  • define the behaviour of an application whenever traffic hits the fabric.
  • trigger the access policies.

Fabric Policies

  • Fabric policies are necessary for the internal working of the fabric. They specify “things” on leafs and spines. An example of a fabric policy can be NTP.

Access Policies

Access policies are probably the most intriguing of all ACI policies you will encounter. Access policies perform the configuration of the logical and physical interfaces. However, the configurations remain in a sort of an inactive state on the fabric ports until triggered by a tenant policy.

Another way to consider access policies is that they specify “things” on leafs in the direction of access ports.

The chronological order of configuring access policies is:

  1. VLAN Pools
  2. Domains
  3. AEP
  4. Interface policies
  5. Interface policy groups
  6. Interface profiles
  7. Switch profiles

In the following paragraphs I will expose each one of the constructs that make the access policies.

Interface Policies

  • An Interface policy sets the value of a procotol state.
  • The Interface policy is later used in the interface policy group.
  • There are default interface policies there preconfigured on APIC. Do not overwrite them but rather leverage them (copy and save as…).

Configuring an Interface Policy

Let us take a basic example: CDP.

We create one interface policy with CDP on, and one with CDP off. Set Admin State to Enabled on the first one, and to Disabled on the second one.

Interface Policy Groups

As their name implies, interface policy groups assemble interface policies together in a group. In this way you can create a variety of combination of protocol values and later invoke them depending on the desired output.

ACI offers the possibility to create spine interface policy groups and leaf interface policy groups.

Whether it is a spine or a leaf interface policy group, we have the following options

  • an Access Port policy group: this policy group is assignable later to one or more individual ports, on one or more switches at the same time.
  • a Port Channel (PC) policy group: this policy group is assignable later to ports that are member of a normal Port Channel.
  • a Virtual Port Channel policy group: this policy group is assignable later to ports that are member of a Virtual Port Channel (VPC)

When I said “is assignable to” I meant that the ACI administrator will have the choice to invoke one of the abovementioned Interface Policy Groups when creating Interface Profiles, depending on whether he wants to configure switch ports als standalone, port channel or VPC.

Cisco recommends to assign one and only one Interface Policy Group to a port Channel or vPC (that’s called 1:1 mapping).

An Interface Policy Group is usable by an only one AAEP. But an Attachable Access Entity Profile can point to many Interface Policy Groups, as long as they have not been pointed by another AAEP. That means during the configuration of an AAEP, when you try to link to an Interface Policy Group that is already being used, you get the following error message:

Configuring an Interface Policy Group

Configuring an Interface Policy Group for an Access Port

We configure in the following example an interface policy group for a single leaf interface:

Within the interface policy group configuration menu, let’s say we need the the CDP interface policy I created before:

Configuring an Interface Policy Group for vPC Interface

To create a VPC Interface Policy Group on a leaf switch, go to Fabric –> Access Policies –> Interfaces –> Leaf Interfaces –> Policy Groups –> VPC Interface. Right-click on Create VPC Interface Policy Group:

The Interface Policy Group is attached to one or more leaf ports through an Interface Profile. We will discover in the next paragraph how it is done.

To read all configured Interface Policy Groups and which are attached to a Switch Profile (through an Interface Profile), perform the following command:

apic# show port-channel map

had you configured a port-channel/VPC interface policy group without attaching it, you won’t be able to read it with show port-channel map. That is the case with a port-channel named pc-ipg that I’ve configured but did not appeared in the above output. As soon as I associated it to an Interface Profile, and the Interface Profile to a Switch Profile, it appeared on the CLI:

In the above screenshot, L3_out_Policy_group is the name of the port-channel, which is of type VPC. It is configured and attached to both Leaf 101 and 102, on the access port selector Eth1/4. However, something interesting we can read here:

We have po1 and po2 as port channel numbers on Leaf 101 and 102 respectively, although the port-channel is configured the same for both leafs. This is a confirmation that the concept of port-channels -whether normal port channels or VPC- is locally significant to each leaf, because each leaf has its own internal implementation of port channels.

The concept of local significance with port channels is the same as with VLANs.

Interface Profiles

Aka Interface Selector Profile, an interface profile contains one or more Access Port Selectors (aka simply Interface Selector). 

An Access Port Selector is a logical construct that defines one or more Interface Blocks. An Interface Block belongs to one and only one Access Port Selector. So the APIC does not allow creating an Interface Block of interfaces I1, I2 and I4 to be part of Access_Port_Selector_X and at the same time part of Access_Port_Selector_Y.

An Interface Block is:

  • either a single physical port, or
  • a range of physical ports, whether they are numerically consecutive or not (in this case they are separated with a comma).
selecting individual physical ports within a single Access Port Selector. Here, Ports 1/3 and 1/5 form the Access Port Selector
Access Port Selector: combination of consecutive and non-consecutive ports. Three ports are chosen consecutively (ports 1/6 through 8) and two ports non consecutively (1/3 and 1/5)

We can define Interface Profiles on either leafs or spines. That is why we find on the ACI GUI both options:

In this blog article we focus only on Leaf Interface Profiles.

Interface Profiles select interfaces on one or more switches, without instructing the fabric which switches they are. However, we ideally use an interface profile naming convention that gives us a hint as to where this interface profile will be deployed. For example: Interface Profile LIP_104_106 shall give us a hint that we will configure access port selectors on leafs 104 and 106.

An interface profile is only a group of interface selectors; i.e it does not configure interfaces.

We will see in a moment that an Access Port Selector is associated to one and only one Interface Policy Group. But an Interface Policy Group can be invoked by an α number of Access Port Selectors, where α equals:

  • infinite, if the Interface Policy Group concerns Access Ports (i.e it is an Access Port Interface Policy Group)
  • 1, if the Interface Policy Group concerns a port channel or a vPC (i.e it is a Port Channel Interface Policy Group or a vPC Interface Policy Group).

Configuring Interface Profiles

As a requirement to configuring an Interface Profile, you should have already created an Interface Policy Group.

Creating interface profiles takes place under Leaf Interfaces –> Profiles menu:

I chose to include “103_104” into the name of the leaf Interface Profile as a quick reminder that this interface profile “is destined” to be associated with leaf switches 103 and 104. Remeber, this is only a naming choice, and ACI fabric up to this point does not know (is not yet programmed) from which switch(es) it should select the interface(s). ACI fabric will know which switches as soon as you associate the Interface Profile to a Switch Profile.

Now create the Interface Profile:

Notice I’ve named the Interface Profile with a prefix of “LIP”. That helps me avoid the naming confusion between Leaf Interface Profiles and Leaf Switch Profiles.

Near Interface Selectors click the + sign and chose which interfaces are part of this Interface Profile.

The Interface ID must be in the format {Module/port number}. With fixed-chassis leafs:

  • Start the Name in the format “1:”
  • start the Interface ID in the format “1/”.

Associate an Interfac Policy Group to the Leaf Interface Profile.

We can define as many Access Selectors in a same Interface Profile as we want:

Configure an Interface Profile for a vPC Interface

In a vPC Interface Profile, make sure:

  • to have in its name the pair of leaf IDs
  • to attach a vPC Interface Policy Group to the Access Port Selector:

Switch Profiles

Another class of ACI policies that sounds like Interface Profiles is the Switch Profile.

A Switch Profile selects one or more switches from which the ports will be configured and invokes an Interface Profile. That is one of the beautiful traits of ACI; you can select a range of interface on a range of switches, unlike the CLI “interface range” command which limits you on a single switch.

A Switch Profile does not configure switches. Remember: no leaf port is configured until an associated tenant policy is activated.

Said in another form: Switch Profile = Switch selector + invoked Interface Profile

Like Interface Profiles, there are:

  • Leaf Switch Profiles, and
  • Spine Switch Profiles

We focus on this blog article solely on Leaf Switch Profiles.

Configuring Leaf Switch Profile

Method 1: Using the Regular GUI

Under Create Leaf Profile menu:

  • insert a significant name and description that can help you later by a troubleshooting session.
  • next to Leaf Selectors, click the + sign. Name and Blocks are text fields.
    • give a name to the Leaf or group of leafs
    • in Blocks:
      • enter the leaf ID if you select one switch
      • enter a range of leaf IDs separated by a dash, if you want to select more than one switch at the same time
  • click Update

In our below example we create a Leaf Switch Profile consisting of leafs 103 and 104:

  • Press the Next button to set up the association between this Switch Profile and one or more Interface Profile(s):
  • from the scrollable list, mark the checkbox(es) near the desired Interface Profile(s) and click Finish. Note though that this step is optional because we can associate an Interface Profile to the Switch Profile later.
Leaf Switch Profile named 103_104 contains leafs 103 and 104, and is associated with Interface Profile LIP_103_104

Et voila!

Pay attention that we can associate more than one Interface Profile to a Switch Profile:

Leaf Switch Profile Leaf101_102 has been associated to two Interface Profiles: eth1_3 and pair_101-102_LIP

We can leverage our example of Leaf Switch Profile for normal access ports, as well as for vPC interfaces since it includes 2 leafs (but this requires us to attach a vPC Interface Profile to the Leaf Profile)

Sometimes you get an error message telling that the interface selector ranges are already used in another Interface Profile:

Interface Eth1/9 is being used elsewhere. And you can see which “overlapping” Interface Profile it is.

Method 2: Using the Quick Start Guide

Go to Fabric –> Access Policies –> Quick Start

Then in both of the following menus you can create a Leaf Switch Profile:

Click on the plus sign to define a Switch Profile.

You select the switches:

And it will automatically generate a Switch Profile:

Determining the Leaf Interface Profile and the Interface Policy Group Associated to a Leaf Switch Profile

At any point, starting from the Leaf Switch Profile, we can determine:

  • which Leaf Interface Profile is being used
  • which Interface Policy Group is being used.

For this, you need a couple of double clicks:

  • In our example, double-click on the Leaf Switch Profile 103_104
  • Scroll down to Associated Leaf Selector Profiles and double-click on the already associated Leaf Interface Profile:
  • The menu changes to “Leaf Interface Profile”:
  • From there you can also read the Interface Policy Group being associated to it:

General note: use a naming convention that is consistent across the fabric(s).


The last pieces of the puzzle of the ACI policies are the ACI domains, which I explained separately.

Conclusion: Linking everything together

Learning the fabric access policies is a daunting task at first. Here is a nice diagram I found on Cisco.com that glues all access policies together:

aci-policies

Click here to read the rest of my Cisco ACI study notes.

Leave a Comment