cancel
Showing results for 
Search instead for 
Did you mean: 

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

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

w1f1n00b
Contributor II

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

1 ACCEPTED SOLUTION

wwillingham
New Contributor III

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.

View solution in original post

7 REPLIES 7

wwillingham
New Contributor III

Without more information on how your network is configured, we can only wildly guess. Are these APs getting there IP address via DHCP? Or are they statically assigned? How is DNS configured at these remote sites? Are there any firewall or router ACLs that could be blocking communication?

 

Also, you mention that you are migrating to NG. Are you trying to get the APs to connect to Classic or NG? If Classic, there is no need to remove them from HM prior to moving them to the new location. If NG, this will depend upon your network configuration. For instance, we are slowly migrating to NG also. To get our APs to connect to NG we have to change the capwap server name to redirector.aerohive.com. Otherwise, the APs will use DNS and connect to our on-prem HM.

w1f1n00b
Contributor II

I'll test that with 1 or 2 tomorrow. Thanks!

weekdaysailor
Contributor

Pure guess - have you tried doing factory reset on the ones giving trouble? Theory is that they have the old capwap server setting and so don't go into discovery.

GTM-P2G8KFN