10-09-2020 07:11 AM - edited 10-09-2020 07:14 AM
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?
Solved! Go to Solution.
10-09-2020 01:21 PM
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.
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
10-10-2020 10:56 AM - edited 10-10-2020 10:56 AM
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
10-09-2020 01:21 PM
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.
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
10-09-2020 03:53 PM
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
10-09-2020 05:15 PM - edited 10-09-2020 05:19 PM
Hi @SIMMN ,
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:
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.
10-09-2020 11:04 PM
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
10-10-2020 05:25 AM
Thanks!
10-10-2020 05:36 AM
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.
10-10-2020 10:56 AM - edited 10-10-2020 10:56 AM
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
10-10-2020 11:38 AM
Cool. It is clear now
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide