This is probably unrelated, but here goes. We are running 4.2.61.0 on all our
WiSMs and they have been very stable as long as ssh is disabled. We were
getting reports of clients that were connected and working one minute and
connected and not working the next. We traced the problem down to a failed
roam. If we looked the user up in WCS, they would exist on two different
controllers at the same time with a protocol of "mobile" on one of them. The
only way we could get them working again was for them to disconnect, wait for 5
minutes and try again (or we could kick both connections off manually). We did
some searching and found that lots of users were in this same state at any given
time.
We enabled "symmetric mobility" on all our controllers. This solved the
problem. Now when a client roams to an AP on a different controller, a tunnel
is setup between the anchor controller and the new controller. Roaming is fast
and simple.
On Wed, 8 Oct 2008, Johnson, Bruce T wrote:
Date: Wed, 08 Oct 2008 18:43:15 -0400
From: "Johnson, Bruce T" <[EMAIL PROTECTED]>
Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv
<[email protected]>
To: [email protected]
Subject: Re: [WIRELESS-LAN] Cisco Wireless Controller
Bear in mind the controllers are designed to remove associations (and save
resources) if there hasn't been any traffic seen from the clients. The User
Idle Timeout is responsible for this behavior.
You can increase this value from its default of 300s to a higher value. This
will keep the (inactive) association active longer. I'm trying to find out from
Cisco whether this will preserve L3 roaming for mobile devices that don't issue
DHCP renewals effectively. Note this can increase memory utilization and will
adversely impact location-by-association.
BTW, here's an example of the radio reset syslog messages I'm seeing from the
APs. Looks like it might be related to another control-plane management
function like the aforementioned TSM. Only the b/g radios are affected.
10-08-2008 18:28:46 Local7.Error 172.20.42.198 17333:
AP:0016.465a.884c: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to up
10-08-2008 18:28:45 Local7.Error 172.20.42.198 17332:
AP:0016.465a.884c: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to down
10-08-2008 18:28:40 Local7.Error 172.20.42.198 17331:
AP:0016.465a.884c: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to up
10-08-2008 18:28:40 Local7.Error 172.20.42.198 17330:
AP:0016.465a.884c: %SYS-3-MGDTIMER: Running timer, init, timer = A0786C.
-Process= "LWAPP 802.11 MAC Management Reception", ipl= 0, pid= 37 -Traceback=
0x5DCB8 0x15F194 0x15F300 0x15F490 0x46F17C 0x46D0E0 0x46D4C4 0x46D5BC 0x193F50
10-08-2008 18:28:39 Local7.Error 172.20.42.198 17329:
AP:0016.465a.884c: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to down
10-08-2008 18:12:20 Local7.Error 132.183.112.28 16239:
AP:0015.fa05.a54e: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to up
10-08-2008 18:12:19 Local7.Error 132.183.112.28 16238:
AP:0015.fa05.a54e: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to down
10-08-2008 18:12:14 Local7.Error 132.183.112.28 16237:
AP:0015.fa05.a54e: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to up
10-08-2008 18:10:42 Local7.Error 172.20.42.143 101:
AP:001e.be27.017e: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to up
10-08-2008 18:10:42 Local7.Error 172.20.42.143 100:
AP:001e.be27.017e: %SYS-3-MGDTIMER: Running timer, init, timer = D382B4.
-Process= "LWAPP 802.11 MAC Management Reception", ipl= 0, pid= 42 -Traceback=
0x5DCB8 0x161FBC 0x162128 0x1622B8 0x4C32FC 0x4C1260 0x4C1644 0x4C173C 0x196D90
10-08-2008 18:10:41 Local7.Error 172.20.42.143 99:
AP:001e.be27.017e: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to down
10-08-2008 18:10:36 Local7.Error 172.20.42.143 98:
AP:001e.be27.017e: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to up
10-08-2008 18:10:35 Local7.Error 172.20.42.143 97:
AP:001e.be27.017e: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to down
10-08-2008 18:07:40 Local7.Error 172.20.42.198 17328:
AP:0016.465a.884c: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to up
10-08-2008 18:07:39 Local7.Error 172.20.42.198 17327:
AP:0016.465a.884c: %SYS-3-MGDTIMER: Running timer, init, timer = A07D7C.
-Process= "LWAPP 802.11 MAC Management Reception", ipl= 0, pid= 37 -Traceback=
0x5DCB8 0x15F194 0x15F300 0x15F490 0x46F17C 0x46D0E0 0x46D4C4 0x46D5BC 0x193F50
10-08-2008 18:07:39 Local7.Error 172.20.42.198 17326:
AP:0016.465a.884c: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to down
10-08-2008 18:07:34 Local7.Error 172.20.42.198 17325:
AP:0016.465a.884c: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to up
10-08-2008 18:07:33 Local7.Error 172.20.42.198 17324:
AP:0016.465a.884c: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to down
10-08-2008 18:00:20 Local7.Error 132.183.112.28 16236:
AP:0015.fa05.a54e: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to up
10-08-2008 18:00:19 Local7.Error 132.183.112.28 16235:
AP:0015.fa05.a54e: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to down
10-08-2008 18:00:14 Local7.Error 132.183.112.28 16234:
AP:0015.fa05.a54e: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to up
10-08-2008 18:00:13 Local7.Error 132.183.112.28 16233:
AP:0015.fa05.a54e: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to down
-----Original Message-----
From: The EDUCAUSE Wireless Issues Constituent Group Listserv
[mailto:[EMAIL PROTECTED] On Behalf Of Todd Lane
Sent: Wednesday, October 08, 2008 6:24 PM
To: [email protected]
Subject: Re: [WIRELESS-LAN] Cisco Wireless Controller
We've been running a "Engineering Special" version of 4.2.130.0 since
August and it's been stable so far. We had several problems with
4.2.185.0 including controller reboots and lockups. The general release
version of 4.2.130.0 fixed all the major problems we were seeing except
two and the engineering special took care of those.
We're just starting to get reports from clients with random disconnects.
--Todd
Mike King wrote:
So Cisco LWAPP people,
Currently we're on 4.1.185.0 <http://4.1.185.0>. It's a 4402 controller,
with 1131AG access points.
Anyone made the leap to one of the 4.2, 5.0 , or 5.1 trains without
seriously regretting it?
We've had some random disconnects with clients. It's pretty common,
happening to most all users. We're running WPA-PSK, so it's not an
802.1x issue. Before we involve TAC, we figured we should upgrade to a
new code train.
Mike
********** Participation and subscription information for this EDUCAUSE
Constituent Group discussion list can be found at
http://www.educause.edu/groups/.
**********
Participation and subscription information for this EDUCAUSE Constituent Group
discussion list can be found at http://www.educause.edu/groups/.
The information transmitted in this electronic communication is intended only
for the person or entity to whom it is addressed and may contain confidential
and/or privileged material. Any review, retransmission, dissemination or other
use of or taking of any action in reliance upon this information by persons or
entities other than the intended recipient is prohibited. If you received this
information in error, please contact the Compliance HelpLine at 800-856-1983 and
properly dispose of this information.
**********
Participation and subscription information for this EDUCAUSE Constituent Group
discussion list can be found at http://www.educause.edu/groups/.
--
Todd M. Hall
Sr. Network Analyst
Information Technology Infrastructure
Mississippi State University
[EMAIL PROTECTED]
662-325-9311 (phone)
**********
Participation and subscription information for this EDUCAUSE Constituent Group
discussion list can be found at http://www.educause.edu/groups/.
