All, When using VLAN Pooling on the RFS7000 does anyone have a good indication of the client side behaviour in the event of clients going to sleep or disappearing off the network for a period of time. Specifically say I have an ESS-ID with 5 VLANs allocated, a client associates and gets put into VLAN 1 and gets an appropriate DHCP address. If that client then goes to sleep when it wakes up will it still be in VLAN 1 or will it go wherever the next available slot is? Is this behaviour dependant on the time that the client has been asleep? What will happen on a roam between 2 APs on 2 different switches in the same cluster? Thanks, IJ
VLAN Pooling// Expert user has replied. |
7 Replies
All, Sorry to revive this thread, but do we have a view of how this works when the switches are in a cluster? Do the switches share the MU information? i.e. assume I have my hold time set for 300 seconds and I have an MU allocated into VLAN 1 on switch 1 If that MU roams out of coverage for a couple of minutes (i.e. within my holdtime) and then roams back into coverage on a different AP on switch 2 would the MU be allocated back into VLAN 1 or would it be allocated the next free slot as perceived by switch 2? Also have we made any changes to this behaviour or functionality in WiNG 5? Thanks IJ
Ian, It's configurable on the switch. By default - we will hold the info about mobile unit for 5 seconds - this is a hold-time for credentials on WLAN configuration. We will hold the rest of the MU info for 30 minutes but you can change it - wlan inactivity-timeout. Basically - if you MU comes back 5 seconds after we de-authed it - it will loose the credential. Again - you can change it - but depending on how many MUs you have and how frequently they roam - it can be dangerous - but possible.
Thanks Alona, That gives us something we can go back to the customer with ... not that I would want to rub their noses in it obviously :P IJ
Chris Described behavior is expected. One additional note. VLAN pooling feature would try to load balance Mobile Stations across the vlans for newly associated device. If a device has been assigned a vlan in the past, and if at the time that device is associated back its cached vlan information is still valid, the device will get its old vlan irrespective of the load. edward
Does that mean if a unit dropped off the network for whatever reason (out of coverage / powered off) for a brief period of time, it should go back into its original VLAN on reassociation? If so how long are the VLAN credentials cached for? The reason for asking is that we have just lost a deal to Cisco, they have started testing the Cisco kit and have run into this problem so it would be nice to go back and highlight the fact that we don't have the issue. Thanks IJ
The behavior you describe Li, is not what I experienced when I tested it. I found that client credentials were not cached in any way, and a client that disconnected from the WLAN was assigned a different VLAN on re-connection in order to maintain the balance of clients across all VLANs. I was running v4.2.
All, I did some quick and dirty testing on this today.
For testing purposes, I set a limit of 2 MUs per VLAN, and 3 VLANs
As each device connected it was placed into a VLAN in a round robin fashion. After 3 devices were connected, there was a device in each VLAN. If one of those MUs was powered off/on, or re-associated with the WLAN, it maintained it's previous VLAN mapping.
However, if while that same device was powered off, ANOTHER MU came along and associated, the switch appeared to load balance and put the new MU into the place of the one that was powered off. This meant that when the original MU was powered back on, it picked up a different VLAN (in order to keep the whole lot balanced).
In the real world with a lot of MUs coming and going all the time, I suspect that we will see MUs moving between VLANs quite often. Radius authentication and VSAs would solve this of course. Chris