Site icon

ACI Fabric Access Policies for CCIEs

ACI is different. I know, this may come as a shock to any CCIE or Network Engineer who may have wondered into the APIC GUI to configure an interface, only to be met with terms like, “Physical Domain”, or “AAEP”. But, it is different, and different, I would argue, for more good than bad.

And, after working for ACI for almost 4 years, there are two things of which I am certain:

  1. There is purpose it’s design (the object model design)
  2. It can be very confusing to folks new to ACI, even seasoned CCIEs

For Point #1 – I’ll say this in defense of the Object Model; the ACI Object Model was designed with automation and orchestration in mind; the infinite flexibility you see today allows ACI Fabrics to be used from anything from a Network-Centric Datacenter fabric used primarily by Network Engineers, to a fully automated private Cloud, automated and configured by Openstack. Same Fabric, Same Switches, Same Object Model, but two vastly different purposes.

For Point #2 – It is confusing. Especially to new folks who aren’t used to the GUI. I acknowledge wholeheartedly that it can frustrating, at times, to understand the Object Model, and the GUI. From experience, this is overcome by repetition of configuration and building muscle memory, and by leaning on those who have gone before us and understand it better than we do 😉

With this post, I hope to de-mystify the infamous Fabric Access Policy section for CCIEs, Network Engineers, and anyone new to ACI.

The picture below gives a graphical “configuration” of a VPC, and the ACI Policy objects you would touch to bring the VPC to life.

Finally, an important reminder; When working in the Fabric > Access Section of the GUI to configure your Switch Interfaces to allow Vlans to go across, there is a linkage of objects that must be maintained. Failure to do so will result in the Vlan not being available in your User Tenant. Use the diagram below as a reference of the most important Fabric Access Objects.

Exit mobile version