perl pass_persist && getnext/getbulk

Jurkiewicz Jean-Marc

2015-07-13 07:19:09 UTC

Hi all,

GETBULK always fills the returned buffer, so if your request does not completely "fill" the returned buffer, the agent will read further in the OID tree to fill the buffer.

(please have a look at http://jmjmon.eu/LaSupervisionDeReseau/SNMP_Mon-V010.pdf page 74 and further)

From my understanding, the problem does not come from GETBULK, either from snmptable that do not "clean-up" the "overhead " used to fill the buffer.

When I use GETBULK I always (see same URL page 81 and 115) check that the last returned information is an answer to the requested OID, and not used-to-fill information.

Hope this helps

Best regards
JMJ

-----Message d'origine-----
De : Turbo Fredriksson [mailto:***@bayour.com]
Envoyé : dimanche 12 juillet 2015 21:46
À : net-snmp-***@lists.sourceforge.net
Objet : perl pass_persist && getnext/getbulk - no end of MIB

I've been fixing some issues with my MIB (or at least tried to, see the "Integer64 support" thread).

In doing so, I discovered some minor issues and one that's . "irritating".

The log file is from the output of the pass_persist script
(https://github.com/FransUrbo/snmp-modules/blob/master/zfs/zfs-snmp-stats.pl)

----- s n i p -----
DebianZFS-Jessie64-Devel-Daily:/usr/src# snmpwalk -uro -v2c -cpublic localhost zfsPoolStatusTable
BAYOUR-COM-MIB::zfsPoolStatusIndex.1 = INTEGER: 1
BAYOUR-COM-MIB::zfsPoolStatusIndex.2 = INTEGER: 2
BAYOUR-COM-MIB::zfsPoolName.1 = STRING: rpool
BAYOUR-COM-MIB::zfsPoolName.2 = STRING: rpool 2
BAYOUR-COM-MIB::zfsPoolGUID.1 = STRING: 4977845871582736322
BAYOUR-COM-MIB::zfsPoolGUID.2 = STRING: 3787144349319647945
BAYOUR-COM-MIB::zfsPoolSize.1 = Opaque: Int64: 8256506880
BAYOUR-COM-MIB::zfsPoolSize.2 = Opaque: Int64: 8256506880
BAYOUR-COM-MIB::zfsPoolAlloc.1 = INTEGER: 132096
BAYOUR-COM-MIB::zfsPoolAlloc.2 = INTEGER: 111616
BAYOUR-COM-MIB::zfsPoolFree.1 = Opaque: Int64: 8256374784
BAYOUR-COM-MIB::zfsPoolFree.2 = Opaque: Int64: 8256395264
BAYOUR-COM-MIB::zfsPoolCap.1 = INTEGER: 0
BAYOUR-COM-MIB::zfsPoolCap.2 = INTEGER: 0
BAYOUR-COM-MIB::zfsPoolDedup.1 = STRING: 1.00
BAYOUR-COM-MIB::zfsPoolDedup.2 = STRING: 1.00
BAYOUR-COM-MIB::zfsPoolHealth.1 = INTEGER: online(4)
BAYOUR-COM-MIB::zfsPoolHealth.2 = INTEGER: online(4)
BAYOUR-COM-MIB::zfsPoolAltRoot.1 = STRING: -
BAYOUR-COM-MIB::zfsPoolAltRoot.2 = STRING: -
BAYOUR-COM-MIB::zfsPoolUsedBySnaps.1 = INTEGER: 0
BAYOUR-COM-MIB::zfsPoolUsedBySnaps.2 = INTEGER: 0
BAYOUR-COM-MIB::zfsPoolUsed.1 = INTEGER: 282624
BAYOUR-COM-MIB::zfsPoolUsed.2 = INTEGER: 111616 DebianZFS-Jessie64-Devel-Daily:/usr/src# egrep '[0-9] \.[0-9]' /tmp/zfs-snmp.log
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.1.1 = 1
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.1.2 = 22015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.2.1 = rpool
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.2.2 = rpool 2
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.3.1 = 4977845871582736322
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.3.2 = 3787144349319647945
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.4.1 = 8256506880
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.4.2 = 8256506880
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.5.1 = 132096
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.5.2 = 111616
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.6.1 = 8256374784
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.6.2 = 8256395264
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.7.1 = 0
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.7.2 = 0
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.8.1 = 1.00
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.8.2 = 1.00
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.9.1 = ONLINE
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.9.2 = ONLINE
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.10.1 = -
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.10.2 = -
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.11.1 = 0
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.11.2 = 0
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.12.1 = 282624
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.12.2 = 111616
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.6.1.1.1 = 1 DebianZFS-Jessie64-Devel-Daily:/usr/src#
----- s n i p -----

Here a "snmpwalk" work just fine. It outputs the whole zfsPoolStatusTable and as soon as "snmpwalk" finds the first entry of the next branch, it cancels (?) the continuing requests.

However:

----- s n i p -----
DebianZFS-Jessie64-Devel-Daily:/usr/src# snmptable -uro -v2c -cpublic localhost zfsPoolStatusTable SNMP table: BAYOUR-COM-MIB::zfsPoolStatusTable
zfsPoolName zfsPoolGUID zfsPoolSize zfsPoolAlloc zfsPoolFree zfsPoolCap zfsPoolDedup zfsPoolHealth zfsPoolAltRoot zfsPoolUsedBySnaps zfsPoolUsed
rpool 4977845871582736322 8256506880 132096 8256374784 0 1.00 online - 0 282624
rpool 2 3787144349319647945 8256506880 111616 8256395264 0 1.00 online - 0 111616
BAYOUR-COM-MIB::zfsPoolStatusTable: WARNING: More columns on agent than in MIB DebianZFS-Jessie64-Devel-Daily:/usr/src# egrep '[0-9] \.[0-9]' /tmp/zfs-snmp.log2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.1.1 = 1
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.1.2 = 2
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.2.1 = rpool
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.2.2 = rpool 2
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.3.1 = 4977845871582736322
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.3.2 = 3787144349319647945
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.4.1 = 8256506880
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.4.2 = 8256506880
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.5.1 = 132096
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.5.2 = 111616
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.6.1 = 8256374784
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.6.2 = 8256395264
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.7.1 = 0
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.7.2 = 0
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.8.1 = 1.00
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.8.2 = 1.00
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.9.1 = ONLINE
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.9.2 = ONLINE
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.10.1 = -
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.10.2 = -
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.11.1 = 0
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.11.2 = 0
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.12.1 = 282624
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.12.2 = 111616
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.6.1.1.1 = 1
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.6.1.2.1 = 1198736
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.6.1.3.1 = 1194848
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.6.1.4.1 = 393386496
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.6.1.5.1 = 524515328
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.6.1.6.1 = 1194848
----- s n i p -----

Here, "snmptable" claims that there's more columns, not part of the MIB. But they're really not part of that table.

But why isn't "snmptable" stops when it receives the ".1.3.6.1.4.1.8767.2.6.6.1.1.1" entry like "snmpwalk" do (I only have one entry/line in the next table, the zfsARCUsageTable)?

And this is the same of ALL my tables. If I add "-CB" to the "snmptable" command it works.

Is there a special "END OF MIB" entry I need to output to make it know that it's done? I tried "NONE\n", but that didn't work. Tried "END\n" as well, but no luck there either.

I guess, from finding the "-CB" option in the manpage, that the "problem" have something to do with GETBULK...
--
Life sucks and then you die

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Net-snmp-users mailing list
Net-snmp-***@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users