cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1536
Views
0
Helpful
1
Replies

ASA EEM + failover sync issue

Jeffx
Level 1
Level 1

Hello.

 

I apologize if this message appears in the wrong category. It's my first post and none of the categories screamed EEM or ASA.


I can't tell if I'm doing something wrong or if I've discovered a bug in the EEM implementation on ASA OSes.

I'm running 9.12.4.26 on a pair of ASA 5555-Xs and I've written a tiny EEM script that allows a python script logged into the Standby unit of an Active/Standby failover pair to enable SCP on the Primary. This script works except for the fact that once the config is saved on the Primary it is not replicated/synced to the Standby unit. In fact, once the command "ssh scopy enable" has been run via EEM and inserted into the Primary's config there is no way to save it to the Standby at all. If I go to the Primary's command line and do a "show run | in scopy" I can see the line the EEM script just added but no amount of "write memory" or "copy running-config startup-config" will cause the new scopy command to be replicated to the Standby. The configs are now out of sync and the only way to get them back in sync is to go into config mode on the Primary, do a "no ssh scopy enable", exit config mode, save the config, then go back into config mode on the Primary, add the "ssh scopy enable" command back, exit config mode and save then config. Now, the "ssh scopy enable" command will appear on the Standby.

I have tried all kinds of variations of the EEM commands to no avail. I have enabled debug mode for both event manager scripts and failover syncing and everything appears as though it has worked but the new config command never shows up on the Standby.

Please believe me when I say I have a good reason for trying to enable SCP this way. My company keeps it disabled by default and only enables it when performing OS upgrades, etc. This isn't my only option. It would however make the external code I have to write a lot simpler.

I also realize that 9.12.4.35 is the current ASA OS version as of today (Oct. 19, 2021) - for the 9.12 train anyway -and upgrading to this version is part of the automation we are crafting now. I see nothing in the release notes between our version and the new version that leads me to believe this is a bug that's been solved.

Here's the EEM script saved to the Primary, replicated to and then executed from the Standby:

event manager applet enable_scopy_eem
 description enable SCP from failover mate
 event none
 output none
 action 001 cli command "ssh scopy enable"
 action 002 cli command "write memory"

I've tried inserting "configure terminal" and "enable" or "end" commands where they seemed appropriate but the debugs showed these commands as producing errors so I stripped them out. This small script works to get "ssh scopy enable" into the Primary device's config from the Secondary so it does work.

Enabling debugs on Primary and Standby nodes:

patty/stby/pri# debug event manager 255

patty/stby/pri# debug fover sync

patty/act/sec# debug event manager 255

patty/act/sec# debug fover sync


Executing this script from the Standby looks like:

patty/stby/pri# failover exec mate event manager run enable_scopy_eem
patty/stby/pri# fover_parse: parse_thread_helper: Cmd: write memory

On the Primary I see this:

patty/act/sec# Running applet enable_scopy_eem
eem: issuing commands
eem: executing 'ssh scopy enable' -> 0
event manager: frep_write_cmd: Cmd: write memory
eem: executing 'write memory' -> 0

If I look at the Primary's config now I see this (trust me, scopy enable wasn't there before)

patty/act/sec# sh run | in scopy
ssh scopy enable
event manager applet enable_scopy_eem
action 1 cli command "ssh scopy enable"

But when I go back to the Standby unit, there's no scopy enable:


patty/stby/pri# sh run | in scopy
event manager applet enable_scopy_eem
action 1 cli command "ssh scopy enable"

 

No errors. Even the Standby acknowledges the write memory command which should trigger a configuration sync.
If I go back to the Primary and do a gratuitous "write memory" or "copy running-config startup-config" it will not write the new command to the Standby leaving the devices out of sync.
Either this is a bug or behavior that I can't find any documentation for.

I'm hoping someone with more experience than I can point out the simple mistake I'm probably making. 
Thank you.

1 Reply 1

Yordan1
Level 1
Level 1

Hi Jeffx,

I have the same problem with ASDM. When I push some changes, I can see them only in Active Node. When I write the script with CLI it works fine.

any ideas? 

br

Review Cisco Networking for a $25 gift card