Page MenuHomeDevCentral

Implement Common Address Redundancy Protocol (CARP)
Open, NormalPublic

Description

Problems solved:

  • Provide high availability (HA) at the router level
  • Enable blue/green deployment using a shared IP address

Context
We are currently considering router-001 and router-002 for blue/green deployment, allowing easy OS updates without service disruption and, most importantly, offering HA.

The first impulse was to write a solution à la keepalived for FreeBSD with scripts to set a virtual IP address (VIP) and MAC address. However, FreeBSD has built-in HA support via the CARP protocol (thanks, FatalNIX, for the insight).

Common Address Redundancy Protocol (CARP) "allows multiple hosts on the same local network to share a set of IPv4 and/or IPv6 addresses" (from the man page).

If one server fails, another takes over. Delays can be set very aggressively, down to approximately 4 ms (1/256 s).

The goal of this lab experiment is to explore different strategies to get CARP working well with:

  • our GRE tunnels
  • our OVH IPFO setup

Activity

  1. Generate a new MAC address (2)
  2. Spin router-002, router-003 (allowing router-001 to serve traffic while giving us two additional servers for testing)
  3. Enable CARP on the machines
  4. Configure CARP for the main gateway
  5. Configure CARP for the GRE tunnels
  6. Check if FreeBSD bug 166462 can be reproduced (1)
    1. Install Quagga
    2. Configure OSPF
    3. Run ospfd
  7. Test that everything works with OVH IPFO, linking the IPFO to the CARP virtual MAC address
  8. Process CARP status change events with a devd rule
  9. Devise optimal strategies for blue/green deployment

FreeBSD issue triage
(1) FreeBSD bug 166462 was created prior to the FreeBSD 10 CARP rewrite.

It is particularly tricky to test, as it normally requires a full setup with GRE + OSPF + IPsec. We may be in a favorable situation to enable OSPF.

While OpenBSD ships with ospfd included, FreeBSD requires external software; Quagga will handle OSPF (and optionally BGP) nicely.

OVH IPFO considerations

(2) OVH routes traffic for an IPFO to a known MAC address attached to a specific server. Therefore, we need to generate a dedicated MAC address at the OVH level for the virtual interface.

References


Workshop — This can be done as part of a Nasqueron lab x Wolfplex labworkshop

Event Timeline

dereckson triaged this task as Normal priority.Thu, Oct 30, 01:26
dereckson created this task.