From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 15:46:36 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D745C106564A for ; Tue, 12 Aug 2008 15:46:36 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 98DAF8FC1B for ; Tue, 12 Aug 2008 15:46:36 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 715F52BDAC; Wed, 13 Aug 2008 03:46:34 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1NFg+noGFuP; Wed, 13 Aug 2008 03:46:29 +1200 (NZST) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Wed, 13 Aug 2008 03:46:29 +1200 (NZST) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id CAB861142D; Wed, 13 Aug 2008 03:46:28 +1200 (NZST) Date: Tue, 12 Aug 2008 08:46:28 -0700 From: Andrew Thompson To: Marian Hettwer Message-ID: <20080812154628.GA45850@citylink.fud.org.nz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: stable@freebsd.org Subject: Re: lagg(4) and failover X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 15:46:36 -0000 On Tue, Aug 12, 2008 at 12:37:15PM +0200, Marian Hettwer wrote: > Hi Folks, > > I'm using lagg(4) on some of our servers and I'm just wondering how the > failover is implemented. > The manpage isn't quite clear: > > failover Sends and receives traffic only through the master port. > If > the master port becomes unavailable, the next active port > is > used. The first interface added is the master port; any > interfaces added after that are used as failover devices. > > What is meant by "becomes unavailable"? Is it just the physical link which > needs to become unavailable to trigger a failover? > > I do wonder, because there might be other faults where the link is still > active, but the port is unusable. Think of a wrong vlan on the switch > itself. > > When using bonding under Linux (yeah, I know, the configuration sucks ;) ), > I can configure the device to check for arp respones of it's default > gateway. If arp to the default gw becomes unavailable, bonding fails over > to the next interface and tries it luck over there. > With that kind of configuration, I could cover a misconfigured switch port > and still have failover. > > Long Story short: How is failover in lagg(4) implemented? It is simply performed on the physical link state, nothing more. Adding smarter methods of detecting the link such as what Linux does are very welcome. You may want to also look at LACP mode where heatbeat frames are exchanged with the peer. Andrew