RE: [WIRELESS-LAN] Move In/Opening Week- Any Problems?

2017-08-31 Thread Lee H Badman
Still happens on newer out-of-box devices as well (at least on my new MBP 
before I properly configured it to disable unused EAP types). Can check timers 
when I’m at a place to access the controller.



Lee Badman | Network Architect

Certified Wireless Network Expert (#200)
Information Technology Services
206 Machinery Hall
120 Smith Drive
Syracuse, New York 13244
t 315.443.3003   f 315.443.4325   e lhbad...@syr.edu w 
its.syr.edu
SYRACUSE UNIVERSITY
syr.edu

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jeffrey D. Sessler
Sent: Thursday, August 31, 2017 2:44 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Move In/Opening Week- Any Problems?

Is this something you still see on the client-side, or was it a problem mainly 
with older OS versions that aren’t around now?

What client exclusion timeout are you currently using?

Jeff

From: 
"wireless-lan@listserv.educause.edu" 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of "lhbad...@syr.edu" 
mailto:lhbad...@syr.edu>>
Reply-To: 
"wireless-lan@listserv.educause.edu" 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Thursday, August 31, 2017 at 11:05 AM
To: 
"wireless-lan@listserv.educause.edu" 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] Move In/Opening Week- Any Problems?

Part of it is your EAP type, and whether users are forced to onboard to get 
configured enough to use the WLAN (like w/ TLS). With PEAP/MS-CHAPv2, I’ve seen 
many out of box, un-onboarded client device “auto connect” situations where OS 
X or Windows does figure out what it needs for EAP type, but first tries a 
couple others which fail. These can land the client in the penalty box if 
things are too tight. That’s where it feels broken to otherwise OK clients. Saw 
a lot of this on the default 60 second timer, when the client exclusion 
threshold was 3 strikes and you’re out. We had a long-running feature request 
to stretch 3 failures out to a selectable value (can now go to 10) which does 
make the longer penalty times more palatable and less likely to ensnare 
unconfigured-but-eventually-get-on-OK clients.



-Lee

Lee Badman | Network Architect

