This is probably an OT question for this list, but I thought someone here may have encountered this.
I've been having a really annoying super slow web interface access to ILO 2 on our DL360 G5s and G6s, since day one, on all of them. SSH to ILO is perfectly fine. IPMI is fine. VSP is fine. Everything to do with ILO is fine except the damn web interface, which is slow to load pages intermittently. It kind of works in bursts for a few seconds when it works, so I try to do things quickly. It's hard to characterize exactly what's happening beyond my vague description, but I've looked at the dev tools in Chrome, tried FF, etc. with no luck.
One thing I haven't tried in a while is a packet capture of an ILO port to see if it's doing something weird, like trying to do rDNS on the client's IP or on itself, etc.
If it helps, our config doesn't use DHCP and otherwise all the boxes are reset to defaults, then have their IP/SM/GW configured and local users configured...nothing fancy. We do use our own SSL certs, but the problem happens without them as well, so I've already ruled that out.
Does anyone have any ideas on what obvious thing I could have missed?
I've dealt with moody ILO's in the past. Presuming (1) they're all on
the latest firmware (2) there isn't anything fishy/tell-tale in the logs
and (3) that you aren't afraid of a CLI, my advice would be to look into
using python-hpilo, which provides a command line interface to the ILO
API for A-Z management tasks:
Options:
-l LOGIN, --login=LOGIN
Username to access the iLO
-p PASSWORD, --password=PASSWORD
Password to access the iLO
-i, --interactive Prompt for username and/or password if they are not
specified.
-c FILE, --config=FILE
File containing authentication and config details
-t TIMEOUT, --timeout=TIMEOUT
Timeout for iLO connections
-j, --json Output a json document instead of a python dict
-P PROTOCOL, --protocol=PROTOCOL
Use the specified protocol instead of autodetecting
-d, --debug Output debug information, repeat to see all XML data
-o PORT, --port=PORT SSL port to connect to
--untested Allow untested methods
-h, --help show this help message or help for a method
-H, --help-methods show all supported methods
I have had a similar experience a while back with some old Dell cards
(DRAC). Usually I ended up logging in to the console and rebooting the
remote access controller which seemed to fix it for a while. I am not
sure how the HP ILO stuff works, have you tried giving the ILO
controller itself a reboot?
I've had issues with HP, Dell, and Super micro in any higher amounts of
broadcast traffic, especially ARP requests. The iDRAC 5 and 6 behave very
badly in high broadcast environments, failing to respond to http and local
ipmi (ipmitool via the smbus or whatever) interface. That's probably where
I would start personally...anything over a couple hundred hosts in the same
broadcast domain, especially if those are windows or osx hosts that love to
jibber about CIFS and mDNS.