On Fri 2015-Jun-05 19:11:16 +0300, Yuriy B. Borysov yokod...@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Hugo
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
