SNMP missing OID's and OID's wrong value

1,274 views
Skip to first unread message

Hadas Ester Dalal

unread,
Jul 12, 2017, 6:14:59 AM7/12/17
to opennetworklinux

Hi ONL’s,

 

I’m running snmpwalk to watch all available onlp OID’s numbers and getting the below list:

 

ro...@10.7.191.120:/tmp# snmpwalk -v1 -c public 10.7.191.120 .1.3.6.1.4.1.42623

iso.3.6.1.4.1.42623.1.1.1.1.1.0 = STRING: "IDG4400"

iso.3.6.1.4.1.42623.1.1.1.1.2.0 = STRING: "MIDG4400-CS2REW"

iso.3.6.1.4.1.42623.1.1.1.1.3.0 = STRING: "MT0000X00000"

iso.3.6.1.4.1.42623.1.1.1.1.4.0 = STRING: "24:ba:07:a3:a4:14"

iso.3.6.1.4.1.42623.1.1.1.1.5 = INTEGER: 64

iso.3.6.1.4.1.42623.1.1.1.1.6.0 = STRING: "Mellanox"

iso.3.6.1.4.1.42623.1.1.1.1.7.0 = STRING: "04/02/2017 13:36:43"

iso.3.6.1.4.1.42623.1.1.1.1.9.0 = STRING: "x86_64-mlnx_idg4400-r0"

iso.3.6.1.4.1.42623.1.1.1.1.10 = INTEGER: 0

iso.3.6.1.4.1.42623.1.1.1.1.15.0 = STRING: "2016.11-5.1.0008-115200"

…

iso.3.6.1.4.1.42623.1.2.1.1.3.1 = INTEGER: 1

iso.3.6.1.4.1.42623.1.2.1.1.3.2 = INTEGER: 1

iso.3.6.1.4.1.42623.1.2.1.1.3.3 = INTEGER: 1

…

iso.3.6.1.4.1.42623.1.3.1.1 = Gauge32: 104

iso.3.6.1.4.1.42623.1.3.1.2 = Gauge32: 9896

 

For some reason OID’s .3.6.1.4.1.42623.1.1.1.1.5 and 3.6.1.4.1.42623.1.1.1.1.10 (OCP-ONL-PLATFORM-MIB) are INTEGER typed and are not suffixed with zero as STRING typed OID’s.

I’m using MIB browser as snmp manager and loading the mib files from OpenNetworkLinux-master\docs\mibs. The above OID’s are displayed with .0 suffix:

.3.6.1.4.1.42623.1.1.1.1.5.0

3.6.1.4.1.42623.1.1.1.1.10.0

 

When trying to perform GET request I’m getting an error of ‘no such name’ (which is expected since snmpwalk shows these OID’s without the suffix of .0).

 

Same issue with OID’s  .3.6.1.4.1.42623.1.3.1.1 and .3.6.1.4.1.42623.1.3.1.2 (OCP-ONL-RESOURCE-MIB) which are not displayed with .0 suffix on snmpwalk and are displayed with .0 suffix on MIB browser.

 

In addition OID’s 3.6.1.4.1.42623.1.1.1.1.11 – 14 are not implemented and also raises ‘no such name error’ when trying to query these values.

 

Did you encounter such issue?

Is it a bug on onlp-snmp/net-snmp code/MIB files?

 

Please assist and advise.

Thanks in advance!

Hadas

Jeffrey Townsend

unread,
Jul 12, 2017, 10:58:02 AM7/12/17
to Hadas Ester Dalal, opennetworklinux
Hadas, 

The default ONL build has SNMP enabled. It also has a script called onl-snmpdwalk which dumps all objects under the ONL tree (iso.3.6.1.4.1.42623.1). 

Here is the output from another platform for your reference. You should run this on your system while debugging:

Open Network Linux OS ONL-2.0.0, 2017-07-07.16:46-8a49914

