Stuart Henderson wrote:
Multicast MAC addresses use a special 24-bit prefix of 0x0100.5Enn.nnnn.
which has the lowest bit of the first byte set to '1'.
afaict: CARP traffic itself goes to the group hence 1, whereas traffic to
the shared address is just for an individual member, hence the 0. But I am
no multicast guru.
...ah, but of course the virtual address is what you're concerned about
(assuming you are preventing 01:00:5e CARP protocol packets from reaching
the peering lan some other way e.g. by a switch that doesn't forward
multicast out of the public port).
Exactly. But the issue would still be the same even if I stop it as the
virtual IP's would still have the MAC address of the 0x0000.5Enn.nnnn
here where it might be block by the provider. I am still curious to know
if that couldn't work with the MAC address of the equipment it is
replacing. One thing I don't know, I never set it up to check that
specifically, does Cisco with VRRP actually end up with a MAC address
different then the actual interface and does use the multicast range?
Knowing Cisco, I kind of guess it wouldn't, but that's speculation on my
part, I do not know that for sure! So, that makes me think it would be
possible, but what would be the implications of it, that I do not know
yet. One side however, no one on the public side would ever know then,
assuming you do block the multicast packets from reaching them on the
public side! (:>
I would be very much interested to know the pro/cons of doing so as well
as the implications of it.
So, it looks like your original question stands then. Looking at
carp_set_enaddr in /usr/src/sys/netinet/ip_carp.c the MAC address
generation is hardcoded (the last octet being the vhid). Maybe it's
simply the case that because lladdr is new, and no developer found
a need to do this for CARP yet, that it hasn't been coded. Or maybe
there's another reason why this shouldn't be done (greater care
than usual would have to be taken to configure all CARP members
identically, of course).
Or, may be following the mapping of multicast IP addresses to IEEE 802
multicast MAC addresses might well take care of the possibility in all
cases, ( well almost, still would be 32 possible overlaps for the range
of IPv4, but what are the chances of that ever happen, none in the same
peering point for sure. Not that it is bad as it is now by any mean
really! There might be some other reasons for sure as well. One that
comes to mind is keep it simple, is sure worth less trouble.
