12-30-2020 11:18 AM
I have a R720 running Unleashed, which gets its IP address from a Mikrotik router via DHCP, with a lease time of 1hr. The DHCP client implementation has a weird issue, where the DHCP lease is released before it is up, but the address continues being used. This is what I see in the router's logs:
Dec/30/2020 10:18:41 LAN assigned 10.1.10.250 to 24:79:2A:XX:XX:XX
Dec/30/2020 10:03:23 LAN deassigned 10.1.10.250 from 24:79:2A:XX:XX:XX
Dec/30/2020 09:18:36 LAN assigned 10.1.10.250 to 24:79:2A:XX:XX:XX
Dec/30/2020 09:03:08 LAN deassigned 10.1.10.250 from 24:79:2A:XX:XX:XX
etc, etc - with this exact pattern repeating every hour.
I suspect the 720 is attempting to refresh the lease after 45 minutes, but instead ends up simply terminating it. I have an R710 and R510 also, which do not exhibit this behavior. (In fact no other device on my network is behaving like this, which leads me to believe this is a Unleashed issue, rather than a Mikrotik one.)
For the most part the bug is benign (the R720 continues to use the DHCP assigned IP after terminating the lease), but I do occasionally experience spurious system reboots which I believe are the result of address collisions resulting from the use of an IP address after the lease has been terminated.
Making the lease for all the unleashed APs static seems to be a usable workaround, but a buggy DHCP client in a networking product that can lead to address collisions is something Ruckus should fix...
Unleashed version 200.9.10.4.212.
EDIT: Unlike I originally suspected this will not lead to address collisions. The reboots are due to something else.
Solved! Go to Solution.
01-07-2021 11:37 PM
Yeah, Ruckus' DHCP client implementation is buggy. Or at least, strange.
For whatever reason, the master AP - and only the master - sends a bunch of DHCPDISCOVER messages when it already has an active lease. The DHCP server dutifully responds with offers, which the AP ignores. Mikrotik's DHCP server interprets this as the client no longer being bound (it still respects the original lease time though, so my initial assumption that this could lead to address collisions was wrong).
Why does it broadcast DHCPDISCOVERs when it is already bound?
01-11-2021 11:21 AM
Sigh. The reboots, after all, do appear to be caused by Ruckus' faulty DHCP implementation, as a result of "heartbeats lost" events.
I see "heartbeats lost" events pretty much exactly the same time every hour, and, sure enough, they correspond exactly to when the master APs lease expire.
Similar issues have already been reported here and here in the past.
I have $10 gadgets that can do DHCP correctly. As already stated - a faulty DHCP implementation is shoddy for an "enterprise grade" networking appliance, and the fact that there are 2 year old reports of this same issue and Ruckus can't be bothered to fix the bug is beyond disappointing.
01-07-2021 04:50 AM
If your switch reports power used by R720 as 8W, something is seriously wrong with your setup, and R720 runs in some fail-save 802.3af-compatible mode. This most probably is the very reason of your unexpected reboots -- Ruckus APs almost never reboot without reason.
Max power consumption is always more than average, of cause, but not that much, and anyway insufficient power at boot switches AP to lower performance mode in the best case, in the worst -- prevents booting or results in different errors.
Max power consumption for R720 is:
in 802.3af mode 12.95 W
802.3at mode 25.5 W
Full mode 33.5 W
So I strongly recommend to provide proper power to R720 APs, or at least configure APs in compatible with 802.3at power way from controller (disable second Ethernet port and USB port). Only when this is done, it makes sense to look for any other issues (which most probably will disappear than).
Using R720 with insufficient power just doesn't make sense -- PoE injectors doesn't cost much, and I would definitely not want to limit capability of rather expensive APs because of low power. If you can't provide proper power, it would be better to use R510 APs (which are much cheaper), as this would provide probably same or even better performance, than you have now with R720 in degradeted mode.
01-07-2021 12:11 PM
Thanks for the tips! The 720 claims it gets power via 802.3at:
01-07-2021 12:40 PM
Also, the 8-10W range seems to be about right.
01-07-2021 02:26 PM
It gets weirder... I changed the master AP to the R710 - lo and behold, now that device is exhibiting the same weird DHCP behavior.
I noticed that both APs use the same hostname (the name configured under "Admin & Services -> System -> System Info", rather than the individual name set for each AP under "Access Points -> Edit -> General -> Device Name"). Maybe that is confusing the DHCP server...
01-07-2021 11:37 PM
Yeah, Ruckus' DHCP client implementation is buggy. Or at least, strange.
For whatever reason, the master AP - and only the master - sends a bunch of DHCPDISCOVER messages when it already has an active lease. The DHCP server dutifully responds with offers, which the AP ignores. Mikrotik's DHCP server interprets this as the client no longer being bound (it still respects the original lease time though, so my initial assumption that this could lead to address collisions was wrong).
Why does it broadcast DHCPDISCOVERs when it is already bound?