SNMP on Nexus 5548 Failing

[Jason Whitehead]

Hi,

I am having an odd problem with SNMP, I have a Pair of Nexus 5548 UP's and the SNMP is setup very simply v2 with a RO communitee string, I had both devices setup on my SNMP NMS and after a few days one of the devices stopped responding to SNMP, I have verified and re-entered the settings and still it does not work. I am using a SNMP testing tool as well, works flawless on one but fails on the other. I have full connectivity to both devices as well.

Any ideas?

Thanks

[andrew.prince]

simple question can the device that is failing ping the snmp collector??  Also what is the SNMP timeout period you have configured on the collector?

[Jason Whitehead]

Hello Andrew,

Thanks for the respones, the failing Nexus 5548 can indeed ping the SNMP collector, and I am using Solarwinds which by default the timeout period is 2500ms

[Jason Whitehead]

Also, I am running a Debug SNMP all command on both devices, the failing device has this:

snmpd: pm_snmp_process_ethernet_counters_n_update_cache: error: statcl_parse_all_intf_mod_msg failed

I wonder how to fix?

[Jerry Ye]

What version of NX-OS are you running on these 5548s???

Regards,

jerry

[george.liu · Accepted solution]

Hi Jerry

I had similar issue as Jason.

the version on nexus is  5.0(3)N2(1)

It looks to me that snmp had been hanged for a while

dcassw202# sh processes cpu sort

PID    Runtime(ms)  Invoked   uSecs  1Sec    Process
-----  -----------  --------  -----  ------  -----------
4565         1308  3838622539      0   46.5%  snmpd
4681          184        90   2045    5.0%  netstack
4476         1054  14064363      0    1.0%  pfma

Your any suggestion will be very appreciated.

Thanks

[Jerry Ye · Accepted solution]

Hi George,

I believe you are hitting the following bug

CSCtr65682

You can upgrade to 5.0(3)N2(2b).

Regards,

jerry

[Jason Whitehead]

I succesfully upgraded to the latest firmware and my issues have been resolved.

thanks for your comments and help

[george.liu]

thanks Jerry for quick response.

"Workaround:

Unload the BRIDGE-MIB from the switch by using snmp server commands. If the switch is reloaded

you will have to redo step 1 as this command is not persistent. For detailed information on the

workaround please contact Cisco TAC. "

Regarding to temporary workaround, do I need to disable snmp and enable snmp back on the switch to solve this issue?

Regards

[Jerry Ye]

Hi George,

Disable SNMP will not fix this problem, you have to unload the BRIDGE-MIB to free up the memory. However, per the bug's release note, this information needs to come from TAC only.

Regards,

jerry

[george.liu]

Hi Jerry,

the workaround solved my problem. Now snmp is back working now.

Thanks for help

Regards

[Jerry Ye]

Hi George,

Did you unload the BRIDGE-MIB? If yes, just FYI, this is setting will not persist if the switch is reloaded. You have to do this command everytime after reload.

Regards,

jerry

[george.liu]

Hi Jason,

I had similar issues on nexus about snmp.

I wonder whether you have solutions on it.

thanks

[Ajai George]

Hi George,

I am also facing the same issue with SNMP monitoring  for Nexus 5596UP. I am using Solarwinds NPM 10.1.3 for monitoring and it  was monitoring fine until I upgraded to v10.2. Solarwinds TAC suspected  an issue with Nexus.

Can you let me know the workaround which solved the issue with SNMP monitoring?

TIA

AJ

[george.liu]

the wo:

1. Unload the BRIDGE-MIB from the switch by using the command "no snmp-server load-mib dot1dbridgesnmp"

2. Verify it is not loaded by using the command "show snmp internal all_loaded_mibs | include bridge"

3. If the switch is reloaded you will have to redo step 1 as this command is not persistent.

Please remember that this is temporary solution. If the switches being reloaded, you need implementing the commands again