SRX

Hi,

on ScreenOS you can set the way a reverse route is choosen with "(un)set flow reverse-route". It's possible to use the initiator as reverse path, ignoring the routing table. On junos 9.6 (on a j-serie, didn't try srx yet) I noticed the routing table is allways used. Is there a way to force using the same path back, avoiding asymetric routing, like "unset flow reverse-route clear-text" on ScreenOS?

its not supported in JUNOS currently.

thanks

raheel anwar

Hi Raheel,

Do you know whether there are plans to implement this feature or it is a principal decision based on some fundamental issues?

I discovered an issue with asymmetric routing when traffic comes to an interface, then gets translated to an internal address and than reverse traffic is sent to another external interface (to another ISP) being back-translated to the address belonging to the first (incoming) interface. In such a case there is a good chance for this traffic to be blocked by ISP's uRPF.

Using a cached next-hop to source, as ScreenOS can do, could save the deal.

--

Kind regards,

Pavel

Ditto what onemorepash said.  If you have a privately addressed server behind two active ISP connections the SRX choice of return egress interface does not seem to factor in the original ingress interface.

Scenario:

  2 ISP's with independant public address pools assigned to the SRX

  Dst NAT configured to translate a public address from each pool to an internal server

  The response from the internal server does not necessarily flow back out the same ISP.  The decision seems to be a packet-based decision, not a flow-based decision???  (the same behavior happened when load-balancing pre-prefix was enabled)

Snippet from a debug:

Dec 10 02:09:45 02:09:44.1101972:CID-0:RT:  route lookup: dest-ip x.x.x.x orig ifp ge-0/0/0.0 output_ifp ge-0/0/1.0 orig-zone 6 out-zone 6 vsd 0
Dec 10 02:09:45 02:09:44.1101972:CID-0:RT:  reroute handling for tunnel 0
Dec 10 02:09:45 02:09:44.1101972:CID-0:RT:  clearing tunnel since the routed interface is ge-0/0/1.0
Dec 10 02:09:45 02:09:44.1101972:CID-0:RT:new output if ge-0/0/1.0

I'm not sure what a good workaround for this is...

I really don't understand why Juniper are avoiding those basic features, im having the same problem with a similar scenario with 2 ISP, the same happen with track-ip, they didn't implement it on  JunOS ES....

I hope someone have something to solve it.

I solve my problem already... , the problem was that the interfases were configured in different zones and when it  was trying to return the package back i received a "zone missmatch error(i saw it in the a flowtrace file". This is something that doesn't happen on the SSG (almost sure).

my flowtrace file:

Dec 15 18:46:13 18:46:12.987602:CID-1:RT:  route lookup: dest-ip orig ifp reth2.0 output_ifp reth1.0 orig-zone 10 out-zone 9 vsd 2
Dec 15 18:46:13 18:46:12.987602:CID-1:RT:

resource: http://kb.juniper.net/index?page=content&id=KB15545&smlogin=true

Regards,

Layard

Layard's problem may be solved, but I think the same issue still exists that was the original thread of this post.

Namely, that you cannot control which interface a return packet will be forwarded out based on original ingress interface; the decision is made solely by the routing/forwarding table.

This is not necessarily a problem if the environment can handle asymmetric routing, but obviously this is not always the case.  Take the case where a company has two independent ISP connections and no publicly assigned IP address space, and they want to make an application available through both ISP's.  If a packet comes in via ISP A it may leave via ISP B, which will not work if the customer is NAT'ing to different public address space.

Netscreen had a way of dealing with this 'set/unset flow reverse-route'.  I have been unsuccessful in getting this to work on the SRX and am not sure if there is (or will be) an alternative workaround for the problem described above.

I have this scenario, Two ISP the same service NATted through both ISP, when a traffic comes for a particular interface or ISP the session is writted down, so in the returned traffic the SRX will see if there's an existing session and will forward it based on the session.

It worked to me if both ISP are in the same security zone.

Can you post what hardware / JUNOS version you are running?  When I tried implementing on an SRX210 running 10.0r1.8 a flow trace showed the return packet decision being made via the forwarding table and not the session table.