Certified Wireless Network Expert (#200)
Information Technology Services
206 Machinery Hall
120 Smith Drive
Syracuse, New York 13244
t 315.443.3003   f 315.443.4325   e lhbad...@syr.edu w 
its.syr.edu
SYRACUSE UNIVERSITY
syr.edu

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jeffrey D. Sessler
Sent: Thursday, August 31, 2017 1:10 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Move In/Opening Week- Any Problems?

Longer client exclusion times coupled with longer session timeouts mean the 
clients most impacted are the troublesome clients i.e.  it only feels broken 
for the already broken clients.

I use a 60 second exclusion timeout with very long user session timeouts. The 
longer exclusion timeouts are necessary to combat those troubling devices that 
create the equivalent of a auth DoS when they have a bad password or other 
misconfiguration. Seldom have I seen this impact a well-behaved client.

The long session timeouts are a realization that disabling a user is a rare 
thing, so why inundate the radius server every ½ hour, hour, etc. with tens of 
thousands of requests just to see if the user is still OK to be connected. If 
immediate action is necessary, use client exclusion.

Been running the above configuration for some eight years and the helpdesk 
phone is very quiet.

Jeff

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman
Sent: Thursday, August 31, 2017 8:12 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Move In/Opening Week- Any Problems?

Interesting, hopefully you get some relief. On this document about RADIUS 
timers 
https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/118703-technote-wlc-00.html
 I can’t buy in to Client Exclusion being set to 120 seconds as a rule. Even at 
60 it’s too long and makes the network feel broken. I agree 100% that it needs 
to be used on .1X networks, but with a short enough timer that the helpdesk 
phone doesn’t ring off the hook.

Wondering what value others are using here?

-Lee

Lee Badman | Network Architect

Certified Wireless Network Expert (#200)
Information Technology Services
206 Machinery Hall
120 Smith Drive
Syracuse, New York 13244
t 315.443.3003   f 315.443.4325   e lhbad...@syr.edu w 
its.syr.edu
SYRACUSE UNIVERSI

Re: [WIRELESS-LAN] Move In/Opening Week- Any Problems?

2017-08-31 Thread Jeffrey D. Sessler
Is this something you still see on the client-side, or was it a problem mainly 
with older OS versions that aren’t around now?

What client exclusion timeout are you currently using?

Jeff

From: "wireless-lan@listserv.educause.edu"  
on behalf of "lhbad...@syr.edu" 
Reply-To: "wireless-lan@listserv.educause.edu" 

Date: Thursday, August 31, 2017 at 11:05 AM
To: "wireless-lan@listserv.educause.edu" 
Subject: Re: [WIRELESS-LAN] Move In/Opening Week- Any Problems?

Part of it is your EAP type, and whether users are forced to onboard to get 
configured enough to use the WLAN (like w/ TLS). With PEAP/MS-CHAPv2, I’ve seen 
many out of box, un-onboarded client device “auto connect” situations where OS 
X or Windows does figure out what it needs for EAP type, but first tries a 
couple others which fail. These can land the client in the penalty box if 
things are too tight. That’s where it feels broken to otherwise OK clients. Saw 
a lot of this on the default 60 second timer, when the client exclusion 
threshold was 3 strikes and you’re out. We had a long-running feature request 
to stretch 3 failures out to a selectable value (can now go to 10) which does 
make the longer penalty times more palatable and less likely to ensnare 
unconfigured-but-eventually-get-on-OK clients.



-Lee

Lee Badman | Network Architect

Certified Wireless Network Expert (#200)
Information Technology Services
206 Machinery Hall
120 Smith Drive
Syracuse, New York 13244
t 315.443.3003   f 315.443.4325   e lhbad...@syr.edu w 
its.syr.edu
SYRACUSE UNIVERSITY
syr.edu

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jeffrey D. Sessler
Sent: Thursday, August 31, 2017 1:10 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Move In/Opening Week- Any Problems?

Longer client exclusion times coupled with longer session timeouts mean the 
clients most impacted are the troublesome clients i.e.  it only feels broken 
for the already broken clients.

I use a 60 second exclusion timeout with very long user session timeouts. The 
longer exclusion timeouts are necessary to combat those troubling devices that 
create the equivalent of a auth DoS when they have a bad password or other 
misconfiguration. Seldom have I seen this impact a well-behaved client.

The long session timeouts are a realization that disabling a user is a rare 
thing, so why inundate the radius server every ½ hour, hour, etc. with tens of 
thousands of requests just to see if the user is still OK to be connected. If 
immediate action is necessary, use client exclusion.

Been running the above configuration for some eight years and the helpdesk 
phone is very quiet.

Jeff

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman
Sent: Thursday, August 31, 2017 8:12 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Move In/Opening Week- Any Problems?

Interesting, hopefully you get some relief. On this document about RADIUS 
timers 
https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/118703-technote-wlc-00.html
 I can’t buy in to Client Exclusion being set to 120 seconds as a rule. Even at 
60 it’s too long and makes the network feel broken. I agree 100% that it needs 
to be used on .1X networks, but with a short enough timer that the helpdesk 
phone doesn’t ring off the hook.

Wondering what value others are using here?

-Lee

Lee Badman | Network Architect

Certified Wireless Network Expert (#200)
Information Technology Services
206 Machinery Hall
120 Smith Drive
Syracuse, New York 13244
t 315.443.3003   f 315.443.4325   e lhbad...@syr.edu w 
its.syr.edu
SYRACUSE UNIVERSITY
syr.edu

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Hector J Rios
Sent: Thursday, August 31, 2017 9:32 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Move In/Opening Week- Any Problems?

BTW, 8.2.161.0 just came out.

-H

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman
Sent: Wednesday, August 30, 2017 2:50 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Move In/Opening Week- Any Problems?

Great information. Thanks, Hector. Now I have some homework too.

-Original Message-
From: Hector J Rios [hr...@lsu.edu]
Received: Wednesday, 30 Aug 2017, 15:41
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
[WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU]
Subject: Re: [WIRELESS-LAN] Move In/Opening Week- Any Problems?
Thank you for the good thoughts on the storm. Luckily we are fine.

So far we’ve been t

RE: [WIRELESS-LAN] Move In/Opening Week- Any Problems?

2017-08-31 Thread Lee H Badman
Part of it is your EAP type, and whether users are forced to onboard to get 
configured enough to use the WLAN (like w/ TLS). With PEAP/MS-CHAPv2, I’ve seen 
many out of box, un-onboarded client device “auto connect” situations where OS 
X or Windows does figure out what it needs for EAP type, but first tries a 
couple others which fail. These can land the client in the penalty box if 
things are too tight. That’s where it feels broken to otherwise OK clients. Saw 
a lot of this on the default 60 second timer, when the client exclusion 
threshold was 3 strikes and you’re out. We had a long-running feature request 
to stretch 3 failures out to a selectable value (can now go to 10) which does 
make the longer penalty times more palatable and less likely to ensnare 
unconfigured-but-eventually-get-on-OK clients.



-Lee

Lee Badman | Network Architect

Certified Wireless Network Expert (#200)
Information Technology Services
206 Machinery Hall
120 Smith Drive
Syracuse, New York 13244
t 315.443.3003   f 315.443.4325   e lhbad...@syr.edu w 
its.syr.edu
SYRACUSE UNIVERSITY
syr.edu

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jeffrey D. Sessler
Sent: Thursday, August 31, 2017 1:10 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Move In/Opening Week- Any Problems?

Longer client exclusion times coupled with longer session timeouts mean the 
clients most impacted are the troublesome clients i.e.  it only feels broken 
for the already broken clients.

I use a 60 second exclusion timeout with very long user session timeouts. The 
longer exclusion timeouts are necessary to combat those troubling devices that 
create the equivalent of a auth DoS when they have a bad password or other 
misconfiguration. Seldom have I seen this impact a well-behaved client.

The long session timeouts are a realization that disabling a user is a rare 
thing, so why inundate the radius server every ½ hour, hour, etc. with tens of 
thousands of requests just to see if the user is still OK to be connected. If 
immediate action is necessary, use client exclusion.

Been running the above configuration for some eight years and the helpdesk 
phone is very quiet.

Jeff

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman
Sent: Thursday, August 31, 2017 8:12 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Move In/Opening Week- Any Problems?

Interesting, hopefully you get some relief. On this document about RADIUS 
timers 
https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/118703-technote-wlc-00.html
 I can’t buy in to Client Exclusion being set to 120 seconds as a rule. Even at 
60 it’s too long and makes the network feel broken. I agree 100% that it needs 
to be used on .1X networks, but with a short enough timer that the helpdesk 
phone doesn’t ring off the hook.

Wondering what value others are using here?

-Lee

Lee Badman | Network Architect

Certified Wireless Network Expert (#200)
Information Technology Services
206 Machinery Hall
120 Smith Drive
Syracuse, New York 13244
t 315.443.3003   f 315.443.4325   e lhbad...@syr.edu w 
its.syr.edu
SYRACUSE UNIVERSITY
syr.edu

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Hector J Rios
Sent: Thursday, August 31, 2017 9:32 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Move In/Opening Week- Any Problems?

BTW, 8.2.161.0 just came out.

-H

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman
Sent: Wednesday, August 30, 2017 2:50 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Move In/Opening Week- Any Problems?

Great information. Thanks, Hector. Now I have some homework too.

-Original Message-
From: Hector J Rios [hr...@lsu.edu]
Received: Wednesday, 30 Aug 2017, 15:41
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
[WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU]
Subject: Re: [WIRELESS-LAN] Move In/Opening Week- Any Problems?
Thank you for the good thoughts on the storm. Luckily we are fine.

So far we’ve been told that the issue we experienced was a combination of two 
things: 1) the 8540’s memory queues and buffers reached their maximum capacity. 
This affected both 802.1X and CAPWAP. Thus the AP flapping. 2) RADIUS and EAP 
timers must be EXTRA optimized. I say EXTRA, because we’ve always followed best 
practices and recommendations from TAC.

This is a good document to read: 
https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/118703-techno

RE: [WIRELESS-LAN] Move In/Opening Week- Any Problems?

2017-08-31 Thread Jeffrey D. Sessler
Longer client exclusion times coupled with longer session timeouts mean the 
clients most impacted are the troublesome clients i.e.  it only feels broken 
for the already broken clients.

I use a 60 second exclusion timeout with very long user session timeouts. The 
longer exclusion timeouts are necessary to combat those troubling devices that 
create the equivalent of a auth DoS when they have a bad password or other 
misconfiguration. Seldom have I seen this impact a well-behaved client.

The long session timeouts are a realization that disabling a user is a rare 
thing, so why inundate the radius server every ½ hour, hour, etc. with tens of 
thousands of requests just to see if the user is still OK to be connected. If 
immediate action is necessary, use client exclusion.

Been running the above configuration for some eight years and the helpdesk 
phone is very quiet.

Jeff

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman
Sent: Thursday, August 31, 2017 8:12 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Move In/Opening Week- Any Problems?

Interesting, hopefully you get some relief. On this document about RADIUS 
timers 
https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/118703-technote-wlc-00.html
 I can’t buy in to Client Exclusion being set to 120 seconds as a rule. Even at 
60 it’s too long and makes the network feel broken. I agree 100% that it needs 
to be used on .1X networks, but with a short enough timer that the helpdesk 
phone doesn’t ring off the hook.

Wondering what value others are using here?

-Lee

Lee Badman | Network Architect

Certified Wireless Network Expert (#200)
Information Technology Services
206 Machinery Hall
120 Smith Drive
Syracuse, New York 13244
t 315.443.3003   f 315.443.4325   e lhbad...@syr.edu w 
its.syr.edu
SYRACUSE UNIVERSITY
syr.edu

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Hector J Rios
Sent: Thursday, August 31, 2017 9:32 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Move In/Opening Week- Any Problems?

BTW, 8.2.161.0 just came out.

-H

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman
Sent: Wednesday, August 30, 2017 2:50 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Move In/Opening Week- Any Problems?

Great information. Thanks, Hector. Now I have some homework too.

-Original Message-
From: Hector J Rios [hr...@lsu.edu]
Received: Wednesday, 30 Aug 2017, 15:41
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
[WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU]
Subject: Re: [WIRELESS-LAN] Move In/Opening Week- Any Problems?
Thank you for the good thoughts on the storm. Luckily we are fine.

So far we’ve been told that the issue we experienced was a combination of two 
things: 1) the 8540’s memory queues and buffers reached their maximum capacity. 
This affected both 802.1X and CAPWAP. Thus the AP flapping. 2) RADIUS and EAP 
timers must be EXTRA optimized. I say EXTRA, because we’ve always followed best 
practices and recommendations from TAC.

This is a good document to read: 
https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/118703-technote-wlc-00.html

Finally, what is most interesting is the fact that even though the 8540 is 
advertised to support 6000 APs and 64000 clients, these numbers do not seem to 
be valid if your environment is mainly 802.1X. So, if your environment is 
mainly 802.1X, and you have an 8540, I would recommend you talk to your Cisco 
SE so they can tell you what the official supported number of APs is. I’ve yet 
to find any official documentation that even hints to this. Miercom performed a 
comparative test in 2015 between Aruba and Cisco, and in the report they did 
test client authentication rate, but only for the Cisco 5520.

https://www.cisco.com/c/dam/en/us/products/collateral/wireless/8540-wireless-controller/miercom-report-wlcs-cisco-aruba.pdf

TAC’s recommendation is for us to use 8.2.160 on the 8540s. We will make all 
necessary config changes and start moving APs in waves of 500 slowly so we can 
watch utilization. Our plan also includes not to exceed the AP capacity of the 
8540s by 50%-60%. If this works, we will have to get an additional pair of 
8540s. I’ll let you know if we are successful.

BTW, we require to have AVC turned on. TAC is very concerned about this. We’ll 
also be watching this.

-Hector

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman
Sent: Wednesday, August 30, 2017 6:43 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU

RE: [WIRELESS-LAN] Move In/Opening Week- Any Problems?

2017-08-31 Thread Lee H Badman
Interesting, hopefully you get some relief. On this document about RADIUS 
timers 
https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/118703-technote-wlc-00.html
 I can’t buy in to Client Exclusion being set to 120 seconds as a rule. Even at 
60 it’s too long and makes the network feel broken. I agree 100% that it needs 
to be used on .1X networks, but with a short enough timer that the helpdesk 
phone doesn’t ring off the hook.

Wondering what value others are using here?

-Lee

Lee Badman | Network Architect

Certified Wireless Network Expert (#200)
Information Technology Services
206 Machinery Hall
120 Smith Drive
Syracuse, New York 13244
t 315.443.3003   f 315.443.4325   e lhbad...@syr.edu w 
its.syr.edu
SYRACUSE UNIVERSITY
syr.edu

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Hector J Rios
Sent: Thursday, August 31, 2017 9:32 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Move In/Opening Week- Any Problems?

BTW, 8.2.161.0 just came out.

-H

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman
Sent: Wednesday, August 30, 2017 2:50 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Move In/Opening Week- Any Problems?

Great information. Thanks, Hector. Now I have some homework too.

-Original Message-
From: Hector J Rios [hr...@lsu.edu]
Received: Wednesday, 30 Aug 2017, 15:41
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
[WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU]
Subject: Re: [WIRELESS-LAN] Move In/Opening Week- Any Problems?
Thank you for the good thoughts on the storm. Luckily we are fine.

So far we’ve been told that the issue we experienced was a combination of two 
things: 1) the 8540’s memory queues and buffers reached their maximum capacity. 
This affected both 802.1X and CAPWAP. Thus the AP flapping. 2) RADIUS and EAP 
timers must be EXTRA optimized. I say EXTRA, because we’ve always followed best 
practices and recommendations from TAC.

This is a good document to read: 
https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/118703-technote-wlc-00.html

Finally, what is most interesting is the fact that even though the 8540 is 
advertised to support 6000 APs and 64000 clients, these numbers do not seem to 
be valid if your environment is mainly 802.1X. So, if your environment is 
mainly 802.1X, and you have an 8540, I would recommend you talk to your Cisco 
SE so they can tell you what the official supported number of APs is. I’ve yet 
to find any official documentation that even hints to this. Miercom performed a 
comparative test in 2015 between Aruba and Cisco, and in the report they did 
test client authentication rate, but only for the Cisco 5520.

https://www.cisco.com/c/dam/en/us/products/collateral/wireless/8540-wireless-controller/miercom-report-wlcs-cisco-aruba.pdf

TAC’s recommendation is for us to use 8.2.160 on the 8540s. We will make all 
necessary config changes and start moving APs in waves of 500 slowly so we can 
watch utilization. Our plan also includes not to exceed the AP capacity of the 
8540s by 50%-60%. If this works, we will have to get an additional pair of 
8540s. I’ll let you know if we are successful.

BTW, we require to have AVC turned on. TAC is very concerned about this. We’ll 
also be watching this.

-Hector

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman
Sent: Wednesday, August 30, 2017 6:43 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Move In/Opening Week- Any Problems?


Hi Hector,



I hope the storm is not causing havoc for you down there- good thoughts to you 
on that.



Did you get anywhere with Cisco on your 8540/8.2.160 problems? I'm being told 
we may need to go that same combination and it doesn't inspire confidence.



Evidently my 8.2.151 (you know... one of those STABLE code versions) may be a 
time bomb that caused a spontaneous 8540 reboot. The comment was made that our 
3300 APs on a platform that supposedly supports 6000 somehow equals a dense 
deployment and that we likely are hitting:

___
Regarding the logs, I was able to check the logs, and yes It seems your 
deployment is a high-density deployment with over 3000 APs.

Based on your deployment and the logs I was able to identify this

It seems the WLC is having load process utilization  on the task SpamReceive 
Task and HAConfigSyncTask.

spamApTask15992   ( 53/ 78)0 (  0/  0)%  30   22
 spamApTask05991   ( 72/ 70)0 (  0/  0)%  305
 spamReceiveTask5990   ( 52/ 78)0 (  0/  0)%  990
 spamSocketTask 5989   (175/ 32) 

RE: [WIRELESS-LAN] Free Aruba APs - just pay shipping

2017-08-31 Thread Harris, Robert
If there are 1 or 2 of the IAPs left, I would gladly pay to have them shipped 
here please, let me know, thanks!

[The Culinary Institute of America]
Robert Harris
Manager of Network Services
Culinary Institute of America
1946 Campus Drive
Hyde Park, NY
845-451-1681
www.ciachef.edu
Food is Life
Create and Savor Yours.™

Please consider the environment before printing this e-mail.

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Kobiske, Rob
Sent: Thursday, August 31, 2017 9:49 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Free Aruba APs - just pay shipping

Brad,

If the IAPs are still available, I’d be willing to take those.

Thanks,
Rob Kobiske
University of Wisconsin – Stevens Point

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Brad Weldon
Sent: Wednesday, August 30, 2017 12:02 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] Free Aruba APs - just pay shipping

After recent campus upgrades, we have an excess of Aruba APs that we'd like to 
give away to anyone willing to pay shipping costs from zip code 97132.

73 each Aruba AP105
9 each Aruba IAP105
28 each Aruba AP125

End of Life Statement from Aruba Networks:
http://www.arubanetworks.com/support-services/end-of-life/#AccessPoints

After 10/31/2017, all remaining units will be recycled and no longer available.

- - - - -
Brad Weldon
Network Engineer
George Fox University
503.554.2571
- - - - -
** Participation and subscription information for this EDUCAUSE 
Constituent Group discussion list can be found at 
http://www.educause.edu/discuss.
** Participation and subscription information for this EDUCAUSE 
Constituent Group discussion list can be found at 
http://www.educause.edu/discuss.

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/discuss.



RE: [WIRELESS-LAN] Free Aruba APs - just pay shipping

2017-08-31 Thread Kobiske, Rob
Brad,

If the IAPs are still available, I’d be willing to take those.

Thanks,
Rob Kobiske
University of Wisconsin – Stevens Point

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Brad Weldon
Sent: Wednesday, August 30, 2017 12:02 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] Free Aruba APs - just pay shipping

