Advice on the correct way to reintroduce the failed primary cluster member back into the cluster

[chris phillips]

We have a pair of ASA 5520's in a cluster running asa 8.2(5)13 where the primary member has been off line for ~ 6 months.

I want to reintroduce the primary back into the cluster. There have been numerous changes made to the config of the secondary-active and naturally the config on the primary-failed is out of date.

reviewing a cisco asa config guide my understanding is that once the primary is reconnected to the secondary, it should:

• go through an election process with secondary-active and determine that it should stay in standby
• copy and run the current config from the secondary-active
• stay as standby once the config has synced.

I want to be doubly sure that the primary-failed does not somehow become active.

My plan is to:

• physically disconnect the lan interfaces on the primary, 
• patch in the sync cable
• ensure the uptodate config from secondary-active is copied to the primary failed
• reconnect the lan interfaces
• ensure primary is now primary-standby
• once i'm satisfied the config is all ok i can then gracefully failover from secondary to primary.

I'm hoping for minimum downtime, which i should achieve so long as everything works as expected.

Does the above look right, anyone have any suggestions or gotchas to look for. 

[Marvin Rhoads · Accepted solution]

That would be an OK approach.

I'd personally go a bit further and strip down the currently inactive to a minimal configuration to allow it to sync as Secondary. Consider that the Primary and Secondary roles are a bit arbitrary in ASA HA pairs. There's seldom a reason why one physical unit has to be in the Primary role. So you could just change the currently online unit to Primary and re-introduce the other one as Secondary.

[chris phillips]

Marvin, are you suggesting a wr erase, reload, config sync interface and then patch the sync, let it come up and then i'm good?

unfortunately the cmdb, physical positioning, physical labels and other paper work won't let me just change the designations, but i'm not fussed as to the designations, so long as they are both up and doing what they are supposed to.

[Marvin Rhoads]

Yes - that is my suggestion.

Sorry to hear that process is in the way of what works best from an engineering point of view.

[chris phillips · Accepted solution]

I actually did it my way but got some downtime and wished I did it your way.

I ensured no patch cables in the bad unit and powered it on
on the running unit I told it to be the primary
i then patched the sync cable into the bad unit.
despite me telling the running unit it was primary, the bad unit took over, copied its months old config to the running and caused an outage as i hadn't patched the other cables in.
I hastily patched the other cables in and let the sync finish.
I then disconnected the cables from the now secondary running unit.
restored its config to what i had copied before the change and saved made it primary repatched the network cables and disconnected the bad unit.
i then made the bad unit secondary and re patched it. The bad unit then copied its config from the running primary.
Once synced i did fail over tests etc and once happy left things in the logical state so the next victim can see the top unit is primary.

So my mistake was hoping removing all network cables from the bad unit and explicitly telling the running unit it was primary was enough to not cause a failover and the bad unit to send its old config to the running unit. I would have been ok if i had told the bad unit it was secondary, it likely would not have copied its old config to the running unit and i would not have had downtime. Had i done what Marvin suggested, the bad unit would have had no choice & would have copied its config from the good unit.