Would any of these snmp options help? Maybe limit SNMP OID ranges or Legacy devices?
Legacy devices using v2c help says this: There exist a few devices out there that behave very badly when using SNMP v2c and bulk walk. If you want to use SNMP v2c on those devices, nevertheless, you need to configure this device as legacy snmp device and upgrade it to SNMP v2c (without bulk walk) with this rule set. One reason is enabling 64 bit counters. Note: This rule won't apply if the device is already configured as SNMP v2c device.
Thank you,
Lance Tost
lance.tost@key-stone.com
Sr. Network Administrator
Keystone Automotive Operations, Inc.
···
________________________________________
From: checkmk-en-bounces@lists.mathias-kettner.de <checkmk-en-bounces@lists.mathias-kettner.de> on behalf of Raphael Mazelier <raph@futomaki.net>
Sent: Tuesday, November 10, 2015 4:28 PM
To: checkmk-en@lists.mathias-kettner.de
Subject: Re: [Check_mk (english)] Check_MK, SNMP, Juniper, Help!
Welcome to the great land of the snmp on cheap juniper network device.
And be sorry. The paper of juniper is right.
Basicaly the snmp implementation of snmp in juniper is completly crappy
as polling the device can completly kill the cpu, and so every userland
daemons of the swith/routeur (rpd, lacpd, etc...) can suffer and have no
time left to run, results in variety of bad things (lost of lacp link,
routing protocol hang, etc...) Note: forwarding, routing is not affected.
This is completly stupid that snmp can kill vitals functions of a
network device... but it was the case 
and juniper have no real plan
to change this...
That says, this is not completly impossible to safely monitor this type
of device using snmp (I suppose we talk about EX2200, 3300, 45XX, with
cheap cpu, high end router do not pose problem).
You must avoid using snmpwalk on this device, specialy on IF part of the
mib. That's why monitoring tools are not equal monitoring this type of
devices :
- obversium is the worst, as it try to snmpwalk at each run almost the
entire IF mib (and a lot of other). The result can be catastrophic.
Anyway the observium poller is just a joke.
- check mk (with basic interface) check do the same, but poll less part
of the mib (but this can cause problem also). Afaik check_mk compile all
snmp requests on one device and do walk on it.
- cacti is the right way to do : first poll to detect/scan wich
interface are present (poller cache), and then at each run do small
targetet snmpget.
So this is the way to do :
- implement a cache of oid to get (refresh it manualy)
- do targeted small snmp get, and better space it out.
I don't know if check_mk can be optimized (or de optimized) for handling
such bad network devices.
Regards,
Le 10/11/15 21:46, Jam Mulch a écrit :
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:
Network Monitoring by using SNMP | Junos OS | Juniper Networks
--
Raphael Mazelier
AS39605
_______________________________________________
checkmk-en mailing list
checkmk-en@lists.mathias-kettner.de
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.mathias-2Dkettner.de_mailman_listinfo_checkmk-2Den&d=CwIF-g&c=rxuyg758I4Zd3CDHNny_Hw&r=IG1JnIFZjjAeb-dpz2SPNF_6BaSzaPzu56FYglLqpI0&m=tlX6FiGKFE1ETOMJL0CeCnvQv6WKf6aLunwxySW39y0&s=y-lR9JCzR7Y5eaIbY4uWj6_SHZRuAWYOu_h41UZ8Uqo&e=