Higher Education

Reply
This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.
New Member

Re: Regular complaints of getting disconnected coming in from students

I am seeing the exact same thing happen on my network. We have redundant 3600 masters, 2 7240's in one location, and 6 M3's split up evenly between 3 other locations. We have about 1,800 APs mixed between 105's, 125's, 135's and some 225's. We just upgraded to 6.3.1.10 from 6.3.1.8 this week to fix a different problem and it did not solve this issue. It does not seem to be happening on our 802.1x SSID, only our open SSID.

 

Tom

 

Johnson & Wales University

New Contributor

Re: Regular complaints of getting disconnected coming in from students

Another institution checking in with this problem.  We are migrating for a lone 3600 controller to master/local 7210's, with approximately 150 AP's.  Most are AP-125's, but around 20 of the 225's as well.  We have been on 6.4.0.3 for quite awhile now.  Haven't had any reports of issues until recently.  Unlike the previous poster, the only reports we are getting are on our 802.1X network, not the other open/captive portal networks.  

 

We have had issues with machines taking 5+ minutes to be able to login (machine not picking up the AP), machines dropping connections during usage, etc.  We have just begun troubleshooting in earnest, but if I find out anything I will post it here.

 

Patrick

Massasoit Community College

Re: Regular complaints of getting disconnected coming in from students

Thank you everyone that has chimed in on this ticket!  Knowing other schools are having the problem helps, as well as hearing suggestions and questions.

 

Not much to add.  We tried turning off Client Match but still had the problem.   Not being able to reproduce the problem at will is really frustrating the effort.  Most recently we have moved some of the students experiencing the problem to the eduroam SSID to see if they still have the problem.  The hope being that this would eliminate some variables since the eduroam SSID is still an dot1x SSID but has fewer changes from the default options and Bradford is not part of the equation at all.   Divide and conquer.

 

If anything changes I will let you know.

Occasional Contributor I

Re: Regular complaints of getting disconnected coming in from students

I have been going over what is going on here and making a time line of all changes upgrades and etc that have gone on. We upgraded our Aruba controller's from 6.2.1.3 to 6.3.1.5 back in April of this year. We wanted to start to take advantage of Airgroups. Well it wasn't but a week in to the semester when we started getting a few reports of drops and as the semester is going on we have gotten much more. Now we have upgraded a few more since then to the current code. I see that there are reports on the 6.4 code as well but has any one heard or seen this dropping issue occured in the previous 6.2 and back versions? I have put this to my Ticket and Sales engineer as well but I thought I'd also put this out there to see if it indeed is a pattern. Or is maybe something to do with Airgroups. I've speculated about disabling that as well. 

 

Ron Gilmore

IT - Network Operations

SUNY Oneonta

New Contributor

Re: Regular complaints of getting disconnected coming in from students

Hey there, 

 

So we have come accross similar issues here at liberty and wanted to see if anybody else is seeing this. We first reviewed our 802.1x (AAA) timers, idle timeout, Station ageout and updated our client match band steering thresholds. After further investigation we took three clients with the disconnect issue and monitored over a 24 period. During this time i found multiple channel changes were occuring. 

 

AoS 6.3.1.13

HA 7220 Masters and 4 local 7220s the 4th being N+1.

Issue has been occuring since semister startup.

We use 4 20k CPPM physical nodes behind an F5 for Radius Auth Airgroup, Guest, etc.

 

When running the show ap arm history command we saw a lot of channel changes with the reason "E: Error threshold exceeded". 

 

