1 問題背景

這是一份基礎網絡運維的事故復盤報告。

因為一些歷史原因，我司各個環境之間的互聯互通采用了串行連接，并且核心鏈路和轉發節點使用了共享資源，既下圖中紅色部分。因為共享資源的可靠性和穩定性表現不佳且故障場景下的權限不足，倍受困擾后下定決心要改變這種局面。在梳理了現有資源之后，基礎網絡架構躍遷歷程如下：

圖片

• 互聯方式由之前身不由己的純靜態路由調整為全BGP環境。因為是混合云架構，所有鄰居之間全部基于EBGP對接，子接口部署，路由結構如下圖所示：

圖片

• as分布如圖所示，看起來很棒：閉合連接/雙上行/EBGP，這些特性配合BFD和觸發更新，完全有能力在異常情況下實現毫秒級的路由收斂，踢出故障鏈路后使流量快速切換到備用路徑。
• 然而，不出意外的，我們遇到了意外———割接很順利，架構變更按計劃完成，但在驗證高可用能力的過程中遇到了光路中斷，造成EBGP-5鄰居狀態idle，導致辦公環境與托管IDC失聯：

圖片

• 確認問題鏈路兩端模塊的光功率均在合理區間，基本排除了模塊故障的可能性。托管IDC側掛表測試，OTDR顯示近端衰減，確認鏈路狀態不可用，鎖定位置后反饋有管井臨時施工造成鏈路中斷。但EBGP鄰居down了，理論上應該能夠通過冗余路徑學到路由才是，為什么會失聯呢？

2 探索

于是問題排查的重心調整到高可用方向。

2.1 鄰居狀態確認

優先確認了所有EBGP鄰居的關系狀態，確保均為established。

圖片

圖片

2.2 路由有效性檢查

其次檢查辦公環境和托管IDC內網出口方向的路由宣告詳情，確認兩側BGP進程路由宣告成功。

圖片

圖片

2.3 路由過濾

再次則分別排查內網出口方向的前綴列表，確認已生效的過濾邏輯不存在誤殺情況。

2.4 手搓新網段，觸發路由更新

最后嘗試在辦公環境內網出口設備上新增loopback，配置并發布一個新的子網和相應的路由，隨后檢查EBGP鄰居的路由收發情況，發現情況依舊。

3 分析原因

經過上述測試排查，發現如下特征————

• 兩端設備配置正確，且路由宣告正常；
• 云上網絡組件L3節點本地路由表中有直連鄰居宣告的路由，說明可以收到正確且完整的路由更新；
• 跨過云上網絡組件后，再下一跳設備（也就是本文中問題鏈路的遠端設備）的路由表中就找不到相應的路由信息了；
• 再進一步測試，在托管IDC本地開debug實時打印路由更新，確認從云上EBGP鄰居處收到的路由更新中，并不包含辦公環境所屬網段的路由信息。

綜上，辦公環境和托管IDC內網出口方向，兩端設備都向云上L3節點宣告了本地路由，云上L3節點也能正常收到路由信息并加入自身的路由表，但是，云上L3節點并不會把這些路由信息再轉發到遠端的云下設備。折騰了近2個小時，過程中我甚至想到了古早概念-水平分割，但想到產品經理明確強調過：“專線接入點就是個渠道，當成鏈路看待就可以了”，加之方案設計時還額外增加了子接口的配置，結果還是在防環上踩了坑。最終又拉上云服務商的售后升級確認，才真正破案。萬萬妹想到哇，555555

4 解決方案

針對問題情況，揪著售后一起確認了各種細節后，敲定了解決方案————

• 在云上再單獨創建一個L3節點；
• 這個新建的L3節點為辦公環境和托管IDC分別連接一個專線接入點；
• 托管IDC和辦公環境的內網出口節點，各自再創建一個子接口，用于和新增的專線接入點對接，并與云上新建的L3節點建立EBGP鄰居EBGP-6和EBGP-7；
• 托管IDC和辦公環境的內網出口節點，分別將本地的路由信息通過新建子接口發布給云上這個新的EBGP鄰居；
• 新增的EBGP-6和EBGP-7這兩組鄰居關系，可以為EBGP-5提供冗余路徑和路由更新渠道，調整后的方案如下圖所示：

圖片

5 總結

整體看下來，問題其實很簡單，認為有了子接口，又是不同as之間的EBGP鄰居，不會受到as-path、水平分割這類防環邏輯的限制，但其實是思維定勢的誤區，造成了后面的周折和時間損耗。

誠然，BGPv4仍是當代互聯網的基礎，但云服務帶來了新鮮內容，基于云的各種能力和產品，相較企業網和數通的傳統技術概念有了明顯變化，應該在掌握基礎的前提下，明了新產品和新特性的更新迭代，真正理解這些不同之處的關聯場景和針對的痛點，才能正確的發揮優勢體現價值，給上層服務提供穩定和持久的支撐。

關于作者

宛景瑞，轉轉基礎設施運維負責人。