A really nice way to keep your ACI Interface Selectors (Access Policies)  Clean

This is a very short blog,   Often times I see that customers have tons of Interface Selectors and they become unwieldy.  

Further, it’s very easy to create an interface selector, let’s say an interface selector called mongo1 for port 1/5 and then they forget to go to the switch profile and add that on the switch that port needs to go to. for example  leaf 301.  Then they have to trobleshoot why it’s not getting connectivity

In addition, when you are looking at pages and pages of interface selectors you have no clue what selector goes to which leaf switch.   You would have to click on the  selector and click on show usage to see which switch that selector is associated with.   Apart from this inconvinience, it is an eye sore.  You will see pages and pages of interface selectors and just by visully looking at it, you have no clue which one is associated to which switch or pair of switches

I’m not sure that this method I’m showing you here is well known or not.  Most customers that I get pulled into to help with advise/escalation don’t seem to be using this simple method and I wish that they did.  Unfortunately this is not listed in any Cisco CVD documentation, neither do I see this in the short cisco ACI demos or dcloud exercises.

This method was actually shown to me by a customer about 4 or maybe 5 years ago and I loved it. Ever since, I’ve shown this to every customer that I have visited.

The Method:

  • You create Switch Profiles for every individual Leaf Switch and every pair of leaf switch that are VPC’d together.  
  • While doing this you create the exact same named policy for your leaf Interface Policy, in other words an empty shell for the Leaf Interface Policy with the same name.
  • You associate the Switch Policy with that empty shell Leaf  Profile Policy. 

That’s it.   From now on,  you never have to touch the switch profile again.  You only do this one time initially.    Only when you add new leaves (in pairs always) do you do this as part of your one time initial setup.

Now whenever you need to add a interface selector, you just go to the appropriate Leaf Interface Profile and add it in there.  Since that Profile is already associated with the parent Switch Policy, you don’t have to touch the Switch Profile again.

Everything is neat and organized and as you all know the more organized your configruations are, the easier to troubleshoot / operate and understand just by visualization.

Let’s look at an example:

In the below example, you see that I  have created Switch Profiles for every switch and pair of switches in the Fabric.  

I’ve also created Leaf Interface Profiles with the exact same names

Now in each of the Switch Profiles, I’ve done associated:

  • The corresponding switch ID
  • The corresponding Interface Selector Porofile

Tha’t it.  From now on, I don’t have to ever touch my switch Profile again.  when I want to add an interface, let’s say I want E1/41 from leaf101 and Leaf 102 (VPC to the host),  I just add it in the correct Leaf Interface Profile and I’m done.

Now if I wanted to see what interfaces are used by a particular switch, all I have to do is click on the Leaf Interface Profile for that switch.  In the example below I’m looking at Leaf 301.

Similarly, I can see a Global View of what switch is using what interface, just by clicking on Leaf Intefaces / Profile.  This is extremely convenient in my view.

What if you’ve already done it the old way and you have pages and pages of Interface Profiles already.  

As always, it’s easier to implement a method from the begining.  I have actually helped customers change over to this method over the course of time.  You basically make the empty shell (using api calls from postman). Don’t put the interface Selectors on the empty shell at this time.   Later during a maintenance window, you delete the Interface that’s out in the open and quickly put that in the shell.   If you do this with API calls, you will not even notice anything going down.  But please don’t do this outside a maintenance window to be safe.  

The other thing is for new leaves you can implement this method as you add those leaves.

Posted in All

4 thoughts on “A really nice way to keep your ACI Interface Selectors (Access Policies)  Clean

  1. All great points, and it can get messy quickly. You can also take this a step further and use standard names for policy groups. For example, a standard vpc policy group for each port-number of a leaf: Port03-vPC_IntPolGrp. Anytime port 3 is used in a VPC (assuming port 3 on each leaf in the VPC pair is used), you can reference this same policy.

    Soumitra– Thanks Justin. You are absolutely correct. The whole idea is to keep everything nice and organized. In the blog I just showed the Interface Selector Organization, because that becomes the most messy and an eye-sore. The next step is to also be organized about the “Policy Groups” AAEPs, etc, etc. Just keep in mind though, based on your AAEP, Vlan Pool/PhysicalDomain the FD Vlan will be determined. So, make sure not to break your intent.

  2. One thing I typically recommend to customers for a policy group naming convention is to name the policy group the name of the endpoint. In addition, I recommend that every endpoint gets its own policy group. The other part to my recommended naming convention is the name of the port selector itself. I typically recommend using “Port-47” or “Eth-47”. This would allow them to click on the interface leaf profile and, on the right side, be able to see exactly what endpoint is plugged into which port.

  3. I bumped into this article looking for recommendations. I am new to ACI myself and on the access leaf switches, the interface selector naming is becoming complex and difficult to manage as more ports are requested. I’ll recommend to my team to mitigate and standardise before it gets out of control.

  4. Lamin, Welcome to the world of ACI ! Yes, you are absolutely correct. ACI gives you so much power. You can do in minutes what would have taken you days to configure in the classical approach. However, if you are not organized from day 1 it becomes a mess really easily and unmanageable. Trying to fix it later is not an easy task. Being organized and having a consistent approach will give you the full potential of ACI, especially when you start automating configurations. Also, please be sure to follow the best practices of day 0 fabric bringup. Please do a search on “best” at unofficial.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.