Wireless Access

Reply
New Contributor
Posts: 4
Registered: ‎07-16-2013

Aruba6000, Version 3.4.5.1, Switched form 1024 to 2048 bit cert, High CPU Usage, Captive Portal

We have a wireless deployment that consists of a mix of about 250 Aruba AP60 and AP61 units split over (2) Aruba 6000 chassis with a single Supervisor-2 card in each 6000.

 

We average around 300 users spit across both systems.

 

We have always used 1024 bit certs.  This October, 1024 is being replaced with 2048 bit as an industry standard.  We can no longer get 1024 bit certs for our https captive portal page.

 

We just updated our certs today from 1024 to 2048 with less than desirable results.  Our processors went from roughly 30% usage to 90% usage.  Rolling the certs back drops us back down to the 30% area.

 

So, my quesion is, is this a code issue or a hardware issue?  What are my options?  Will a code upgrade fix this issue or do I have to drop an M3 controller card into each Aruba6000?

 

Suggestions welcome from anyone!

Guru Elite
Posts: 20,761
Registered: ‎03-29-2007

Re: Aruba6000, Version 3.4.5.1, Switched form 1024 to 2048 bit cert, High CPU Usage, Captive Portal

[ Edited ]

How many users are hitting that Captive Portal (bringing up the captive portal page or authenticating) simultaneously?  I would suspect that is what is driving your utilization up.  

 

type "show web-server" to see how many concurrent clients your have your web server restricted to (25 is the default).  

 

Serving up a Captive Portal with a 2048-bit certificate is definitely more computationally intensive, so to service the same amount of clients as you did with a 1024-bit cert, you would have to go to a more powerful platform like the M3; correct.



Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

New Contributor
Posts: 4
Registered: ‎07-16-2013

Re: Aruba6000, Version 3.4.5.1, Switched form 1024 to 2048 bit cert, High CPU Usage, Captive Portal

How many users are hitting that Captive Portal (bringing up the captive portal page or authenticating) simultaneously?  I would suspect that is what is driving your utilization up.  

 

 - I'm not sure how to tell.  Would I just do a show user and see how many are in logon or do you check that number differently?

 

type "show web-server" to see how many concurrent clients your have your web server restricted to (25 is the default).  

 

User session timeout <30-3600> (seconds)       900
Maximum supported concurrent clients <25-400>  25

- Are you recommending that I adjust that number to help with the new certificate?  What would a decent value be that would alleviate some of the CPU utilization?

 

Serving up a Captive Portal with a 2048-bit certificate is definitely more computationally intensive, so to service the same amount of clients as you did with a 1024-bit cert, you would have to go to a more powerful platform like the M3; correct.

 

- Is changing from a supervisor-2 to an M3 something that's pretty much straight forward?  I want to keep the exact same config but move all of the APs to the new M3 (slave) .  If we buy the M3 I would want to take the 256 AP licenses off of each sup-2 card and roll them both onto the M3.  I would let one of the old sup-2 cards be the master (with no APs on it), the new M3 be a slave (with 512 APs), and retire the other old sup-2.

New Contributor
Posts: 4
Registered: ‎07-16-2013

Re: Aruba6000, Version 3.4.5.1, Switched form 1024 to 2048 bit cert, High CPU Usage, Captive Portal

Also, there is a bug in the older versions of code.  I was wondering if upgrading to version 5.x is going to make this problem with using a 2048 bit cert better or worse?

 

------------------------------------------------------------------------------------------------------------------------------------------------

Product and Software: This article applies to ArubaOS 3.3.2 and 3.4.0.

The controller CPU utilization may intermittently spike to more than 80%.

Such spikes might occur when HTTPS based captive portal authentication is deployed for a large number of users on the legacy platforms such as A200, A800, A2400, SC-I and SC-II based controllers.

One cause for such high utilization is the use of the 2048-bit certificate to establish the SSL sessions between the controller and the stations.

To reduce the load, use the 1024-bit certificate.
------------------------------------------------------------------------------------------------------------------------------------------------
Guru Elite
Posts: 20,761
Registered: ‎03-29-2007

Re: Aruba6000, Version 3.4.5.1, Switched form 1024 to 2048 bit cert, High CPU Usage, Captive Portal

It is a bug, but the workaround is to use 1024 bit certificates.  The sup-2 simply cannot support the same number of sessions without higher utilization.  This cannot be fixed.

 

You should not change the web server numbers, because that will either give you higher utilization if you increase it, or allow fewer users on at a time if you decrease it.

 

If you upgrade to the M3, in the release notes for 6.x code, there are upgrade instructions that mention how to upgrade.  Ideally you would work together with support to get a game plan together to ensure that you do it safely.

 

A gotcha with upgrading is that if you upgrade the sup-2 to 5.x, you can only terminate 128 access points instead of 256, so you need to plan your upgrade carefully.

 

The M3s use a different licensing scheme than the Sup-2, so those licenses cannot be leveraged.  It is best that you speak to your Aruba Sales team so that you get a full set of options on how to do this.

 

In the meantime, you can try to actively move users to other methods of authentication like 802.1x or PSK to keep the load off of the internal web server.

 



Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

New Contributor
Posts: 4
Registered: ‎07-16-2013

Re: Aruba6000, Version 3.4.5.1, Switched form 1024 to 2048 bit cert, High CPU Usage, Captive Portal

It is a bug, but the workaround is to use 1024 bit certificates.  The sup-2 simply cannot support the same number of sessions without higher utilization.  This cannot be fixed.

 

- 1024 bit certs are going away globally on the internet.  We have to switch to 2048.  If we don't use any certs at all on our captive portal page, so browsers will simply deny access to the page.

 

A gotcha with upgrading is that if you upgrade the sup-2 to 5.x, you can only terminate 128 access points instead of 256, so you need to plan your upgrade carefully.

 

- 5.x is out then because we currently have more than 128 APs on each controller, plus we have licenses for 256 APs on each sup-2 controller and wouldn't want to lose capacity.

 

The M3s use a different licensing scheme than the Sup-2, so those licenses cannot be leveraged.  It is best that you speak to your Aruba Sales team so that you get a full set of options on how to do this.

 

- So it is possible to change my slave sup-2 to an M3, and then get 512 AP licenses for it?  And I would still be able to use my sup-2 as a master with no APs running on it?  I would just have them show up on the master sup-2 in the 'default' group, then move then over to the slave M3 after I iniitally program them.  The only problem then that I see is that I don't think you can run 6.x on the master (sup-2) and 6.x on the slave (M3).

 

In the meantime, you can try to actively move users to other methods of authentication like 802.1x or PSK to keep the load off of the internal web server.

 

- Everything here is designed around our captive portal page.  Is it possible to serve this page externally to reduce the load on the CPU?  We really need to figure out a good solution for this.

Search Airheads
Showing results for 
Search instead for 
Did you mean: