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
MalibuKenAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

dpk_walCommented:
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.
MalibuKenAuthor Commented:
Thanks dpk_wal,
I will be implementing tomorrow and report back.
MalibuKenAuthor Commented:
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.
Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

dpk_walCommented:
Thank you for the update; please post your results and we should be able to nail the problem! :)
MalibuKenAuthor Commented:
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!
dpk_walCommented:
attachments are missing.
MalibuKenAuthor Commented:
I'll try again.
status.jpg
status2.jpg
MalibuKenAuthor Commented:
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!
dpk_walCommented:
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.
MalibuKenAuthor Commented:
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
MalibuKenAuthor Commented:
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?
MalibuKenAuthor Commented:
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!
dpk_walCommented:
Same thing is detailed in KB article http://kb.juniper.net/KB22052

By default all traffic going out ISP1 routing instance would take 173.1.1.1 as next-hop and the installed next-hop in ISP2 routing instance would be 212.44.1.1.

When 173.1.1.1 is unreachable, then the next-hop in ISP1 routing instance should change to ISP2 next-hop 212.44.1.1.
If we change next-hop in ISP2 routing-instance to 212.44.1.1 then we do no good as the default route in ISP2 routing-table was already 212.44.1.1.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
MalibuKenAuthor Commented:
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!
dpk_walCommented:
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
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Network Architecture

From novice to tech pro — start learning today.