I had similiar problems with my 2960s in OOB. TAC had me change from SNMPv3 to SNMPv2 and the problem went away... not as good as a fix, but it is a work around.
Ben ___________________________________________________________ Benjamin Nagle, Network Administrator Gannon University, Erie, PA 16541 http://www.gannon.edu EMAIL: [EMAIL PROTECTED], PHONE: 814-871-7440, FAX: 814-871-5560 -----Original Message----- From: Cisco Clean Access Users and Administrators [mailto:[EMAIL PROTECTED] On Behalf Of Sean A Thomas Sent: Tuesday, December 04, 2007 12:44 PM To: [email protected] Subject: Re: SNMP failure for OOB switches I have been seeing similar things happening in my infrastructure. We are running mostly 4506 chassis and have seen the "unable to control switch" message in CAM at random times. I installed the patch a few weeks ago, unfortunately After half of my switches lost data. TAC has not been of any help with this yet. Any ideas would be welcome. Sean ________________________________ Sean A. Thomas, MCP, RHCT Academic Systems Administrator Embry-Riddle Aeronautical University [EMAIL PROTECTED] 386-226-6193 - Office Any technology questions or issues, please contact IT Support at 386-226-6990 -----Original Message----- From: Cisco Clean Access Users and Administrators [mailto:[EMAIL PROTECTED] On Behalf Of Bill Davis Sent: Tuesday, December 04, 2007 11:19 AM To: [email protected] Subject: SNMP failure for OOB switches Has anyone experienced a failure of SNMP queries to Cisco 3750 switches? We am running Clean Access v4.1.2.0. I posted a previous event where the Clean Access Manager was unable to control the switches (see Nov 1, Manager loses control of OOB switches). We have had a second occurrence of this problem last night. The patch mentioned in the previous thread was installed on the Managers, so we did not lose the switch configurations in Clean Access, but the effect on user logins was the same. In brief, about half of our 3750 switch stacks became unmanageable and OOB users were unable to login because the manager could not change their vlan from auth to access. I could see SNMP queries to/from the Clean Access Manager, but the interface indicated the switch could not be controlled. Direct SNMP queries from a work station confirmed there was no response from the affected switches. A reload of the switch stack did no resolve the problem. One of the network staff recalled a similar problem on HP switches and the resolution was to remove all snmp-server configuration settings on each affected switch and re-install them. That did work for the Cisco 3750s and we were able to bring up all the failed switch stacks. They have remained up so far (14+ hours). I don't think this is specific to Clean Access, but thought I'd post before contacting Cisco TAC. We are in the last week of classes and I am concerned of a repeat. Does anyone know of what might be causing the failure of the SNMP service on multiple random switches? As a side issue: We shut down the standby manager as a precaution when this first occurred. When we had brought everything back up and all looked OK on the primary manager we booted up the standby. When it came up, I checked both managers using fostate.sh and they both indicated they were primary and the other was standby. I had to shut the second manger back down. The fail over for the manager has never seemed to work. I usually have to log into the system and restart the service to get it to come up at all. Is this the standard experience for others who use a failover configuration? Thanks! -Bill Davis Housing Technology Services Colorado State University
