Open stfast opened 9 months ago
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.
use_vmac_addr
can be specified on avrrp_instance
so that all VIPs/eVIPs not on the VRRP instance's interface are on VMACs.use_vmac
can be specfied per VIP/eVIP to achieve the same result for individual addresses.vmac_prefix
allows the default prefix of VMAC names for a primary VMACvmac_addr_prefix
allows specifying the default VMAC name prefix for VIPs/eVIPs on other interfacesvrrp_garp_extra_if [all]
and per VRRP instancegarp_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. Ifall
is not specified, GARP/NA messages will only be sent on each VMAC configured; specifyingall
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 https://github.com/acassen/keepalived/issues/1743#issuecomment-708644420