cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1662
Views
4
Helpful
6
Replies

ASA Failover Cluster: SNMP configuration was not replicated completely

swscco001
Level 3
Level 3

Hello everybody,

we had to replace the standby-node of a ASA Failover Cluster (9.14(3)18)) because a HW defect.

After cluster re-establishment our monitoring complained because several SNMP values
could not be requested. On the primary node all is ok.

I checked the failover status:

ENAM-ASA01/pri/act# sh fa
Failover On
Failover unit Primary
Failover LAN Interface: HEARTBEAT Ethernet1/16 (up)
Reconnect timeout 0:00:00
Unit Poll frequency 1 seconds, holdtime 15 seconds
Interface Poll frequency 5 seconds, holdtime 25 seconds
Interface Policy 1
Monitored Interfaces 1 of 1293 maximum
MAC Address Move Notification Interval not set
Cipher in use: 3DES/AES
Version: Ours 9.14(3)18, Mate 9.14(3)18
Serial Number: Ours JAD2444020W, Mate JAD23130VMN
Last Failover at: 10:00:37 CET Dec 9 2023
        This host: Primary - Active
                Active time: 618451 (sec)
                slot 0: FPR-2130 hw/sw rev (1.4/9.14(3)18) status (Up Sys)
                  Interface Transfer (10.9.0.10): Normal (Not-Monitored)
                  Interface outside (185.247.62.10): Normal (Monitored)
                  Interface management (10.31.131.155): Normal (Not-Monitored)
        Other host: Secondary - Standby Ready
                Active time: 0 (sec)
                slot 0: FPR-2130 hw/sw rev (1.4/9.14(3)18) status (Up Sys)
                  Interface Transfer (10.9.0.11): Normal (Not-Monitored)
                  Interface outside (185.247.62.11): Normal (Monitored)
                  Interface management (10.31.131.153): Normal (Not-Monitored)

Then I compared the SNMP configuration of both nodes:

Active:

ENAM-ASA01/pri/act# sh run | in snmp
snmp-server group nocasa4check v3 priv
snmp-server user nocuser nocasa4check v3 engineID <engineID deleted> encrypted auth sha <key deleted>
snmp-server host Transfer 10.9.0.15 version 3 nocuser
no snmp-server location
no snmp-server contact
snmp-server community *****
no snmp-server enable oid mempool
class-map class_snmp
 class class_snmp
  inspect snmp

------------------------------------------------------------------------

Standby:

ENAM-ASA01/sec/stby# sh run | in snmp
snmp-server group nocasa4check v3 priv
no snmp-server location
no snmp-server contact
snmp-server community *****
no snmp-server enable oid mempool
class-map class_snmp
 class class_snmp
  inspect snmp

Even if I enter 'wr mem' on the active node the SNMP configuration was not
replicated to the standby.

All other configuration was replicated.

How can I solve the issue?

Thanks a lot for every hint!


Bye
R.

1 Accepted Solution

Accepted Solutions

You need to enter passwords on the active unit in this command in clear text and don't specify engine-id. Refer to command reference for exact syntax.

View solution in original post

6 Replies 6

Mark Elsen
Hall of Fame
Hall of Fame

 

              - FYI : https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvy60100

 M.  



-- Let everything happen to you  
       Beauty and terror
      Just keep going    
       No feeling is final
Reiner Maria Rilke (1899)

tvotna
Spotlight
Spotlight

This is expected behavior and the mentioned bug is not relevant for you.

Before 9.14 SNMP user information was hashed by the local SNMP engine-id in the configuration. Active and standby ASA exchanged engine-id over failover link and put two instances of the "snmp-server user" command into configuration: each hashed by the corresponding engine-id.

In 9.14 and above behavior was changed again and documented by the CSCvx18878. SNMP engine-id is no longer synchronized over failover link and each unit uses its own local engine-id to hash "snmp-server user". There is only one copy of the "snmp-server user" command in the config.

When the ASA is replaced, the new ASA has new SNMP engine-id and hence cannot accept "snmp-server user" from its peer during config sync, because hashing is a one-way function. Hence, "snmp-server user" is rejected on the new standby unit. You need to re-enter "snmp-server user" and "snmp-server host" manually on the active unit specifying passwords in clear text and then do "write mem". The commands will be synced in clear to standby, local engine-ID applied and resulting configuration saved.

 

Hi tvotna,

thanks for your fast reply!

Unfortunately the manual re-enter of teh commands on the active unit did not solve the issue:

ENAM-ASA01/pri/act(config)# snmp-server user nocuser nocasa4check v3 engineID <engine-ID> encrypted auth sha <key deleted> priv aes 128 <key deleted>
WARNING: This command cannot be replicated because it contains localized keys.
ENAM-ASA01/pri/act(config)# snmp-server host Transfer 10.9.0.15 version 3 nocuser
ENAM-ASA01/pri/act(config)# wr mem
Building configuration...

Is there any other option I could try?

Thanks a lot!



Bye
R.

You need to enter passwords on the active unit in this command in clear text and don't specify engine-id. Refer to command reference for exact syntax.

Hi tvotna,

I misunderstood your first reply.

After entering the 'snmp-ser user' command without engine ID and clear-text password the monitoring can  request the data again.

Thanks a lot!


Bye
R.

Hi cora9881,

thanks for your reply but this is not an active/active cluster but a normal active/standby.

Thanks a lot!


Bye
R.

Review Cisco Networking for a $25 gift card