路由器之VRRP排障篇

■ 河南 李虎 夏曉斌

編者按： 筆者單位在經過網絡升級后，出現業(yè)務系統(tǒng)登錄不暢的問題，筆者經過一系列排查發(fā)現，是因為ACL訪問列表的加入導致VRRP協(xié)議工作出現異常。

S集團下屬某分公司使用兩臺H3C6604路由器部署在內網邊界，直連內網核心交換機，同時通過兩條運營商專線（800M移動和50M電信），上聯(lián)集團總部。

兩臺路由器使用VRRP協(xié)議做雙機熱備部署，電信專線路由器內網互聯(lián)IP為10.*.*.222（以下簡稱“222”），移動專線路由器內網互聯(lián)IP為10.*.*.223（以下簡稱“223”），建立了VRID分別是100和200的兩個VRRP熱備組，熱備組100的master是移動專線路由器，虛擬IP是10.*.*.210，內網核心上把去往集團的大部分流量指向了該IP；熱備組200的master是電信專線路由器，虛擬IP是10.*.*.211，內網核心上把去往集團總部的少量重要業(yè)務指向該IP。

因為兩條專線存在較大差異，通過上述部署，可以實現電信專線故障后，該鏈路上的所有流量可以由移動專線承載，而移動專線故障后，僅有少量業(yè)務流量轉移至電信專線傳輸。VRRP熱備組拓撲結構如圖1所示。

圖1 VRRP熱備組拓撲圖

故障現象

近日，集團公司要求加強網絡安全管控，該分公司網管在核心交換機上設置了ACL訪問列表，把去往集團總部的流量實行白名單準入策略。

隨后兩天陸續(xù)有很多用戶反映訪問集團總部應用系統(tǒng)時快時慢，無法進行耗時較長的在線業(yè)務，分給兩條專線的業(yè)務都存在這樣的問題。

網管人員通過ping總部服務器發(fā)現有時很流暢不丟包，響應時間很短；有時丟包嚴重，響應時間也較長。

故障分析

針對這一現象，網管員首先逐一檢查了核心交換機上的ACL策略條目，白名單策略都是嚴格按照分公司到集團的業(yè)務訪問需求做的，該通的都放通，且ACL不結合QoS策略，不會對流量快慢造成影響。接著聯(lián)系移動和電信檢查了專線鏈路，也排除了鏈路質量問題。難道是網絡攻擊造成的？網管員檢查了在內網核心和路由器之間做透明部署的防火墻，檢查了各類日志，也未發(fā)現異常。

在排除了ACL策略、鏈路質量和網絡攻擊等故障原因之后，網管員把思路重新調整到路由方面，這一調整確實有重大發(fā)現。之前，網管員登錄網管平臺曾發(fā)現50M電信專線流量明顯有異于平常，這幾天里有大量的突發(fā)流量超出了專線帶寬。另外，使用tracert追蹤路由，發(fā)現本該走移動專線路由器223的流量走的卻是電信專線222（如圖2），過一會兒再tracert，發(fā)現又正常了，如此頻繁反復，造成了50M電信專線上時常承載了超出自身帶寬能力的流量，最終導致用戶訪問集團業(yè)務出現問題也不奇怪了，如圖3。

圖2 使用tracert追蹤路由結果

圖3 頻繁反復走tracert致流量過載

圖4 兩臺路由器都宣告自己是master

圖5 增加一條策略后再次登錄路由器觀察

總結上述發(fā)現，即內網核心上去往總部的下一跳地址在兩個專線路由器之間來回變化，最終導致訪問總部業(yè)務的異常。接下來就是尋找下一跳地址來回變化的原因了。內網核心交換機把去往總部的路由分別指向了兩個專線路由器VRRP熱備組的虛擬IP，這一點不會變化，而虛擬IP代表的路由器是可能發(fā)生變化的，一般情況下，熱備組中的優(yōu)先級高的那臺路由器會被選為master，這時，master才是虛擬IP的真身。網管員分別登錄兩臺路由器，發(fā)現兩臺路由器都宣告自己是master，如圖 4。

兩臺路由器都認為自己是master，都會給內網核心交換機廣播IP（熱備組虛擬IP）相同但MAC不同的ARP信息，導致核心交換機上去往總部的路由下一跳不斷地變化，由此引發(fā)故障。

雙Master的出現一定是兩個路由器通信出現了問題，要么是互相不通，要么是VRRP工作異常。在兩臺路由器上互ping對方內網接口地址（222和223），并沒有問題。那么剩下的就只有VRRP機制工作異常這一個可能了。

故障解決

仔細回顧了一下VRRP工作原理，結合此故障現象發(fā)生的開始時間與開啟白名單準入進行訪問控制的時間相同，所以故障原因應為做白名單準入的ACL阻斷了兩個路由器之間的VRRP協(xié)商，而VRRP主備協(xié)商要用到的組播地址224.0.0.18并沒有在這個ACL的放行策略里。

此時，故障的前因后果完全清晰起來，最后一擊就變得很簡單了，在核心交換機的ACL訪問控制列表中增加一條訪問策略，如下：

rule 99 permit ip source any destination 224.0.0.18 0

增加這條策略之后，再次登錄路由器進行觀察，持續(xù)雙master的問題得到解決，業(yè)務恢復正常，如圖5。