Broken or missing SNMP MIBS for firmware 10.0.0.31 (GSM7352Sv2)

Question

I have upgraded a GSM7352Sv2 to 10.0.0.31 firmware, but unfortunately the results to SNMP queries are different to 8.0.3.34.The support pages have no MIB files specifically for 10.0.0.x to download, only MIBs for version 8.0.3.25Now, I'm not sure if this is a case of the MIBs intentionally changing (but Netgear not yet providing the MIBs to go with the new 10.0.0.x firmware), or the SNMP implementation in 10.0.0.31 being broken.I am specifically looking at the boxServices part of the MIB, for checking PSU and fan status, and temperature.FAN STATUS { boxServicesGroup 6 }On 8.0.3 firmware:
# snmpwalk x.x.x.x 1.3.6.1.4.1.4526.10.43.1.6SNMPv2-SMI::enterprises.4526.10.43.1.6.1.1.0 = INTEGER: 0  &lt;&lt; indexSNMPv2-SMI::enterprises.4526.10.43.1.6.1.1.1 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.6.1.1.2 = INTEGER: 2SNMPv2-SMI::enterprises.4526.10.43.1.6.1.2.0 = INTEGER: 1  &lt;&lt; 1=fixedSNMPv2-SMI::enterprises.4526.10.43.1.6.1.2.1 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.6.1.2.2 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.6.1.3.0 = INTEGER: 1  &lt;&lt; 1=operationalSNMPv2-SMI::enterprises.4526.10.43.1.6.1.3.1 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.6.1.3.2 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.6.1.4.0 = INTEGER: 2800  &lt;&lt; RPMSNMPv2-SMI::enterprises.4526.10.43.1.6.1.4.1 = INTEGER: 0SNMPv2-SMI::enterprises.4526.10.43.1.6.1.4.2 = INTEGER: 2400SNMPv2-SMI::enterprises.4526.10.43.1.6.1.5.0 = INTEGER: 0  &lt;&lt; duty%SNMPv2-SMI::enterprises.4526.10.43.1.6.1.5.1 = INTEGER: 0SNMPv2-SMI::enterprises.4526.10.43.1.6.1.5.2 = INTEGER: 0
This is fine, and I have annotated the values according to the MIB.Here is what I see from the same switch running 10.0.0.31:
# snmpwalk x.x.x.x 1.3.6.1.4.1.4526.10.43.1.6SNMPv2-SMI::enterprises.4526.10.43.1.6.1.1.0 = INTEGER: 0SNMPv2-SMI::enterprises.4526.10.43.1.6.1.1.1 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.6.1.1.2 = INTEGER: 2SNMPv2-SMI::enterprises.4526.10.43.1.6.1.2.0 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.6.1.2.1 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.6.1.2.2 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.6.1.3.0 = INTEGER: 2  &lt;&lt; 2=failed!!SNMPv2-SMI::enterprises.4526.10.43.1.6.1.3.1 = INTEGER: 2SNMPv2-SMI::enterprises.4526.10.43.1.6.1.3.2 = INTEGER: 2SNMPv2-SMI::enterprises.4526.10.43.1.6.1.4.0 = STRING: "2800"SNMPv2-SMI::enterprises.4526.10.43.1.6.1.4.1 = STRING: "Not Supported"SNMPv2-SMI::enterprises.4526.10.43.1.6.1.4.2 = STRING: "2400"SNMPv2-SMI::enterprises.4526.10.43.1.6.1.5.0 = STRING: "Not Supported"SNMPv2-SMI::enterprises.4526.10.43.1.6.1.5.1 = STRING: "Not Supported"SNMPv2-SMI::enterprises.4526.10.43.1.6.1.5.2 = STRING: "Not Supported"
And yet the fans have definitely not failed ("show environment" says they are fine)POWER { boxServicesGroup 7 }8.0.3:
# snmpwalk x.x.x.x 1.3.6.1.4.1.4526.10.43.1.7SNMPv2-SMI::enterprises.4526.10.43.1.7.1.1.0 = INTEGER: 0  &lt;&lt; indexSNMPv2-SMI::enterprises.4526.10.43.1.7.1.1.1 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.7.1.2.0 = INTEGER: 1  &lt;&lt; fixedSNMPv2-SMI::enterprises.4526.10.43.1.7.1.2.1 = INTEGER: 2  &lt;&lt; removableSNMPv2-SMI::enterprises.4526.10.43.1.7.1.3.0 = INTEGER: 1  &lt;&lt; operationalSNMPv2-SMI::enterprises.4526.10.43.1.7.1.3.1 = INTEGER: 5  &lt;&lt; notpresent
Same switch on 10.0.0:
# snmpwalk x.x.x.x 1.3.6.1.4.1.4526.10.43.1.7SNMPv2-SMI::enterprises.4526.10.43.1.7.1.1.0 = INTEGER: 0SNMPv2-SMI::enterprises.4526.10.43.1.7.1.1.1 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.7.1.2.0 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.7.1.2.1 = INTEGER: 2SNMPv2-SMI::enterprises.4526.10.43.1.7.1.3.0 = INTEGER: 2  &lt;&lt; failed!SNMPv2-SMI::enterprises.4526.10.43.1.7.1.3.1 = INTEGER: 1  &lt;&lt; operational!
Even worse: on another switch running 10.0.0.31, which *does* have an RPS connected and working, I get:
SNMPv2-SMI::enterprises.4526.10.43.1.7.1.1.0 = INTEGER: 0SNMPv2-SMI::enterprises.4526.10.43.1.7.1.1.1 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.7.1.2.0 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.7.1.2.1 = INTEGER: 2SNMPv2-SMI::enterprises.4526.10.43.1.7.1.3.0 = INTEGER: 2  &lt;&lt; failed!SNMPv2-SMI::enterprises.4526.10.43.1.7.1.3.1 = INTEGER: 5  &lt;&lt; notpresent!
However the PSUs are both fine.TEMPERATURE { boxServicesGroup 8 }8.0.3:
SNMPv2-SMI::enterprises.4526.10.43.1.8.1.1.0 = INTEGER: 0  &lt;&lt; indexSNMPv2-SMI::enterprises.4526.10.43.1.8.1.1.1 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.8.1.1.2 = INTEGER: 2SNMPv2-SMI::enterprises.4526.10.43.1.8.1.1.3 = INTEGER: 3SNMPv2-SMI::enterprises.4526.10.43.1.8.1.2.0 = INTEGER: 1  &lt;&lt; fixedSNMPv2-SMI::enterprises.4526.10.43.1.8.1.2.1 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.8.1.2.2 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.8.1.2.3 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.8.1.3.0 = INTEGER: 1  &lt;&lt; normalSNMPv2-SMI::enterprises.4526.10.43.1.8.1.3.1 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.8.1.3.2 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.8.1.3.3 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.8.1.4.0 = INTEGER: 46  &lt;&lt; tempSNMPv2-SMI::enterprises.4526.10.43.1.8.1.4.1 = INTEGER: 37SNMPv2-SMI::enterprises.4526.10.43.1.8.1.4.2 = INTEGER: 56SNMPv2-SMI::enterprises.4526.10.43.1.8.1.4.3 = INTEGER: 52
10.0.0:
SNMPv2-SMI::enterprises.4526.10.43.1.8.1.1.1.0 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.8.1.1.1.1 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.8.1.1.1.2 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.8.1.1.1.3 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.8.1.2.1.0 = INTEGER: 0SNMPv2-SMI::enterprises.4526.10.43.1.8.1.2.1.1 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.8.1.2.1.2 = INTEGER: 2SNMPv2-SMI::enterprises.4526.10.43.1.8.1.2.1.3 = INTEGER: 3SNMPv2-SMI::enterprises.4526.10.43.1.8.1.3.1.0 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.8.1.3.1.1 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.8.1.3.1.2 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.8.1.3.1.3 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.8.1.4.1.0 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.8.1.4.1.1 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.8.1.4.1.2 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.8.1.4.1.3 = INTEGER: 1SNMPv2-SMI::enterprises.4526.10.43.1.8.1.5.1.0 = INTEGER: 44SNMPv2-SMI::enterprises.4526.10.43.1.8.1.5.1.1 = INTEGER: 37SNMPv2-SMI::enterprises.4526.10.43.1.8.1.5.1.2 = INTEGER: 55SNMPv2-SMI::enterprises.4526.10.43.1.8.1.5.1.3 = INTEGER: 52
It's pretty clear what the temperatures are, but they are at a completely different OID. The OIDs are one component longer, so I'm not sure this is even a valid SNMP table.sysObjectIDBoth versions of software return
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.4526.100.1.14
i.e. { stackswitch 14 }Obviously, it's the same model of switch. On the other hand, it's extremely confusing because the MIB is different; normally you would expect to see the same MIB whenever you see the same sysObjectID. It seems you have to determine the firmware revision first, and match certain firmware ID patterns to certain MIBs. And as I say, the MIB for 10.0.0.31 isn't even published.Hence my suspicion it's simply a bug, and 10.0.0 SNMP output no longer matches the MIB.Regards,brian.

