Amit,
I'll give you the long answer so you understand the relevance of the feature. In UCSM each Fabric Interconnect has a Port-VLAN count limiation. The Port VLAN count is a total of each & every VLAN allowed on each vNIC in the system, plus the # of VLANs allowed on each border interface (uplink). These have been slowly increased across versions from 3000 -> 6000 -> 14000 -> 32000 now in version UCSM 2.1 (with VLAN compression disabled)
You can see what your VLAN port limit is with
UCS-6296-A# scope fabric-interconnect a
UCS-6296-A /fabric-interconnect # show vlan-port-count
VLAN-Port Count:
VLAN-Port Limit Access VLAN-Port Count Border VLAN-Port Count Alloc Status
--------------- ---------------------- ---------------------- ------------
32000 18 20 Available
[After enabling VLAN compression]
UCS-6296-A /fabric-interconnect # show vlan-port-count
VLAN-Port Count:
VLAN-Port Limit Access VLAN-Port Count Border VLAN-Port Count Alloc Status
--------------- ---------------------- ---------------------- ------------
64000 18 20 Available
As you can see just by enabling VLAN Compression, my PV count greatly increases. In my lab example above I have barely anything configured, so let's take a real world example . Let's say your UCSM domain looks something like this:
VLANs created: 100
VLANs allowed on each vNIC: 100
vNICs per Service Profile: 2
Service Profiles: 50
Uplink (Border) Interfaces per FI: 2 (Non port-channeled)
The PV count would be calculated as:
(100 VLANS * 4 vNICs per Service Proflie * 50 Service Profiles) + (100 VLANs * 2 Uplink Interfaces)
= 20200
And you can see, if you had more VLANs, vNICs, or service profiles, the count woudl increase accordingly. This is why its best practice to only allow VLANs the service profile host needs. The customers that hit this limiation are usually multi-tenant cloud providers where they need to allow all VLANs on all hypervisor vNICs to allow their tenants VM resources to be migrated to any host. Another case where this limitation can be hit is with the Nexus 1000v, where the VLAN provisioning occurs at the N1K level and all VLANs need to be passed soutbound from UCSM to the N1K.
So why does this matter? Well the higher the vlan port count the more processing strain it puts on the system managing all the internal counts & VLAN states. With this new feature UCSM will automatically map the state of multiple VLANs into a single state or "group" which greatly reduces the CPU load on the system and allows us to safely increase the overall PV count.
To enable this feature simply go to the "LAN" tab in UCSM, click on "LAN Cloud" on the left navigation pane, click on the "Global Policies" tab on the right pane and you'll see a radio button for "VLAN Port Count Optimization" Enabled/Disabled. Once enabled - that's it! UCSM will to all the magic of creating the VLAN groups transparently within the system and optimize the PV count for you.
**Since this is a new feature, it will be disabled by default for both upgrades and new installs. In future releases this default may be changed.
Hope this helps! - Let me know if you have any questions.
Regards,
Robert
