Page MenuHomeVyOS Platform
Create Task
Maniphest T5572

Add capability for sending Gratuitous ARP (GARP) and the equal for IPv6
Needs reporter action, WishlistPublicFEATURE REQUEST
Actions

Description

https://vyos.dev/T5559 (Selective proxy-arp/proxy-ndp when doing SNAT/DNAT) only resolves the case for when other devices politely asks "who-has x.x.x.x?" (or the equal in IPv6-world).

When dealing with active/passive failover a more active way of informing the rest of the network that "hey, send packets for x.x.x.x to my mac-address" (or the equal in IPv6-world) must be performed.

For virtual IP-addresses configured through VRRP or virtual-server this should be taken care of by keepalived (when the VyOS becomes active).

However if you have SNAT configured along with VRRP, something like this:

VRRP_VIP (eth0): 192.168.0.1/24
VRRP_R1 (eth0): 192.168.0.2/24
VRRP_R2 (eth0): 192.168.0.3/24
SNAT (eth0): 192.168.0.4
SNAT (eth0): 192.168.0.5

When the failover occurs and passive VyOS (VYOS2) becomes active VyOS then the other devices at 192.168.0.0/24 network will not understand that packets towards 192.168.0.4 and 192.168.0.5 should be sent to the mac-address of VYOS2 rather than VYOS1 which is currently in their arp/ndp cache (and might remain there until it gets timed out).

The other devices might even detect that an IP-collission exists on this network or detect it as an ongoing arp-spoofing.

To resolve this Gratuitous ARP (GARP) (and similar for IPv6) must be implemented in VyOS (to work in combination with selective proxy-arp/proxy-ndp).

Solution for IPv4:

arping -q -b -c 1 -I eth0 -U -s 192.168.0.4 192.168.0.4
arping -q -b -c 1 -I eth0 -U -s 192.168.0.5 192.168.0.5

arping do support an interval between packets:

-i <interval> set interval between packets (default: 1 second)

Which means it should be able to configure this as a systemd.service and let systemd watchdog over it (restart if it crashes).

When runned as a service the "-c 1" should be removed.

Solution for IPv6:

ndsend 2001:db8::1 eth0

ndsend doesnt seem to have an interval so if runned as systemd.service it needs to be scripted into a loop with a sleep statement.

ndsend is part of vzctl package in Debian.

Another option is ndptool part of package libndp-tools in Debian.

An abandoned source from 2006 named ndping (works similar to arping) exists at https://sourceforge.net/projects/ndping/files/latest/download

NOTE! For the above (IPv4 and IPv6) to work properly kernel setting ip_nonlocal_bind must be set to 1 (because whats being announced is an IP-address not currently configured on any interface):

sysctl -w net.ipv4.ip_nonlocal_bind=1
sysctl -w net.ipv6.ip_nonlocal_bind=1

The commands in VyOS should be similar for those proposed regarding proxy-arp/proxy-ndp.

That is something like:

set protocols static garp 192.0.2.1 interface eth0 interval 1
set protocols static garp 192.0.2.1 interface eth1 interval 1
set protocols static una 2001:db8::1 interface eth1 interval 1

Where "garp" = "IPv4 Gratuitous ARP" and "una" = "IPv6 Unsolicited Neighbor Advertisements".

I have no idea if the short name for "IPv6 Unsolicited Neighbor Advertisements" is "una" anywhere else but could be handy to not have to spell out the full name in the config (so Im open for suggestions if a better name can be used, gnd perhaps (Gratuitous Neighbour Discovery)?).

To match "how others do" the default interval should be 30 seconds: https://www.arista.com/en/um-eos/eos-varp#xx1152897 (ip virtual-router mac-address advertisement-interval <period>)

Ref:

https://datatracker.ietf.org/doc/html/rfc5227

https://datatracker.ietf.org/doc/html/rfc2461#section-7.2.6

https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

https://manpages.debian.org/bookworm/iputils-arping/arping.8.en.html

https://manpages.ubuntu.com/manpages/jammy/en/man8/ndsend.8.html

https://sourceforge.net/projects/ndping/files/latest/download

https://blog.veloc1ty.de/2021/01/03/prevent-ndp-neighbor-cache-expiry-at-netcup-unsolicited-neighbor-advertisements/

https://manpages.debian.org/testing/libndp-tools/ndptool.8.en.html

