Peer in Cold State. Incremental Sync Failure: SSL Keyfile does not exist

[Marvin Rhoads]

I am gettng the subject message when trying to sync my ACE modules. I am running A2(1.0a) right now (about to upgrade to 1.6a).

Both primary and backup ACE report the identical output from a "show crypto files" down to the individual file sizes.

Any tips?

[Marvin Rhoads]

I found the answer in the Cisco Application Control Engine Module SSL Configuration Guide. Basically once you get out of sync (because the keys wern't loaded on both modules in my case) you need to take the units out of aut sync and then but them back in to force a bulk synchronization.

In a redundant configuration, the ACE does not synchronize the SSL certificates and key pairs that are present in the active context to the standby context of an FT group. If the ACE performs a configuration synchronization and does not find the necessary certs and keys on the standby, config sync fails and the standby enters the STANDBY_COLD state. To copy the certs and keys to the standby context, you must export the certs and keys from the active context to an FTP or TFTP server using the crypto export command, and then import the certs and keys to the standby context using the crypto import command. For more information about importing and exporting certs and keys, see the “Importing or Exporting Certificate and Key Pair Files” section.

To return the standby context to the STANDBY_HOT state after a config sync failure, ensure that you have imported the necessary SSL certs and keys to the standby context, and then perform a bulk sync of the active context configuration by entering the following commands in configuration mode in the active context of the FT group:

1.no ft auto-sync running-config

2.ft auto-sync running-config

Hope this helps somone else avoid this bump.

[huangedmc]

I see that you plan on upgrading to A2(1.6a).

We'd been running that code for a while, and it had been rock solid until the primary ACE module failed over to secondary after a memory corruption bug hit us: CSCta06378

The bug is fixed in A2(2.3), so I'd go w/ that version instead.

Thanks for the tip about the config sync issue.

Instead of disabling auto-sync and then re-enabling it, we've been doing shut & no shut on the ft interface, which seems to work too.

I'll give your method a try next time we have the same issue.

[Sean Merrow]

Hello,

If you need to force a config-sync, you are better off bouncing the ft auto-sync run.  This is because the config-sync is the only thing affected when you do this.  If you bounce the FT interface, you could cause both of your ACE modules to become active (unless you have FT Query VLAN configured).  If the standby ACE becomes active even for a second, it will GARP for the IPs it owns and could corrupt ARP tables in adjacent devices.

Hope this helps,

Sean

[j.kostecki]

Great solution! Thank you for posting!

[aakagarw]

Thanks guys,

I am new born baby for ACE, but I know that a bit and learning too. I had similar issue, I found both ACEs had same cert/ssl keys for the context.

All I did went to Active ACE context and :

1.no ft auto-sync running-config

2.ft auto-sync running-config

Problem Solved. thanks for the post Marvin.

-Aakash

[alessandro.dona]

Hi,

i'm trying to import the certs and keys to secondary ACE but i'm not able because on secondary all conf are disabled.

What is the procedure in order i can import also when on secondary?

Should i launch "no ft auto.sync", import and then "auto-sync" or what else?

Regards

Alessandro.

[aakagarw]

You are not required to goin config mode to import cert - that can be done from User exec mode

[alessandro.dona]

I know but when i try to write crypto i got error...i think i should de-refernce ssl proxy key and cert....importo on secondaru anc then refercen again....

[aakagarw]

Would you mind pasting the error you get?

[Jorge Bejarano]

Alessandro,

Here you have a link about uploading certificates:

https://supportforums.cisco.com/message/3695563#3695563

Jorge

[Michal Mihaly]

Marvin great help! Thank you

[Marvin Rhoads]

Michal,

Glad to know my posting is still helping 6 years later. :)

Thanks for letting me know

[Edward Brennan]

Still helping! 

Thank you Marvin.