topic RE: SNMP Extreme Stack Member Table Missing Data in ExtremeSwitching (Other)

SNMP Extreme Stack Member Table Missing Data

Geoff_Mather — Thu, 18 Feb 2016 09:20:00 GMT

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.

RE: SNMP Extreme Stack Member Table Missing Data

Bharathiraja__S — Thu, 18 Feb 2016 11:35:00 GMT

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

RE: SNMP Extreme Stack Member Table Missing Data

Geoff_Mather — Thu, 18 Feb 2016 11:43:00 GMT

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.

RE: SNMP Extreme Stack Member Table Missing Data

Bharathiraja__S — Thu, 18 Feb 2016 12:05:00 GMT

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

RE: SNMP Extreme Stack Member Table Missing Data

Bharathiraja__S — Thu, 18 Feb 2016 12:13:00 GMT

Hi Geoff,

Also share the OID number.

Thanks
Suresh.B

RE: SNMP Extreme Stack Member Table Missing Data

Geoff_Mather — Thu, 18 Feb 2016 18:37:00 GMT

snmpwalk -v 2c -c * 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

RE: SNMP Extreme Stack Member Table Missing Data

Dorian_Perry — Fri, 19 Feb 2016 03:16:00 GMT

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?

RE: SNMP Extreme Stack Member Table Missing Data

Geoff_Mather — Fri, 19 Feb 2016 03:40:00 GMT

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.

RE: SNMP Extreme Stack Member Table Missing Data

Drew_C — Fri, 19 Feb 2016 03:40:00 GMT

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

RE: SNMP Extreme Stack Member Table Missing Data

Rob_Bredin — Fri, 19 Feb 2016 03:40:00 GMT

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.

RE: SNMP Extreme Stack Member Table Missing Data

Drew_C — Fri, 19 Feb 2016 03:40:00 GMT

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)

RE: SNMP Extreme Stack Member Table Missing Data

Rob_Bredin — Fri, 19 Feb 2016 03:40:00 GMT

Thanks for the direction. Case 01305578 has been created.