實戰:你敢信?運營商中心機房同時上兩套 VRRP 熱備網關,竟互相打架導致整網爆炸!
本期分享的案例是VRRP雙機熱備的相關問題。
背景介紹
這是個大單子:某大型運營商中心機房增補出口網關設備的項目。機房原有出口網關運行的是某W的框架式路由器,2塊路由板卡做“雙機熱備”,負責A區域網絡出口,核心交換也是某W的。
近期因業務需要,采購了另一家某C的框式路由器,同樣也是2塊路由板卡做“雙機熱備”,打算作為B區域網絡的出口:
網絡拓撲說明:
- 核心交換機做MUX VLAN,上聯出口路由VLAN10為主VLAN,A、B區域分別為從VLAN100、200,均屬于互通型從VLAN;
- 核心交換機與出口網關上聯萬兆光纖互聯,下聯千兆以太網A、B區域的匯聚交換機;
- 原有某W框兩塊路由板卡分別接入核心G0/1和G0/2口作為一個熱備組,作為區域A網關;
- 新增某C框兩塊路由板卡分別接入核心G0/3和G0/4口作為一個熱備組,作為區域B網關。
備注:MUX VLAN,從VLAN可以和主VLAN通信,互通型從VLAN下的終端均可互訪。
問題描述
結果發現,新增的某C網關路由接入核心網絡后,A、B網絡區域均發生癱瘓!這兩組熱備雖說在同一個局域網中,但是對內的網關IP是不同的不存在沖突,怎么會造成內網區域全部癱掉呢?兩兄弟打架啦?
如果撤掉C框路由熱備組,網絡又一切正常:
由于項目重大,不會給太多時間排障處理,甲方要求必須1小時之內定位并解決。OK,一起來看這個案例!
排查分析
第一步、確認Ping包交互情況
為了快速定位報文轉發情況,于是我們在某W框入口和核心連接A區域下聯口抓包:
發現ICMP報文PC是有轉出來的,源目的MAC均正確,但是大量的ICMP 請求并沒有轉到核心連接W框的上聯口,只有1個請求被W框路由收到并且也做了應答:
從這一步說明:出口框收發包沒問題,區域A的電腦終端收發包也沒問題。那么問題指向核心交換機,大概率是將報文轉錯接口或者未轉發?
PS:其實有經驗的工程師看到這一步大概能猜到為啥兩個熱備組接入網絡會打架了。
第二步、查看核心交換機的MAC地址表
確認交換機端口轉發是否正確,首要看其MAC地址表中對應目的MAC是否正確。這個拓撲中網關是熱備,大家注意哦,它本質上是VRRP,網關是虛擬IP+虛擬MAC。從上述抓包可以看到網關虛擬MAC是VRRP:0000-5e00-0101,多次核心交換機敲擊命令:
<CenterSwitch> dis mac-address 0000-5e00-0101
回顯如下:
這里徹底搞清楚原因:
熱備網關的MAC地址存在頻繁漂移,導致A、B區域終端訪問網關震蕩,也就是說這個VRRP虛擬的MAC地址0000-5e00-0101既能從G0/0/1接口學到、又能從G0/0/3接口學到,所以是兩個雙機熱備出口網關的虛擬MAC地址相同而產生的沖突!那到底是怎么回事呢?
第三步、查看VRRP相關參數信息
我們從PC側抓到的報文中分析可發現有2份VRRP宣告報文,分別是源IP為172.16.10.1和10.10.10.1兩個熱備組發過來的,但是注意,它們的源MAC是一致的均為0000-5e00-0101:
為什么這個生成的VRRP虛擬MAC是相同的呢?
因為VRRP協議規定:虛擬 MAC 地址的生成取決于 VRRP 備份組編號(VRID)。虛擬 MAC 地址的格式為 00-00-5E-00-01-[VRID],其中 [VRID] 是 VRRP 備份組的編號,以十六進制表示。例如,如果 VRRP 備份組編號是 5,那么對應的虛擬 MAC 地址就是 00-00-5E-00-01-05。
rfc vrrp協議原文
綜合分析
某W和某C配置的VRRP雙機熱備都是VRID=1,導致生成的虛擬MAC相同造成核心交換機主VLAN地址表紊亂,從而出現轉發異常整網癱瘓。相關VRRP組配置如下:
某W雙板卡熱備框式路由器:
某C雙板卡熱備框式路由器:
備注:這里沒有要到現場截圖,我就以eNSP模擬器的方式向大家展示了,實際情況一致。
解決方案
修改新增某C的VRID配置為2,生成的虛擬MAC即為0000-5E00-0102唯一不沖突:
雙熱備組同時接入網絡A、B區域均能正常上網和通信: