Datasource development challenge
Anyone have any ideas about how to solve this challenge? We'd like to collect dhcp relay stats from our Juniper routers, not necessarily for minute-by-minute graphs and alerts but to be able to show patterns of longer term trends (hourly, daily, monthly) I've got the list of OIDs for the counts of DORA plus Naks, Informs, total lease count and total drops. The kicker is that they are stored on a per routing instance (ie VRF) basis and the OIDs aren't structured like #WILDVALUE (routing instance name or ID)#.n.n.n Instead, all routing instances use the same OIDs, and to query them you issue a get at each OID with [routing instance name@(snmp community)] as the snmp community; the output returned corresponds to the name of the routing instance. Somehow this has to possible, but it may be a situation where the effort to achieve and/or sustain it is going to exceed the value of the data it would provide.Solved37Views0likes4CommentsJuniper switch port usage trending R2NNTG
R2NNTG My group supports several hundred switches across all of our buildings and locations, but we don't always receive reliable or timely information about events that change the local density of wired connectivity needed to support constituents and their various devices. This frequently results in a significant amount of wasted switch port capacity and wasted electricity when a specific location is vacated or its use changed and we are not told, leaving a 48-port switch where 24 ports or less would be sufficient for example (worst of all is the scenario where we purchase additional switch hardware to support growth or expansion in a location while under-utilized switch hardware needlessly burns power and annual maintenance $ elsewhere. The referenced datasource here is expected to help this situation. It is not a switch-by-switch, port-by-port uptime measurement, rather it shows the percentage of ports with link (ie in use) over a range of time. Its value is expected to come from providing a longer-term trend of ports in use for specific locations by highlighting those locations where switches can be removed due to persistent over-capacity, but it can certainly be effective tracking use-cases with shorter term periods as well. It is extremely well-suited to presentation on a dashboard. Note that this datasource was built for Juniper switches [and includes specific interface filtering so you will need to adjust that (along with Applies To and any thresholds) to meet your needs] but it is most likely not difficult to substitute other vendors' MIB/OID into it. Much thanks to Josh L on the pro-services team who did all the real development work. R2NNTG0Views0likes0CommentsJuniper Switch HW Info
Name: Name: Juniper Virtual Chassis_lmsupport Display Name: Displayed As: Juniper Virtual Chassis_HW Info Locator Code: YWWE74 I modified (actually, I had help from Support) the datasource Juniper Virtual Chassis- so that values that originally were displayed in the UI as only descriptive text on per-instance mouse-overs are now presented as properties. Juniper switches present difficulty to the datasource Device_Component_Inventory; this modification allows a single-step way to associate with stand alone switches and virtual chassis while getting inventory data on a per-member basis instead of on just whichever switch happens to be the virtual chassis routing-engine at the time of polling. And it comes with the huge bonus that using ILP as the instance grouping method produces a great presentation in the UI. It collects from jnxVirtualChassisMemberEntry (there are other values there that may be of interest to you, so walk it) for each member of a virtual chassis, but it does require that you enter any specific info you would like to see into the command <set...member n location [any desirable text value]>. We chose to enter building and room location along with asset tag number and it is stored by the property auto.vcmemberassetinfo Also, you will need to configure even standalone switches as a virtual chassis <set...member 0 location [any desired value]> The Descriptive text in the original datasource is not reportable, but properties are, and this lets us create a great report using the Device Inventory report. It gives us device name building, room number and asset tag for each individual switch in a virtual chassis serial number for each individual switch in a virtual chassis HW model info for each individual switch in a virtual chassis junos version for each individual switch in a virtual chassis Special thanks to Support Engineer Johnny Y for doing most of the heavy lifting (after recognizing that I was trying to pound a screw in with a hammer), all the other Support Engineers who patiently answered my questions in a series of cases, and to CSM Kyle for kickstarting me.2Views0likes3CommentsJuniper Router HW Info
Name: Juniper Router Inventory Displayed As: Juniper MX and SRX HW Info Locator Code: RJEAXH I cloned the Device_Component_Inventory and modified it to work with Juniper MX and SRX devices, since D_C_I didn't work with Juniper OoB. There is more information available within Juniper's jnxBoxAnatomy if you'd like to further modify, but serial number and box description were most valuable to us. We added snmp sysContact, which is how/where we've chosen to record Building Location and Asset Tag number in a router's local configuration file (we wanted to reserve snmp sysLocation for future use) and represent that with a property called "auto.assetinfo" and then we added the system.sysinfo property. We've used this very effectively with the Device Inventory Report, which gives us inventory with the following: Device Name (in Logicmonitor) Serial number Building, Room number, asset tag HW Description Junos version Thanks very much to my CSM Kyle and to each of the Support Engineers who provided answers to questions that helped me put this together.0Views0likes0CommentsCustomized Juniper Interface datasources
I've published these customized interface datasources for use with Juniper Networks' switches and routers. Combined with additional snmp configuration of the devices, these have helped make Juniper devices a little easier to deal with. I think there is much room for additional customization to permit further grouping. NOTES: in all three the Collection schedule is unchanged but the Discovery period has been reduced to the minimum (10 minutes), which may not be necessary for all use-cases/environments. none of the default datapoints (normal and complex) were removed or edited in any way "snmp64_If_juniper_VCP_interfaces" does not capture every single VCP port in VC larger than 2 members. Additional investigation is needed to understand how Juniper makes VCP accessible via snmp, and whether or not it is possible to discover and monitor every such instance. snmp64_If_juniper_logical: MM6C96 snmp64_If_juniper_physical: WZ2AZC snmp64_If_juniper_VCP_interfaces: YZ42H71View0likes0CommentsSNMP 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.3Views0likes3Comments