We attempted to upgrade our c160 and it failed to boot after the upgrade, we have an RMA in the process but my question is we were on a very old version of Asyncos Version: 7.1.1-012, and I am sure that the new device will have a much newer version of the software on it.
I have backups of the config - can they be applied to the new version of AsyncOS?
It was in a cluster but the other c160 is running Version: 7.1.1-012 as well, and I do not want to do any upgrades until this is resolved, is there a way to add the new machine with dissimilar versions into the cluster?
Can I downgrade the OS?
If there are any options other than my thoughts please advise.
Appliances will refuse to be added to a cluster if they are not all on the same version. Configs have different options and it is beyond complicated to even try to account for differences so all the same version is a hard requirement.
In order to be able to backup a config using saveconfig, you have to completely remove a given appliance from a cluster first. The centralized management feature adds so many different things to a config that you will not get a coherent config otherwise.
Cisco can send you a box with an older build upon request but too many versions can delay your RMA since they can end up having to pull a specific image out of the archives.
I would be very careful about trying to load a config from an older version. It may or may not load even if you edit the version information in the file. The problem is that during the upgrade process things are done to the config file (adding new options/removing old) that don't necessarily get re-done later on. I've done it in the past but not without a stern warning from support that a resetconfig may be the only solution if the box has problems later.
My sincere recommendation is to take the new box, add a minimal config to get it upgraded to the latest & greatest stable version of AsyncOS and manually add your setup. You will be much better off in the long run with an appliance that started from a known good place.
For the future, when you are upgrading from a really old version (something I have done many times) check the upgrade path to make sure that you are dealing with a supported upgrade. Even then, you are going to be better off doing an upgrade in multiple steps rather than jumping really far in one big upgrade. Do a saveconfig at each interim version so you can revert back if needed.
Whenever you upgrade a box in a cluster it is always safer if you pull it out of the cluster completely and do a saveconfig first. Then once all of your boxes are upgraded you can rebuild the cluster from scratch. I realize that is the 'hard' way and usually not necessary but it all depends on how well you can tolerate a down box if something goes awry.
I will be the first to agree that manually redoing a config is really a pain but if nothing else it will refresh your memory of all the more subtle configurations that you have set up. I always looked at an RMA box as a "fresh start" and did a manual reload unless I had a known good config.
I second Bob's explanation, also want to give some additional thoughts on this.Beforehand, as you are running a cluster it would make more sense to upgrade that working appliance to a newer version (that of the appliance you got during the RMA), and then join the new appliance to the cluster. As mailflow is still going on during the upgrade, your downtime will be limited to the reboot only.
As for using an older config, the inffocial way to adapt a config file from a different version is to keep uploading the configuration file to a new box and remove all lines the system complains at, until the config loads completely without errors. However this makes sense only for slight different versions, i.e. 7.1.3 and 7.1.5. If the difference is larger, trying to adapt a config this way is not recommented any longer because:
1. It will take a long time, and I really mean very long by that. Tried once to adapt a version 5.1 to 5.5, and that took more than an hour.
2. Stripping lines from the configuration means you loose this part of the configuration, and have to find and to reconfigure it later. With that previous example, at the end basically only the network part and some listener settings were left, everything else was gone.
In the end, you'll waste a lot of time, and still have to reconfigure a lot of things. So like Bob suggested, upgrade to the latest version you want, then apply your settings manually.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :