Forum Discussion

Michael_Dieter's avatar
Michael_Dieter
Icon for Neophyte rankNeophyte
9 years ago

SNMP tuning with Juniper Networks devices

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.

juniper
snmp
  • Michael_Dieter's avatar
    Michael_Dieter
    Icon for Neophyte rankNeophyte
    9 years ago

    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.

     

  • Michael_Horwath's avatar
    Michael_Horwath
    9 years ago

    BTW: thanks for linking that PDF - never seen that one before and it has some good info in it.

  • Michael_Horwath's avatar
    Michael_Horwath
    9 years ago

    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?