Wireless Access

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!

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.

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?

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

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.

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.