Preview Tool

Cisco Bug: CSCus53650 - N3500 missing index in entPhysicalTable when doing snmpwalk/ snmpgetnext

Last Modified

Mar 01, 2017

Products (2)

  • Cisco Nexus 3000 Series Switches
  • Cisco Nexus 3548 Switch

Known Affected Releases

6.0(2)A3(2.55) 6.0(2)A4(3)

Description (partial)

The entPhysicalTable is skipping the index value for the 'Module-1 processor-1' when doing a snmpwalk or snmpgetnext. 

[ffaraux.INF@UHPLab-nms1 ~]$ snmpwalk -v 2c -c <community> <IP_address>
SNMPv2-SMI::mib- = STRING: "PowerSupply-1 Fan-1"
SNMPv2-SMI::mib- = STRING: "PowerSupply-2 Fan-1"
SNMPv2-SMI::mib- = STRING: "FixedModule-1 Port-1"
SNMPv2-SMI::mib- = STRING: "FixedModule-1 Port-2"

In the output above note how it goes from index 540 to 4950. 

With getnext the same thing happens: 

[ffaraux.INF@UHPLab-nms1 ~]$ snmpgetnext -v 2c -c <community> <IP_address>
SNMPv2-SMI::mib- = STRING: "PowerSupply-2 Fan-1"

[ffaraux.INF@UHPLab-nms1 ~]$ snmpgetnext -v 2c -c <community> <IP_address>
SNMPv2-SMI::mib- = STRING: "FixedModule-1 Port-1"

Index 598 is skipped and this represents the 'Module-1 processor-1', the only way to get that index is with a snmpget. 

[ffaraux.INF@UHPLab-nms1 ~]$ snmpget -v 2c -c <community> <IP_address>
SNMPv2-SMI::mib- = STRING: "Module-1 processor-1"

This is a problem because most nms tools use snmpwalk of getnext operations when discovering the devices using SNMP. So the tools won't discover the ' Module-1 processor-1' instance.

N3500 running 6.0(2)A3(2) , latest version is also affected 6.0(2)A4(3). This also affects the N3048 platform.
Bug details contain sensitive information and therefore require a account to be viewed.

Bug Details Include

  • Full Description (including symptoms, conditions and workarounds)
  • Status
  • Severity
  • Known Fixed Releases
  • Related Community Discussions
  • Number of Related Support Cases
Bug information is viewable for customers and partners who have a service contract. Registered users can view up to 200 bugs per month without a service contract.