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

[Henrik Nordstrom]

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
> /proc/sys/net/ipv4/ip_local_port_range

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
> flows.

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 
port.

> 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 
than practical.

> 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).
> Assuming:
>
> - 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 
badly.

Regards
Henrik