From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 11:30:14 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 543BF1065681 for ; Tue, 12 Aug 2008 11:30:14 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 1C6008FC16 for ; Tue, 12 Aug 2008 11:30:14 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSs4q-000HFz-5z; Tue, 12 Aug 2008 12:30:12 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSs4q-000AVN-4d; Tue, 12 Aug 2008 12:30:12 +0100 To: eugen@kuzbass.ru, mh@kernel32.de In-Reply-To: Message-Id: From: Pete French Date: Tue, 12 Aug 2008 12:30:12 +0100 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 11:30:14 -0000 > However, IMO lacp doesn't solve that problem. lacp is used for link > aggregation, not failover. It does both - if one of the links becomes unavailable then it will stop using it. We use this for failover and it works fine, the only caveat being that your LACP device at the far end needs to look like a single phsyical device (the nicer Cisco switches do this quite happily) > The manpage states "In the event of changes in physical connectivity...". > Again, does that mean, the link needs to be physically unavailable? If so, > it'll be the same behaviour as in failover mode and doesn't solve my > problem of a misconfigured switch... lagg is to handle failover at the physical layer for when one of your ether ports fails, or someone unplugs a cable. If I understand you correctly you are looking for something at the next layer up, to handle a problem where the ports work fine, but are not going to their expected destinations. lagg won't do this. -pete.