Date: Thu, 09 Oct 2008 10:23:57 -0400
From: "Legge, Jeffry" <[EMAIL PROTECTED]>
Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv
<[email protected]>
To: [email protected]
Subject: Re: [WIRELESS-LAN] Cisco Wireless Controller
I had to do the same....I believe the correct term is "symmetric
tunneling" ....picky, picky, picky :)
-----Original Message-----
From: The EDUCAUSE Wireless Issues Constituent Group Listserv
[mailto:[EMAIL PROTECTED] On Behalf Of Todd M. Hall
Sent: Thursday, October 09, 2008 9:06 AM
To: [email protected]
Subject: Re: [WIRELESS-LAN] Cisco Wireless Controller
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/.