After recent campus upgrades, we have an excess of Aruba APs that we'd like to 
give away to anyone willing to pay shipping costs from zip code 97132.

73 each Aruba AP105
9 each Aruba IAP105
28 each Aruba AP125

End of Life Statement from Aruba Networks:
http://www.arubanetworks.com/support-services/end-of-life/#AccessPoints

After 10/31/2017, all remaining units will be recycled and no longer available.

- - - - -
Brad Weldon
Network Engineer
George Fox University
503.554.2571
- - - - -
** Participation and subscription information for this EDUCAUSE 
Constituent Group discussion list can be found at 
http://www.educause.edu/discuss.

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/discuss.



RE: [WIRELESS-LAN] Move In/Opening Week- Any Problems?

2017-08-31 Thread Hector J Rios
BTW, 8.2.161.0 just came out.

-H

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman
Sent: Wednesday, August 30, 2017 2:50 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Move In/Opening Week- Any Problems?

Great information. Thanks, Hector. Now I have some homework too.

-Original Message-
From: Hector J Rios [hr...@lsu.edu]
Received: Wednesday, 30 Aug 2017, 15:41
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
[WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU]
Subject: Re: [WIRELESS-LAN] Move In/Opening Week- Any Problems?
Thank you for the good thoughts on the storm. Luckily we are fine.

So far we’ve been told that the issue we experienced was a combination of two 
things: 1) the 8540’s memory queues and buffers reached their maximum capacity. 
This affected both 802.1X and CAPWAP. Thus the AP flapping. 2) RADIUS and EAP 
timers must be EXTRA optimized. I say EXTRA, because we’ve always followed best 
practices and recommendations from TAC.

This is a good document to read: 
https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/118703-technote-wlc-00.html

Finally, what is most interesting is the fact that even though the 8540 is 
advertised to support 6000 APs and 64000 clients, these numbers do not seem to 
be valid if your environment is mainly 802.1X. So, if your environment is 
mainly 802.1X, and you have an 8540, I would recommend you talk to your Cisco 
SE so they can tell you what the official supported number of APs is. I’ve yet 
to find any official documentation that even hints to this. Miercom performed a 
comparative test in 2015 between Aruba and Cisco, and in the report they did 
test client authentication rate, but only for the Cisco 5520.

https://www.cisco.com/c/dam/en/us/products/collateral/wireless/8540-wireless-controller/miercom-report-wlcs-cisco-aruba.pdf

TAC’s recommendation is for us to use 8.2.160 on the 8540s. We will make all 
necessary config changes and start moving APs in waves of 500 slowly so we can 
watch utilization. Our plan also includes not to exceed the AP capacity of the 
8540s by 50%-60%. If this works, we will have to get an additional pair of 
8540s. I’ll let you know if we are successful.

