Junos Asymmetric Routing

Jensen Tyler JTyler at fiberutilities.com
Fri May 28 15:06:39 UTC 2010


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 at ttec.com]
Sent: Friday, May 28, 2010 9:14 AM
To: Ken Gilmour
Cc: nanog at 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
>
>





More information about the NANOG mailing list