What would be the benefits of using the AAEP Application EPG?

[m1xed0s]

I ran into an existing Fabric that they associated AAEP with bunch of EPGs for VLAN trunking southbound. I never done the setup this way and I am a little bit puzzled on what would be the benefits of doing so comparing to the EPG static path binding. From my experience, 99% of the ACI fabric (new or existing) is 1:1 mapping between EPG and BD if EPG is mapped to classic VLAN. So is the AAEP with EPG approach much superior or the same as EPG static path binding? Or maybe it is a legacy approach, similar to the static leaf binding feature?

Assuming there is no automation tool in place but just manual APIC GUI configuration and a single AAEP is used for the vPC interface group policies. Say there are 50 EGPs (50 VLANs) in the network or fabric need to be trunked southbound to five vPC connected ESXi hosts in a brand new fabric,

• If using the static path binding approach, each EPG would be configured to trunk its VLAN onto the five vPC link. In total, there would be 250 similar configuration change repeats.
• If using the AAEP approach, each EPG is associated with the AAEP which has the VLAN pool (may or may not have additional non-related VLANs). In total, there would be 50 similar configuration change repeats.

Other than the "significant" one-time saving on number of changes, is there any other benefits (technical or non-technical) of doing the AAEP approach to deploy EPG VLAN trunking southbound?

[RedNectar · Accepted solution]

Hi @m1xed0s ,

There are a couple of differences between "mapping up" (AAEP to EPG) and "mapping down" (EPG Static Ports). The main one is the one you've identified - you can easily configure a lot of EPGs on a collection of trunk ports that are members of the same AAEP.

But there are a couple of other more subtle differences, at least in the way these things are viewed.  I don't have knowledge of whether one way is more efficient in terms of memory or capacity. If there is, I hope someone else addresses that.

But let's look at the cosmetic differences. I have a tenant (Tenant03) with two very similar EPGs - but one EPG has a static mapping from the EPG to a VPC, while the other has a VLAN mapped in the AAEP to an EPG. Here's the picture.  The static mappings to the FEX ports are irrelevant, but it was easier to leave them there than draw a new picture:

One of the first places you'll notice a difference is in the EPG Members option of each EPG. The static mapping will appear in the EPG Members list, the AAEP "mapping up" will not.

For me, I see this as a DISADVANTAGE of "mapping up".  When looking from the point of view of the EPG, you can't actually tell if a port is mapped to that EPG unless you can see some endpoints appearing there under the Operational tab. (I don't have any configured ATM, so can't show you)

Now the next (small) disadvantage (as I see it - others may disagree) takes a bit more thought processing power.

I want you to notice from my diagram above that

• the AppServers_EPG has only one VLAN linked to port 1201/1/13 which isvlan-1031
• the WebServers_EPG has only one VLAN linked to port 1202/FEX-192/1/13 which isvlan-1032
• But since vlan-1033 is linked to the AAEP, when I look at the VLANs associated with ports 1201/1/13 and 1202/FEX-192/1/13, I also see vlan-1033 in the list

Now in many designs, this is not going to be an issue, but you just need to remember that when you "map up" - your VLAN is going to appear on EVERY port that is linked to that AAEP.

Finally, (relying on memory here) I believe that older versions (v3? v4? not sure) of ACI could show a degraded health for an EPG that had an AAEP mapped up to the EPG if ANY interface linked to the AAEP was down. I believe that was fixed at some point. Or I could be just talking nonsense. I don't have an older version in the lab to test.

[m1xed0s]

Appreciate the information and effort!! 

I currently consider the "MAPPING UP" to be very similar approach as the "Static Leaf" legacy approach. But will see if anyone from Cisco would be able to chime in, especially on the performance side of the benefits. 

[Robert Burns · Accepted solution]

There's no performance gain to my knowledge, just a convienance benefit.  This concept works well with Hypervisors if they all exist in a dedicated AEP.  If you happen to share the AEP with baremetal hosts also, then you're going to bind EPGs to interfaces that may not require it wasting resources.  While this can be handle I don't like the AEP EPG mapping myself.  It's somewhat hidden from the UI unless you know where to look.  I prefer to use the API (if needed) but leverage the EPG static path mappings which are far more granular and keeps all mapping under the tenant, rather than access policies area of the UI.  
The only other caveat of using the AEP approach to map EPGs is that each EPG must use the same tagging method on all ports (Tagged/Untagged/Access) - with the static path approach the same EPG "could" be tagged on one interface and untagged on another.  Not a big deal if you're being consistent with things, but it is more flexible.

Robert

[m1xed0s]

Thanks for the information, @Robert Burns!!!

[RedNectar]

Thanks @Robert Burns 

for reminding me about that tagging method restriction. I've come across this before too, where we needed an access port for one EPG - when we tried to add it to the EPG things broke!

However, this reminds me of one sneaky use you can make of combining "mapping up" and "mapping down"

An EPG can only have one mapping per port, so if you have a trunk port with VLAN 10 statically mapped to EPG_A and for some reason you want to also map VLAN 20 on that port to EPG_A, well, you can't do that with static mappings.  And similarly, you can't map both VLAN 10  AND VLAN 20 from the AAEP "up" to the EPG.

But - you CAN map say EPG 10 statically form the EPG and EPG 20 from the AAEP up to the EPG and achieve the result you were looking for.

[m1xed0s]

Good point!! However is there really a use case of associating more than one VLANs to a single EPG?

[RedNectar]

---

@m1xed0s wrote:

Good point!! However is there really a use case of associating more than one VLANs to a single EPG?

---

Well - probably not a really good one. But one case where I COULD see it happening in ACI is where, during migration, a customer decides that subnet A on VLAN A and subnet B on VLAN B could be merged into the same EPG because they want open communications between the two subnets.

But of course, with ESGs, you could get around that.