Migrating Nexus port profiles to ACI

[taskmanas]

We have datacenter network with row end switches (N5K) at each row of the racks and FEX extenders (N2K) as top-of the rack switches. We use port profiles on N5K's heavily to identify different kind of end user devices and assign vlans configuration to multiple physical interfaces simultaneously. Port profiles plays two main roles for us: 
1. We are able to identity what physical interfaces on FEX(es) the servers are connected to. For example we have Port Profile called 'CCTV servers' or 'Customer 1 servers' and are able to quickly tell where in the whole datacenter they are connected to.

2. We are able to see and change vlan port configuration on all physical interfaces on FEX(es) for given type of the device. Might be all servers belonging to Customer 1 or all CCTV servers.

Usually port profile would be a trunk port with multiple vlans tagged to it. Often same vlans are used elsewhere for different port profiles so we cant say that any interface that vlanX goes to is belonging to Customer 1. 

What would be equivalent object in ACI to replace Nexus Port Profiles? I need to somehow track different group of devices in some sort of container or tag. When our Server and Storage team asks as to add another vlan (EPG) to all their BMS servers for example, I need a way to know which leaf interfaces I need to add that EPG to as static port assignment. Our implementation in Network centric as most IP gateways are on external firewall and we don't use VMM integration (also vmware integration would not solve all of this as some of these nexus port profiles are used to track physical bare metal things).

I am interested to know how other people went from using Nexus Port Profile on legacy DC to ACI. I hope we are not unique in ways we used to use Nexus Port Profiles. 

[Ruben Cocheno]

@taskmanas @taskmanas 

Interface Policy Groups are templates used to dictate ports behaviour. Interface policy groups use the interface policies described in previous section to specify how links should behave.
An Interface policy group is also associated to an AAEP and to a switch port through Interface selector. This double association (AAEP and interface) will result in associating a set of domains and their VLAN Pool to a switch interface.

There are three types of interface policy groups depending on link type:
• Access Ports (individual)
• Port channel
• Virtual Port Channel (vPC)

The type of interface policy groups will have an impact on how it will be used within the ACI Fabric.
A unique interface policy group should be defined for each port channel and virtual port channel, as an interface policy is the triggering object for generating a port-channel interface when the configuration is applied to the leaf nodes. Each host connected to the ACI Fabric by the means of a vPC or Port-Channel will require a unique vPC or PC Policy Groups.
An access port policy group can be reused for all interfaces having the same Interface policy and AAEP requirements.

Leaf and Spine switches use distinct interface policy-group types.

An Attachable Entity Profile (AEP) represents a group of external entities with similar infrastructure policy requirements. The attachable access entity profile (AAEP) is used to map domains (physical or virtual) to interface policies; an AEP is required to deploy VLAN pools on leaf switches and it implicitly provides the scope of the VLAN pool to the physical infrastructure.
In addition, AAEPs allow a one-to-many relationship (if desired) to be formed between interface policy
groups and domains as shown in the following figure:

[RedNectar]

Hi @taskmanas & @Ruben Cocheno ,

I've now split my answer into two - one answering the original question, and this little rant that I spewed because I could feel your pain grappling with the difference between an AAEP and an AEP

---

Let me start by calling out Cisco for their STUPIDITY of inconsistent naming - it clearly has caused @taskmanas problems understanding the concept of an Attachable Access Entity Profile - AAEP (@taskmanas - the AAEP and AEP are exactly the same object - your explanation seems to assume they are different things)

Cisco's stupidity is that they often refer to the AAEP as an AEP - they even call the Attachable Access Entity Profile variously an Attachable Entity Profile; an Attached Entity Profile; an Access Entity Profile and possibly other terms on some screens.

The point is, there is NO such object called an Attachable Entity Profile or AEP!  It does NOT exist in the ACI Management Information Tree.

The TRUE name for the object class is actually infraAttEntityP - you can use moquery to find all your AAEPs by querying this class with the command moquery -c infraAttEntityP 

I was going to mention that you can also get a full description of this class by navigating to https://<YOUR_APIC_IP>/model-doc/#/objects/infraAttEntityP/overview , but Cisco's description given there is so pathetic that it's not worth wasting your time. The description even refers to it as "The attached entity profile".  

</end of rant about Cisco's pathetic naming inconsistencies and pathetic documentation. I feel better now>

---

FWIW - I asked Bard the following:

In Cisco ACI - what is the difference between an AAEP and an AEP?

