Open for Voting
over 1 year ago

Multiple IP Address polling support for a single node

It is taken from a feature request from Questionario. By the way we need this badly.

Re: Feature Request: Multiple IPs per Node

Hi, right now I have several nodes double and triple for monitoring purposes.

One would be the standard Management VLAN IP, another for OSPF and another for a backup tunnel (which is constantly up)

now the management IP is reachable as long as one of these still work but I want to be notified if either of them goes down as well.

I dont need to get performance reports about each single IP but still get notifications if the IP on the node is unreachable!

So it would be a nice enhancement to simply add more "secondary" IPs to nodes without having to create another object (Its not about the licenses but about the manageability).

Parents
  • Loopback is not a solution for our situation.

    Let's say we are using a VPN device on our edge office. This edge VPN has two connections. Primary one is ADSL and the other one is 3G for backup. Both have dynamic IP addresses (unfortunately).


    • We can't monitor it with loopback IP because the tunnel may go down but the device can be up and running. And we have to know the root cause.
    • We can't monitor it with static IP because the IP can be changed (Dynamic). Of course we prefer static IP but not every static IP is cheap on some countries. We are working on a dynamic IP address solution on our side. But that's another story.
    • Also the static IP can be up but the loopback (VPN tunnel IP) is down. Also we can't monitor the static IP because it can be up but the loopback (VPN tunnel IP) is down. We need to monitor tunnel as well.
    • On some situations the static IP address is up and the interface (VPN tunnel IP) also seems up but it is actually down. You can't ping the VPN tunnel interface (Juniper SRX Series have that bug). And opening a CASE is not always a solution emoticons_happy.png.
    • In addition to these we need the availability of each connection (both primary and secondary). That's important for us to decide which connection is better.
Comment
  • Loopback is not a solution for our situation.

    Let's say we are using a VPN device on our edge office. This edge VPN has two connections. Primary one is ADSL and the other one is 3G for backup. Both have dynamic IP addresses (unfortunately).


    • We can't monitor it with loopback IP because the tunnel may go down but the device can be up and running. And we have to know the root cause.
    • We can't monitor it with static IP because the IP can be changed (Dynamic). Of course we prefer static IP but not every static IP is cheap on some countries. We are working on a dynamic IP address solution on our side. But that's another story.
    • Also the static IP can be up but the loopback (VPN tunnel IP) is down. Also we can't monitor the static IP because it can be up but the loopback (VPN tunnel IP) is down. We need to monitor tunnel as well.
    • On some situations the static IP address is up and the interface (VPN tunnel IP) also seems up but it is actually down. You can't ping the VPN tunnel interface (Juniper SRX Series have that bug). And opening a CASE is not always a solution emoticons_happy.png.
    • In addition to these we need the availability of each connection (both primary and secondary). That's important for us to decide which connection is better.
Children
  • I've migrated to monitoring BOTH nodes and interfaces.  Monitoring interfaces is important for detecting the problem with one circuit in an NxT1(E1) solution, and I monitor tunnels (st0 logical interfaces) and sometimes VLAN logicals.  As we know, the ability to ping and whether an interface is up is two different things (since the path affects pings).  Also, latency measurement requires a ping or RPM / IPSLA.  My use case is when running HSRP.  Cisco does not list the virtual interface as an interface, so I have to configure a virtual IP node.  Normally pinging the two physical routers is enough, but a VLAN problem can screw up the virtual IP so we monitor that to be safe.  Junos 11.2 for SRX-100-650 implemented a netscreen-style "Track-IP" function: set services ip-monitoring policy POLICY-NAME match rpm-probe PROBE-NAME.

    Note: Our clustered Netscreens will put clustered interfaces in standby state, and NPM shows this as an interface error.  I probably should open a case on that.

    -=Dan=-