Interface :wifi0
ARM History
-----------
Time of Change Old Channel New Channel Old Power New Power Reason
-------------- ----------- ----------- --------- --------- ------
2014-11-06 14:48:09 149+ 149+ 21 24 P+
2014-11-06 14:42:04 149+ 149+ 18 21 P+
2014-11-06 10:51:53 149+ 149+ 24 18 P-
2014-11-06 02:00:13 161- 149+ 24 24 E
2014-11-05 19:40:10 153- 161- 24 24 E
2014-11-05 19:39:08 157+ 153- 24 24 E
2014-11-05 19:29:38 153- 157+ 24 24 E
2014-11-05 19:14:06 153- 153- 21 24 P+
2014-11-05 18:42:08 153- 153- 18 21 P+
2014-11-05 14:59:19 40- 153- 18 18 E
2014-11-05 14:58:13 40- 40- 24 18 P-
2014-11-05 14:51:44 157+ 40- 24 24 E
2014-11-05 13:12:03 157+ 157+ 21 24 P+
2014-11-05 12:49:47 157+ 157+ 18 21 P+
2014-11-05 12:36:43 157+ 157+ 24 18 P-
2014-11-05 11:47:33 40- 157+ 24 24 E
2014-11-05 10:06:35 40- 40- 21 24 P+
2014-11-05 10:02:18 40- 40- 18 21 P+
2014-11-05 09:50:39 40- 40- 24 18 P-
Interface :wifi1
ARM History
-----------
Time of Change Old Channel New Channel Old Power New Power Reason
-------------- ----------- ----------- --------- --------- ------
2014-11-05 06:43:09 11 11 15 12 P-
2014-11-05 06:38:51 11 11 12 15 P+
I: Interference, R: Radar detection, N: Noise exceeded, Q: Bad Channel Quality E: Error threshold exceeded, INV: Invalid Channel, G: Rogue AP Containment, M: Empty Channel, P+: Increase Power, P-: Decrease Power, 40INT: 40MHZ intol detected on 2.4G, NO40INT: 40MHz intol cleared on 2.4G, OFF: Turn off Radio, ON: Turn on Radio

(JFL-local-01) #show ap association ap-name RCH01-A827-AP135

The phy column shows client's operational capabilities for current association

Flags: A: Active, B: Band Steerable, H: Hotspot(802.11u) client, K: 802.11K client, R: 802.11R client, W: WMM client, w: 802.11w client

PHY Details: HT : High throughput; 20: 20MHz; 40: 40MHz
VHT : Very High throughput; 80: 80MHz; 160: 160MHz; 80p80: 80MHz + 80MHz
<n>ss: <n> spatial streams

 

Association Table
-----------------
Name bssid mac auth assoc aid l-int essid vlan-id tunnel-id phy assoc. time num assoc Flags Band steer moves (T/S)
---- ----- --- ---- ----- --- ----- ----- ------- --------- --- ----------- --------- ----- ----------------------
RCH01-A827-AP135 24:de:c6:0c:4c:91 7c:7a:91:cd:de:21 y y 1 250 Liberty-Secure 3801 0x104af a-HT-40sgi-2ss 2h:54m:52s 1 WAB 0/0
RCH01-A827-AP135 24:de:c6:0c:4c:82 50:1a:c5:c0:f3:0d y y 1 10 Liberty-Wireless 3920 0x104b4 g-HT-20-2ss 21h:29m:43s 1 WAB 0/0
RCH01-A827-AP135 24:de:c6:0c:4c:91 60:03:08:8f:05:5c y y 3 10 Liberty-Secure 3825 0x104af a-HT-40sgi-3ss 42m:59s 1 WAB 0/0
Num Clients:3
Total num of 5G capable clients:3
Total num of 5G capable clients in 2.4G band:1
Total num of 5G capable clients in 5G band:2
Total num of 2.4G only clients:0

 

When conducting a client trail we found the following:

 

Client Trail Info
-----------------
MAC BSSID ESSID AP-name VLAN Deauth Reason Alert
--- ----- ----- ------- ---- ------------- -----
50:1a:c5:c0:f3:0d 24:de:c6:0c:4c:82 Liberty-Wireless RCH01-A827-AP135 3920 Unspecified Failure Unspecified Failure

Deauth Reason
-------------
Reason Timestamp
------ ---------
Unspecified Failure Nov 5 19:39:07
Unspecified Failure Nov 5 19:29:37
Unspecified Failure Nov 5 14:59:19
Unspecified Failure Nov 5 14:51:43
Unspecified Failure Nov 5 11:47:32
STA has left and is deauthenticated Nov 5 11:34:02
STA has left and is deauthenticated Nov 5 11:33:08
STA has left and is deauthenticated Nov 5 11:30:33
Num Deauths:8

