SNMPv3 on ISE 3.2 patch-2 stopped working after every reboot

[adamscottmaster2013]

I have an ISE cluster 3.2 patch-2 with 4 nodes:  Primary Admin/MNT, Secondary Admin/MNT, PSN, and PSN.  I have this snmp configuration:

no snmp-server enable
snmp-server enable
snmp-server contact "test@test.com"
snmp-server location "TEST"
no snmp-server user test-v3 v3
snmp-server user test-v3 v3 sha1 plain XXXXXXXXXX YYYYYYYYYYY

Everything is working fine until I reboot the ISE and it stops working after that.  From the CLI whenever I do a "show run | include snmp", I see this:

ISEAMP/admin#show running-config | include snmp
snmp-server enable
snmp-server contact test@test.com
snmp-server location TEST
snmp-server user test-v3 v3 sha1 hash ********** **********
ISEAMP/admin#

But it is not working.  I had to perform the followings to get it working again:

no snmp-server enable
snmp-server enable
snmp-server contact "test@test.com"
snmp-server location "TEST"
no snmp-server user test-v3 v3
snmp-server user test-v3 v3 sha1 plain XXXXXXXXXX YYYYYYYYYYY

If I reboot the appliance again, it stops working.  I can reproduce on multiple ISE 3.2 patch-2 appliances.

Is this another bug? Thoughts?

[marce1000]

                       - FYI : https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvt15998
  - Whilst this issue is reported for ISE 2.6 in the bug report the Known Fixed Releases section is 0.  In such cases , contact TAC  , 

 M.

[adamscottmaster2013]

Your reply does nothing to help me :-).  This is NOT an issue with either ISE 3.0 or ISE 3.1,  I see it in ISE 3.2.

[marce1000]

                           - Could  you please start reading replies too ?

 M.

[adamscottmaster2013 · Accepted solution]

There is a bug in ISE 3.2:  CSCwe95624  

[stayd]

You do not need to wait for patch 4 until the end of year. Open the TAC and request the HOT PATCH:

*ise-apply-CSCwe95624_3.2.0.542_patch3-SPA.tar.gz

*ise-rollback-CSCwe95624_3.2.0.542_patch3-SPA.tar.gz

After applying the HP on top of patch 3, snmp works like charm again.

[Feds]

Hi stayd,

Thanks for suggesting that, TAC sent the hotpatch and I can confirm it works, but it has to be applied when SNMP is fully configured and operational (that is, after installing patch 3 as you wrote which fixes CSCwf32255 and after applying the workaround for CSCwe95624).

FYI, it's showing as "3.1".
ise32/admin#show logging application hotpatch.log
Fri Sep 15 12:42:26 ACST 2023 => CSCwe95624_3.1.x_patchall

[Feds]

Hi, we have the same issue with 3.2 patch 2, SNMP v2c and not v3, post-patching all nodes stopped responding to SNMP.
[edit: issue started when nodes were upgraded to 3.2 and not after patch 2 - this was also confirmed in lab]
Workaround implemented but no success, what worked for us was removing "snmp-server host ..." lines and applying workaround again.
TAC also pointed to CSCwe95624 however there's no mention to the trap config lines being the issue or part of the issue.
Seems like patch 4 (ETA Dec 2023) will contain the fix.

[adamscottmaster2013]

When will Cisco release patch 3?

[Feds]

You have to ask TAC.. anyway patch 3 won't have the fix for that bug.

[adamscottmaster2013]

I know patch 3 will not fix the snmp issue but it will be better than patch-2.  I am looking at rolling ISE 3.2 at the end of August so I am hopeful that I can use patch 3 and avoid patching ISE for the next two years, unless there are critical security vulnerabilities.

[Feds]

For our issue which affected v2c, TAC stated bug is CSCwf32255 and confirmed it's fixed in patch 3 that is available already.

[Minnesotakid]

Just an FYI - I recently upgraded from 3.1p7 to 3.2p4 and still hit this SNMP bug. I've submitted a case but posting in case others are also seeing this on the latest patch. 

Workaround listed in CSCwe95624 worked for me.

[stayd]

Hi Minnesotakid,

so you installed patch 4 and the issue is still there ? Cisco said it will be fixed in patch 4.

Could you confirm it ?

[Minnesotakid]

@stayd Yes - after upgrading to 3.2 and then patching to patch 4, I still needed to remove and re-add my snmp configuration to get it work with our NMS. That was the workaround listed in the original bug.