ability to specify using vmac_prefix for addresses not on the VRRP instance's interface.

[stfast]

          Commit 3dcd13c adds the ability to specify using VMACs for addresses not on the VRRP instance's interface.

1. use_vmac_addr can be specified on a vrrp_instance so that all VIPs/eVIPs not on the VRRP instance's interface are on VMACs.
2. use_vmac can be specfied per VIP/eVIP to achieve the same result for individual addresses.
3. vmac_prefix allows the default prefix of VMAC names for a primary VMAC
4. vmac_addr_prefix allows specifying the default VMAC name prefix for VIPs/eVIPs on other interfaces
5. Global vrrp_garp_extra_if [all] and per VRRP instance garp_extra_if [all] enable sending periodic GARP/NA messages for VIPs/eVIPs not on a VRRP instance's primary interface (more details below).

Re point 5. above, if a VIP/eVIP is configured on a VMAC on a different interface from the primary VRRP interface, no traffic will normally be sent with the source MAC address of the VMAC interface, since VRRP adverts will be sent on the primary VRRP interface. This means that any network switches that cache MAC addresses will expire the VMAC's MAC address, typically after 300 seconds (note: this is (was) also a problem when using vmac_xmit_base). Sending periodic GARP/NA messages on those interfaces will refresh the MAC caches in switches, and avoid any packets sent to the VMAC's MAC address flooding the whole layer 2 network. The only instance where packets will normally be sent using the VMAC's MAC address is when using IPVS with NAT forwarding. If all is not specified, GARP/NA messages will only be sent on each VMAC configured; specifying all will also send the GARP/NA messages for VIPs on other interfaces that are not using VMACs.

The one feature that has not yet been implemented is detecting if the address based VMACs are deleted, and subsequently recreating them (this is done for a primary VMAC interface but not yet for the address based ones).

Originally posted by @pqarmitage in #1743 (comment)

[stfast]

Commit (3dcd13c) solves all our setup and configuration issues, with working configuration:

global_defs {
vrrp_version 3
router_id postgres1
enable_script_security
script_user root
vmac_addr_prefix vlan-ha
nftables keepalived
}

vrrp_instance pgbase1.vlan113 {
version 3
state MASTER
interface vrrp0
virtual_router_id 1
priority 150
advert_int 1
garp_master_delay 1
garp_master_refresh 1
garp_extra_if 1
virtual_ipaddress {
172.16.113.41/24 dev vlan113 use_vmac noprefixroute
}
}

But we would like to have an option vmac_addr_prefix per virtual ipaddress as we have use_vmac option

virtual_ipaddress {
	172.16.113.41/24 dev vlan113 use_vmac noprefixroute vmac_addr_prefix vlan113-ha
}

So we would get more "readable" generated VMAC interface name "vlan113-ha.1":

$ ifconfig vlan113-ha.1
vlan113-ha.1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.16.113.41 netmask 255.255.255.0 broadcast 0.0.0.0
ether 00:00:5e:00:01:01 txqueuelen 1000 (Ethernet)
RX packets 5 bytes 490 (490.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5 bytes 210 (210.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

instead of "vlan-ha.1" currently defined with "vmac_addr_prefix vlan-ha" in global options

$ ifconfig vlan-ha.1
vlan-ha.1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.16.113.41 netmask 255.255.255.0 broadcast 0.0.0.0
ether 00:00:5e:00:01:01 txqueuelen 1000 (Ethernet)
RX packets 5 bytes 490 (490.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5 bytes 210 (210.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Thank you.