https://packages.debian.org/bookworm/libndp-tools

Details

Difficulty level
Unknown (require assessment)
Version
-
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Feature (new functionality)

Related Objects

Event Timeline

Apachez created this task.Sep 13 2023, 12:35 AM
Apachez added a comment.Sep 13 2023, 12:54 AM

Turns out to exist an RFC for this regarding IPv6 along with a naming:

"Gratuitous Neighbor Advertisements"

or

"Gratuitous Neighbor Discovery"

Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers
https://datatracker.ietf.org/doc/rfc9131/

So the shortname for the command in VyOS should be either "gna" or "gnd".

Since this usecase is to inform all node neighbors (and not just first-hop routers) on the current interface using "Unsolicited Neighbor Advertisements" (short: una) might still be a better naming according to section 7.2.6 of RFC4861?

https://datatracker.ietf.org/doc/html/rfc4861#section-7.2.6

pasik added a subscriber: pasik.Sep 13 2023, 8:04 AM
Viacheslav changed the task status from Open to Needs reporter action.Jan 19 2024, 10:47 PM
Viacheslav added a subscriber: Viacheslav.

@Apachez Could you recheck if it works as you expected?

vyos@r4# set high-availability vrrp group FOO garp 
Possible completions:
   interval             Interval between Gratuitous ARP (default: 0)
   master-delay         Delay for second set of gratuitous ARPs after transition to
                        master (default: 5)
   master-refresh       Minimum time interval for refreshing gratuitous ARPs while
                        beeing master (default: 5)
   master-refresh-repeat
                        Number of gratuitous ARP messages to send at a time while beeing
                        master (default: 1)
   master-repeat        Number of gratuitous ARP messages to send at a time after
                        transition to master (default: 5)
Apachez added a comment.Jan 20 2024, 9:24 AM

GARP is needed for VRRP but the GARP setting is also needed when doing NAT.

So Im not sure that the GARP settings should be locked to the VRRP context.

As with my previous example but without VRRP the VyOS router could be configured with:

eth0: 192.168.0.1/24

With routing set to "ip route 0.0.0.0/0 192.168.0.254".

But since there is a /24 to play with on this linknetwork and for whatever reason NAT is needed then the VyOS router can NAT traffic to 192.168.0.1-192.168.0.253.

eth0: SNAT 192.168.0.4
eth0: SNAT 192.168.0.5

For that to work proxy-arp and GARP must work in combination to not end up with situations where the upstream router is missing mac-address for the NATed address and because of that traffic will in those situations never reach the VyOS router.

Viacheslav triaged this task as Wishlist priority.Jan 20 2024, 9:43 AM
Viacheslav added a comment.Jan 20 2024, 9:48 AM

As to me there arping -q -b -c 1 -I eth0 -U -s 192.168.0.4 192.168.0.4 should to be in the transition script master of VRRP, isn't it?
What else we can do there?

Apachez added a comment.Jan 20 2024, 9:55 AM

Again, notifing upstream (or downstream) is not only about VRRP.

The same is needed if you do NAT without VRRP and for that there is no transition script master to deal with.

Comparing to others such as Arista you can there define if GARP should be enabled and how often the device should GARP the IP-address to its surroundings.

But thats about the physical interface - when doing NAT (which Arista switches/routers doesnt do) the GARP is needed for that too.

Viacheslav added a comment.Jan 21 2024, 12:04 AM

How will it looks like if we have for example 100.64.0.0/24
R1 should announce 100.64.0.0/25
Will we add 128 entries or there better solution?

Apachez added a comment.Thu, Apr 18, 7:58 AM

It would be handy if the GARP announcement wouldnt be a separate list but rather picked up from any DNAT or SNAT rules.

But that would add some logic to this which might get bugs over time.

For example this issue mainly only exists if you SNAT/DNAT for IP-addresses within the IP-range of the interface.

Like if you use a linknet lets say 169.254.1.1/30 on one side and 169.254.1.2/30 on the other over which you route whatever other IP-range then there is no issue.

But if you have lets say 192.168.1.1/24 configured on your end (and the other side have 192.168.1.254/24) and you for whatever reason SNAT/DNAT 192.168.1.5 on your end then this GARP and proxy-arp thingy is needed to inform the other party that you listen not only on 192.168.1.1 but also 192.168.1.5.

Looking at manpages for arping it seems limited to single /32 host addresses for both source and destination.