Cisco ACI Naming Standards


Cisco ACI Naming Standards

The Naming of Cats is a difficult matter,
It isn’t just one of your holiday games;

When you notice a cat in profound meditation,
The reason, I tell you, is always the same:
His mind is engaged in a rapt contemplation
Of the thought, of the thought, of the thought of his name:
His ineffable effable
Effanineffable
Deep and inscrutable singular Name.

T.S. Elliot. The Naming of Cats

Have you become frustrated at the multiple names Cisco uses for the same object within the ACI GUI? Have you clicked on a link that promised to show a list of Interface Selector Profiles only to be shown a list of Leaf Interface Profiles instead? Have you ever wondered what a L3 Out object is, when there no facility to create an object called L3 Out?
I managed to muddle my way around the GUI and discover that L3Outs were actually External Layer 3 Networks and solve many other ambiguities by developing and adopting a consistent naming standard.

In a nutshell…

Consistent and structured naming of objects in Cisco’s ACI environment can help you greatly when learning how the different objects relate to each other.  This article explains the logic I use to name objects in Cisco ACI. In summary, these are:

Rule#1: Suffixes

If the object will ever be referred to by another object, make sure you name the object with a hyphen an underscore followed by a suffix that describes the item. For example:
Leaf101_IntProf describes the Interface Profile for Leaf switch 101,
WebServers_EPG describes an End Point Group.

[Edit: 2019-03-09 I’ve changed my mind about using hyphens in names. My new approach if to NOT use hyphens at all, because you will find the names you use appended to system created names throughout the MIT (Management Information Tree). And when you find them, they will be separated by a hyphen. So a tenant called TenantX will be located under uni/tn-TenantX in the Object Store Browser. If you use use hyphens in your name, there will be times when it is hard to distinguish where the system added hyphenation ends, and your naming hypen begins.  So as of today, I’ve replaced all hyphens with the underscore character.]

Of course the problem when you first start out is that you don’t know what objects are going to be referred to in another drop-down list somewhere. That’s why you will want to use this guide.

Rule#2: Prefixes

If the object is a infrastructure object intended for use by a single tenant, prefix the object with a reference to that Tenant followed by a colon. For example, TenantX:StaticVLANs_VLAN.Pool describes a VLAN Pool intended for use by Tenant TenantX and Common:Telstra_ExtL3Dom describes an External Layer 3 Domain used by the common tenant. In a similar vein, infrastructure objects shared by multiple tenants should be prefixed with Shared:, such as Shared:WAN.Links_AEP which describes an Attachable Access Entity Profile (AAEP) that multiple Tenants may share.

Rule#2 corollary:  Global infrastructure objects

If the object can be used by all tenants, omit the prefix.  Disable_CDP is the only CDP Interface Policy you’ll ever need to disable CDP – no need to create multiple duplicates.  Similarly, you’ll only ever need one Leaf Switch Profile for leaf 101, so call it Leaf101_LeafProf, but if you think it helps, Global:L101_LeafProf or Shared:L101_LeafProf would be acceptable.

Rule#3: Punctuation

I use TitleText style to concatenate words in names, but if an acronym is involved, I use a period as a  separator to make VLAN.Pool more readable than VLANPool. I reserve the use of the underscore character for use only as part of the descriptor suffix, but will use the colon character both as a separator for the prefix and as a replacement for a slash character when naming port numbers, such as TenantX:L101..102:1:35_VPCIPG which also shows my preference for using double periods to indicate a range.  Hopefully the above example obviously describes a VPC Interface Policy Group for TenantX on port 1/35 of both Leaf101 and Leaf102.

Legal names, characters and separators

There are some characters that you can’t use in names. There are sixty-six legal characters. They are all alphanumeric characters (upper and lowercase) and the four separator characters .:-_ (period, colon, hyphen and underscore).  In fact, you could indeed call an object ...:-_-:... if you wished. Numeric names are OK too, so a Leaf Switch Selector could indeed be called 101 or even 101..102. But keep in mind the following:

  1. you can’t use the space character,
  2. the underscore character is used as the separator for objects requiring a suffix (using my conventions)
  3. the colon character is used as the separator for objects requiring a prefix (using my conventions)
  4. Don’t EVER use the hyphen character in a name – leave that character to the system to help you identify system created names based on your names.

