-
-
Notifications
You must be signed in to change notification settings - Fork 730
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ability to specify using vmac_prefix for addresses not on the VRRP instance's interface. #2356
Comments
Commit (3dcd13c) solves all our setup and configuration issues, with working configuration: global_defs { vrrp_instance pgbase1.vlan113 { But we would like to have an option vmac_addr_prefix per virtual ipaddress as we have use_vmac option
So we would get more "readable" generated VMAC interface name "vlan113-ha.1": $ ifconfig vlan113-ha.1 instead of "vlan-ha.1" currently defined with "vmac_addr_prefix vlan-ha" in global options $ ifconfig vlan-ha.1 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 #1743 (comment)
The text was updated successfully, but these errors were encountered: