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.

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.errors.length ? 'Fix before using this config' : 'Review before using this config' }}

{{ item }}
{{ item }}

{{ 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 }}

Export to PDF Fullscreen

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Keepalived uses Virtual Router Redundancy Protocol (VRRP) to let a group of Linux nodes present one shared virtual IP address. One node acts as MASTER and owns the address. The other nodes listen for advertisements and can take over when the MASTER stops sending them.

That shared address is often used in front of a load balancer, firewall, DNS resolver, database proxy, or small service pair where clients need one stable target. The configuration has to answer several operational questions at once: which interface carries the advertisements, which virtual router ID (VRID) identifies the group, which priority should win the election, which virtual IP rows are owned, and how peers hear each other.

VRRP pair with one MASTER node, one BACKUP node, a shared virtual IP, advertisements, and a master down timer.

VRRP configuration is small, but the failure modes are not small. Duplicate VRIDs on the same segment can confuse peer groups. A priority that is too close to a peer can make election outcomes harder to predict. A multicast path that the network blocks can leave every node waiting alone. A health check that is too aggressive can move the virtual IP away from a host during a brief service pause.

A generated Keepalived draft should be reviewed with the peer node beside it. The local file can look valid while the pair is still mismatched on VRID, VIP rows, advertisement interval, authentication choice, unicast addresses, or preemption behavior.

Technical Details:

A Keepalived VRRP instance is built around a named vrrp_instance. Inside that block, state sets the startup role, interface names the Linux interface that handles advertisements, virtual_router_id identifies the peer group, priority participates in MASTER election, and virtual_ipaddress lists the shared addresses that move with the active node.

VRRP peers exchange advertisements on a shared network path. In multicast mode the network must pass VRRP multicast. In unicast mode each node needs a local unicast_src_ip and matching unicast_peer rows on the other nodes. The same VRID, VIP rows, advertisement interval, and authentication choice must be aligned across the peer set, while priorities should remain different enough to make the expected owner clear.

Rule Core:

Keepalived VRRP directives and review meaning
Configuration part	Directive	Review meaning
Node identity	`global_defs.router_id`	Names the local Keepalived process for logs and transition notices.
VRRP group	`vrrp_instance` and `virtual_router_id`	The instance label should match peer files, and the VRID must be the same inside one peer set.
Election	`state`, `priority`, and optional `nopreempt`	Highest priority normally wins MASTER; `nopreempt` lets a lower-priority MASTER keep the VIP after a higher-priority node returns.
Transport	`interface`, `unicast_src_ip`, and `unicast_peer`	Use unicast when multicast VRRP is blocked, and make each peer point back to the real addresses of the other nodes.
Shared address	`virtual_ipaddress`	Each accepted VIP row is emitted as one address line, including prefix and any options kept on that row.
Health response	`vrrp_script` and `track_script`	A periodic command can lower effective priority or force fault behavior after configured fall failures.
Transitions	`notify_master`, `notify_backup`, and `notify_fault`	Optional absolute paths run when the instance changes state.

The failover timer combines the advertisement interval with a priority-based skew. A higher priority produces a smaller skew, so a stronger backup can declare the MASTER down a little sooner than a weaker one when advertisements stop.

Failover Timing Formula:

Skew = \frac{(256 - Priority)}{256} AdvertInterval MasterDown = 3 AdvertInterval + Skew

With priority 150 and advert_int of 1 second, the skew is about 0.414 seconds, so the master-down estimate is about 3.41s. The generated Failover Timing chart splits that estimate into the three-advertisement window and the priority skew component.

Validation Boundaries:

