Re: [Keepalived-devel] Re: Question concerning virtual mac address

[Christian S. <Chr...@gm...>]

Francois JEANMOUGIN wrote:
> First of all VMAC is a pain on network without IGMP and IGMP can be a pain to
> implement. So, noone who had to manage VMAC services with high loaded server
> and mixed routers would recommend it. That is for the poor interest in VMAC
> on the list.
> 
> What in the RFC make VMAC mandatory ?

well, i would say the following parts at least suggest that they are
mandatory?

ftp://ftp.ietf.org/rfc/rfc2338.txt

7.3 Virtual Router MAC Address

    The virtual router MAC address associated with a virtual router is an
    IEEE 802 MAC Address in the following format:

       00-00-5E-00-01-{VRID} (in hex in internet standard bit-order)

8.2  Host ARP Requests

    When a host sends an ARP request for one of the virtual router IP
    addresses, the Master virtual router MUST respond to the ARP request
    with the virtual MAC address for the virtual router.

> ARP caching is not a problem because equipments that are doing arp caching
> SHOULD accept gratuitous arp. For my experience, the one I know do.

i don't know about your implementation, but i would guess that
gratuitous arp packets are only sent if the deamon takes control for the
virtual ip?

now suppose you plug off the ethernet cable of the machine which is
currently the master. now both (at least two) machines think that they
are the master; the original master just keeps to be the master and the
vrrp daemon with the highest priority (call it machine2) will take over
the virtual ip, because the master is not accessible anymore. machine2
has sent a gratuitous arp packet and therefore the router caches this
packet. if you then plug in the network cable again machine2 will take
down the virtual ip and the original master will not send a gratuitous
arp packet, because it was always the master. but if you try now to
access the virtual ip the router will send the packets to the wrong mac
address.

i have to say, that i did not do any real tests with keepalived, but i
have this problem with vrrpd:
https://sourceforge.net/projects/vrrpd/
which was the starting point of my search for an alternative.

if i may continue to ask questions :)

i would like to have a solution where the vrrp daemon runs on the same
machine as the service (apache) and therefore i would like to have the
option to configure the checks in the vrrp_instance NAME {} section. if
then a failure of the actual service occurs the vrrp daemon instance of
this server just goes into back-up mode and another machine takes over.
i do not need the lvs/load balancing functionality and i have a kernel
which does not support lvs. i would like to be able to have the same
checks that go normally into the virtual_server IP {} section to trigger
a "go to backup-mode" or "go to master-mode" of the vrrp daemon.

is this possible with keepalived? would you take such an implementation
proposal into consideration for the future?

thanks for your time and effort!
-- 
Christian Schuhegger
http://www.el-chef.de/