With the ground rules laid, let me continue with some more specific detail.  I will approach this in three sections.

  • Firstly, I’ll discuss objects defined in the Tenant space, where you will discover exactly what a L3Out really is.
  • Next, I’ll look at the Access-Policy Chain which the infrastructure administrator will define under the Fabric > Access Policies and VM Networking menus, and
  • Finally, I’ll fill you in on a bit of the background to this article and tidy up any loose ends.

Names for objects defined in Tenants

I guess there is no better start than the name of the Tenant itself.

Tenants > Add Tenant

The name of your tenant need to be as short as possible. If the Tenant is a listed company, consider using the stock symbol – CSCO rather than Cisco Systems.  This is because (as explained above), you will often want to use the Tenant name in naming Access Policies. Another consideration (if you are hosting multiple Tenants) is the real estate on the Submenu for Tenants – which lists more names if the names are short! And similarly, in many drop-down menus, you will see the name of the Tenant included in the list. Shorter the better!
Here are my examples:

Recommended Tenant Name Purpose
common Pre-defined. You can’t change this.
CSCO If your Tenant has a stock symbol, use it
NNK Abbreviated form of Nectar Network Knowledge Pty Ltd
UQ.Admin University of Queensland Administration Tenant
UQ.Dev University of Queensland Development group Tenant

Tenants > Tenant TenantName > Networking > VRFs

Give VRDs a _VRF suffix, although you may prefer _Ctx for Context (VRFs are sometimes referred to as contexts, and before v1.2, VRFs were known as Private Networks).

Here are my examples:

Recommended Private Network Name Purpose
Dev_VRF VRF to separate the Development team
Production_VRF Main routing VRF
DMZ_VRF You can use VRFs to implement a DMZ type approach

Tenants > Tenant TenantName > Networking > Bridge Domains

Bridge Domains get a name describing the Bridge Domain and a _BD suffix. If the BD is being mapped to a VLAN, the existing VLAN name may be appropriate.

Here are my examples:

Recommended Bridge Domain Name Purpose
WebServer_BD Bridge Domain for the Web Servers server farm
NAS_BD Bridge Domain for the Network Attached Storage VLAN
DevTest_BD Bridge Domain for testing
VLAN100_BD Bridge Domain used to migrate VLAN 100. Use with care, because you may find that other VLANs also end up using this BD


Tenants > Tenant TenantName > Application Profiles

Application Profiles get a name describing the Application and a _AP suffix.

Here are my examples:

Recommended Application Profile Name Purpose
SAP_AP Application Profile for SAP
Webshop_AP Application Profile for your Webshop Application
OurAppDev_AP Application Profile for an application in development

Tenants > Tenant TenantName > Application Profiles > Application EPGs

End Point Groups get a name describing the type of servers that are represented in the group and a _EPG suffix.

Here are my examples:

Recommended EPG Name Purpose
SAP.Servers_EPG Application Servers for SAP
WebServers_EPG EPG for the Web servers server farm
SQL_EPG EPG for SQL DataBase servers

Tenants > Tenant TenantName > Security Policies > Filters

Filters can be used multiple times within a Tenant, and indeed filters in the common Tenant can be used by any Tenant, so I recommend defining all filters in the common Tenant. But the most confusing aspect about filters is that a filter can define a single TCP port number, or could consist of many entries with multiple protocols and even ranges of port numbers. My suggestion is to keep filters to specific protocol/port numbers, or at the very most a collection of closely related port numbers.
Inside the filter, you will also need to name the filter entries.  My convention is to name the filter entries based on the protocol/port number, and to give the filter a _Fltr suffix.
Here are my examples:

Recommended Filter Name Purpose Recommended Filter Entry Name(s)
HTTP_Fltr Filter for HTTP traffic TCP80
HTTPS_Fltr Filter for HTTPS traffic TCP443
AD_Fltr Filter for Active Directory Protocols TCP1025..5000
TCP49152..65535
TCP389
UDP389
TCP636
… etc (See MS website)
ICMP_Fltr Filter for ICMP traffic ICMP

Tenants > Tenant TenantName > Security Policies > Contracts

Contracts define the collection of protocols that are required for an EPG to provide a service to another EPG.  Therefore, as well as having a _Ct suffix, I always include the word Services (or Svcs) in the name of the contract to indicate which EPG is the provider of the service.  Contracts also contain Subjects, and unless there is a reason to have more than one Subject in a Contract, I duplicate the contract name for the Subject name, except with a _Subj extension.

Here are my examples:

