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.