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.
- 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.