Date: Wed, 8 Jun 2016 18:30:33 +0200 From: Niklaas Baudet von Gersdorff <stdin@niklaas.eu> To: freebsd-net@freebsd.org, "freebsd-questions@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> In-Reply-To: <SN1PR08MB1821CE60861ADDD84BA20CEEBA5E0@SN1PR08MB1821.namprd08.prod.outlook.com> <7a877e3c-9c77-c104-e47e-94c9d9389656@shrew.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <public-ip> alias
or
ifconfig vtnet0 <public-ip> -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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160608163033.GC8540>