Alerts
------
Reason Timestamp
------ ---------
Unspecified Failure Nov 5 19:39:07
Unspecified Failure Nov 5 19:29:37
Unspecified Failure Nov 5 14:59:19
Unspecified Failure Nov 5 14:51:43
Unspecified Failure Nov 5 11:47:32
STA has left and is deauthenticated Nov 5 11:34:02
STA has left and is deauthenticated Nov 5 11:33:08
STA has left and is deauthenticated Nov 5 11:30:33
Num Alerts:8

Mobility Trail
--------------
BSSID ESSID AP-name Timestamp
----- ----- ------- ---------
24:de:c6:0c:4c:82 Liberty-Wireless RCH01-A827-AP135 Nov 5 19:39:10
24:de:c6:0c:4c:92 Liberty-Wireless RCH01-A827-AP135 Nov 5 19:39:07
24:de:c6:0c:4c:92 Liberty-Wireless RCH01-A827-AP135 Nov 5 19:29:41
24:de:c6:0c:4c:92 Liberty-Wireless RCH01-A827-AP135 Nov 5 19:29:37
24:de:c6:0c:4c:92 Liberty-Wireless RCH01-A827-AP135 Nov 5 14:59:24
24:de:c6:0c:4c:92 Liberty-Wireless RCH01-A827-AP135 Nov 5 14:59:19
24:de:c6:0c:4c:92 Liberty-Wireless RCH01-A827-AP135 Nov 5 14:51:48
24:de:c6:0c:4c:92 Liberty-Wireless RCH01-A827-AP135 Nov 5 14:51:43
24:de:c6:0c:4c:92 Liberty-Wireless RCH01-A827-AP135 Nov 5 13:29:07
24:de:c6:0c:4c:92 Liberty-Wireless RCH01-A827-AP135 Nov 5 11:47:32
Num Mobility Trails:10

 

In most clients when we see "Unspecified Failure" it matches up with the channel changes that reside with the threshold errors. Currently we have a known issue with our internet pipes being over subscibed and are in the process of upgrading to 10gb uplings. I think some of what were is airtime being crowded due retrys however when we look at the controller the channels look healthy for this ap on the 5ghz.

 

Airwave RF capacity statisics below for the follow A radio. The WAP is an AP135 that averages 8 clinets per radio. 

 

 Last Min Max Avg 

 
Busy
16.93 %1.57 %33.46 %11.42 %
 
Interference
1.57 %0 %24.41 %1 %
 
Receiving
9.84 %0.79 %30.71 %8.27 %
 
Transmitting
6.69 %0 %16.93 %2.76 %

 

 

AoS 6.3.1.13

HA 7220 Masters and 4 local 7220s the 4th being N+1.

Issue has been occuring since semister startup.

We use 4 20k CPPM physical nodes behind an F5 for Radius Auth Airgroup, Guest, etc.

T.J. Norton - Wireless Architect

All opinions written here are my own and do not necessarily reflect the views and opinions of my employer or Aruba Networks
Highlighted
Guru Elite

Re: Regular complaints of getting disconnected coming in from students

Tnorton7,

Why is your access point at power levels 21 and 24? It should probably be no more than 18 or you will observe interference like you have seen.

in addition, since you have 40 megahertz channelsyour access points only have 4 channels to go to avoid interference. You should use 20 megahertz channels and it will give youmore room.

*Answers and views expressed by me on this forum are my own and not necessarily the position of Aruba Networks or Hewlett Packard Enterprise.*
ArubaOS 8.4 User Guide
InstantOS 8.3 User Guide
Airheads Knowledgebase
Airheads Learning Videos
Aruba Central Documentation
Sign up for Security Alerts
Aruba Technical Webinars
New Contributor

Re: Regular complaints of getting disconnected coming in from students

Hey Colin, That makes sense to me as of right now we are still using the default ARM profiles on a lot of our AP groups. In terms of 20 meg channels I agree with you there. We have been working to move away from 40 mhz channels in our dense enviorments but have yet to make the change. Ron is planning on coming out the 19th and that is one of the areas i wanted to get his input on. We will do some reading up on what changes need to be made in this area and coordinate with you guys. Thanks for the input! 

T.J. Norton - Wireless Architect

All opinions written here are my own and do not necessarily reflect the views and opinions of my employer or Aruba Networks
Frequent Contributor I

