[nf-failover] My basic concept (repost)

[Lennert Buytenhek]

On Thu, Feb 01, 2001 at 10:23:48AM +0100, HaraldWeltelaforge at gnumonks.org wrote:

> > This might be a little eary for this, but the earlier we consider it,
> > the easier it might be to implement it later: Next to failover we might
> > even think about load-balancing. The second (or third ;) ) firewall is
> > not only a hot spare, but does active firewalling and NATing,
> > transparently to all subnets.
> 
> MMh... it is not too early to discuss this now. If we want support for 
> that, we may want to design the failover in a way enabling us to 
> do load balancing in the future.

I believe this would make a noticeable difference.

In the case of loadbalancing we would also want to be able to tell conntrack
f.e. in the case of NAT: "Sorry, (addr,port) you mapped to was taken while
you weren't looking, please try again." Transaction abort, in a way.

We also need a mechanism for saying: "Conntrack, thank you for handing me this
SYN packet, now please wait with forwarding it until I notify the other
cluster members of the new state entry."

Perhaps we could do this with an NF_HOOK-like async interface. Something like:

void NF_CT_HOOK(struct sk_buff *, struct conntrack_entry *old, struct conntrack_entry *new, int (*handler_fc)(struct sk_buff *skb, struct conntrack_entry *old, struct conntrack_entry *new, int verdict));

Where verdict could take the values:
- NF_CT_OK	- slaves notified, all is well
- NF_CT_EAGAIN	- mapped to address was already taken, please try again
etc.

I haven't looked at any of the involved code yet, so the feasibility of this
is just pure speculation at this point.


> But as far as my thoughts have gone - load-balancing is way too complex
> and has a number of difficult, unresolved issues. Not only that you 
> have to find a way of equally distributing the load between the machines,
> but also: both machines need to share one IP / MAC adress on both sides
> _at the same time_. 

Not in the case of bridging..


> I don't think that this is feasible (with linux) at all. 
> 
> But if anybody has knowledge of other systems (and their design, 
> implementation, ...) or protocols / standards / recommendations about
> this topic: Feel free to discuss it on this list :)

2.2 (and also 2.4) ethernet bridging will allow redundancy and load-
balancing (not in combination with state tracking though).

The basic redundancy setup is as follows: Put two bridges side-by-side and
enable the Spanning Tree Protocol on them. Give them identical filtering
rules. Now one bridge will handle all the load, and in case it falls over,
the other one will take over. A bit of tweaking of the spanning tree
parameters will allow this to happen in a few seconds.

The basic loadbalancing setup is as follows: configure, between two switches,
an aggregated link (trunk, EtherChannel, bonding, whatever you want to call
it), and have one bridge (with STP /disabled/) filter one of the aggregated
link sublinks. Some switch brands run an aggregated link protocol like LACP
over aggregated links, or at least detect carrier loss, and failover to using
less links.

Both of these setups have been implemented and are working in practise. Now
that I have the 2.4 bridge netfilter stuff working (few small things left to
be sorted out), I'd like to get bridged redundant loadbalancing state-tracking
firewalling working. :)


cheers,
Lennert


-- 
 I are sigfile disease!!
 All your quote are belong to us.
 Copy us every "sig"!