Keepalived VRRP Config Generator

Router ID:

Name the local Keepalived process for logs and notifications.

VRRP instance name:

Use the same instance name on every node in this VRRP set.

Initial state:

Choose the local node's startup role.

VRRP interface:

Use the Linux interface carrying the VIP subnet.

Virtual router ID:

Valid VRID range is 1-255.

Local priority:

Use a higher value for the preferred active node.

Advertisement interval:

Preemption behavior:

Choose whether a higher-priority node can reclaim MASTER after recovery.

Virtual IP address rows:

Enter one VIP line per address.

Keep interface-specific options on the same VIP line.

Peer transport:

Choose how VRRP advertisements reach peer nodes.

Local unicast source IP:

Use the local node's real IP on the VRRP path.

Unicast peer IPs:

List peer node addresses for this VRRP instance.

Peer nodes need matching VRID, VIPs, and advert interval.

{{ result.errors.length ? 'Fix before using this config' : 'Review before using this config' }}

{{ item }}
{{ item }}

PASS authentication:

Default omits the authentication block.

PASS string:

Keep the value at eight characters or fewer.

Add vrrp_script health tracking

Generate a top-level vrrp_script and attach it with track_script.

Track script name:

Use a short label without spaces.

Track script path:

Use an absolute path on the Keepalived host.

Track interval:

Keep this longer than the script's worst-case runtime.

Track weight:

Use -253 to 253. A negative weight is common for service-failure penalties.

Fall count:

Consecutive failures before the script affects the instance.

Rise count:

Consecutive successes before recovery is accepted.

notify_master script:

Leave blank to omit notify_master.

notify_backup script:

Leave blank to omit notify_backup.

notify_fault script:

Leave blank to omit notify_fault.

{{ result.config }}

Severity	Directive	Generated value	Deployment note	Copy
{{ row.severity }}	{{ row.directive }}	`{{ row.value }}`	{{ row.note }}

Node role	Address or transport	Priority guidance	Peer action	Copy
{{ row.role }}	{{ row.address }}	{{ row.priority }}	{{ row.action }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

A virtual IP address only helps availability when every participating node agrees who owns it right now. Keepalived uses Virtual Router Redundancy Protocol (VRRP) to make that ownership decision on Linux systems. One node sends regular advertisements for the shared address, while the others wait in backup state and take over only when the advertisements stop or when policy says a higher-priority node may reclaim the address.

The vocabulary can be confusing because standards and configuration files use different words. Recent VRRP documents describe the current owner as the Active Router and the standby devices as Backup Routers. Keepalived configuration still uses MASTER and BACKUP, so operators often read both naming systems in the same change window. The important idea is not the label itself, but the election plan behind it: priority, advertisement timing, preemption, and the virtual router ID must match the intended failover design.

VRRP is common in modest but critical pairs: load balancers, firewall gateways, database proxies, DNS resolvers, NAT devices, and edge appliances that need one stable address in front of replaceable machines. The shared address can move quickly, but only the address moves. The application, health checks, firewall rules, ARP or neighbor discovery behavior, and peer configuration still need their own validation.

VRRP active and backup nodes sharing a virtual IP with advertisement timing.

A short Keepalived file can hide several cross-node promises. The peers need the same virtual router ID, the same virtual IP rows, compatible authentication choices if authentication is used, matching advertisement intervals, and deliberate priority differences. The values that must match are not always the values that should be identical on every node. The local unicast source address, router ID, and local priority usually change from one file to the next.

Failover speed is a tradeoff, not a single race to the smallest interval. Reducing the advertisement interval can shorten takeover time, but it also leaves less room for packet loss, CPU pauses, slow health scripts, and network devices that treat multicast or protocol 112 traffic differently from ordinary TCP flows. Unicast and multicast are deployment choices rather than quality levels: multicast fits a segment that forwards VRRP correctly, while unicast is often easier in cloud, routed, filtered, or tightly controlled networks.

Health tracking, transition scripts, and non-preempting behavior can make a VRRP design safer, but they do not turn a generated file into proof of availability. A useful review compares every peer file, checks the target host syntax, verifies advertisement delivery, and runs a controlled failover while watching the service address from a client network.

How to Use This Tool:

Build the file for one local node first, then use the audit and peer checklist to prepare the matching peer files.

Enter Router ID, VRRP instance name, Initial state, and VRRP interface. Keep the instance name shared across peers, but use a router ID that identifies this node in logs.
Choose a Virtual router ID from 1 to 255 and set Local priority. Give the preferred active node the highest ordinary priority, and reserve priority 255 for address-owner behavior that has been planned deliberately.
Set Advertisement interval in seconds. The failover estimate combines this value with local priority, so review the timing before shrinking the interval for faster takeover.
Add Virtual IP address rows, one address per line. Start each row with an IPv4 or IPv6 address, optionally followed by a prefix and same-line Keepalived address options such as dev or label.
Select Peer transport. For unicast, enter a plain local source address and peer addresses without CIDR prefixes; for multicast, plan a separate network check for VRRP advertisement delivery.
Open Advanced only for needed deployment policy: PASS authentication, vrrp_script health tracking, script weight, fall and rise counts, or state-change notification scripts.
Fix every blocker in the warning area, then review VRRP Config, Directive Audit, Peer Checklist, and Failover Timing. Copy or download the config only after the audit matches the peer design you intend to test.

Interpreting Results:

VRRP Config is a local-node draft. If the summary reports Check input or the warning area lists blockers, the displayed config is not ready for use even if most directives look reasonable. A copy ready badge means the visible validation rules passed; it does not prove that the peer files, firewall rules, interface names, or live daemon behavior are correct.

Directive Audit separates syntax-blocking input problems from review choices. Missing unicast source addresses, peer rows with CIDR prefixes, invalid VIP rows, and unsafe PASS strings block the draft. Review rows point to decisions that can be valid in the right environment, such as multicast transport, legacy PASS authentication, priority 255, high-priority BACKUP startup, omitted health tracking, or omitted transition scripts.

Peer Checklist shows what must be checked across nodes. Keep the virtual router ID, virtual IP rows, advertisement interval, and authentication choice aligned across the peer group, while changing each node's local source address and priority intentionally. Failover Timing estimates the advertisement window plus priority skew; use it to compare settings, not to promise exact outage length.

Use the generated config only after the audit has no Blocker rows.
Keep peer priorities distinct unless equal-priority behavior is intentional and tested.
Run Keepalived syntax validation and a controlled failover test before applying the file to production service traffic.

Technical Details:

A VRRP instance has four technical jobs: identify the peer group, elect the current address owner, carry advertisements between peers, and move one or more virtual addresses during failover. The virtual router ID identifies the group on the segment, priority influences election, the advertisement interval controls heartbeat cadence, and the virtual IP rows list the addresses that should follow the active node.

VRRPv3 standards describe an Active Router and Backup Routers, while Keepalived configuration still uses state MASTER and state BACKUP. The file's initial state is only a startup hint; ongoing ownership depends on advertisements, priority, preemption behavior, and health-related priority changes. A backup declares the active peer down only after the active-down timer expires, unless it receives an explicit shutdown-style priority signal.

Formula Core:

The failover timing estimate follows the VRRP active-down relationship. The form accepts seconds, while the protocol formula is defined in centiseconds; the displayed result is converted back to seconds.

Skew_Time = \frac{256 - Priority}{256} Advertisement_Interval

Active_Down_Interval = 3 Advertisement_Interval + Skew_Time

With priority 150 and advertisement interval 1 second, skew is (256 - 150) / 256 * 1 = 0.414 seconds. The estimated active-down interval is 3 * 1 + 0.414 = 3.414 seconds, shown as about 3.41s. Higher priority lowers the skew portion, so a higher-priority backup can take over slightly sooner after the same missing advertisement sequence.

Rule Core:

Keepalived VRRP configuration rules and review meaning
Configuration concern	Directive or value	Rule or review meaning
Node identity	`global_defs.router_id`	Names the local Keepalived process for logs and transition notices; it does not identify the whole peer set.
Peer-group identity	`vrrp_instance` and `virtual_router_id`	The instance name should match peer configs, and the VRID must match within one VRRP group while avoiding accidental overlap on the same segment.
Election	`state`, `priority`, and `nopreempt`	Highest priority normally wins. `nopreempt` lets a lower-priority active node keep the VIP when a higher-priority backup returns, except address-owner behavior still preempts.
Advertisement path	`interface`, `unicast_src_ip`, and `unicast_peer`	Multicast depends on the network forwarding VRRP packets. Unicast requires each node to point at reachable peer node addresses.
Shared address	`virtual_ipaddress`	Each accepted VIP row becomes one address line, so interface options and labels must stay on the intended address row.
Service health	`vrrp_script` and `track_script`	A periodic command can reduce effective priority or move the instance toward fault handling after the configured fall count.
Transition hooks	`notify_master`, `notify_backup`, and `notify_fault`	Optional scripts run on state changes; use absolute paths and keep the scripts idempotent because failover events can happen under pressure.

Validation Boundaries:

Input validation boundaries for Keepalived VRRP config generation
Input	Accepted range or shape	Generated warning or reason
Virtual router ID	Integer 1 to 255	Values outside the range are clamped because the VRID is an 8-bit protocol field.
Local priority	Integer 1 to 255	Priority 255 is marked for review because it represents address-owner behavior; ordinary backups should use lower values.
Advertisement interval	0.1 to 60 seconds	The value is rounded to three decimals and feeds the active-down estimate.
Virtual IP rows	IPv4 or IPv6 address, optional prefix, optional same-line address options	Rows with braces or invalid first address tokens are rejected; mixed IPv4 and IPv6 VIP rows are flagged for review.
Unicast source and peers	IPv4 or IPv6 address without a CIDR prefix	Unicast mode blocks copy-ready output until a plain local source address and at least one peer address are present.
Track script controls	Interval 1 to 300 seconds, weight -253 to 253, fall and rise 1 to 20	The script path is required when tracking is enabled; non-absolute paths are allowed with a review warning.
PASS string	Non-empty when PASS is enabled, no whitespace or braces, first eight characters used	Long values are truncated to match Keepalived behavior, and PASS is marked for review because modern VRRP does not define authentication.

The timing calculation is deterministic from priority and advertisement interval. Real failover also depends on daemon scheduling, network delivery, script runtime, firewall behavior, address movement, ARP or neighbor discovery convergence, and whether peer files agree on the shared values.

Limitations and Privacy Notes:

The generated text is a deployment draft, not a live Keepalived validation. It does not connect to nodes, read existing config files, verify interface names on a host, test multicast reachability, execute health scripts, or prove that a virtual IP moves correctly during a real failure.

Run Keepalived syntax validation on the target host before restarting a service.
Compare every peer file because a valid local file can still disagree with its peers.
The config text is assembled from the entered values in the browser. Avoid pasting secrets into PASS or notify fields that you would not want visible in local browser state or copied reports.

Worked Examples:

A three-node load balancer group can start with router ID lb01, instance VI_APP, interface ens192, VRID 42, priority 150, advertisement interval 1, VIP 10.44.20.10/24 dev ens192, local unicast source 10.44.20.11, and peers 10.44.20.12 and 10.44.20.13. With no blockers, VRRP Config should be copy-ready, Directive Audit should show the unicast peer block, and Failover Timing should report about 3.41s for the active-down estimate.

A recovered primary that should not immediately retake the virtual IP can set Preemption behavior to nopreempt. The audit marks the choice for review because it is operational policy rather than a syntax problem. Test this with the peer files because startup state, priority gaps, and priority 255 can change the behavior people expect from non-preempting failover.

A health-aware pair can enable Add vrrp_script health tracking with /usr/local/bin/check_haproxy.sh, interval 2, weight -20, fall 2, and rise 2. The audit should show track_script as generated and include the weight, fall, and rise values. A negative weight lowers effective priority after repeated failures, so peer priority gaps must be wide enough for the penalty to matter.

A common troubleshooting case is a peer value such as 10.44.20.12/24 in Unicast peer IPs. Unicast peer rows must be plain node addresses, so the blocker clears only after changing the row to 10.44.20.12. Confirm that Local unicast source IP is also a plain IPv4 or IPv6 address, then recheck Peer Checklist before copying the config.

FAQ:

Why should peer priorities usually be different?

Different priorities make election behavior easier to predict. The checklist uses the local priority as a planning reference, but each peer file should set its own local priority and unicast source address.

When should I use unicast instead of multicast?

Use unicast when the network does not forward VRRP multicast or when the environment requires explicit peer addresses. Use multicast only after checking switches, host firewalls, and platform networking for VRRP advertisement delivery.

Why is PASS authentication marked for review?

Keepalived can use a PASS block, but modern VRRP does not define authentication and Keepalived documentation treats it as a compatibility feature. Use it only for a known compatibility need, keep the same value on peers, and remember that only the first eight characters are used.

Why did my peer row get rejected?

Unicast peer rows must start with one IPv4 or IPv6 node address and must not include a CIDR prefix. Remove prefixes such as /24, remove braces, and keep address options out of peer rows.

Does the generated config prove failover will work?

No. It creates a structured local draft, audit table, peer checklist, and timing estimate. You still need peer comparison, syntax validation, firewall checks, multicast or unicast reachability checks, and a controlled failover test.

Glossary:

VRRP: Virtual Router Redundancy Protocol, the protocol used to coordinate ownership of one or more virtual IP addresses.
Active Router: The current standards term for the router forwarding traffic for the virtual address; Keepalived configs commonly express this as MASTER.
Backup Router: A peer that listens for advertisements and can take over when the active node stops advertising.
VRID: Virtual router ID, a number from 1 to 255 that identifies a VRRP peer group on a segment.
Advertisement interval: The configured time between VRRP advertisements sent by the active node.
Skew time: The priority-based delay added to the active-down timer so higher-priority backups can converge sooner.
Track script: A Keepalived health-check command that can adjust effective priority or fault handling after repeated failures.

References:

RFC 9568: Virtual Router Redundancy Protocol Version 3 for IPv4 and IPv6, IETF.
Keepalived for Linux Manpage, Keepalived.
Keepalived Configuration Synopsis, Keepalived.