Cisco ACI Object Naming and Numbering: Best Practices

Cisco ACI Object Naming and Numbering: Best Practices 2

General Recommendations 2
Tenant Naming Conventions 3
Fabric Access Policy Naming Conventions 6
Revised: September 30, 2020

Cisco ACI Object Naming and Numbering: Best Practices

Cisco Application Centric Infrastructure (ACI) is based upon the managed object (MO) model, where each object requires a name.
A clear and consistent naming convention is therefore essential to aid manageability and troubleshooting. Any change in naming
convention for any MO such as profiles or policies requires disruption. We strongly recommended that you plan ahead and define
the policy naming convention before deploying the ACI fabric to ensure that all policies are named consistently.
• Develop a naming convention for all of your named objects in ACI
• Ensure that the naming convention makes it easier to operate your ACI Fabric

General Recommendations
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

2
 • 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 Naming Conventions

In naming your Tenant and its associated objects, balance the readability of the object name against the inconvenience of possibly
very long compound object names. For example, in VMware vCenter, APIC automatically creates a port group name that is a
concatenation of the tenant name, the application profile name, and the EPG name. This example illustrates a result when maximizing
readability for each object.

ExampleCorpTenant|ExampleCorpApplicationProfileForScom|ExampleCorp_ScomWeb_EPG

This example uses some abbreviations, but makes a more readable compound name.

ExampleCorp|ExampleCoAP|ExampleCo_ScomWeb_EPG

Similarly, troubleshooting a leaf switch may involve frequently typing or pasting the name of your routing table, which is the
combination of your tenant name and VRF name.

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:

3
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

4
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:

5
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:

Filter Name Filter Purpose Filter Entry Name

http_Filt HTTP filter using TCP port 80 tcp80

https_Filt HTTPS filter using TCP port 443 tcp443

icmp_Filt ICMP icmp

Fabric Access Policy Naming Conventions

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

6
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

7
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

8
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

9
© 2019–2020 Cisco Systems, Inc. All rights reserved.
 Americas Headquarters Asia Pacific Headquarters Europe Headquarters
Cisco Systems, Inc. CiscoSystems(USA)Pte.Ltd. CiscoSystemsInternationalBV
San Jose, CA 95134-1706 Singapore Amsterdam,TheNetherlands
USA

Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers are listed on the
Cisco Website at www.cisco.com/go/offices.