VLAN Pool limitations

[doridor]

Hey, I can't find any information on the capacity of a VLAN Pool with regarding to the amount of encap blocks that can be added to one pool, If any one has any information about this I would love to know

The reason I need to get this number is because I don't wont to allocate any vlan ranges, I want to have the capability to change vlans between domains without any problems, due to the fact I cant have any downtime, I don't want to declare a large pool which i will then need to delete in order to move a Vlan to another pool. I work with automations anyway so managing the pool with single entries wont be an issue.

If any one has any suggestions on how to better handle this issue I would love the hear,
thanks in advance

[Robert Burns]

I'd be curious to hear about your use case.  Are you operating multi-tenancy and/or multi-AEPs?  Having a large single VLAN pool is usually the way to go, unless you need to restrict them to particular users. Multiple VLAN pools usually follows the necessity for multi domains (VMM, L3, Physical etc).  RBAC can be applied to domains, and in turn, VLAN pools, but beyond this, I don't often see multiple domains of the same type in most average deployments.

A large single VLAN pool can associated with an AEP - which just permits the VLAN on the respective interfaces.  It doesn't automatically enable it though. t's still required to configure the EPG static path with appropriate VLAN ID before it can be utilized.

You could automate encap blocks addition/removal, but typically these are fairly static.  I'd like to hear more about the necessity of this before going towards an overly complicated solution.

Robert

[doridor]

Hi Robert,
I'll explain our situation in simpler way, We have one VLAN pool for our physical domain which is used in the entire fabric. we have other pools which are used for layer3 connectivity, Service graph and so on ... We want to be as flexible as possible, meaning we want to have the capability to delete a vlan from the pool at a moments notice. I understand it is not a use-case that occurs often, but I don't want any limitations that can cause downtime. I figured that the best idea would to add many encap blocks to the VLAN pool instead of a large range. Even though it will be harder to manage, we work with automations so there is no overhead in man hours.

[RedNectar]

Hi @doridor ,

I'm not sure if there is a limit, but we have 404 ranges in one VLAN pool, mainly because the script my colleague used to add them did it that way.

I'm guessing you are trying to make your VLAN pools as flexible as possible, while keeping in mind the guidelines from the ACI Best Practices Summary white paper which says (red emphasis is mine)

VLAN Pool

A VLAN Pool decides which VXLAN ID (VNID) is assigned to each VLAN. For example, VLAN 10 from VLAN pool A and VLAN pool B will be assigned different VNID. AEPs represent a group of interfaces on Cisco ACI switches. The Cisco APICs decide which VLAN pool to use for which VLAN on which interface based on domains such as physical domain that tie a VLAN pool and AEPs.

The best practice is to configure minimum number of VLAN pools to avoid overlapping VLAN ranges.

Where

·         Fabric > Access Policies > Pools > VLAN

Options/Notes

·         When there are multiple VLAN pools with overlapping VLAN ID ranges tied to the same AEP, VNID assignments may be indeterministic and cause various issues to endpoint learnings, STP BPDU flooding, and so on.

·         Ultimately, one or two VLAN pools for the entire fabric may be enough if you do not need features that require different VLAN pools, such as per-port-VLAN.

·         Consider Enforce EPG VLAN Validation under System > System Settings > Fabric Wide Setting (available starting in the 3.2(6) release), which prevents two domains containing overlapping VLAN pools from being associated to the same EPG. If you are familiar with the VNID assignment logic and need to use overlapping VLAN pools on purpose, you do not need this validation. Otherwise, we recommend that you enable this option.

So keeping you ranges small is probably a good idea, but making them as small as one VLAN per entry may be a little excessive, but then again if you are using a script to create them, why not.

I've expressed my ideas on the topic in an earlier post

[Gilad Meirovich]

Hi @doridor

Following @RedNectar's reply you should also consider how You manage vlan pools with a relevant "Scalability Guide" such as https://www.cisco.com/c/en/us/td/docs/dcn/aci/apic/5x/verified-scalability/cisco-aci-verified-scalability-guide-523.html
to take into account Your fabric's limitations

[doridor]

Hi gilad, thanks for the link,
could you direct me to the part about vlan pools if there is one, I can't seem to find it

[Claudia de Luna · Accepted solution]

I understand exactly why you are asking.  In fact I alway recommend this, if feasible, in all my ACI builds.   That is, enumerate each vlan in the static pool rather than add via ranges for just exactly the reason you state. So rather than create a static pool with 100 - 105, I will create a pool with 100, 101, 102,103,104, and 105.  If, for whatever reason, I need to put Vlan 102 in another domain, no problem.  If it was in a range, problem!   I recommend this because that has happened to me.

I just did some testing on my simulator and it looks like 4096 is the max as you would expect with12 bits used in 802.1q.  You can see the transition from successful posts to failed ones in the log of my script to push 4999 vlans.

====================POST Action: Adding VLANs POST Object: 4094 - 4094
Status Code: 200
Reason: OK
========================================
====================POST Action: Adding VLANs POST Object: 4095 - 4095
Status Code: 200
Reason: OK
========================================
====================POST Action: Adding VLANs POST Object: 4096 - 4096
Status Code: 400
Reason: Bad Request
	 Error Text: unknown property value uni/infra/vlanns-[GDL-Legacy-POOL]-static/from-[vlan-4096]-to-[vlan-4096], name dn, class fvnsEncapBlk [(Dn0)] Dn0=, 
========================================
====================POST Action: Adding VLANs POST Object: 4097 - 4097
Status Code: 400
Reason: Bad Request
	 Error Text: unknown property value uni/infra/vlanns-[GDL-Legacy-POOL]-static/from-[vlan-4097]-to-[vlan-4097], name dn, class fvnsEncapBlk [(Dn0)] Dn0=, 

This makes sense (to me)...regardless of our ability to put a range in, under the hood the fabric will need to enumerate.  Strictly speaking we should not be able to go higher than 4095 and my test in the simulator shows that we are not unnecessarily limited by the interface.  At the end of the day, this is what I would expect for any network device, ACI fabric or otherwise.

If you look at the Scalability guide @Gilad Meirovich provided, while its not specifically stated, I'd focus on the Fabric Topology > Configurable Options table and see if you are going to hit any of those limits. 

Not an authoritative answer I know, more of a practical one, but I hope it helps.

[doridor]

This was extremely helpful, thank you very much!!!

[RedNectar]

Thanks for the kudos @doridor - but double thanks to @Claudia de Luna for doing the final step that I was too lazy to do - i.e. actually TEST to see if there was a limitation.