[nf-failover] Re: [RFC] ct_sync 0.15 (corrected)

[Henrik Nordstrom]

On Tue, 28 Sep 2004, KOVACS Krisztian wrote:

>> I would use IP addresses in this scheme.. it is very nice to have NAT as
>> non-intrusive as possible preserving what can be preserved of the original
>> tuple.
>
> Definitely. However, I don't see how it would be possible to use
> MASQUERADE and a single public IP in this case.

If you only have a single IP using division by IP addresses is clearly not 
an option.

>> There remains some delicate thinking on how to manage the traffic flows in
>> a sane manner to make sure the correct traffic is forwarded by the correct
>> node, considering failovers, recoveries etc.
>
> Yes, of course. Full re-sync would be a somewhat more complicated
> problem as well.

The full re-sync is just one more facet of the same problem. If one is 
solved you can solve both. It needs to be known per connection which node 
is currently the master, and the addressing/forwarding scheme needs to 
make sure the node who is master for a connection sees the traffic it 
needs to se.

> But if we maintain some per-conntrack mark indicating
> which node "owns" that entry, then even full re-sync could be
> implemented quite easily: each node dumps all entries it is responsible
> for. The protocol itself should be extended as well, we would need
> per-node sequence numbers and per-node recovery requests.

Indeed.

And the flow question of existing connections is also not such big problem 
as all you need is to look up the connection in conntrack and if not 
master you either drop the packet (multicast forwarding model) or 
request to become master of the connection (unicast forwarding model). 
The multicast forwarding model is a lot easier to implement but does not 
scale as well as all nodes need to see all traffic and drop the traffic 
for which they are not master.

This moves the "clusterIP" decision to after the conntrack lookup but 
before creating new conntrack sessions.

Regards
Henrik