Inspur M5: Configure and Test SNMP Traps and Queries
This English edition follows the archived Inspur/IEI M5 SNMP configuration article. It separates BMC-generated traps from manager-initiated queries and keeps the OEM command templates tied to the illustrated firmware. Use the supported procedure and MIB files for the actual M5 model/BMC version; these raw command numbers are not a cross-vendor interface.
Community strings, authentication/privacy passwords, IPMI login values and their encoded bytes are omitted. Angle-bracketed command parameters are placeholders, not executable values. The new figures are English instructional reconstructions; peripheral layout and file-picker metadata are schematic rather than verified device or package properties. Credential-bearing original screenshots were not used as image-generation inputs. Example addresses describe the archived topology rather than a required network plan.
1. SNMP roles and connectivity
SNMP provides management requests and notifications. For the conventional UDP configuration in this guide, the BMC agent receives queries on port 161, while the monitoring receiver listens for traps on port 162. A GET retrieves an object; a SET requests a supported writable-object change. A trap is sent by the BMC and is not a response to an ordinary polling GET.
The source covers SNMPv1, v2c and v3, with examples for v2c/v3. Match the actual version, access permissions and credentials at both ends. V3 authentication/privacy settings and v2c community matching are distinct configuration models. The source’s web trap example uses MD5/DES, its raw trap example uses MD5/AES, and its GET/SET example uses SHA/AES; do not silently mix those profiles.
Check the intended BMC/receiver route and permitted UDP traffic. The archived troubleshooting recipe uses a direct laptop connection and disables its firewall. Use the approved test network and targeted firewall rules for the necessary traffic instead of treating whole-firewall disablement as a prerequisite.
2. Configure SNMP traps
BMC web interface
Open BMC Settings → SNMP Alert Management. For v3, configure the authorized user and matching authentication/privacy algorithms and secret values locally, with receiver port 162 as required by the actual destination. The source web example shows MD5/DES; it does not establish which algorithms every firmware supports or which profile your site requires. Save the intended settings.
For v2c, configure the matching authorized community locally. Configure the alert policy and receiver destination independently. The source’s web policy example is enabled on the Dedicated management channel and targets 10.72.71.1. That destination differs from the raw-command example below; substitute the intended receiver consistently.
OEM ipmitool templates
Some BMC versions in the source enable only v3 by default. The following archived command enables the v2c trap path on supported firmware. Verify its applicability before changing the BMC.
ipmitool raw 0x3c 0x3a 0x00 0x01For the source’s v3 trap profile, the parameter sequence selects v3, sets its user, chooses MD5 and AES, then sets the authentication and privacy secrets. Supply the required byte encodings locally; no source secret bytes are reproduced.
ipmitool raw 0x3c 0x19 0x00 0x03
ipmitool raw 0x3c 0x19 0x02 <USER_BYTES>
ipmitool raw 0x3c 0x19 0x03 0x02
ipmitool raw 0x3c 0x19 0x04 0x02
ipmitool raw 0x3c 0x19 0x05 <AUTH_SECRET_BYTES>
ipmitool raw 0x3c 0x19 0x06 <PRIV_SECRET_BYTES>For v2c after enabling the applicable path, select its version and configure the authorized community bytes. The source uses selector 0x02 for a v3 username and 0x01 for the v2c community; they are not interchangeable fields.
ipmitool raw 0x3c 0x19 0x00 0x02
ipmitool raw 0x3c 0x19 0x01 <COMMUNITY_BYTES>The archived policy/destination commands below use policy ID 1, channel 1 (Dedicated) and destination ID 1. The final address bytes c0 a8 00 0b encode 192.168.0.11. This is an example address, not the web example’s 10.72.71.1. Resolve the intended channel, policy and destination before applying any change.
ipmitool raw 0x04 0x12 0x09 0x01 0x18 0x11 0x00
ipmitool raw 0x0c 0x01 0x01 0x12 0x01 0x00 0x03 0x03
ipmitool raw 0x0c 0x01 0x01 0x13 0x01 0x00 0x00 0xc0 0xa8 0x00 0x0b 0x00 0x00 0x00 0x00 0x00 0x003. Verify trap configuration and reception
Read configuration
The source reads the configured trap profile using the OEM command below. Its example version byte 02 indicates v2c. The response may include community/user data; inspect it locally and redact it from shared output rather than copying the full dump.
ipmitool raw 0x3c 0x1a
iReasoning MIB Browser
Use the appropriate iReasoning distribution and a matching vendor alert MIB. In the archived desktop interface choose File → Load MIBs. The source shows both Alert_v2.4_20190802.mib and Alert_v2.4_20191031.mib examples; choose the package for the actual BMC rather than treating those dates as equivalent.
Open Tools → Trap Receiver, then its settings. Set the intended listening port, normally 162 here, and the required transport/profile. Starting a receiver and configuring its listener are separate from saving a polling agent profile. Button names and service/client behavior vary across MIB Browser releases; the current vendor guide describes a newer interface than these archived screenshots.
The source also opens Tools → Options → Agents and records a profile at 10.7.11.107:162. That archived profile is shown for comparison; it does not start the trap listener. For GET/SET polling later in this guide, use the BMC agent’s actual port, normally 161. Enter the authorized community locally and match the chosen version.
Start the intended receiver as required by its version, then issue the BMC web policy’s Test action. Check the real receiver for a matching trap source, notification OID and test time. The BMC acknowledgment that an alert was sent alone does not prove end-to-end reception. The source shows destination 10.72.71.1 and a trap sent from BMC 10.7.11.107; receiver source and destination are different roles.
4. Configure GET/SET access
BMC web interface
Open BMC Settings → SNMP Settings. The source v3 query profile uses SHA authentication, AES privacy and port 161. Configure the authorized user and both secrets locally, then save. For v2c configure the intended community/access settings locally. A readable object does not imply the same object is writable.
OEM ipmitool templates
For the archived v3 GET/SET profile, the source writes the user, selects authentication code 01 (SHA in this example), supplies its secret bytes, selects privacy code 02 (AES), supplies its secret bytes, writes access-control value 01 and applies the configuration. Treat the access-control byte as an OEM value to verify for the actual firmware; the source does not establish a universal permission mapping.
ipmitool raw 0x3c 0x64 0x00 <USER_BYTES>
ipmitool raw 0x3c 0x64 0x01 0x01
ipmitool raw 0x3c 0x64 0x02 <AUTH_SECRET_BYTES>
ipmitool raw 0x3c 0x64 0x03 0x02
ipmitool raw 0x3c 0x64 0x04 <PRIV_SECRET_BYTES>
ipmitool raw 0x3c 0x64 0x05 0x01
ipmitool raw 0x3c 0x64 0xffThe v2c community template uses selector 06, followed by the apply command. The source also gives a selector-06 readback; that can expose the community and is omitted from the published verification transcript. Verify matching values locally without exporting them.
ipmitool raw 0x3c 0x64 0x06 <COMMUNITY_BYTES>
ipmitool raw 0x3c 0x64 0xff5. Verify queries
Configuration-query interpretation
The source queries the configured username with selector 00 and the authentication/privacy modes with selectors 01/03. Read username results locally. Its shown non-secret mode responses are 01 and 02. Attempts to read secret fields returned completion code 0xc9, Parameter out of range, in the archived transcript; do not treat an unreadable secret as proof that the whole configuration is invalid. A configuration readback is also distinct from a successful network SNMP request.
ipmitool raw 0x3c 0x65 0x01
ipmitool raw 0x3c 0x65 0x03
MIB Browser v2c test
Load the matching GET/SET MIB. The archived filename is SNMP_GetSet_Purley_v1.6_20200427.mib. Open Tools → Options → Agents, add the intended BMC address, agent port 161, v2c version and authorized community locally, then review Advanced settings. These profiles use 10.7.11.45 as the example BMC address, separate from the earlier trap case.
Select a suitable MIB node/OID and choose Walk to inspect the accessible subtree. Check actual results, types and permissions; an example screen cannot establish complete device inventory or unrestricted access. A walk does not perform SET operations, and does not verify write permission.
Net-SNMP command-line test
The following retain the source command structure with placeholders for the authorized community and BMC address. The literal template must be completed locally; shared command history or output must not contain credentials. Use the intended client credential configuration for actual execution.
snmpwalk -v 2c -c <COMMUNITY> <BMC_ADDRESS>
snmpwalk -v 2c -c <COMMUNITY> <BMC_ADDRESS> <OID>The source describes the no-OID form as obtaining all information. Net-SNMP documents a narrower behavior: the default walk starts at mib-2, so it does not automatically include every private enterprise subtree. Supply the intended subtree explicitly for vendor objects. A walk rooted at a scalar instance can also return little or no output; use snmpget for a single scalar value instead of assuming the walk is an exact single-object GET.
Sources and version scope
- Original manufacturer M5 article (Chinese; credential values omitted here)
- iReasoning official current MIB Browser guide (newer interface than the archived screens)
- iReasoning agent/receiver troubleshooting
- Net-SNMP snmpwalk: subtree, default mib-2 and scalar behavior
- Net-SNMP common command options
No matching complete English M5 BMC screenshot set was established from the original source. The English tool references clarify behavior without replacing the OEM-specific raw-command contract or claiming that a newer tool screenshot is the same firmware session.