[126727] in North American Network Operators' Group
Re: Junos Asymmetric Routing
daemon@ATHENA.MIT.EDU (Ricardo Tavares)
Thu May 27 19:59:35 2010
In-Reply-To: <AANLkTimilon0PpfIqi4CykORni4WwwX5llosxoa5G212@mail.gmail.com>
Date: Thu, 27 May 2010 20:59:19 -0300
From: Ricardo Tavares <curupas@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
Hi Ken,
Not sure if I correctly undestand you but default route its the route
that the packet must follow if it do not have a specific route for the
destination, so, if the next-hop for the source IP (3.3.3.3) is not in
the route table then the packet will follow the default route (ISP1).
So, this behavior is correct. Just for troubleshooting purpose install
a static route like:
set routing-option static route 3.3.3.0/24 next-hop
<the-correct-gateway-address> (ISP2)
If this works fine then verify the route table, are you using BGP to
receive such routing info? If you are not filtering the update maybe
the sender is.
Regards,
Ricardo
On Thu, May 27, 2010 at 8: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 pho=
ne
> to the Juniper Devs after about 4 hours with no result. They understand t=
he
> 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 alway=
s
> active. Client comes in on ISP1's link, traffic goes back out on ISP1s li=
nk.
> 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 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 th=
en
> intercept the packets if they are destined for the wrong interface and se=
nd
> 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 stoppe=
d
> 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 r=
ely
> on someone else.
>
> Thanks!
>
> Ken
>
--=20
Rio de Janeiro Ciclopata! Cora=E7=E3o Brasiliense e Floripano!
Twitter: http://www.twitter.com/curupas
Orkut: http://www.orkut.com.br/Main#Profile?rl=3Dmp&uid=3D69155823531129414=
69
Vai Encarar? http://www.vaiencarar.com.br
