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

jamal hadi at cyberus.ca
Tue Sep 28 04:41:17 CEST 2004


On Mon, 2004-09-27 at 09:39, Harald Welte wrote:

> I totally agree with you, jamal.  And in fact this is exactly what we
> have.  You tell one box it is master, and it becomes master.   You tell
> a box it is slave, and it becomes slave.
> There is just a minor addition in one case, where we want to safeguard
> against a (currently) invalid mode of operation.  As soon as ct_sync
> supports multiple master, this safeguard will certainly be removed.

So if understood correctly the issue is as described by Krisztian:

On Mon, 2004-09-27 at 09:30, KOVACS Krisztian wrote:
> The main problem is with NAT and preserving the uniqueness of
> tuples in the whole cluster, and unfortunately this would make a lot of
> things much more complicated. So, even if the protocol would be
> completely multi-master compatible ct_sync would be capable of
> single-master operation.

If you have two machines A and B, assuming they are symetric (exactly 
same internal and external IPs) then i should be able to send state from 
A->B and B->A and have both B and A updated (if such state doesnt exist).

With above if i decide i want to have two nodes as master, they both
generate and accept state update messages.

> But for the current code, unless somebody shows to me that it severely
> limits some use of ct_sync, or it causes practical problems, I don't see
> why we should remove this safeguard.

As i see it you need 3 states:
Master - accepts and generates sync messages
slave - only accepts syncs
init - unknown; does neither

If you didnt have this safeguard then i should be able to achive
master/master on two nodes (even if for starters i assume symetric
setup). ct_sync in itself should not attempt to be too smart and have a
built-in protocol IMO - there is no point in reinventing the wheel;
people have spent years researching HA protocols, good idea to just use


More information about the netfilter-devel mailing list