Standby ASA RMA step-by-step

[Melinbonian]

Hello

I have a question regarding the RMA process of a standby unit in a ASA cluster. Here are the steps that I have concluded, please correct/add where im wrong:

• Configure hostname ,
• Install/Verify boot image and asdm is same as primary.
• Activate with the new license key
• Configure failover and connect only failover interface and failover config

Some questions:

• I assume I need to generate RSA key after configuration, to get ssh access?
• Is management config  possible to be needed to be installed manually?
• Whats the easiest/fastest way to install boot and asdm image? Can I just copy from primary via failover link (I don’t think there is another interface between them)? I m ean with failover exec mate copy/ noconfirm tftP;…..x.x..xx .bin ?

[balaji.bandi · Accepted solution]

Make sure You have same hardware as Active and ASA Version of code.

Take the exiting backup config( for safer side)

just configure failover config on the standby.

failover lan unit secondary

failover lan interface Failover gig x/x

failover key *****

failover link Failover gi x/x

failover interface ip Failover x.x..x.1 255.255.255.248 standby x.x.x.2

failover

Rest should be replicated automatically.

[Melinbonian]

Hi Balaji

thanks, you mean to take the backup from the primary one which is active?  I  I will take the show run anyway or even from asdm, in case there are anyconnect profiles.

1. But i was wondering for example, hostnames, do you usually configure them first? Because if you dont , will it failover and just have the same name on both (which is ok, since its not impacting, can be changed later)?

2. If i do configure failover via console, will it 'replicate' ssh key etc , so need for key generation?

3. And i read that it is possible to copy from one member to another, the asdm and boot image, in case there is no tftp or internet connectivity. Are there any concerns for this?

[balaji.bandi]

yes take the backup of existing primary, so you have config backup.

here is cisco official document to configure standby.

https://www.cisco.com/c/en/us/td/docs/security/asa/asa91/configuration/general/asa_91_general_config/ha_failover.html#53599

another good steps for reference.

https://cybersana.tech/cisco-asa-firewall-cluster-member-replacement/

[Marius Gunnerud]

First make sure you have a full running configuration backup of the primary ASA (more system:running-config).

1. update ASA software to same version as the primary ASA

2. copy AnyConnect profiles (the .xml files if any) to the new secondary ASA

3. import any third party certificates to the standby ASA

4. configure failover on the new standby ASA

5. test failover (be sure to do this in a service window)

You only need to make sure that the physical .xml files and certificates are manually copied to the standby ASA.  Other than that, all configuration is automatically copied over from the primary ASA.

[Melinbonian]

Thanks Marius,

i know i can check if there are certificates via CLI with:

show crypto ca certificate 

Is there a way to check the xml profiles as well? I assume a show flash/disk will show if there are any? Although in theory, there could be some but not used.

[Marius Gunnerud]

You will find the .xml files stored in flash.  You can use either dir or show flash: to view them.

[Melinbonian]

Thanks, 

it was sorted, sorry for the delay , i had account issues. One more thing, in this case was lucky, since it had no need to configure any firepower (SFR module) on it, thus left it to default 5.4.1 version. Is there a guide how to RMA the module though? I found out that either you install new image or upgrade, still is going to take ours.

Furthermore, i assume you need to re-install in FMC, but cant find a  decent example on it. 

[Marvin Rhoads]

If you RMA an ASA and there is an associated Firepower service module then it needs to be rebuilt on the replacement unit. 

The quickest and easiest way is to use the following steps:

1. Uninstall the 5.4.1 default module on the replacement unit.

2. Copy the recovery image equal to the major revision level of your FMC.

3. Configure it and add the system image.

4. Prep the FMC by removing/deregistering the old module.

4. Register the rebuilt module to FMC, assigning the licenses and putting it in a device group with the active unit's module.

5. Resync policies with a deployment to the replaced module.

6. Patch the replaced module to be equal to the FMC patch level and deploy once more.