RE: Junos Asymmetric Routing

28 May 2010

      Sorry ken I sent the wrong link. Below is the correct one:

Configuration Example: Configure J-Series/SRX for dual ISP without dynamic routing protocols.
http://kb.juniper.net/index?page=content&id=KB15545&actp=search&searchid=1263410684167&smlogin=true

Still note virtual-router instance is needed not forwarding instance as in this guide.

Jensen Tyler
Network Engineer
Fiberutilities Group, LLC

-----Original Message-----
From: Jensen Tyler [mailto:JTyler@fiberutilities.com]
Sent: Friday, May 28, 2010 10:07 AM
To: Ken Gilmour
Cc: nanog@nanog.org
Subject: RE: Junos Asymmetric Routing

When you set-up your virtual-instance, was your ISP2 interface a member of that instance? I have a working setup that ran on a J-series running 9.6 something.

This is a Juniper guide I used but it was a little bit different and didn't work for me.

http://www.juniper.net/us/en/local/pdf/day-one-guides/7100110-en.pdf

I used below:

--Routing instance:
routing-instances {
    DSL {
        instance-type virtual-router;
        interface ge-0/0/1.0; // <-- Most important part - ISP2 Interface must be a member to get correct incoming context.
        routing-options {
            static {
                route 0.0.0.0/0 next-hop 172.24.1.1; // ISP2 next hop
            }
        }
    }
}

--Firewall filter:
firewall {
    filter DSL {
        term DSL {
            from {
                address {
                    192.0.1.210/32; // This is the address that will go into the virtual router (ISP2 addresses should go here)
                }
            }
            then {
                count source-route;
                log;
                routing-instance DSL;
            }
        }
        term default {                          // Everything else uses default routing table.
            then {
                count defualt-counter;
                log;
                accept;
            }
        }
    }
}
Jensen Tyler
Network Engineer
Fiberutilities Group, LLC

-----Original Message-----
From: Joe Maimon [mailto:jmaimon@ttec.com]
Sent: Friday, May 28, 2010 9:14 AM
To: Ken Gilmour
Cc: nanog@nanog.org
Subject: Re: Junos Asymmetric Routing

Firewalls that can route and service properly multiple "untrusts"?

Good luck. Hit or miss. Constant flux.

Place a router in front of it and that will get you a ways there.

Ken Gilmour wrote:
...
Hi all,
I have a very peculiar situation here that i seem to have difficulty
explaining in such a way for people to understand. I just got off the phone
to the Juniper Devs after about 4 hours with no result. They understand the
problem but can't seem to think of a working solution (last solution led to
the primary firewall hard crashing and then failing over after a commit
(which also makes me wonder what made the primary crash and not the
secondary)). I am wondering if there is anyone "creative" on the list who
has encountered and worked around this problem before...
Here goes *sigh*
ISP1 - 1.1.1.0/24
ISP2 - 2.2.2.0/24
ISP1 is the default gateway, ISP2 is a backup provider but which is always
active. Client comes in on ISP1's link, traffic goes back out on ISP1s link.
Client comes in on ISP2's link (non default gateway) but for some reason,
the packets seem to be going back out through the link for ISP1.
So look at it this way:
SYN comes from client at 3.3.3.3 aimed at 2.2.2.2, packet is received by the
firewall. Firewall sends a SYN/ACK but the firewall at 1.1.1.1 sees it in
TCPDump, the firewall at 2.2.2.1 never sees it.
Here's a log snippet (I can send you more if you need:
May 27 21:38:49 21:38:48.1509569:CID-1:RT:  route lookup: dest-ip 3.3.3.3 *orig
ifp reth3.0* *output_ifp reth2.0* orig-zone 19 out-zone 19 vsd 3
You will see that the orig and out zones are the same zone, however this was
a last ditch effort (putting both interfaces into one zone, effectively
creating a swamp).
Our current (non-preferred) solution is to put match-all rules on our
Catalyst 6513s and put both providers into a swamp and the switch will then
intercept the packets if they are destined for the wrong interface and send
them out the right one based on a bunch of boolean.
We've tried setting up a virtual instance on the offending interface and a
firewall filter, but this had little to no effect (at one point it stopped
passing the packets to the end machine altogether). We're using small SRX
650ies. Why do we want to do it this way you ask? In the event of a BGP
session failure we need to be able to use our statically routed IPs and rely
on someone else.
Thanks!
Ken