Grouping -best practice

[Curtis Parish]

We are in the middle of an ACI rollout and have a question about how people group things.   We have an (outside) engineer that has created a separate  Leaf Policy Group for nearly  every single interface and named it for the attached entity profile.  Needless to say, the list of policies has gotten quite long.  I am arguing that it defeats the purpose of groups and greatly complicates things  and he is saying that it simplifies things because he has one long string of policies where everything is named the same from contract to port.  

Suggestions before I go though and start simplifying this?  

[Claudia de Luna]

Hi Curtis,

I typically start out with a "generic" set of policy groups 

Access10GIntPolGrp

Access1GIntPolGrp

Those will get applied to Interface Profiles.

For example if I'm putting 5 compute hosts on Leafs 1 and 2 e1/10-14 and all the hosts have 1Gig Uplinks I'll create 

CompHost-e1-10-e1-14-IntProf (or CompHost-P10-14-IntProf)

---> Within this construct I will configure CompHost-e1-10-e1-14-IntSel for interfaces 1/10-14 and be tied to Access1GIntPolGrp

OK so now I have my Access type interfaces with the settings I want for links speed, cdp, lldp, mcp etc..and AEP ("allowed vlans")

Then I attach that to my Leaf01-SwProf construct and my Leaf02-SwProf construct

Let say I have two leafs (202 and 203) totally dedicated to compute hosts which are all going to be 10Gig Access uplinks probably trunked to several EPGs.  Then it is very simple:

I have CompHostP1-P48-IntProf

--> CompHostP1-P48-IntSel (e1/1-48) tied to Access10GIntPolGrp to define the characteristics I want on ports 1-48

Then that is attached to Leaf202-SwProf and Leaf203-SwProf.

when you add compute Leafs 204 and 205 and those hosts are uplinked in this way all you have to do is apply your existing CompHostP1-P48-IntProf to your two new leaf Switch Profiles.

If your connections are LACP or port channel based then you will need more discreet Interface Profiles, one for each port/switch "bundle".

So in general I'll have just a few Access type of Interface Policy Groups

One fore every vpc or direct port channel I need to configure so if I have 4 hosts with 2x10G vpcs I'll have 4 of those constructs and I like to put the uplink type in the name so I know right away from the name what I am dealing with.

So in this case, lets say I have a host with two 10G uplinks to Leaf 201 and 202 on e1/9

CompHost-vPC-L201-L202-e1-9-IntProf 

---> Within this construct I will configure  CompHost-vPC-L201-L202-e1-9-IntSel for interface 1/9 and be tied to CompHost-vPC-L201-L202-e1-9-IntPolGrp (Note that this one is very specific on what it is - vpc- and what interfaces are used - e1/9 and even what leafs - its a vpc it needs to be that specific)

OK so now I have my vpc type interface with the settings I want for links speed, cdp, lldp, mcp etc..and with the correct port channeling attributes (LACP Active for example in this case).

Then I attach that to my Leaf01-02-SwProf construct forming a vPC across both those leaf switches on interface e1/9 on each switch.

Hope this isnt too confusing!

The Interface Policy Groups define the nature of whatever interfaces you apply them to so unless very single interface is different or in a vPC you should not really need one for every interface.

Those are then applied to Interface profiles which basically tie those interface characteristics so some interface (not switch).

Then finally you do apply that set of characteristics on some interface to a specific switch or set of switches (vpc domain) so that you get those characteristics, on those interfaces on those switches.

General Characteristics (IntPolGrp)

• cdp run
• lldp run
• port speed 1000
• channel-group <TBD> mode active

Tied to interface (but not to a switch yet) (IntProf)

• int e1/9
• • cdp run
  • lldp run
  • port speed 1000
  • channel-group <TBD> mode active

Tied to a vpc domain switch pair (SwProf)

• Leaf201-202-SwProf

Now you can tie your LACP Active vPC uplink from your host to an EPG via a static path binding (or L2Out) with whatever encapsulation ("vlan") you need as long as your original IntPolGrp is tied to an AEP that allows that vlan.

Hope that helps a bit!

[Curtis Parish]

Thank you for your detailed description.   Your practice seems to be between his and mine in that you are less detailed than he is and more detailed than I might be.  This was the same engineer that created a separate firmware and maintenance group for each leaf. 

[Claudia de Luna]

I create Odd and Even Maintenance groups and so far that has served me well.

