CSMA/CD and full duplex for wireless? It could be coming

A group of researchers at National Instruments have found a way to listen to radio signals while receiving on the same frequency.

The team found a solution that relies on in-band full duplex, so it can sense while transmitting, which potentially eliminates all collision overheads in wireless networks.

This could have huge implications – and even give your home wifi a boost if you have a lot of users – certainly will give the office and cafe wifi hotspots a boost.

The problem with existing wireless communications is that once a device starts transmitting, it doesn’t know if another device has transmitted at the same time (causing a collision) until it has finished transmitting and waited for an acknowledgement from the Access Point.  If no acknowledgement comes, it tries again. This is called Carrier Sense, Multiple Access with Collission Avoidance (CSMA/CA).

Your ancient (1980-c2000) shared Ethernet on the other hand operated in much the same way, a device would start transmitting, but was able to detect if any other device transmitted at the same time, and so stop transmitting immediately. This was called  Carrier Sense, Multiple Access with Collission Detection (CSMA/CD) and is course much more efficient than Collision Avoidance.

But that is not the whole story. Modern wired Ethernet networks use two pairs of wires to transmit, and another to recieve, meaning they can transmit AND receive at the same time. Full Duplex.  If we could do that for wireless, (and this article indicates that they have achieved full-duplex operation albeit with just 6 devices at this stage), then the benefits could be much greater.


Posted in blog, opinion, wifi, wireless network | Tagged ,

Why have WordPress made it soooo hard to follow someone?

WordPress, you have hosted my blog since 2010.  I won’t start a tirade of things you STILL can’t do on WP, but I am going to have a whinge about one feature you have obscured.

Why have WordPress made it soooo hard to follow someone?  I should never have to respond to a reader’s comment such as the one I got today.

I would like to thank you sooooo much for such a awesome ACI blogs, I found things here which are not well documented even in Cisco Docs. You are surely doing a great job. I wish to find a subscriber button on your website and keep up with your great work.

For those who would like to follow my blog, or any other wordpress.com blog, you have to move your cursor to the bottom right-hand corner of the page, and/or scroll up a bit (scrolling is clearly the only option on a mouseless device). You will then get an option pop up giving you the chance to follow or subscribe to my blog.


Posted in opinion, rant, wordpress | Tagged | 2 Comments

RedNectar’s HX Pre-Install Checklist

…has been updated and is found here: https://rednectar.net/2018/10/06/rednectars-hyperflex-pre-install-checklist-updated/

Posted in Cisco, Data Center, Data Centre, Hyperflex, UCS | Tagged , , ,


Note: This post started as an answer I gave on the Cisco Support Forum. This version is slightly expanded with pictures and examples.

In this post I will examine the roles of three very important protocols that exist in the ACI environment.

I will explain

  • that IS-IS is the underlying routing protocol that is used by the leaves and spines to learn where they sit in the topology in relation to each other
  • how Leaf switches use COOP to report local station information to the Spine (Oracle) switches
  • how BGP and MP-BGP is used to redistribute routes from external sources to leaf switches.

Let me start with a picture.  Imagine a simple 2leaf/2spine topology with HostA attached to to Leaf1 and with HostB attached to to Leaf2.

  • Leaf1 has a VTEP address of
  • Leaf2 has a VTEP address of
  • Spine1 has a VTEP address of
  • Spine2 has a VTEP address of
  • HostA has a MAC address of A and an IP address of and is attached to port 1/5 on Leaf1
  • HostB has a MAC address of B and an IP address of and is attached to port 1/6 on Leaf2

Enter IS-IS

The leaves and spines will exchange IS-IS routing updates with each other so that Leaf1 sees that it has two equally good paths to reach Leaf2, and Leaf2 sees that it has two equally good paths to reach Leaf1.

Leaf1# show ip route vrf overlay-1
IP Route Table for VRF "overlay-1", ubest/mbest: 2/0
*via, eth1/51.2, [115/3], 6d20h, isis-isis_infra, L1
*via, eth1/52.2, [115/3], 6d20h, isis-isis_infra, L1

For now, that’s all we need to know about IS-IS – it is the routing protocol used by the VTEPs to learn how to reach the other VTEPs.

