When deploying dual‑ISP or multi‑ISP connectivity on Junos platforms, Real‑Time Performance Monitoring (RPM) and IP‑monitoring can be used to achieve intelligent failover based on real reachability rather than interface state.

However, when static route preferences, qualified‑next-hop, and IP‑monitoring are used together, routing behavior can become unpredictable—particularly during failback.

In a scenario with two ISP uplinks (ISP1 primary, ISP2 backup) and both route‑preference and IP‑monitoring with RPM probes are configured, the firewall/router successfully fails over to ISP2 when ISP1 becomes unreachable.

However, after ISP1 becomes stable again, traffic does NOT return to ISP1, even though the RPM probe for ISP1 shows a healthy state.

Example Configuration

set routing-options static route 0.0.0.0/0 next-hop <ISP1>
set routing-options static route 0.0.0.0/0 qualified-next-hop <ISP2> preference 20

IP-monitoring

set services ip-monitoring policy GE1 match rpm-probe Failover1
set services ip-monitoring policy GE1 then preferred-route route 0.0.0.0/0 next-hop <IP>——— ISP2 next hop
set services ip-monitoring policy GE1 then preferred-route route 0.0.0.0/0 preferred-metric 4

When ISP1 fails, traffic correctly moves to ISP2. The IP‑monitoring preferred-route injects a new default route with higher priority (i.e lower preference) than the static default. According to Juniper documentation, IP‑monitoring always injects a route with higher priority than the manually configured static route. This injected route overrides the primary ISP1 route. See IP Monitoring Overview.

Recovery

• IP‑monitoring may still have an active preferred-route installed.
• The system may end up with two competing defaults via ISP2:
  1. One from qualified-next-hop
  2. One injected by IP‑monitoring

Because the IP‑monitoring‑injected route has lower preference (i.e higher priority), it continues to pass traffic—even after ISP1 is healthy again. Hence, the device becomes “stuck” on ISP2.

To prevent the above scenario, use the following recommendations: 

1. Keep a plain static default route only for ISP1.

2. Use IP‑monitoring to inject (or withdraw) the ISP2 default route.  IP‑monitoring will insert the failover route to ISP2 when RPM fails or remove it (or restore the primary route) when the probe recovers.