[126764] in North American Network Operators' Group
Re: Junos Asymmetric Routing
daemon@ATHENA.MIT.EDU (Jian Gu)
Fri May 28 16:49:32 2010
In-Reply-To: <AANLkTilxvSfEoFExm7_Udir9ohwllS-tQxZJmW928zWW@mail.gmail.com>
Date: Fri, 28 May 2010 13:49:10 -0700
From: Jian Gu <guxiaojian@gmail.com>
To: Ken Gilmour <ken.gilmour@gmail.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Then you should look at your IGP, right?
On Fri, May 28, 2010 at 8:09 AM, Ken Gilmour <ken.gilmour@gmail.com> wrote:
> Hi Jian,
>
> Yes sir that's what I thought too. The packets are being NATted (and I al=
so
> used a bit of DNAT for port forwarding to test the theory) but the result=
is
> the same.
>
> Regards,
>
> Ken
>
> On 27 May 2010 23:46, Jian Gu <guxiaojian@gmail.com> wrote:
>>
>> Wouldn't simply configure source NAT on firewall 2.2.2.1 resolve the
>> problem gracefully? when connection requests coming in through ISP2,
>> source NAT the incoming traffic's source IP with IPs on firewall
>> inside interface, that way when server replies, firewall 2.2.2.1 will
>> guarantee to receive the ACK because ACK traffic won't follow default
>> routing to ISP1.
>>
>> On Thu, May 27, 2010 at 4:27 PM, Ken Gilmour <ken.gilmour@gmail.com>
>> 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 understan=
d
>> > the
>> > problem but can't seem to think of a working solution (last solution l=
ed
>> > to
>> > the primary firewall hard crashing and then failing over after a commi=
t
>> > (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: =A0route 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 th=
is
>> > was
>> > a last ditch effort (putting both interfaces into one zone, effectivel=
y
>> > 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 a=
nd
>> > 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 BG=
P
>> > session failure we need to be able to use our statically routed IPs an=
d
>> > rely
>> > on someone else.
>> >
>> > Thanks!
>> >
>> > Ken
>> >
>
>
