Symptom

The MIB fru-ctrl it dosent find on the default mib for version 24.3.x on HW 8201-32FH=: the customer mention that in previous versions they did not have to add the ?snmp-server trap fru-ctrl? configuration and it worked. The numeric OIDs only worked with version 7.10.2 without the 'snmp-server traps fru-ctrl' configuration. In the case of versions 24.x.x, the client indicates that initially they do not run with the SNMP walk using the OID name, nor when running the command with the numeric OID. However, once the 'snmp-server traps fru-ctrl' is configured, the SNMP walk runs correctly with both the OID name and numeric OID. After that, the client removed the 'snmp-server traps fru-ctrl' command and ran both SNMP walks again, and they ran correctly. I suppose this is because, as mentioned, once this command is configured, the OIDs are dynamically loaded. What the client expects is for the SNMP walk to run without the need for adding extra configuration, as it worked previously. That is the reason why the SMU request was opened. Behaviour change is seen when SNMP traps config are not present, snmp walk on FRU CTRL does not work as exepcted.

Conditions

This MIB dosent exist on the default MIBs for version 24.3.x: $ snmpwalk -v 2c -c xxx swilab8201 cefcFRUPowerAdminStatus CISCO-ENTITY-FRU-CONTROL-MIB::cefcFRUPowerAdminStatus = No Such Instance currently exists at this OID $ snmpwalk -v 2c -c xxx swilab8201 cefcFRUPowerOperStatus CISCO-ENTITY-FRU-CONTROL-MIB::cefcFRUPowerOperStatus = No Such Instance currently exists at this OID $ snmpwalk -v 2c -c xxx swilab8201 cefcFanTrayOperStatus CISCO-ENTITY-FRU-CONTROL-MIB::cefcFanTrayOperStatus = No Such Instance currently exists at this OID This behavior is seen on router boot up with minimal snmp configuration present on device.

Workaround

Enable Fru Ctrl MIB Traps on the router. Configure the following: snmp-server traps fru-ctrl

Further Problem Description