02-01-2024 09:17 AM
Just curious if the "new" Interface Configuration wizard is widely used for implementing the ACI fabric OR migrated the existing selectors/profiles to the Interface configuration fashion?
I am still preferring the manual approach to define the interface selector and switch selector to configure access ports, PC and vPC. However, one "issue" I ran into with the manual approach is specifying the description for each individual ports, whether they are individual access or a PC member port, if the interface selector has multiple ports included...
Solved! Go to Solution.
02-02-2024 12:44 AM
Once you start pushing configs using Ansible, it will make your life much easier. I still prefer the old interface config style
02-02-2024 01:34 AM
Hi @m1xed0s ,
Old habits die hard eh?
My opinion is that the "new" (5.27(g) and later) way of managing Leaf and Interface Profiles and selectors is the way it SHOULD have been done on day 1.
Now I do have some criticisms - all around the system-dash-something-ridiculously-long-convoluted-names that are used, so that when you looks at narrow list of names they all look the same. SHAME ON YOU CISCO - you should have made the designers use the product first!
Now I've got that off my chest - back to your question.
Whether people like it or not, this is the way it will be done going forward. There's no sense resisting change when Cisco have decided this is the way it is done - yes, you are left with option of continuing your old ways... UNTIL someone gets soooo tempted by that message that appears at the top of the page every time you visit Fabric > Access Policies >> Interface Configuration that tells you are doing things the old way and asks "Would you like me to fix that?"
The moment someone clicks that link (and confirms) then your turning back is like diving your car back up the cliff you just ran off.
And regarding your problem:
I am still preferring the manual approach to define the interface selector and switch selector to configure access ports, PC and vPC. However, one "issue" I ran into with the manual approach is specifying the description for each individual ports, whether they are individual access or a PC member port, if the interface selector has multiple ports included...
Port descriptions in ACI have been a PIA forever - and in the new system (since there are no Leaf Profiles with more than one leaf) VPCs have to have the interface description entreated twice (because there is an Interface Selector for each VPC leaf pair)
BUT if you are still using the old system, the best way to enter a description is go to Fabric > Access Policies >> Interfaces > Leaf Interfaces > Profiles > Your_Leaf_Profile > Your_Interface_Selector and double-click on the port block - be it a single port or a range. If you enter the description there, it should work.
In other words DON'T try and enter the interface description from Fabric > Inventory >> Pod 1 > Your_Leaf > Interfaces > Physical Interfaces > interface-id
02-02-2024 12:44 AM
Once you start pushing configs using Ansible, it will make your life much easier. I still prefer the old interface config style
02-02-2024 05:00 AM
Would not disagree with you but personally prefer Terraform when working with ACI...
02-02-2024 01:34 AM
Hi @m1xed0s ,
Old habits die hard eh?
My opinion is that the "new" (5.27(g) and later) way of managing Leaf and Interface Profiles and selectors is the way it SHOULD have been done on day 1.
Now I do have some criticisms - all around the system-dash-something-ridiculously-long-convoluted-names that are used, so that when you looks at narrow list of names they all look the same. SHAME ON YOU CISCO - you should have made the designers use the product first!
Now I've got that off my chest - back to your question.
Whether people like it or not, this is the way it will be done going forward. There's no sense resisting change when Cisco have decided this is the way it is done - yes, you are left with option of continuing your old ways... UNTIL someone gets soooo tempted by that message that appears at the top of the page every time you visit Fabric > Access Policies >> Interface Configuration that tells you are doing things the old way and asks "Would you like me to fix that?"
The moment someone clicks that link (and confirms) then your turning back is like diving your car back up the cliff you just ran off.
And regarding your problem:
I am still preferring the manual approach to define the interface selector and switch selector to configure access ports, PC and vPC. However, one "issue" I ran into with the manual approach is specifying the description for each individual ports, whether they are individual access or a PC member port, if the interface selector has multiple ports included...
Port descriptions in ACI have been a PIA forever - and in the new system (since there are no Leaf Profiles with more than one leaf) VPCs have to have the interface description entreated twice (because there is an Interface Selector for each VPC leaf pair)
BUT if you are still using the old system, the best way to enter a description is go to Fabric > Access Policies >> Interfaces > Leaf Interfaces > Profiles > Your_Leaf_Profile > Your_Interface_Selector and double-click on the port block - be it a single port or a range. If you enter the description there, it should work.
In other words DON'T try and enter the interface description from Fabric > Inventory >> Pod 1 > Your_Leaf > Interfaces > Physical Interfaces > interface-id
02-02-2024 05:57 AM - edited 02-02-2024 06:02 AM
SHAME ON YOU CISCO - you should have made the designers use the product first!
Lol...Wasn't this what people complained from Day 1 of adopting ACI...
Thanks for the detailed reply, as always! What you showed is what I do currently to specify the interface description. However, I do run into limitation from time to time. One of most frequent scenario would be there are multiple interfaces with similiar characteristics under the same selector which means the description I put in there would be applied to all the interfaces within...
02-02-2024 12:25 PM
@m1xed0s ,
One of most frequent scenario would be there are multiple interfaces with similiar characteristics under the same selector which means the description I put in there would be applied to all the interfaces within...
In that case, you have to use a different selector for each description you want, which I don't think is such a bad idea.
Having said that, you could start using (ugh! yuck!) Fabric > Access Policies >> Interfaces > Leaf Interfaces > Overrides but that is so ugly I wouldn't advise it. And that won't work in the new system either, so I'm not sure what happens during conversion if you have Overrides. I only mention this as a possibility because Cisco used to use Overrides to hold interface descriptions - it was VERY confusing (I wrote a whole blog post about it back in 2021)
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide