Table of Contents
Why Basic VRRP Is Not Enough
VRRP provides a shared virtual IP address across multiple routers. Through a Active/Backup election process, it decides which router currently responds to that virtual IP.
For a simple LAN default gateway, a single VRRP instance is usually enough to provide gateway redundancy. However, enterprise edge routers often provide multiple gateway functions at the same time, including WAN access, LAN routing, NAT, and service publishing.
For example, a dual-WAN enterprise gateway may use multiple VRRP instances:
- ISP-A WAN VIP for the first Internet connection
- ISP-B WAN VIP for the second Internet connection
- LAN Gateway VIP for internal users
By default, each VRRP instance performs its own Master/Backup election independently. This means different virtual IPs may be active on different routers after a failover event.
For example:
- Router-A owns the LAN Gateway VIP and ISP-A WAN VIP.
- Router-B owns the ISP-B WAN VIP.
This behavior is not a VRRP protocol failure. In some scenarios, administrators may intentionally distribute different VRRP instances across multiple routers for load sharing.
However, in a high-availability gateway design, these virtual IPs are often expected to move together. They represent different parts of the same forwarding path.
If the LAN gateway remains active on Router-A while the WAN gateway has already moved to Router-B, traffic processing roles become separated between two devices. This can introduce unnecessary inter-router forwarding, suboptimal traffic paths, and inconsistent handling of services such as NAT and stateful inspection.
VRRP only determines which router owns a virtual IP address. It does not understand the relationship between multiple VRRP instances, nor does it synchronize runtime service states such as NAT sessions or connection tracking tables.
Therefore, enterprise edge routers require additional mechanisms to coordinate multiple VRRP instances and preserve service continuity during failover.
In summary, VRRP alone is not sufficient for high-availability gateway scenarios because it only provides basic gateway redundancy. The main limitations are:
- VRRP only provides virtual IP availability, not service state continuity
- VRRP does not coordinate multiple VRRP instances
- VRRP does not understand service dependency or forwarding relationship
Therefore, for complex scenarios such as dual-WAN routers, enterprise edge gateways, and multi-service gateways, additional mechanisms such as VRRP synchronization groups and session synchronization are required to achieve service-level high availability.
What Is VRRP Sync Group?
VRRP is a standard protocol, while VRRP Sync Group is an implementation-specific extension used to coordinate multiple VRRP instances and enable synchronized state changes.
In a standard VRRP deployment, each VRRP group operates independently. A network device can run multiple VRRP groups at the same time, and each group performs its own Active/Backup election based on its priority and device status.
For example, a router may have multiple VRRP groups configured:
- VRRP Group 10: Provides default gateway redundancy for user VLANs.
- VRRP Group 20: Provides default gateway redundancy for server VLANs.
- VRRP Group 30: Provides gateway redundancy for WAN uplinks.
VRRP Synchronization combines multiple VRRP groups into a single VRRP Sync Group. When one VRRP group changes its state due to a failover, fault condition, or other status change, the associated VRRP groups in the same Sync Group transition together. This prevents inconsistent VRRP states across different VLANs or interfaces on the same device.
For example, in a dual-WAN router deployment, the LAN gateway and WAN uplink gateway usually need to run on the same active device. When the active device fails or a WAN link becomes unavailable, related services should fail over together to the standby device.
Without a VRRP Sync Group, each VRRP group independently determines whether a failover is required. For example:
- The WAN-related VRRP group detects a link failure and switches to the standby device.
- The LAN gateway VRRP group remains active on the original device.
This condition may cause inconsistent traffic paths. For example, outbound traffic may continue using the original path, while return traffic follows the new WAN virtual IP path after failover. This can result in asymmetric routing, NAT state mismatch, or service connection interruptions.
How VRRP Sync Group Works in SONiC with HA Stateful Failover
VRRP is responsible for VIP failover, while a Sync Group coordinates failover across multiple VRRP instances. Service continuity relies on an additional HA Stateful Failover mechanism to synchronize runtime states between active and standby devices.
- VRRP Sync Group Coordination Mechanism
A VRRP Sync Group coordinates the states of multiple VRRP instances. When a VRRP instance within the Sync Group changes its state due to an interface failure, priority change, or health check result, other VRRP instances in the same Sync Group transition accordingly.
This ensures that related VIPs maintain consistent Active/Backup roles across different interfaces or services.
- Runtime State Synchronization with HA Sync
VIP migration alone is not sufficient because standard VRRP does not synchronize service session states.
HA Stateful Failover uses a dedicated synchronization channel to replicate runtime session states between active and standby routers in real time. The synchronized states include NAT sessions, SPI (Stateful Packet Inspection) states, and load balancing session information.
When the standby router takes over the VIP, it already has the required session context to continue forwarding existing traffic flows and performing NAT processing without disrupting active TCP/UDP connections.
- End-to-End Failover Workflow
In a real failure scenario, VRRP Sync Group and HA Stateful Failover work together as follows:
- Failure detection: A critical interface or VRRP instance detects a failure condition.
- VIP failover: The associated VRRP instances and VIPs within the same Sync Group transition together to the standby router.
- State takeover: After taking over the VIP, the standby router uses the synchronized NAT and connection tracking states to continue processing existing TCP/UDP traffic.
VRRP Sync Group Deployment Scenarios
Scenario 1: Dual-WAN Router
In an enterprise gateway with dual-WAN connectivity, the device typically runs multiple VRRP instances to provide high availability for different interfaces and services:
- WAN1 VIP: Provides gateway redundancy for the connection to ISP-A.
- WAN2 VIP: Provides gateway redundancy for the connection to ISP-B.
- LAN Gateway VIP: Provides default gateway redundancy for internal users.
Without a Sync Group mechanism, when the WAN1 interface fails, only the WAN1 VRRP instance performs a failover. The LAN gateway VRRP instance and WAN2 VIP remain active on Router A. This causes inbound and outbound traffic to traverse different routers, resulting in traffic path separation and asymmetric routing.
By binding WAN1 VIP, WAN2 VIP, and LAN Gateway VIP into the same VRRP Sync Group, any failure of the active WAN link or the primary gateway node triggers a coordinated failover. All related VRRP instances transition together to Router B, ensuring that both internal and external traffic continue to pass through the same physical gateway device.
Scenario 2: Enterprise Edge Gateway
This scenario is commonly used in branch routers, campus gateways, and SD-WAN edge devices. These gateways typically integrate multiple network services, including routing, NAT, VPN tunnels, and security policies.
Enterprise edge devices typically provide gateway services for multiple business VLANs, such as office networks, server networks, and guest networks. At the same time, they establish tunnels to connect branch sites with headquarters or cloud platforms, such as IPsec VPN tunnels or SD-WAN tunnels.
By binding multi-VLAN gateway VRRP instances with WAN-side control instances into the same VRRP Sync Group, all enterprise services can remain active on the same Active router. When the primary node triggers a failover, all related gateway roles and session states transition together to the standby router.
This prevents service disruption caused by inconsistent gateway states, such as partial subnet connectivity failures or VPN tunnel interruptions.
Scenario 3: Firewall / Security Gateway HA
In gateway or security cluster deployments with stateful firewall capabilities, devices typically divide the network into multiple independent security zones:
- Outside Interface VRRP: Provides redundancy for the external Untrust zone.
- Inside Interface VRRP: Provides redundancy for the internal Trust zone.
- DMZ Interface VRRP: Provides redundancy for the server DMZ zone.
Stateful firewalls have strict requirements for bidirectional traffic symmetry. If outbound traffic passes through Firewall A, but return traffic is forwarded to Firewall B because the VIP states are not synchronized, Firewall B cannot find the corresponding security context, such as the connection tracking table or SPI state. It will treat the traffic as invalid and drop the packets.
In this scenario, a VRRP Sync Group coordinates the VRRP states of the Outside, Inside, and DMZ interfaces, ensuring that traffic entering and leaving different security zones is always processed by the same active firewall.
Combined with HA Session Sync, runtime firewall states are synchronized between active and standby devices in real time. This enables the standby firewall to take over existing security policies and session connections during failover, minimizing service interruption and maintaining stateful traffic continuity.
SONiC VRRP Configuration Guide
Learn how to configure VRRP on SONiC-based devices for basic gateway redundancy and virtual IP failover.
Please refer to: VRRP Configuration Guide
Solution for Dual-WAN Platform Stateful Failover
Learn how to extend basic VRRP failover with VRRP Sync Group and HA Sync to achieve coordinated virtual IP failover and session continuity in dual-WAN enterprise gateway environments.
Stay tuned for our upcoming updates.
