This statement is especially true when it comes to naming objects inside of ACI. Naming your ACI objects in a meaningful and thoughtful way will increase the supportability of your fabric and even help the fabric to become “self-documenting”. Having naming conventions that are haphazard, will have an equally negative impact.
To complicate matters, most ACI objects don’t allow you to re-name them; so if you wanted to re-name something, it would require you to delete the object and recreate it.
High-level naming conventions
Beautiful naming conventions are definitely in the eye of the beholder. You may find other delimiters or naming conventions more appropriate for your deployment. What I have outlined here are recommendations and naming conventions that I have used for countless customers. In almost all cases, customers will add a bit of uniqueness and modify the naming conventions to fit their needs. If I can convey two things in this post that are absolutely critical, I hope you remember this:
- Develop a naming convention for all of your named objects in ACI
- Ensure that the the naming convention makes it easier to operate your ACI Fabric.
Select a delimiter – My recommendation: The Underscore “_”.
The underscore is my delimiter of choice for separation of object suffix/prefix (i.e., web_epg, Leaf201_SwProf). Why the underscore? The underscore is NEVER used by the system (i.e., the fabric) when displaying XML or JSON configuration. By using the underscore character, when you download XML or JSON configuration, it will be much easier to differentiate where the system object names end, and where the human naming conventions for the objects begin.
<fvTenant dn="uni/tn-CloudMgmt_Tenant" name="CloudMgmt_Tenant">
CapitalizeSeparateWords for each of the objects to improve readability
Using a capitalization between words in your objects will help to make it more readable. Some examples of this:
- Leaf201_SwProf or lf201_SwProf
Leaf and Spine Numbering
Keep your leaf and spine numbering simple. A few rules of thumb for numbering:
- Have even and odd members of your VPCs (i.e., Leaf201 and Leaf202 make up a VPC pair). I have seen customers use Leaf201_203 as a VPC leaf pair, and because this is uncommon, it can really hamper troubleshooting in a network down situation because you have to get everyone on the same page in regard to numbering of your leaf switches.
- Spines = 101 -> 199. You will generally have far fewer spines. Keep them in the 100 range
- Leafs = 200 and above. For a single site, just use 200 and above. You can also use separate leaf numbers to separate leafs in different Pods.
- Pod1 Leafs = 200 –> 299
- Pod2 Leafs = 300 — > 399
Whatever the leaf numbering convention – still to the K.I.S.S. rule (Keep it simple s…..) If you have to spend more than 30 seconds explaining your spine and leaf numbering design to someone, chances are you’ve overthought it.
Tenant Naming Conventions
- VMM integration considerations – If you are taking advantage of VMM integration, your “Tenant | Application Profile | EPG” name will be displayed in Vcenter as portgroup names. Please keep in mind that less is more, in this case.
- Troubleshooting considerations – When you are troubleshooting on your leafs, the name of your routing table is the combination of your TenantName:VrfName. Choose wisely, or you will be typing (or copying and pasting) that name a lot.
Leaf201# show vrf all VRF-Name VRF-ID State Reason black-hole 3 Up -- Coast:main_vrf 6 Up -- common:default 5 Up -- management 2 Up -- overlay-1 4 Up -- Leaf201# show ip route vrf Coast:main_vrf IP Route Table for VRF "Coast:main_vrf" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%<string>' in via output denotes VRF <string> 18.104.22.168/24, ubest/mbest: 1/0, attached, direct, pervasive *via 10.0.192.66%overlay-1, [1/0], 3d16h, static 22.214.171.124/32, ubest/mbest: 1/0, attached, pervasive *via 126.96.36.199, vlan12, [1/0], 3d16h, local, local 188.8.131.52/24, ubest/mbest: 1/0, attached, direct, pervasive *via 10.0.192.66%overlay-1, [1/0], 3d16h, static 184.108.40.206/32, ubest/mbest: 1/0, attached, pervasive *via 220.127.116.11, vlan17, [1/0], 3d16h, local, local 18.104.22.168/32, ubest/mbest: 1/0 *via 192.168.50.251, vlan14, [90/128576], 3d16h, eigrp-default, internal
Keep the Tenant name as short and concise as possible. A short tenant name will ensure that if you need to reference the Tenant name when naming other objects (i.e., AAEPs, Vlan Pools), the shorter the better. For Tenants, I don’t recommend that you add a “_Tenant” suffix.
Customer Name: Enterprise Tenant Name: EntProd; EntTest; EntDev
(Tenant > Application Profiles)
Keep it short. Are you noticing a pattern? Again, for VMM considerations, application profiles are one of the best places to save on real estate. In general, I recommend a short application name + the “_AP” suffix.
ApplicationName + “_” + AP
Application Name: Microsoft SCOM Application Profile: Scom_AP, Scom_Ap, scom_ap
(Tenant > Application Profiles > Application EPGs)
ApplicationEPGName + “_” + EPG
Application EPGs – Below are a list of recommend sample EPG names.
Grouping(s): Web, Vlan 101, Management, PXE EPG Name(s): Web_EPG, Vl101_EPG, Mgmt_EPG, PXE_EPG Web_epg, Vl101_epg, Mgmt_EPG, PXE_epg
BD (Bridge Domains)
(Tenant > Networking > Bridge Domains)
If you are using a Network Centric Approach to EPG/BD creation, then re-using the EPG name for the BD makes perfect sense. It will also limit errors when you are associating the EPG to the correct Bridge Domain.
BridgeDomain + “_” + BD
Bridge Domain – Below are a list of recommend sample BD names.
Name(s): Web, Vlan 101, Management, PXE BD Name(s): Web_BD, Vl101_BD, Mgmt_BD, PXE_BD Web_bd, Vl101_bd, Mgmt_bd, PXE_bd
VRF (Routing Table)
(Tenant > Networking > VRFs)
For your VRF name, regardless of what you choose, remember to keep it short. Remember, during troubleshooting (on your leafs), the VRF name is the combination of your TenantName+VrfName.
VrfName + “_” + VRF
VRF (Routing table, VRF, or Context) – Below are a list of recommend sample VRF names.
VRF Name(s): Main_VRF, Prod_VRF, TenantX_VRF, DMZ_VRF Main_vrf, Prod_vrf, TenantX_vrf, DMZ_vrf
L3out (External Routed Domain)
(Tenant > Networking > External Routed Domains)
In general for L3outs, I like to mirror the VRF that will be referenced from the L3out. If you VRF name is “Prod_VRF”, then “Prod_L3out” leaves little doubt as to which VRF the L3out is attached. This type of naming also ensures that you don’t attach your L3out to the wrong VRF (assuming you have multiple).
L3outName + “_” + L3out
L3out – Below are a list of recommend sample L3out names.
L3out Name(s): Main_L3out, Prod_L3out, TenantX_L3out, DMZ_L3out
L3out Node Profiles
(Tenant > Networking > External Routed Domains > Node Profiles)
A Logical Node Profile for an L3Out defines which Leafs will be used. While you can certainly define multiple border leaf switches under a single node profile, I recommend using a node profile per switch to keep things simple and straight forward. Note – The Node Profile is not referenced outside of the L3out. The suffix is optional.
L3outNodeProfile + “_” + NodeProf
L3out Node Profile Name(s): Leaf201_NodeProf, Leaf202_NodeProf lf201_NodeProf, lf202_NodeProf
L3out Interface Profiles
(Tenant > Networking > External Routed Domains > Node Profiles > Interface Profiles)
Logical Interface Profiles for an L3Out defines which Leaf interfaces will be used. Note – The Interface Profile is not referenced outside of the L3out. The suffix is optional.
L3outNodeProfile + “_” + IntProf
L3out Node Profile Name(s): Leaf201_IntProf, Leaf202_IntProf lf201_IntProf, lf202_IntProf
(Tenant > Networking > External Routed Domains > L3out > Networks)
Your L3out EPG is the External Endpoint Group for your L3out. Policy for external routes (which you specify) will be applied here. It is recommended that you name the L3out EPG according to it’s function.
L3EPGName + “_” + L3EPG
L3out EPG – Below are a list of recommend sample L3out EPG names.
L3out EPG Name(s): DC_L3EPG, Internet_L3EPG, InetProxy_L3EPG, Campus_L3EPG, LabSubnets_L3EPG
(Tenant > Security Policies > Contracts) – in later versions of code (Tenant > Contracts)
Contracts define protocols that are allowed from EPG to EPG. Because we will be referencing the contract we configure in multiple places, I generally like to be as descriptive with the contract as possible. In addition, this is another place where a suffix can come in handy (especially if reading through XML or JSON)
ContractName + “_” + CT
Sample Contract names: web_http_CT, web_https_CT, webMultiple_CT, ssh_CT, mssql_CT
(Tenant > Security Policies > Filters) – in later versions of code (Tenant > Contracts > Filters)
FilterName + “_” + Filt
Filters are the entries that make up contract (think of these as ACE entries to an ACL). Filters can be single entries, or contain multiple entries, which can lead to confusion. In general, I typically recommend that customers use a single entry per filter, and ensure the naming leaves no question. Some samples are included below:
|Filter Name||Filter Purpose||Filter Entry Name|
|http_Filt||Http Filter using tcp80||tcp80|
|https_Filt||HTTPS Filter using tcp443||tcp443|
Fabric Access Policy Naming Conventions
VPC Pair naming
Fabric > Access Policies > Switch Policies > Virtual Port Channel default
Explicit VPC Protection Groups (this is just a large set of words that describe a VPC Pair). For the name, I would recommend using a short name for the leaf (and not necessarily the FDQN of the leaf switch). For the logical pair ID, use the first node ID of the VPC pair. This will ensure uniqueness and should be easy to follow.
LeafSwitchA + “_” + LeafSwitchB
Name: lf201_lf202 or Leaf201_Leaf202 Logical Pair ID: 201 Name: lf203_lf204 or Leaf203_Leaf204 Logical Pair ID: 203
Fabric > Access Policies > Interface Policies > Policies
PolicyConfigurationName + “_” + State (i.e., Enable|Disable, Active|Off|On)
Interface Policies are the individual configuration options, such as, enabling CDP, setting the interface speed to 10Gig, disabling LLDP, and so on. Although ACI has pre-configured defaults, I always setup my own policies for each feature to highlight if the feature is enabled or disabled. You’ll notice I capitalize the feature and use the delimiter of an “underscore” to separate the feature from its state. I do this for maximum readability. If you’d like a simple way of configuring interface policies quickly using Postman, check out this post.
LLDP_Enable LLDP_Disable CDP_Enable CDP_Disable MCP_Enable MCP_Disable LACP_Active LACP_On LACP_Off 10GigAuto 40GigAuto InheritAuto
Interface Policy Groups
Fabric > Access Policies > Interface Policies > Policy Groups
Interface Policy Groups allow you to group the configuration polices you’ve already created and apply those to a collection of switches and interfaces. For Interface Policy groups, I recommend a strategy that will allow you to document what it is you are attaching, and the type of policy group you are using (i.e., policy groups can be of type access, port-channel, or vpc).
Name of thing you are attaching to ACI + type of policy group.
APG = Access Port PC = Port-channel VPC = VPC port-channel
Sample Policy Groups: Pod1_UCSB_APG <<< UCSB policy group (access port) N7K1_VPC <<< N7k1 policy group (vpc port) Server1_APG <<< Server connection (access port) Server2_PC <<< Server connection (port-channel)
Switch Selectors (Profiles)
Fabric > Access Policies > Switch Policies > Policies
Switch Selectors allow you to select switches. You will then associate your switch selector with interface selectors. From a naming convention, there are typically 3 options I see in used. I generally gravitate to option #1 to keep it simple.
Leaf Name + “_” + SwSel suffix
Option #1 - Single Switch Selector for each switch; Option #2 - Combined Switch Selectors for VPC pairs; Option #3 - a combination of the option #1 and option #2. Sample Names Option #1 Lf201_SwSel or Leaf201_SwSel Lf202_SwSel or Leaf202_SwSel Option #2 Lf201_202_SwSel or Leaf201_202_SwSel Option #3 Lf201_SwSel or Leaf201_SwSel - and - Lf201_202_SwSel or Leaf201_202_SwSel
Interface Selectors (Profiles)
Fabric > Access Policies > Interface Policies > Profiles
Interface Profile Selectors allow you to select your interfaces. You will then associate your Interface Profiles with your access port selectors. You will select Interface Profile Selectors from your Switch Selector (Profile) configuration. From a naming convention, there are typically 3 options I see in used. I generally gravitate to option #1 to keep it simple.
Leaf Name + “_” + IntProf suffix
Option #1 - Single Interface Profile for each switch; Option #2 - Combined Interface Profile Selectors for VPC pairs; Option #3 - a combination of the option #1 and option #2. Sample Names Option #1 Lf201_IntProf or Leaf201_IntProf Lf202_IntProf or Leaf202_IntProf Option #2 Lf201_202_IntProf or Leaf201_202_IntProf Option #3 Lf201_IntProf or Leaf201_IntProf - and - Lf201_202_IntProf or Leaf201_202_IntProf
Access Port Selectors
Fabric > Access Policies > Interface Policies > Profiles > Interface Profile > Access Port Selectors
Access Port Selectors are objects in ACI that refer to the individual interfaces under your Interface Profiles. An interface profile will act as a folder for all of the access ports (i.e., 1-48).
I recommend that you create a list that reference all 48 ports. From there, you’ll be able to point your access port selector to your policy groups.
Sample Naming Convention eth1_1 eth1_2 eth1_3 .... eth1_48
This is an example of what I was referring to when I discussed using naming conventions to assist with a self documenting fabric; the access port selector is under Leaf201_IntProf (so I know which switch I am on), the access port selector name is eth1_48 (so I know exactly which port on Leaf201), and the Policy Group name is N7K1_VPC.
So – by just looking at the access port selector, I know that N7k1 is VPC connected off of Leaf201 eth1/48 (and if I’ve done my job correctly), I also know that the other leg of the VPC is connected off of Leaf202 eth1/48. << Self documenting.
Fabric > Access Policies > Global Settings > AAEP
AAEPs act as the glue between our Switch Interfaces and our Vlan Pools. It is a good practice to name them according to the resources that will be using them.
TenantName + “_” + AAEP
Sample AAEPs: EntProd_AAEP EntDev_AAEP EntTest_AAEP
Fabric > Access Policies > Pools > Vlan Pools
Vlan Pools are pools of vlan resources that can be utilized. There are two different types of pools, static, and dynamic. I typically recommend that you name them according to the resources that will be using them, the pool type (static or dynamic) suffix.
TenantName + “_” + TypeOfVlanPool + VLPool
Sample Vlan Pool Names: EntProd_StaticVLPool EntProd_DynVLPool EntDev_StaticVLPool EntDev_DynVLPool
Fabric > Access Policies > Physical and External Domains
I typically recommend that you name domains according to the resources that will be using them, the domain type (Physical, External, VMM) suffix.
TenantName + “_” + TypeOfDomain
Sample Domain Names: EntProd_PhysDom EntProd_ExtRoutedDom EntProd_VMMDom EntDev_PhysDom EntDev_ExtRoutedDom EntDev_VMMDom