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:

1. Develop a naming convention for all of your named objects in ACI
2. 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
• TenantX_AAEP
• TenantX_VlanPoolStatic
• V201_EPG
• ScomWeb_EPG
• ScomWeb_BD

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>

100.1.1.0/24, ubest/mbest: 1/0, attached, direct, pervasive
 *via 10.0.192.66%overlay-1, [1/0], 3d16h, static
100.1.1.1/32, ubest/mbest: 1/0, attached, pervasive
 *via 100.1.1.1, vlan12, [1/0], 3d16h, local, local
101.1.1.0/24, ubest/mbest: 1/0, attached, direct, pervasive
 *via 10.0.192.66%overlay-1, [1/0], 3d16h, static
101.1.1.1/32, ubest/mbest: 1/0, attached, pervasive
 *via 101.1.1.1, vlan17, [1/0], 3d16h, local, local
111.111.111.111/32, ubest/mbest: 1/0
 *via 192.168.50.251, vlan14, [90/128576], 3d16h, eigrp-default, internal

Tenant Names

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

Application Profiles

(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

Application EPGs

(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 Networks > 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 Networks > 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

L3out EPG

(Tenant > Networking > External Routed Networks > 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

Contracts

(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

Filter

(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
icmp_Filt	ICMP	icmp

Fabric Access Policy Naming Conventions

VPC Pair naming

Fabric > Access Policies > Policies > Switch > 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

Interface Policies

Fabric > Access Policies > Policies > Interface

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 > Interfaces > Leaf Interfaces > 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 > Switches > Leaf Switches > Profiles

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 > Interfaces > Leaf Interfaces > 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 > Interfaces > Leaf Interfaces > Profiles > PROFILE_NAME > ACCESS_PORT_SELECTOR

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.

AAEPs

Fabric > Access Policies > Policies > Global > 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

Vlan Pools

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

Domains

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