HP iLO Port Probe

[jpd713]

Most of the physical servers in our environment are equipped with various generations of an HP iLO for remote Lights-Out type management (essentially, a separate network port for remote management). While a great tool for our server admins, these iLOs have been causing a number of problems with the proper discovery of the actual server the iLO is sitting in. These problems vary depending on the specific configuration of the iLO, the server itself, and the discovery method, but all seem to be related to the fact that iLO acts as a pass-through for SNMP — any SNMP queries sent to the iLO's IP are forwarded to the server which then respond with its data. In other words, we get back identical SNMP data when querying a given server's primary network port and its iLO port.

I'm trying to get discovery to recognize that a given IP is an iLO and then stop any further discovery on that IP. Of course, it would be nice to update the server CI with its iLO's IP address or to create separate iLO CIs with a Relationship to the server, but first thing's first. Seemingly common to all the various versions/configurations of iLOs on our network is the presence of TCP port 17988, the iLO Virtual Media port. Since this doesn't exist in the OOB system, I added an IP Service and Port Probe and a Behavior that would use it.

It seems to work in that Shazzam is indeed checking the port and reporting back that it's "open". My problem now is, given an open TCP 17988, getting discovery to stop any further discovery activities for that IP. I've tried a number of different port probe configurations, but discovery always falls back to using SNMP — sends an SNMP Classify probe, runs the results through the SNMP classifiers, and then takes the actions directed in the matched classifier — exactly what I'm trying to stop.

Does anyone have any ideas or see anything I'm doing wrong?

[haldroid]

ILO discovery would be a win for us as well, mainly because ILO IP addresses are maintained manually at this time.

[jonprivatt]

We've got the the same problem. HP ILOs all over the place.

Back when I wrote my own discovery (largely via SNMP), I remember finding some pretty interesting settings on the HP MIB, including some that indicate the relationship between the Server/ILO (which I stored). I have always thought it would be nice to catch that information; I don't know how much value it has since the server team are uses Insight Manager which already knows that information, but it might help non-server personnel from getting confused... these things get classified as servers, which is DEAD WRONG!

From discovery perspective (SNMP), these things are very confusing. They show up looking very much like the server they're attached to, though they have no real life of their own.

One of my coworkers got sick of the ILO ports screwing up server reports/counts. Since most of them have been set up with"ILO-" in the prefix, so he gathered them up and chucked them into their own classification. Not elegant, but it works for the ones with with DNS names.

We've had a lot of problems with SNMP misclassifying servers and had to disable finding servers via SNMP completely to resolve the issue. Since ILO's show up as a server, without SNMP, I'm not sure how I would approach this now. Hmmm. I just checked. Since we disabled SNMP server discovery classifiers, I guess we don't even FIND these things anymore. Great, more "Active, couldn't classify" that I don't need.

We really need a proper solution.

[jpd713]

Hal/Jon, thanks for the vote of confidence on the ILO issues.

For reference, here was my solution for "interrupting" the discovery process on SNMP pass-through enabled HP ILOs in my environment. I'm using CPQSM2-MIB::cpqSm2CntlrAgentLocation to distinguish between an ILO and its server.

--Added SNMP MIBs CPQHOST-MIB and CPQSM2-MIB. Note that Berlin fixes PRB572222 which sounds like it may allow the use of numeric OIDs instead.
--Added walk to CPQSM2-MIB::cpqSm2CntlrAgentLocation (1.3.6.1.4.1.232.9.2.2.10) to SNMP Classify probe.
--Updated classify sensor to check the new OID and set an "ilo" SNMP capability (just like the routing/hosting/printing SNMP capabilities) true when the result is 2, 3, or 4.
--Added a dummy (ie, empty) classifier to run before the computer classifiers that checks my new ilo capability and just logs to the Discovery Log. Unlike most other classifiers, this one does not create CIs and does not trigger further probes.

To be clear, this doesn't "do" anything - no CIs or Relationships are updated. My goal was simply to prevent the discovery of an ILO from corrupting my server CIs.

[StephenHey]

If you don't want to Discover ILOs at all AND the SSH port is open AND the SNMP port is closed, you can add this function to the script in the SSH port probe and it will interrupt ILO discovery:

function(cidata, result, scanner, status, midServer, sensor) {
  
   var bannertext = scanner.contents.banner_text.toString();
  
   if (bannertext.indexOf("SSH-2.0-RomSShell") != -1) {
 
  sensor.suppressProbe();
  return;
 
   }
  
}

[dedeepyatirugu]

Hi,

We have a similar requirement. Unable to detect iLO ports through discovery process. Could you please post the solution here if it worked for you.

Thanks In advance.