Junos OS

Expand all | Collapse all

Services RPM and IP-Monitoring Configuration for Dual ISP Failover

  • 1.  Services RPM and IP-Monitoring Configuration for Dual ISP Failover

    Posted 01-25-2021 13:13
    Good Evening!

    I have looked near everywhere for a solution to this problem however it doesnt seem anyone else has had the same issue.

    We have installed a solution for a client that has dual ISPs connected to an SRX300. We want the primary circuit to failover to the secondary circuit should the primary circuit not be able to ping google.

    Please see our below config:

    test PRI_WAN_Ping {
    probe-type icmp-ping;
    target address 8.8.8.8;
    probe-count 15;
    probe-interval 1;
    test-interval 3;
    thresholds {
    total-loss 10;
    }
    destination-interface ge-0/0/5
    }
    }

    IP-Monitoring config:
    policy Wan_Failover {
    match {
    rpm-probe PRI_WAN;
    }
    then {
    preferred-route {
    route 0.0.0.0/0 {
    next-hop xxx.xxx.xxx.xxx; (this is the secondary ISP GW)
    }
    }
    }
    }

    We have a default route sending all traffic to the primary ISP GW. The Primary ISP IP Address is configured on ge-0/0/5. The secondary ISP IP is configured on Ge-0/0/0. When we check the session flow with our destination prefix set to 8.8.8.8 we see the following:

    Session ID: 6645, Policy name: self-traffic-policy/1, Timeout: 50, Valid
    In: xxx.xxx.xxx.xxx/14 --> 8.8.8.8/50;icmp, Conn Tag: 0x0, If: .local..0, Pkts: 1, Bytes: 28,
    Out: 8.8.8.8/50 --> xxx.xxx.xxx.xxx/14;icmp, Conn Tag: 0x0, If: ge-0/0/0.0, Pkts: 0, Bytes: 0,
    Total sessions: 15

    Both xxx.xxx.xxx.xxx in the above session are the primary ISP interface address but for some reason the reply is coming back on interface ge-0/0/0 which is the secondary line! Why is this? The secondary line is currently the active line of the two too even though the primary is up and working.

    This is the current status of IP Monitoring:
    RPM Probes:
    Probe name Test Name Address Status
    ---------------------- --------------- ---------------- ---------
    PRI_WAN PRI_WAN_Ping 8.8.8.8 FAIL
    Route-Action:
    route-instance route next-hop state
    ----------------- ----------------- ---------------- -------------
    inet.0 0.0.0.0/0 xx.xx.xx.xx (secondary ISP LINE) APPLIED


    Any ideas why the return packets are coming in on the wrong interface and why our device will switch to use the primary line as opposed to the secondary?

    Any help would be amazing, 

    thanks!

    ------------------------------
    Ryan Todd
    ------------------------------


  • 2.  RE: Services RPM and IP-Monitoring Configuration for Dual ISP Failover

    Posted 01-26-2021 05:38
    Hi Todd,

    I would try adding the gateway (next-hop) for your primary internet connection on ge-0/0/5 to the test configuration:
    test PRI_WAN_Ping {
    	probe-type icmp-ping;
    	target address 8.8.8.8;
    	probe-count 15;
    	probe-interval 1;
    	test-interval 3;
    	thresholds {
    		total-loss 10;
    	}
    	destination-interface ge-0/0/5;
    	next-hop xx.xx.xx.xx;
    }
    ​

    Best regards,
    Steven



    ------------------------------
    Steven Scholte
    ------------------------------



  • 3.  RE: Services RPM and IP-Monitoring Configuration for Dual ISP Failover

     
    Posted 01-26-2021 05:40
    I assume we are implementing this recommendation from the kb.

    https://kb.juniper.net/InfoCenter/index?page=content&id=KB17223

    We will need to check the filter and routing instance related configuration as well.

    ------------------------------
    Steve Puluka BSEET - Juniper Ambassador
    IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
    http://puluka.com/home
    ------------------------------



  • 4.  RE: Services RPM and IP-Monitoring Configuration for Dual ISP Failover

    Posted 01-26-2021 09:58
    Hi There,

    Don't rule out that the ISP's might be engineering the traffic. We've experienced this problem a number of times and it can be a bear to track down.

    For us, even though the proper addresses and routes are advertised (confirmed with ISP and looking-glass) some of the ISP's send the traffic back to us via the wrong route. This is done for a variety of reasons.

    You could consider adding another filter for returning traffic to send it to the proper routing table.

    We were lucky to have a genius come in and help us set up our fail overs using routing policies with the imported default route from our ISPs. That way, if an ISP goes down and stops sending the default route, that is removed from the routing table and the secondary ISP route takes over automatically.

    Good Luck,
    JimD,



    ------------------------------
    JimD,
    ------------------------------