rrichter ✭✭✭✭✭

It is a universal poller that I added to watch the probes, as that's what triggers the ip-monitoring policy on the Juniper router to turn on the interface to the metered internet circuit. To make it useful I also added a 2nd universal poller for readable labels 1.3.6.1.4.1.2636.3.7.1.3.1.22 (jnxPingResultsOwnerIndex). Once…

I found an OID that can be used to monitor JunOS Probes: 1.3.6.1.2.1.80.1.3.1.7 (listed as pingResultsProbeResponses) With that said, to answer my own question, every node we've setup that's normally down but is up in case of a failover event has been named to [FAILOVER] (Rest of Node Name). The idea being that if one of…

The setup is similar to Cisco IP SLA. We're actually using Juniper ip monitoring. Juniper Networks - [SRX] Example - IP Monitoring with route fail-over configuration and behavior - Knowledge Base

So I reran the script as Admin and it added the groups successfully. For my purposes this works, as I now have hundreds of dependency groups to go create. For reference, I can create groups and dependencies in the Web UI, but with what I'd need to do it'd be way too time consuming. I've attached the InformationService log…

I had this issue as well, and changing the interface downtime resource from 1 week to 24 hours it looks normal again. Perhaps there's a bug with it loading the interface status for the last week?

Just for reference, this error is showing up in the ESI.BusinessLayer.Log file. We're not sure if it's relevant or not, but if it is it's worth pointing out that the integration module is mostly working, but they payloads don't include state changes like they should. Does anyone know how we'd go about finding this null…