SRX

We have a SRX320 with two ISPs connected to the ge-0/0/0 and ge-0/0/2 interfaces and trusted subnets connected to the ge-0/0/5 interface.

We use both ISPs for destination NATs to forward ports from the Internet to trusted subnets. To solve the problem with asymmetric NAT, for each ISP interface a separate routing-instance.

root@orn-gw-01> show configuration interfaces ge-0/0/0
description "ISP1";
unit 0 {
    family inet {
        address 95.78.251.27/24;
    }
}

root@orn-gw-01> show configuration interfaces ge-0/0/2
description "ISP2";
unit 0 {
    family inet {
        address 79.140.22.231/24;
    }
}

root@orn-gw-01> show configuration routing-instances
isp-1 {
    instance-type virtual-router;
    interface ge-0/0/0.0;
    routing-options {
        static {
            route 0.0.0.0/0 next-hop 95.78.251.254;
        }
    }
}
isp-2 {
    instance-type virtual-router;
    interface ge-0/0/2.0;
    routing-options {
        static {
            route 0.0.0.0/0 next-hop 79.140.22.1;
        }
    }
}

Routes from the default routing table are copied into ISP routing-instances using rib-groups.

root@orn-gw-01> show configuration routing-options
interface-routes {
    rib-group inet isp;
}
static {
    route 0.0.0.0/0 next-table isp-1.inet.0;
}
rib-groups {
    isp {
        import-rib [ inet.0 isp-1.inet.0 isp-2.inet.0 ];
    }
}

Also, we use both ISPs for source NATs. We have configured a simple filter for that.

root@orn-gw-01> show configuration firewall filter output-isp
term to-isp-2 {
    from {
        source-address {
            10.110.12.0/24;
        }
    }
    then {
        routing-instance isp-2;
    }
}
term default-isp {
    from {
        source-address {
            0.0.0.0/0;
        }
    }
    then {
        routing-instance isp-1;
    }
}
term default-allow {
    then accept;
}

root@orn-gw-01> show configuration interfaces ge-0/0/5.10
vlan-id 10;
family inet {
    filter {
        input output-isp;
    }
    address 10.110.10.1/24;
}

Everything works fine, but there is no basic failover for the Internet access. We would like that routes switches to the ISP2 provider interface if there are no Internet access over the ISP1 provider.

To do this, we configured probes in the real-time performance monitoring service.

root@orn-gw-01> show configuration services rpm
probe isp-1 {
    test google {
        probe-type icmp-ping;
        target address 8.8.8.8;
        probe-count 3;
        probe-interval 5;
        test-interval 10;
        thresholds {
            successive-loss 3;
            total-loss 3;
        }
        destination-interface ge-0/0/0.0;
        next-hop 95.78.251.254;
    }
}
probe isp-2 {
    test google {
        probe-type icmp-ping;
        target address 8.8.8.8;
        probe-count 3;
        probe-interval 5;
        test-interval 10;
        thresholds {
            successive-loss 3;
            total-loss 3;
        }
        destination-interface ge-0/0/2.0;
        next-hop 79.140.22.1;
    }
}

Then we added actions in the ip monitoring service that changes a preffered routes for routing-instances.

root@orn-gw-01> show configuration services ip-monitoring
policy isp-1 {
    match {
        rpm-probe isp-1;
    }
    then {
        preferred-route {
            routing-instances isp-1 {
                route 0.0.0.0/0 {
                    next-hop 79.140.22.1;
                }
            }
        }
    }
}
policy isp-2 {
    match {
        rpm-probe isp-2;
    }
    then {
        preferred-route {
            routing-instances isp-2 {
                route 0.0.0.0/0 {
                    next-hop 95.78.251.254;
                }
            }
        }
    }
}

But it does not work. If probe fails configured action is applied.

root@orn-gw-01> show services ip-monitoring status

Policy - isp-1 (Status: PASS)
  RPM Probes:
    Probe name             Test Name       Address          Status
    ---------------------- --------------- ---------------- ---------
    isp-1                  google          8.8.8.8          PASS
  Route-Action:
    route-instance    route             next-hop         state
    ----------------- ----------------- ---------------- -------------
    isp-1             0.0.0.0/0         79.140.22.1      NOT-APPLIED

Policy - isp-2 (Status: FAIL)
  RPM Probes:
    Probe name             Test Name       Address          Status
    ---------------------- --------------- ---------------- ---------
    isp-2                  google          8.8.8.8          FAIL
  Route-Action:
    route-instance    route             next-hop         state
    ----------------- ----------------- ---------------- -------------
    isp-2             0.0.0.0/0         95.78.251.254    APPLIED

But there is no specified route in the routing-instance.

root@orn-gw-01> show route table isp-2.inet.0 exact 0.0.0.0/0

