[j-nsp] SRX FBF issue

[Hugo Slabbert]

On Fri 2015-Jun-05 19:11:16 +0300, Yuriy B. Borysov <yokodzun at yokodzun.kiev.ua> wrote:

>Hello!
>
>I got a strange problem with Filter Based Forwarding on SRX 220.
>
>I have two uplink:
>
>show configuration interfaces ge-0/0/0.14
>description uplink1;
>vlan-id 14;
>family inet {
>    mtu 1500;
>    address x.x.x.82/29;
>    address x.x.x.85/29;
>    address x.x.x.86/29;
>}
>
>show configuration interfaces ge-0/0/0.18
>description uplink2;
>vlan-id 18;
>family inet {
>    mtu 1500;
>    address y.y.y.114/28;
>    address y.y.y.117/28;
>}
>
>
>Default route on ge-0/0/0.14 (x.x.x.81).
>
>I configure destination nat on y.y.y.114:
>show security nat destination rule-set port-redirect rule test
>match {
>    destination-address y.y.y.y/32;
>    destination-port 2555;
>}
>then {
>    destination-nat pool test;
>}
>
>
>
>Run telnet y.y.y.114 2555 and I see a strange picture:
>
>run show security flow session destination-port 2555
>Session ID: 133327, Policy name: untrust-to-trust/11, Timeout: 14, Valid
>  In: 213.160.143.26/21722 --> y.y.y.114/2555;tcp, ****If: ge-0/0/0.14****, Pkts: 2, Bytes: 120
>  Out: 10.100.0.252/25 --> 213.160.143.26/21722;tcp, If: ge-0/0/0.100, Pkts: 3, Bytes: 180
>Total sessions: 1
>
>
>Why inbound interface is ge-0/0/0.14 but not ge-0/0/0.18???
>

This is an issue with the interaction between FBF and flow route caching.  
When the packet ingresses ge-0/0/0.18, a route lookup is done for the 
source address within the routing table to which ge-0/0/0.18 belongs.  As 
you mentioned, the default route for that VR/table is out ge-0/0/0.14, so 
the cached flow route entry is entered as such and the flow session gets 
installed with ge-0/0/0.14 as the "outside" interface.

I haven't found a way around this outside of sticking ge-0/0/0.18 in a 
totally separate virtual-router with a default route via ge-0/0/0.18's 
gateway and then leaking interface routes between instances as needed.  
With ge-0/0/0.18 in its own VR with a default gateway pointing to its 
next-hop, the route lookup on initial packet ingress will pick up 
ge-0/0/0.18 as the egress interface on the return path.  It gets kinda 
messy, though, and I haven't really run it in production.

My past pings on this fell on deaf ears:
http://forums.juniper.net/t5/SRX-Services-Gateway/SRX110-Asymmetric-routing-with-FBF-and-remote-sourced-traffic/m-p/199115


>Thanks!
>

No problem.

>
>
>-- 
>WBR, Yuriy B. Borysov
>YOKO-UANIC | YOKO-RIPE	
>_______________________________________________
>juniper-nsp mailing list juniper-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/juniper-nsp

--
Hugo