jmizoguchi · Answer

You want to contact support via portal.  Forum is only user to user and not support.  my.netgear.comMake sure that you have factory default after flashing firmware and still the same contact support

candlerb · Answer

Thank you, I will do this in future.In this case we needed to get the switches into service quickly, so I have reverted to 8.0.3.34 firmware.In any case, I cannot see what extra functionality is available in 10.0.0.x which is not in 8.0.3.x - the release notes only give changes against earlier 10.0.0.x releases. Is there a document anywhere which describes the differences?Regards,Brian.

kofi · Answer

Such doc is not a strong point of Netgear ;-)

Anyhow, get the MIBs that are in the download section for the M5300s since that is the new line of switches.

I have a GSM7228PS which was (likely like yours) bought a couple of months before M5300 were released, nonetheless they got gifted by 10.x. I generally feel the syntax to be a little more consistent on some edges, I remember some differences in default assumptions for STP.

A handy new feature is the ability to read out some values of installed SFPs.
Another one is the support of private VLANs which can be quite handy to improve security and separation at VLAN level.

8.0.3.34 also has problems with DST updating which 9.x and 10.x don't have.

candlerb · Answer

Here's an update, as Netgear support have kindly provided me with new MIBs for 10.x firmware. To summarise:

* There are different MIBs for 10.x firmware versus 8.x firmware