isp-2.inet.0: 30 destinations, 32 routes (30 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[Static/5] 01:17:19
                    > to 79.140.22.1 via ge-0/0/2.0

We suppose that our mistake is that ip monitoring is trying to install a route to the non-related inteface for that routing-instance. Probably, it would be right to use next-table in another routing-instance as an action. But ip monitoring can do only next-hop.

How else can we solve this problem?

You can try to change the routing-instance type to forwarding and check.

Please follow the below document: 

https://kb.juniper.net/InfoCenter/index?page=content&id=KB22052&actp=METADATA

Hi jalaj. Thank you for reply.

We tried several times to switch routing instances from virtual router to frowarding, but each time lost control on the device. As it turned out, to apply the configuration correctly, it is necessary to reboot the device after the commit.

As you advice, with forwarding routing instances ip monitoring works perfectly.

Hey,

first you forgot to activate RIB Groups on routing instances

set routing-instances isp-1 routing-options interface-routes rib-group inet isp
set routing-instances isp-2 routing-options interface-routes rib-group inet isp

Also you write

"Also, we use both ISPs for source NATs. We have configured a simple filter for that."

I hope the config is different from what you mean.  Cus this is NOT source NAT config... 🙂

avanoc,

I have a few questions for you and your setup.

Would you mind sharing your config after your changes? I am confused on your routing-instances on using the type as "forwarding".

We have a very similar setup as we had 2 ISPs and destination NATs going to both. We are also wanting to perform failover with ip-monitoring but didn't see any option for next-table; only next-hop. We were running into the asyncronous NAT issue where the reverse route lookup for something that came in on the secondary ISP would only be performed in the default routing instance and then use the source NAT for the primary ISP. Filter based forwarding would not effect this. Everything we have read is to implement 2 Zones, 1 for each ISP, and use another routing-instance but it has to be the type of "virtual-router".

How are you attaching your interface to the forwarding type routing-instance? Configuration options in Space, GUI, don't allow you to select an interface. But in the CLI I see that you can. Maybe this is a limitation of Space and the GUI?

dwolcot1, hi.

Unfortunately, we didn't manage to configure the SRX320 for automatic failover without problems with asymmetric NAT. To make ISP failover works properly you need to use forwarding routing-instances; to avoid problems with asymmetric NAT you need to use virtual-router routing-instances. One excludes the other. Therefore, I assume that case is impossible.

We decided that automatic failover to the backup ISP (source NAT) is more important for us, so our configuration uses forwarding routing-instances.

> show configuration interfaces ge-0/0/0
description "ISP Primary";
unit 0 {
    family inet {
        address 95.78.251.27/24;
    }
}

> show configuration interfaces ge-0/0/1
description "ISP Backup";
unit 0 {
    family inet {
        address 79.140.22.231/24;
    }
}

> show configuration routing-instances
isp-1 {
    instance-type forwarding;
    routing-options {
        static {
            route 0.0.0.0/0 {
                next-hop 95.78.251.254;
                qualified-next-hop 79.140.22.1 {
                    preference 100;
                }
            }
        }
    }
}
isp-2 {
    instance-type forwarding;
    routing-options {
        static {
            route 0.0.0.0/0 {
                next-hop 79.140.22.1;
                qualified-next-hop 95.78.251.254 {
                    preference 100;
                }
            }
        }
    }
}

> show configuration routing-options
interface-routes {
    rib-group inet isp;
}
static {
    route 0.0.0.0/0 next-table isp-1.inet.0;
}
rib-groups {
    isp {
        import-rib [ inet.0 isp-1.inet.0 isp-2.inet.0 ];
    }
}

> show configuration services ip-monitoring
policy isp-1 {
    match {
        rpm-probe isp-1;
    }
    then {
        preferred-route {
            routing-instances isp-1 {
                route 0.0.0.0/0 {
                    next-hop 79.140.22.1;
                }
            }
        }
    }
}
policy isp-2 {
    match {
        rpm-probe isp-2;
    }
    then {
        preferred-route {
            routing-instances isp-2 {
                route 0.0.0.0/0 {
                    next-hop 95.78.251.254;
                }
            }
        }
    }
}

> show configuration services rpm
probe isp-1 {
    test google {
        probe-type icmp-ping;
        target address 8.8.8.8;
        probe-count 3;
        probe-interval 5;
        test-interval 10;
        thresholds {
            successive-loss 3;
            total-loss 3;
        }
        destination-interface ge-0/0/0.0;
        next-hop 95.78.251.254;
    }
}
probe isp-2 {
    test google {
        probe-type icmp-ping;
        target address 8.8.8.8;
        probe-count 3;
        probe-interval 5;
        test-interval 10;
        thresholds {
            successive-loss 3;
            total-loss 3;
        }
        destination-interface ge-0/0/1.0;
        next-hop 79.140.22.1;
    }
}

I had a thought. What about instead of using ip-monitoring for failover using event-options to run a command that activates a default static route configured to go to your isp2 routing-instance? Do you think this would work?

user@srx300# show event-options
policy failover {
    events ping_test_failed;
    then {
        execute-commands {
            commands {
                "activate routing-options static route 0.0.0.0/0 next-table isp2.inet.0";
            }
        }
    }
}