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

Henrik Nordstrom hno at marasystems.com
Wed Sep 29 13:44:25 CEST 2004

On Wed, 29 Sep 2004, Jamal Hadi Salim wrote:

> To clarify what you are saying: you will have (in the case of
> masquareding single external realm IP) 64K possible flows per internal
> realm _src_ IP?

No, per external IP,port contacted by your internal addresses.

Original tuples

internal_station_ip,port external_server_ip,port

Masqueraded tuples

masquerade_ip,port(*) external_server_ip,port

> The cluster shouldnt care how the packet got there. Put LVS infront of
> cluster or play ARP tricks - It doesnt matter.
> Maybe iam missing something.

For a firewall you have to care about traffic on both sides, unless you 
are doing multicast balancing.  Your distribution must be 100% equal on 
both sides.

>> 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.
> I am not saying this shouldnt be supported, but why the restiction
> to _only_ this?

Who have said this? It is certainly not my intentions to imply multicast 
load balancing is the only way to go.

>>  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.
> Thats what it seems to me.
> Maybe the piece i am missing is this "flow key balance IDs"...
> If i have all the state of peer firewall, why should i not be able
> to process packets you throw at me?

Beause you don't have the all the state. There is significant delays in 
the state distribution unless you accept to make the state syncronization 
syncronous with the packet flow (no packet forwarded before the state 
change this packet implies have been verifiable syncronized to all 
firewalls) which would in effect make the total cluster performance some 
orders of magnitude worse than having a single firewall with no or very 
little options for load balancing.

> Sorry, I meant symetric setup .. i.e equal looking machines with same or
> similar set of addresses. Two masquareding examples:
> I:
> Machine A: internal IP:, external
> Machine B: internal IP:, external
> On failover, all addresses taken over by peer; state synced, things
> run as before.
> II:
> Machine A: internal IP:, external
> Machine B: internal IP:, external

I don't quite follow what you aim for here. Please outline this in terms 
of connections (full tuples), masquerading/NAT (modified tuples) and 
routing/forwarding of traffic in both directions.


More information about the netfilter-devel mailing list