Hope this sounds familiar to someone.
My conrollers run with snmp v3 user only, and seem to lose their snmpsettings after a reload of the controller.
Does anyone experience the same here, and is there a solution to this annoying problem?
thanx in advance
This may seem like an obvious question, but are you saving the configs on the controller?
Also, are you setting the config directly on the controller or through WCS?
I have had mixed results with driving controllers with WCS and have a larger comfort level with configuring the controllers directly.
Well yes this is the case.
i have saved the configs and i basically run the controllers trough wcs, but in this case i have to do both the wcs and the controller snmp settings in order to get wcs to reach the controllers again.
SO you are saying that the snmp between the wcs and wlc is not correct and you have to change it on the wcs or wlc? If you are having to configure the wlc snmp settings, are you auditing the wlc on the wcs and maybe pushing out another template?
As far as i know i cannot push the snmpv3 user as a template to the controller, and i have to change both, i use v3 exclusively and it makes sense to me to re-enter them both but i just cannot figure out why these settings get lost whenever i reboot a controller. one would expect that the controller loses the settings, but i have used all available methods to save them.
are these saved on the controllers flash?
FYI, I just ran into the same problem after upgrading one controller from 220.127.116.11 to 18.104.22.168. The SNMP v3 credentials appeared to be in the config after the upgrade; however, WCS could not talk to the controller until I re-entered the SNMP info. The same controller crashed this morning so the update is not looking so good.
Just a quick update. My controller crashed again today with 22.214.171.124 code, and I had to cycle power. Then, I had to re-enter the snmpv3 data again. Just like you, I only use V3. It sounds like we have the same problem. Actually, the data was still listed, it just did not work without deleting and re-entering.
Well i just hope this is enough to open a TAC case, i cannot open one myself but next week i will ask my Cisco reseller to open one, i will keep you posted here.
I ran into a similar problem a while back on a very large rollout of 2100 controllers. Turns out the problem was related to the IP stack on the machine WCS was running on. To test, when you lose connection try rebooting the WCS server completely. Down the machine and reboot. THen see if you still have connectivity via SNMP. If you do you will need to update some device drivers for the NIC on the WCS server. Ours was a Dell.
Alas, this did not resolve my problem, i replicated the "device is unreachable" fault, rebooted the machine. the faulty controller stayed in the forementioned state after the reboot, was only revivable by removing the snmpv3 user on the controller and re-entering it. :-( thanx for the suggestion though. btw we are running on HP with HP 373i Gb Nic.
It's a known problem
SNMPV3 Stops Working
After a reboot of the controller, SNMPv3 stops working. The controller running SNMPv3 shows as unreachable in WCS once the controller has been rebooted. This issue is a result of caveat CSCsv64590. You must delete and re-add the SNMPv3 users on the controller any time a controller is rebooted.