vlan groups

  • 2
  • Idea
  • Updated 2 years ago
  • Under Consideration
It would be great if groups of vlans could be assigned to ssids, classifiers, etc.

currently they only function in the bonjour gateway

a certain vendor that begins with a C has something called interface groups which allows you to group several interfaces[vlans] under the interface group and then performs a round robin distribution of the vlans. This allows you to scale up for large groups.
Photo of Andrew MacTaggart

Andrew MacTaggart, Champ

  • 483 Posts
  • 86 Reply Likes
  • Ruby Tuesday

Posted 4 years ago

  • 2
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Would hashing based on the client's MAC address that is rounded to a VLAN not be better than a round robin distribution?
Photo of Terence Fleming ThinkWireless

Terence Fleming ThinkWireless, Champ

  • 79 Posts
  • 27 Reply Likes
Hashing on the client's MAC has the advantage that the device always gets put into the same VLAN when they connect: however it also has the (possible) disadvantage that devices won't be evenly allocated to VLANs .  Also note that a group of 300 MAC addresses split into three groups of hashed MACs will not have 100 MACs in each group, as the hash is not truly random, which means that the sub-groups have to be large enough to accommodate some variation.

But given that other vendors chose the MAC hashing route there are probably some good advantages to always getting put in the same VLAN so I am with you Nick.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
You could actually have an algorithmic weighting/tuning of the hash based on the MAC addresses that are encountered over time with that weighting/tuning taking effect in a gradual and graceful way.
Photo of Carsten Buchenau

Carsten Buchenau, Champ

  • 356 Posts
  • 117 Reply Likes
Hmmm... I would think that the main reason those vendors implemented this feature was to solve the problem of all user vlans being bridged at the controller, and thus overloading a L2 domain. When the traffic is bridged at the Access Point, we do not have this limitation as we can implement location based VLAN zones and use Aerohive's classifier maps to assign the proper VLANs.

Maybe I am missing a point here? But it appears to me that the only reason to support this would be for those existing installations that have this implemented and want to ditch their Controller (which actually might be a good reason for Aerohive to implement this, just for the transition :-)).

But would there ever be a reason for implementing VLAN pooling like this in a new installation with Aerohive?

Just my thoughts...
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
I do not think that this is particularly needed and cannot see myself using something like this. I was just making the point that conceptually hashing is likely to be better than a round robin approach due to the consistency of the VLAN that is assigned to a client.
(I have just seen that this very point is also in discussion 'elsewhere'!)
(Edited)
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
VLAN pooling is offered by other vendors than just the big C and it's probably not a bad idea to be able to implement it. I can't see myself rolling out a WEP-secured SSID, but I still have the option to if for some reason I need or want to, you know? 
Photo of Terence Fleming ThinkWireless

Terence Fleming ThinkWireless, Champ

  • 79 Posts
  • 27 Reply Likes
Location based VLANs are a really useful feature in their own right, but I do not believe they address the fundamental problem that Andrew's idea seeks to address, of how to split a large group across multiple VLANs.

Simple reason being, that the "large group" in question has some common factor amongst the members of the group (that's why they are a group, after all), and it is often easy to imagine a situation where sufficient of the group members could be in the same place at the same time to overwhelm a location based VLAN
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
Yeah, it's possible that you'd want to implement pools of location-based VLANs. I can definitely see that.
Photo of Mike Kouri

Mike Kouri, Official Rep

  • 1030 Posts
  • 271 Reply Likes
+Carsten Buchenau was spot-on about the general feelings regarding VLAN Groups here at corporate, and why we haven't implemented that before now. 

The idea about implementing them as an aid for customers migrating from other vendor solutions to ours is interesting, and we'll take that into consideration when planning future developments. My immediate knee-jerk reaction was that if we make it too easy for people to leave the training wheels on then they'll never learn to ride the bike properly, but I'll discuss it with my PLM peers and my brain-trust folks. 
Photo of Dominic Russell

Dominic Russell

  • 10 Posts
  • 0 Reply Likes
I don't suppose this feature has been added?

We have a small site that has a similar need for this, 2 APs and 30 clients, we can only get a 5Mb DSL line to fuel the Wi-fi, adding VLAN pooling would allow us to add another DSL line to share the load.

We also have a larger site that utilities the AP tags to put clients into different VLANs, that works very well for us.
(Edited)