From owner-freebsd-net@freebsd.org Wed Jun 8 16:19:52 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 42E1FB6F89D for ; Wed, 8 Jun 2016 16:19:52 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 194521DC1 for ; Wed, 8 Jun 2016 16:19:51 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.14.7/8.14.7) with ESMTP id u58GGlka056383 for ; Wed, 8 Jun 2016 11:16:47 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.16.32.30] (unknown [172.126.77.65]) by mail.shrew.net (Postfix) with ESMTPSA id A2F9718C61E for ; Wed, 8 Jun 2016 11:16:36 -0500 (CDT) Subject: Re: Getting CARP to broadcast on a different interface To: freebsd-net@freebsd.org References: <20160608124310.GG2050@box-hlm-03.niklaas.eu> From: Matthew Grooms Message-ID: Date: Wed, 8 Jun 2016 11:19:44 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx2.shrew.net [10.24.10.11]); Wed, 08 Jun 2016 11:16:47 -0500 (CDT) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 16:19:52 -0000 On 6/8/2016 10:15 AM, David DeSimone wrote: > One of the purposes of the CARP announcements is to announce the > location of the virtual mac address to the upstream switch fabric. > Since CARP uses a virtual mac that floats between multiple ports, you > need to have the CARP master continually assert that its particular > port is the target that should be used for delivery of packets to the > virtual MAC address. Without this function, switches might still > mistakenly deliver their frames to the standby node. > > The CARP announcements are also helpful in detecting and routing > around some odd failure scenarios, such as a failure within the > upstream fabric, where the master sees link on its port, but can't > actually send frames that reach the rest of the network. If the > standby can't hear the master's announcements any more, it can > promote itself to master and hopefully keep your cluster online. > This would not happen without the announcement feature. > > I would hope you could explain this to your provider and get them to > white-list CARP announcements because they are defeating important > safety features you wish to use. > You just need a gratuitous ARP on the new switch port after the MAC is migrated. That's how VMs move quickly between hypervisors with almost no downtime. As soon as a MAC is seen on a new port, the switch should overwrite it's notion of the port to MAC association. https://wiki.wireshark.org/Gratuitous_ARP As for the standby node, it should never announce unless the master node fails to suppress it. -Matthew