Re: Regular complaints of getting disconnected coming in from students

Hi Aaron,

 

Like everyone else has mentioned on the forums, you are not alone.  We've also noted isolated instances where this appears to be occuring @ Drexel.  

 

We were first alerted to the situation w/ a campus in Sacramento, CA.  The report focused on the specific issue of iPads being disconnected & searching for wifi & then re-connecting; never explicitly needing to re-authenticate, but interrupting flows while it scans & re-associates w/ the wifi network.  We disabled Client Match for the profile in use there and have not heard of any major complaints since then; which reminds me that I need to follow up.  

 

I've also heard scattered reports from various individuals around campus; not a lot, less than 5 - 7.  However, for those that occur in a specific location / building, we can also disable Client Match on the AP Group Profile, should the need arrise.  

 

We're running AOS 6.3.5 & the release notes for 6.3.7 state that they've added an Client Match config parameter to help lessen its aggressiveness.  Hopefully, upgrading to the latest stable release will help alleviate any issues.  

 

Since not that many users complain, we aren't turning off Client Match campus wide just yet.  For those that do, I've been disabling Client Match on individual machines w/ a command Gallagher provided me.

 

add ap arm client-match unsupported <mac>

 After doing so I've tried to maintain an eye on the client in Airwave & have ask them to follow up if they notice any significant change.  

 

Possibly related to this whole mess is wifi issues w/ Mac OS X Yosemite; not sure how much of your client base is Mac OS X & what percentage of them have upgraded.  See this PC World article.   I just added a 10.10 user to the client-match unsupported list and did not immediately observe any noticable change in their Association History via Airwave.  I've asked the user to comment & they did note that the issue appeared to still occur; in which case, I'm assuming its OS based.  

 

BTW, after disabling Client Match in Sacramento, we DID observe a substantial decrease in the number of association history entires; which makes sense being that they're no longer being steered.  More importantly, the complains have seemed to have subsided.  

 

I'm using the client-match unsupported to try and handle those that bring up issues about constant disconnections.   If they're running Mac OS X 10.10 & they constantly get disconnected, then disabling Client Match will hopefully improve the situation; but if it doesn't, then the issue might be w/ the OS.  If the complaining machine is a non Mac OS computer, then if disconnections lessen, it only lets us know that Client Match has been set too aggressively.  

  

 

 

--Raf
Guru Elite

Re: Regular complaints of getting disconnected coming in from students


Raf,

 

I believe a full post-mortem of what is going in those specific portions of your network is warranted.  Adding devices to the unsupported list is not scalable and is not encouraged.  

 

 


*Answers and views expressed by me on this forum are my own and not necessarily the position of Aruba Networks or Hewlett Packard Enterprise.*
ArubaOS 8.4 User Guide
InstantOS 8.3 User Guide
Airheads Knowledgebase
Airheads Learning Videos
Aruba Central Documentation
Sign up for Security Alerts
Aruba Technical Webinars
Guru Elite

Re: Regular complaints of getting disconnected coming in from students


@tnorton7@liberty.edu wrote:

Hey Colin, That makes sense to me as of right now we are still using the default ARM profiles on a lot of our AP groups. In terms of 20 meg channels I agree with you there. We have been working to move away from 40 mhz channels in our dense enviorments but have yet to make the change. Ron is planning on coming out the 19th and that is one of the areas i wanted to get his input on. We will do some reading up on what changes need to be made in this area and coordinate with you guys. Thanks for the input! 


tnorton7,

 

You can go to 20mhz channels without any issues, because all clients support 20mhz channels.  You also gain 5 channels in the process and reduce your interference footprint.  The power of your access points is also crucial because many, many performance and disconnection issues have too high or too lower power at the root of those issues.  

 

Everyone on this thread should first check the range of their power on their access points (12 to 18 range) to ensure that they are not creating or contributing to their issues.

 


*Answers and views expressed by me on this forum are my own and not necessarily the position of Aruba Networks or Hewlett Packard Enterprise.*
ArubaOS 8.4 User Guide
InstantOS 8.3 User Guide
Airheads Knowledgebase
Airheads Learning Videos
Aruba Central Documentation
Sign up for Security Alerts
Aruba Technical Webinars
Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: