cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1988
Views
25
Helpful
5
Replies

ACI VLAN Pool, AAEP and Domain Best Practises

dm2020
Level 1
Level 1

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.

 

1 Accepted Solution

Accepted Solutions

RedNectar
VIP
VIP

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?

ANSWER:

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.

Here's some more tips:

  1. Don't use a VLAN range of 2-4095 at the get go.  Or if you do, add them as several smaller ranges (a VLAN Pool can have many ranges added).
    • The reason for this is that it is VERY EASY to add more VLANs to a VLAN pool.  It is IMPOSSIBLE to remove a VLAN from a VLAN pool without removing the entire range. So if you DO need to allocate some Dynamic VLANs at a later date (which is reasonably likely) you'll have some spare VLAN ranges to do so.
    • There are certain cases where overlapping VLAN pools can cause a problem, so if you ever need a 2nd Static VLAN pool, it will overlap with this one.
    • Having said that, when it comes to Static VLAN pools, YOU are in control, so any overlapping you do is your fault. Since you have effectively ALWAYS had a VLAN range of 2-4095 on every switch since 1998, and have coped so far, you can probably continue to cope with one VLAN Pool with all VLANs
  2. As I mentioned above, don't use L2 Outs. Create an Application Profile in your Tenant1 and add 30 Bridge Domains (one for each subnet) and 30 EPGs (one for each VLAN).
    • But there is nothing wrong with having fewer BDs and giving the BDs multiple default gateway addresses. One BD with 30 IP Addresses is probably going too far, but be aware that you have this additional level of segregation at your disposal.  Initially, you probably won't use it. Just be aware that it is possible. And should you find that you have say two subnets that you want to have full communication with each other forever, you can actually create just one BD and one EPG for those two subnets. Since they are in the same EPG they will always have full communication.
  3. There's also nothing wrong with having a 2nd VLAN Pool just for the L3Out. Some people find this neater. I have mixed feelings.
  4. Finally, I love your names, and appreciate your great descriptive names, and the fact that you've avoided the hyphen character in your names.
    • But as much as I love your names, you might consider abbreviating them a bit, simply because when you see lists of say EPGs you may only see the first 6 or so letters - now you can always make columns wider etc.  One way to do this is to use the colon or period character in names rather than the underscore in some places. For example, I'd probably call the L3 Domain in your example
    • Tenant1_L3Dom or Tenant1:External_L3Dom or T1:Ext_L3Dom
      • I'd use the term L3Dom rather than Domain_L3_Out because ACI is now fairly consistent with calling these objects L3 Domains RedNectar_0-1673981180027.png
      •  I'd actually use AAEP in the name of the AAEP rather than just AEP.  This is part of my personal vendetta agains Cisco for using stupid and confusing abbreviations
    • These are purely aesthetic suggestions and in no way influences the design

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

RedNectar aka Chris Welsh.
Forum Tips: 1. Paste images inline - don't attach. 2. Always mark helpful and correct answers, it helps others find what they need.

View solution in original post

5 Replies 5

RedNectar
VIP
VIP

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?

ANSWER:

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.

Here's some more tips:

  1. Don't use a VLAN range of 2-4095 at the get go.  Or if you do, add them as several smaller ranges (a VLAN Pool can have many ranges added).
    • The reason for this is that it is VERY EASY to add more VLANs to a VLAN pool.  It is IMPOSSIBLE to remove a VLAN from a VLAN pool without removing the entire range. So if you DO need to allocate some Dynamic VLANs at a later date (which is reasonably likely) you'll have some spare VLAN ranges to do so.
    • There are certain cases where overlapping VLAN pools can cause a problem, so if you ever need a 2nd Static VLAN pool, it will overlap with this one.
    • Having said that, when it comes to Static VLAN pools, YOU are in control, so any overlapping you do is your fault. Since you have effectively ALWAYS had a VLAN range of 2-4095 on every switch since 1998, and have coped so far, you can probably continue to cope with one VLAN Pool with all VLANs
  2. As I mentioned above, don't use L2 Outs. Create an Application Profile in your Tenant1 and add 30 Bridge Domains (one for each subnet) and 30 EPGs (one for each VLAN).
    • But there is nothing wrong with having fewer BDs and giving the BDs multiple default gateway addresses. One BD with 30 IP Addresses is probably going too far, but be aware that you have this additional level of segregation at your disposal.  Initially, you probably won't use it. Just be aware that it is possible. And should you find that you have say two subnets that you want to have full communication with each other forever, you can actually create just one BD and one EPG for those two subnets. Since they are in the same EPG they will always have full communication.
  3. There's also nothing wrong with having a 2nd VLAN Pool just for the L3Out. Some people find this neater. I have mixed feelings.
  4. Finally, I love your names, and appreciate your great descriptive names, and the fact that you've avoided the hyphen character in your names.
    • But as much as I love your names, you might consider abbreviating them a bit, simply because when you see lists of say EPGs you may only see the first 6 or so letters - now you can always make columns wider etc.  One way to do this is to use the colon or period character in names rather than the underscore in some places. For example, I'd probably call the L3 Domain in your example
    • Tenant1_L3Dom or Tenant1:External_L3Dom or T1:Ext_L3Dom
      • I'd use the term L3Dom rather than Domain_L3_Out because ACI is now fairly consistent with calling these objects L3 Domains RedNectar_0-1673981180027.png
      •  I'd actually use AAEP in the name of the AAEP rather than just AEP.  This is part of my personal vendetta agains Cisco for using stupid and confusing abbreviations
    • These are purely aesthetic suggestions and in no way influences the design

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

RedNectar aka Chris Welsh.
Forum Tips: 1. Paste images inline - don't attach. 2. Always mark helpful and correct answers, it helps others find what they need.

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

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

  1. If you deploy Nexus Dashboard in the future, it will REQUIRE an In-band management connection
  2. If you want to configure L3Out access to the ACI management, you'll need In-band management
RedNectar aka Chris Welsh.
Forum Tips: 1. Paste images inline - don't attach. 2. Always mark helpful and correct answers, it helps others find what they need.

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

dm2020
Level 1
Level 1

Thanks both, very helpful

Save 25% on Day-2 Operations Add-On License