And Bard gave the following (pretty darn good) answer:

---

There is actually no difference between an AAEP and an AEP in Cisco ACI. Both terms refer to the same object: Attachable Access Entity Profile.

The confusion arises because Cisco sometimes uses the shorter "AEP" for brevity within its documentation and interface. However, the full and officially recognized term is Attachable Access Entity Profile, often abbreviated as AAEP.

Therefore, you can safely consider "AAEP" and "AEP" to be interchangeable when referring to this policy object in Cisco ACI.

Here are some additional points to remember:

• An AAEP defines a combination of a domain type (L2 or L3) and a VLAN pool, along with optional interface policies.
• It acts as a bridge between tenant space and the underlying fabric infrastructure.
• You can associate AAEPs with Endpoint Groups (EPGs) to provide connectivity and security for applications.

I hope this clarifies the situation. Feel free to ask any further questions you may have about AAEPs or other aspects of Cisco ACI.

[taskmanas]

This is really helpful, I was reading @Ruben Cocheno reply and was actually googling the difference between AAEP and AEP. Thanks a lot for clearing the fog! 

[RedNectar]

Hi @taskmanas ,

Let's focus on your actual question:

What would be equivalent object in ACI to replace Nexus Port Profiles?

The answer is Interface Policy Groups. 

Interface Policy Groups come in three main flavours.  To explain, I'll steal this from a blog post I wrote just over 8 years ago.  You'll have to use Google to find my blogpost if you want to read it.

Key Point:

There are three types of Interface Policy Groups – one of these is for directly attached devices, the other two for bundled interfaces. Access Port Policy Groups (APPGs) define a set of policies for a group of ports that are allowed to use the same VLAN set (via the AAEP – discussed later) Port Channel Interface Policy Groups (PCIPGs) define a set of policies for a single port channel – which of course must be allowed to use the same VLAN set (via the AAEP – discussed later).  This PCIPG becomes the identifier for the port-channel for later reference. Virtual Port Channel Interface Policy Groups (VPCIPGs) define a set of policies for a single virtual port channel – which of course must be allowed to use the same VLAN set (via the AAEP – discussed later). This VPCIPG becomes the identifier for the port-channel for later reference.

To take your example of Port Profiles called 'CCTV servers' and 'Customer 1 servers', you could create two Access Port Policy Groups, one called say CCTV.servers_APPG and the other Customer1_APPG.

But unfortunately, it is not that simple.

The problem is, the relationship between Interface Policy Groups and "allowed VLANs" is not so clear in ACI as it is in NEXUS Port Profiles, because the switchport trunk allowed command is added and manipulated dynamically by ACI.  In fact, this dynamic nature of ACI is one of its key advantages.

So back at your concept of being able to assign vlans configuration to multiple physical interfaces simultaneously, it does not work quite that way in ACI.  But I can show something that works in a similar way using VLAN Pools and a method of mapping VLANs to EPGs via the AAEP.

Let's have an example.  I'll assume you are already using VLANs 1000-1009 on your CCTV Servers, and you have CCTV Servers attached to ports 1/10 and 1/12 on leaf switch 1201 and the same port numbers on leaf switch 1202. To achieve this, you would already have had to build an Access Policy Chain like this - where I've assumed that your CCTV.servers_APPG has a couple of interface policies (link speed, CDP and LLDP) included in the migrated Port Profile:

You'll notice a similarity to @Ruben Cocheno's elegant diagram, except I've removed the VMM and External domains, and added the system created

• leaf (node) profiles and selectors
• interface (port) profiles and selectors
• interface policies (link speed, cdp, lldp)

Now somewhere in your design, I'll assume that VLAN 1000 is mapped to and EPG - lets call it Cameras_EPG - and similarly for VLANs 1001-1009.  But for my example, I'll stick with Cameras_EPG.

The mapping of the Cameras_EPG to VLAN 1000 could have happened two ways:

1. Mapping Down
   Navigate to Tenants >> YourTenant > Application Profiles > Your_appProfile > Application EPGs > Cameras_EPG > Static Ports >+ Deploy Static EPC on PC, VPC or Interface
   • Select node 1201
   • Select Path eth1/10
   • Specify VLAN 1000
   • Still under Cameras_EPG > Static Ports >+ Deploy Static EPC on PC, VPC or Interface
   • Select node 1201
   • Select Path eth1/12
   • Specify VLAN 1000
   • Still under Cameras_EPG > Static Ports >+ Deploy Static EPC on PC, VPC or Interface
   • Select node 1202
   • Select Path eth1/10
   • Specify VLAN 1000
   • Still under Cameras_EPG > Static Ports >+ Deploy Static EPC on PC, VPC or Interface
   • Select node 1202
   • Select Path eth1/12
   • Specify VLAN 1000
