Header Only - DO NOT REMOVE - Extreme Networks
Question

SNMP Extreme Stack Member Table Missing Data


I have a couple Stacked Summit X250/X450 and I'm having trouble using the extremeStackMemberTable SNMP table. The OS version of these are 16.1.2.14. I am seeing the extremeStackMemberEntPhysicalIndex column returning as zero for all stack members of these stacks. This causes the various tools I use to not be able to link into the entPhysicalTable to gather serial numbers and os versions.

Is this a known issue or expected behaviour? If not, is there another way of making these associations of stack members to their respective data?

Thanks.

11 replies

Userlevel 4
Hi Geoff,

Please correct me if i am wrong,

You are unable to get the active stack nodes details from NMS tool. which is giving output as zero instead of one.

if yes please let me know what is the NMS tool and is this issue with only these two stacks ?

was it working earlier ?

Thanks,
Suresh.B
Thanks for the reply. The issue is that if you snmpwalk on extremeStackMemberTable.extremeStackMemberEntPhysicalIndex against the stack it is returning zero as the entPhysicalIndex instead of the index of the corresponding row in entPhysicalTable. I haven't tried this in the past on these devices. On a different extreme stack I've used in the past this returned correctly.
Userlevel 4
Hi Geoff,

I could see you are using 16.1 MIB for this SNMP walk so please let me know the exact hardware which you are using.

what is the tool name.

Thanks,
Suresh.B
Userlevel 4
Hi Geoff,

Also share the OID number.

Thanks
Suresh.B
snmpwalk -v 2c -c * [i] 1.3.6.1.4.1.1916.1.33.2.1.5

Sysoid of affected devices: 1.3.6.1.4.1.1916.2.213
Userlevel 4
Hi Geoff,

X250/X450 switches only support through EXOS 15.3.X. Therefore the version could not be 16.1.2.14. Could the issue be that the incorrect MIB file is being used?
I could have the switch type wrong, the OS version is what SNMP is reporting.

I don't believe the MIB file is the issue. I can correctly get SNMP data from the OIDs around the one I am only getting zero from. For example, extremeStackMemberMACAddress (1.3.6.1.4.1.1916.1.33.2.1.6) I can get correct MAC Address information for the stack members. The extremeStackMemberEntPhysicalIndex (1.3.6.1.4.1.1916.1.33.2.1.5) OID is returning zero, when it should be returning something like 2 or 3, corresponding to the entPhysicalIndex in entPhysicalTable for the stack member module. This happens on two separate stacks using this same hardware and version.
Userlevel 7
Geoff Mather wrote:

I could have the switch type wrong, the OS version is what SNMP is reporting.

I don't believe the MIB file is the issue. I can correctly get SNMP data from the OIDs around the one I am only getting zero from. For example, extremeStackMemberMACAddress (1.3.6.1.4.1.1916.1.33.2.1.6) I can get correct MAC Address information for the stack members. The extremeStackMemberEntPhysicalIndex (1.3.6.1.4.1.1916.1.33.2.1.5) OID is returning zero, when it should be returning something like 2 or 3, corresponding to the entPhysicalIndex in entPhysicalTable for the stack member module. This happens on two separate stacks using this same hardware and version.

Hi Geoff, are you still having problems with this issue?
Geoff Mather wrote:

I could have the switch type wrong, the OS version is what SNMP is reporting.

I don't believe the MIB file is the issue. I can correctly get SNMP data from the OIDs around the one I am only getting zero from. For example, extremeStackMemberMACAddress (1.3.6.1.4.1.1916.1.33.2.1.6) I can get correct MAC Address information for the stack members. The extremeStackMemberEntPhysicalIndex (1.3.6.1.4.1.1916.1.33.2.1.5) OID is returning zero, when it should be returning something like 2 or 3, corresponding to the entPhysicalIndex in entPhysicalTable for the stack member module. This happens on two separate stacks using this same hardware and version.

This is still an issue affecting multiple devices today (1 year later) now running 16.1.3.6. We believe the issue was introduced in version 15.7.3.1 P1-6. Do you need more information in order to escalate it? The entPhysicalTable is useless when the extremeStackMemberEntPhysicalIndex reports the incorrect index.
Userlevel 7
Geoff Mather wrote:

I could have the switch type wrong, the OS version is what SNMP is reporting.

I don't believe the MIB file is the issue. I can correctly get SNMP data from the OIDs around the one I am only getting zero from. For example, extremeStackMemberMACAddress (1.3.6.1.4.1.1916.1.33.2.1.6) I can get correct MAC Address information for the stack members. The extremeStackMemberEntPhysicalIndex (1.3.6.1.4.1.1916.1.33.2.1.5) OID is returning zero, when it should be returning something like 2 or 3, corresponding to the entPhysicalIndex in entPhysicalTable for the stack member module. This happens on two separate stacks using this same hardware and version.

Hi Rob,
If you have more information, please open a ticket with GTAC so it can be fixed.
How to contact Extreme Networks Global Technical Assistance Center (GTAC)
Geoff Mather wrote:

I could have the switch type wrong, the OS version is what SNMP is reporting.

I don't believe the MIB file is the issue. I can correctly get SNMP data from the OIDs around the one I am only getting zero from. For example, extremeStackMemberMACAddress (1.3.6.1.4.1.1916.1.33.2.1.6) I can get correct MAC Address information for the stack members. The extremeStackMemberEntPhysicalIndex (1.3.6.1.4.1.1916.1.33.2.1.5) OID is returning zero, when it should be returning something like 2 or 3, corresponding to the entPhysicalIndex in entPhysicalTable for the stack member module. This happens on two separate stacks using this same hardware and version.

Thanks for the direction. Case 01305578 has been created.

Reply