This VRRP config generator (with HSRP and keepalived output) writes matching configurations for a primary and a backup gateway that share one virtual IP address, so clients keep working when one device fails. It runs entirely in your browser: nothing you type is sent to our server.
Loading the tool… It runs in your browser and needs JavaScript.
Table of Contents
How first-hop redundancy works
Both devices have their own IP address; clients use the virtual IP as their gateway. The device with the highest priority answers for the virtual IP. If it fails, or its tracked uplink goes down and its priority drops below the backup’s, the backup takes over within seconds.
What the VRRP config generator checks
- The virtual IP and both device addresses are in the same subnet and all different.
- The primary priority is higher than the backup’s, and the tracking decrement is large enough to make the backup win when the uplink fails.
- Group numbers fit the protocol (HSRP v2: 0-4095; VRRP: 1-255) and keepalived passwords are at most 8 characters.
On Linux servers
keepalived is the usual way to give two Linux servers (load balancers, firewalls, database proxies) a floating IP. Allow VRRP (IP protocol 112) between them in the firewall, or both will become MASTER (split brain).
Using the VRRP config generator step by step
- Enter the virtual IP and the subnet both devices share. The virtual IP must be unused and in the same subnet as both interface addresses.
- Pick the protocol: VRRPv3 for mixed vendors and Linux (keepalived), HSRP v2 when both gateways are Cisco.
- Give the primary the higher priority (for example 110 against 100) and keep preemption on, so it takes the role back after a reboot.
- Add interface or object tracking, so the primary steps down when its uplink fails, not only when the whole device dies.
- Apply both configs, then test: shut the primary’s LAN interface and keep a ping running from a client to the virtual IP.
Common mistakes:
- Different group (VRID) numbers or virtual IPs on the two devices: both become master, a split brain.
- A firewall dropping the hellos: VRRP is IP protocol 112 to 224.0.0.18; HSRP is UDP 1985 to 224.0.0.2 (version 1) or 224.0.0.102 (version 2). Blocked hellos also make both sides active.
- Cloud networks without multicast: keepalived then needs
unicast_src_ipandunicast_peer. - Equal priorities: the higher interface address wins, which may not be the device you expect.
Related tools and guides: VLAN config generator, subnet calculator, Cisco ACL generator, Windows DHCP failover.
How we checked it
We checked the generated HSRP, VRRPv3 and keepalived configurations on 11-12 October 2026, including interface tracking, and the validation of subnets, priorities and the tracking decrement.
Protocol references: VRRPv3 is RFC 5798, and HSRP is described in
Frequently asked questions
What is the difference between HSRP and VRRP?
HSRP is Cisco’s protocol; VRRP is an open standard (RFC 5798) supported by most vendors and by keepalived on Linux. They work in the same way.
Why use preempt delay?
So a rebooted primary waits until its routing has converged before taking the gateway role back.
Why do both keepalived servers think they are MASTER?
They cannot see each other’s VRRP advertisements, usually because a firewall blocks IP protocol 112 or multicast between them.