I have multiple 4506 switches having a problem with snmp.
After upgrading to IOS cat4000-i5k91s-mz.122-25.EWA13.bin, these switches are having an issue being monitored via snmp.
It almost seems like the snmp agent is frozen. None of my monitoring software..i.e. CiscoWorks, HP OV, or any other MIB browser can access these devices via snmp.
I have IP connectivity between the Net Mgt. Server and these switches(I can ping all of them) and there are no ACLs.
I have tried renaming the community strings to ensure that they are correct and even tried stopping/starting the SNMP agent (via the no snmp-server command..and turing it back on), but still no success.
Also, out of the bunch that arent working, there are 3 4506 switches that "ARE" working with that same EWA13 IOS. I have compared the configs on the ones that are working and the ones that arent and they are all the same.
At this point, I am inclined to think that maybe there is a bug in this IOS, but not sure.
Enable debug snmp packet on one of the failing switches, and see what output you get on your terminal. While ICMP connectivity exists, there may be new ACLs that were put in place to block udp/161 traffic to these devices.
I debugged snmp packets a little earlier and it was kind of weird. The debug is contantly spitting out that it is recieving UDP snmp packets from the Net MGT. server, but it is like the switch isnt doing anything with them. When I do a sh snmp, the 'snmp packets input' is not even incrementing. It is stuck on 4119210 and will not move from that number.
Your SNMP ENGINE is wedged trying to send an authFail trap. Either that, or you captured this stack at the moment it was sending an authFail trap. If repeated show stacks on SNMP ENGINE look the same, and the switch is not being polled, then this process is most likely wedged.
I didn't see a bug to explain this, so you might be hitting something new. A reload should work around it, but you may want to contact the TAC for more troubleshooting.
Thanks for the help. I kind of figured it was hung. I was hoping there was a workaround without a reboot. I have alot of switches and it can be difficult getting down time. I guess the best solution is to push for the downtime and simply go to another IOS. Again thanks for your help!
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...