2. Mapping Up
   Navigate to Fabric > Access Policies >> Policies > Global > Attachable Access Entity Profiles > CCTV.Servers_AAEP
   • Click + under Application EPGs and map YourTenant/Your_appProfile/Cameras_EPG to VLAN 1000

As you can see, method 2 (Mapping Up) is much easier than method 1 (Mapping Down) above.  But method 2 does have some drawbacks

• you loose some visibility - you will NOT see any ports appearing under Tenants >> YourTenant > Application Profiles > Your_appProfile > Application EPGs > Cameras_EPG > EPG Members
• VLAN 1000 will appear to exist on all 4 ports above, even if it is NOT being used at all by the attached server.

Now. Back to your scenario.  Let's say your Server and Storage team asks as to add vlan 1010 (Vlan1010+EPG)  to all their CCTV servers.

1. You'll need to create the new EPG
   • Tenants >> YourTenant > Application Profiles > Your_appProfile > Application EPGs >+ Create Application EPG.  You'll need to:
     • name it
     • link it to a Bridge Domain
     • link it to the CCTV.Servers_PhysDom
2. Then you can just navigate to Fabric > Access Policies >> Policies > Global > Attachable Access Entity Profiles > CCTV.Servers_AAEP
   • Click + under Application EPGs and map YourTenant/Your_appProfile/VLAN1010_EPG to VLAN 1010

Job done.  Or of course, you could do the long way by mapping each of the 4 ports as shown above.

Note: When VLAN 1010 is mapped to the AAEP, the following configuration will automatically appear in the running configuration for the template policy-group CCTV.Servers_EPG:

switchport trunk allowed vlan 1010 tenant YourTenant application Your_appProfile epg VLAN1010_EPG  

which I think is more or less what you were trying to achieve.

[taskmanas]

Thank you @RedNectar this is very useful! I will test it immediately on our networks and see if I get any operational issues.

My immediate concern is that some of our vlans on legacy network are in use by multiple Nexus port-profiles. Following your example above  I would need to create vlan pools with some overlapping vlans, which I think ACI will not like that. (At lease this is what I read in the past). Would creating one massive vlan pool with all vlans in it called 'ALL DC VLANS' be a solution? Its not as elegant, but would this cause any problems?
For example 'cctv-servers' Nexus port profile might have config :  switchport trunk allowed vlan 1002-1010
and 'customer1' port profile might have this: switchport trunk allowed vlan 700, 800, 1008. 
vlan 1008 would have to be in both vlan pools. 

Another operational challenge I can see that for example our Server and Storage team might say: 'We have connected a new box to leafs 203 and 204 interfaces 1/20 on both, can we have port enabled and configured the same as all out CCTV servers'.
In the old world we would just make the ports inherit 'CCTV SERVERS' port profile and we would not need to know what vlan config they need. I am not sure how to du that in ACI. 

Many thanks for your help on this!

[RedNectar]

Hi @taskmanas ,

---

My immediate concern is that some of our vlans on legacy network are in use by multiple Nexus port-profiles. Following your example above  I would need to create vlan pools with some overlapping vlans, which I think ACI will not like that. (At lease this is what I read in the past). Would creating one massive vlan pool with all vlans in it called 'ALL DC VLANS' be a solution? Its not as elegant, but would this cause any problems?

Yes.  That would be the best solution.  If VLANs are to be shared between domains and/or AAEPs, it is best practice to have the shared VLANs in the same VLAN pool. 

For example 'cctv-servers' Nexus port profile might have config :  switchport trunk allowed vlan 1002-1010
and 'customer1' port profile might have this: switchport trunk allowed vlan 700, 800, 1008. 
vlan 1008 would have to be in both vlan pools. 

I'm afraid it won't work that way if:

