lagg(4) and failover

[Tom Samplonius]

----- "Brian A. Seklecki" <bseklecki at collaborativefusion.com> wrote:
> On Sun, 2008-12-07 at 08:03 +1100, Peter Jeremy wrote:
> > On 2008-Dec-05 07:34:21 -0500, "Brian A. Seklecki"
> > <bseklecki at collaborativefusion.com> wrote:
> > >Well ... name a price for the development; HA L1/L2 is a feature
> the
> > >community would gladly sponsor the development of.
> > 
> > net/ifstated covers at least some of this.
> 
> I was thinking something like a heartbeat protocol could work well
> w/o
> LACP hacking on mid-range switches.
> 
> I think that's how Dell does it with the RHEL crap for Broadcom.
> 
> Send multicast packets on both an active/standby link.  If either
> node
> discontinues to see the others packets, some admin-configurable logic
> promotes (Metric/Bias/Weighting).

  I don't know if that is such a great idea, as that would only test the switch that you are connected to.

  The Linux bonding driver supports probing the default gateway.  Now, it uses ARP for this (probably because the ARP who-has code is also in the kernel and easily accessible), which also not so great, as a ARP who-has is a broadcast.  So if you have lots of servers on the LAN using the bonding driver, you get a lot of broadcast traffic.  ICMP echo-request would be a better approach, but my take on this, is that the echo-request/reply handling code would have to be written, so this hasn't been done yet.  But ultimately, gateway probing is the best, as not only does it verify the directly connected switch, but also that you can get from that switch to the outside world.

  lagg is ultimately a problem as a high-availability solution since most switches do not support multi-switch 802.3ad yet, and most probably never well.  So you are limited to a single switch.  So 802.3ad is good only for aggregation, and not for high availability.

  So an active-standby system with probing is the way to go for high-availability.  It seems that FreeBSD has most of the components of this already.  ng_one2many was a possible base for this.  

> ~BAS
> 
> -- 
> Brian A. Seklecki <bseklecki at collaborativefusion.com>
> Collaborative Fusion, Inc.

Tom