03-01-2018 12:46 PM - edited 03-01-2019 05:28 AM
What's the pros and cons for using only one Bridge Domain for multiple EPGs?
In the same tenant we’ve one AP, twenty or more EPGs and one BD. In this case all EPGs share the same BD and communicate between there is across contract. The question is. Do I have any problem or important limitation with this approach?
Solved! Go to Solution.
03-03-2018 02:53 AM - edited 09-10-2019 03:07 PM
[Edit 2019-09-11: When you've read my answer, scroll down and check out @cweinhold's pictorial approach to answering this question]
Hi Marcelo,
This question has been around in various forms since the 1990s!
But to be specific to ACI, let me tell you about Application Centric Design and Network Centric Design.
Both are valid design strategies, and you can read more of the official Cisco view here. But basically, what you have described is an Application Centric approach. A Network Centric Design would put each EPG in its own Bridge Domain and own Subnet.
Now, back to your question.
What's the pros and cons for using only one Bridge Domain for multiple EPGs?
Assuming you have left the options above at their defaults (which is what happens if you specify Optimize as the Forwarding method when you create the bridge domain) then you will be able to create a larger Bridge Domain than the traditional Broadcast Domain you would have been able to create using traditional networking methods. (Switches/VLANs). But, there are some limitations on those optimised values, and if you need to change them in the future, you may find that your BD suddenly has to cope with more BUM traffic than before. Specifically:
One approach is not necessarily better than the other.
When migrating existing VLANs/Subnets, a Network Centric approach is what I would recommend.
When writing an Orchestration Application, an Application Centric approach is what I would recommend.
If neither is more important, and each is equally easy to implement, I'd recommend sticking with a Network Centric approach because it gives you better flexibility to later implement L4-7 services and control BUM traffic.
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
03-02-2018 08:32 AM - edited 03-02-2018 08:36 AM
In the legacy networks the vlan represents the forwarding domain for L2 traffic, in comparison with ACI the BD represents the forwarding domain for L2 traffic.
Having said that, one limitation I can think of is when a single endpoint, is configured with multiple IPs to send traffic to multiple vlans, but it uses the same NIC (MAC address) to source the traffic. In this situation endpoint will be flapping between EPGs and this can cause traffic interruptions. To solve this problem you would need to deploy a separate BD per vlan used by this VM instead of a single BD.
03-03-2018 02:53 AM - edited 09-10-2019 03:07 PM
[Edit 2019-09-11: When you've read my answer, scroll down and check out @cweinhold's pictorial approach to answering this question]
Hi Marcelo,
This question has been around in various forms since the 1990s!
But to be specific to ACI, let me tell you about Application Centric Design and Network Centric Design.
Both are valid design strategies, and you can read more of the official Cisco view here. But basically, what you have described is an Application Centric approach. A Network Centric Design would put each EPG in its own Bridge Domain and own Subnet.
Now, back to your question.
What's the pros and cons for using only one Bridge Domain for multiple EPGs?
Assuming you have left the options above at their defaults (which is what happens if you specify Optimize as the Forwarding method when you create the bridge domain) then you will be able to create a larger Bridge Domain than the traditional Broadcast Domain you would have been able to create using traditional networking methods. (Switches/VLANs). But, there are some limitations on those optimised values, and if you need to change them in the future, you may find that your BD suddenly has to cope with more BUM traffic than before. Specifically:
One approach is not necessarily better than the other.
When migrating existing VLANs/Subnets, a Network Centric approach is what I would recommend.
When writing an Orchestration Application, an Application Centric approach is what I would recommend.
If neither is more important, and each is equally easy to implement, I'd recommend sticking with a Network Centric approach because it gives you better flexibility to later implement L4-7 services and control BUM traffic.
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
01-25-2019 02:36 PM - edited 01-25-2019 02:37 PM
Your Server or Application
Your Current Data Center
English Garden (aka "Network-Centric")
Trees remain in place. You have tools to add incremental security improvements around them.
French Garden (aka "Application-Centric")
You cut down all your trees and plant new ones that are all exactly the same shape and height and placed in a prescribed location.
English Garden with some French accents (Hybrid?)
Legacy forest intermixed with some highly-structured areas. 95% of my ACI deployments are Hybrid.
Tenants - ACI's most powerful, unsung feature
Tenants allow you to deploy as many gardens as you want across the same physical & virtual infrastructure with shared northbound networking. You can deploy whatever garden that networking green thumb of yours can dream up!
01-12-2023 09:34 PM
You are awesome.......
01-11-2020 09:43 AM - edited 01-11-2020 10:00 AM
And what about L2 security ? I mean, with a single bridge domain (and a single large subnet over it) with many EPG, how does the fabric mitigates (or not) the risk of arp poisoning ?
Host1 in EPG1 is compromised and send a malicious garp/arp response for every address in the subnet. The arp table of the fabric and the arp table of every endpoint in the BD will be corrupted (if the arp processing mode is "flooding"), am i right ?
Every host in every EPG will be affected, EPG isolation and contracts don't come into play as it happens at a lower level, ie at bridge domain level.
Contracts should still prevent host1 from talking to other hosts in other EPG, but they will be affected as long as the invalid arp entries will be kept in their peers table (who won't be able to talk to the legitimate hosts as they will have the malicious entry sent by host1 in their table, disrupting communication for every affected host).
Am I my missing something because if i am not, application centric configuration (many EPG on same BD) sensibility to L2 attacks could be a big concern :(
03-03-2018 11:15 AM
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