(Nice KB reference though.  That looks like it does provide a work around via separate routing-instances, although they reference 2 different security zones for the different ISP's.)

Example session & flow trace below (1st packet enters via ge-0/0/0; return packet egresses ge-0/0/1 [based on forwarding table]; all interfaces in same security zone):

super> show security flow session session-identifier 100
Session ID: 100, Status: Normal
Flag: 0x4400000
Policy name: default-permit/4
Source NAT pool: Null, Application: junos-ssh/22
Maximum timeout: 1800, Current timeout: 1648
Start time: 985, Duration: 161
   In: 192.168.254.30/59320 --> 10.2.1.3/22;tcp,
    Interface: ge-0/0/1.0,
    Session token: 0x180, Flag: 0x4129
    Route: 0x60010, Gateway: 10.2.2.1, Tunnel: 0
    Port sequence: 0, FIN sequence: 0,
    FIN state: 0,
   Out: 192.168.9.81/22 --> 192.168.254.30/59320;tcp,
    Interface: .local..0,
    Session token: 0x80, Flag: 0x4144
    Route: 0xfffb0006, Gateway: 192.168.9.81, Tunnel: 0
    Port sequence: 0, FIN sequence: 0,
    FIN state: 0,

1 sessions displayed

super> show log dbuf
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:<192.168.254.30/59320->10.2.1.3/22;6> matched filter test:
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:packet [64] ipid = 22411, @423fc09e
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:---- flow_process_pkt: (thd 1): flow_ctxt type 13, common flag 0x0, mbuf 0x423fbf00
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT: flow process pak fast ifl 68 in_ifp ge-0/0/0.0
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  ge-0/0/0.0:192.168.254.30/59320->10.2.1.3/22, tcp, flag 2 syn
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT: find flow: table 0x4d5c93c0, hash 41244(0xffff), sa 192.168.254.30, da 10.2.1.3, sp 59320, dp 22, proto 6, tok 384
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  no session found, start first path. in_tunnel - 0, from_cp_flag - 0
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  flow_first_create_session
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:Installing pending sess (100) in ager
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:First path alloc and instl pending session, natp=0x4b5d2550, id=100
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  flow_first_in_dst_nat: in <ge-0/0/0.0>, out <N/A> dst_adr 10.2.1.3, sp 59320, dp 22
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  chose interface ge-0/0/0.0 as incoming nat if.
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:flow_first_rule_dst_xlate: DST xlate: 10.2.1.3(22) to 192.168.9.81(22), rule/pool id 1/1.
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:flow_first_routing: call flow_route_lookup(): src_ip 192.168.254.30, x_dst_ip 192.168.9.81, in ifp ge-0/0/0.0, out ifp N/A sp 59320, dp 22, ip_proto 6, tos 0
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:Doing DESTINATION addr route-lookup
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:flow_ipv4_rt_lkup in VR-id: 0
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:flow_ipv4_rt_lkup: Found route entry 0x0x4fe463f0,nh id 0x225, out if 0x0
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:flow_ipv4_rt_lkup: nh word 0xfffb0006
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:flow_ipv4_rt_lkup success 192.168.9.81, iifl 0x44, oifl 0x0
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:Changing out-ifp from .local..0 to fe-0/0/6.0 for dst: 192.168.9.81 in vr_id:0
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  routed (x_dst_ip 192.168.9.81) from trust (ge-0/0/0.0 in 0) to fe-0/0/6.0, Next-hop: 192.168.9.81
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  policy search from zone trust-> zone trust
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  app 22, timeout 1800s, curr ageout 20s
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:Permitted by policy 4
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:flow_first_src_xlate: 192.168.254.30/59320 -> 10.2.1.3/22 | 192.168.9.81/22 -> 0.0.0.0/59320: nat_src_xlated: False, nat_src_xlate_failed: False
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:flow_first_src_xlate: src nat 0.0.0.0(59320) to 192.168.9.81(22) returns status: 0, rule/pool id: 0/0, pst_nat: False.
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  dip id = 0/0, 192.168.254.30/59320->192.168.254.30/59320
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:flow_first_get_out_ifp: 1000 -> cone nat test
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  choose interface fe-0/0/6.0 as outgoing phy if
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:is_loop_pak: Found loop on ifp fe-0/0/6.0, addr: 192.168.9.81, rtt_idx: 0 addr_type:0x1.
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:flow_first_loopback_check: Setting interface: fe-0/0/6.0 as loop ifp.
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:policy is NULL (wx/pim scenario)
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:sm_flow_interest_check: app_id 0, policy 4, app_svc_en 0, flags 0x2. not interested
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:sm_flow_interest_check: app_id 1, policy 4, app_svc_en 0, flags 0x2. not interested
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:flow_first_service_lookup(): natp(0x4b5d2550): local_pak(0x3fdedc70.0x423fbf00): TCP proxy NOT interested: 0.
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:tcp proxy not needed
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  service lookup identified service 22.
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  flow_first_final_check: in <ge-0/0/0.0>, out <fe-0/0/6.0>
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:flow_first_final_check: flow_set_xlate_vector.
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:In flow_first_complete_session
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:flow_first_complete_session: pak_ptr is xlated packet
                   
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  existing vector list 1002-446c08a8.
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  Session (id:100) created for first pak 1002
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:first pak processing successful
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  flow_first_install_session======> 0x4b5d2550
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT: nsp 0x4b5d2550, nsp2 0x4b5d25bc
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:lpak_init: lpak 48abef78, paksize 4096, machdr 0, iphdr 0x42df2500
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:flow_proc_loop_back:In loopback session processing
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:duplicate_local_pak: duplicated pak has zone: Unknown, ifp: none, vsys: root, 192.168.254.30->10.2.1.3, lports    10001, tlen 64
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  post addr xlation: 192.168.254.30->192.168.9.81.
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:proc_loopback_common: Found loop if fe-0/0/6.0
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:check self-traffic on fe-0/0/6.0, in_tunnel 0x0
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  flow_first_create_session
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:Loopback first path alloc pending session, natp=0x4b5d2728, id=101
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  flow_first_in_dst_nat: in <fe-0/0/6.0>, out <N/A> dst_adr 192.168.9.81, sp 59320, dp 22
                   
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  chose interface fe-0/0/6.0 as incoming nat if.
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:flow_first_rule_dst_xlate: DST no-xlate: 0.0.0.0(0) to 192.168.9.81(22)
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:flow_first_routing: call flow_route_lookup(): src_ip 192.168.254.30, x_dst_ip 192.168.9.81, in ifp fe-0/0/6.0, out ifp N/A sp 59320, dp 22, ip_proto 6, tos 0
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:Doing DESTINATION addr route-lookup
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:flow_ipv4_rt_lkup in VR-id: 0
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:flow_ipv4_rt_lkup: Found route entry 0x0x4fe463f0,nh id 0x225, out if 0x0
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:flow_ipv4_rt_lkup: nh word 0xfffb0006
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:flow_ipv4_rt_lkup success 192.168.9.81, iifl 0x46, oifl 0x0
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  routed (x_dst_ip 192.168.9.81) from trust (fe-0/0/6.0 in 0) to .local..0, Next-hop: 192.168.9.81
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  policy search from zone trust-> zone junos-self
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  app 22, timeout 1800s, curr ageout 20s
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:Permitted by policy 1
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:flow_first_src_xlate: 192.168.254.30/59320 -> 10.2.1.3/22 | 192.168.9.81/22 -> 0.0.0.0/59320: nat_src_xlated: False, nat_src_xlate_failed: False
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:flow_first_src_xlate: src nat 0.0.0.0(59320) to 192.168.9.81(22) returns status: 0, rule/pool id: 0/0, pst_nat: False.
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  dip id = 0/0, 192.168.254.30/59320->192.168.254.30/59320
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:flow_first_get_out_ifp: 1000 -> cone nat test
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  choose interface .local..0 as outgoing phy if
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:is_loop_pak: No loop: ifp doesnt match .local..0 vs looked-up: fe-0/0/6.0, addr: 192.168.9.81, rtt_idx: 0, addr_type:0x1
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:policy is NULL (wx/pim scenario)
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:sm_flow_interest_check: app_id 0, policy 1, app_svc_en 0, flags 0x2. not interested
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:sm_flow_interest_check: app_id 1, policy 1, app_svc_en 0, flags 0x2. not interested
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:flow_first_service_lookup(): natp(0x4b5d2728): local_pak(0x48abef78.0x42df2180): TCP proxy NOT interested: 0.
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:tcp proxy not needed
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  service lookup identified service 22.
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  flow_first_final_check: in <fe-0/0/6.0>, out <.local..0>
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:In flow_first_complete_session
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  existing vector list 2-446f9128.
                   
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  Session (id:101) created for first pak 2
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:combine_loopback_session:Ready to merge loop sessions: 100 & 101
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:combine_loopback_session:
First session:
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:nsp:0x4b5d2550, 192.168.254.30/59320 -> 10.2.1.3/22:6,
 If: ge-0/0/0.0, nsp-flag: 0x21 tok: 0x180, nh:0x0
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:nsp:0x4b5d25bc, 192.168.9.81/22 -> 192.168.254.30/59320:6,
 If: fe-0/0/6.0, nsp-flag: 0x8 tok: 0x180, nh:0xfffb0006
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:combine_loopback_session:
Second session:
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:nsp:0x4b5d2728, 192.168.254.30/59320 -> 10.2.1.3/22:6,
 If: fe-0/0/6.0, nsp-flag: 0x1 tok: 0x180, nh:0x0
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:nsp:0x4b5d2794, 192.168.9.81/22 -> 192.168.254.30/59320:6,
 If: .local..0, nsp-flag: 0x10 tok: 0x80, nh:0xfffb0006
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:old natp: flow_fto1 4b5d256c(fto 0) flow_fto2 4b5d25d8(fto 4474b6f0),new natp: flow_fto1 4b5d2744(fto 0), flow_fto2 4b5d27b0 (fto 4474b6f0)
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:combine_loopback_session:  vector index of sess1 1002,  vector index of sess2 2
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  existing vector list 1002-446c08a8.
                   
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:combine_loopback_session: New vector index 1002.
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:combine_loopback_session: New merged session has id 100, natflag: 0x44400000
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:nsp:0x4b5d2550, 192.168.254.30/59320 -> 10.2.1.3/22:6,
 If: ge-0/0/0.0, nsp-flag: 0x21 tok: 0x180, nh:0x0
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:nsp:0x4b5d25bc, 192.168.9.81/22 -> 192.168.254.30/59320:6,
 If: .local..0, nsp-flag: 0x10 tok: 0x80, nh:0xfffb0006
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:set_nat_invalid: natp:id 101, flag 4b315389
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  make_nsp_ready_no_resolve()
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:flow_ipv4_rt_lkup in VR-id: 0
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:flow_ipv4_rt_lkup: Found route entry 0x0x4fdb15c0,nh id 0x229, out if 0x45
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:flow_ipv4_rt_lkup: nh word 0x60010
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:flow_ipv4_rt_lkup success 192.168.254.30, iifl 0x0, oifl 0x45
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  route lookup: dest-ip 192.168.254.30 orig ifp ge-0/0/0.0 output_ifp ge-0/0/1.0 orig-zone 6 out-zone 6 vsd 0
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  reroute handling for tunnel 0
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  clearing tunnel since the routed interface is ge-0/0/1.0
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:new output if ge-0/0/1.0
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  route to 10.2.2.1
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:Installing c2s NP session wing
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  flow_spu_install_np_session: FLOW STUB
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:Skip installing s2c NP session wing
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:updating pending sess (100) in ager
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:first path session installation succeeded
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  flow got session.
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  flow session id 100
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  tcp flags 0x2, flag 0x2
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  Got syn, 192.168.254.30(59320)->10.2.1.3(22), nspflag 0x1021, 0x30
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:  post addr xlation: 192.168.254.30->192.168.9.81.
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:insert usp tag for vpn apps
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT:mbuf 0x423fbf00, exit nh 0xfffb0006
 
Dec 22 23:17:29 23:17:29.656517:CID-0:RT: ----- flow_process_pkt rc 0x0 (fp rc 0)

Found this thread when trying to get some filter based forwarding working with dual ISPs and incoming services myself and I've found the solution so thought I'd post it up if anyone else gets here from Google.

As @aweck noted, incoming traffic can be routed incorrectly (as per different forwarding instances) because the route resolution is always done via the inet.0 table. The way I worked round this was to implement a virtual router for each ISP, and then use a filter to direct traffic to either routing instance as required. That way when incoming traffic hits the routers it can use the routing table of the virtual router which stands more chance of sending the return traffic back correctly without asymetric routing. 

I bumped into this issue when the two ISP connections were in the same zone in the default routing instance. The initial policy lookup used the inet.0 table so even if I used FBF with two forwarding instances, the inital policy lookup locked the reverse path to the default route and the fast path processing would not  look at the routes.

When I used a virtual router instance and two zone, the intial first path policy lookup used the correct gateway for each zone and filters were not required.

Thanks Wae76,

Would it be possible for you to share the config you got working here?

I am trying to get reverse path routing to go via the same path that the traffic came in on and am not having much sucess.

I have set my two ISP connections up in a VR and each interface sits in its own zone, but I am still getting errors like this (these are obviously just sections of the log):

Feb 4 13:30:58 13:30:58.202163:CID-1:RT: route lookup: dest-ip 82.2.189.248 orig ifp reth1.301 output_ifp reth1.3915 orig-zone 10 out-zone 11 vsd 1

Feb 4 13:30:58 13:30:58.202163:CID-1:RT:Reject route in make_nsp_ready_no_resolve. zone mismatch

Feb 4 13:30:58 13:30:58.202656:CID-1:RT: route lookup failed: dest-ip 82.2.189.248 orig ifp reth1.301 output_ifp reth1.3915 fto 0x49f51b68 orig-zone 10 out-zone 11 vsd 1
Feb 4 13:30:58 13:30:58.202656:CID-1:RT: readjust timeout to 6 s

Feb 4 13:30:58 13:30:58.202656:CID-1:RT:ha_ifp: reth1.301

Feb 4 13:30:58 13:30:58.202656:CID-1:RT: packet dropped, pak dropped since re-route failed

Many thanks