Now think about the hosts.

This is where COOP comes in.

When Leaf1 learns about HostA because, say HostA sent an ARP request seeking the MAC address of (which you know is HostB, but that’s not relevant at the moment), Leaf1 looks at that ARP request, and just like a normal switch, learns that MAC A is present on port 1/5.  But the leaf is a bit more clever than that, and looks INSIDE the payload of the ARP packet and learns that Host1 also has an IP address of and records all this information in its Local Station Table.

Leaf1#show endpoint interface ethernet 1/5

VLAN/Domain  Encap VLAN  MAC/IP Address  Interface
65           vlan-2051  a036.9f86.e94e L eth1/5
Tenant1:VRF1 vlan-2051    L eth1/5

AND THEN reports this information to one of the spine switches (chosen at random) using the Council Of Oracles Protocol (COOP).  The spine switch (oracle) that was chosen then relays this information to all the other spines (oracles) so that every spine (oracle) has a complete record of every end point in the system.

The spines (oracles) record the information learned via the COOP in the Global Proxy Table, and this information is used to resolve unknown destination MAC/IP addresses when traffic is sent to the Proxy address.

Note that all of this happens without anything to do with BGP.

But to round off the COOP story, we would assume that at some stage Leaf2 (a citizen) will also learn HostB‘s MAC and IP and also inform one of the spines (oracles) at random of this information using the COOP.

Spine1#show coop internal info repo ep | egrep -i "mac|real|-"
EP mac : A0:36:9F:86:E9:4E
MAC Tunnel :
Real IPv4 EP :
EP mac : A0:36:9F:61:88:FD
MAC Tunnel :
Real IPv4 EP :

So COOP is used solely for the purpose of distributing endpoint information to spine switches (oracles). As far as I know, spine switches never use COOP to distribute end host information to leaf switches.

So where does BGP fit in?

BGP is not needed until an external router is connected.  So now imagine that Leaf2 has had a router connected and has learned some routes from that external router for a particular VRF for a particular Tenant.

How can Leaf2 pass this information on to Leaf1 where HostA is trying to send packets to one of these external networks?  For Leaf2 to be able to pass routing information on to Leaf1 and keep that information exclusive to the same VRF, we need a routing protocol that is capable of exchanging routing information for multiple VRFs across an underlay network

Which is exactly what MP-BGP was invented for – to carry routing information across MPLS underlay networks.  In the case of ACI, BGP is configured by choosing an Autonomous System number and nominating one of the spine switches to be a route reflector.  MP-BGP is self configuring, you don’t need to do anything to make it work!

(Although you will have to configure your Tenant to exchange routes with the external router.)

Leaf1# show ip route vrf Tenant1:VRF1, ubest/mbest: 1/0, attached, direct, pervasive
*via, [1/0], 04:43:32, static, tag 4294967295, ubest/mbest: 1/0, attached, pervasive
*via, vlan25, [1/0], 03:52:23, local, local, ubest/mbest: 1/0
*via, [200/5], 00:11:41, bgp-1, internal, tag 1

aka Chris Welsh

Posted in ACI, ACI configuration, APIC, Cisco, Data Center, Data Centre, EPG, L3 Out, L3out | Tagged , ,

Guest Post! WTF Are all those Checkboxes? (ACI L3 Outs) – Part 2 of ???

Found this great post explaining a lot of fine detail on ACI L3 outs – make sure you check out the original!

Come Route With Me!

My friend and colleague Mr. Jason Banker recently ran into some good times with the mysteries of the ACI L3 Out Checkbox Madness! He Slack’d me and told me he’d found some clowns blog post about it (yours truly) and that some updates and additional information was needed, so he kindly volunteered some time to help out! Without further ado here is Jason’s Checkbox Madness:

As we continue to deploy fabrics we always joke about these damn routing checkboxes shooting us in the foot.  We play with different scenarios in the lab to ensure we understand how these pesky boxes work and what other options we have for future deployments.   The scenario here was to use get different OSPF areas connected to the same border leaf using ACI as the transit.  This scenario brings up some certain challenges and hopefully my testing will help others understand it a little better…

View original post 999 more words

Posted in GNS3 WorkBench

