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 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.

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 (AEP) 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 hyphen 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 you can’t use the space character, and using my conventions, the hyphen character is used as the separator for objects requiring a suffix and the colon character is used as the separator for objects requiring a prefix.

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 in the Advanced configuration mode, 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 there is an argument for having all filters defined 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

An External Bridged Network has colloquially become known as a L2 Out – 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-IntProf 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 (AEPs) 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 AEP to symbolise the collection of V[X]LANs along with the ports that will permit these V[X]LANs. TenantX:AllVLANs-AEP

Shared:ExternalAccess-AEP

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 like1: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.

Advertisements

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.

One Response to Cisco ACI Naming Standards

  1. Durwood says:

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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s