Link to home
Start Free TrialLog in
Avatar of MalibuKen
MalibuKen

asked on

Need review of Juniper SRX210 config for dual-WAN setup

Hi All,

I've been a member for years, but I don't think I've ever posted a question.  I'm experienced with Juniper SSG firewalls and now I need to implement some SRX210's and 220's.  I'm still learning JunOS and need some help validating a configuration I want to place at a small site.

I'm trying to get it right the first time, but I can't create a dual-WAN network in my main office lab, so I have only been able to test one leg, which works fine.  I don't have access to the site after hours, so I need to install it during working hours and don't want to be troubleshooting too much on the fly.

My goal is to have ISP2 be a standby.  I want fail-over to occur not just if the link goes down, but if I cannot reach a reliable IP address on the Internet (my example uses 8.8.8.8 for now).  Then I want to fail back when the probe succeeds on ISP1.  In addition, I will be creating site-to-site VPN tunnels with other SRX's soon after, so my dual-WAN config needs to support that.

The configuration I came up with is a conglomeration of examples I've found searching online.  It uses separate routing instances and security zones for each ISP.  I've attached a generic diagram and matching config file.

Questions I have:

1.  In my lab network, I couldn't get out to the Internet until I changed the static route setting using the "next-table" option.  Would like to know why and whether that affects other areas of the config where static routes are called out.

2.  The idea of using separate routing instances and zones looks like it complicates things, but at the same time it makes sense to have things modular.  Is this a good approach, or should I be using a simpler approach?

3.  And last but not least, will it work as is?  If not, what needs to change?

Thanks in advance!
DualWAN.jpg
DualWAN.txt
Avatar of dpk_wal
dpk_wal
Flag of India image

The configuration is correct have a look at KB below and modify few parameters like successive-loss total-loss, probe-count/interval, KB explains them, I think it should work:
http://kb.juniper.net/InfoCenter/index?page=content&id=KB25052

Please implement and update.

Thank you.
Avatar of MalibuKen
MalibuKen

ASKER

Thanks dpk_wal,
I will be implementing tomorrow and report back.
Just to update you on how it went - I put the SRX210 in place, but didn't have enough time to troubleshoot properly.  I couldn't get it to fail over.  My RPM settings are:

    probe-count  5
    probe-interval  3
    test-interval  5

I disconnected the uplink on the primary twice.  The first time I waited about 2 minutes, the second time about 5 minutes.  The settings I have should take a maximum of 35 seconds I believe.

Unfortunately, I didn't have a session running to watch the ip-monitor status, so I don't have any information there.

But I can test remotely now during off hours by changing a probe target IP to one I can control and then troubleshoot.  Will update this post when I have results.
Thank you for the update; please post your results and we should be able to nail the problem! :)
I changed the probe for ISP1 to ping one of my other Juniper firewall WAN interfaces.  Then I removed the ping service from the interface.  The ip-monitor status picked it up and changed the route action to "Applied" for the ISP2 route instance.  However, I was remoted in to a workstation on the LAN (I love ScreenConnect!) and my tracert command still goes out the ISP1 gateway.  I'm attaching the results of the ip-monitor status command (status.jpg).

Then when I turn the ping service back on my firewall that I was probing, the tests show a "Pass" status, but neither routing instance shows as "Applied".  See attachment status2.jpg.

Any ideas?
Thanks!
attachments are missing.
I'll try again.
status.jpg
status2.jpg
dpk_wal,
Can you review the screenshots and let me know if you have any ideas what's wrong or what I can try to narrow down the cause?
Thanks!
Hi MalibuKen,

Sorry for the delay in responding; the probe results are not helping much.

Can you please send the updated and masked config please.

I would try and replicate and report back.

Thank you.
dpk_wal,

See attached config.  The only change was the probe parameters.  I'm wondering if it has to do with the routing-options stanza:

routing-options {
    static {
        route 0.0.0.0/0 next-table ISP1.inet.0;
    }
    rib-groups {
        ISP1-to-ISP2 {
            import-rib [ ISP1.inet.0 ISP2.inet.0 ];
        }
        ISP2-to-ISP1 {
            import-rib [ ISP2.inet.0 ISP1.inet.0 ];
        }
    }
}


When I originally had my config in my lab (which only had one WAN connection) I had the static route called out with "next-hop 1.1.1.2".  No traffic could get out to the Internet with it like that.  I found an example online where the person used the "next-table" option, so I tried that and it worked.  I don't understand why the original didn't work or why one would use the "next-table" instead.  And it makes me wonder if the "next-hop" statements in the "routing-instances" stanza would have similar issues.

Thanks!
DualWanMod.txt
I now have a dual-ISP test network and have placed my configuration on it.  Still getting same results.  I really think the key is in why my static route doesn't work using the "next-hop" option in my routing-options stanza.  I tried replacing all the static routes statements in the config with "next-table ISP1(or 2).inet.0" but got a syntax error on commit.

Any ideas or suggestions for me to try?
Okay, I think I have success, but I don't understand why.  Most of my config came from  this post.  In his "step 5" he defines his ip-monitoring policies:

policy track-isp1 {
    match {
        rpm-probe probe-isp1;
    }
    then {
        preferred-route {
            routing-instances ISP1 {
                route 0.0.0.0/0 {
                    next-hop 212.44.1.1;
                }
            }
        }
    }
}
policy track-isp2 {
    match {
        rpm-probe probe-isp2;
    }
    then {
        preferred-route {
            routing-instances ISP2 {
                route 0.0.0.0/0 {
                    next-hop 173.1.1.1;
                }
            }
        }
    }
}

In his first stanza, I followed the logic as saying "if ISP1 probe test is a match (failed) then change the preferred route to routing-instance ISP1".  This didn't make sense.  I thought it should change the routing preference to ISP2, so I changed the second part in my config (for both policies).

Well, I finally decided to change to how he had it and now it seems to work.

Can anyone help explain the logic on his?

Thanks!
ASKER CERTIFIED SOLUTION
Avatar of dpk_wal
dpk_wal
Flag of India image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
dpk_wal,

Thanks, I understand it now.  I was thinking the the ip-monitoring policy was going to replace which routing instance would be used, but as you explained and linked, it is just modifying the default route within the particular instance.

A final question - on my routing-options stanza, I had to use the "next-table" option instead of "next-hop" to get traffic out from the LAN?  Why is that?  Is it because of the way I have structured the routing instances?

Thanks!
I think as we are going between the routing instance next-table worked  than next-hop.

Here are details on next-hop for static routes:
http://www.juniper.net/techpubs/en_US/junos14.2/topics/reference/configuration-statement/static-edit-routing-options.html