• 0
Michael Dieter

SNMP tuning with Juniper Networks devices

Question

I started working on the best-practice of implementing Collector dashboards, which revealed to me a number of undesirable conditions of which I hadn't previously been aware and suggest that I need to go through some Collector Tuning excercises.

LogicMonitor has an excelllent reference page on this topic http://www.logicmonitor.com/support/settings/collectors/tuning-collector-performance/

For those of you who are monitoring any density of Juniper devices, 1)I feel your pain; 2)I would recommend that you use this Juniper reference to complement LM's instructions.

https://www.juniper.net/techpubs/en_US/release-independent/nce/information-products/topic-collections/nce/snmp-best-practices/junos-os-snmp-best-practices.pdf

And another note: you can look for my previous thread for details if you want, but I do not at all recommend using SNMPv3 to monitor either Juniper Virtual Chassis (switch stack) or Juniper routers with multiple Routing Engines.  If you've somehow managed to consistently and successfully do this, I'd appreciate a post with your solution.

Share this post


Link to post
Share on other sites

3 answers to this question

Recommended Posts

  • 0

I don't think that SNMPv3 is really worth it in the private enterprise where everything is already hidden behind firewalls and RFC1918 networks. The data being gathered really isn't all that sensitive.

DMZ? Yeah, that's a place for it just in case but in the private network area I think SNMPv3 is overkill.

Just my opinion. Last gig I was at I worked hard removing SNMPv3 from all of the private stuff with 98% of the issue being with getting the other engineers to understand the lack of privacy issues involved with private networking.

I have a juniper stack in my lab (3xEX4200) that I am hitting regularly with SNMPv2 without hiccup or problem. Perhaps move away from SNMPv3 where you do not need it?

Share this post


Link to post
Share on other sites
  • 0

As a follow-up, see below for ideas that I should have included the first time.

A good way to contribute towards improved Collector efficiency and performance, and potentially moderate the demands that polling exert on your Juniper devices (or any devices, really):

  • Review the datasources that associate with your devices, to ensure that they are providing only information that has value and then customize them accordingly --> adjust Discovery schedules and eliminate any datasources or underlying datapoints that aren't providing value. Use Caution: don't delete a datapoint supporting a calculation elsewhere!
  • Review datasource Collection intervals (especially multi-instance ones with a high-density) and increase them from their default values (either by globally editing the datasource, creating customized versions with different collection intervals, or setting group/device properties specifying collection interval for that datasource) where possible.  For example, maybe its acceptable to poll the 48 10/100/1000 switch interfaces that connect end-user devices every 4-5 minutes, but the 2 fiber uplinks require 2 minute visibility.  If you have 100 (or even 50 or 10) switches this can make a big difference.

LogicMonitor gives you many different ways to combine settings to achieve this, so think it through to come up with the way best suited for your environment. Just don't forget that changes in collection intervals will impact Alert Thresholds, so make sure you account for that.

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.