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?

[Marcus Fly]

Are your ILO IP address's on a seperate subnet or do they share the same subnet as your servers? If seperate you could exclude that subnet from discovery.

Another solution could be to write a custom probe and sensor that identifies LOM (lights-out management) devices (HP ILO and Dell DRAC, IBM RSA, etc..) and stores them in a LOM table and relates to the server with the LOM information such as versions of the ILO software to keep track of.

Last option would be from your insight manager set the enable SNMP pass-thru to "no".

[doug_schulze]

Ive done two things to accommodate for these management ..

1. Disable the Computer based SNMP classifiers, this way we can't match it to any criteria and won't go any further with discovery

and/or

2. Create a unique SNMP classifier for the card. You can only accomplish this if there is unique 'ci_data' value (found at the bottom of the classifier input record). All that I have come across have a name that identifies the 'management device' such as ilocomputername. So in my classifier when cidata.name starts with ilo I create a ilo card in a table. You can then trigger additional probe/sensors to then relate that card to the system it manages in exploration.

Process on how to set up a snmp classifier can be found at

http://community.service-now.com/blog/dougschulze/build-simple-snmp-classifier

[jpd713]

Marcus/Doug, thanks for your responses.

Unfortunately, our ILOs are not necessarily on their own separate, identifiable subnets — those in our larger datacenters usually are, but not at many of our smaller sites. We don't want to disable SNMP on the ILOs because our monitoring group uses these features. And we definitely don't want to turn off the computer-based SNMP Classifiers — SNMP isn't exactly our preferred server discovery method, but it's used more often than I'd like to admit.

Regarding adding an SNMP Classifier leveraging the CIData, I've looked in to that, but the only CIData I have to work with — at least at this point, before it's been classified (or should I say misclassified, as a Winserver :P) — is an IP, and I can't classify by just an IP address. Most of our newer ILOs are registered in DNS and/or WINS, so these will also have a CIData.name available, but even then, the naming doesn't always follow a consistent convention.

Given this, any more suggestions? Nobody mentioned my ILO Port Probe; do you think that's the wrong way to go? That TCP 17988 was the only constant I could find on the cards.

[doug_schulze]

port Probe.. No because it will still need to trigger the SNMP classifier probe which would still catch the windows (if you haven't disabled it.) Can you attach a copy (or emai)l me the xml input from your classifier?