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

[Francois J. <Fra...@12...>]

> well, i would say the following parts at least suggest that they are
> mandatory?
>=20
> ftp://ftp.ietf.org/rfc/rfc2338.txt
>=20
> 7.3 Virtual Router MAC Address
>=20
>     The virtual router MAC address associated with a virtual router is =
an
>     IEEE 802 MAC Address in the following format:
>=20
>        00-00-5E-00-01-{VRID} (in hex in internet standard bit-order)

Well, I would love not to see it implemented :).

> 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.

No, not ar all. When you plug the master again, it will receive an =
advert
from the other master (machine2) and then will force a new election. So, =
it
will send 3 adverts with its highest priority and send the gratuitous =
ARPs to
the network. This will clean the caches.

> 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.

Well, keepalived is your friend :). I have some things to say about =
Europe,
software patents, and so on, but... well, out of list perhaps :). =
Keepalived
is our friend, for sure.
=20
> if i may continue to ask questions :)

You're welcome.
=20
> 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.
>=20
> is this possible with keepalived? would you take such an =
implementation
> proposal into consideration for the future?

Well, I never find a way to do it in keepalived. What I do is to check =
the
service from a supervisor (Nagios) and make it flip (by stopping =
keepalived)
if the supervisor detects that the application is down. In fact, this =
let me
do some other tests, manage service depedencies, restart failed =
application
on the (one that became) backup and so on.

Fran=E7ois.