Higher Education

Reply
This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.
Highlighted
All-Decade MVP 2020

Re: Regular complaints of getting disconnected coming in from students


@cjoseph wrote:

- Make sure your access point is min and max TX are at 12 and 18 to match the power of clients that would be connecting to it.

 

 


Hi Colin,

 

Just to clarify, are you referring to 'min-tx-power' and 'max-tx-power' commands within the ARM profile? Thismight help those who have the default value (127).

 

From the 6.3 UG:

 

max-tx-power

Maximum effective isotropic radiated power (EIRP) from 3 to 33 dBm in 3 dBm increments. You may also specify a special value of 127 dBm for regulatory maximum to disable power adjustments for environments such as outdoor mesh links. This value takes into account both radio transmit power and antenna gain. Higher power level settings may be constrained by local regulatory requirements and AP capabilities.

 

Range:  3, 6, 9, 12, 15,18, 21, 24,27, 30, 33,127

 

Default: 127 dBm

Highlighted
Guru Elite

Re: Regular complaints of getting disconnected coming in from students

mldickson,

 

Yes.  Max-TX-Power in the ARM profile for the 802.11a band 18.  Min-TX-Power in the ARM profile on the 802.11a band 12.

 

There is nothing wrong with starting off the 802.11g ARM profile with these same settings;  users with significant density might want to change the 802.11g profile to MAX 15 and MIN 9.

 

 

 


*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.5 User Guide
InstantOS 8.5 User Guide
Airheads Knowledgebase
Airheads Learning Videos
Remote Access Point Solution Guide
ArubaOS Consolidated Release Notes
ArubaOS 8 ViA VPN Solution Guide
Highlighted

Re: Regular complaints of getting disconnected coming in from students

I wanted to give an update on how things turned out.  We ended up closing the ticket due to a lack of data.  Sadly, we could never recreate the problem or capture enough data with debugs to identify an actionable problem.  So the habit of turning off/on their wifi adapter is still the quickest fix for the problem.

 

Thanks for all of the great suggestions these last few months and good luck to those still working through their own tickets.

 

Aaron

Highlighted
Contributor II

Re: Regular complaints of getting disconnected coming in from students

I'll tack on to that.  We are a relatively new Aruba shop and are still working things out as we upgrade from our older Cisco wireless.  Similar to others, we had reports of disconnects and issues and went through some troubleshooting and tickets.  We were watching this thread with interest thinking it sounded like there was some global Aruba issue that was going to be sussed out.

 

In a number of cases, we updated client software to fix the issue (some known Yosemite updates, some very old Ubuntu digital signage installations, and so on).  In other cases, we are still in the process of tweaking our AP placements and power settings.  Coming from Cisco, our first pass was to put an Aruba AP wherever we had a Cisco one.  While the Cisco APs were mostly omni-directional antennas, the Arubas are designed to hang on the ceiling grid and aim down.  In some spots, this caused us to rethink and shift our AP placements.  In others, we simply did not have enough APs for coverage and ended up placing more.  Indeed, AirWave showed us that some clients were being moved due to "load balancing" in places where we were getting reports from.  So, we ended up solving a lot of our own "disconnect" issues, and we continue to revist AP placements, etc. across campus.

 

The part of this thread that I can't comment on (and can't get out of my head) is the reports by some that "we've had Aruba a while and this just started happening on the newer OS versions".  We started on 6.4.x.x so we've known nothing else.

 

At any rate, I would say it is certainly worth revisiting "the basics" of wireless deployments to see if things like that might be in play.

Highlighted

Re: Regular complaints of getting disconnected coming in from students

For areas where ceiling mount APs are not desired, we have been using APs with onmidirectional external antennas (AP-224 instead of AP-225).

 

As Aruba keeps adding more features and enhancing existing ones, sometimes issus are created and wireless strategies are changed to ultimately make things work better.

 

You should expect a few more issues on ArubaOS 6.4 because the OS is a Technical Preview used to find and resolve more bugs. Some companies that have a specific need for the new features run 6.4 too. We are running the lates 6.3 General Availability release because, currently, reliability is one of our top concerns and we have not yet seen a 6.4 feature that says we need to switch yet. We also have some older APs that will not work on 6.4 and must be replaced.

 

This Aruba Solution should give you some good wireless design ideas. It is primarily written bu one of the advanced Aruba Support Engineers. https://ase.arubanetworks.com/solutions/id/75


Bruce Osborne - Wireless Engineer
ACCP, ACMP

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

Highlighted
Occasional Contributor II

Re: Regular complaints of getting disconnected coming in from students


aaron.smith@swarthmore.edu wrote:

I wanted to give an update on how things turned out.  We ended up closing the ticket due to a lack of data.  Sadly, we could never recreate the problem or capture enough data with debugs to identify an actionable problem.  So the habit of turning off/on their wifi adapter is still the quickest fix for the problem.

 

Thanks for all of the great suggestions these last few months and good luck to those still working through their own tickets.

 

Aaron


We had the same exact issue with our ticket.  The issue was non-reproducable and even when we could collect data with an engineer on the line the data was incomplete or inconclusive.

Highlighted
All-Decade MVP 2020

Re: Regular complaints of getting disconnected coming in from students

I also want to provide an update. While troubleshooting reports of dropped connections and other ephemeral anomalies reported in this thread, we did a comprehensive analysis of all ancillary services supporting wireless. This included DHCP, DNS, and the authentication backend infrastructure.  We discovered that during high mobility events (class changes) delays increased from some point downstream of our radius servers, causing "back pressure" on the radius servers, but no auth dead events.

 

To the device this manifested as dropped connections on 802.1X, particularly in dense environments (high roaming events). To the user this is perceived as degradation and dropped connections.

 

After some digging it was determined that saslauthd (provides ldap -> kerberos lookups) was slogging during these peak times. We resolved that issue and quickly found that the radius servers were now insufficient to handle to newly-unconstrained throughput. We doubled the amount of radius servers serving .1X . We also physically moved them closer to the controllers, direct-connected them to the same router hosting our controllers. This reduced packet hop count and redundant traverasl of established authentication network links. This eliminated the timeouts, even during high mobility events, and reduced radius auths-per-second to a more reasonable number.

 

Having resolved the backend auth delays we are now getting reports of happier clients and can verify faster roaming events and handoffs. We cleared out our t-ticket queue and are now looking at new trouble reports with a fresh perspective.

 

While this certainly won't apply to many (most?) who are experincing issues the take away for us was to look deeper into *all* components that make up what we call "wireless".

 

Mike

 

Highlighted
Moderator

Re: Regular complaints of getting disconnected coming in from students

Great post. Highlights that the scale of networks and large mobility events need tolooked at holistically.
Highlighted
Moderator

Re: Regular complaints of getting disconnected coming in from students

Great write-up Mike, thanks!

 

This also helps to highlight why EAP-TLS is preferred over EAP-PEAP and EAP-TTLS when feasible. LDAP/AD add additional latency to an authentication request.



If this response is more than 1 year old, it may no longer be accurate. Please consult official Aruba documentation, TAC or your Aruba SE.

| Aruba Alumni | @timcappalli | timcappalli.me |

Highlighted
Guru Elite

Re: Regular complaints of getting disconnected coming in from students


@mldickson wrote:

I also want to provide an update. While troubleshooting reports of dropped connections and other ephemeral anomalies reported in this thread, we did a comprehensive analysis of all ancillary services supporting wireless. This included DHCP, DNS, and the authentication backend infrastructure.  We discovered that during high mobility events (class changes) delays increased from some point downstream of our radius servers, causing "back pressure" on the radius servers, but no auth dead events.

 

To the device this manifested as dropped connections on 802.1X, particularly in dense environments (high roaming events). To the user this is perceived as degradation and dropped connections.

 

After some digging it was determined that saslauthd (provides ldap -> kerberos lookups) was slogging during these peak times. We resolved that issue and quickly found that the radius servers were now insufficient to handle to newly-unconstrained throughput. We doubled the amount of radius servers serving .1X . We also physically moved them closer to the controllers, direct-connected them to the same router hosting our controllers. This reduced packet hop count and redundant traverasl of established authentication network links. This eliminated the timeouts, even during high mobility events, and reduced radius auths-per-second to a more reasonable number.

 

Having resolved the backend auth delays we are now getting reports of happier clients and can verify faster roaming events and handoffs. We cleared out our t-ticket queue and are now looking at new trouble reports with a fresh perspective.

 

While this certainly won't apply to many (most?) who are experincing issues the take away for us was to look deeper into *all* components that make up what we call "wireless".

 

Mike

 


Mike,

 

Excellent work!

 

Do you now have a ratio of users, access points or authentications/second calculation formula to know when to add an additional radius server or are you just monitoring saslauthd?  Others are probably looking for guidance on how to monitor their radius infrastructure....

 


*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.5 User Guide
InstantOS 8.5 User Guide
Airheads Knowledgebase
Airheads Learning Videos
Remote Access Point Solution Guide
ArubaOS Consolidated Release Notes
ArubaOS 8 ViA VPN Solution Guide
Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: