General Naming of ACI Policies
It is preferred to include an underscore “_” followed by a descriptive suffix within your naming convention. This is preferred because with Cisco ACI, down the line, you will most likely leverage some type of automation tool like Postman or Ansible where you will be manipulating variables in order to easily deploy ACI Tenant and/or Fabric Access Policies programmatically.
Use of underscore with suffix
| Fabric Access Policy Type |
Suffix | Result |
| <AEP-Type> | _aep | <AEP-Type>_aep |
| <Physical-Domain-Name> | _phydom | <Physical-Domain-Name>_phydom |
| <VLAN-Pool-Type> | _pool | <VLAN-Pool-Type>_pool |
| <Interface-Policy-Group> | _polgrp | <Interface-Policy-Group>_polgrp |
| <Interface-Profile> | _intprof | <Interface-Profile>_intprof |
| <Switch-Profile> | _swprof | <Switch-Profile>_swprof |
Ease of Management
Organizing your ACI Fabric Access Policies and naming them accordingly will make it easier in the long run when operating Cisco ACI. Grouping endpoint types such as Baremetal servers and Virtual servers separately will greatly assist when you must conduct searches in ACI and want to more easily identify if the endpoint is a virtualized host or a Baremetal operating system. One may disagree and argue that it is easier to clump all endpoint types together under the same AEP and physical domain but in the long run, it will be a lot more difficult to branch out to hybrid or application-centric designs.