{{ summaryHeading }}
{{ summaryValue }}

{{ summaryLine }}

Role{{ computation.ok ? values.state : '—' }} Transport{{ computation.ok ? peerModeLabel : '—' }} Master down{{ computation.ok ? formatSeconds(values.master_down_seconds) : '—' }}
Local node {{ state }} Peer {{ peerModeLabel }} {{ topologyVipLabel }}
Use a single token such as lb01 or edge-a.
A short shared label such as VI_APP.
Use version 3 for IPv6 virtual addresses.
Initial state:
Use the interface carrying the virtual-address subnet.
Whole number from 1 to 255.
Use distinct priorities on peer nodes.
This tool accepts 0.1 to 60 seconds.
s
Choose an explicit failback policy for this node.
Enter one IPv4 or IPv6 address row per line.
Address options stay on their source row.
The generated transport block follows this explicit choice.
Use one address without a CIDR prefix.
One reachable peer address per line, without CIDR prefixes.
Duplicate peer rows are removed.
The neutral default omits legacy authentication.
Use the same value on every peer.
Attach one periodic vrrp_script service check to this VRRP instance.
{{ track_script_enabled_bool ? 'Enabled' : 'Disabled' }}
Leave blank to omit this transition hook.
Leave blank to omit this transition hook.
Leave blank to omit this transition hook.
{{ values.config_text }}
Node roleAddress or transportPriority guidancePeer actionCopy
{{ row.role }}{{ row.address }}{{ row.priority }}{{ row.action }}

The chart renderer is unavailable. Exact timing values remain in the configuration summary and directive audit.

LevelDirectiveGenerated valueDeployment noteCopy
{{ row.level }}{{ row.directive }}{{ row.value }}{{ row.note }}
HA Pair Role Consistency Checker Check HA peer snapshots for ownership drift, standby readiness, stale synchronization and heartbeat failures with service and priority evidence.
HAProxy Backend Config Generator Build an HAProxy backend block from server rows with health checks and TLS trust choices, then review capacity limits and deployment warnings.
HA Failover Budget Calculator Calculate a serial HA failover budget, compare every recovery phase with an RTO and safety reserve, and identify the longest delay.
Load Balancer Failover Time Calculator Estimate user-visible load balancer failover time across health checks, routing changes, DNS cache exposure, and an RTO target.

A shared service address is useful only when one node owns it and the standby nodes agree when to take over. Virtual Router Redundancy Protocol (VRRP) coordinates that decision on a local network. The active node advertises its presence at a fixed interval; backups compare priority and timing before assuming responsibility for the virtual IP address.

Keepalived turns that protocol into a Linux high-availability service. A vrrp_instance joins an interface, virtual router identifier, priority, advertisement interval, peer transport, and one or more virtual addresses. The same instance is described from each peer's local viewpoint, so some values must match across the group while router identity, local source address, and priority normally differ.

Usually shared Usually node-specific Reason
Instance name, VRID, virtual IP rows Router ID, interface when host naming differs Peers describe one virtual router from different hosts.
VRRP version and advertisement interval Priority and startup state Timing must agree while election preference remains distinct.
Authentication policy and failback intent Unicast source and remote-peer list Each node sends from its own address and points to the others.

Multicast is the protocol's normal transport, but cloud networks, filters, or routed designs may require explicit unicast peers. Neither choice proves that advertisements can travel between nodes. Firewalls, switches, security groups, address families, and interface placement can still prevent a correct-looking configuration from failing over.

Priority decides which eligible peer is preferred. Normal preemption lets a higher-priority backup reclaim the active role after it returns; nopreempt can avoid that failback, but Keepalived expects it to start from BACKUP. Priority 255 is reserved for the address owner and has special behavior, so ordinary high-availability pairs normally use distinct values from 1 to 254.

Fast timers reduce the theoretical detection delay but also leave less room for scheduling pauses, packet loss, and congested queues. Health scripts add service awareness by changing effective priority or fault state after repeated checks. They do not replace a syntax check, peer comparison, packet-level verification, and a controlled failover observed from a client network.

How to Use This Tool:

