Versions Compared

Old Version 3

changes.mady.by.user Keith Sinclair

Saved on

compared with

New Version Current

changes.mady.by.user alexz

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: simplified instructions

...

SNMP is a protocol specification which is standardised in the IETF, . SNMPv1 does not support 64 bit counters, ; 64 bit counters were one of the primary drivers behind the development of SNMPv2 and ultimately SNMPv2c.  SNMPv1 was ratified in 1990 with RFC 1155, RFC 1156 and RFC 1157, the MIB definitions were updated in RFC 1213.  SNMPv2c was ratified in 1996, making which makes 2016 is its 20th birthday.

Why are 64 bit counters important?

Cisco published a great article on this, : SNMP Counters: Frequently Asked Questions, and RFC 2233 summarises this the issue best:

"As the speed of network media increase, the minimum time in which
a 32 bit counter will wrap decreases.  For example, a 10Mbs stream
of back-to-back, full-size packets causes ifInOctets to wrap in
just over 57 minutes; at 100Mbs, the minimum wrap time is 5.7
minutes, and at 1Gbs, the minimum is 34 seconds.  Requiring that
interfaces be polled frequently enough not to miss a counter wrap
is increasingly problematic."

...

Despite this interesting bit of history, some Network Vendors, network device vendors still only support SNMPv1, which isn't a problem , unless you have high speed interfaces , (for example 1 gigabit per second, which some of these vendors to have, funnily do have). Funnily enough these same vendors vendor companies have only existed for 10-15 years, so are younger than the standards they should be implementing.

So In the other corner we have NMIS, which is Open Source and - by the nature of Open Source and of software using relying on IETF protocols and specifications , NMIS is standards based- strongly standards-oriented.

...

Making NMIS work with SNMPv1 using 64-bit counters

NMIS itself is not strongly typed , and doesn't have a problem with 64-bit counters; the issue here is with the set of SNMP libraries that NMIS uses, which do strictly enforce the standards.

How will I know that I need to change NMIS?

NMIS will be reporting an error with for SNMP , collection operations; the message is will be something like "The Counter64 type is not supported in SNMPv1", this .  This would be seen in the debug output and also in the NMIS Event log.  For example:

Code Block
19:25:13 checkResult, SNMP ERROR (Ubiquiti-AirFiber1) (1.3.6.1.4.1.41112.1.3.3.1.1) The Counter64 type is not supported in SNMPv1

If you see this, then you have devices cheating and a device that is cheating by using a non-standard protocol-datatype combination.

What do I have to change?

To make NMIS work with this non-standard combination, you need to modify the SNMP library source code to prevent it from detecting the issue.  NMIS (and aborting on) the datatype mismatch.
NMIS uses the Net::SNMP library perl module and only one file in belonging to this library needs to be changedadjusted.  The The file in question is Message.pm, (or in Perl terms the class file module Net::SNMP::Message, );this is the object which manages the SNMP messages.
First locate locate Message.pm on your system, it which will normally be in one of the perl directories in under /usr /local or possibly in /usr/local.
Run Simply use the Unix Unix find command to do the lookup work for you.:

 

Code Block
find /usr/local/ -type f -name path "*/Net/SNMP/Message.pm "

The result would should be something like similar to this:

Code Block
[root@nmis models]# $ find /usr/local/ -type f -name path "*/Net/SNMP/Message.pm "
/usr/local/share/perl5/Net/LDAPSNMP/Message.pm
/usr/local/share/perl5/Net/SNMP/Message.pm

If find returns more than one match, run perl -V and check the @INC list: the module files are looked up in all  @INC directories in order, and the first match wins. That's the file you want to modify. In the example above, the module in /usr/local/share wins over the one in /

perl5

usr/

Mojo/Message.pm

share.

  • First, make a backup (as the root user): cp /usr/local/share/perl5/Net/
HTTP
  • SNMP/Message.pm
We are after the one for the class Net::SNMP::Message so the file we want (translating :: to
  • /
) is /
  • usr/local/share/perl5/Net/SNMP/Message.pm
, first thing, make a backup
  • .unpatched
Edit the source code
  • Next, edit the file /usr/local/share/perl5/Net/SNMP/Message.pm
and find "
  • (again as the root user) and look for 'sub _process_counter64
" in
  • '.
    In version 3.0.1 it is on line 1650 of
the code
  • that file.
 You
  • You want to
comment out the
  • disable the if statement which generates the error and returns
, so
  • ; just comment out the 'problematic' code with
# as below,
  • '#'.
    It is also advisable to add a comment that explains why the change wa made; In the example below, the editor was started with line number display, lines 1655 to 1657 have been commented out,
    and line 1654 was amended to describe the change.

 

Code Block
   1650 sub _process_counter64
   1651 {
   1652    my ($this, $type) = @_;
   1653 
   1654    # Verify the SNMP version - disabled for non-standard V1+64bit combination
   1655    #if ($this->{_version} == SNMP_VERSION_1) {
   1656    #   return $this->_error('The Counter64 type is not supported in SNMPv1');
   1657    #}
   1658 
   1659    # Decode the length
That's it
  • Finally, run
your
  • an  NMIS update on the node in question
,
  • ; this will verify
the
  • that your modified code still compiles and runs, and that NMIS works
and should solve your problem, if  you get crazy
  • around the non-standard device behaviour.
    Should you get weird Perl errors, restore your backup and try the edit operation again.

If Please note that if the perl Library is updated this change will library is updated (by apt-get or yum or some other software administration tool), then your adjustment will likely be lost and you will need to do it again.