Platforms: All ePMP N/AC platforms Firmware versions: 4.7.1 and newer
The feature has been developed to cover cases when SM has been disconnected from the Primary AP and connected to the Secondary one and never gets back to Primary that affects APs load and customers’ experience.
The implementation of the 1st Stage of "Primary AP reconnect " feature is available starting 4.7.1 firmware.
Primary AP is the AP which SSID is entered in the first row of the Preferred APs table.
It is considered as the default AP that SMs has to be trying to connect.
If SM has been disconnected from the Primary AP(in case of short-term outage of the Primary AP), it connects to the Secondary AP.
Starting 4.7.1 firmware the new filed “Primary AP Reconnect Period” is available for the configuration. The default value is 60 minutes. It represents the time period when SM initiates the disconnect from the AP that it’s currently connected to if its SSID doesn’t mach the one configured as the Primary AP in the Preferred APs Table.
If SM is connected to the Primary AP the disconnect is not initiated despite of the duration of “Primary AP Reconnect Period” configured.
The 2nd Stage of the feature implementation will include background scanning on the SM to avoid SMs disconnect from the Secondary AP when the Primary AP is not available and the option to configure exact time when SM verifies if it’s connected to Primary AP and disconnects if it’s not.
4.7.1 Alpha Firmware will be shared under that article shortly for testing purposes.
This is a really great addition and would make it an easier decision to add all APs that an SM can see as a secondary as a default option.
One thing I would really love to see is the ability to actually set a specific time that the SM will attempt reconnecting to the primary AP, such as 3:00AM every day, so that the SM is not attempting to reconnect to the primary in the middle of the day, where there’d be more disruption for the user normally compared to off-hours.
Great to hear, I’m really looking forward to this feature even more knowing that.
It was my only point of hesitation from initial thoughts on making more use of it with our network, so that will be really nice, thanks Fedor!
It would be pretty good if the SM recognised when it is in low or no use and does a backgound search for the best AP, or back to the priority AP. This would be optimum as at some sites we have more than three APs and being able to redistribute the load would be a killer function. And additionally having SMs under load doing an occasional backgound scan allowing moving to APs with spare capacity would be great. An occasional scan could provide this offloading capability. Latency could be a factor in this calculation.
Russ,
we are pretty close to publish 4.7.1 release candidate. Almost all major bugs are fixed and verification is in progress. I’ve crossed my fingers. If there will be no surprises in the next build we will provide it for testing.
This is a phenomenal feature but I have one issue and a way to hopefully improve this feature.
In my particular configuration, each AP has its own data VLAN with a unique subnet and DHCP server. I believe this is a very common configuration for security reasons.
When the SM fails over to the secondary AP (whether it be primary AP failure or just a DFS frequency change, the router behind it will not renew its DHCP lease until it times out (im using Mikrotik so its typically 10 min).
It would be very nice if the SM could signal to the router behind it to renew its DHCP lease. This way, the downtime for the end user would only be a matter of seconds. The only way to speed up the DHCP lease renewal is to completely reboot the SM.
I think if the SM could trigger a brief ethernet disconnect, it would force the router to renew its lease. I dont think it should be too difficult to add.
Hello, Is it possible for this feature to be use in EPTP Mode? the thing is i’m having issue with [
Reason: 34 (BEACONs MISS) and the AP needed to be manually reboot so it can reconnect again…
