Virtual Redundancy Routing Protocol(VRRP)是以一個虛擬IP，讓多臺設備經營這個虛擬IP，達到即使一臺因故失聯，其餘設備也能接手該IP以維持功能正常的方法之一。
VRRP是個Active Standby的運作模式，只會有一臺Active，其餘Standby。
在VRRP的用語中，主為Master，其餘為Backup。
一個正常的VRRP運作，在多臺設備中，只能看見一個Master，其餘為Standby。如果一個同網段的VRRP出現多個Master，就代表VRRP在設備間沒有正常運作，而VRRP是有特定型式的MAC前綴，因此若VM需要建立VRRP，安全性需要勾選允許偽造MAC。
一定要先檢查VRRP運作能不能正常，因為不正常的話，後續建立在VRRP的功能就會不正常。而我第一步檢查客戶環境起VRRP是正常的。
當兩台設備，想要一臺為主，另一臺為備援時，會用一組VRRP去達到目的。
當兩台設備，想要各自分擔一些流量跟使用，萬一出狀況，另外一臺能接替，這時候就會用兩組VRRP去處理，並將流量分派給兩者。
今日去客戶救援之前，得知問題設備並無明顯故障燈號時，而且出狀況後已經導流到另外一臺時，查看一下設定，很快就以VRRP去著手。並且查看各流量的分流設定。
Aruba使用VRRP的部分很多，而HA架構有很多種實踐方法，我傾向不使用VRRP，畢竟一旦能做到更舒服的備援機制，即使千台AP失去主控制器，也能在幾秒內換臺控制器繼續運作，悄悄默默地重開一臺控制器，卻沒接到回報狀況的電話，也沒人斷線。
不過上段敘述，已經是後面與現行的主力架構，早期還沒開發出這種方式，只好用VRRP去做。
VRRP確實有些不足之處，就是AS模式，就像是總統與副總統，總統存在，副總統就沒有法律上實權。總統做所有事情，副總統就是等總統不在就會去接管。能負載分享(Load Sharing)總比全讓一臺做事其餘納涼好吧，於是就更偏好各自分擔一些流量。
以VRRP去做備援，又想要各自分擔一些流量，這時候設定就不是典型VRRP那麼單純。
今天有設備A跟設備B，然後為了讓各自分擔流量，於是有了A虛擬IP與B虛擬IP。A虛擬IP平時交給設備A當Master，B虛擬IP平時就交給設備B當Master。如此能用分別幫流量設定往A虛擬IP與B虛擬IP導向，達到負載分享。
一旦設備A出狀況，設備B接手A虛擬IP，本來往設備A的就會導向設備B。
But!
後面設備A恢復時，因為VRRP在預設沒有Preempt，所以設備A並不會搶回A虛擬IP的主導權，導致設備B仍主導A虛擬IP所以吃好所有流量，該由設備A承擔的流量也將不會回到設備A身上，即使設備A已正常了。
在任何一方能承擔全部流量時，我不會設定VRRP，因為Preempt機制，一定會讓連線中斷一下下，任何一方能全擔的話，誰當Master都沒關係。
但是沒有一方能承擔全部流量時，換過去只是暫時撐個一下，等廠商緊急處理，我就會設Preempt，即便在上線時會因為Preempt斷一下，最終又能恢復設計時負載分享的架構，能恢復更完整的網路基礎服務。
正常以VRRP做負載分享的設計，只會有該虛擬IP的負責設備設定Preempt，其他不會。但這個實戰的客戶是都有設定preempt，導致一個狀況發生後，所有流量被導過去，本來設備就沒有流量，全數失聯。
後面即使設備恢復了，該回來的流量還是沒有回來。而另一方又無法撐起全部流量，就部分地區損失網路服務。
畢竟我從未瞭解客戶網路，去到時是第一次認識，於是就猜錯誰主負責的IP，如此也藉機向客戶展示VRRP功能與運作以及沒設定好會長什麼樣子。客戶說:「跟當那時很像呢~」
以VRRP設定疏失舉例，也能完美契合客戶說的網路狀況，一個狀況就全部流量往一邊導。當初為什麼狀況會發生？我也不知道，但是網路狀況發生總是意外，誰也料不準。
一旦修正成VRRP備援的正確設計，很快客戶的網路能力就全數恢復，正如預期規劃的那樣，客戶就覺得滿意，因為我來有解決掉狀況，且只是第一個論述就打中要害。
(網路除錯很常在建立假說，接著推翻假說，繼續新假說的驗證。能一次斷言就命中那是少見的)
最後要記住，以VRRP做負載分享時，如果沒有特別需求，且任何一方能承載全部流量時，就不需要用Preempt。
如果需要指定設備去負責該虛擬IP，只需要在負責設備開Preempt，不然都開就不會搶回去了。