Re: Junos Asymmetric Routing

[Ken Gilmour <ken.gilmour () gmail com>]

Hi Joe,

Interesting questions, Answers are below your questions:

On 28 May 2010 00:33, Joe Blanchard <jbfixurpc () gmail com> wrote:

> That would seem to be a good resolution (Firewall/NAT) . Aside from that,
> perhaps a load
> balancer for each segment might help?

Possibly but this will cost money to implement and there is no guarantee
that it will work.


> One question that comes to mind is why (if ISP2 is a backup) would valid
> traffic
> be using that route?

Several reasons, but the two main reasons are:

1. Some clients might find one path faster than another (e.g.
vpn.example.com vs vpn2.example.com). If they are on the same provider then
chances are that they will have better remote access that way.
2. If BGP fails we want all of our statically routed IP addresses to work
too, this is our solution to be able to guarantee connectivity to payment
processors (so quite important to ensure that we can make money)


> Unless maybe your loadbalancing using a DNS round robin perhaps to hit the
> second IP space or loadbalancing
> the 2 ISPs?

No round robin... This is the last resort if BGP fails


> Another "maybe" resolve would be to multi-home the application to that
> segment, i.e. 2 nics on the
> server, one on the primary network, the other on the secondary with
> appropriate Def.GWs, of course
> since there is little information on the infrastructure here this may not
> be possible.
> I suppose if one were to get really detailed about this, you could look
> into reverse routing using MAC, but
> theoretically that would/could open a whole other set of issues.

I can go extremely detailed offlist but there would be far too much
information to post to NANOG otherwise, and it would probably just annoy
people and result in flaming more than anything.


> Regards,
> Joe Blanchard
>
>
>
> Jian Gu 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 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