Keepalived keeps forcing new elections despite priority not 255

[peter <peter@xxxxxxxxxxxxxxxxxxxxxxx>]

I have two boxes that are also trying to be firewalls, load balancers 
and provide high
availability via keepalived.

Either box alone works, but if I have keepalived running on both they 
get into a
non-stop effort to force new elections.

Both boxes are 64bit (x86_64 AMD Opteron(tm)) with a 2.6.12-gentoo-r4 kernel
running Keepalived v1.1.11 all compiled at the same time.

They seemed to work once for a bit, then started failing.
I suspect failed multicasting between them, but cant determine what 
traffic actually
has to get passed on which interfaces when...
(Other thoughts are uint8 vs int instances of priority in vrrp.c - I am 
on a 64 bit processor?
Configuration confusion - I'm a newbie at this.)

Any help appreciated,

Some details -

On the preffered (MASTER) server the log gets filled with:

Jul 23 18:45:48 fw1 Keepalived_vrrp: VRRP_Instance(CI_1) Recieved lower 
prio advert, forcing new election
On the other (BACKUP) server the log fills with repeating sequences of:

Jul 23 18:45:47 fw2 Keepalived_vrrp: VRRP_Instance(VI_GW) Entering 
BACKUP STATE
Jul 23 18:45:48 fw2 Keepalived_vrrp: VRRP_Instance(VI_GW) Transition to 
MASTER STATE
Jul 23 18:45:48 fw2 Keepalived_vrrp: VRRP_Group(VG1) Syncing instances 
to MASTER state
Jul 23 18:45:48 fw2 Keepalived_vrrp: VRRP_Instance(VI_1) Transition to 
MASTER STATE
Jul 23 18:45:48 fw2 Keepalived_vrrp: VRRP_Instance(VI_1) Received higher 
prio advert
Jul 23 18:45:48 fw2 Keepalived_vrrp: VRRP_Instance(VI_1) Entering BACKUP 
STATE
Jul 23 18:45:48 fw2 Keepalived_vrrp: VRRP_Group(VG1) Syncing instances 
to BACKUP state
Jul 23 18:45:48 fw2 Keepalived_vrrp: VRRP_Instance(VI_GW) Entering 
BACKUP STATE
Jul 23 18:45:49 fw2 Keepalived_vrrp: VRRP_Instance(VI_GW) Transition to 
MASTER STATE
Jul 23 18:45:49 fw2 Keepalived_vrrp: VRRP_Group(VG1) Syncing instances 
to MASTER state
Jul 23 18:45:49 fw2 Keepalived_vrrp: VRRP_Instance(VI_1) Transition to 
MASTER STATE
Jul 23 18:45:49 fw2 Keepalived_vrrp: VRRP_Instance(VI_1) Received higher 
prio advert
Jul 23 18:45:49 fw2 Keepalived_vrrp: VRRP_Instance(VI_1) Entering BACKUP 
STATE
Jul 23 18:45:49 fw2 Keepalived_vrrp: VRRP_Group(VG1) Syncing instances 
to BACKUP state
The keepalived.conf on both servers is pretty simple.
Here is the secondary server (primary is same except:
   router_id fw1
   state MASTER
   priority  150
):

! Configuration File for keepalived on fw2

global_defs {
  notification_email {
    peter@xxxxxxxxxxxxxxxxxxxxxxx
  }
  notification_email_from peter@xxxxxxxxxxxxxxxxxxxxxxx
  smtp_server mail.ebagle.com
  smtp_connect_timeout 30
  router_id fw2
}

vrrp_sync_group VG1 {
   group {
       VI_1
       VI_GW
   }
}

vrrp_instance VI_1 {
   state BACKUP
   interface eth2
   lvs_sync_deamon_interface eth5
   virtual_router_id 51
   priority 100
   advert_int 1
   authentication {
       auth_type PASS
       auth_pass xxxxxxxx
   }
   virtual_ipaddress {
       64.13.136.10
   }
}

vrrp_instance VI_GW {
   state BACKUP
   interface eth0
   lvs_sync_deamon_interface eth5
   virtual_router_id 52
   priority 100
   advert_int 1
   authentication {
       auth_type PASS
       auth_pass xxxxxxxx
   }
   virtual_ipaddress {
       10.1.0.254
   }
}

virtual_server 64.13.136.10 80 {
   delay_loop 6
   lb_algo rr
   lb_kind NAT
   persistence_timeout 50
   protocol TCP


   real_server 10.1.0.14 80 {
       weight 1
       TCP_CHECK {
       connect_port 80
           connect_timeout 3
       }
   }
}

! end of keepalived.conf