Why won't APs get CAPWAP server info for Hivemanager Classic?

[w1f1n00b]

I'm hoping this may just be something simple I'm missing.

I'm having repeat issues with AP230s not grabbing Capwap info when onboarded. These are devices that were active in Hivemanager Classic (onprem), were removed, and are being re-deployed to different physical locations.

I can't get them to show up in Hivemanager until I console into the AP and manually set the CAPWAP server.

Additional Details

Hivemanager Classic 6.8r7a

We are currently running both Hivemanager Classic and Hivemanager (NG) (slowly migrating)

I've confirmed the serial number is NOT in Hivemanager (NG)

Hivemanager Classic auto provisioning is enabled and has the correct CAPWAP info

[w1f1n00b]

You hit the nail on the head from the beginning "How is DNS configured at these remote sites?

"But I would still check your DNS to make sure that your local HM has a record, and that the record is correct since it isn't always getting your local HM IP."

This whole problem ended up being dns, and took so long due to my lack of understanding of the details of dns servers.

Thank you for your time and direction.

Ultimately I found out, as currently configured, all APs are not necessarily in the same dns zone, and the a record for hivemanager was missing from some zones.

All appears to be working well now.

Cheers!

[w1f1n00b]

Thank you for the detailed reply. This helped a lot with my general understanding of this process and how to troubleshoot it. So far everything that I've tested appears to be working. I plan to test out DHCP options to see if that makes a difference. Unfortunately I'm going to have to back burner this particular issue in the short term as I have other things I have to focus on, and If I have to deploy any of these devices in the meantime, I can still manually set the CAPWAP info in a pinch.

Thank you again for you time, and I hope to get this sorted out the next chance I get.

We only have One HM Classic.

[wwillingham · Accepted solution]

So the toggling of CAPWAP server IP from 0.0.0.0 and 54.172.0.252 sounds like the APs either cannot communicate with redirector.aerohive.com or the serial numbers have not been added to your VHM. It also sounds like there may be some communication issues to your Classic HM if they are sometimes onboarding and sometimes not.

So one thing you can try is to use DHCP options to specify the HM (Classic or NG) that you want the APs to connect to. I'd have to look at the documentation, but from the top of my head, APs that get their IP from DHCP will first check to see if there are DHCP options for HM. Then they will use DNS to find hivemanager.local (local being your DNS domain). If the APs don't find a local HM, that's when they try to go out to redirector.aerohive.com. And if the serial number for the AP is not registered, it will repeat the cycle. For APs that have a statically assigned IP, obviously it would just skip the DHCP option.

It looks like your DNS is properly resolving redirector.aerohive.com. But I would still check your DNS to make sure that your local HM has a record, and that the record is correct since it isn't always getting your local HM IP. You could also check that the CAPWAP traffic is passing properly by doing a CAPWAP ping. In case you haven't done this before: SSH to the AP, then run "capwap ping redirector.aerohive.com" and "capwap ping hivemanager.local" (substituting your DNS domain for local). If CAPWAP is flowing correctly, you should get back 5 successful pings of 82 bytes each.

And on the reset device configuration question. First, there is a difference between reset to default and reset bootstrap. When you reset to default, it will delete all settings except for what is stored in the bootstrap config. The bootstrap config is usually empty, so a reset to default will clear everything. But if the bootstrap config has been configured, you will also need to reset the bootstrap config. For instance, we use the bootstrap config on our AP330s that we use as VPN routers. It has just one line in the config; our external CAPWAP server IP. That way if we remotely reset the config on the AP, it will still know to connect to our on-prem HM. But to answer your question, it depends. If the AP was online when the reset command was issued by HM, it will just appear as a new unconfigured device. You would not need to manually reset it too. If the AP was offline when you issued the command via HM and then you moved the AP while it was offline, you would need to manually reset it.

So do you have multiple HM Classics? Just curious as I am wondering if you do, why?

Lastly, during migration, it is a good idea to prevent migrated APs from being able to communicate with your local HM. The reason being is that sometimes the APs will revert back to you local HM. I believe this occurs if the APs have enough latency communicating with NG that they redo the discovery process and connect to the on-prem HM because it can establish a connection.

[w1f1n00b]

DHCP - yes

DNS - "Set the router as the DNS server in DHCP offers"

ACL's - not that I'm aware of.

If I console in, it has a dhcp ip but no capwap server. CAPWAP Server IP toggles between 0.0.0.0 and 54.172.0.252 every several minutes.

If I factory reset, sometimes it onboards to classic, sometimes not. I haven't yet determined why. If I manually set the CAPWAP server IP it seems to work everytime.

I'm trying to figure out if this is maybe a process issue on my part.

These are APs that are being re-deployed. When they were removed from their previous location, they were deleted from Classic. They are now being re-deployed and onboarded to Classic at a different physical location.

If after removing an AP, you delete it from Classic and choose "Reset device configurations to their default or bootstrap settings", what happens the next time you bring it online in the same environment? Does it reset at that point or would it still need to be manually reset?

On the subject of migration while both Hives are running, we've been using autoprovisioning in Classic just for the purpose of getting the AP the CAPWAP setting for NG. So it checks into Classic, gets it's config ( CAPWAP points it to NG), and then it checks into NG. Depending on your network you may also be able to temporarily black hole the Classic server IP so that new APs can't find Classic and go to NG instead. I've been testing this, and it appears to be the faster of the two options.