01-17-2023 10:09 AM
Hi All,
I'm currently working on an ACI Multipod design and I have some questions regarding best practices for VLAN Pools AAEPs and Domains.
The design is for a single customer/single tenant that requires 1 VRF initially to support their production server network (with roughly 30 VLANs). L2 Outs will be required from Pod 1 to support the migration of servers into ACI and L3 Outs will be required from Pods 1 and 2 to provide IP connectivity back into the customers core network (all external routing preferring the L3 Outs via Pod 1 with Pod 2 as a secondary path). The customer does have a Hyper-V environment, but I dont see the need for VMM integration at this stage.
I am trying to keep the design is as simple as possible (for easy adoption and troubleshooting more than anything) and planning to start with a Network Centric approach (so one VLAN equals one BD + one EPG)
Will the above be possible with just three Domains (one physical, one external bridged and one L3), with one AAEP and one VLAN pool? For example:
VLAN Pool Name: Tenant1_VLAN_Pool
Allocation Mode: Static
VLAN Range: 2-4094
Domain: Tenant1_Domain_Physical
Type: Physical Domain
VLAN Pool: Tenant1_VLAN_Pool
Domain: Tenant1_Domain_L3_Out
Type: Layer 3 Domain
VLAN Pool: Tenant1_VLAN_Pool
Domain: Tenant1_Domain_L2_Out
Type: External Bridged Domain
VLAN Pool: Tenant1_VLAN_Pool
AAEP Name: Tentant1_AEP
Enable Infra VLAN: No
Domains: Tenant1_Domain_Physical, Tenant1_Domain_L3_Out, Tenant1_Domain_L2_Out
Hopefully this make sense. Any guidance would be appreciated.
Solved! Go to Solution.
01-17-2023 11:18 AM - edited 01-17-2023 11:19 AM
Hi @dm2020 ,
Firstly, just my opinion, but
PLEASE DON'T USE ANY L2-OUTS. They are an abomination and should NEVER have been made a thing in ACI.
Phew. That feels better. So let me say it more politely.
Any time you think you need a L2 Domain or L2Out, just use a Physical Domain and regular Application EPG instead. It will achieve exactly the same result but give you future flexibility that just isn't there in L2Outs.
Now to your question.
Will the above be possible with just three Domains (one physical, one external bridged and one L3), with one AAEP and one VLAN pool?
Actually, you only need just TWO Domains (one physical, and one L3), with one AAEP and one VLAN pool.
Your Network Centric approach is also perfectly sound for this task.
You may also glean some more or my ideas from this previous answer I gave to a similar question and maybe even this one or this one
01-17-2023 11:18 AM - edited 01-17-2023 11:19 AM
Hi @dm2020 ,
Firstly, just my opinion, but
PLEASE DON'T USE ANY L2-OUTS. They are an abomination and should NEVER have been made a thing in ACI.
Phew. That feels better. So let me say it more politely.
Any time you think you need a L2 Domain or L2Out, just use a Physical Domain and regular Application EPG instead. It will achieve exactly the same result but give you future flexibility that just isn't there in L2Outs.
Now to your question.
Will the above be possible with just three Domains (one physical, one external bridged and one L3), with one AAEP and one VLAN pool?
Actually, you only need just TWO Domains (one physical, and one L3), with one AAEP and one VLAN pool.
Your Network Centric approach is also perfectly sound for this task.
You may also glean some more or my ideas from this previous answer I gave to a similar question and maybe even this one or this one
01-17-2023 01:40 PM
Hi @RedNectar
Thank you for the advice. I have a fair bit of learning to do with ACI (and its coming together slowly) and your response has been extremely helpful.
A few other questions if you dont mind. I am proposing to configure the L3 Out within the customers tenant. I have reviewed various ACI designs whereby the L3 Out is configured in the common tenant, however I'm assuming that this is only applicable when multiple tenants will be used so that the L3 Out can be shared? In my example, is it perfectly acceptable to configure the L3 Out within the customers tenant? Am I limiting myself/causing any restrictions here?
The ACI fabric will be stood up using out-of-band management connectivity. Reading through various implementation guides, in-band management is also configured. This requires an additional L3 Out within the mgmt tenant, however I have not found any conclusive reasons why I need to use in-band management. Maybe its my lack of understanding/experience, but is there are good reason why in-band management is required? Again for simplicity, I would prefer not to configure it if it is not required.
Thanks Again
01-17-2023 04:23 PM
Hi again @dm2020 ,
Thank you for the advice. I have a fair bit of learning to do with ACI (and its coming together slowly) and your response has been extremely helpful.
NP
A few other questions if you dont mind. I am proposing to configure the L3 Out within the customers tenant. I have reviewed various ACI designs whereby the L3 Out is configured in the common tenant, however I'm assuming that this is only applicable when multiple tenants will be used so that the L3 Out can be shared? In my example, is it perfectly acceptable to configure the L3 Out within the customers tenant? Am I limiting myself/causing any restrictions here?
It is perfectly acceptable to configure the L3Out in the customer tenant. IF it is configured in the common tenant, then it WILL ALWAYS be available to ALL tenants (although no tenant is FORCED to use it, and some tenants may have incompatible internal config - such as a BD using the same subnet as the L3Out.) So the common tenant is a good option if say you are providing a common Internet gateway for ALL tenant to use IF they wish.
On the other hand, if the L3Out is configured in one tenant, it can be shared with other tenants if you like, but that config gets a bit tricky.
The ACI fabric will be stood up using out-of-band management connectivity. Reading through various implementation guides, in-band management is also configured.
This requires an additional L3 Out within the mgmt tenant,
Actually, that's not true. But that's not relevant (Google rednectar In-Band Management ACI)
however I have not found any conclusive reasons why I need to use in-band management. Maybe its my lack of understanding/experience, but is there are good reason why in-band management is required? Again for simplicity, I would prefer not to configure it if it is not required.
By all means, configure OOB as the primary management method. But there ARE some compelling reasons why you might want to also configure In-band management as well
01-17-2023 04:52 PM
While inband management is required for NDFC and Insights, it's optional for the Orchestrator service. Out-of-band reachabilty is if fine if that's the only service you're running on ND. Regardless, its a good idea to configure so you don't have to re-jig things if you add Insights service to Orchestrator-managed sites.
Robert
01-19-2023 04:06 PM
Thanks both, very helpful
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: