Use Underscores as Delimiters

In constructing the distinguished name (DN) of an object, the ACI system uses hyphens to separate system-generated prefixes from suffixes that include user-defined naming strings. Because underscores are not used in any system-generated strings, they are ideal for use as delimiters in naming strings. In the following example, the system combines the prefix "tn-" with the user-defined tenant name "CloudMgmt_Tenant" to create the the DN. Because the naming string uses an underscore instead of a hyphen, it is easier to differentiate where the system object name component ends and where the user-defined component begins.

<fvTenant dn="uni/tn-CloudMgmt_Tenant" name="CloudMgmt_Tenant">

Note	Do not create an object whose name contains "__int_" or "__ui_" as those are reserved for internal usage and will be marked as read-only in the GUI.

Use Medial Capitals for Compound Words

When combining words without using delimiters, you can improve readability by using capitalization between words in object names. This practice is less formally known as "CamelCase" or "CapCase." The following examples show this style.

CloudMgmt_Tenant
TenantCiscoDocs_AAEP
Leaf201_SwitchProfile

Use Consistent Numbering for Ports and Leaf and Spine Switches

The following are recommendations for numbering:

• When numbering virtual port channels, use sequential odd and even number pairs. For example, Leaf201 and Leaf202 can make up a vPC pair.

• Number spine switches from 101 to 199. You are not likely to have more than 100 spines.

• Number leaf switches from 200 and above. For a single site, use 200 and above. When numbering leaf switches for more than one pod, begin each pod with a multiple of 100. For example:

  • Number Pod1 leaf switches from 200 to 299

  • Number Pod2 leaf switches from 300 to 399

Use Shorter Names If CLI Output Is Important

If you intend to use CLI command output for troubleshooting or for listing objects, consider that some CLI tables have fixed width columns. Longer names may require line-wrapping, which will reduce readability, as shown in this example in which the 'Vrf' column is limited to ten characters:

apic1# show vrf
 Tenant      Vrf         Consumed Contracts    Provided Contracts    Description
 ----------  ----------  --------------------  --------------------  ----------------------------------------
 common      Short_vrf   -                     -
 common      VeryLongNa  -                     -
             me_vrf
 common      copy        -                     -
 common      default     -                     -
 infra       ave-ctrl    -                     -
 infra       overlay-1   -                     -
 mgmt        inb         -                     -
 mgmt        oob         -                     -
apic1#

Tenant Names

Keep the tenant name as short and concise as possible. If you need to include the tenant name when naming other objects, such as VLAN Pools, a shorter name is better. Avoid adding “Tenant” to the name, either as a prefix or suffix. For example, for a customer named Example Corporation, consider names such as these:

ExampleProd
ExmplDev
ExCoTest

Application Profiles

Tenants > Tenant name > Application Profiles

Use a short application name along with a suffix of "_AP." For example, consider names such as these:

SampleApp_AP
SampleApp_Ap
SampleApp_ap

Application Endpoint Groups (EPGs)

Tenants > Tenant name > Application Profiles > AP name > Application EPGs

Use the application profile name along with a suffix of "_EPG." For example, consider names such as these:

Grouping:   Web, VLAN 101, Management, PXE
EPG names:  Web_EPG, Vl101_EPG, Mgmt_EPG, PXE_EPG
            Web_epg, Vl101_epg, Mgmt_epg, PXE_epg

Bridge Domains (BDs)

Tenants > Tenant name > Networking > Bridge Domains

If you use a network-centric approach to EPG and BD creation, we recommend using the EPG base name for the BD. This convention helps to prevent errors when associating the EPG to the correct bridge domain. Use the application profile name along with a suffix of "_BD." For example, consider names such as these:

Base names: Web, VLAN 101, Management, PXE
EPG names:  Web_BD, Vl101_BD, Mgmt_BD, PXE_BD
            Web_bd, Vl101_bd, Mgmt_bd, PXE_bd

VRF (Routing Table)

Tenants > Tenant name > Networking > VRFs

Use the application profile name along with a suffix of "_VRF." The VRF name will be combined with others in naming objects such as your routing table, which is the combination of your tenant name and VRF name. Consider names such as these:

VRF names:  Main_VRF, Prod_VRF, TenantX_VRF, DMZ_VRF
            Main_vrf, Prod_vrf, TenantX_vrf, DMZ_vrf

L3Out (External Routed Network)

Tenants > Tenant name > Networking > External Routed Networks

We recommend naming the external routed network (L3Out) using the base name of the VRF that will be referenced from the L3Out. If your VRF name is “Prod_VRF”, an L3Out name of “Prod_L3Out” is a clear indication as to which VRF the L3Out is attached. This convention helps to prevent you from attaching your L3Out to the wrong VRF when multiple VRFs are present. Use the application profile name along with a suffix of "_L3Out." For example, consider names such as these:

Main_L3Out
Prod_L3Out
TenantX_L3Out
DMZ_L3Out

L3Out Node Profiles

Tenants > Tenant name > Networking > External Routed Networks > Node Profiles

A logical node profile for an L3Out specifies which leaf switch or switches are used. While it is possible to specify multiple border leaf switches under a single node profile, we recommend specifying a single switch per node profile. Use the switch name along with a suffix of "_NodeProf." For example, consider names such as these:

Leaf201_NodeProf, Leaf202_NodeProf
lf201_NodeProf, lf202_NodeProf

Note	The node profile is not referenced outside of the L3Out. The suffix is optional.

L3Out Interface Profiles

Tenants > Tenant name > Networking > External Routed Networks > Node Profiles > Interface Profiles

