From owner-freebsd-net@FreeBSD.ORG Thu Jun 2 23:02:15 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 491A3106566C for ; Thu, 2 Jun 2011 23:02:15 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 3212B8FC15 for ; Thu, 2 Jun 2011 23:02:14 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta01.emeryville.ca.mail.comcast.net with comcast id rAjJ1g0071smiN4A1Ap3fs; Thu, 02 Jun 2011 22:49:03 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta20.emeryville.ca.mail.comcast.net with comcast id rAor1g0071t3BNj8gAost7; Thu, 02 Jun 2011 22:48:53 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id E5445102C19; Thu, 2 Jun 2011 15:48:58 -0700 (PDT) Date: Thu, 2 Jun 2011 15:48:58 -0700 From: Jeremy Chadwick To: Patrick Lamaiziere Message-ID: <20110602224858.GA57713@icarus.home.lan> References: <20110602203940.GA80549@slowblink.com> <20110603001036.5ad0ff8d@davenulle.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110603001036.5ad0ff8d@davenulle.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org, freebsd-net@freebsd.org, John Subject: Re: Production use of carp? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 23:02:15 -0000 On Fri, Jun 03, 2011 at 12:10:36AM +0200, Patrick Lamaiziere wrote: > Le Thu, 2 Jun 2011 16:39:40 -0400, > John a ?crit : > > Hello, > > > However, if system A is the MASTER, and system B is rebooted, > > the carp interface on system A will flip/flop going down and > > coming back up which is not what I want. > > I saw this if the switch connecting the two systems takes some time to > forward packets when a link is "up". This happens if the switch is doing > some spanning tree protocol. (on cisco swith you should use an option > "spanning tree port fast" on the switch port to avoid this) Expanding a bit on this: This is written oddly (to me anyway). What Patrick's referring to is classic STP (Spanning Tree Protocol) taking a long time to deal with link negotiation, and for you to consider using RSTP (Rapid Spanning Tree Protocol) instead. This advice doesn't apply if spanning tree isn't enabled on your switches; whether or not it is by default is unknown to us. Please refer to your switch documentation and/or vendor. Alternately, depending on the model of switch used, there are other protocols which can cause this behaviour as well. One such protocol is LLDP (Link Layer Discovery Protocol). I ran into this issue on our HP ProCurve switches; disabling LLDP ("no lldp run") solved slow link negotiation. Other such protocols link disovery protocols are EDP, NDP (SONMP) and LLTD. Turn them all off if you don't need them. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |