[Check_mk (english)] Check_MK, SNMP, Juniper, Help!

Archive checkmk-en
11

I’m woefully ignorant about SNMP, but here’s what I found from
Google.
It seems Juniper wants their devices to be polled ‘row by row’
instead of ‘column by column’ which
from what I’ve read, excludes using NetSNMP snmpwalk/bulkwalk.

From:�
···

http://www.juniper.net/documentation/en_US/junos14.1/topics/reference/general/snmp-junos-faq.html

SNMP Interaction with

Juniper Networks Devices FAQs
This section presents frequently asked questions
and answers
related to how SNMP interacts with Juniper Networks devices.

** How frequently should a device be polled? What
is a good polling rate?**

    It is difficult to give an absolute number for

the rate of SNMP
polls per second since the rate depends on the following two
factors:

  •     The number of variable bindings in a protocol data

    unit
    (PDU)

  •     The response time for an interface from the Packet

    Forwarding
    Engine
    In a normal scenario where no delay is being
    introduced by the
    Packet Forwarding Engine and there is one variable per PDU (a Get
    request), the response time is 130+ responses per second. However,
    with multiple variables in an SNMP request PDU (30 to 40 for
    GetBulk
    requests), the number of responses per second is much less.
    Because
    the Packet Forwarding Engine load can vary for each system, there
    is greater variation in how frequently a device should be polled.

      Frequent polling of a large number of counters,

especially statistics,
can impact the device. We recommend the following optimization
on
the SNMP managers:

  •     Use the row-by-row polling method, not the

    column-by-column
    method.

  • Reduce the number of variable bindings per PDU.

  •     Increase timeout values in polling and discovery

    intervals.

  •     Reduce the incoming packet rate at the SNMP process

    (snmpd).
    For better SNMP response on the device, the Junos
    OS does the
    following:

  • Filters out duplicate SNMP requests.

  •     Excludes interfaces that are slow in response from

    SNMP
    queries.
    One way to determine a rate limit is to note an
    increase in
    the Currently Active count
    from the show snmp statistics
    extensive command.

The following is a sample output of the show snmp statistics
extensive command:

user@host> ** show snmp statistics extensive** 

   SNMP statistics:
Input:
Packets: 226656, Bad versions: 0, Bad community names: 0,
Bad community uses: 0, ASN parse errors: 0,
Too bigs: 0, No such names: 0, Bad values: 0,
Read onlys: 0, General errors: 0,
Total request varbinds: 1967606, Total set varbinds: 0,
Get requests: 18478, Get nexts: 75794, Set requests: 0,
Get responses: 0, Traps: 0,
Silent drops: 0, Proxy drops: 0, Commit pending drops: 0,
Throttle drops: 27084, Duplicate request drops: 0
V3 Input:
Unknown security models: 0, Invalid messages: 0
Unknown pdu handlers: 0, Unavailable contexts: 0
Unknown contexts: 0, Unsupported security levels: 0
Not in time windows: 0, Unknown user names: 0
Unknown engine ids: 0, Wrong digests: 0, Decryption errors: 0
Output:
Packets: 226537, Too bigs: 0, No such names: 0,
Bad values: 0, General errors: 0,
Get requests: 0, Get nexts: 0, Set requests: 0,
Get responses: 226155, Traps: 382
SA Control Blocks:
Total: 222984, **Currently Active: 501**     , Max Active: 501,
Not found: 0, Timed Out: 0, Max Latency: 25
SA Registration:
Registers: 0, Deregisters: 0, Removes: 0
Trap Queue Stats:
Current queued: 0, Total queued: 0, Discards: 0, Overflows: 0
Trap Throttle Stats:
Current throttled: 0, Throttles needed: 0
Snmp Set Stats:
Commit pending failures: 0, Config lock failures: 0
Rpc failures: 0, Journal write failures: 0
Mgd connect failures: 0, General commit failures: 0

On 11/10/2015 03:09 AM, William wrote:

    Hi, we are still in a situation where we can't

monitor our ex2200s.

    Our other tech is trying to push zabbix because of

this issue which sucks as check_mk seems alot friendlier to
manage. :frowning:

    On 9 Nov 2015 19:41, "Andreas D�hler"

<andreas.doehler@gmail.com >
wrote:

Hi Matthew,

          yes the "Check_MK" service is the only active service

pulling all the needed data from the target device. The
shown time is the complete runtime to pull the data.

          I can remember that there where a discussion so

days/weeks before regarding the long runtime of interface
checks on Juniper devices.

http://lists.mathias-kettner.de/pipermail/checkmk-en/2015-June/015902.html

          The result of this discussion was that Juniper has some

stupid SNMP implementation and it is nearly impossible to
monitor the complete switch if there are more than some
ports on the switch.

Best regards

Andreas

Matthew Nickerson < >
schrieb am Mo., 9. Nov. 2015 um 20:01�Uhr:

            Can someone also please explain

what the check called “check_mk”

            actually does.� I know this sounds so stupid, but I

can’t figure it

            out.� I assume it is a count of how long it takes to

complete all of the

            checks assigned to a given host, maybe? I do know this,

when interface

            monitoring is on, the execution time of this process is

increased on

            average by about 3.5 times on every device. Take a look

at the attached

            photo, of the check_mk execution time.� Ythe time when I

disabled

            interface monitoring.� Very significant difference. I'm

trying to figure

            out how these two things tie together to troubleshoot

this.

            Thanks in advance all!



            On 11/9/2015 1:28 PM, Matthew Nickerson wrote:

            > So, as Lance pointed out to me once, I know there

was a big discussion

            > that took place just before I joined the list.�

I’ve read through it,

            > but I'm wondering if there have been any

developments. This

            > conversation was in regard to SNMP checks,

timeouts, and CPU usage on

            > Juniper devices with Check_MK.

            >

            > As it stands, now, when I enable� interface

monitoring (evenly solely

            > on my critical links) the CPU usage goes through

the roof and timouts

            > and retries happen all over the place.� I have set

all of the timers

            > various SNMP checks super low, and have tweaked my

SNMP timout and

            > retry values, (currently at 7 seconds with 5 second

retry) but it

            > isn't helping much

            >

            > Let me also say that we are currently using Zenoss

AND Infoblox

            > NetMRI, both of which are monitoring these Juniper

Switches. Further,

            > when they are turned on they are monitoring EVERY

single interface on

            > every juniper switch at 10 minute intervals and�

they do not cause the

            > above mentioned problems on the switches.� I have

tried turning them

            > off, and in fact, have them turned off completely

on the problem

            > switches and still all of the issues appear when

check_mk is

            > monitoring even just a handful of interfaces...�

This leads me to

            > believe that, indeed there may be something wrong

with the juniper

            > checks.

            >

            > Just trying to get some input, because as it stands

I won’t be able to

            > use check_mk, unfortunately, because I absolutely

love it and want to

            > get rid everything else!

            >

            > Help!

            >



            --

            Matthew Nickerson

            Network Engineer

            Computing Facilities, SCS

            Carnegie Mellon University

            (412) 268-7273

            checkmk-en mailing list

            checkmk-en@lists.mathias-kettner.de

            [http://lists.mathias-kettner.de/mailman/listinfo/checkmk-en](http://lists.mathias-kettner.de/mailman/listinfo/checkmk-en)

      _______________________________________________

      checkmk-en mailing list

      checkmk-en@lists.mathias-kettner.de

      [http://lists.mathias-kettner.de/mailman/listinfo/checkmk-en](http://lists.mathias-kettner.de/mailman/listinfo/checkmk-en)

_______________________________________________
checkmk-en mailing list

mnickers@cs.cmu.edu
checkmk-en@lists.mathias-kettner.dehttp://lists.mathias-kettner.de/mailman/listinfo/checkmk-en