During a network switch failure in our VLAN setup, we encountered a VIP connectivity issue that persisted even after switch recovery. Here's what happened:

• Primary switch failed, triggering keepalived failover to backup instance
• Backup sent gratuitous ARP (GARP), but Cisco ASA missed it due to switch failure
• After switch recovery (minutes later), VIPs remained inaccessible
• ASA retained stale ARP entries (4h timeout) without issuing new ARP requests
• Manual keepalived restart was required to trigger new GARP and restore access

By default, keepalived sends GARP packets:

1. Immediately after taking over VIP
2. At 5-minute intervals while maintaining VIP ownership
3. During graceful shutdown

The 5-minute interval may be insufficient for devices with long ARP timeouts (like Cisco ASA's 4h default).

We can modify the keepalived configuration to send more frequent GARP updates:

vrrp_instance V1 {
    state BACKUP
    interface eth0
    virtual_router_id 150
    priority 120
    advert_int 1
    garp_master_delay 1       # Delay after becoming master before sending GARP
    garp_master_repeat 2      # Number of additional GARP packets to send
    garp_master_refresh 60    # Seconds between refresh GARP packets
    garp_lower_prio_repeat 1  # GARP packets to send when priority lowers
    
    virtual_ipaddress {
        10.xxx.xxx.xxx dev eth0
    }
}

For environments where keepalived configuration isn't sufficient:

Script-based periodic GARP:

#!/bin/bash
while true; do
    ip neigh flush dev eth0
    arping -c 3 -U -I eth0 10.xxx.xxx.xxx
    sleep 300  # Adjust interval as needed
done

Cisco ASA Workaround:

! Reduce ARP timeout on ASA
arp timeout 600  # 10 minutes instead of default 14400 (4 hours)

! Or enable ARP inspection
arp inspection trust

To verify your GARP configuration:

# Monitor ARP traffic
tcpdump -i eth0 'arp' -n -v

# Check ASA ARP table
show arp | include 10.xxx.xxx.xxx

• Balance GARP frequency with network load
• Monitor switch buffer capacity during failover events
• Consider VRRP advert_int timing when setting garp_master_refresh
• Test failover scenarios with actual network equipment

For critical environments, combine periodic GARP with health checks that force ARP updates when detecting stale routes.

During a recent network incident involving a switch failure in our VLAN setup, we observed an interesting ARP caching behavior that crippled VIP accessibility for nearly 4 hours. Here's the technical breakdown:

Sequence of Events:
1. Primary switch failure occurred
2. Keepalived successfully failed over to backup instance
3. Backup sent GARP (gratuitous ARP) but Cisco ASA missed it
4. Switch recovered after several minutes
5. ASA retained stale ARP entry (4h timeout)
6. Manual keepalived restart forced new GARP

The standard keepalived configuration only sends GARP packets during these events:

• Initial VIP assignment
• After failover completion
• When manually restarted

This becomes problematic with long ARP cache timeouts (like Cisco ASA's default 4 hours).

We can modify the keepalived configuration to periodically refresh ARP caches:

vrrp_instance V1 {
    ...
    virtual_ipaddress {
        10.xxx.xxx.xxx dev eth0
    }
    # Send GARP every 60 seconds
    garp_master_refresh 60
    # Number of GARP packets to send per refresh
    garp_master_repeat 2
    # Delay between repeated GARPs
    garp_lower_prio_repeat 1
}

For Cisco ASA-specific environments, consider these additional approaches:

# ASA ARP timeout adjustment (not always practical)
arp timeout 300  # Sets 5 minute timeout instead of default 14400

# Combined with keepalived advanced configuration:
vrrp_script chk_arp {
    script "arping -c 1 -I eth0 -s 10.xxx.xxx.xxx 10.xxx.xxx.1"
    interval 30
    fall 2
    rise 1
}

After implementation, verify GARP transmission with tcpdump:

tcpdump -i eth0 'arp and (arp[6:2] == 2)' -vv
# Should show periodic GARP packets from backup when active

For ASA verification:

show arp | include 10.xxx.xxx.xxx
# MAC address should match current active node