Lenovo XCC SNMPv3: Agent Setup, MIB Loading, Traps and Polling Verification
This archived example uses an SR650, first-generation XCC and SnmpB. Addresses, user names and firmware-specific screens are examples. Polling and trap delivery are separate paths; use a security profile and network configuration that match the actual XCC and monitoring service.
1. Configure XCC
Log in and open Server Configuration → Server Properties. Fill in contact and location information. The source calls Contact and Building required fields; the official XCC documentation requires a configured contact and location before enabling the SNMPv3 agent. The picture uses qqq for both example fields and Lowest U 0:
Open BMC Configuration → Network. Enable SNMPv3 Agent and SNMPv3 Trap, then select the event classes to forward. The source checks Critical, Attention and System:
Confirm service enablement and ports. The pictured defaults are SNMP Agent 161 and SNMP Traps 162. Keep them unless the real deployment uses different ports, and match the monitoring service and network access rules:
Under Events → Alert Recipients, choose Create in the SNMPv3 User section:
Create or select an appropriate monitoring user rather than relying on the default management account. Address for traps is the monitoring receiver’s address. The blank form initially shows the default account and a missing-address error; the subsequent example uses JACKY and 10.119.176.57. Match authentication/privacy algorithms and secrets on both ends. This historical case displays None/None; those fields do not provide authentication or encryption, and retaining defaults is not proof of a protected profile:
The source recommends restarting XCC after setup. Plan for its brief management-connection interruption if needed; this is not a factory reset. Verify the saved recipient and settings after reconnecting:
2. Configure the monitoring side
The source uses the Windows build of SnmpB. Prefer the SnmpB project distribution to the source’s third-party download listing. No software installation is required merely to read these steps.
Obtain the MIB package matching the server/XCC from Lenovo Support, under the XCC firmware’s additional documentation/utility downloads. MIBs decode object identifiers and trap fields into meaningful names; raw numeric OIDs can still be queried without every vendor label loaded. Copy the applicable MIB files to SnmpB’s mibs directory. The screenshot is an older cdi322b-1.77 package example, not the version to use universally:
In the Modules tab, move the relevant files from Available MIB modules to Loaded MIB modules. Lenovo documents the dependency order SMI MIB → Product MIB → XCC MIB → XCC Alert MIB. These cover data structure, product identifiers, monitoring objects and alert traps:
Open Options → Manage SNMPv3 USM Profile and create a profile with the same security user and matching protocol/credential settings as XCC. The screenshot’s passwords are already masked; do not treat the visible masked dots as literal values:
On Discovery, enter the actual XCC address/range and choose Discover. The pictured range is 10.245.54.113 at both ends, which differs from the trap receiver 10.119.176.57. Discovering an agent does not by itself verify trap reception:
Open Traps to inspect notifications received from XCC. The source’s log lists SNMPv3 notifications from 10.245.54.113. An agent’s source port in this log is not necessarily the receiver’s configured trap-listening port:
3. Source SR650 event-validation case
The original controlled test used two drives in RAID1 while the OS was running. One drive was removed, reinserted and rebuilt. This reports that historical test; do not remove a required live member merely to reproduce an example. Use an approved test-event or maintenance procedure for the actual system.
The receiver logged a drive-removal notification for Drive1/bay1, then a RAID-volume-state transition to critical:
After reinsertion, the source logged Drive 1 has been added and then Rebuild in progress for Array in system ThinkSystem SR650. Rebuild in progress is not a completed rebuild:
Compare the trap messages with XCC Event Logs. The final table contains the corresponding removal, critical-state, addition and rebuild messages. This checks agreement for the pictured events; it does not prove every event class or future network path is working:
4. Linux polling and OIDs
The source also uses snmpwalk to poll XCC and displays the system MIB objects. Its terminal example has the user name JACKY and the XCC address followed by a dot, with output paged through more. No password or key is visible in that capture; existing redactions remain intact:
A walk retrieves a subtree using successive GETNEXT requests; it is not one SNMP GET that means “all data” merely because a dot follows the address. Specify the intended OID or subtree explicitly. For the source’s None/None security case only, the following placeholder example walks the standard system subtree:
snmpwalk -v3 -u SNMP_USER -l noAuthNoPriv XCC_IP 1.3.6.1.2.1.1Replace the user/address with the actual approved profile. An authenticated/encrypted deployment requires its matching security configuration; the example above does not configure that. To request one known scalar, use snmpget with that scalar’s full instance OID, such as sysName.0. Use the MIB browser to resolve the required object names: