nanog mailing list archives
Re: Junos Asymmetric Routing
From: Ken Gilmour <ken.gilmour () gmail com>
Date: Fri, 28 May 2010 09:09:58 -0600
Hi Jian, Yes sir that's what I thought too. The packets are being NATted (and I also 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 thephoneto the Juniper Devs after about 4 hours with no result. They understandtheproblem but can't seem to think of a working solution (last solution ledtothe 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 isalwaysactive. Client comes in on ISP1's link, traffic goes back out on ISP1slink.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 bythefirewall. 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*origifp 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 thiswasa 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 willthenintercept the packets if they are destined for the wrong interface andsendthem out the right one based on a bunch of boolean. We've tried setting up a virtual instance on the offending interface andafirewall filter, but this had little to no effect (at one point itstoppedpassing 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 andrelyon someone else. Thanks! Ken
Current thread:
- Re: Junos Asymmetric Routing, (continued)
- Re: Junos Asymmetric Routing Ricardo Tavares (May 27)
- Re: Junos Asymmetric Routing Larry Sheldon (May 27)
- Re: Junos Asymmetric Routing Mark Hermsdorfer (May 28)
- Re: Junos Asymmetric Routing Ken Gilmour (May 28)
- Re: Junos Asymmetric Routing Adrian Chadd (May 28)
- Re: Junos Asymmetric Routing Larry Sheldon (May 28)
- Re: Junos Asymmetric Routing Jack Bates (May 28)
- Re: Junos Asymmetric Routing Joe Blanchard (May 27)
- Re: Junos Asymmetric Routing Ken Gilmour (May 28)
- Re: Junos Asymmetric Routing Ken Gilmour (May 28)
- Re: Junos Asymmetric Routing Jian Gu (May 28)
- Re: Junos Asymmetric Routing Ken Gilmour (May 28)
- Re: Junos Asymmetric Routing Jack Bates (May 28)
- RE: Junos Asymmetric Routing Jensen Tyler (May 28)
- RE: Junos Asymmetric Routing Jensen Tyler (May 28)
- Re: Junos Asymmetric Routing Ken Gilmour (May 28)
- Re: Junos Asymmetric Routing Adrian Chadd (May 28)