From owner-freebsd-questions@freebsd.org Wed Jun 8 16:30:38 2016 Return-Path: Delivered-To: freebsd-questions@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 367F9B6FB8A; Wed, 8 Jun 2016 16:30:38 +0000 (UTC) (envelope-from stdin@niklaas.eu) Received: from box-hlm-03.niklaas.eu (box-hlm-03.niklaas.eu [84.22.110.84]) by mx1.freebsd.org (Postfix) with ESMTP id D6E79152D; Wed, 8 Jun 2016 16:30:37 +0000 (UTC) (envelope-from stdin@niklaas.eu) Received: by box-hlm-03.niklaas.eu (Postfix, from userid 1001) id A04CE38841C; Wed, 8 Jun 2016 18:30:33 +0200 (CEST) Date: Wed, 8 Jun 2016 18:30:33 +0200 From: Niklaas Baudet von Gersdorff To: freebsd-net@freebsd.org, "freebsd-questions@freebsd.org" Subject: Re: Getting CARP to broadcast on a different interface Message-ID: <20160608163033.GC8540@box-hlm-03.niklaas.eu> Mail-Followup-To: freebsd-net@freebsd.org, "freebsd-questions@freebsd.org" MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rz+pwK2yUstbofK6" Content-Disposition: inline In-Reply-To: <7a877e3c-9c77-c104-e47e-94c9d9389656@shrew.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 16:30:38 -0000 --rz+pwK2yUstbofK6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Matthew Grooms [2016-06-08 11:02 -0500] : > Rewriting the multicast destination would be a neat trick, but sadly no.= =20 > You can't rewrite a destination address on egress. Using a route-to rule= =20 > would only modify the destination MAC address. If you were using=20 > OpenBSD, you would switch from multicast to unicast using the syncpeer=20 > option. Unfortunately that's not supported on FreeBSD. >=20 > At one point I wrote a broadcast relay daemon to forward select UDP=20 > broadcast traffic between two networks separated by an IPsec tunnel. It= =20 > had limited utility, but it worked well for what I needed it to do. I=20 > wonder if someone has written a multicast relay daemon that works in a=20 > similar fashion. If so, you could use it to forward CARP traffic to a=20 > peer. Super ugly, but it would probably do the trick in this scenario. Thank you for your explanation. I am far from understanding the underlying mechanisms to really get my head around possible solutions -- your comments helped. And, as you said, maybe there is someone else who came across this problem and has implemented a workaround. David DeSimone [2016-06-08 15:15 +0000] : > 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. >=20 > 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. >=20 > 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. Thank you too, David. I have already contacted my provider about this and they asked me to use keepalived -- which is deprecated in ports... I shall keep them updated about my progress in solving the issue though. Maybe I am lucky and can convince them to white-list the packets at some point. At this stage I am thinking about running CARP on the additional private virtual interface vtnet1 that I got from my provider. As I understood it, nothing is black-listed on these interfaces so CARP packets should go through. Then, I could use devd to assign the public failover IP (that I actually wanted to share with CARP on vtnet0) to the public interface vtnet0. CARP(4) provides an example on how to use carp status change events for additional scripting: --------------------8<-------------------- Processing of carp status change events can be set up by using the fol- lowing devd.conf rule: notify 0 { match "system" "CARP"; match "subsystem" "[0-9]+@[0-9a-z]+"; match "type" "(MASTER|BACKUP)"; action "/root/carpcontrol.sh $subsystem $type"; }; -------------------->8-------------------- Depending von $type, carpcontrol.sh could either ifconfig vtnet0 alias or ifconfig vtnet0 -alias I am not sure whether that works but I'll post my solution if I find one. In the meanwhile, I appreciate any further comment. Niklaas --rz+pwK2yUstbofK6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXWEfsAAoJEG2fODeJrIU/Ap4P/RCuNYYBzRfjA61VHVUY1srs ycSSwi7XfIBndLlg1IKw5qvEr7hxg+TDcvEIfXcffsOZDHI6wLqlMe0JBuqqA0u8 9ddUREf712d68HeCY4R05ij5worNbFYeOvTrE9FaaFEzwP47GRRtn1QLotzy+vww lQnZ9HfekHAUdY8XrflVnFOoISffrtQWfokxu+mp3itZy/73K5eTus69vgZ6WY97 FsgKc9vvs19KnVBtvGQ5KZnksnn5qEgJYxujGt1gtQ7GulB4oi8cijqX2pXBnxLI yfmIDIKOzyW1kPnK3/Er7AwAy6YvhcPYpVhQbKqmHHY0Qg8W7O0RVhrL3poY7pC0 b3Q1EfA2YRbTMwsJPCaMIIVeGQXwph2cqycgah+EpqNx90KpiTk8ijgk9I3rILGr a78768FyqVGOPeJKG3iardCssOdot768Q6ekiLQPOIysJKMu3adrOKqLI6OkVhht NKhrCrmQdFoObEYMHAIWROZIiGTGWQoul14NgLQ5BaMhOlbdVAcxwaokMl3vE2cF LaV9V/PL/lcQCfmJ5+ILq04DjxYTuzY79zsxiu6r1x/jPEjTNgtEILFyRoARlTCU nInOUXEfP076zynfyV+iI0SeAdpwMB93hPsTlUK6AinFjBOWRo0xZdfGRaSpk2+R 3I+JZ8AyQZWnaDawmQNI =MAtn -----END PGP SIGNATURE----- --rz+pwK2yUstbofK6--