Wireless Access

Looking for clarification and possibly some help with backing up an ArubaOS8 config via an automated task on the CLI.

What is the best method to actually grab the config from the command line with ArubaOS 8? In trying to automate the backup of our new controllers (via SolarWinds CatTools) we are running into a bunch of issues. (I.E. not working.) It currently works great in our 6.x environment.

For our 6.X environment we use to use three separate commands to do the backup and copy off the results to another system:

copy running-config tftp: $IP_Address $path_to_upload_to
backup flash
copy flash: flashbackup.tar.gz tftp: $IP_Address $path_to_upload_to
delete filename flashbackup.tar.gz

So while this will work via an SSH session to a ArubaOS 8 cluster, it no longer works via CatTools. That is one issue. (Love to hear anyone's opinion on this or a solution? I have posted this question to the Solarwinds community as well.)

But the command:

copy running-config tftp: $IP_Address $path_to_upload_to

Does not really do what it use to do. So I'm confused with how this is supposed to work as it does not give you the full config. Since you need to dive down into the node for the actual controllers and add "effective" to get a full configuration(?).

show configuration

vs

show configuration effective       (within the correct node/path)

vs

show running-config

I would have thought that trying to display the running-config would give you the entire configuration but that does not seem to be the case. I get the tree / node path (or I don't because this makes no sense to me) but doing the above is pretty confusing as to what works where...?  Can someone point me to a document (best practices?) that explains this further?

And, how do you get the entire config, at the controller node level. via some CLI command like: 

copy running-config tftp: $IP_Address $path_to_upload_to ?? 

Since copy running-config effective is not a valid command.

Thoughts?

backup config

https://www.arubanetworks.com/techdocs/ArubaOS_86_Web_Help/Content/arubaos-solutions/1cli-commands/backup.htm?Highlight=backup

Have you removed any reference to an enable password in the Solarwinds config? An expect script may be waiting for an enable login response, which is not used in AOSv8.

Yes... I made sure the enable options are not there.

I would type "show audit-trail" on the controller on which it fails to see what commands were executed and if successfully.

I don't have any specific assistance regarding your backup, however I want to point out or remind you (and anyone else who reads this later) about the OS 8 environment, and the config that exists on the Mobility Controllers (MCs).

Remember, all of the configuration for the MC is actually configured on the Mobility Master (MM). When the MC boots, it's entire configuration is downloaded from the MM. As changes are made on the MM, updates are sent to the MCs. From the MM, you can use the "show switches" command to see if all of the switches are synchronized. This is the "Config ID" column. From the MC you can use the "show switchinfo" command to see it's Config ID level.

Backing up the MC is a good thing to do. I like doing "backup flash date-flashbackup.tar.gz" which will create a backup file on the local filesystem of the MC, and I specify the date as part of the name. I specify a name because if someone simply performed a "restore flash" on the MC, if the "flashbackup.tar.gz" (default backup filename) exists, a restore will immediately be performed.

Copying the file off to an external system is good practice, but I also like keeping a recent file on the MC (providing there is enough storage space on the MC). If you do not keep a copy of a backup on the MC, and you have a problem, you have to do some rebuilding of the MC, so you can get it communicating again, so you can copy the file back to the MC, so you can restore it; too much work. If you are in crisis mode, it needs to happen quickly.

If you do restore the config to the MC ("restore flash date-flashbackup.tar.gz"), you will need to do a reboot of the MC for the file to take effect. So, the MC is rebooted, and when it comes back up, it communicates with the MM and checks whether it's "Config ID" matches the MM; does the MC have the same configuration revision as the MM. If it doesn't, the MC will download the latest configuration updates from the MM and now be up to date.

So looking at this, the restore of the MC is not necessarily about getting it back to exactly where it was when it had a problem. It is about getting up and running, so that it can re-establish communications with the MM, so that it can re-synchronize itself with the latest configuration that has been set for it on the MM. 

This process also works with SD-Branch gateways and Central. I tested it last week in an SD-Branch class that I was teaching, using the tasks/steps that I stated above.

So, make backing up the MC is good, but make sure you have a backup of the MM, because that contains the configuration for all MCs on your network.

I hope this helps,