When configuring multiple VRRP instances across nodes in a Keepalived cluster, the virtual_router_id parameter plays a crucial role in VRRP communication. This ID identifies the VRRP group and must be unique within the same broadcast domain.

vrrp_instance VIP1 {
    virtual_router_id 51
    interface eth0
    priority 100
    virtual_ipaddress {
        192.168.1.100/24
    }
}

vrrp_instance VIP2 {
    virtual_router_id 52
    interface eth0
    priority 100
    virtual_ipaddress {
        192.168.1.101/24
    }
}

The key clarification needed is that virtual_router_id must be:

• Unique per VRRP instance within the same broadcast domain
• Can be reused across different physical nodes if they're in separate broadcast domains
• Must be unique for each VIP on the same interface

For two nodes with two VIPs each (as in your example), here's how to properly set the router IDs:

# Node 1 configuration
vrrp_instance VIP1 {
    virtual_router_id 51  # Unique in broadcast domain
    ...
}

vrrp_instance VIP2 {
    virtual_router_id 52  # Must differ from 51
    ...
}

# Node 2 configuration
vrrp_instance VIP1 {
    virtual_router_id 51  # Matches Node1's VIP1 ID
    ...
}

vrrp_instance VIP2 {
    virtual_router_id 52  # Matches Node1's VIP2 ID
    ...
}

1. Duplicate IDs on same interface: Causes VRRP communication conflicts

2. Overlapping IDs in large environments: Use a numbering scheme (e.g., VLAN ID + increment)

3. ID conflicts after node replacement: Document your ID allocation

When dealing with separate networks/VLANs, you can reuse IDs:

# VLAN 100 configuration
vrrp_instance VLAN100_VIP {
    virtual_router_id 100
    interface eth0.100
    ...
}

# VLAN 200 configuration (can use same router_id)
vrrp_instance VLAN200_VIP {
    virtual_router_id 100
    interface eth0.200
    ...
}

The key takeaway is that router IDs must be unique per broadcast domain, not necessarily per physical node. This allows flexible configurations while maintaining proper VRRP operation.

When configuring Keepalived with multiple VIPs across nodes, the virtual_router_id parameter often causes confusion. Let me clarify how this works based on real deployment experience.

The virtual_router_id identifies a VRRP instance within a broadcast domain. Key points:

• Must be unique among competing instances (those managing the same VIP)
• Can be duplicated for instances that don't interact with each other
• Range: 1-255 (RFC 5798 compliance)

For your two-node, two-VIP setup:

# Node 1 keepalived.conf
vrrp_instance VIP1 {
    virtual_router_id 51
    # other config...
}

vrrp_instance VIP2 {
    virtual_router_id 52
    # other config...
}

# Node 2 keepalived.conf
vrrp_instance VIP1 {
    virtual_router_id 51  # MUST match Node1's VIP1
    # other config...
}

vrrp_instance VIP2 {
    virtual_router_id 52  # MUST match Node1's VIP2
    # other config...
}

1. Same VIP cluster: All nodes must use identical virtual_router_id
2. Different VIPs: Should use distinct IDs to prevent multicast conflicts
3. Across datacenters: Can reuse IDs when VLANs/L3 separation exists

Check VRRP advertisements with tcpdump:

tcpdump -nn -i eth0 vrrp

This reveals whether instances with duplicate IDs are interfering.

When managing related VIPs (e.g., IPv4+IPv6 for same service):

vrrp_instance WEB_IPv4 {
    virtual_router_id 101
    # ...
}

vrrp_instance WEB_IPv6 {
    virtual_router_id 102
    track_script {
        check_web_service  # Both VIPs track same health check
    }
}