Recommended Contract Name Purpose Recommended Subject Name(s)
WebServices_Ct Contract to be provided by the WebServes_EPG WebServices_Subj
WebServices_Ct Contract to be provided by the WebServes_EPG, but with TCP443
traffic to be treated differently to TCP80 traffic
HTTP_Subj
HTTPS_Subj
AD.Svcs_Ct Contract for Active Directory Services AD.Svcs_Subj

Tenants > Tenant TenantName > Networking > External Bridged Networks

Firstly, I’d recommend you never use External Bridged Networks (colloquially become known as a L2 Outs), they don’t add any value over mapping a VLAN to an Application EPG and are harder to configure.  But that said, if you had to use one, here is how I’d name it

An External Bridged Network is a “Layer 2 Outside” network. Consequently, a suffix of _L2Out is a great abbreviation.  But there is a more important association that also has a significant bearing on the name. Each L2 Out is associated with a single VLAN ID.  So my advice is to name the L2 Out after the VLAN – either by ID or VLAN Name if appropriate. Here are my examples:

Here are my suggestions.

Recommended External Bridged Network (L2 Out) Name Purpose
VLAN2000_L2Out L2 Out for VLAN 2000
NAS.VLAN_L2Out L2 Out for Network Attached Storage VLAN

Tenants > Tenant TenantName > Networking > External Bridged Networks > VLANx_L2.Out > Networks

A L2 Out also needs a child object that can be used to link to Contracts.  This object is referred to in the GUI as a Network but I prefer the concept of referring to is as a L2 EPG, because the whole ACI policy philosophy is centred around the EPG-Contract association.  And since this L2 EPG is going to allow traffic to and from a particular external VLAN, it is appropriate to name the entity with a name mimicking its parent and a _L2EPG suffix.

Here are my examples:

Recommended (L2 Out)  Network Name Purpose
VLAN2000_L2EPG L2 EPG for VLAN2000_L2Out
NAS.VLAN_L2EPG L2 EPG for NAS.VLAN_L2Out
2020_L2EPG L2 EPG for 2020_L2.Out


 Tenants > Tenant TenantName > Networking > External Routed Networks

Similar to the L2 Out idea, an External Routed Network is known as a L3 Out – and indeed even referred to as such under a Bridge Domain’s configuration. The essential use of the “Layer 3 Outside” network is to give a VRF the ability to:

  1. advertise public subnets on behalf of linked Bridge Domains using a particular protocol (OSPF/BGP/EIGRP), and
  2. process incoming routes for that protocol to be added to the VRF routing table.  In other words, it provides a routing service for a VRF for a particular protocol(s).

So it makes sense to name a L3 Out based on VRF and/or routing protocol and give it a _L3Out suffix.

Here are my examples:

Recommended External Routed (L3 Out) Network Name Alternative Form Purpose
DevVRF_L3Out Dev_L3.Out OSPF & BGP L3 Out for the Development VRF
ProductionVRF_EIGRP.L3Out Production_EIGRP.L3.Out EIGRP L3 Out for the Production VRF
ProductionVRF_BGP.L3Out Production_BGP.L3.Out BGP L3 Out for the Production VRF
DMZ.VRF_OSPF.L3Out DMZ_L3.Out L3 Out for DMZ VRF

 Tenants > Tenant TenantName > Networking > External Routed Networks > L3OutName_L3Out > Logical Node Profiles

When you create a Logical Node Profile for a L3Out you are defining which Leaf Switches are going to become external routers – PE routers in terms of how MP_BGP works in ACI.  The Node Profile name will not be seen outside the L3Out, so adding a the suffix is not necessary, but you may feel more comfortable using it. One thing to remember when creating Logical Node profiles for multiple Nodes within the same L3 Out is that it makes no difference whether you create one Node Profile per Leaf, or include all Nodes (Leaves) in a single Node Profile.  For me, I like to see a single Node Profile per Leaf. Since the Node Profile is going to define Leaf switch, name name the profile based on the Leaf name. Node profiles aren’t referenced by other objects, so using a _NodeProf suffix is not so necessary here.

Here are my examples:

Recommended Node Profile Name Alternative Form Purpose
L101 L101_NodeProf Node Profile for Leaf101
103..104 103..104_NodeProf Node Profile for Leaves 103 and 104

Tenants > Tenant TenantName > Networking > External Routed Networks > L3OutName_L3Out > Logical Node Profiles > NodeProfileName > Logical Interface Profiles

