Learn Keepalived - IPv6 & Multi-network Topologies

#Introduction

Modern networks aren't just IPv4. IPv6 clients are growing in number, and infrastructure shouldn't have to choose between HA and IPv6. Episode 10 bridges the two: VRRPv3 support for IPv6, dual-stack configuration, and running Keepalived in complex topologies like multiple subnets and VLANs.

You'll also learn how a single daemon handles several networks at once with one instance per VLAN, and how inter-subnet routes are integrated with VRRP state. By the end of this episode, your network architecture can grow without replacing the HA foundation you've already built.

#IPv6 VRRP: VRRPv3 and Dual-stack

#Adding an IPv6 VIP

VRRPv3 (RFC 5798) supports IPv6. Keepalived uses ip6 as the keyword for IPv6 addresses inside virtual_ipaddress:

vrrp_instance VI_DUAL {
  state MASTER
  interface eth0
  virtual_router_id 60
  priority 100
  advert_int 1
  virtual_ipaddress {
    192.168.1.100/24 dev eth0
    fd00::100/64 dev eth0
    fe80::1/64 dev eth0
  }
}

The virtual_ipaddress block above holds both worlds: 192.168.1.100 for IPv4 and fd00::100 plus fe80::1 for IPv6 in a single instance. The syntax key is that ip6 is placed in front of addresses for IPv6 only, while without ip6 the address is treated as IPv4.

#accept_mode and mcast_src_ip6

Because IPv6 Link-Local is tied to the interface, some parameters need adjustment:

• accept: receives packets destined for the IPv6 VIP even when not MASTER, useful for services like VRRP itself.
• mcast_src_ip6: sets the IPv6 source address for advertisements.

Make sure the interface uses a stable IPv6 Link-Local address, for example by setting addr-gen-mode stable-privacy in NetworkManager or netplan, so advertisements don't change when the interface restarts.

#Keepalived Across Multiple Subnets and VLANs

#One Instance per VLAN

If services are spread across several VLANs, create one vrrp_instance per VLAN with the appropriate VLAN interface:

vrrp_instance VI_FRONT {
  state MASTER
  interface eth0.10
  virtual_router_id 61
  priority 100
  virtual_ipaddress {
    10.10.0.100/24 dev eth0.10
  }
}
 
vrrp_instance VI_BACK {
  state MASTER
  interface eth0.20
  virtual_router_id 62
  priority 100
  virtual_ipaddress {
    10.20.0.100/24 dev eth0.20
  }
}

Instance VI_FRONT runs on interface eth0.10 and VI_BACK on eth0.20. Each VLAN has its own virtual router and VIP, so a failure in one segment doesn't drag down the others.

#Synchronizing Across VLANs

If both VLANs must move together, wrap them in a vrrp_sync_group as you learned in episode 8. This pattern is common in topologies where the frontend and backend always live on the same node.

#track_interface with VLANs

A VLAN interface whose uplink is down should lower the priority. Track eth0.10 only if a failure in that VLAN should actually demote the node:

vrrp_instance VI_FRONT {
  state MASTER
  interface eth0.10
  virtual_router_id 61
  priority 100
  track_interface {
    eth0.10
  }
  virtual_ipaddress {
    10.10.0.100/24 dev eth0.10
  }
}

The track_interface block makes sure VI_FRONT drops priority when eth0.10 has problems, so another node in the same VLAN takes over.

#Routing Integration and Advanced Layouts

#Cross-Subnet Routes in an Instance

For gateway topologies, a VRRP instance can carry routes that follow its state:

vrrp_instance VI_GW6 {
  state MASTER
  interface eth0
  virtual_router_id 63
  priority 100
  virtual_routes {
    fd00:200::/64 via fe80::1 dev eth1
  }
  virtual_ipaddress {
    fd00:100::1/64 dev eth0
  }
}

The virtual_routes block above installs the fd00:200::/64 route only while the node is MASTER. When it drops to BACKUP, the route is removed too — keeping the routing table always aligned with whoever holds the VIP.

#Link-local for Gateways

In IPv6 topologies, client gateways use the router's Link-Local address, not a global prefix. Because VRRPv3 uses multicast and Link-Local, make sure the IPv6 instances on all nodes use the same interface and that the MASTER state is always on the right node, so a client's default gateway never points to a node that doesn't hold the VIP.

#Verifying the IPv6 Configuration

Once the configuration is ready, verify the IPv6 VIP is installed:

ip -6 addr show dev eth0
ping -6 -c 3 fd00::100

The ip -6 addr show dev eth0 output should show fd00::100/64 on the MASTER node, and ping -6 -c 3 fd00::100 confirms the VIP is responsive. Combining these two commands is a quick dual-stack readiness test.

#Closing

Episode 10 expands Keepalived's horizons to IPv6 and complex networks: dual-stack in a single instance, one instance per VLAN with proper tracking, and IPv6 routes that follow the VRRP state. Your infrastructure is now ready for a world that is no longer purely IPv4.

Key takeaways:

• VRRPv3 supports IPv6; use ip6 for IPv6 addresses in virtual_ipaddress.
• Dual-stack can live in a single VRRP instance.
• Each VLAN gets its own instance with its own VLAN interface.
• vrrp_sync_group synchronizes movement across VLANs.
• virtual_routes installs IPv6 routes according to instance state.
• Verify the IPv6 VIP with ip -6 addr show and ping -6.

In episode 11 next, we cover configuration management and drift control — managing keepalived.conf with Git and Ansible, validating changes before deploying, rollback strategies, and preventing configurations from drifting apart between nodes.