localhost login: root
Password:
Last login: Thu Aug 30 22:45:00 UTC 2001 on ttyS1
Linux localhost 3.16.39-OpenNetworkLinux #1 SMP Fri Jul 7 16:53:08 UTC 2017 x86_64
root@localhost:~# onl-snmpwalk
OCP-ONL-PLATFORM-MIB::ProductName.0 = STRING: 5712-54X-O-AC-F
OCP-ONL-PLATFORM-MIB::PartNumber.0 = STRING: FP1ZZ5654001A
OCP-ONL-PLATFORM-MIB::SerialNumber.0 = STRING: SN-MAC-70:72:CF:DF:EE:6C
OCP-ONL-PLATFORM-MIB::MAC.0 = STRING: 70:72:cf:df:ee:6c
OCP-ONL-PLATFORM-MIB::MACRange = INTEGER: 74
OCP-ONL-PLATFORM-MIB::Manufacturer.0 = STRING: Accton
OCP-ONL-PLATFORM-MIB::Vendor.0 = STRING: Edgecore
OCP-ONL-PLATFORM-MIB::PlatformName.0 = STRING: x86_64-accton_as5712_54x-r0
OCP-ONL-PLATFORM-MIB::DeviceVersion = INTEGER: 0
OCP-ONL-PLATFORM-MIB::LabelRevision.0 = STRING: R01H
OCP-ONL-PLATFORM-MIB::CountryCode.0 = STRING: TW
OCP-ONL-PLATFORM-MIB::DiagVersion.0 = STRING: 2.0.1.0
OCP-ONL-PLATFORM-MIB::OnieVersion.0 = STRING: 2014.08.00.05
OCP-ONL-SENSOR-MIB::onlTempSensorsIndex.1 = INTEGER: 1
OCP-ONL-SENSOR-MIB::onlTempSensorsIndex.2 = INTEGER: 2
OCP-ONL-SENSOR-MIB::onlTempSensorsIndex.3 = INTEGER: 3
...


Additional comments inline. 

On Wed, Jul 12, 2017 at 3:14 AM, Hadas Ester Dalal <had...@mellanox.com> wrote:

Hi ONL’s,

 

I’m running snmpwalk to watch all available onlp OID’s numbers and getting the below list:

 

ro...@10.7.191.120:/tmp# snmpwalk -v1 -c public 10.7.191.120 .1.3.6.1.4.1.42623

iso.3.6.1.4.1.42623.1.1.1.1.1.0 = STRING: "IDG4400"

iso.3.6.1.4.1.42623.1.1.1.1.2.0 = STRING: "MIDG4400-CS2REW"

iso.3.6.1.4.1.42623.1.1.1.1.3.0 = STRING: "MT0000X00000"

iso.3.6.1.4.1.42623.1.1.1.1.4.0 = STRING: "24:ba:07:a3:a4:14"

iso.3.6.1.4.1.42623.1.1.1.1.5 = INTEGER: 64

iso.3.6.1.4.1.42623.1.1.1.1.6.0 = STRING: "Mellanox"

iso.3.6.1.4.1.42623.1.1.1.1.7.0 = STRING: "04/02/2017 13:36:43"

iso.3.6.1.4.1.42623.1.1.1.1.9.0 = STRING: "x86_64-mlnx_idg4400-r0"

iso.3.6.1.4.1.42623.1.1.1.1.10 = INTEGER: 0

iso.3.6.1.4.1.42623.1.1.1.1.15.0 = STRING: "2016.11-5.1.0008-115200"

…

iso.3.6.1.4.1.42623.1.2.1.1.3.1 = INTEGER: 1

iso.3.6.1.4.1.42623.1.2.1.1.3.2 = INTEGER: 1

iso.3.6.1.4.1.42623.1.2.1.1.3.3 = INTEGER: 1

…

iso.3.6.1.4.1.42623.1.3.1.1 = Gauge32: 104

iso.3.6.1.4.1.42623.1.3.1.2 = Gauge32: 9896

 

For some reason OID’s .3.6.1.4.1.42623.1.1.1.1.5 and 3.6.1.4.1.42623.1.1.1.1.10 (OCP-ONL-PLATFORM-MIB) are INTEGER typed and are not suffixed with zero as STRING typed OID’s.