When you create a Logical Interface Profile for a L3Out‘s Logical Node Profile, you are defining the actual interface that will be used to send and receive routing exchanges.  These profiles can define physical routed interfaces, logical sub-interfaces or logical switched virtual interfaces (SVIs).  My recommendation is to only ever include one such interface in each profile (the Node Profile can have multiple Interface Profiles if required), and follow slightly different naming rules depending on whether the Interface Profile is a routed interface, sub-interface or SVI. Similar to the Node Profiles within a L3 Out, the Interface Profile’s _IntProf suffix is not essential here.

Here are my examples:

Recommended Logical Interface Profile Name Alternative Form Purpose
eth101:1:1 101:1:1_IntProf Routed interface on eth1/1 on leaf 101
eth102:1:2.333 102:1:2.333_IntProf Routed sub-interface for VLAN 333 on eth1/2 on leaf 102
VLAN400 VLAN400_SVI.Prof SVI on VLAN 400

Names for Access Policy model objects

Understanding the Access Policy model, or Access Policy Chain as I like to call it, is one of the hardest concepts to master in ACI. Access policies are configured under:

Fabric > Access Policies

Object Concept Examples
Interface Policies You will need a collection of well defined interface policies to define non-default policies for per-interface configuration options such as CDP, LLDP, BPDU Guard etc.   Once you have defined a particular Interface Policy once, it can be used universally for all tenants. Enable_CDP
Disable_CDP
Enable_BPDU.Filter
Enable_BPDU.Guard
Enable_BPDU.GuardFilter
Enable_BPDU.Flood

ActiveLACP_PC
PassiveLACP_PC
MAC.Pinning_PC

PerPort_VLAN.Scope
PerLeaf_VLAN.Scope

Leaf Profile Describes a Leaf switch (or collection of leaf switches). Name the profile based on the Switch ID(s) Leaf101_LeafProf
101_LeafProf
L101..102VPC_LeafProf
RedNectar’s Rule: Have one and only one Leaf Profile per leaf switch for all leaf switches

Permitted Exception: You may consider having a special VPC Leaf Profile per pair of VPC linked leaf switches to link to the upcoming VPC Interface Profile

Leaf Selector Child object of Leaf Profiles, defines a leaf switch Leaf101
101_LeafSel
Global:Leaf101
Interface Profiles Describes a set of switch ports linked to a Leaf Profile.
Match the name of the Interface Profile to its related Leaf Profile
Leaf101_IntProf
L101_IntProf
L101..102VPC_IntProf
RedNectar’s Rule1: Have one and only one Interface Profile per Leaf Profile, except for …
RedNectar’s Rule2: If you don’t have a corresponding Leaf Profile for each pair of VPC Leaves, create a special VPC Interface Profile per pair of VPC linked leaf switches, and have both leaves link to this VPC Interface Profile
Access Port Selectors Child object of Interface Profiles. Give the selector a name that reflects the port number it represents. 1:01 (defines port 1/1)
1:01_IntSel (defines port 1/1)
1:13..14_PC (defines port 1/13-14 used in a port channel)
RedNectar’s Rule: Have one Access Port Selector per port (very tedious), except when two ports on a leaf must have congruent configurations, such as when defining a Port Channel, so…
RedNectar’s Rule: Have one Access Port Selector per configured Port Channel
RedNectar’s Tip: When naming Access Port Selectors, use leading zeros in the port-numbering scheme as shown above.  That will keep your list of Access Port Selectors in order when sorted alphabetically.
Note: Interface Policy Groups have subtle but important differences depending on whether they are Access Port Policy Groups or [Virtual] Port Channel Interface Policy Groups; so I have treated each case separately.
Access Port Policy Groups  Describe a generalised collection of Interface Policies for single-attached devices. The more “generalised” the Group, the more re-usable it becomes. Name the APPG to describe the type of attached hosts and the Tenant using the attached host.  If the attached host is to be shared, indicate it in the name. TenantX:SingleAttachedHosts_APPG

Shared:AccessPorts_APPG

[V]PC Interface Policy Groups Describe a specific Port Channel or Virtual Port Channel Interface. There is way of “generalising” a group of polices as per Access Port Policy Groups, but each [V]PC will need it’s own collection of Interface Policies defined. Since VPCs and PCs must be unique for a given pair/group of ports, name the [V]PC to describe the Leaf Ports to be assigned.[See Footnote] Leaf101..102:1:35_VPCIPG (defines a VPC on interface 1/35 on Leafs 101 and 102)
L103:1:4..5_PCIPG (defines a Port Channel on 1/4-5 of Leaf 103)
TenantX:FIA_VPCIPG (defines a VPC to Fabric Interconnect A for TenantX)
Attachable Access Entity Profiles (AAEPs) Provides a joiner between the physical configuration of the Leaf ports and the encapsulation configuration. Think of it as a VLAN Profile. Or a VXLAN Profile.  Name the AAEP to symbolise the collection of V[X]LANs along with the ports that will permit these V[X]LANs. TenantX:AllVLANs_AAEP

