hello, i tried to find a document describing it but was not successful.
i understood that on an ACI witch a BD and one EPG is always consuming an internal VLAN. maximum numbr of vlans is 3964 (or similar). therfore you can approx copnfigure 1980 EPGs in network centric mode.
is this correct? i know it is a huge number...but in case of a big migrration an in our case
such an issue might happen.
Hi @Heinz Kern ,
Remember these numbers are PER LEAF SWITCH - so do you think you will have 1980 or more EPG on any individual leaf switch? If so, why have 1980 BD? You don't HAVE to have one BD per EPG...
One of the reasons the whole Software Defined Networking idea is so popular is that (at least in the case of Cisco ACI), it that configuration is pushed DYNAMICALLY as needed to the leaf switches. And if it is no longer needed, it is removed.
So if you have your EPGs spread across multiple switches, it is possible to support up to 21,000 EPGs across all tenants, with a maximum of 4000 EPGs per tenant. (Link)
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.
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
yes, the situation is that we expect 2200 vlans/EPGs on a vmware cluster. so a link needs to transport all of them. with network centric approach we have an issue. in the whole fabric we expect more than 5000 EPGs so we already take usage of doubled vlan-ids on different access-PoDs etc.
i could also understand the question regarding better design of this segmemtation of subnets but we are not able to change it at the moment. so our issue are the 2200 and we need to concentrate on it. the 2200 comes from brownfield migration.
so again...2200 on one link...not possible with network centric? we could move all EPG´s into one BD..right? but what would this mean
Sounds like you're going to need a Hybrid approach. I'd suggest reducing the # of BDs by grouping EPGs together. You can do this while still maintaining a network-centric-ish type of deployment. You can have individual EPGs, and groups of Subnets within BDs. Each BD can have multiple Subnets and happily support single or multiple DHCP relay policies. If you have a single set of DHCP servers (serving all EPGs) then its very simple. If you have separate DHCP Servers for different apps/EPGs, its a little more complex, but still manageable. The only consideration is that the source of the DHCP relay address will always be the primary subnet on the BD (typically this is the first subnet added to a BD, but you can change this with the "Make Primary" config flag.
To contain the broadcast traffic just within the EPGs you can set the "Multi Destination Flooding" option of the BD to "Flood in Encap". This would restrict the flooding within EPGs.
appreciate your response. regarding the broadcast traffic (flood in encap) thanks for that informaiton. this makes sense and sounds good. i did not know this possibility.
regarding DHCP: if a dhcp request comes with the source-ip (primary subnet) different from the requested subnet i am not sure if this works with a dhcp server. honetsly we did never have this use case. maybe 10years ago we had some issues with a secondary ip on a SVI (i would say then this is the same here in ACI). if i remember well this did not work because the source IP is for my understanding the key for the dhcp-server from which subnet the dhcp-ip is retrieved. am i wrong?