[nf-failover] Re: [RFC] ct_sync 0.15 (corrected)
hno at marasystems.com
Wed Sep 29 10:12:04 CEST 2004
On Wed, 28 Sep 2004, Jamal Hadi Salim wrote:
> Like you said earlier, the allocation is IPaddress:portrange. I do think
> this will require some extra hack for the mapping. Am i mistaken?
> So instead if you just zeroed out the IPaddres piece, then the only
> change left is por range.
> I believe this is already supported in the form of
This is for local connections, not related to NAT.
> Unfortunately i am not sure if you can force current to always get
> its port allocation from the allocated range _only_. Is this doable?
iptables NAT allows you to specify the IP and port range acceptable.
> Caveat: You just limited your active connections for your cluster to 64K
Not really. But if you only have a single IP address then the port
allocation limits you to 64K flows per "other" IP. As already discussed
the tuple needs to be unique between different flows, not neccesarily the
> I think we should make the issue of balancing a separate item.
It is separate from the matter of syncronization. But the reason why the
syncronization protocol has not yet been designed for active-active is
because no load balancing scheme has been designed which would work. The
two goes hand in hand and both needs to be solved.
Most likely the first load balancing method which will get implemented
(and forcing ct_sync to add the two minor pieces missing for active-active
syncronization) is the multicast balancing method in a no-NAT clused where
each firewall sees all traffic and selects what it looks closer at. This
is by far the easiest to implement. But even this is not entirely trivial
as there may be conflicts in flow key balance IDs depending on the
direction of the flow, but most likely this problem is more theoretical
> It shouldnt matter how the packet gets delivered to an active node
> (pigeons, expensive loadbalancers, LVS, some routing tricks,
> etc all is fine by me).
> - The state is already synced across all the nodes;
> - assuming theres no conflict and
> - assuming asymetry (ok, maybe thats too restrictive) but a good start.
Allowing for assymetric flows is not something which is realistic to aim
for unless you also aim for absolute syncronization by delaying packets
until the firewalls have been syncronized. Such design will scale very
More information about the netfilter-devel