Something like VRRP/keepalived without MAC address impact? (RHEL 8) [closed]

I am looking to set up a cluster (of two systems) with a VIP, just what keepalived would do. In a different context, I already have keepalived working well. However, our network team told me not to introduce any new VRRP MAC addresses, since it may conflict with some of their own VRRP configurations.

I also do not want to add a reverse proxy for this purpose. Having a single point of failure like this would defeat the purpose of having the VIP in the first place.

Is there a way to either configure keepalived to just use layer 3 constructs, or a different tool that would do the same thing without going down to layer 2?

I realize that one of the reasons for the virtual MAC address is ARP resolution. Short outages due to changing MAC addresses would be undesirable but acceptable in my scenario.

Solution 1:

Examples below assumes IPv4, with configuration similar to the basic Red Hat example here: a node with address 192.168.122.101/24, an other with 192.168.122.102/24, using VRRP instance VI_1 and VRRP VIP 192.168.122.200/24.

This won't be VRRP compliant anymore, because RFC 5798 tells to use the VRRP MAC address in ARP replies.

Anyway, you can configure keepalived to be compliant with the policy set by your network team instead.

• don't use the option use_vmac in the VRRP instance configuration

  to prevent source Virtual Router MAC addresses of type 00:00:5E:00:01:XX to ever be used at all.

  • one can simply remove the use_vmac option,

    Clients won't have much trouble following a failover, because each time a node of keepalived becomes master for a VRRP address, it starts by announcing its (VIP) address with 5 DAD ARP requests for gratuitous ARP requests (pacemaker/corosync behaves the same in this regard), and will do it again 10s later. A capture of the announce would change for example from:

    00:00:5e:00:01:33 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.122.200 (ff:ff:ff:ff:ff:ff) tell 192.168.122.200, length 28
    

    to:

    56:24:20:bf:2a:37 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.122.200 (ff:ff:ff:ff:ff:ff) tell 192.168.122.200, length 28
    

    So instead of (the) switch(es) noticing a different port must be used to reach the same MAC address and updating its/their forwarding database(s), the IPv4 clients will notice snoop a different MAC address must be used to reach the same IPv4 address and will update their ARP tables.

  • or if really needed, replace it with use_ipvlan (at the cost of two extra IPv4 addresses!),

    for the same effect (and exactly the same on-wire capture as last example above).

    This would be needed only if the cluster's configuration relies on an additional virtual interface created by keepalived on each node, and thorough reconfiguration is to be avoided. An ipvlan interface behaves the same as a macvlan interface except it will use the MAC address from its parent interface (and handles internally how IP packets have to be multiplexed to the correct interface).

    On IPv4 this options requires to use an additional IPv4 address on it. This address must not be the VRRP and should not be the parent interface's IP address (or expect routing issues), so if it's on the same interface/LAN as the system network configuration, the 2 nodes cluster will now probably require 5 addresses instead of 3: the two original system-defined addresses, the 2 additional ipvlan addresses and the VRRP address.

    For example one server would use in addition to its original 192.168.122.101 system-configured address:

    use_ipvlan vip0 192.168.122.103
    

    and the other in addition to its 192.168.122.102:

    use_ipvlan vip0 192.168.122.104
    

    I'd avoid this option if given the choice.

• use an unicast_peer block

  to prevent use of the IPv4 VRRP multicast address 224.0.0.18 and the corresponding destination VRRP MAC multicast address 01:00:5E:00:00:12.

  This also requires disabling strict_mode if set (or if vrrp_strict is set in the global_defs block) , and doesn't support use_ipvlan described above (nor use_vmac). check_unicast_src could also be enabled to protect against configuration error of a third system rather than for any security.

  For example the node with 192.168.122.101 can use:

  vrrp_instance VI_1 {
      ...
      strict_mode off
      check_unicast_src
      unicast_peer {
          192.168.122.102
      }
  }
  

  and the node with 192.168.200.102:

  vrrp_instance VI_1 {
      ...
      strict_mode off
      check_unicast_src
      unicast_peer {
          192.168.122.101
      }
  }
  

  When doing this, only unicast traffic will be used by keepalived.

  Note that removing strict_mode might alter the firewalling behavior performed by keepalived.