Wireless Access

We're having issues with our DHCP scopes nearing their thresholds constantly.  I'm curious if anyone is doing this differently or has any recommendations.  This is really a 2 part question.  

The first part involves the mechanism of how the controller assigns a user to a VLAN on the trunk.... we have 6 /23 VLANS at each campus.  It seems that some DHCP scopes fill up way faster than others despite all 6 being identical in every way.  If it was a round-robin process we wouldn't see such different percentages of DHCP scopes used up that we do.

The second part is just a curiosity of how are other's doing this and anyone recommend any other way?  Like I said, we have 6 /23's under a VAP... we want to leave routing to the router and leave DHCP to the DHCP server.

Please let me know if any other info is necessary or I'm unclear on anything, thanks!

Are you using VLAN Pooling or just assiging the 6 VLANs to the VAP?

-Mike

What version of code are you running? 

By default vlan pooling assigns based on a hash algorithm. Here are the details from the Campus WLAN VRD 

=======================================================================================

"To determine which pool to put the user into, the user MAC address is run through a hash algorithm. The

output of this algorithm places the user into one of the VLANs in the pool and ensures that the user is always
placed into the same pool during a roaming event. As the user associates with the next AP, the address is
hashed. The user is again placed into the same VLAN on the new AP, because the hash algorithm generates the
same output as before. The user can continue to use their existing IP address with no break in their user
sessions.

The hashing algorithm does not place users into the available pool of VLANs in a
round-robin method. Ten clients that join a WLAN are not load balanced equally
among the VLANs. Instead, the distribution is based on the output of the hash. One
VLAN might have more users than the others. For example, consider 150 clients that
join a WLAN with just two VLANs in the pool and with 80 addresses per VLAN available
for clients. Based on the output of the hashing algorithm, 80 clients are placed in one
VLAN and 70 in the other. When the 151st client joins, the output of the hash might
place the client in the VLAN whose scope of 80 addresses has already exhausted. The
result is that the client cannot obtain an IP. To avoid such a rare situation, the network
administrator should design pools with sufficient number of user VLANs and DHCP
scopes to accommodate the user density."

=======================================================================================

Starting with version 6.1.3.0, you can have even assignment of vlan pool among the users. 

(config) #vlan-name <vlan-name> pool assignment even

Regards,

--

HT

Ah, sorry.  Posted around the same time you did.  

We are running 5.0.4.5

VLAN pooling means putting more than one VLAN in the VAP.  You can put a VLAN pool name in the VAP and then assign multiple VLANs to the pool.  That is just two ways of doing VLAN pooling.

---

@mleja2 wrote:

Ah, sorry.  Posted around the same time you did.  

 

We are running 5.0.4.5

---

As mentioned in the previous post, starting 6.1.3.0, even vlan pool assignment feature is available. The latest ArubaOS code available on the support site is 6.1.3.1. 

The controller will use some type of algorythm on the mac address to assign each client to a VLAN.  You very well may see uneven loading on the VLANs in your pool.  It should be close to balanced, but if the mac addresses hash a certain way, I have seen VLANs that are much more utilized than others.

There may be an option, in future ArubaOS, to do a round robin assignment and therefore balance VLANs better. 

While this may sound better, the hash function ensures that a mac address always goes into the same VLAN.  If you assign them based on round robin, there is no guarantee that a client will be in the same VLAN from session to session (connect/disconnect), day to day or controller to controller.

To answer your other question, lots of customers use VLAN pooling (putting more than one VLAN in the VAP).  The overloading issue is known and will be addressed by round robin assignment.

I found this excerpt in the VRD which I'm assuming you got your response from as well:

The hashing algorithm does not place users into the available pool of VLANs in a
round-robin method. Ten clients that join a WLAN are not load balanced equally
among the VLANs. Instead, the distribution is based on the output of the hash. One
VLAN might have more users than the others. For example, consider 150 clients that
join a WLAN with just two VLANs in the pool and with 80 addresses per VLAN available
for clients. Based on the output of the hashing algorithm, 80 clients are placed in one
VLAN and 70 in the other. When the 151st client joins, the output of the hash might
place the client in the VLAN whose scope of 80 addresses has already exhausted. The
result is that the client cannot obtain an IP. To avoid such a rare situation, the network
administrator should design pools with sufficient number of user VLANs and DHCP
scopes to accommodate the user density.

This was in the VLAN Pooling portion of the doc.  Yeah, we to clarify your last statement VLAN Pooling and simply assigning mutliple VLANs to a VAP are two different things, correct? If so then why am I allowed to do one of each?  (Hope you understand what I'm talking about)...  but if they're not the same thing, then what is the benefit of one over the other?

The hashing feature makes sense, thanks for explaining that.