12 High Availability

A single BIG-IP is a single point of failure. High availability (HA) joins two or more BIG-IPs so that configuration is shared and, if the active unit fails, another takes over its traffic. This note covers the HA building blocks, Active/Standby and Active/Active, what triggers a failover, and the settings that make failover fast and predictable.

Building blocks

ObjectWhat it is
Device trustCertificate-based trust between BIG-IPs (they become peers). Required before anything else
Device groupTrusted devices that share config: Sync-Failover (config + failover) or Sync-Only (config only)
Traffic groupFloating objects (floating self IPs, virtual addresses, SNATs) that fail over together. traffic-group-1 is the default; traffic-group-local-only never moves
Floating self IPSelf IP owned by a traffic group; moves to the active unit. Servers use it as gateway
ConfigSync addressSelf IP used to synchronize configuration
Failover addressesUnicast (and/or multicast) addresses for the heartbeat (UDP 1026)
Mirroring addressUsed to copy connection/persistence state to the peer (TCP 1029–1155, one channel per traffic group; 1028 in older versions)
SOD (Switch-Over Daemon)Decides active/standby and executes failover

Cisco / Palo Alto analogy

  • Traffic group + floating self IP ≈ an HSRP/VRRP group and its virtual IP.
  • Device group + ConfigSync ≈ Palo Alto HA config sync.
  • Active/Active with two traffic groups ≈ two HSRP groups, each router active for one.

What is synchronized

  • Synced: virtual servers, pools, monitors, profiles, iRules, policies, floating self IPs, traffic groups.
  • Not synced (device-specific): hostname, management IP, non-floating self IPs, interfaces and VLAN-to-interface mapping, license, provisioning, ConfigSync/failover/mirroring addresses.
  • So two synced devices are not a perfect mirror image.

Building an HA pair

  1. Same software version on both units, NTP synchronized, VLANs ready. A dedicated HA VLAN is recommended.
  2. On each device set the ConfigSync, Failover and Mirroring local addresses.
  3. Create the device trust (add the peer by IP + admin credentials, verify the certificate). Peers talk over TCP 4353 (CMI / iQuery, SSL).
  4. Create a Sync-Failover device group with both devices and do the initial sync.
  5. Create floating self IPs in traffic-group-1.

Status (top-left of the GUI and in the prompt): ONLINE (ACTIVE) / ONLINE (STANDBY) and sync status — In Sync, Changes Pending, Awaiting Initial Sync, Not All Devices Synced, Disconnected.

Config Sync

  • Propagates config changes to all devices in the device group.
  • Modes: manual (sync to group from the device with the newest config) or automatic; full vs incremental sync.
  • “Changes Pending” → do a manual push to the group.
  • Compare timestamps / last change to know which device has the newest config.
  • Sync errors are logged in /var/log/ltm.

Active/Standby vs Active/Active

  • Active/Standby — one unit owns all traffic groups; the peer waits.
  • Active/Active — create a second traffic group (traffic-group-2) with its own floating IPs and virtual addresses, and make each device active for a different group (Force to Standby on a traffic group moves it to the peer).
    • Benefit: both boxes process traffic — you don’t pay for an idle standby.
    • Risk: if one fails, the survivor carries the load of both. Size each unit for 100%.

Manual operations

  • Force to Standby — the active unit hands its traffic groups to the peer (planned failover).
  • Force Offline — takes the unit out of service for maintenance; it won’t process traffic or become active until you bring it online again.

What triggers a failover

CategoryExamples
AdministrativeForce to Standby / Offline, moving a traffic group
SystemTMM or critical daemon failure (HA table), hardware failure, reboot
NetworkLoss of the failover heartbeat, VLAN fail-safe, gateway fail-safe
Health scoreHA group score drops below the peer’s

Failover detection features

FeatureWhat it does
HA groupScore from the health of pools, trunks or clusters; the higher score becomes active for the traffic group
VLAN fail-safeNo traffic seen on a VLAN for a timeout → BIG-IP sends ARP requests to generate traffic; if still nothing, it takes the configured action (failover, reboot or restart all; the default action is Reboot)
Gateway fail-safeA pool containing the upstream router goes down → fail over
Network failoverHeartbeats over UDP 1026 — required for VE and for more than two devices
Serial (hardwired) failoverCable between two physical units only

Making failover fast and clean

  • MAC masquerading — a shared virtual MAC per traffic group. The floating IP keeps the same MAC after failover, so neighbors don’t need to update ARP (no dependence on gratuitous ARP). Same idea as the HSRP virtual MAC 0000.0c07.acXX.
  • Connection mirroring — copies connection state to the peer so long-lived sessions survive failover. It costs CPU and bandwidth: use it for long sessions (FTP, SSH, databases, VPN), not short HTTP.
  • Persistence mirroring — copies persistence records (or avoid records with CARP).
  • Auto-failback — disabled by default and usually left disabled. If enabled, the preferred unit takes traffic back as soon as it recovers, causing a second failover (and possible flapping). Most teams fail back manually in a maintenance window.

Global HA

HA between data centers is done with GSLB (BIG-IP DNS), which answers DNS queries with the IP of an available data center.

Self-check

Q1 — When two BIG-IPs are synchronized, is all their configuration identical?

Q2 — Which TCP port do peers use to communicate over SSL for trust and sync?

Q3 — Which feature makes the active BIG-IP fail over to the standby?

Q4 — Which object is synchronized when a device group is synced: hostname, management IP or pools?

Q5 — The sync status doesn't say "In Sync". What do you do?

Q6 — Without MAC masquerading, is there a brief interruption on failover?

Q7 — For a global HA solution, what do you choose?

Q8 — Should auto-failback be enabled for HA to work well?