* The MIBs are incompatible. They re-use the same OIDs but with different semantics :eek:. In the case of environmental sensors, both are called fastpath_boxservices.my and both sit at OID { ng7000managedswitch 43 }

* This means it's impossible to load 8.x and 10.x MIBs at the same time. Netgear assume that your network does not have a mixture of equipment.

However in our case, we have some GSM7224v2, for which there is 8.x firmware but not 10.x; and we have some M4100-50G for which there is 10.x firmware but not 8.x. We also have some GSM7352Sv2 which can run either.

* Since the GSM7352Sv2 returns the same sysObjectID regardless of whether it's running 8.x or 10.x, there is no sensible way to auto-detect which MIB flavour to use.

Example of differences - fan status


(8.x)
    boxServicesFanItemState OBJECT-TYPE
             SYNTAX      INTEGER {
                                  operational(1),
                                  failed(2),
                                  powering(3),
                                  notpowering(4),
                                  notpresent(5)
                                 }

(10.x)
    boxServicesFanItemState OBJECT-TYPE
             SYNTAX      INTEGER {
                                  notpresent(1),
                                  operational(2),
                                  failed(3),
                                  powering(4),
                                  nopower(5),
                                  notpowering(6),
                                  incompatible(7)
                                 }

The data is presented at the same OID, but the values have different meanings. Clearly Netgear could have enhanced the MIB in a backwards-compatible way by adding new values and keeping the old ones unchanged, but instead they shuffled them all around.

boxServicesPowSupplyItemState has the same issue.

Upgrading firmware from 8.x to 10.x without also changing your monitoring scripts will cause spurious errors. e.g. an "operational" fan will change from value 1 to value 2, which is "failed" in the old MIB. :(

Example of differences - temperature


(8.x)
    boxServicesTempSensorsEntry OBJECT-TYPE
         SYNTAX      BoxServicesTempSensorsEntry
         MAX-ACCESS  not-accessible
         STATUS      current
         DESCRIPTION
                     "Box Services Temperature Sensor Entry"
         INDEX { boxServicesTempSensorIndex }
         ::= { boxServicesTempSensorsTable 1 }

(10.x)
    boxServicesTempSensorsEntry OBJECT-TYPE
         SYNTAX      BoxServicesTempSensorsEntry
         MAX-ACCESS  not-accessible
         STATUS      current
         DESCRIPTION
                     "Box Services Temperature Sensor Entry"
         INDEX { boxServicesUnitIndex, boxServicesTempSensorIndex }
         ::= { boxServicesTempSensorsTable 1 }

Notice how the INDEX line has changed. The table now has a compound index (UnitIndex, TempSensorsIndex). UnitIndex is defined in the MIB as being a value between 1 and 8, I guess to do with stacking.

This is why the OIDs are one component longer than they were before.

If the monitoring system is still polling the old OID, it will find no data there at all.

However, once you find the new OID, at least the values returned are the same:


    boxServicesTempSensorState OBJECT-TYPE
             SYNTAX      INTEGER {
                                  normal(1),
                                  warning(2),
                                  critical(3),
                                  shutdown(4),
                                  notpresent(5),
                                  notoperational(6)
                                 }

I hope this helps anyone else who comes across the same issue!

Regards,

Brian.

Forum Discussion

Broken or missing SNMP MIBS for firmware 10.0.0.31 (GSM7352Sv2)

4 Replies

Related Content

Upgrade GSM7352Sv2 To Firmware 10.0.0.31 Fails

SNMP MIBs for GSM7352Sv2 10.0.0.53 firmware

Auto VoIP on gsm7352sv2

New - RS700S Firmware Version 1.0.9.16 Released

GSM7352Sv2 No Operational Code

NETGEAR Academy

ProSupport for Business