The reason they are INTEGER instead of STRING is because they are integers and not strings. .1.5 is the MacRange and .1.10 is the DeviceVersion. 
It is working as designed. 


 

I’m using MIB browser as snmp manager and loading the mib files from OpenNetworkLinux-master\docs\mibs. The above OID’s are displayed with .0 suffix:

.3.6.1.4.1.42623.1.1.1.1.5.0

3.6.1.4.1.42623.1.1.1.1.10.0

 

When trying to perform GET request I’m getting an error of ‘no such name’ (which is expected since snmpwalk shows these OID’s without the suffix of .0).

 


I can't speak to what is happening in your MIB browser but the ONL MIB files declare their type correctly as far as I can tell. 
When the same MIB files are loaded and dumped locally on the switch (as per onl-snmpwalk above) there does not appear to be an issue. 

If there is some subtle misdeclaration in the MIB files I would be happy to fix it (but someone will have to point it out to me). 

 

Same issue with OID’s  .3.6.1.4.1.42623.1.3.1.1 and .3.6.1.4.1.42623.1.3.1.2 (OCP-ONL-RESOURCE-MIB) which are not displayed with .0 suffix on snmpwalk and are displayed with .0 suffix on MIB browser.

 


Also not strings (Gauge32). 
 

In addition OID’s 3.6.1.4.1.42623.1.1.1.1.11 – 14 are not implemented and also raises ‘no such name error’ when trying to query these values.


These values are the LabelRevision, Country Code, Diag Version, and Service Tag, respectively. 
If these fields are not present in your eeprom (and are not displayed by onlpd -s) then they will not be available via SNMP either. 

Jeff


 

 

Did you encounter such issue?

Is it a bug on onlp-snmp/net-snmp code/MIB files?

 

Please assist and advise.

Thanks in advance!

Hadas

--
You received this message because you are subscribed to the Google Groups "opennetworklinux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opennetworklinux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Hadas Ester Dalal

unread,
Jul 13, 2017, 3:58:17 AM7/13/17
to Jeffrey Townsend, opennetworklinux

Hi Jeff,

 

First, thanks for the quick and detailed answer!

 

Regarding to OID’s .1.5 and .1.10 (MacRange, DeviceVersion) , I didn’t ask why they are INTEGER typed and not STRING, just why OID’s does not have the suffix of .0 as STRING types have.

Same question regarding OID’s  .3.6.1.4.1.42623.1.3.1.1 and .3.6.1.4.1.42623.1.3.1.2 (CpuAllPercentUtilization, CpuAllPercentIdle).

iso.3.6.1.4.1.42623.1.1.1.1.2.0 = STRING: "MIDG4400-CS2REW"

iso.3.6.1.4.1.42623.1.1.1.1.3.0 = STRING: "MT0000X00000"

iso.3.6.1.4.1.42623.1.1.1.1.4.0 = STRING: "24:ba:07:a3:a4:14"

iso.3.6.1.4.1.42623.1.1.1.1.5 = INTEGER: 64

these OID’s are represented in MIB file same as STRING types, and each standard MIB browser/SNMP manager extract their OID’s with the suffix of .0, what causes to ‘no such name error’ although it exists (with OID number without .0 suffix).

 

Regarding to LabelRevision, Country Code, Diag Version, and Service Tag fields, they are indeed not represented in EEPROM but as I can understand from code, this part of implementation is not a platform specific($ONL/packages/base/any/onlp-snmpd/builds/src/onlp_snmp/module/src/onlp_snmp_platform.c : onlp_snmp_platform_init) and should have some defaults to case it’s not represented. Isn’t it?

Note that when adding this to eeprom file, their values are been retrieved successfully.

 

Thanks,

Hadas

--

To unsubscribe from this group and stop receiving emails from it, send an email to opennetworklin...@googlegroups.com.

Jeffrey Townsend

unread,
Jul 13, 2017, 4:04:29 PM7/13/17
to Hadas Ester Dalal, opennetworklinux
Hadas, 