Draft one local node at a time, using the same peer plan for every member of the virtual router.

  1. Enter a safe Router ID, shared VRRP instance name, local startup state, and the interface that carries the virtual-address subnet.
  2. Choose VRRP version 2 or 3, then set the shared Virtual router ID, a distinct local priority from 1 to 255, and an advertisement interval from 0.1 to 60 seconds. Use version 3 for IPv6 virtual addresses.
  3. Add 1 to 64 Virtual IP address rows. Each row must begin with a valid IPv4 or IPv6 address and may include a prefix plus same-line Keepalived address options.
  4. Select unicast or multicast transport. Unicast requires one local source address and 1 to 32 remote peer addresses of the same family, without CIDR prefixes.
  5. Choose normal preemption or nopreempt. Open Advanced only when the design needs legacy PASS authentication, a tracked health command, or state-change notification commands.
  6. Resolve input errors, then compare VRRP Configuration, Peer Checklist, Failover Timing, and Directive Audit. Repeat the draft for each peer with its local values changed deliberately.

Interpreting Results:

The generated configuration is a node-local draft. Pass means a directive met the generator's bounded checks; Review marks a deployment choice that can be valid but needs operator confirmation. Review priority 255, multicast delivery, nopreempt, legacy PASS authentication, omitted health tracking, and non-absolute notification commands in the context of the whole peer set.

The timing value is an estimate for advertisement loss detection, not a service outage promise. It excludes daemon scheduling, health-check cadence, address announcement, neighbor-cache convergence, application readiness, and client retry behavior. Compare the same interval and priority assumptions across peers, then measure real failover from outside the cluster.

Before installation, validate the file with the Keepalived release running on the target host. Confirm that every peer shares the VRID, address set, version, timer, and intended failback policy; then test both planned maintenance and abrupt failure paths.

Technical Details:

VRRP elects the eligible router with the highest priority. Advertisements from the active router keep backup timers refreshed. When advertisements stop, the backup waits for three advertisement intervals plus a priority-dependent skew, allowing higher-priority backups to expire slightly sooner.

Formula Core

The generated estimate retains the familiar Master Down wording used by the configuration model. Current VRRPv3 terminology calls the corresponding quantity Active Down Interval.

tskew = (256−P)×A 256
tdown = 3×A + tskew
Symbol Meaning Unit and range
PLocal priorityWhole number, 1 to 255
AAdvertisement intervalSeconds, 0.1 to 60
tskewPriority-dependent delaySeconds
tdownEstimated advertisement-loss detection intervalSeconds

Intermediate values retain full precision. Exact timing values are presented to three decimal places in the audit and chart. Priority 150 with a 1-second advertisement interval gives a skew of 0.4140625 seconds and an estimated down interval of 3.4140625 seconds, displayed as 3.414 seconds.

Rule Core

Configuration assembly follows a fixed order: global router identity, an optional health-check definition, the VRRP instance, optional unicast and authentication blocks, virtual addresses, health tracking, and transition commands. Duplicate address and peer lines are removed before emission.

Area Accepted rule Review boundary
AddressesIPv4 prefixes from 0 to 32; IPv6 prefixes from 0 to 128VRRPv2 rejects IPv6 virtual addresses.
UnicastOne source plus 1 to 32 peers, all in one address familyA peer equal to the local source is flagged.
Health trackingInterval 1 to 300 seconds; weight −253 to 253; fall and rise 1 to 20A weight that can reduce effective priority to zero or below is flagged.
PASS authentication1 to 8 characters without whitespace or bracesIt is a legacy Keepalived compatibility feature, not modern VRRP security.
CommandsOne line, at most 255 characters, without bracesNon-absolute notification commands require environment review.

A tracked command with weight zero moves the instance toward fault after the configured consecutive failures. A nonzero weight adjusts effective priority after the fall threshold and reverses after the rise threshold. Priority 255 remains address-owner behavior and cannot be reduced like an ordinary backup priority.

Limitations and Safety Notes:

No generated file can confirm interface names, permissions, script behavior, firewall rules, multicast support, unicast reachability, or compatibility with the installed Keepalived version.

  • PASS authentication offers limited compatibility protection and should not be treated as confidentiality or strong peer authentication.
  • Large virtual-address sets may need a deployment-specific split or excluded-address handling.
  • Install changes and service restarts can interrupt traffic; use host syntax checks and a controlled maintenance plan.

Worked Examples:

Two-node unicast pair

Node A uses priority 150 and source 10.44.20.11; Node B uses a lower distinct priority and source 10.44.20.12. Both files keep VRID 42, version 3, a 1-second advertisement interval, and the same virtual address. Each peer list points to the other node. The Node A timing estimate is 3.414 seconds, but the rollout still needs syntax validation, bidirectional advertisement checks, and a client-observed takeover test.

References: