SANnav snmpv3 Notify Type: INFORM Problem

[MarioE]

Hello

I have been using HPE SANnav with Broadcom SAN Switch for 5 years. Since then I have activated the Notify Type: INFORM(2) in the “snmpconfig --set snmpv3” configuration. SNMP Informs is activated in SANnav:

I have always received all SNMP traps from the SAN switches in SANnav with this setting. Since the update of the SANnav from 2.3.1a to 2.3.1b the SNMP traps from the SAN Switches to the SANnav did not arrive anymore.
I had to change the Notify Type on all SAN Switches with “snmpconfig --set snmpv3” from
Notify Type: INFORM(2)
to
Notify Type: TRAP(1)
After that the traps arrived again.

Has anyone had similar experience with SNMP configurations?

[Jarvisstark01]

It sounds like the update might have changed how SANnav handles SNMP informs vs. traps. I’ve seen similar issues where INFORMs require extra acknowledgements while TRAPs just fire and forget—maybe SANnav 2.3.1b isn’t handling INFORMs correctly anymore. It might be worth checking Broadcom’s release notes or logs for changes!

[srujan_kumar]

Hello @MarioE 
There could be a number of problems when utilizing SANnav with SNMPv3 with the notify type set to "INFORM (2)" or "TRAP (1)."
-Make sure the switch and SANnav are set up for the same notify type, and make sure the firewall has UDP 162 open.
Check out the following link; it might help you fix the problem

https://techdocs.broadcom.com/us/en/fibre-channel-networking/sannav/management-portal/2-3-1x/v26513544/troubleshooting-snmp-and-telemetry-failures/unable-to-receive-snmp-traps-and-syslog-messages.html?utm_source=perplexity 

Regads
Srujan_Kumar

[MarioE]

I have read all these documents.
I have found no evidence that anything has changed in the SNMP behavior during the update.
Before the update, the traps with Notify Type: INFORM(2) worked without any problems. I have not changed any configuration on the SAN Swtich or the SANnav.
I have reset the snmpv3 permissions on the SAN Switch and SANnav.
As a solution, I then changed the Notify Type from INFORM(2) to TRAP(1) on the SAN Switch, then the SNMP traps arrived in the SANnav again without having to adjust anything in the SANnav.

[MarioE · Accepted solution]

After another remote session with HPE support, the problem was solved by stopping and then restarting the SANnav service:

# /sannav-home/Portal_2.3.1b_bld037/bin/stop-sannav.sh
# /sannav-home/Portal_2.3.1b_bld037/bin/start-sannav.sh

I have already restarted the SANnav server several times without success. Apparently, rebooting the server isn't the same as to restarting the SANnav services.

[Sunitha_Mod]

Hello @MarioE,

We are glad to know the issue has been resolved, and we appreciate you for keeping us updated.