Date: Tue, 12 Aug 2008 21:24:30 +1000 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Eugene Grosbein <eugen@kuzbass.ru> Cc: stable@freebsd.org, Marian Hettwer <mh@kernel32.de> Subject: Re: lagg(4) and failover Message-ID: <20080812112430.GC64458@server.vk2pj.dyndns.org> In-Reply-To: <20080812105552.GA89695@svzserv.kemerovo.su> References: <a588673badeccac53d23f7964c216f62@localhost> <20080812105552.GA89695@svzserv.kemerovo.su>
next in thread | previous in thread | raw e-mail | index | archive | help
--OQhbRXNHSL5w/5po Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Aug-12 18:55:52 +0800, Eugene Grosbein <eugen@kuzbass.ru> wrote: >On Tue, Aug 12, 2008 at 12:37:15PM +0200, Marian Hettwer wrote: > >> I'm using lagg(4) on some of our servers and I'm just wondering how the >> failover is implemented. As far as I can tell, not especially well :-(. It doesn't seem to detect much short of layer 1 failure. In particular, shutting down the switch port will not trigger a failover. >> The manpage isn't quite clear: >>=20 >> failover Sends and receives traffic only through the master por= t.=20 >> If >> the master port becomes unavailable, the next active p= ort >> is >> used. The first interface added is the master port; a= ny >> interfaces added after that are used as failover devic= es. >>=20 >> What is meant by "becomes unavailable"? Is it just the physical link whi= ch >> needs to become unavailable to trigger a failover? It seems to be, >Yes. It seems you need lacp protocol described later in the manual. Actually, lacp and failover are used differently: lacp is primarily used to increase the bandwidth between the host and the switch whilst failover is used for redundancy. With lacp, all the physical interfaces must be connected to a single switch. With failover, the physical interfaces will normally be connected to different switches (so a failure in one switch will not cause the loss of all connectivity. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --OQhbRXNHSL5w/5po Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkihcu4ACgkQ/opHv/APuIcNXgCeJPEp9QTb83+iPyesHUaIwCYR Z+AAn1gGYSRZTEUDA+R6czO86QOEt4kk =HvEk -----END PGP SIGNATURE----- --OQhbRXNHSL5w/5po--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080812112430.GC64458>