My apologies, I understand. You are correct -- after looking at the code it looks like those 4 scalars (MacRange, DeviceVersion, Cpu*Percent*) are getting registered as integer instances instead of integer scalars with the consequence that the single-instance subidentifier (.0) is missing. 
This is a bug in the onlp-snmpd agent and should be corrected for compliance with the standard. 

As for the EEPROM fields the code that exports the fields is not platform specific but the data in the fields is provided by the platform. If the data is not present then there are no meaningful defaults that can be provided. There are no default values for LabelRevision, Country Code, Diag Version, or Service Tag that can be provided in lieu of the actual data. 
Currently the OIDs just don't get registered -- the only other possible option is to keep the OIDs registered but return empty strings. 

Jeff



--

To unsubscribe from this group and stop receiving emails from it, send an email to opennetworklinux+unsubscribe@googlegroups.com.

Hadas Ester Dalal

unread,
Jul 16, 2017, 6:27:38 AM7/16/17
to Jeffrey Townsend, opennetworklinux

Hi Jeff,

 

First, thanks for the reply!

 

I have added a fix to onlp-snmpd agent in our origin branch and tested it with MIB browser and snmpwalk.

Please review the fix below so we can push it to general origin OpenNetworkLinux in the future:

 

--- a/packages/base/any/onlp-snmpd/builds/src/onlp_snmp/module/src/onlp_snmp_platform.c

+++ b/packages/base/any/onlp-snmpd/builds/src/onlp_snmp/module/src/onlp_snmp_platform.c

@@ -66,10 +66,11 @@ platform_int_register(int index, char* desc, int value)

     int* v = aim_zmalloc(sizeof(value));

     *v = value;

-    netsnmp_register_int_instance(desc,

-                                  tree,

-                                  OID_LENGTH(tree),

-                                  v, NULL);

+    netsnmp_register_watched_scalar2(

+               netsnmp_create_handler_registration(

+                     desc, NULL, tree, OID_LENGTH(tree), HANDLER_CAN_RWRITE),

+               netsnmp_create_watcher_info(

+                   (void *)v, sizeof(int), ASN_INTEGER, WATCHER_FIXED_SIZE));

}

 static void

@@ -83,9 +84,9 @@ resource_int_register(int index, const char* desc,

         netsnmp_create_handler_registration(desc, handler,

                                             tree, OID_LENGTH(tree),

                                             HANDLER_CAN_RONLY);

-    if (netsnmp_register_instance(reg) != MIB_REGISTERED_OK) {

-        AIM_LOG_ERROR("registering handler for %s failed", desc);

-    }

+    if (netsnmp_register_scalar(reg) != MIB_REGISTERED_OK) {

+       AIM_LOG_ERROR("registering handler for %s failed", desc);

+   }

}

 

Thanks,

Hadas

 

From: Jeffrey Townsend [mailto:jeffrey....@bigswitch.com]
Sent: Thursday, July 13, 2017 11:04 PM
To: Hadas Ester Dalal <had...@mellanox.com>
Cc: opennetworklinux <opennetw...@googlegroups.com>
Subject: Re: SNMP missing OID's and OID's wrong value

 

Hadas, 

 

My apologies, I understand. You are correct -- after looking at the code it looks like those 4 scalars (MacRange, DeviceVersion, Cpu*Percent*) are getting registered as integer instances instead of integer scalars with the consequence that the single-instance subidentifier (.0) is missing. 

--

To unsubscribe from this group and stop receiving emails from it, send an email to opennetworklin...@googlegroups.com.

Jeffrey Townsend

unread,
Jul 19, 2017, 5:48:05 PM7/19/17
to Hadas Ester Dalal, opennetworklinux
Hadas, 

Thank you very much for the fix. Would you mind submitting a pull request so it can be reviewed and merged properly?

Jeff

On Sun, Jul 16, 2017 at 3:27 AM, Hadas Ester Dalal <had...@mellanox.com> wrote:

Hi Jeff,

 

First, thanks for the reply!

Cc: opennetworklinux <opennetworklinux@googlegroups.com>

--

To unsubscribe from this group and stop receiving emails from it, send an email to opennetworklinux+unsubscribe@googlegroups.com.

Reply all
Reply to author
Forward
0 new messages