ACI Physical Domain and L2Out domain

[m1xed0s]

Say I am working on a ACI network centric implementation and I need to inter-connect ACI fabric to classical ethernet for VLAN trunking. There are two ways to connect, either using physical domain or using L2Out (External bridged domains)...As far as I know the only difference between the two is L2Out requires contracts between EPGs while physical domain does not, assuming intra-EPG communication is allowed.

However if I do not care about inter-EPG security and I set inter-EPG communication not enforced OR just use vzAny within the Tenant, is there any advantage of using physical domain over L2Out to connect classical ethernet, vice versa? 

[RedNectar · Accepted solution]

Say I am working on a ACI network centric implementation and I need to inter-connect ACI fabric to classical ethernet for VLAN trunking. There are two ways to connect, either using physical domain or using L2Out (External bridged domains)...As far as I know the only difference between the two is L2Out requires contracts between EPGs while physical domain does not, assuming intra-EPG communication is allowed.

That's not all.

1. L2Outs are limited to a maximum of ONE VLAN, making them less flexible than Application EPGs
2. L2Outs are much more complicated to configure than Application EPGs
3. In my opinion, L2Outs are a complete waste of time and serve only to confuse the issue by providing a sub-set of features already available using Application EPGs

However if I do not care about inter-EPG security and I set inter-EPG communication not enforced OR just use vzAny within the Tenant, is there any advantage of using physical domain over L2Out to connect classical ethernet, vice versa? 

No

---

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

[m1xed0s]

Thanks for the information which are helpful.

however, 

regarding your #1, it is true only under App centric mode IMHO;

regarding your #2, statically mapping the ports with VLAN after associating the phy dom within a APP EPG does not necessarily make the configuration simpler than L2Out...so I would consider they are the same. Just different APIC menu structure IMHO...Plus there is always scripted API calls

[RedNectar]

Hi @m1xed0s ,

I wish people would not get hung up about "Application Centric" and "Network Centric" as if they were "better" or "worse".

If you start with a design that has one VLAN per Application EPG, you can later add more VLANs to that EPG.

If you start with a design that has one VLAN per L2Out EPG, you can NEVER add more VLANs to that EPG.

The typical use case where you MIGHT want to add an additional VLAN to an EPG is when a VMM Domain is added to your system, or you need to add some legacy servers to an EPG that just happen to be mapped to a different VLAN.

I also missed a little point in your original post that may indicate a mis-conception you have regarding L2Outs

As far as I know the only difference between the two is L2Out requires contracts between EPGs while physical domain does not, assuming intra-EPG communication is allowed.

This statement is not true - in the sense that the requirement for contracts is the same for L2Out External EPGs as is is for Application EPGs.  All endpoints within an EPG (intra-EPG) can communicate, irrespective of whether it is a L2Out External EPG or an Application EPG. And all EPGs (irrespective of type) require a contract to communicate with another EPG - with the following exceptions:

1. The VRF to which the Application EPG or L2Out EPG belongs to has the Policy Enforcement set to Unenforced
2. There is a contract provided and consumed by the VRF's vzAny construct that allows communication between EPGs - again this is true irrespective to whether it is L2Out External EPG or an Application EPG
3. The VRF to which the Application EPG or L2Out EPG belongs to has the Preferred Group option enabled AND
   1. The  L2Out External EPG or an Application EPG belongs to that preferred group

Another thing to consider when looking at L2Out EPGs vs Application EPGs is the use of the new Endpoint Security Groups in ACI v5. These may suit your purpose better than either L2Out External EPGs or an Application EPGs.

I take your point that if you use API calls and scripting to create your EPGs, one type of EPG is not easier than the other to create. Although personally, I find navigating Application EPGs for operational purposed easier than L2Out EPGs. But that's just personal.

[Sergiu.Daniluk]

From my perspective, L2Out is an "old" ACI feature, with limited functionality, which was left there for "backward compatibility". Any new deployment should NOT have this implemented.

Stay safe,

Sergiu

[m1xed0s]

Thanks!

[m1xed0s]

Thanks! Good information.

I donot think anyone is hanging too much on network centric or app centric...it is not a switch to turn on one vs the other. It is methodology to design the fabric and policy IMHO.

Regarding your point “adding VLANs to app EPG later”, can you give a detailed example? I can only think of doing that if I designed fabric “app centric” which the VLANs are irrelevant...

Coming back to L2OUT vs phydom. Say there is a app epg for vlan 100 and l2out for vlan 100. By default, you would need contract to allow traffic between the L2out and app epg, right? This is not a requirement for the setup with phydom.

[Robert Burns · Accepted solution]

The L2Out simply provides a mechanism to 'control' the flow of Layer2 traffic in/out of the fabric.  If you implement PhysDom/Static Path EPG, then you're allowing any:any access from the outside world into that EPG.  For most customers, that's acceptable.

Similar to how an L3Out provides a control point for security policy and dictates which routed networks (l3extInstP) can access which Application EPGs (AEPg), the L2Out provides similar (l2extInstP) for L2 traffic access to those same Application EPGs.

Is it used commonly - No

Is it slightly more complicated than Static Paths - Yes

Can it provide additional security than Static Paths - Yes

Robert

[m1xed0s]

Cool. It is clear now