cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
397
Views
0
Helpful
2
Replies

ASA 5525-X upgraded from 9.12(4)67 to 9.14(4)24 and SNMP polling fails

m.george
Level 1
Level 1

Hi team,

We have just upgraded our ASA 5525-X firewalls to mitigate the IKEv2 bug that has just bitten this platform. The TAC supplied image was 9.14(4)24. As soon as the firewalls came back into service we noticed we were getting odd SNMP polling results. For example only seeing the status of 65 site to site VPN tunnels instead of the usual list in excess of 100 (we use OID  1.3.6.1.4.1.9.9.171.1.2.3.1.7 for this). As time has gone on (1 day) we are now seeing the firewall stop responding to SNMP polling completely. A capture shows the get-requests hitting the firewall but no get-responses. It feels like a bug but any bugs I have found on the Cisco web site are reluctant to provide any details that will confirm my suspicions and advise what is needed to remedy the situation. Very hard to make sure all services are operating correctly when the firewall keeps turning out the lights.

Has anyone found and solved this problem or got a suggestion that could point us in the right direction please?

Thanks

2 Replies 2

pieterh
VIP
VIP

is this a ha-pair ?
i'm not sure (answering from history) but you may need to reconfigure snmp on both ASA's because the snmp-system-id has changed and is different on both members

m.george
Level 1
Level 1

Thanks for making a suggestion. Yes, they are an HA pair but the system-id did not appear to be the issue, we were getting partial responses rather than no response. I would expect system-id mismatch to break rather than degrade responses? Prepared to be wrong! (I did re-enter the SNMP configuration while we were troubleshooting in case a password or similar had been corrupted to no avail)

What we did was to use the API to gather the tunnel information. We then use SNMP to poll for tunnel status and other parameters. This appeared to reduce the SNMP polling volume to a level the ASA was happy with. Once we found the workaround we stopped expending energy attempting to identify the cause of the SNMP polling issues. Sorry - should have updated this earlier so anyone else dealing with this challenge could use this too.