cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
10888
Views
45
Helpful
3
Replies

Best Practices for Vlan Pools, Domains and AAEP

eric.ahernandez
Level 1
Level 1
Hi everyone, we’re working on an ACI design and I have some questions about the best practices regarding Vlan Pools, Physical Domains and AAEP, for now we’re working on phase 1 which is Network Centric Approach. According to the Best practices guide the recommendations are to keep it simple (like 1 phys domain, 1 routed domain, 1 bridged domain per tenant), 1 AAEP per tenant unless you have vmm integration you need another AAEP with infra VLAN, etc. I attached the info I found on the Guide to this post for reference.
 
I was wondering if anyone can give me some input regarding this according to your experiences and what are the considerations. Thanks a lot in advance.
1 Accepted Solution

Accepted Solutions

Hi Eric,

Yes - definately hard to get you head around!!

Regarding the 1 VLAN=1 EPG/BD - go for it. It is the simplest to understand and pretty easy to change later if you want.

Regarding AAEPs, Domains and VLAN Pools.  When it comes to static VLANs, you can almost say it is safe to have one massive STATIC pool with say VLANs 2-4095 in it, becuase these VLANs will not be used until someone allocates them statically somewhere, which pretty much equates to the situation you live with today. But DYNAMIC VLAN pools need to be managed much more closely, because once a VLAN is in the range of a Dynamic Pool, it is pretty much ruled out for use for a static allocation. So BEST PRACTICE is to a) Not overlap static and dynamic pools, and therefore b) be a little conservative when creating static VLAN pools to gice yourself future wiggle room for dynamic pools. Remember that if you have a static pool of say 100 VLANs, it is a 5 second job to add another 100. But if you start with a pool of 3000, it is VERY hard to reduce it. Same for Dynamic pools.

Keeping the number of Domains and AAEPs to a minimum is also a good idea. One per Tenant is a good target. The fewer there are, the easier it is to troubleshoot. Only allocate additional AAEPs and Domains if you can't possibly use an existing one. If unsure, try to reuse one you have.

As for the rest of the Access Policy Chain, it is also best to have:

ONLY ONE Leaf/Switch Profile per VPC Pair of switches (plus one per leaf for each leaf that has single atached hosts)

ONLY ONE INTERFACE profile per Leaf/Switch profile. Add lots of INTERFACE SELECTORS to this interface profile, one at a time (one per VPC/one per Single Attached host)

ONLY ONE VPC INTERFACE POLICY GROUP per VPC. This allows you to give the VPC a meaningful name like L1101..1102:1:9..10_VPCIPG which defines the VPC attached to Leaves 1101 and 1102 with 2 interfaces on each leaf (1/9-10) in the VPC

Then the VPCIPG liks to you one AAEP, and maintenance consists of occassionally adding new INTERFACE SELECTORs to an INTEFACE PROFILE and a new VPC INTERFACE POLICY GROUP for that VPC.

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


 

 

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

3 Replies 3

RedNectar
VIP
VIP

Hi @eric.ahernandez ,

This is a question that deserves much more detail than I have time to give right now, I'll try and expand later if I get time.

The references you referred to are pretty much on the ball.  (I've included them inline below to make it easier for others to read and hopefully comment).

Typically with a "Network Centric" approach though, you have multiple Bridge Domains - One BD+One EPG=One lagacy VLAN.  But there is nothing wrong with putting all (or multiple collections of) VLANs in the same BD.

The AAEP is a hard one to understand.  It is the meeting place for a collection of entites that define ports, and another collection that define ranges of encapsulations (VLANs/VXLANs).  I sometimes call it the "Attachable Access Entity Party" (If you do a search for "Attachable Access Entity Party" (with quotes) you might find more)

 

VlanPool.pngDomains.pngAAEP.png

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 Chris,

 

Thanks a lot for your input. As you said, right now on phase 1 we'll be doing a Network Centric Approach and we'll be mapping every legacy VLAN to a different EPG and a Bridge Domain. We have some questions about the design of vlan pools, physical domains and AAEPs.

 

For example, per the guidelines we could create only 1 AAEP (without infra VLAN enabled), create 1 physical domain per tenant (right now we'll be working on only 1 tenant, but in the future there may be more), 1 or more vmm domains if needed and assign all those physical and virtual domains to that AAEP. We could make a second AAEP but only if we need something with infra VLAN enabled like AVE integration, or if the VLAN Pools overlap we would need a different AAEP (as I understand it).

 

And for the VLAN Pools, create a Pool with a big range for static allocation and a Pool for dynamic allocation with a range of 200+ for VMM Integration. I understand it is dependant on the scenario and it's a matter of preference as well when dealing with these kind of ACI Constructs, it's hard to wrap my head around them sometimes.

Hi Eric,

Yes - definately hard to get you head around!!

Regarding the 1 VLAN=1 EPG/BD - go for it. It is the simplest to understand and pretty easy to change later if you want.

Regarding AAEPs, Domains and VLAN Pools.  When it comes to static VLANs, you can almost say it is safe to have one massive STATIC pool with say VLANs 2-4095 in it, becuase these VLANs will not be used until someone allocates them statically somewhere, which pretty much equates to the situation you live with today. But DYNAMIC VLAN pools need to be managed much more closely, because once a VLAN is in the range of a Dynamic Pool, it is pretty much ruled out for use for a static allocation. So BEST PRACTICE is to a) Not overlap static and dynamic pools, and therefore b) be a little conservative when creating static VLAN pools to gice yourself future wiggle room for dynamic pools. Remember that if you have a static pool of say 100 VLANs, it is a 5 second job to add another 100. But if you start with a pool of 3000, it is VERY hard to reduce it. Same for Dynamic pools.

Keeping the number of Domains and AAEPs to a minimum is also a good idea. One per Tenant is a good target. The fewer there are, the easier it is to troubleshoot. Only allocate additional AAEPs and Domains if you can't possibly use an existing one. If unsure, try to reuse one you have.

As for the rest of the Access Policy Chain, it is also best to have:

ONLY ONE Leaf/Switch Profile per VPC Pair of switches (plus one per leaf for each leaf that has single atached hosts)

ONLY ONE INTERFACE profile per Leaf/Switch profile. Add lots of INTERFACE SELECTORS to this interface profile, one at a time (one per VPC/one per Single Attached host)

ONLY ONE VPC INTERFACE POLICY GROUP per VPC. This allows you to give the VPC a meaningful name like L1101..1102:1:9..10_VPCIPG which defines the VPC attached to Leaves 1101 and 1102 with 2 interfaces on each leaf (1/9-10) in the VPC

Then the VPCIPG liks to you one AAEP, and maintenance consists of occassionally adding new INTERFACE SELECTORs to an INTEFACE PROFILE and a new VPC INTERFACE POLICY GROUP for that VPC.

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


 

 

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.
Getting Started

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:

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