Page MenuHomePhabricator

Add GARP settings to VRRP/keepalived
On hold, NormalPublicFEATURE REQUEST

Description

Hello!

It will be good to have ability to configure followed GARP settings for individual VRRP groups or, at least for keepalived daemon overall. These options can help in situations when for some of the reason clients have wrong records in an ARP table.

Global options:

# delay for second set of gratuitous ARPs after transition to MASTER.
# in seconds, 0 for no second set.
# (default: 5)
vrrp_garp_master_delay 10

# number of gratuitous ARP messages to send at a time after
# transition to MASTER.
# (default: 5)
vrrp_garp_master_repeat 1

# delay for second set of gratuitous ARPs after lower priority
# advert received when MASTER.
vrrp_garp_lower_prio_delay 10

# number of gratuitous ARP messages to send at a time after
# lower priority advert received when MASTER.
vrrp_garp_lower_prio_repeat 1

# minimum time interval for refreshing gratuitous ARPs while MASTER.
# in seconds.
# (default: 0 (no refreshing))
vrrp_garp_master_refresh 60

# number of gratuitous ARP messages to send at a time while MASTER
# (default: 1)
vrrp_garp_master_refresh_repeat 2

# Delay in ms between gratuitous ARP messages sent on an interface
# decimal, seconds (resolution usecs).
# (default: 0)
vrrp_garp_interval 0.001

# Delay in ms between unsolicited NA messages sent on an interface
# decimal, seconds (resolution usecs).
# (default: 0)
vrrp_gna_interval 0.000001

# By default keepalived sends 5 gratuitions ARP/NA messages at a
# time, and after transitioning to MASTER sends a second block of
# 5 messages 5 seconds later.
# With modern switches this is unnecessary, so setting vrrp_min_garp
# causes only one ARP/NA message to be sent, with no repeat 5 seconds
# later.
vrrp_min_garp [<BOOL>]

# If a lower priority advert is received, don't send another advert.
# This causes adherence to the RFCs. Defaults to false, unless
# strict_mode is set.
vrrp_lower_prio_no_advert [<BOOL>]

# If we are master and receive a higher priority advert, send an advert
# (which will be lower priority than the other master), before we
# transition to backup. This means that if the other master has
# garp_lower_priority_repeat set, it will resend garp messages.
# This is to get around the problem of their having been two simultaneous
# masters, and the last GARP messages seen were from us.
vrrp_higher_prio_send_advert [<BOOL>]

Per interface:

# interface specific settings, same as global parameters.
# default to global parameters
garp_master_delay 10
garp_master_repeat 1
garp_lower_prio_delay 10
garp_lower_prio_repeat 1
garp_master_refresh 60
garp_master_refresh_repeat 2
garp_interval 100
gna_interval 100

Manpage with detailed description: http://www.keepalived.org/manpage.html

Details

Difficulty level
Unknown (require assessment)
Version
-
Why the issue appeared?
Will be filled on close

Event Timeline

zsdc created this task.Mar 12 2019, 7:03 PM
zsdc updated the task description. (Show Details)Mar 12 2019, 7:08 PM
pasik added a subscriber: pasik.Mar 17 2019, 3:01 PM
syncer assigned this task to hagbard.Apr 17 2019, 7:46 PM
syncer changed the task status from Open to Confirmed.
syncer triaged this task as Normal priority.

It will be good to have ability to configure followed GARP settings for individual VRRP groups or, at least for keepalived daemon overall, becouse in some situation switches can filter multiple ARP-packets, that is generated on transition.
In the process of migration to 1.2.1 we have discovered, that some GARP packets (we have 6 VRRP-groups on Interner interface) was filtered with ARP-spoofing filter by our ISP.
Problem was solved with VRRP-migration scripts, that execute some additional arping in ARP-Reply mode.

hagbard changed the task status from Confirmed to In progress.Apr 24 2019, 5:36 PM
hagbard added a comment.EditedApr 24 2019, 5:48 PM

The garps should be send as they are being set per default to the values you have pasted from the documentation. Do you want to make that a config option to modify the defaults?

hagbard changed the task status from In progress to On hold.Apr 29 2019, 4:20 PM
hagbard reassigned this task from hagbard to zsdc.May 13 2019, 4:19 PM
hagbard added a subscriber: hagbard.