CLEANACCESS Archives

November 2007

CLEANACCESS@LISTSERV.MIAMIOH.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Osborne, Bruce W. (NS)" <[log in to unmask]>
Reply To:
Cisco Clean Access Users and Administrators <[log in to unmask]>
Date:
Thu, 1 Nov 2007 13:24:49 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (94 lines)
Nate,

That BugID is not available to us. More information, please. 

Is this related to the High Availability manager, or a 3750 issue? 

I am running 4.1.1 OOB VG with a majority of my OOB users on 3750s. Is
there a patch for 4.1.1?

Bruce Osborne
Liberty University

-----Original Message-----
From: Cisco Clean Access Users and Administrators
[mailto:[log in to unmask]] On Behalf Of Nathaniel Austin
Sent: Thursday, November 01, 2007 11:47 AM
To: [log in to unmask]
Subject: Re: [CLEANACCESS] Manager loses control of OOB switches

Bill,

Looks like you are hitting CSCsk66548. It is due to be fixed in version 
4.1.3, but a patch exists for 4.1.2.

Nate


Bill Davis wrote:
> We experienced a major outage Tuesday evening when our CCA Manager
> (v4.1.2.0) lost the ability to change vlans from auth to access when a
user
> had "successfully logged on".
>
> 10 of the switch stacks (Cisco 3750's) in the device list indicated
the
> manager was unable to control these switches, but we were also getting
> reports for users they were unable to log in throughout our OOB
deployment,
> regardless of switch "control" or not.
>
> The symptom was the user would log in successfully, then within a
couple
> seconds they would see the login screen pop up.  Obviously, the
manager was
> unable to have the switch change the port to the access vlan once
> authenticated/checked.  Of course, those logged in were able to
maintain
> full access even if they did a link down/up.
>
> After rebooting, it was apparent the fail-over manager pair were
confused
> and I finally shut down the standby server.  This resolved the issue. 
> Bringing the standby server back up caused it to reoccur, so I shut it
back
> down.  Possibly this is a database corruptions/sync error.
>
> On occasion, I have seen the switch configuration maintained by the
manager
> come up with all ports "default uncontrolled" rather than displaying
the
> port profiles that were specified.  The interface indicates the switch
needs
> to be updated and an exclamation mark is indicated by each port.
Checking
> the switch config on the switch itself, the ports are all still set up
for
> control by the manager and I can see the snmp traffic flowing between
the
> switch and manager (though they may just be one way UDP traffic headed
each
> direction).  Changing the manager UI port profiles back to the
preferred
> profile and clicking on update sets the manager back correctly and it
does
> not prompt to update the switch config.
>
> Has anyone else noticed problems with the managers not maintaining the
> correct switch configurations, port profiles, descriptions, or
experienced a
> similar loss of control?
>
> And why didn't they include uploading the port description from the
switch
> config via snmp rather than having to hand enter all the port
description
> info???
>
> I think it is time to call Cisco TAC!
>
> -Bill Davis
> Colorado State University
>
>   

ATOM RSS1 RSS2