|
Hi Joe,
> questions
>
> vrrpd listens on raw 0.0.0.0:112 (two instances).
>
> I assume I can put "vrrpd" into /etc/services?
yes
> Is this socket the channel that vrrpd uses to exchange roles with
> backup/master?
VRRP adverts are sent/received on this protocol socket, using multiplexing, ...
> Since this is listening on 0.0.0.0 rather than say 192.168.1.0/24, I will
> have to add filter rules to stop machines on the non-admin interfaces
> from accessing it. Is it possible/sensible to specify IP/interface to
> which it
> binds?
VRRP is interface specific (like HSRP and others hot standby protocol). So
when you configure a VRRP instance on interface eth0 for example, VRRP
will create a raw vrrp-proto socket and bind the socket to interface eth0
(using bindtodevice kernel call). Then it join the VRRP multicast group.
So this socket will receive VRRP adverts only on eth0. The same thing is
done for sending socket, vrrp proto sending socket is bound to interface
VRRP instance belong to. Additionnaly if you have more than one VRRP instance
on the same interface (for active/active setup) then VRRP code will create
a new socket it will multiplex on the already created socket.
So to sum up, VRRP is interface specific and use a socket pair for
sending/receiving adverts bound to interface it belong to.
> In the early days, vrrpd put a private MAC address onto the interface
> with the
> movable IP (here the VIP) and thus the MAC address for the connection to the
> VIP didn't change on failover. The -1.1.4 version doesn't do this. Did it
> just not get implemented?
We had long discussion on this with Julian, and Jamal. The way previous code
handled VMAC was not really clean. It consisted of changing interface MAC
address inside the kernel to fake the need one... This is not clean and
not scalable since this restrict to use only one VMAC per interface since
multiple VMAC is not supported. Later, we done some offline work with Julian
and he produced his nice iparp netlink patch that offer arp reply to VMAC.
but this was not enought because all the traffic stuck with the interface
MAC. Later, on the netdev ML, we discussed with Julian and Jamal, and the
best solution were to provide a patch at the ingress/egress code to support
this VMAC need. This code still need to be written.
The current VRRP code work with gratuitous ARP. Gratuitous ARP are well
supported by routing equipment... only one packet is lost during takeover.
> What triggers failover? Are the two machines exchanging packets like
> heartbeat
> and then one machine disappears, the other takes over? Is there a split
> brain
> problem?
VRRP is based on 1s advert sending over multicast. This is an election
protocol. Master own the higher priority, when master crash an election
is done to find the new higher priority VRRP master.
Best regards,
Alexandre
|
