Bug 1734560 - Garp should be send when 1 of the keepalived servers stops being master
Summary: Garp should be send when 1 of the keepalived servers stops being master
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: keepalived
Version: 7.6
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Ryan O'Hara
QA Contact: Brandon Perkins
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-30 21:14 UTC by mvillagran
Modified: 2020-02-11 18:53 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github 542 None None None 2020-02-11 18:48:23 UTC
Github acassen keepalived issues 542 None closed garp should be send when 1 of the keepalived servers stops being master 2020-02-11 18:48:24 UTC

Description mvillagran 2019-07-30 21:14:35 UTC
Description of problem:

In a Keepalived Master/backup config, on Vmware, sometimes when take a Snapshot on Master Node, it's freeze for a few seconds and Keepalived backup node entering in Master ROLE for fews seconds but don't inform this to  Master node  for what  resend garp VIP.


Version-Release number of selected component (if applicable):

keepalived-1.3.5-8.el7_6.x86_64

How reproducible:

server1 => Master
server2 => Backup

Steps to Reproduce:
1. Take Snapshot to server1
2. View syslog on server2. he become a master
3. server2, become a backup again.

Actual results:
server1 don't resend garp.

Expected results:
The server2 should send some inform to server1: 'I was master, please garp your VIP's again.

Additional info: https://github.com/acassen/keepalived/commit/da3fd4bd15be70cf6d2c24a76726dce20d971ce5

Comment 2 Ryan O'Hara 2019-08-26 14:19:37 UTC
Has customer support been contacted about this issue? That is the first step.

Second, you should be able to find a workaround by using the vrrp_garp_* settings. There are several that will allow you to have the master send multiple gratuitous ARPs, either after transition to MASTER or repeatedly while in MASTER state. There are also options to control the frequency, etc.

Comment 3 Ryan O'Hara 2020-01-02 18:38:20 UTC
Are you using VRRP sync groups? The patch you referenced only affects VRRP sync groups. Please attach your keepalived.conf file.

Comment 4 Klaus Brombeere 2020-01-27 18:01:25 UTC
(In reply to Ryan O'Hara from comment #3)
> Are you using VRRP sync groups? The patch you referenced only affects VRRP
> sync groups. Please attach your keepalived.conf file.

Yes I do...

This is my master cfg:

vrrp_script chk_haproxy {
  script "killall -0 haproxy" # check the haproxy process
  interval 2 # every 2 seconds
  weight 2 # add 2 points if OK
}

vrrp_instance VI_1 {
  interface ens192 # interface to monitor
  state MASTER # MASTER on haproxy-01, BACKUP on haproxy-02
  virtual_router_id 51
  priority 101 # 101 on haproxy-01, 100 on haproxy-02
  virtual_ipaddress {
        172.20.1.76
	172.20.1.106

  }
  track_script {
    chk_haproxy
  }
}

And this is my slave cfg:

vrrp_script chk_haproxy {
  script "killall -0 haproxy" # check the haproxy process
  interval 2 # every 2 seconds
  weight 2 # add 2 points if OK
}

vrrp_instance VI_1 {
  interface eno16780032 # interface to monitor
  state MASTER # MASTER on haproxy-01, MASTER on haproxy-01
  virtual_router_id 51
  priority 100 # 101 on haproxy-01, 100 on haproxy-02
  virtual_ipaddress {
        172.20.1.76
	172.20.1.106
  }
  track_script {
    chk_haproxy
  }
}


Thanks!

Comment 5 Ryan O'Hara 2020-02-11 18:53:47 UTC
I don't see any VRRP sync groups in the configuration file posted in comment #4. Check the man page for "VRRP synchronization group(s)" (keyword: vrrp_sync_group). My understanding is that the upstream commit referenced in comment #1 only changes the behavior if you are using VRRP sync groups.

https://github.com/acassen/keepalived/commit/da3fd4bd15be70cf6d2c24a76726dce20d971ce5

Check lines 1923-1926 in that commit. Without VRRP sync group, this patch will not change the behavior.


Note You need to log in before you can comment on or make changes to this bug.