A logical interface profile for an L3Out specifies which leaf interfaces are used. Use the switch name along with a suffix of "_IntProf." For example, consider names such as these:

Leaf201_IntProf, Leaf202_IntProf
lf201_IntProf, lf202_IntProf

Note	The interface profile is not referenced outside of the L3Out. The suffix is optional.

L3Out EPG

Tenants > Tenant name > Networking > External Routed Networks > L3out name > Networks

An L3Out EPG (or L3InstP) is the external endpoint group for your L3Out. Your policy for external routes is applied to the L3Out EPG. We recommended naming the L3Out EPG according to its function. Use the function name along with a suffix of "_L3EPG." For example, consider names such as these:

DC_L3EPG
Internet_L3EPG
InetProxy_L3EPG
Campus_L3EPG
LabSubnets_L3EPG

Contracts

Tenant > Security Policies > Contracts (in earlier releases)
Tenants > Tenant name > Contracts

Contracts define protocols that are allowed from EPG to EPG. Because you may be referencing the contract in multiple places, give the contract as descriptive a name as possible. Use the descriptive name along with a suffix of "_CT." For example, consider names such as these:

web_http_CT
web_https_CT
webMultiple_CT
ssh_CT, mssql_CT

Filters

Tenant > Security Policies > Filters (in earlier releases)
Tenants > Tenant name > Contracts > Filters

Filters are the rule entries that make up a contract, similar to ACE entries in an ACL. Although filters can contain single entries or multiple entries, we recommend using a single entry per filter in most cases. Give the filter an unambiguous name along with a suffix of "_Filt." For example, consider names such as these:

VPC Pairs

Fabric > Access Policies > Policies > Switch > Virtual Port Channel default

A Virtual Port Channel (vPC) pair, also known as an explicit vPC protection group, needs both a name and a logical pair ID. For the vPC pair name, use the short names of the two leaf switches, joined by an underscore. For the logical pair ID, use the first node ID of the vPC pair. For example, consider names such as these:

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

An interface policy contains individual configuration settings, such as enabling CDP, setting the interface speed, and disabling LLDP on the interface. In the absence of a policy, ACI uses a default setting for a feature, but we recommend that you explicitly define a policy for each feature. The naming of your policy can combine the feature and the state of the feature to clearly indicate the configuration. For example, the policy name could include the capitalized feature name, joined with the selected state using an underscore delimiter. For example, consider names such as these:

LLDP_Enable
LLDP_Disable
CDP_Enable
CDP_Disable
LACP_Active
LACP_On
LACP_Off
40GigAuto
InheritAuto

Interface Policy Groups

Fabric > Access Policies > Policies > Interface > Leaf Interfaces > Policy Groups

An interface policy group allows you to combine several configuration polices and apply them to a collection of switches and interfaces. An effective interface policy group name combines a short description of the entity being attached to the ACI fabric and the type of the interface policy group, such as leaf access port, port-channel (PC), or vPC port. For example, consider names such as these:

Pod1_UCSB_APG  <<< UCSB, where policy group type is access port (APG)
Server2_PC     <<< server connection, where policy group type is port-channel (PC)
N7K1_VPC       <<< Nexus7000 switch, where policy group type is vPC port (VPC)

Switch Selectors (Profiles)

Fabric > Access Policies > Switches > Leaf Switches > Profiles

A switch selector allows you to select switches. You will then associate your switch selector with interface selectors. Choose from the three naming convention options shown in the example below, with the simplest option first. Use a short leaf switch name along with a suffix of "_SwSel." For example, consider names such as these:

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. Choose from the three naming convention options shown in the example below, with the simplest option first. Use a short leaf switch name along with a suffix of "_IntProf." For example, consider names such as these:

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 > Interface Selector

An access port selector is an object that refers to the individual interfaces under your interface profile. An interface profile acts as a folder for all of the access ports, such as Ethernet ports 1 through 48, for example.

We recommend creating a list that references each port. From there, you’ll be able to point your access port selector to your policy groups. For the access ports, consider a set of names such as these:

eth1_1
eth1_2
eth1_3
....
eth1_48

The access port selectors are added to an interface profile, which can be added to a policy group. When the naming conventions are followed, the physical fabric connections are clearly documented by the descriptive object names. For example, the following policy group, interface profile, and access port selector names clearly describe a virtual port channel (vPC) that combines Ethernet ports eth1/48 on each of two leaf switches, 201 and 202:

policy group -> interface profile -> access port selector  

N7K1_VPC -> Leaf201_IntProf -> eth1_48
N7K1_VPC -> Leaf202_IntProf -> eth1_48

Attachable Access Entity Profiles (AAEPs)

Fabric > Access Policies > Policies > Global > AAEP

Use a short profile name along with a suffix of "_AAEP." For example, consider names such as these:

EntProd_AAEP
EntDev_AAEP
EntTest_AAEP

VLAN Pools

Fabric > Access Policies > Pools > VLAN

Name a VLAN pool according to the resource that will draw from it. Add a suffix indicating the pool type, which can be either static or dynamic. For example, consider names such as these:

EntProd_StaticVLPool
EntProd_DynVLPool
EntDev_StaticVLPool
EntDev_DynVLPool

Domains

Fabric > Access Policies > Physical and External Domains

Name a domain according to the resource that will use it. Add a suffix indicating the domain type, such as Physical, External, or VMM. For example, consider names such as these:

EntProd_PhysDom
EntProd_ExtRoutedDom
EntProd_VMMDom
EntDev_PhysDom
EntDev_ExtRoutedDom
EntDev_VMMDom