Validation boundaries used by the Keepalived VRRP generator
Field or choice	Accepted or adjusted behavior	Review cue
`virtual_router_id`	Clamped to whole numbers from `1` to `255`.	Keep the same value on peers, and avoid overlapping duplicate VRIDs on the same segment.
`priority`	Clamped to whole numbers from `1` to `255`.	Priority `255` is address-owner behavior; health tracking cannot reduce it like an ordinary priority.
`advert_int`	Clamped to `0.1` through `60` seconds.	All peers should use the same interval before comparing failover timing.
VIP rows	Each row must start with an IPv4 or IPv6 address, optionally with a prefix. Braces are rejected.	Mixed IPv4 and IPv6 VIP rows produce a review warning because separate instances or excluded addresses may be more appropriate.
Unicast peer rows	Each row must start with one IPv4 or IPv6 address without a CIDR prefix. Duplicate rows are omitted with a warning.	Unicast mode also requires a local source address and at least one peer address.
`auth_pass`	Required only when PASS authentication is enabled, truncated to the first eight characters, and blocked if it contains whitespace or braces.	PASS is a legacy compatibility choice and must match on all peers when used.
Health script	Script interval is `1` to `300` seconds, weight is `-253` to `253`, and fall/rise counts are `1` to `20`.	A negative weight is common for service-failure penalties; weight `0` can send the instance to FAULT after fall failures.
Notify paths	Blank values are omitted; control characters and braces are blocked, and non-absolute paths are warned.	Confirm the scripts exist, are executable, and behave safely during repeated state changes.

The configuration text remains a draft even when the page reports no blockers. Keepalived syntax, host firewall rules, service script permissions, interface names, multicast reachability, and peer-side values still need validation on the systems that will run the pair.

Everyday Use & Decision Guide:

Start with a two-node unicast pair when you are drafting for cloud networks, routed VLANs, or segments where multicast VRRP is uncertain. Set Router ID to the local host label, use the same VRRP instance name and Virtual router ID on both nodes, and give the preferred active node the higher Local priority.

Use Virtual IP address rows for the exact addresses Keepalived should own. Keep each address and its options on one line, such as 10.44.20.10/24 dev ens192. Run Normalize VIPs after the page accepts the rows if you want the textarea rewritten from the parsed lines.

Choose Unicast peers when you can name each peer address directly. The local source address should be the real address that peers can reach.
Choose Default multicast only when the switches, host firewall, and cloud network pass VRRP multicast for the address family in use.
Use Add nopreempt when a recovered preferred node should not immediately take the VIP back from a healthy current MASTER.
Enable Add vrrp_script health tracking when service health should affect the instance, then choose a track weight and fall/rise counts that match the service's normal failure pattern.
Leave PASS authentication omitted unless a legacy peer set requires it. If enabled, keep the string at eight characters or fewer and match it on every peer.
Add notify scripts only after the transition actions are idempotent. Repeated MASTER, BACKUP, or FAULT changes can otherwise create their own outage.

Stop on Fix before using this config. The output will still show commented diagnostic text, but that is for review, not deployment. Common blockers include an empty VIP list, a missing unicast source address, peer rows with CIDR prefixes, missing PASS text, or a required health script path left blank.

Treat Review before using this config as a real pause. Warnings such as mixed IPv4 and IPv6 VIP rows, priority 255 with health tracking, a high-priority BACKUP, or multicast selected with leftover unicast values can all produce text that needs an operator decision before it reaches a host.

Step-by-Step Guide:

Draft one node at a time, then mirror the peer-sensitive values into the other node's file.

Enter Router ID and VRRP instance name. If the summary or Directive Audit shows a normalized label, confirm the final text still matches your host naming plan.
Choose Initial state, VRRP interface, Virtual router ID, Local priority, and Advertisement interval. The summary badges should show the chosen VRID, priority, peer transport, and readiness state.
Set Preemption behavior. If Add nopreempt is selected, verify the generated VRRP Config includes nopreempt and that the startup role supports the behavior you expect.
Add one or more Virtual IP address rows. If the alert says a row must start with an IPv4 or IPv6 address, fix that row before copying the configuration.
Choose Peer transport. In unicast mode, fill Local unicast source IP and Unicast peer IPs; the Peer Checklist should list the local node plus one row per accepted remote peer.
Open Advanced only for PASS authentication, health tracking, or transition scripts. When health tracking is enabled, the generated text should include both vrrp_script and track_script.
Read the alert area and Directive Audit. Clear every Blocker, then decide whether each Review row should be accepted or changed.
Open Failover Timing and compare the advertisement window, priority skew, and total master-down estimate against the outage window your service can tolerate.
Use VRRP Config only after the peer-side values are ready to be generated with the matching VRID, VIP rows, authentication choice, and advertisement interval.

Interpreting Results:

VRRP Config is the generated Keepalived draft. Directive Audit explains each directive, generated value, and deployment note. Peer Checklist is the handoff view for matching the other nodes. Failover Timing estimates how long a backup waits after advertisements stop.

