controller losing snmp settings

Unanswered Question
Mar 9th, 2009


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

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3 (1 ratings)
ericgarnel Mon, 03/09/2009 - 06:35

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.

snarf65 Mon, 03/09/2009 - 07:17


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.


Scott Fella Mon, 03/09/2009 - 08:44

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?

snarf65 Mon, 03/09/2009 - 09:22


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?

rduke Mon, 03/16/2009 - 07:37

FYI, I just ran into the same problem after upgrading one controller from to 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.


rduke Tue, 03/17/2009 - 15:02

Just a quick update. My controller crashed again today with 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.


snarf65 Tue, 03/17/2009 - 15:22

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.

greetings Frans

dennischolmes Tue, 03/17/2009 - 19:56

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.

snarf65 Thu, 03/19/2009 - 04:03

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.

olivier.nicolas... Mon, 03/30/2009 - 14:06

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.

snarf65 Tue, 03/31/2009 - 01:51


Missed that,


Guess it will be fixed in 6.X



This Discussion



Trending Topics: Other Wireless Mobility

client could not be authenticated
Network Analysis Module (NAM) Products
Cisco 6500 nam
reason 440 driver failure
Cisco password cracker
Cisco Wireless mode