Keepalived：無效的主轉換

我們有一個兩台機器的 keepalived 設置，兩台機器的配置方式相同。

vrrp_instance RP_VI_1 {
 interface                 eth3
 state                     BACKUP
 virtual_router_id         61
 priority                  150
 advert_int                1
 garp_master_delay         5

 virtual_ipaddress {
   x.x.x.x dev eth2
 }
}

兩台機器已經在這個配置下執行了大約半年，沒有任何問題，但是今晚出現了一個看似錯誤的狀態轉換。

host1: in BACKUP state
host2: in MASTER state

03:44:44: host1: Transition to MASTER state
03:44:45: host1: Entering MASTER STATE
03:44:46: host1: Received higher prio advert 150
03:44:46: host1: Entering BACKUP state

在那段時間，host2 沒有在任何狀態之間轉換，也沒有記錄任何資訊。因此，host1 向網路發送了一個免費的 ARP，它的 mac 地址被記憶體了幾個小時，同時丟棄了所有流量。

我們最大的問題是，host1 恢復到 BACKUP 狀態，說收到“更高優先級廣告”，而兩個主機的優先級相同，都是 150。如果系統沒有隨後通信來決定誰應該留下，怎麼可能觸發了這個轉換master 並因此發送一個新的免費 ARP 以確保數據包被傳輸到正確的主機？

通讀 VRRPv2 (RFC3768) 定義後，以下是明顯的：

1. 使用兩個具有相同優先級主 IP 地址的主機之間的平局斷路器。IP地址高的主機獲勝，IP地址低的主機轉為MASTER

2. garp_master_refreshkeepalived 選項可用於在 x 秒後重新發送免費 ARP。由於此預設值為 0，現在預設情況下重新發送請求，指定它應該會導致系統在一段時間後恢復。

引用自：https://serverfault.com/questions/1004811