What constitutes a failed config load?

  • 1
  • Question
  • Updated 3 years ago
  • (Edited)

Hi there, we have a number of remote branch locations, all connected to head office via WAN links, and we have a virtual hivemanager appliance located in head office

When setting up one of our remote branches with wifi, I preconfigure the APs in head office, upload the configuration to the AP, but I don't reboot the AP to apply the config, I just unplug the AP after the configuration upload and send it to the remote site

My understanding is that the uploaded configuration is placed in the backup partition initially, and upon AP startup the current and backup configs are swapped, so the previously uploaded config in the backup partition is now the 'current' config, and the AP will load that

This seems to work most of the time, but sometimes the AP indicator light doesn't go white and I'm not sure why, and I'm not sure what happens to the configuration after that

My question is in a few parts - firstly, is this a valid approach for pre-configuring APs for remote sites?

If the AP wasn't able to make a CAPWAP connection to the hivemanager, does that constitute a failed config load?

If so, and if my uploaded config file is moved to the failed partition, does the AP ever try to re-use it, or does it require administrator intervention to bring the config out of the failed partition and back into the backup or current partition?

The Aerohive Deployment Guide seems light on detail in this area

Photo of Steve Bennett

Steve Bennett

  • 23 Posts
  • 1 Reply Like

Posted 3 years ago

  • 1
Photo of Steve Bennett

Steve Bennett

  • 23 Posts
  • 1 Reply Like
Nobody knows?
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Assuming that the configuration is correct, I suspect that you are hitting up against configuration rollback in HiveOS due to site specific transient conditions that result in the AP not making and sustaining a CAPWAP connection to HiveManager.

Configuration rollback is intended as a safety net and exists and is on by default for obvious reasons. It is usually a lifesaver rather than a hinderance.

My thoughts are: The APs get shipped to site, cannot make a connection to HiveManager within the 10 minute period allowed for some reason and they roll back.

Because of what you are doing, uploading but not activating the configuration you upload, it is on probation when it gets to the remote site.

If the config contained "no config rollback enable", I suspect you would not be seeing this.

You could simulate this and execute "show config rollback" at the CLI to see details of the rollback status.
(Edited)
Photo of Steve Bennett

Steve Bennett

  • 23 Posts
  • 1 Reply Like

Thanks Nick, I wasn't aware of this feature. I can see the global setting on the server now

Can you please verify if I understand the sequence of events properly

- When I upload the configuration but don't reboot the AP, the uploaded config is sitting in the backup partition

- When the AP is plugged in at the remote branch, the backup and current configs are swapped, and my uploaded config is now the current config

- If a CAPWAP connection is made, the current config is now permanently applied as the current config

- If for some reason the AP is unable to make a CAPWAP connection within 10 minutes, the previous config from the backup partition is brought back in as the current config

If that's all correct, what happens to the uploaded configuration after rollback?

Photo of Andrew Garcia

Andrew Garcia, Official Rep

  • 368 Posts
  • 120 Reply Likes

What Nick says is likely correct.  I believe you are having a problem with config rollback, which typically kicks in if you are changing to a static IP address or monkeying with the native or management VLANs.  Something that would keep you from forming a CAPWAP connection to HM after boot.

However, I was interested in whether there are any effects of the way you are provisioning (presumably a complete config) without a corresponding reboot triggered through the normal processes.  I know I have done that many times, and never really thought about whether there are any repurcussions. So I did some testing to see what the difference was.

I tested with an AP350 running 6.4r1a. I did use HMOL 6.5 rather than on-premises, so I used the redirector rather than some other method of finding my HM instance.

Long story short, you have a couple misconceptions about which partition gets written to when, and unplugging instead of rebooting may have an unintended consequence when trying to write the backup.

First off: there is running config, current (primary) config, and backup config.

Delta config changes change running config and current config. Backup configs are not touched.

Complete configs write to current config, but do not touch running config.  Backup config seems to be updated as part of the clean reboot.  If you disconnect rather than reboot, the backup config does not get set correctly.  sometimes I see two versions ago, sometimes I see the same as the current config.  I have not figured out what causes the difference yet.


Photo of Andrew Garcia

Andrew Garcia, Official Rep

  • 368 Posts
  • 120 Reply Likes
That out of the way, why are you staging APs and then deploying them, rather than plugging them in in the deployment locations and configuring them there?

You mentioned you had an on-premises HM and remote sites, so I would guess you are doing it either to a) configure static Ip addresses on the AP or 2) to make it easy for the AP to find your HM instance.

If the latter is correct, you can actually configure either DHCP or DNS services at your remote site to tell your APs where your HM is.  Or, if you don't want to do that, you can call support and request an on-premises Redirector.  This is a little known feature we offer that lets you provide cloud redirector services that point to your HM instead of HMOL.  Basically, you enter your AP serial numbers in and define the IP address or hostname of your HM in the redirector.  The APs will automatically call the redirector on first boot and get your HM address, then connect up.
Photo of Steve Bennett

Steve Bennett

  • 23 Posts
  • 1 Reply Like

Hi Andrew, thanks for your replies and all your testing

As per your first guess, the reason for pre-configuring the APs is because we don't have DHCP enabled on management VLANs in our remote sites

Your testing indicates that the only way to update the backup configuration reliably is to do a clean reboot after the upload

So in future I'll do a clean reboot before I unplug the AP and send it to the remote site - as long as after the reboot, I disconnect the AP from head office within the 10 minute rollback window, because the newly configured IP will only be valid for the remote site

Thanks again guys