On 12/03/2012 03:48 AM, Dale Shaw wrote:
Sometimes (due to OSPF's route selection process when presented with
equal cost routes) the path traffic takes from "A" to "B" is not the
same as the path from "B" to "A" -- the intermediate device to
hair-pin on (for A->B and B->A) is different. In performance terms,
the difference is insignificant. Most of the time the intermediate
devices are sitting next to each other in a rack (e.g. primary and
secondary routers).
How does this even work? Surely TCP flows through the device just won't go?
Does the SRX do something "special" with asymmetric UDP flows? When I
say UDP I mean UDP generically, because I'm aware of special cases
like "set security flow allow-dns-reply". I have an ever-growing
suspicion that we are throwing packets on the floor in certain
circumstances.
What kind of "special" were you thinking of?
Obviously each flow will appear as a separate uni-directional session to
the SRX, since each device only sees half the traffic. It's possible
something funny happens in this situation e.g. if the flow runs for X
seconds without a packet in the other direction, drop it. But that's
purely speculation.
This is probably not what you want to hear, but OSPF is a nightmare in
this situation; you end up balancing route metrics constantly (if you
want multiple devices forwarding) or just running one device active at a
time. We used to do it, and I hated it...
cheers,
Dale (..on the never-ending quest to make SRXs behave like routers w/IPsec)
I feel your pain. It's a mystery to me why vendors seem to be abandoning
traditional IPSec on routers in favour of "small firewalls" with all
their attendant problems re: flow symmetry.
That said: we run flow-based devices in dual-active mode using BGP
rather than OSPF. The reason this works is that judicious use of BGP
communities and routing policy can be used to ensure both sides of a
flow route via the same path in the steady state - though not in every
topology, I'm afraid.
The other option is to stick a load-balancer in front of the IPSec
terminators. All very yucky.
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
