Re: [Keepalived-devel] multicast packets not sent by lvs director

[Nicolas <ara...@ya...>]

Francois JEANMOUGIN wrote:

>Nicolas :
>  
>
>>I have the same problem with keepalived 1.1.11
>>Any ideas ?
>>    
>>
>
>It looks like your dameons try to get MASTER on both instances at the time,
>as if you included those in the same vrrp_sync_group. Try to define two
>vrrp_sync_group, each one with only one instance to force it.
>
>  
>
Thanks for your reply Francois :)

So, i have appended this in the configuration of the two LVS directors :

vrrp_sync_group VSGF {
  group {
    LVS_F
  }
}

vrrp_sync_group VSGB {
  group {
    LVS_B
  }
}

But I saw that in my logs :

( I have changed the advertissement interval to 5sec )

Apr 27 18:39:50 bar Keepalived_vrrp: VRRP_Instance(LVS_F) Transition to 
MASTER STATE
Apr 27 18:39:50 bar Keepalived_vrrp: VRRP_Group(VSGO) Syncing instances 
to MASTER state
Apr 27 18:39:55 bar Keepalived_vrrp: VRRP_Instance(LVS_F) Entering 
MASTER STATE
Apr 27 18:42:15 bar Keepalived_vrrp: VRRP_Instance(LVS_F) Received 
higher prio advert
Apr 27 18:42:15 bar Keepalived_vrrp: VRRP_Instance(LVS_F) Entering 
BACKUP STATE
Apr 27 18:42:15 bar Keepalived_vrrp: VRRP_Group(VSGO) Syncing instances 
to BACKUP state


Apr 27 18:39:50 foo Keepalived_vrrp: VRRP_Instance(LVS_F) Received lower 
prio advert, forcing new election
Apr 27 18:40:05 foo Keepalived_vrrp: VRRP_Instance(LVS_F) Received lower 
prio advert, forcing new election
Apr 27 18:40:10 foo Keepalived_vrrp: VRRP_Instance(LVS_F) Received lower 
prio advert, forcing new election
Apr 27 18:40:20 foo Keepalived_vrrp: VRRP_Instance(LVS_F) Received lower 
prio advert, forcing new election
[...]
Apr 27 18:42:00 foo Keepalived_vrrp: VRRP_Instance(LVS_F) Received lower 
prio advert, forcing new election
Apr 27 18:42:05 foo Keepalived_vrrp: VRRP_Instance(LVS_F) Received lower 
prio advert, forcing new election
Apr 27 18:42:10 foo Keepalived_vrrp: VRRP_Instance(LVS_F) Received lower 
prio advert, forcing new election

Between 2min30, the 2 directors havnt be able to comunicate each other ( 
no multicast packet send ) and "bar" become master on LVS_B and LVS_F , 
but "foo" was already master on LVS_F instance during this time.

Same problems of synchronisation , so ... any clue ?

Regards,
    Nicolas