Page MenuHomeVyOS Platform

Add GARP settings to VRRP/keepalived
Closed, ResolvedPublicFEATURE 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

Related Objects

Mentioned In
1.3.6

Event Timeline

syncer changed the task status from Open to Confirmed.Apr 17 2019, 7:46 PM
syncer assigned this task to hagbard.
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

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 added a subscriber: hagbard.
Unknown Object (User) added a subscriber: Unknown Object (User).Feb 26 2021, 2:11 PM

Tested in the lab the following simple topology on 1.2.6-S1 and 1.3-beta, behavior the same and GARP works by default.

Screenshot 2021-02-26 at 17.04.44.png (472×545 px, 45 KB)

VyOS1 config

set high-availability vrrp group eth1 hello-source-address '100.64.0.1'
set high-availability vrrp group eth1 interface 'eth1'
set high-availability vrrp group eth1 peer-address '100.64.0.2'
set high-availability vrrp group eth1 rfc3768-compatibility
set high-availability vrrp group eth1 virtual-address '100.64.0.50/24'
set high-availability vrrp group eth1 vrid '1'
set interfaces ethernet eth0 address 'dhcp'
set interfaces ethernet eth0 duplex 'auto'
set interfaces ethernet eth0 hw-id '50:00:00:01:00:00'
set interfaces ethernet eth0 speed 'auto'
set interfaces ethernet eth1 address '100.64.0.1/24'
set interfaces ethernet eth1 duplex 'auto'
set interfaces ethernet eth1 hw-id '50:00:00:01:00:01'
set interfaces ethernet eth1 speed 'auto'

VyOS2 config

set high-availability vrrp group eth1 hello-source-address '100.64.0.2'
set high-availability vrrp group eth1 interface 'eth1'
set high-availability vrrp group eth1 peer-address '100.64.0.1'
set high-availability vrrp group eth1 virtual-address '100.64.0.50/24'
set high-availability vrrp group eth1 vrid '1'
set interfaces ethernet eth0 address 'dhcp'
set interfaces ethernet eth0 duplex 'auto'
set interfaces ethernet eth0 hw-id '50:00:00:02:00:00'
set interfaces ethernet eth0 speed 'auto'
set interfaces ethernet eth1 address '100.64.0.2/24'
set interfaces ethernet eth1 duplex 'auto'
set interfaces ethernet eth1 hw-id '50:00:00:02:00:01'
set interfaces ethernet eth1 speed 'auto'

In traffic dump on VyOS3 we can see traffic when BACKUP node switched to MASTER state

14:02:34.152959 50:00:00:02:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 100.64.0.50 (ff:ff:ff:ff:ff:ff) tell 100.64.0.50, length 28
14:02:34.153042 50:00:00:02:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 100.64.0.50 (ff:ff:ff:ff:ff:ff) tell 100.64.0.50, length 28
14:02:34.153086 50:00:00:02:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 100.64.0.50 (ff:ff:ff:ff:ff:ff) tell 100.64.0.50, length 28
14:02:34.153090 50:00:00:02:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 100.64.0.50 (ff:ff:ff:ff:ff:ff) tell 100.64.0.50, length 28
14:02:34.153092 50:00:00:02:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 100.64.0.50 (ff:ff:ff:ff:ff:ff) tell 100.64.0.50, length 28
14:02:34.153467 50:00:00:02:00:01 > 50:00:00:01:00:01, ethertype IPv4 (0x0800), length 54: 100.64.0.2 > 100.64.0.1: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 20
14:02:35.153544 50:00:00:02:00:01 > 50:00:00:01:00:01, ethertype IPv4 (0x0800), length 54: 100.64.0.2 > 100.64.0.1: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 20
14:02:36.154117 50:00:00:02:00:01 > 50:00:00:01:00:01, ethertype IPv4 (0x0800), length 54: 100.64.0.2 > 100.64.0.1: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 20
14:02:37.154233 50:00:00:02:00:01 > 50:00:00:01:00:01, ethertype IPv4 (0x0800), length 54: 100.64.0.2 > 100.64.0.1: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 20
14:02:38.154470 50:00:00:02:00:01 > 50:00:00:01:00:01, ethertype IPv4 (0x0800), length 54: 100.64.0.2 > 100.64.0.1: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 20

The same behavior with rfc3768-compatibility option.
I think we don't need to change behavior because it should be suitable for all cases.

Viacheslav changed the task status from On hold to Needs testing.Jan 25 2023, 4:52 PM

This would be a useful feature to have.

My team was having issues where due to the number of public IPs we have in VRRP groups, the upstream router was being flooded with GARPs, causing it to stop listening to them. This had us ending up with some IPs having the correct new MAC address, while others were still pointed to the failed router.

Our team has had to manually add these options to the /usr/share/vyos/templates/vrrp/keepalived.conf.tmpl file on our router in the mean time to ensure that we do not bombard our ISP's router.