Shared:ExternalAccess_AAEP

Physical Domains Provide a place to define a single collection of VLANs (or VXLANs) to be used to map directly connected hosts to EPGs. Name the Physical Domain based on the name of the Tenant and the associated VLAN Pool. TenantX:StaticVLANs_PhysDom

Common:StaticVLANs_PhysDom

External Layer 2 Domains Provide a place to define a single collection of VLANs (or VXLANs) to be used to map VLANs or hosts to L2EPGs. Name the External Layer 2 Domain based on the name of the Tenant and the associated VLAN Pool. TenantX:StaticVLANs_ExtL2Dom

Common:StaticVLANs_ExtL2Dom

External Layer 3 Domains Provide a place to define a single collection of VLANs (or VXLANs) to be used to map external connections to L3 External Networks (L3 Outs). Name the External Layer 2 Domain based on the name of the Tenant and the associated VLAN Pool. TenantX:StaticVLANs_ExtL3Dom

Common:StaticVLANs_ExtL3Dom

Virtual Machine Management (VMM) Domains VMM Domains are multi-murpose. A VMM:
a) provides a place to define the identity and login credentials to a vCenter/SCVM/KVM
b) provides a place to define a single collection of VLANs (or VXLANs) to be used to map PortGroups/VM Networks to EPGs.
c) will bestow its name to a Distributed Virtual Switch in the target vCenter/SCVM/KVM Name the VMM Domain based on the name of the Tenant, the type of VMM and the associated VLAN Pool.
TenantX:Apps.vCenter_VMM.Dom

Shared:SCVM_VMM.Dom

VLAN Pools Every Domain (Physical, L2/L3 External or VMM) needs an associated VLAN Pool. If you give each Tenant a collection of Static VLANs and another collection of Dynamic VLANs should be sufficient. Name the VLAN Pool based on the name of the Tenant and the associated Domain. TenantX:StaticVLANs_VLAN.Pool

TenantX:Apps.vCenter_VLAN.Pool

Footnote: A PC Interface Policy Group (PCIPG) must be unique per leaf – so it is possible to re-use PCIPGs, but… if you do, you’ll now have to have some way of remembering if a particular PCIPG has been used on a particular leaf or not, in which case you might still use names like 1:4..5_PCIPG omitting the leaf name and only using that PCIPG when deploying a PC on ports 4-5. Your choice.  Similarly, a VPC Interface Policy Group (VPCIPG) need only be unique per VPC pair of switches and if you choose this option I would again suggest using names like 1:35_VPCIPG and only use that VPCIPG when deploying a VPC on port 35 of the two switches.

The logic…

Throughout my Cisco ACI Tutorial, I followed a naming standard which I suggest you follow for your first install. I wanted to follow the convention that was cited in the Troubleshooting Cisco Application Centric Infrastructure book, but decided that the examples they gave were sometimes inconsistent, too detailed, and in some cases too verbose. But I stuck with the spirit of using a structure of [Purpose]-[ObjectType] that seemed to be the backbone of the convention, adding some extra punctuation rules, such as concatenating words into TitleTextStyle to make them readable, and adding a [TenantName]: to the convention when appropriate – so my convention is: [TenantName]:[Purpose]_[ObjectType] Having the [ObjectType] as part of a name can help tremendously when learning the structure and when distinguishing between similar objects. Clearly Leaf101_IntProf is less likely to be confused with Leaf101_LeafProf for having the _[ObjectType] suffix.

RedNectar

Note: The Interface Profile object is referred to as an associated Interface Selector Profile or Interface Select Profile on the Switch Profile page. On the other hand, the Access Port Selector object is also referred to in various places as an Interface Selector or the Host Port Selector.

Don’t be confused. I was.

About RedNectar Chris Welsh

Professional IT Instructor. All things TCP/IP, Cisco or VoIP
This entry was posted in Access Policies, ACI, ACI configuration, Cisco, Data Center, Data Centre, Nexus, Nexus 9000, SDN, Software Defined Networking and tagged , , , , . Bookmark the permalink.

1 Response to Cisco ACI Naming Standards

  1. Durwood says:

    Very helpful! Any consideration for naming selectors and profiles when a FEX is involved?

Comments are closed.