BTW, we require to have AVC turned on. TAC is very concerned about this. We’ll 
also be watching this.

-Hector

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman
Sent: Wednesday, August 30, 2017 6:43 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Move In/Opening Week- Any Problems?


Hi Hector,



I hope the storm is not causing havoc for you down there- good thoughts to you 
on that.



Did you get anywhere with Cisco on your 8540/8.2.160 problems? I'm being told 
we may need to go that same combination and it doesn't inspire confidence.



Evidently my 8.2.151 (you know... one of those STABLE code versions) may be a 
time bomb that caused a spontaneous 8540 reboot. The comment was made that our 
3300 APs on a platform that supposedly supports 6000 somehow equals a dense 
deployment and that we likely are hitting:

___
Regarding the logs, I was able to check the logs, and yes It seems your 
deployment is a high-density deployment with over 3000 APs.

Based on your deployment and the logs I was able to identify this

It seems the WLC is having load process utilization  on the task SpamReceive 
Task and HAConfigSyncTask.

spamApTask15992   ( 53/ 78)0 (  0/  0)%  30   22
 spamApTask05991   ( 72/ 70)0 (  0/  0)%  305
 spamReceiveTask5990   ( 52/ 78)0 (  0/  0)%  990
 spamSocketTask 5989   (175/ 32)0 (  0/  0)%   0   13
 HAPeerToPeerCommTa 5988   ( 90/ 64)0 (  0/  0)%   07
 rmgrPing   5987   ( 80/ 67)0 (  0/  0)%   0   13

HAConfigSyncTask   6204   (240/  7)0 (  0/  0)%  993
​
Based on the symptoms, the WLC version and your WLC density. You may be hitting 
bug.

CSCvd20251 - Data Plane stopped working on Cisco 5508 WLC running 
8.0.140.0
 ___
I hope to have confirmation today. I can't imagine what Cisco could have done 
between .151 and .6 to make this sort of thing better, and I am really 
interested in whether they isolated your own .160 problems. There is no way in 
hell I'm moving to that version without seeing case notes on every single issue 
people are having in this continual cycle of trading one set of bugs for 
another.

This game just isn't fun anymore.

Thanks-




Lee Badman | Network Architect | CWNE #200
Information Technology Services
206 Machinery Hall
120 Smith Drive
Syracuse, New York 13244
t 315.443.3003   f 315.443.4325   e lhbad...@syr.edu<