keepalived 中不存在 vrrp_garp_master_delay 参数，实际控制 garp 行为的是 vrrp_garp_master_refresh、vrrp_garp_master_refresh_repeat 和 vrrp_garp_interval，切换延迟主因是 arp 缓存未及时更新。
这个参数其实并不存在——Keepalived 官方配置中没有 vrrp_garp_master_delay 这一选项。你可能混淆了几个关键参数：真正控制 GARP 行为的是 vrrp_garp_master_refresh、vrrp_garp_master_refresh_repeat 和 vrrp_garp_interval；而影响“切换后延迟发 GARP”的核心机制，实际由 advert_int（通告间隔）和状态跃迁逻辑共同决定。
明确可用的 GARP 相关参数
Keepalived 中与 GARP 发送直接相关的可调项如下：
- vrrp_garp_master_refresh：Master 启动或接管 VIP 后，首次批量发送 GARP 的次数（默认 5 次）
- vrrp_garp_master_refresh_repeat：每次批量 GARP 之间的毫秒级间隔（默认 1000 ms）
- vrrp_garp_interval：Master 稳态运行期间，周期性刷新 GARP 的间隔（默认 0，即禁用）
- advert_int：VRRP 通告包发送间隔（秒级，默认 1），它间接影响 Master 切换完成的判定时机
为什么“切换后网络响应慢”？根源在 ARP 缓存同步滞后
双机切换后客户端无法立即访问 VIP，通常不是因为 Keepalived 没切成功，而是交换机/终端仍缓存着旧 Master 的 MAC 地址。GARP 的作用就是主动“喊话”刷新这个映射。但若 GARP 发得太少、太晚、或被交换机限速丢弃，就会出现“VIP 已切换，流量仍发往宕机节点”的现象。
典型表现：
- 切换完成后 ping VIP 通，但业务 TCP 连接超时（因 SYN 包被发到旧 MAC）
- 抓包看到客户端发出的 ARP 请求未得到响应（说明交换机没更新，也不代答）
- 手动在客户端执行
arp -d VIP后立即恢复通信
实用调优建议（针对物理网络环境）
目标是让新 Master 在接管后 尽快、可靠、不扰动地广播 GARP，覆盖全网关键设备的 ARP 表。推荐组合配置：
- 将
vrrp_garp_master_refresh设为 10（比默认 5 更充分，应对高丢包率交换机） - 将
vrrp_garp_master_refresh_repeat设为 200（200ms 间隔，10 次共 2 秒内密集刷新，提高到达率） - 保持
vrrp_garp_interval为 0（稳态无需轮询，避免无谓流量） - 确保
advert_int≤ 1（配合 VRRP 快速检测，避免 Backup 等待过久才升主）
示例配置片段：
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
vrrp_garp_master_refresh 10
vrrp_garp_master_refresh_repeat 200
# 其他配置...
}配合交换机侧的关键动作
参数调优只是半程。若交换机 ARP 老化时间长达数小时（如 Cisco Nexus 默认 4 小时），再频繁的 GARP 也难覆盖所有设备。务必同步操作：
- 在接入层交换机启用 Gratuitous ARP 学习（部分厂商叫
arp learning gratuitous） - 将核心交换机的 ARP 老化时间缩短至 300 秒以内（如
arp aging-time 300） - 确认交换机未开启 ARP 报文限速（如 Cisco 的
arp rate-limit），否则 GARP 可能被批量丢弃
