HPE

Hewlett Packard Enterprise (HPE) SNMP objects are registered under two earlier corporate identities rather than a single number of its own. Enterprise number 11 ("Hewlett-Packard") is the original assignment, still used as the base for network-switch MIBs inherited from the ProCurve product line (HP-ICF-OID, HP-ENTITY-MIB, HP-SYSTEM-MIB). Enterprise number 232 ("Compaq") is the number actually used by server-management MIBs for ProLiant servers and iLO, inherited from HP's 2002 merger with Compaq (CPQHLTH-MIB, CPQIDA-MIB, CPQSM2-MIB, CPQSINFO-MIB). A third number, 58515, is registered to "HP Inc.", the separate company formed by HP's 2015 split that retained the PC and printer business; it is not used by HPE's enterprise products and should not be confused with 11 or 232.

This guide covers products still branded HPE directly: iLO and ProLiant server management, and OneView. HPE's networking switch line was transferred to Aruba Networks following HPE's acquisition of Aruba, and current Aruba-branded switches (ArubaOS-Switch, Aruba CX) use Aruba's own MIB tree (WLSX-SWITCH-MIB, WLSX-WLAN-MIB) rather than the HP-ICF or Compaq-derived MIBs described below.

SNMP configuration

iLO (Integrated Lights-Out), the baseboard management controller on HPE ProLiant servers, provides its own SNMP agent configuration through the iLO web interface or its REST/Redfish API. Enabling SNMP is a layered process rather than a single switch: the SNMP protocol itself, then SNMPv1 and SNMPv3 individually, and then trap or inform delivery, are each enabled through separate settings, reflected in the Redfish interface as distinct properties under ManagerNetworkProtocol. Which of these layers are enabled by default is not explicitly documented by HPE, so each should be checked rather than assumed. On earlier iLO generations, SNMP queries directed at the host are in some configurations passed through to an agent running on the server's own operating system rather than answered by iLO itself - the objects returned in that case come from the host OS's own CPQ* MIB implementation rather than an iLO-specific one.

SNMPv3

SNMPv3 is configured on recent iLO generations (iLO 5 and iLO 6) under the Management menu, in the SNMP Settings page's SNMP Alerts section. The underlying Redfish properties are a per-manager snmpv3/enabled flag and a per-user username, with a choice of MD5 or SHA for authentication and DES or AES for privacy. The exact wording of the corresponding web-interface fields is not confirmed here against HPE's primary iLO user guide, only against the underlying Redfish property names, so the on-screen labels may differ slightly from how they are described above.

Sending traps and OneView

OneView, HPE's infrastructure management appliance, does not expose its own SNMP agent for polling. It forwards events from the devices it manages - iLO, Onboard Administrator, and Virtual Connect - as SNMP traps to a configured receiver, set up through OneView's own alerting settings. OneView also provides a general REST API that can be queried for alerts and events, but no officially documented push-based webhook alerting mechanism exists as an alternative to SNMP trap relay; HPE support has directed customers asking about this to open a support case rather than pointing to a documented feature.

Platform differences

HPE's server-management architecture changed between generations. ProLiant Gen9 servers relied on agent-based, in-band monitoring: Insight Management Agents installed in the host operating system, communicating over SNMP, WMI, or WBEM. Gen10 (iLO 5) and Gen11 (iLO 6) servers shifted toward agentless, out-of-band monitoring through iLO itself, with Redfish/REST presented alongside SNMP rather than replacing it outright. HPE has not published an explicit statement deprecating SNMP in favor of Redfish, but newer documentation and tooling are built primarily around the Redfish interface.

Common OIDs and MIBs

Server hardware health is reported in CPQHLTH-MIB, under enterprises.232 (1.3.6.1.4.1.232). Memory status is reported in one of two tables depending on server generation: cpqHeResMemModuleTable (1.3.6.1.4.1.232.6.2.14.11) on older models, or cpqHeResMem2ModuleTable (1.3.6.1.4.1.232.6.2.14.13) on newer ones. Temperature sensor readings are reported in cpqHeTemperatureTable (1.3.6.1.4.1.232.6.2.6.8.1), and power supply status in the power supply table at 1.3.6.1.4.1.232.6.2.9.3.1.

Storage status is reported in CPQIDA-MIB: cpqDaLogDrvStatus (1.3.6.1.4.1.232.3.2.3.1.1.4) reports logical drive status, and cpqDaPhyDrvStatus (1.3.6.1.4.1.232.3.2.5.1.1.6) reports physical drive status, including predictive failure conditions.

Several further Insight Management Agent MIBs cover specific subsystems. CPQSINFO-MIB covers system-level inventory: cpqSiFruTable (field-replaceable units), cpqSiMemModuleTable (memory module and ECC status), and cpqSiFirmwareRevTable. CPQNIC-MIB covers network adapters, including cpqNicIfPhysAdapterTable (per-physical-adapter role, duplex, speed, and error counters) and cpqNicIfLogMapTable (teamed or LACP logical adapters). CPQSM2-MIB, despite its name, covers the management-processor interface - the iLO's own management NIC and event log (cpqSm2NicConfigTable, cpqSm2EventLogTable) - rather than storage, which is covered instead by CPQSCSI-MIB: cpqScsiCntlrTable (controller model, firmware, and status), cpqScsiLogDrvTable (logical drive RAID level and rebuild state), and cpqScsiPhyDrvTable (physical drive health and predictive-failure indicators).

Gotchas

Which memory table a given server populates - cpqHeResMemModuleTable or cpqHeResMem2ModuleTable - depends on the server generation, and a monitoring template written for one does not reliably return data from the other. OneView does not provide a health MIB of its own; monitoring through SNMP means polling the underlying iLO or Virtual Connect devices directly, with OneView used only to receive and relay their trap output. Because HP/HPE/Compaq/HP Inc. SNMP objects are split across three enterprise numbers with overlapping naming, confirming which of 11, 232, or 58515 an OID found online actually belongs to is necessary before assuming it applies to a given device.

SNMP object placement for sensor data is not guaranteed to stay fixed across an iLO firmware update: a documented case on a DL385 Gen11 server showed a combined iLO and NIC firmware update changing how fan information was exposed over SNMP, breaking a previously working OID. CPQSM2-MIB's name is itself a common source of confusion - despite "SM" suggesting storage, it covers the management-processor interface, not disk or array data, which lives in CPQSCSI-MIB instead.