Force a new DHCP lease when roaming between vSZ APs
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-22-2015 10:58 AM
Hi all,
Does anyone know of a way to force a client to pull a new DHCP lease every time they roam to a new AP? vSZ version 3.2
Does anyone know of a way to force a client to pull a new DHCP lease every time they roam to a new AP? vSZ version 3.2
5 REPLIES 5
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-22-2015 12:01 PM
Well I sorta answered my own question from the manual. In practice, have any of you used this option? Does it cause any unintended consequences?
• Force DHCP: Enable this option to force clients to obtain a valid IP address from DHCP within the specified number of seconds. This prevents clients configured with a static IP address from connecting to the WLAN. Additionally, if a client performs Layer 3 roaming between different subnets, in some cases the client sticks to the former IP address. This mechanism optimizes the roaming experience by forcing clients to request a new IP address
• Force DHCP: Enable this option to force clients to obtain a valid IP address from DHCP within the specified number of seconds. This prevents clients configured with a static IP address from connecting to the WLAN. Additionally, if a client performs Layer 3 roaming between different subnets, in some cases the client sticks to the former IP address. This mechanism optimizes the roaming experience by forcing clients to request a new IP address
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-22-2015 02:24 PM
Thumbs up for discovering the Force DHCP option on the WLAN, to help clients that roam between different subnets.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-29-2016 03:54 PM
For my understanding, this option will not make a big difference in case of L3 roaming:
1. clients with incorrect static address don't have access to network anyway.
2. If client sticks to previously received DHCP address, this option will not allow clients to connect to WLAN on a new AP bridged to different VLAN (as it is not requested new IP from DHCP server). But this client doesn't have access to WLAN anyway, as his IP is wrong for this VLAN.
So nit has no much effect on this sticky clients. Otherwise ""Force DHCP" feature is very usefull - to avoid users playing with static IPs.
Sticking to old IP primarly become a problem for laptops or tablets which are put to sleep and moved to other building or site, where same SSID is bridget to different VLAN. You can't prevent problem completely (it is actually problem of client and network design mainly), but you can make shorter DHCP lease time to limit damage.
Even better way is to use tunneled WLANs, when you need same SSID on different sites and with different IP addressing, and some users often move between this sites. Also you can use them in areas where L3 roaming really happens fast and often. Usually you prefer to avoid such situation from the very beginning, keeping this in mind when designing networks, and use VLAN pooling instead of L3 roaming feature in a big sites with intensive roaming, many users and APs.
Hope it helps.
1. clients with incorrect static address don't have access to network anyway.
2. If client sticks to previously received DHCP address, this option will not allow clients to connect to WLAN on a new AP bridged to different VLAN (as it is not requested new IP from DHCP server). But this client doesn't have access to WLAN anyway, as his IP is wrong for this VLAN.
So nit has no much effect on this sticky clients. Otherwise ""Force DHCP" feature is very usefull - to avoid users playing with static IPs.
Sticking to old IP primarly become a problem for laptops or tablets which are put to sleep and moved to other building or site, where same SSID is bridget to different VLAN. You can't prevent problem completely (it is actually problem of client and network design mainly), but you can make shorter DHCP lease time to limit damage.
Even better way is to use tunneled WLANs, when you need same SSID on different sites and with different IP addressing, and some users often move between this sites. Also you can use them in areas where L3 roaming really happens fast and often. Usually you prefer to avoid such situation from the very beginning, keeping this in mind when designing networks, and use VLAN pooling instead of L3 roaming feature in a big sites with intensive roaming, many users and APs.
Hope it helps.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-30-2016 10:01 AM
I think it will likely be helpful. Most clients don't consider roaming from BSSID to BSSID as grounds for re-checking gateway connectivity / requesting a new IP.
So, if this option is checked, AND a client roams with a sticky DHCP lease, the AP will kick out the client. This should cause the client to reassociate to the SSID at some later time and ask for a new DHCP lease.
So, if this option is checked, AND a client roams with a sticky DHCP lease, the AP will kick out the client. This should cause the client to reassociate to the SSID at some later time and ask for a new DHCP lease.