Keepalived VRRP output cues and follow-up checks
Output cue	Meaning	Follow-up
Check input	At least one blocker exists, and the configuration text starts with comments describing the issue.	Fix the alert items before using the generated config text.
Review	The text can be generated, but one or more warnings need a decision.	Read Directive Audit and approve or change the affected setting.
Copy ready	The page found no blockers or warnings for the current values.	Still test Keepalived syntax and peer reachability on the target hosts.
Master-down estimate	The total of three advertisement intervals plus priority skew.	Compare the estimate with service recovery expectations, then test a controlled failover.

A clean draft does not prove that failover will work. It does not check switch multicast behavior, host firewall rules, Linux interface names on the peer node, script permissions, or whether a service behind the VIP is healthy after the address moves. Use the generated audit as a pre-check, then run a Keepalived syntax test and a controlled failover in the target environment.

The strongest confidence signal is consistency across nodes. The VRID, VIP rows, advertisement interval, and PASS choice should match; local source IPs, peer rows, router IDs, priorities, and notify script paths should be local to each node.

Worked Examples:

Two load balancers on unicast. A local node named lb01 uses instance VI_APP, interface ens192, VRID 42, priority 150, advert_int 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. VRRP Config includes unicast_src_ip, a unicast_peer block, and one virtual_ipaddress row. Failover Timing shows about 3.41s for the master-down estimate.

Recovered node should wait. A maintenance plan leaves lb02 temporarily MASTER with priority 100. The preferred node returns with priority 150, but Preemption behavior is set to Add nopreempt. Directive Audit marks preemption for review because the generated nopreempt line changes recovery behavior. That draft is useful when stability matters more than immediately returning the VIP to the preferred host.

Health check penalty for HAProxy. Enabling Add vrrp_script health tracking with Track script path set to /usr/local/bin/check_haproxy.sh, interval 2, weight -20, fall 2, and rise 2 generates a top-level vrrp_script and attaches it with track_script. Directive Audit reports the script name, weight, fall, and rise values so the service team can decide whether two failed checks should reduce priority.

Peer row with a CIDR prefix. If Unicast peer IPs contains 10.44.20.12/24, the alert reports that the row should use an address without a CIDR prefix. VRRP Config starts with comments explaining the blocker. Replace the peer value with 10.44.20.12, then confirm Peer Checklist has a remote peer row before using the config text.

FAQ:

Should I use unicast or multicast?

Use unicast when each peer has a reachable real address and the network may block VRRP multicast. Use multicast only when the interface, switches, firewall, and platform allow VRRP advertisements for the peer segment.

Why does the peer row reject a CIDR prefix?

Unicast peer IPs are peer node addresses, not VIP or route rows. Enter 10.44.20.12 rather than 10.44.20.12/24, then check Peer Checklist for the accepted remote peer.

Does priority 255 make health tracking safer?

No. The page warns when priority 255 is combined with health tracking because address-owner behavior is different from ordinary priority. Use an ordinary priority such as 150 when a script weight should reduce election strength.

Why is PASS authentication marked for review?

PASS authentication is supported as a compatibility option, but it is a legacy choice. If enabled, the PASS string is required, only the first eight characters are used, and the same value must be configured on every peer.

Are the generated values sent to a server for processing?

The current generation, audit rows, peer checklist, timing estimate, and JSON payload are built in the browser session after the page loads. Avoid entering sensitive deployment secrets into fields such as PASS text or notify paths unless that fits your local handling policy.

Glossary:

VRRP: Virtual Router Redundancy Protocol, the election and advertisement protocol used to move responsibility for a shared address.
VRID: The virtual router identifier that peers use to recognize the same VRRP group.
VIP: The virtual IP address owned by the current MASTER and moved to a backup after failover.
MASTER: The node currently responsible for the VIP and for sending VRRP advertisements.
BACKUP: A peer node that listens for advertisements and can take over when the MASTER is considered down.
Preemption: The behavior where a higher-priority node can reclaim MASTER after it returns.
Master-down estimate: The calculated wait before a backup can decide the MASTER has stopped advertising.

References:

RFC 5798: Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6, Internet Engineering Task Force, March 2010.
Keepalived configuration man page, Keepalived project.