View Only
last person joined: 7 days ago 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.
  • 1.  IP-monitoring multiple route failover

    Posted 11-28-2014 05:38

    I have two possible exits from my LAN to my data center. One is a point-to-point path, and the other is an MPLS path.

    The P2P is supposed to be primary for all non-voice data traffic with failover to the MPLS; the MPLS exit is primary for all voice-related traffic. The secondary path is just opposite.


    I've been reading on ip-monitoring with route failover. Since there are multiple subnets involved, and all the routing is static, is it possible/required that I have a next hop for each network? Because these aren't default routes, but specific routes.


    Does this technology work for that situation?




  • 2.  RE: IP-monitoring multiple route failover

    Posted 11-28-2014 06:02

    From your description, I think you could use the qualified next hop on your static routes to accomplish your desired failovers.  With this option you simply designate the alternate next hop on the static route.  And when the primary next hop is not available this will automatically revert to the qualified next hop as a backup path.


  • 3.  RE: IP-monitoring multiple route failover

    Posted 11-28-2014 11:21
    From a routing perspective, that is what I plan to do. However, the routers that have the default gateways are not ours. So, in the case of the P2P, it seems that if the circuit on that router's wan fails, my qualified next hop wouldn't kick in. Only if the direct connection fails would that solution work.

    That's why I thought the IP monitoring might be necessary.

  • 4.  RE: IP-monitoring multiple route failover

    Posted 11-29-2014 05:58

    Sorry I misunderstood the scenario.  I think then you are correct that ip monitoring will be the only option.  This is the kb I think is closest for you.



    Since this is not a default route you will essentially need one RPM for every route that needs to change.  So if the table is large it can get big.


    There is a function to bring down the interface in the RPM instead of changing the route. This would then trigger your qualified next hop for the traffic and all the routes would failover.


    But when I tried to use that function I discovered that you cannot automatically restore of the interface.  I could only restore service manually on the device.  This is a function I wish we had for this type of scenario.


  • 5.  RE: IP-monitoring multiple route failover

    Posted 11-30-2014 11:15

    Thank you. I'll look into this. I had a feeling that the RPM would be needed for each. One question more: the reason for this is, as I stated, if the WAN circuit fails. But would you still implement the qualified next-hop as well, to cover router failure, or is that unnecessary?


    I appreciate the followup!

  • 6.  RE: IP-monitoring multiple route failover
    Best Answer

    Posted 12-01-2014 18:43

    I would think qualified next hop would be redundent in this scenario since the monitoring failover would work in the case of the router failure anyway.

  • 7.  RE: IP-monitoring multiple route failover

    Posted 12-02-2014 16:47
    Side comment: I can't find it, but to your knowledge, is there any way of ip-monitoring with route failover with ex switches?

  • 8.  RE: IP-monitoring multiple route failover

    Posted 12-02-2014 18:30

    The best place to check for platform compatibility is in the Feature Explorer on the documentation site.


    IP monitoring with route failure looks like it only has branch SRX as the supported platforms.



    Screen Shot 2014-12-02 at 9.26.30 PM.png



  • 9.  RE: IP-monitoring multiple route failover

    Posted 01-05-2015 19:33

    Thank you for the reply. I did implement this just as you said. Fun part is that the "other end" is a cisco 3750, and the failover path between the two endpoints is an mpls cloud on one side, and a p2p link on the other. Seems to be working at this point. Will test a few times to be sure. The rpm with ip-monitoring filles exactly the failover strategy.