[j-nsp] SRX, UDP traffic, routing asymmetry

[Phil Mayers]

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.