On Mon, 2009-05-25 at 16:58 +0200, Tore Anderson wrote:
> > the link states of network devices. The major drawback is that it also
> > has a IPVS module which is printing harmless error messages when the
> > underlying kernel doesn't support IPVS but I suppose you could prevent
> > that if you'd compile keepalived yourself.
>
> I knowthat keepalived has a command line option to only start the VRRP
> parts of the code (-P). Perhaps that will silence the warnings?
It doesn't but I am simply ignoring them (they are only
printed at startup anyway).
> The lack of IPv6 support is something I miss, too. I plan to deal with
> it by adding/removing the HA IPv6 addresses from shell scripts ithat
> runs when the state changes (the settings notify_{master,backup,fault}).
> I didn't try it yet but I see no reason why it wouldn't work.
It does work as that's what I am doing now ;) (Debian 5.0 nodes
with packaged keepalived). Also the Linux IPv6 stack automatically
sends something equivalent to a gratuitous ARP request anyway
(some ICMPv6 type deals with announcing address changes on the link).
> You'll
> need to piggy-back it on an IPv4 VIP though (just use dummy addresses
> from 169.254.0.0/16 or RFC1918 space for single-stack IPv6 networks).
I'm using a dual stack approach so I don't have that problem.
> > Finally the problem with all these implementations is that they don't
> > support virtual MAC addresses in the way VRRP is usually provides
> > by router vendors and thus have to send gratuitous ARP requests
> > to inform their networks about the new MAC address after a failover.
>
> I think this is due to a limitation in the Linux kernel - it is simply
> not possible to have a multiple unicast layer-2 addresses assigned to a
> single network interface. Go bug the people on netdev - I'm sure
> keepalived will support VMAC immediately after the necessary kernel
> changes have been made.
Am aware of this but I simply don't have the time right now, but
surely would be a nice thing to have, also from a security perspective
(relying on what makes ARP-Spoofing possible for your fundamental
infrastructure is not nice ;)
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