As long connections are redundant you can have a completely hitless fabric upgrade, first you upgrade the odd devices and then the even.

One of the beauties of ACI or any controller based fabric really is that you are out of the single device management business. Take advantage of it!!

Check out Robert's tips...they will serve you well!

[Curtis Parish]

I immediately deleted everything he had done with the firmware and maintenance groups and created even and odd groups but it does make me question everything else now. 

[Robert Burns]

lol.  There's always going to way to do something, and then a "better" way in ACI.  Very flexible, but as you've noticed, it comes down to operations & management going forward.  

Firmware policies are simple.  As cdeluna states you only need a single Firmware Group (unless you have a very unique reason to run different versions on some switches than others - and this is not recommended/supported for any length of time), and maybe two Maintenance Groups. I use exactly the same approach with odd/even.  I have seen some people even go as far as doing odd/even (leafs) then odd/even (spines), but it makes an upgrade twice as long.  Assuming you do your diligence & check fabric health prior to upgrade, and have all hosts dual connected to odd/even switches, you shouldn't need anything more complicated.

Robert

[Claudia de Luna]

LOL!  Your inclination to question is never a bad thing.  As Robert said, you need to nail down your naming convention at the very start or it gets ugly fast.  (Remember you can't rename)  The naming convention I use for all my clients is very similar to Roberts so you have two naming convention examples that are very similar from two independent sources that you can tailor to fit your ACI build out.  Good luck!

[Robert Burns]

Personally, I'm not a fan of creating a single policy per interface.  Agreed this completely defeats the purpose of policy re-usability.   What I prefer to do instead is create the Leaf Interface Profiles based on the connected device.

Interface Policies - The individual Policies that will be group into a Policy Group. 

Pro Tip: Never change the default policy, always create new policies if you want to change default behavior.  Personally I avoid ever using Default policies all together. Instead I create specific policies named according to what the function.  Ie. LLDP is Enabled by default.  Instead of using the default LLDP policy, I create a new LLDP policies called "LLDP-Enabled" and would use that when needed.  Similarly I have a Link-Level Policy called "10G-auto", which as you can guess enables interfaces for 10G with auto negotiation enabled.

Policy Group - With these you have to be a little more careful. You can re-use PolGrps in some cases, but not others.  Ex. When creating a VPC, the membership is based on the interfaces being assigned to the same PolicyGrp.  This pretty much limits which Interfaces you can assign to it.  So if you have 10x hosts dual connected to the fabric, that's going to require 10x [VPC] Policy Groups.  Other Policy groups for Access ports can easily be recycled.  You might have a PolGrp called "Windows-BareMetal" which would essentially act as your interface template for any windows host.  This might include the Link Speed defined, CDP/LLDP properties, Port Security etc.  This example of a policy could be re-used for all Windows hosts.  Keep in mind in this example, none of the interfaces to any one host are channeled. 

Interface Profiles - Contain Interface selectors and tie them to an Interface Policy Group.  For this, I like to name my interface Profiles based on "what" they are connected to.  For Example, I have a Leaf Interface profile called "UCSM-IntProf", which has two Selectors, one called "UCS-A-Ints" which maps to a VPC policy Group called "UCS-A-VPC-PolGrp", and another Selector called "UCS-B-Ints" which maps to a VPC policy Group called "UCS-B-VPC-PolGrp".   Lastly, my single Interface Profile "UCSM-IntProf" is assigned to a Switch selector containing the two Leaf VPC peers.

I've seen many people use Interface #'s as the policy name, but it really defeats the purpose of having a logical layer you can take advantage of.  This really makes  troubleshooting a pain when you don't remember "what" is connected "where". 

It's critically important to start your ACI design on the right foot.  Sure you can always go back and re-create policies, but once you decide on a system that makes sense, its far easier to manage going forward. 

I'm also attaching a sample Naming Convention that I've personally used in my lab.  You're free to use it or make your own, but I do recommend setting one up early on.

Regards,

Robert

[Curtis Parish]

Thanks. I like your  descriptions and naming convention.  I wish ACI would allow an object to be renamed because it would be very nice to have "policy group" be a part of the name.  It would eliminate a lot of confusion in our meetings that are held via WebEx. 

[Claudia de Luna]

You can, Curtis.  Part of the naming convention that both Robert and I use includes a "suffix" for that the thing is:

xxxx-IntPolGrp

xxx-IntProf

xxx-IntSel

etc...