02-22-2012 08:22 AM
We recently migrated to Amigopod for our guest captive portal solution and noticed we were experiencing a lot of issues with Andriod devices and sometimes Firefox on laptops. One obvious thing we see is that the Aruba controller that guests connect to, and is used for redirection over to Amigopod, is frequently pegged at 100% CPU, 90% of which is in the "user" part of show cpuload. Also, when the CPU get's that high, we can't even SSH to the controller.
show cpuload current shows the high CPU utilization is attributed to the httpd daemon, and the controller can spawn quite a lot of httpd processes as well.
These are 2400 controllers running 18.104.22.168 and were previously used (for about four yesra) as our guest solution using the Aruba captive portal without issue.
We have cases open with both Aruba and Amigopod, but wanted to see if anyone else has seen this or has any ideas.
02-22-2012 08:57 AM
Were you doing HTTPS on the controller for CP before you moved it to Amigopod?
Do a show web-server on the controller and post the results.
02-22-2012 10:01 AM
Yeah, we were doing HTTPs with the old solution as well.
Web Server Configuration
Cipher Suite Strength high
SSL/TLS Protocol Config sslv3 tlsv1
Switch Certificate GW_PORTAL
Captive Portal Certificate GW_PORTAL
Management user's WebUI access method username/password
User session timeout <30-3600> (seconds) 900
Maximum supported concurrent clients <25-400> 25
02-23-2012 10:18 AM - edited 02-23-2012 10:18 AM
Just in case anyone finds this post in the future, a kernal change was made on our Amigopod server. We were source PATing our guest IP addresses so they wouldn't be seen in the inside of the network. That in itself caused some issues that caused the need for the tweak in Amigopod.
We still don't know why the controller's CPU utilization is so high aside from the fact that it's the httpd processes that is causing it.
02-23-2012 10:44 AM - edited 02-23-2012 10:48 AM
# Disable TCP timestamps
net.ipv4.tcp_timestamps = 0