On 2024/10/18 16:21, Robert Keizer wrote:
> Thank you to everyone who has responded!
> 
> Going through the responses, and thinking a bit more about the
> particular details of what I'm attempting to solve for, I could
> have been much more concise, apologies.
> 
> I think I'm going to live with my edge case and handle it
> another way. It's too small to be concerned with at this time.
> 
> My use case was N nodes, advertising the same space into the DFZ;
> For certain (very limited) connections, I was thinking it would be best
> to be able to "defer" across more than 1 other node.
> 
> From a functional perspective, I think a way to have the "defer" flag
> functionality apply to N nodes, and the ability to control N in
> runtime, would address my small edge case.
> 
> The edge case is thus: suppose 3 nodes advertising the same IP space,
> "A", "B", and "C", all running pfsync. Suppose a client "Z" connects to A,
> and just as they open a connection, routes change such that traffic
> from "Z" ends up going to "B". If "A", "B", and "C" are all using pfsync
> with "defer" set, I was worried that it could be possible that "B" didn't
> receive the pfsync message by the time "Z" sends a subsequent packet.
> 
> After some reflection, it's almost a contrived example edge case, given
> how low likelihood it is that routes from "Z" to the system would change
> at that instant, and also that the latency would have to be such that a
> pfsync message from "A" to "B" took longer when compared to
> ( "A" to "Z" + "Z to "B" ).
> 
> In any event, thank you all for the responses and thoughts.
> 

So, with bgp - I would recommend advertising routes with the carp
address set as the nexthop if possible. That way you avoid most of
the problems with asymmmetric routes that are the main reason for defer.