On Wed, Jun 28, 2006 at 10:22:28AM +0100, Dr A V Le Blanc wrote:
> }
> virtual_ipaddress {
> 130.88.203.138
> 130.88.203.219
> }
...
> Now the master starts up perfectly happily, but the file
> /var/log/messages has thousands of errors like this:
>
> Jun 28 09:18:32 rust Keepalived_vrrp: receive an invalid ip number count
> associated with VRID!
> Jun 28 09:18:32 rust Keepalived_vrrp: bogus VRRP packet received on eth0 !!!
> Jun 28 09:18:32 rust Keepalived_vrrp: VRRP_Instance(VI_1) Dropping received
> VRRP packet...
>
> The backup director starts up, but doesn't listen on the virtual addresses
> at all. Its /var/log/messages has thousands of errors like this:
>
> Jun 28 06:25:05 stye Keepalived_vrrp: receive an invalid ip number count
> associated with VRID!
> Jun 28 06:25:05 stye Keepalived_vrrp: bogus VRRP packet received on eth0 !!!
> Jun 28 06:25:05 stye Keepalived_vrrp: VRRP_Instance(VI_1) ignoring received
> advertisment...
I have discovered that if I specify the netmask in the virtual_ipaddress
blocks, as some of the configs in the archives do, then the abovementioned
errors go away, and I see in the log files:
on the presumed MASTER server:
Jun 28 14:36:16 rust Keepalived_vrrp: Using MII-BMSR NIC polling thread...
Jun 28 14:36:16 rust Keepalived_vrrp: Registering Kernel netlink reflector
Jun 28 14:36:16 rust Keepalived_vrrp: Registering Kernel netlink command
channelJun 28 14:36:16 rust Keepalived_vrrp: Registering gratutious ARP shared
channel
Jun 28 14:36:16 rust Keepalived_vrrp: Configuration is using : 38142 Bytes
Jun 28 14:36:17 rust Keepalived_vrrp: VRRP_Instance(VI_1) Transition to MASTER
STATE
Jun 28 14:36:18 rust Keepalived_vrrp: VRRP_Instance(VI_1) Entering MASTER STATE
Jun 28 14:36:18 rust Keepalived_vrrp: VRRP_Group(VG1) Syncing instances to
MASTER state
and on the presumed BACKUP server:
Jun 28 15:40:50 stye Keepalived_vrrp: Using MII-BMSR NIC polling thread...
Jun 28 15:40:50 stye Keepalived_vrrp: Registering Kernel netlink reflector
Jun 28 15:40:50 stye Keepalived_vrrp: Registering Kernel netlink command
channelJun 28 15:40:50 stye Keepalived_vrrp: Registering gratutious ARP shared
channel
Jun 28 15:40:50 stye Keepalived_vrrp: Configuration is using : 38141 Bytes
Jun 28 15:40:50 stye Keepalived_vrrp: VRRP_Instance(VI_1) Entering BACKUP STATE
Jun 28 15:40:54 stye Keepalived_vrrp: VRRP_Instance(VI_1) Transition to MASTER
STATE
Jun 28 15:40:54 stye Keepalived_vrrp: VRRP_Group(VG1) Syncing instances to
MASTER state
Jun 28 15:40:55 stye Keepalived_vrrp: VRRP_Instance(VI_1) Entering MASTER STATE
In other words, this now solves the problem of the error messages, but
failover is still not taking place. Both keepaliveds are trying
to manage the addresses, and whichever is started last works.
The keepalived vrrp function seems simply not to work.
-- Owen
|