ACI - Bare metal servers - Trunk and Access mode inside the same EPG / AAEP

[ju.mahieu]

Current version :  2.1.1h / n9000-12.1(1h)

Hi,

I would like to know the best practices to achieve the following scenario :

# The simplest way to group inside the same EPG ?
     + Bare metal servers connected in Access mode.
     + And Bare metal servers connected in Trunk mode anywhere in the datacenter. Workload are identified by vlan tag. Each vlan ID is bounded to a different EPG.Today, we are using the new feature directly available through the AAEP to bind a vlan to an epg (See attached screenshot).
Unfortunately, this feature seems not really working as expected (See this topic).
During test, it seems also the behavior is really unstable if you use at the same time "Static path binding" for access mode and "AAEP EPG binding" for trunking mode inside the same EPG.   

Any advice to configure correctly the "AAEP EPG" functionality or any thoughts about this topic will be really appreciated...

Best regards,

Ju

[Marcel Zehnder · Accepted solution]

Hi Ju

From my point of view static paths are the way to go for both options (access/trunk). If you use static paths (fvRsPathAtt) all your bindings are configured under the EPGs. If you use the "AAEP EPG" functionality (infraRsFuncToEpg) you configure half of your logic under the fabric and the other half under the tenant. Another disadvantage of using AAEP-EPG is that you end up with more or less one AAEP per bare-metal server. Also if you compare the two objects (fvRsPathAtt, infraRsFuncToEpg) you'll see that there is no path-information in the infraRsFuncToEpg object, so with the infraRsFuncToEpg object there is useful information missing.

I don't understand why the AAEP-EPG-Binding feature was introduced, I don't see the use case for this feature and I also think by using it we break the physical/logical (fabric/tenant) configuration isolation - but this is just my point of view.

Marcel

[ju.mahieu]

Thank you Marcel for sharing your opinion.

I agree with you. The AAEP functionality sounds not so good.

Maybe the Cisco team will give his point of view ? 

Ju

[Robert Burns · Accepted solution]

The AAEP EPG was introduced as a way to quickly deploy an EPG to every port associated with the AEP.  Let's say you had 2000+ ports you want an EPG deployed do - you can either deploy 2000+ static bindings, or you can deploy a single AAEP EPG.

Personally, I would never use it.  I could just as easily script up the XML/API command to deploy the static path bindings where needed.  I'd agree with Marcel to keep your bindings in one place, rather than hiding some under Access policies.

Robert

[Marcel Zehnder]

Thank you robert for your point of view. You named it: we have a great API which makes it easy to deploy a huge number of static paths, this is exactly why I don't understand why this feature was introduced. So I completly agree with you and stay with my scripts.

Marcel

[wim.juste]

Using automation configuration tools like ansible, a single trunk port with 600 vlan tags would have a lead team +\- 30 minutes to be deployed. (Compare it to classic NXOS switch trunk allowed vlan x,y, ... -> subsecond)

I understand the AEP EPG binding is kind of a traditional NXOS port-profile approach.

[ju.mahieu]

Thank you Robert and Marcel,

You convinced me. I'm going to use static path rather than an aaep binding.

:-)

Ju