|
Alexandre Cassen wrote:
>
> > 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 it's listening to 0.0.0.0 on one interface (say eth0)
> > 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.
OK, will update the HOWTO
> > 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.
OK so you still have the split brain problem
I have just the vrrpd part of keepalived running on a pair of routers.
These machines are also running dhcpd (and a few other services) in failover
mode each with their own failover mechanism. It would be nice to have them
all failover together in from a central monitoring process, rather than
each application failing over independantly. I know this isn't your problem,
but it would be nice if each application didn't write its own failover.
> >from Vinnie's HOWTO
> >
> >mcast_src_ip doesn't do it. vrrpd still is listening on 0.0.0.0
>
> This option is used if you want to mangle the src ip present in
> outgoing VRRP advert. By default it used the primary interface
> IP. You can use this for security reason to completly hide the
> real IP. Since this is multicast traffic this is permitted design.
OK
> >/etc/init.d/keepalive status
> >
> >where it returns master|backup and a list of the other nodes that
> >it is in contact with (and their status)?
>
> All operations are logged into syslog. You can see state transition
> and interface state into syslog /var/log/message (by default).
it would be nice to be able to ask the state in a programatic way.
> >Is there a way to force a transition master<->backup, without killing
> >the keepalived on any of the nodes?
>
> you can for master->fault by setting down interface VRRP instance
> is running on.
>
> Or you can modify the priority in the keepalived.conf and reload
> on the fly keepalived.
OK
> >Is there a list of the commands available for keepalived.conf?
>
> The fact is that due to hard development process, I have not updated
> PDF file for a while. All Keepalived keyword and command can be
> found in the tarball in the doc directory in file keepalived.conf.SYNOPSIS.
got it thanks
would it be better to move subsequent questions to the keepalived mailing list?
Joe
--
Joseph Mack PhD, High Performance Computing & Scientific Visualization
SAIC, Supporting the EPA Research Triangle Park, NC 919-541-0007
Federal Contact - John B. Smith 919-541-1087 - smith.johnb@xxxxxxx
|
