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 is a single unit of configuration that denotes a value of a protocol or feature state. For example let’s take a basic layer 2 protocol: LLDP. ACI allows to define an Interface Policy for LLDP when LLDP is on, or when LLDP is off. So a network engineer can define two Interface Policies for LLDP: one with LLDP on (and he can name it for example Int-Pol-LLDP-ON) and another one with LLDP off (for example Int-Pol-LLDP-OFF).

Let us take another example, but for a feature this time, not protocol: interface speed. A network engineer can define Link Level Interface Policies that set… well… link-level stuff like:

  • activating (nor not) auto-negotiation
  • interface speed: 1Gbps, 10Gbps, etc.

Our Interface Policies would look something not very different from this:

  • Int-Pol-1Gbps
  • Int-Pol-10Gbps
  • Int-Pol-40Gbps
  • etc.

There are default interface policies that are pre-configured on APIC. A network engineer should NOT overwrite them, but rather leverage them (copy and save as…).

Each Interface policy can be later invoked in the Interface Policy Group.

Configuring an Interface Policy

Let us take the example of CDP:

clicking on the CDP Interface menu
create CDP interface policy

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.

submitting CDP interface policy settings
setting the CDP interface policy admin state to Disabled.

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 and link properties 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. And whether it is a spine or a leaf Interface Policy Group, we have the following flavors:

  • an Access Port Policy Group: this policy group is assignable 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 to ports that are member of a normal Port Channel.
  • a Virtual Port Channel Policy Group: this policy group is assignable 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.

Note that, unlike in Cisco IOS where a Port Channel (and also a vPC) is identified with a number on the device, a Port Channel Interface Policy Group name (or for the same matter, a vPC Interface Policy Group name) identifies in ACI the Port Channel (or vPC). This appears clear when a Network Engineer associates an Interface Profile’s Interface Selector (or in case of an AAEP) a with an Interface Policy Group; we see their names, not numbers.

Cisco recommends:

  • to assign a Port Channel Interface Policy Group to one and only one Access Port Selector
  • to assign a virtual Port Channel Interface Policy Group to one and only one Access Port Selector

I am not yet sure of the reason why. But I guess, if we have this setup where two Interface Profiles are pointing to the same Interface Policy Group:

two ACI interface profiles for test
two ACI interface profiles for test
first ACI interface profile with vPC interface policy group
first ACI interface profile with vPC interface policy group
second ACI interface profile with the same vPC interface policy group
second ACI interface profile with the same vPC interface policy group

then the resulting vPC would contain ports 12, 13 and 19 as member ports together in the same aggregation. This is only a speculation that needs to be labbed and analyzed in detail…

So basically, a Network Engineer should avoid this design and make sure a Port Channel Interface Policy Group or a virtual Port Channel Interface Policy Group is attached to only one Interface Profile (through one of its Access Port Selectors).

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:

an error when trying to attach an interface policy group to an Attachable Access Entity Profile

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:

menu for creating a Leaf Access Port Policy Group

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

sample settings for a Leaf Access Port Policy Group

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:

menu to create a VPC Interface Policy Group
settings of a VPC Interface Policy Group
displaying leaf interface policy groups

Whether we configure an access port interface policy group, a port channel interface policy group, or a VPC interface policy group, all of them are displayed under the same menu Leaf Policy Group.

However, clicking on the configured interface policy groups one by one, we can determine in the work menu which type of interface policy group it is.

For example, the first configured interface policy group is a PC or VPC interface policy group:

a PC or VPC interface policy group
a PC or VPC interface policy group

The second one is an access port interface policy group

a port interface policy group
a port 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
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:

issuing the show port-channel map command after associating the PC Interface Policy Group to an Interface Profile

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:

port channel ID in the output of show port-channel map command

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).
create access port selector menu
selecting individual physical ports within a single Access Port Selector. Here, Ports 1/3 and 1/5 form the Access Port Selector
giving a range of interfaces in the Create Access Port Selector menu
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:

Leaf Interfaces menu and Spine Interfaces menu under the fabric Access Policies

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.