1. you have one VLAN pool as suggested above, and
2. you use the "mapping up" of VLANs from the AAEP as described in my last answer.
   (OK. I've had to edit my last answer to include a Mapping UP  heading)

It WILL work that way (but the config will be under the interface, not the "port profile") if

1. you have one VLAN pool as suggested above, and
2. you do static mapping (the long method described in my first answer)

Another operational challenge I can see that for example our Server and Storage team might say: 'We have connected a new box to leafs 203 and 204 interfaces 1/20 on both, can we have port enabled and configured the same as all out CCTV servers'.
In the old world we would just make the ports inherit 'CCTV SERVERS' port profile and we would not need to know what vlan config they need. I am not sure how to du that in ACI. 

---

You can still achieve that in ACI using the "mapping up" of VLANs from the AAEP as described in my last answer.  In this case, you assign interfaces 1/20 on leaves 203 and 204 to the same CCTV.Servers_APPG that I described in my last answer.  But you'd still have to assign the new VLAN to an EPG too.

[taskmanas]

Hi @RedNectar 

The testing was going well until I tried configuring Port Channels and Virtual Port Channels. As you explained in your blog ''single PCIPG or VPCIPG can only refer to a set of ports that define a single Port Channel or Virtual Port Channel''. 
Here is what happened. I had my Access Policy Chain set up like this:
ALL-SERVER-VLANS.pool <- ALL-SERVERS_phyDom <- CCTV.SERVERS_AAEP <- CCTV.SERVERS_APPG
This works fine with with Leaf Access Port policy group, but it cannot be used with PCs and VPCs. I went into Leaf Interface Profile and added Two interface selectors:
SERVER1 interface 1/4 Policy Group CCTV.SERVERS_VPCIPG
SERVER2 interface 1/6 Policy Group CCTV.SERVERS_VPCIPG
And of off course instead of having two separate VPC port channels, I got one VPC port channel (despite the fact that I used two different port selectors) with both intercase on both switches. Its a simple fix to use unique VPCIPG for every single VPC. My biggest challenge was naming convention. How on earth do I name hundreds of these VPCIPGs and make them readable and friendly to automate through postman or terraform. I ended up naming them like this:
VPC_DC1_b12-1_b12-2_ports6
VPC_DC2_a3-1_a3-2_ports3-4
We are multi-pod environment so this would read:
VPC _ Pod number _ rack number leaf 1 _ rack number leaf 2 _ port(s) number

I would like to hear how other people named their VPCIPGs

[RedNectar · Accepted solution]

Hi @taskmanas ,

You have discovered the frustration of every ACI user when it comes to naming VPCs!

So let's focus on

---

Its a simple fix to use unique VPCIPG for every single VPC.

Yes. That is the fix and what I'd recommend. But it is possible to use the same VPC Interface Policy group more than once - but you can only use it once per VPC pair of switches. More later

My biggest challenge was naming convention. How on earth do I name hundreds of these VPCIPGs and make them readable and friendly to automate through postman or terraform. I ended up naming them like this:
VPC_DC1_b12-1_b12-2_ports6
VPC_DC2_a3-1_a3-2_ports3-4
We are multi-pod environment so this would read:
VPC _ Pod number _ rack number leaf 1 _ rack number leaf 2 _ port(s) number

---

That looks like a pretty good naming convention, although I recommend not using the hyphen or dash character - in names, see reference below.  When names get long, I find the fact that you can use periods .  and colons :  in names useful because the ACI GUI uses normal character spacing, you'll get to read more of the name if you use these rather than underscores _ even two dots ..  takes less space than underscore _

So something like

VPC_DC1_b12-1_b12-2_ports6
could be reduced in screen real-estate to
DC1.b12:1..b12:2.ports6_VPC

Following my conventions, I've moved the VPC to the end, because if you are looking at a list of VPCs, it's the first part of the name you see, so put the most import part you want to see at the beginning, and the policy type identifier at the end.

But of course this is all personal choice - the thing is to come up with a way that works for you. And as I said, you seem to have done that.

Finally (as promised) - if you really want to re-use VPC interface policy groups - you can, just so long as each time you use the same policy group it is a different VPC pair.  Similarly for PCs - only for PCs its one use per swtich.

If you took this approach, you MIGHT get away with a name like

port6_VPC 

and use it for and VPC that is configured on a pair of port 6s at either DC.  Although personally, I don't like this idea. If I was naming this VPC, using your naming as a guide, I'd use

DC1.b12:1..b12:2p6_VPC

I hope this helps.

---

Don't forget to mark answers as correct if it solves your problem. This helps others find the correct answer if they search for the same problem.

---

Hyphens in Names

The following quote was taken from this blogpost - and yes it's my blog. Sorry about referencing my own work

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