Non overlapping VTEP IP addresses in Cisco ACI

In a Cisco ACI deployment, Cisco recommends that “The TEP IP address pool should not overlap with existing IP address pools that may be in use by the servers (in particular, by virtualized servers).”

Let me tell you a reason much closer to reality why you might want to avoid overlapping your Cisco ACI TEP addresses with your locally configured addressing scheme.

When you first configure a Cisco ACI fabric, you need to configure a range of IP addresses that the ACI Fabric uses internally for VTEP addressing of the APICs, leaf and spine switches and other internally used addresses like anycast addresses for the spine proxy functions.

As I mentioned, Cisco recommends that “The TEP IP address pool should not overlap with existing IP address pools that may be in use by the servers (in particular, by virtualized servers).” I can only guess by the wording of this advice that Cisco sees that there may be some issue with the APICs being able reaching remote VTEPs on Cisco AVS virtual switches, but I see this as an outlier scenario.

The problem with VTEP IP address pools is the APICs.  You see, the APICs can’t handle:

  1. having a management IP address that overlaps with the VTEP address space, (it can’t figure out which interface to send management responses on) or
  2. being accessed from a workstation that is using an IP address that overlaps with the VTEP address space.

Since it is conceivable that any internal IP address may need to access the APIC for some reason sometime, I would recommend that you don’t overlap VTEP addresses with any currently used internal addresses.

Below is an example of the routing table from an APIC:

apic1# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface         UG        0 0          0 oobmgmt     UG        0 0          0 bond0.3967 UH        0 0          0 bond0.3967 UGH       0 0          0 bond0.3967 UGH       0 0          0 bond0.3967   U         0 0          0 teplo-1   U         0 0          0 lxcbr0   U         0 0          0 oobmgmt     U         0 0          0 docker0

In this case, the VTEP address range is, and the APIC sees all 10.0.x.x IP addresses as being reachable via the bond0.3967 interface, as shown by the UG 0 0 0 bond0.3967
routing table entry on the APIC.

Recall I said that the APICs can’t handle:

  1. having a management IP address that overlaps with the VTEP address space, (it can’t figure out which interface to send management responses on) or
  2. being accessed from a workstation that is using an IP address that overlaps with the VTEP address space.

I’ll deal with case #2 first.

Now imagine for a minute I have a workstation with an IP address of say that wishes to communicate with the OOB (Out of Band) management IP address of the APIC, which happens to be  Now that remote workstation of may well have a perfectly good route to, and may indeed be able to send packets to the APIC.

The problem of course arises when the APIC tries to send the reply packets to As per the APIC’s routing table, the APIC would expect to reach via its bond0.3967 interface, as shown by the UG 0 0 0 bond0.3967
routing table entry on the APIC.

Similarly, with case#1. This time, imagine I had used as https://supportforums.cisco.com/discussion/13311571/overlapping-or-non-overlapping-vtep-poolmy OOB Management subnet.  Since that overlaps with my VTEP range ( there is potential that IP addresses from my OOB subnet ( could be allocated to VTEPs somewhere – and if that happened my APIC would be unable to communicate with any other address on the OOB subnet that clashes with a VTEP address.  In theory, the APIC would still be able to communicate with the VTEP addresses because it adds a /32 address to its routing table for every VTEP, but in my experience when I saw a customer with this configuration there was a problem communicating with the OOB subnet.


Just been reading this discussion on the Cisco forum – it seems that the docker0 interface that was introduced in version 2.2 may also screw up the APIC’s view of the rest of the world in the same way


This is an expansion of a reply I gave on the Cisco Support forum

More information on VTEP addressing in the Cisco Application Centric Infrastructure Best Practices Guide

Posted in ACI, ACI configuration, APIC, Cisco, Data Center, Data Centre | Tagged , , , ,

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

 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



Leaf Profile Describes a Leaf switch (or collection of leaf switches). Name the profile based on the Switch ID(s) Leaf101_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
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
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


[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


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


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


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


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.


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


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.


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.

Posted in Access Policies, ACI, ACI configuration, Cisco, Data Center, Data Centre, Nexus, Nexus 9000, SDN, Software Defined Networking | Tagged , , , , | 1 Comment