cisco aci interface profile access port selector and interface blocks
cisco aci interface profile access port selector and interface blocks

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 :

  • α  ≈ ∞ (actually it is limited to the amount of available resources) , 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).
cisco aci interface policy group and its relationship with access port selectors 1
cisco aci interface policy group and its relationship with access port selectors 1

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:

Create Leaf Interface Profile 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:

setting a name for a Leaf 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 Interface Policy Group to the Interface Selector:

We can define as many Access Selectors in a same Interface Profile as we want, and associate to them Interface Policy Groups according to our business needs:

Configure an Interface Profile for a vPC Interface

In a vPC Interface Profile, I recommend to:

  • to name the Interface Profile after the pair of leaf IDs,
  • to attach a vPC Interface Policy Group (neither an Access Port Interface Policy Group, nor a Port Channel Interface Policy Group) to the Access Port Selector. In the example below I already created a VPC Interface Policy Group named KBB-VPC-IPG, then attached it to the Access Port Selector:

Sometimes you get an error message telling that one of the ports in an interface block is already used in another Interface Profile:

ACI error while selecting interfaces in an interface block
Interface Eth1/9 is being used elsewhere. And you can see which “overlapping” Interface Profile it is.
interface is associated to another ACI interface profile
interface is associated to another ACI interface profile

To quickly have a look at which interfaces are reserved in which Interface Profile, a Network Engineer can click on the Interface Profiles menu

clicking on Leaf Profiles menu in ACI
clicking on Leaf Profiles menu in ACI

and sort the list with names in the working pane:

sorting Interface Profiles with names in ACI
sorting Interface Profiles with names in ACI

Hopefully you have the same naming convention. That is one reason why I recommend Network Engineers to have a consistent naming convention for all ACI managed objects.

For example, from the above screenshot a Network Engineer can find out that the following ports are assigned to some Interface Profiles:

  • on Leaf 1, and on Leaf 2: ports 1, 2-3, 5-7
  • on Leaf 3: ports 1-2, 3-5
  • on Leaf 4: ports 5-7

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 -in a previously defined Interface Profile- will be configured. So to say it in other words, a Switch Profile selects one or more switches that will instantiate the Interface Profile’s ports:

A Switch Profile 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 to a single switch.

Switch Profile = Switch selector + invoked Interface Profile

So there must be a way to “link” a Switch Profile to an Interface Profile. And this is what we will see in the second step of configuring a Leaf Switch Profile. However, a Network Engineer technically does not have to attach an Interface Profile right during the definition of a Switch Profile; he can do that later.

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

Like Interface Profiles, there are:

  • Leaf Switch Profiles, and
  • Spine Switch Profiles

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

Leaf switch profiles and spine switch profile
Leaf switch profiles and spine switch profile

Configuring Leaf Switch Profile using the regular GUI

Create the Switch Profile

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:

But, if we need more than one Leaf switch in a Switch Profile, do we configure them as part of the same Leaf Selector or in separate ones?

I still have no solid argument for that, since I still do not have experience with Switch Policy Groups. Technically, both ways should work:

  • whether the network engineer configures one Leaf Selector per leaf:
configuring more than one Leaf Selector in ACI each contains only one leaf
configuring more than one Leaf Selector in ACI each contains only one leaf
  • or all leafs under the same Leaf Selector:
configuring only one Leaf Selector in ACI which holds all leafs
configuring only one Leaf Selector in ACI which holds all leafs

And ACI allows the network engineer to have both types of Switch Profiles at the same time!

both Leaf Switch Profiles appear in ACI
both Leaf Switch Profiles appear in ACI

Attach Interface Profile to our Switch Profile

Press the Next button to set up the association between this Switch Profile and one or more Interface Profile(s):

ACI leaf switch profile next step
ACI leaf switch profile next step

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 Switch Profile).

Configuring a Switch Profile 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:

Cisco ACI access policies summary
Cisco ACI access policies – copyright cisco.com

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

References and further reading

  • https://community.cisco.com/t5/data-center-blogs/connecting-physical-servers-to-cisco-aci-fabric-simplified/ba-p/3808366

Leave a Comment