簡介面向數據中心規(guī)劃、建設與運維人員的技術方案文檔聚焦傳統(tǒng)架構擴展性差、維護成本高、資源利用率低等痛點提出以整合能力、虛擬化能力、自動化能力和綠色節(jié)能為核心的建設框架。內容從網絡架構切入介紹一體化交換、無丟棄以太網、性能支撐、網絡服務虛擬化與服務器虛擬化等關鍵技術并結合指揮學院場景給出目錄式落地參考便于讀者對照理解設計目標如何轉化為實際部署。資源內含1個doc文檔壓縮包約2.68MB目錄按總述、技術實現等章節(jié)編排結構清晰從需求梳理到技術選型均有展開可直接用于數據中心方案設計、課程設計或項目投標的參考模板。目前已有47人學習下載適合需要快速搭建方案框架并了解新一代數據中心技術選型的工程與教學人員。1. 數據中心建設方案為什么先把寶押在 SRv6 Policy 上一份數據中心建設方案寫到網絡部分最容易變成機房平面圖和設備清單但真正決定兩年后運維體驗的往往是數據中心之間那幾十條跨機房路徑怎么被管住。我在IDC和政企DCI項目里反復遇到同一個現象Underlay路由學得通業(yè)務卻“玄學”地繞路、丟包、抖動查到最后都是策略粒度不夠流量被默認路由帶到了不想走的鏈路上。這篇筆記圍繞一個核心結論展開數據中心的跨域流量調度需要顯式路徑能力而用 SRv6 Policy 做數據中心間 policy 是目前最值得投入的方案。它把“從A到B的流量走哪條鏈路、故障后切到哪條備選路徑”變成一段可配置、可查詢、可手動干預的策略而不是交給IGP和ECMP去猜。適合正在做數據中心間互聯(lián)規(guī)劃、被多云出口或雙活流量折騰過的網絡架構師和運維工程師閱讀下面按“選型—配置—路由聯(lián)動—避坑—驗證”走一遍。2. 組網規(guī)劃與 policy 選型數據中心間流量為什么不能用默認路由打發(fā)2.1 數據中心間互聯(lián)的三種訴求哪種才需要引入 SRv6 Policy先說清楚這個方向值不值得做。數據中心間流量大概逃不出三種訴求同城雙活要求時延可預期兩條物理鏈路哪怕差 0.5ms數據庫同步都能看出差距兩地三中心關心主備切換能不能在秒級完成默認路由只能等IGP收斂收斂時間在故障場景下不可控多云出口則是大量前綴要按業(yè)務打不同的策略路由純靠BGP屬性堆 community 會復雜到沒人敢動。SRv6 Policy 解決的是這三類場景里的同一個痛點路徑不可編程。傳統(tǒng)組網里頭端設備只能看到路由表看不到“這條流量會經過哪幾個節(jié)點”一旦某段鏈路擁塞運維沒有任何手段把它撥到另一條路上。SRv6 Policy 把整條路徑編碼成有序 SID 列表頭端設備顯式地把流量封裝進這條段列表路徑變成了一等公民可以被查、被比較、被手動切換。如果你只維護一個單機房那確實用不上但只要你的建設方案里有第二個機房、第三條專線或者對外提供跨機房帶寬SRv6 Policy 就不是錦上添花而是把流量調度從黑匣子變成可操作對象的關鍵一環(huán)。2.2 從業(yè)務訴求到 policy 形態(tài)把需求翻譯成配置參數在敲任何配置之前我會先逼著自己把業(yè)務訴求翻譯成一張參數清單。這個習慣幫我避過很多返工因為 policy 一旦上線改 endpoint 或 color 往往牽動兩個機房的防火墻策略、BFD 配置和監(jiān)控告警不是改一行配置那么簡單。下表是我在做跨數據中心互聯(lián)方案時常用的設計清單建議在實施方案評審階段就逐行確認。設計項取值示例說明Endpoint對端PE的IPv6地址Policy 要到達的目標節(jié)點通常寫回環(huán)地址Color100把同一條 endpoint 的路徑分組不同業(yè)務用不同 colorCandidate PathPreference 100 / 200候選路徑優(yōu)先級決定哪條 SList 做優(yōu)選路徑SList 數量初始兩條單候選路徑下掛多個段列表承載主備或負載分擔SBFD間隔 100ms乘數 3帶內雙向轉發(fā)檢測快速感知路徑故障Binding SID獨立分配 10001頭端用來封裝和索引 policy 的本地標簽必須全局唯一回切模式手動或自動故障恢復后是否自動回到原最優(yōu)路徑現網建議先手動把這張表填完基本就知道這個方案要做到多細了。比如同城雙活業(yè)務Color 按業(yè)務線劃分每個 Color 下面掛兩條 SList一條走低時延專線一條走備用鏈路SBFD 間隔壓到 100ms故障感知后立刻切到備用 SList兩地三中心則相反候選路徑優(yōu)先級差異拉到 100 以上避免輕微抖動就來回往返。這里特別提醒一點常見做法是讓 Controller 統(tǒng)一計算和下發(fā)病程但很多現網環(huán)境的 Controller 還沒建起來。我一般會選擇先在頭端設備上手工配置 policy把路徑狀態(tài)跑穩(wěn)定之后再決定要不要接 Controller。手工配置的優(yōu)點是每條路徑的含義都清清楚楚排障時不至于對著 Controller 下發(fā)的幾十條 SList 一臉茫然。3. 數據中心間 SRv6 Policy 配置落地單 CP 多 SList 場景如何把兩條初始路徑寫進去3.1 配置骨架policy、endpoint 與候選路徑我在很多機房割接時見過完全具名的配置風格這里先用一段貼近商用設備 CLI 的示例把骨架搭出來。不同廠商的字段名會有些差異但 SRv6 Policy 的模型是一致的照著這份配置能對照到自家設備上。segment-routing ipv6 traffic-engineer policy DC1_TO_DC2 color 100 endpoint 2001:db8:0:100::1 binding-sid 10001 candidate-path preference 100 segment-list SLIST_A segment-list SLIST_B segment-list SLIST_A index 10 sid ipv6 2001:db8:0:100::1 index 20 sid ipv6 2001:db8:0:200::2 segment-list SLIST_B index 10 sid ipv6 2001:db8:0:100::1 index 20 sid ipv6 2001:db8:0:300::2 sbfd enable sbfd remote-discriminator 10001這段配置表示頭端設備建立了一條名叫 DC1_TO_DC2 的 SRv6 Policy本端通過 BGP 或 IGP 學到遠端 2001:db8:0:100::1 的可達性color 100 用來標識“這是一組同城雙活路徑”。binding-sid 10001 是本端設備給這條 policy 的本地索引后續(xù)引流和封裝都靠它。candidate-path preference 100 定義了候選路徑的優(yōu)先級preference 值越大的路徑越優(yōu)先成為活躍路徑現網建議主備路徑之間拉開一定數值差距避免兩條路徑的優(yōu)先級過于接近導致故障恢復時反復橫跳。3.2 單 CP 多 SList 的語義與“初始兩條 SList”的選路策略再看候選路徑下面掛著的兩條 SListSLIST_A 和 SLIST_B。這就是熱詞場景里反復出現的“單 CP 多 list 場景”——一個候選路徑Candidate Path下掛多個段列表Segment List初始兩條 SList 分別編碼了不同的轉發(fā)路徑。SLIST_A 經過 2001:db8:0:200::2走的是低時延專線SLIST_B 經過 2001:db8:0:300::2走的是帶保護的備用鏈路。兩條 SList 都掛在同一個候選路徑下意味著它們共享同一個 policy、同一個 color通過權重或主備機制決定流量怎么分配。要是把兩條 SList 拆到兩個 candidate-path 里語義就變了它們會變成兩條互相競爭選優(yōu)的獨立候選路徑preference 高的那個當選另一個只在故障時接管。單 CP 多 SList 的好處是當主備切換發(fā)生時policy 自身依然是 Active 狀態(tài)頭端設備不需要重新選候選人只需在內部完成 SList 的重新優(yōu)選切換粒度更細狀態(tài)機也更干凈。初始兩條 SList 的意義就在于此一條為主、一條為輔SBFD 快速探測到 SLIST_A 的路徑斷了之后流量被切到 SLIST_B中間不需要等 IGP 重新收斂。3.3 參數怎么調SBFD、回切與 SID 校驗配置能跑通只是第一步參數不調好割接當晚就容易翻車。我先說 SBFD它決定了設備多快能感知到 SRv6 Policy 的路徑故障。SRv6 Policy 在轉發(fā)路徑斷開時底層鏈路可能還通著尤其是光模塊故障或中間節(jié)點 CPU 異常時普通 BFD 探測不到流量會持續(xù)打到黑洞里。SBFD 是帶內雙向轉發(fā)檢測直接復用 SRv6 數據面做探測開銷更小、發(fā)現故障更快。我通常會先把 SBFD 的探測間隔從默認值壓到 100ms~150ms偵測乘數保持默認 3這樣能在 300ms~450ms 內完成故障發(fā)現和路徑切換。間隔再低會增加頭端和目的節(jié)點的 CPU 壓力在現網沒有特別強的低時延要求時我不建議低于 50ms。然后是回切。故障恢復后如果配置了自動回切SLIST_A 一恢復流量會自動回到原主用路徑。這個行為在雙活場景下會導致一次瞬斷因為回切本身是一次轉發(fā)切換狀態(tài)需要重新同步。我的習慣是第一階段全部關閉自動回切由運維確認 SList 狀態(tài)穩(wěn)定后手動回切等上線三個月、路徑質量全部摸透后再把自動回切打開。調試期間如果覺得流量去向難判斷可以臨時把主用 SList 的 preference 調高或調低觀察流量是否跟著切換驗證完再改回來這是最直接的對照實驗。4. 大型數據中心用 BGP 承載路由時policy 怎么跟路由表聯(lián)動4.1 BGP 在數據中心里的雙重職責Underlay 通互聯(lián)Overlay 通租戶在大型數據中心使用 BGP 進行路由是當前的主流形態(tài)但它承擔的職責要拆成兩層看。Underlay 層用 iBGP/eBGP 建立設備間的 IPv6 可達性把每個節(jié)點的 SRv6 回環(huán)地址和 SID 信息傳播到全網SRv6 Policy 的 endpoint 地址正是通過這層 BGP 學到的。Overlay 層則承載租戶或業(yè)務的真實路由常見做法是 EVPN-VXLAN 疊加在 IPv6 Underlay 上或者用 BGP IPv6 前綴路由直接傳遞業(yè)務流量。二者分開的原因是收斂域不同Underlay 的變化要盡快讓全網知道Overlay 的路由量往往大得多混在一張表里會把 Underlay 的收斂速度拖垮。數據中心間 policy 在這個體系里的位置像是給 BGP 學習到的頂層前綴加了一層“路徑偏好”。BGP 路由表只能告訴設備“下一跳是誰”SRv6 Policy 則告訴設備“去這個下一跳要走哪條顯式路徑”。兩者聯(lián)動起來流量才能既選得對路由也走得好路徑。4.2 讓 BGP 發(fā)布 SRv6 相關路由BGP-LS 與 SID 傳播先把 BGP 側的關鍵配置放出來這段配置的意義在于把 SRv6 Policy 需要的路徑信息托底。router bgp 65001 address-family ipv6 network 2001:db8:0:100::1/128 exit-address-family address-family link-state link-state segment-routing ipv6 traffic-engineer advertise dae srv6-policy exit-address-family第一段 address-family ipv6 發(fā)布的是本端設備的 SRv6 回環(huán)地址保證全網 BGP 都能學到對端 PE 的可達性第二段是 BGP-LS 地址族它負責把本端 SRv6 Policy 的 TEATraffic Engineering Attributes信息上送給 Controller 或鄰居設備。這里的邏輯要理解清楚SRv6 Policy 是頭端本地的轉發(fā)狀態(tài)BGP-LS 上報它是為了讓 Controller 能收集全網 policy 狀態(tài)并據此計算跨數據中心的優(yōu)化路徑。如果只是手工配置 policy 不上報 BGP-LSpolicy 也能工作只是少了全網視角的調度能力。4.3 引流與過濾哪些流量走 policy哪些流量必須繞過路由和 policy 都通了最后的問題是“流量怎么走進 policy”。常見做法是引流路由把匹配特定下一跳或特定 color 的 BGP 路由顯式綁定到 policy 上。動作一般分兩類一類是按下一跳引流所有去往 endpoint 地址的流量都自動走對應 policy另一類是按業(yè)務前綴引流比如只讓 10.1.0.0/16 這條業(yè)務段的流量走 policy其余流量繼續(xù)查普通路由表。過慮同樣重要語音、視頻會議這類交互性強的流量我會故意繞過 policy讓它們直接走 Underlay 原生路徑避免 SRv6 隧道封裝帶來的額外時延抖動。在大型數據中心用 BGP 進行路由聯(lián)動時最容易被忽略的一個點是把 BGP 下一條與 policy endpoint 做一致性校驗。很多排障現場出現“policy 是 Active 的但業(yè)務流量沒走它”的怪象追下去就是引流條件沒匹配上BGP 路由的下一跳是環(huán)回地址的 IPv4 形式而 policy endpoint 用的是 IPv6 地址兩者對不上流量自然走不進 policy。記住一個口訣先看路由表下一跳再看 policy endpoint最后看引流規(guī)則三者一致流量才會進隧道。5. SRv6 Policy 落地避坑5 個高頻坑的現象、根因與解法5.1 主路徑閃斷后切不回來業(yè)務長時間懸在備路上現象SBFD 檢測到主路徑故障流量成功切到備用 SList。主路徑幾分鐘后恢復policy 狀態(tài)也顯示 Active但流量一直不回切業(yè)務持續(xù)走在次優(yōu)路徑上。原因多半是關閉了自動回切但沒有配置手動回切路徑或者手動回切時目標 SList 的 SBFD 狀態(tài)還沒完全恢復設備判定它不滿足回切條件。另一種可能是主備路徑的 preference 差值沒有拉開設備在閾值邊界反復比較導致回切判斷失敗。解決配置回切前加一條前置校驗確認目標 SList 連續(xù)三個探測周期無丟包再執(zhí)行把主備 preference 差值保持在 50 以上。割接前在維護窗口里實際演練一次“手動關主路徑→觀察切換→恢復主路徑→手動回切”這一步省不掉。5.2 policy 顯示 Active業(yè)務流量卻完全不進隧道現象policy 狀態(tài)正常SBFD 也在 UP 狀態(tài)但抓包看到業(yè)務流量還是裸路由轉發(fā)完全沒有 SRv6 頭封裝。原因引流規(guī)則沒有真正命中業(yè)務前綴或者 BGP 路由的下一跳與 policy endpoint 不匹配。這種問題隱蔽在路由表里光看 policy 狀態(tài)根本發(fā)現不了我把它叫作“黑匣子式陷阱”。解決按三條線排查。先查 BGP 路由表里業(yè)務前綴的下一跳地址確認和 endpoint 一致再查引流策略的匹配順序看是否有更靠前的 deny 規(guī)則把流量放過了最后在頭端設備上用 packet-tracer 模擬一條業(yè)務報文看它實際匹配到的是 policy 還是普通路由。5.3 單 CP 多 SList 場景下第二條 SList 永遠只在配置里“存在”現象單候選路徑下配置了兩條 SListSLIST_A 和 SLIST_B 都寫在配置里但設備一直只用 SLIST_A 轉發(fā)SLIST_B 連 SBFD 都不建立。原因單 CP 多 SList 的語義不等于裸的負載分擔。如果兩條 SList 沒有配置 weights 或 loadshare 參數設備默認只選擇 preference 最高的那條 SList 作為活躍路徑另一條只在活躍路徑故障后才啟用平時完全是冷備狀態(tài)。解決想讓兩條 SList 同時承載流量需要為每條 SList 配置轉發(fā)權重比如權重 1:1 就是均分。想讓一條為主、一條為輔則不配權重保持現在的冷備邏輯。設計階段把這個語義定清楚別等到流量分布和預期不符才開始猜。5.4 新增一條 SList 導致全網 policy 抖動現象在某個數據中心間 policy 里新增了一條 SList結果不只是這條 policy相鄰機房的幾條 policy 也相繼報錯控制平面日志里全是 SID 異常告警。原因SRv6 的 Locator 和 SID 在規(guī)劃時沒有嚴格區(qū)分新加的 SList 里用了和其他 policy 重疊的 Binding SID 或節(jié)點 SID頭端設備索引 policy 時發(fā)生了沖突。解決給每個數據中心規(guī)劃獨立的 SRv6 Locator 段Binding SID 使用專門保留的區(qū)間在新增 SList 前用命令查一下目標 SID 已經被哪些 policy 占用。這個坑在多個 controller 同時下發(fā)時最常出現人工配置時反而容易注意到。5.5 Underlay ECMP 與 Policy 疊加時延抖動呈鋸齒狀現象業(yè)務流量明明走了 policy但時延曲線一抖一抖的沒有規(guī)律像是在兩條鏈路之間隨機跳。網絡團隊查了兩天最后發(fā)現 Underlay 的等價多路徑一直開著。原因Policy 顯式指定了一條 SList但這條 SList 里的某些節(jié)點之間仍存在 ECMP 等價路徑流量在隧道里被 ECMP 二次打散導致同一條業(yè)務流的兩個報文可能走不同物理路徑時延當然只能跳動。解決兩個方向。要么把 policy 的 SList 寫得更深把每一跳都改成顯式 SID徹底掉 ECMP 的陰影要么把該段鏈路的 ECMP 收斂為單路徑。一般我會傾向后者因為顯式逐跳 SID 會吃不少 SID 資源。判斷標準很簡單抖動段的物理路徑是否只有兩條如果是直接收斂 ECMP 見效最快。6. 割接前把結論一條條驗證進去查路徑、看 BFD、再回切6.1 三張命令表把狀態(tài)釘死進入維護窗口前我習慣先做一輪靜態(tài)體檢。以下三條命令對應三張表policy 總表看路徑狀態(tài)BFD 表看故障探測流量統(tǒng)計表看實際轉發(fā)情況。display segment-routing ipv6 traffic-engineer policy name DC1_TO_DC2 display srv6-policy sbfd brief display segment-routing ipv6 traffic-engineer statistics第一條看 policy 是否 Active、當前活躍的 SList 是哪條第二條看 SBFD 的探測間隔和狀態(tài)間隔在不在預設值第三條看走 policy 的報文計數是否持續(xù)增長。這三張表要連續(xù)觀察十分鐘確認計數單調增長而不是原地抖動。6.2 割接驗證步驟手動故障注入與回切拿到穩(wěn)定基線后再做一次故障注入演練。第一輪手工把主用 SList 的 preference 調低觀察流量是否在幾個探測周期內切到備用 SList統(tǒng)計切換耗時第二輪恢復主用 SList 的 preference確認回切正常第三輪模擬中間節(jié)點宕機觀察 SBFD 在指定間隔內是否完成故障上報。這套流程做完policy 的可靠性才算真正立在數據上而不是立在“配置看著沒什么問題”的直覺上?；厍袆幼魅绻鞘謩拥奈乙话銜鸦厍忻顚懺谶\維腳本里而不是現切現場敲敲錯一個字段在割接窗口里沒有任何后悔藥。SRv6 Policy 在數據中心間的建設方案里不是銀彈它解決的是路徑可控問題解決不了帶寬不足和鏈路質量問題。我踩過的教訓是方案里給 policy 預留的狀態(tài)監(jiān)控點位越多上線后半夜的電話就越少。希望幫到你。本文還有配套的精品資源點擊獲取 SRv6 Policy 數據中心跨域流量調度：從配置到落地避坑
簡介面向數據中心規(guī)劃、建設與運維人員的技術方案文檔聚焦傳統(tǒng)架構擴展性差、維護成本高、資源利用率低等痛點提出以整合能力、虛擬化能力、自動化能力和綠色節(jié)能為核心的建設框架。內容從網絡架構切入介紹一體化交換、無丟棄以太網、性能支撐、網絡服務虛擬化與服務器虛擬化等關鍵技術并結合指揮學院場景給出目錄式落地參考便于讀者對照理解設計目標如何轉化為實際部署。資源內含1個doc文檔壓縮包約2.68MB目錄按總述、技術實現等章節(jié)編排結構清晰從需求梳理到技術選型均有展開可直接用于數據中心方案設計、課程設計或項目投標的參考模板。目前已有47人學習下載適合需要快速搭建方案框架并了解新一代數據中心技術選型的工程與教學人員。1. 數據中心建設方案為什么先把寶押在 SRv6 Policy 上一份數據中心建設方案寫到網絡部分最容易變成機房平面圖和設備清單但真正決定兩年后運維體驗的往往是數據中心之間那幾十條跨機房路徑怎么被管住。我在IDC和政企DCI項目里反復遇到同一個現象Underlay路由學得通業(yè)務卻“玄學”地繞路、丟包、抖動查到最后都是策略粒度不夠流量被默認路由帶到了不想走的鏈路上。這篇筆記圍繞一個核心結論展開數據中心的跨域流量調度需要顯式路徑能力而用 SRv6 Policy 做數據中心間 policy 是目前最值得投入的方案。它把“從A到B的流量走哪條鏈路、故障后切到哪條備選路徑”變成一段可配置、可查詢、可手動干預的策略而不是交給IGP和ECMP去猜。適合正在做數據中心間互聯(lián)規(guī)劃、被多云出口或雙活流量折騰過的網絡架構師和運維工程師閱讀下面按“選型—配置—路由聯(lián)動—避坑—驗證”走一遍。2. 組網規(guī)劃與 policy 選型數據中心間流量為什么不能用默認路由打發(fā)2.1 數據中心間互聯(lián)的三種訴求哪種才需要引入 SRv6 Policy先說清楚這個方向值不值得做。數據中心間流量大概逃不出三種訴求同城雙活要求時延可預期兩條物理鏈路哪怕差 0.5ms數據庫同步都能看出差距兩地三中心關心主備切換能不能在秒級完成默認路由只能等IGP收斂收斂時間在故障場景下不可控多云出口則是大量前綴要按業(yè)務打不同的策略路由純靠BGP屬性堆 community 會復雜到沒人敢動。SRv6 Policy 解決的是這三類場景里的同一個痛點路徑不可編程。傳統(tǒng)組網里頭端設備只能看到路由表看不到“這條流量會經過哪幾個節(jié)點”一旦某段鏈路擁塞運維沒有任何手段把它撥到另一條路上。SRv6 Policy 把整條路徑編碼成有序 SID 列表頭端設備顯式地把流量封裝進這條段列表路徑變成了一等公民可以被查、被比較、被手動切換。如果你只維護一個單機房那確實用不上但只要你的建設方案里有第二個機房、第三條專線或者對外提供跨機房帶寬SRv6 Policy 就不是錦上添花而是把流量調度從黑匣子變成可操作對象的關鍵一環(huán)。2.2 從業(yè)務訴求到 policy 形態(tài)把需求翻譯成配置參數在敲任何配置之前我會先逼著自己把業(yè)務訴求翻譯成一張參數清單。這個習慣幫我避過很多返工因為 policy 一旦上線改 endpoint 或 color 往往牽動兩個機房的防火墻策略、BFD 配置和監(jiān)控告警不是改一行配置那么簡單。下表是我在做跨數據中心互聯(lián)方案時常用的設計清單建議在實施方案評審階段就逐行確認。設計項取值示例說明Endpoint對端PE的IPv6地址Policy 要到達的目標節(jié)點通常寫回環(huán)地址Color100把同一條 endpoint 的路徑分組不同業(yè)務用不同 colorCandidate PathPreference 100 / 200候選路徑優(yōu)先級決定哪條 SList 做優(yōu)選路徑SList 數量初始兩條單候選路徑下掛多個段列表承載主備或負載分擔SBFD間隔 100ms乘數 3帶內雙向轉發(fā)檢測快速感知路徑故障Binding SID獨立分配 10001頭端用來封裝和索引 policy 的本地標簽必須全局唯一回切模式手動或自動故障恢復后是否自動回到原最優(yōu)路徑現網建議先手動把這張表填完基本就知道這個方案要做到多細了。比如同城雙活業(yè)務Color 按業(yè)務線劃分每個 Color 下面掛兩條 SList一條走低時延專線一條走備用鏈路SBFD 間隔壓到 100ms故障感知后立刻切到備用 SList兩地三中心則相反候選路徑優(yōu)先級差異拉到 100 以上避免輕微抖動就來回往返。這里特別提醒一點常見做法是讓 Controller 統(tǒng)一計算和下發(fā)病程但很多現網環(huán)境的 Controller 還沒建起來。我一般會選擇先在頭端設備上手工配置 policy把路徑狀態(tài)跑穩(wěn)定之后再決定要不要接 Controller。手工配置的優(yōu)點是每條路徑的含義都清清楚楚排障時不至于對著 Controller 下發(fā)的幾十條 SList 一臉茫然。3. 數據中心間 SRv6 Policy 配置落地單 CP 多 SList 場景如何把兩條初始路徑寫進去3.1 配置骨架policy、endpoint 與候選路徑我在很多機房割接時見過完全具名的配置風格這里先用一段貼近商用設備 CLI 的示例把骨架搭出來。不同廠商的字段名會有些差異但 SRv6 Policy 的模型是一致的照著這份配置能對照到自家設備上。segment-routing ipv6 traffic-engineer policy DC1_TO_DC2 color 100 endpoint 2001:db8:0:100::1 binding-sid 10001 candidate-path preference 100 segment-list SLIST_A segment-list SLIST_B segment-list SLIST_A index 10 sid ipv6 2001:db8:0:100::1 index 20 sid ipv6 2001:db8:0:200::2 segment-list SLIST_B index 10 sid ipv6 2001:db8:0:100::1 index 20 sid ipv6 2001:db8:0:300::2 sbfd enable sbfd remote-discriminator 10001這段配置表示頭端設備建立了一條名叫 DC1_TO_DC2 的 SRv6 Policy本端通過 BGP 或 IGP 學到遠端 2001:db8:0:100::1 的可達性color 100 用來標識“這是一組同城雙活路徑”。binding-sid 10001 是本端設備給這條 policy 的本地索引后續(xù)引流和封裝都靠它。candidate-path preference 100 定義了候選路徑的優(yōu)先級preference 值越大的路徑越優(yōu)先成為活躍路徑現網建議主備路徑之間拉開一定數值差距避免兩條路徑的優(yōu)先級過于接近導致故障恢復時反復橫跳。3.2 單 CP 多 SList 的語義與“初始兩條 SList”的選路策略再看候選路徑下面掛著的兩條 SListSLIST_A 和 SLIST_B。這就是熱詞場景里反復出現的“單 CP 多 list 場景”——一個候選路徑Candidate Path下掛多個段列表Segment List初始兩條 SList 分別編碼了不同的轉發(fā)路徑。SLIST_A 經過 2001:db8:0:200::2走的是低時延專線SLIST_B 經過 2001:db8:0:300::2走的是帶保護的備用鏈路。兩條 SList 都掛在同一個候選路徑下意味著它們共享同一個 policy、同一個 color通過權重或主備機制決定流量怎么分配。要是把兩條 SList 拆到兩個 candidate-path 里語義就變了它們會變成兩條互相競爭選優(yōu)的獨立候選路徑preference 高的那個當選另一個只在故障時接管。單 CP 多 SList 的好處是當主備切換發(fā)生時policy 自身依然是 Active 狀態(tài)頭端設備不需要重新選候選人只需在內部完成 SList 的重新優(yōu)選切換粒度更細狀態(tài)機也更干凈。初始兩條 SList 的意義就在于此一條為主、一條為輔SBFD 快速探測到 SLIST_A 的路徑斷了之后流量被切到 SLIST_B中間不需要等 IGP 重新收斂。3.3 參數怎么調SBFD、回切與 SID 校驗配置能跑通只是第一步參數不調好割接當晚就容易翻車。我先說 SBFD它決定了設備多快能感知到 SRv6 Policy 的路徑故障。SRv6 Policy 在轉發(fā)路徑斷開時底層鏈路可能還通著尤其是光模塊故障或中間節(jié)點 CPU 異常時普通 BFD 探測不到流量會持續(xù)打到黑洞里。SBFD 是帶內雙向轉發(fā)檢測直接復用 SRv6 數據面做探測開銷更小、發(fā)現故障更快。我通常會先把 SBFD 的探測間隔從默認值壓到 100ms~150ms偵測乘數保持默認 3這樣能在 300ms~450ms 內完成故障發(fā)現和路徑切換。間隔再低會增加頭端和目的節(jié)點的 CPU 壓力在現網沒有特別強的低時延要求時我不建議低于 50ms。然后是回切。故障恢復后如果配置了自動回切SLIST_A 一恢復流量會自動回到原主用路徑。這個行為在雙活場景下會導致一次瞬斷因為回切本身是一次轉發(fā)切換狀態(tài)需要重新同步。我的習慣是第一階段全部關閉自動回切由運維確認 SList 狀態(tài)穩(wěn)定后手動回切等上線三個月、路徑質量全部摸透后再把自動回切打開。調試期間如果覺得流量去向難判斷可以臨時把主用 SList 的 preference 調高或調低觀察流量是否跟著切換驗證完再改回來這是最直接的對照實驗。4. 大型數據中心用 BGP 承載路由時policy 怎么跟路由表聯(lián)動4.1 BGP 在數據中心里的雙重職責Underlay 通互聯(lián)Overlay 通租戶在大型數據中心使用 BGP 進行路由是當前的主流形態(tài)但它承擔的職責要拆成兩層看。Underlay 層用 iBGP/eBGP 建立設備間的 IPv6 可達性把每個節(jié)點的 SRv6 回環(huán)地址和 SID 信息傳播到全網SRv6 Policy 的 endpoint 地址正是通過這層 BGP 學到的。Overlay 層則承載租戶或業(yè)務的真實路由常見做法是 EVPN-VXLAN 疊加在 IPv6 Underlay 上或者用 BGP IPv6 前綴路由直接傳遞業(yè)務流量。二者分開的原因是收斂域不同Underlay 的變化要盡快讓全網知道Overlay 的路由量往往大得多混在一張表里會把 Underlay 的收斂速度拖垮。數據中心間 policy 在這個體系里的位置像是給 BGP 學習到的頂層前綴加了一層“路徑偏好”。BGP 路由表只能告訴設備“下一跳是誰”SRv6 Policy 則告訴設備“去這個下一跳要走哪條顯式路徑”。兩者聯(lián)動起來流量才能既選得對路由也走得好路徑。4.2 讓 BGP 發(fā)布 SRv6 相關路由BGP-LS 與 SID 傳播先把 BGP 側的關鍵配置放出來這段配置的意義在于把 SRv6 Policy 需要的路徑信息托底。router bgp 65001 address-family ipv6 network 2001:db8:0:100::1/128 exit-address-family address-family link-state link-state segment-routing ipv6 traffic-engineer advertise dae srv6-policy exit-address-family第一段 address-family ipv6 發(fā)布的是本端設備的 SRv6 回環(huán)地址保證全網 BGP 都能學到對端 PE 的可達性第二段是 BGP-LS 地址族它負責把本端 SRv6 Policy 的 TEATraffic Engineering Attributes信息上送給 Controller 或鄰居設備。這里的邏輯要理解清楚SRv6 Policy 是頭端本地的轉發(fā)狀態(tài)BGP-LS 上報它是為了讓 Controller 能收集全網 policy 狀態(tài)并據此計算跨數據中心的優(yōu)化路徑。如果只是手工配置 policy 不上報 BGP-LSpolicy 也能工作只是少了全網視角的調度能力。4.3 引流與過濾哪些流量走 policy哪些流量必須繞過路由和 policy 都通了最后的問題是“流量怎么走進 policy”。常見做法是引流路由把匹配特定下一跳或特定 color 的 BGP 路由顯式綁定到 policy 上。動作一般分兩類一類是按下一跳引流所有去往 endpoint 地址的流量都自動走對應 policy另一類是按業(yè)務前綴引流比如只讓 10.1.0.0/16 這條業(yè)務段的流量走 policy其余流量繼續(xù)查普通路由表。過慮同樣重要語音、視頻會議這類交互性強的流量我會故意繞過 policy讓它們直接走 Underlay 原生路徑避免 SRv6 隧道封裝帶來的額外時延抖動。在大型數據中心用 BGP 進行路由聯(lián)動時最容易被忽略的一個點是把 BGP 下一條與 policy endpoint 做一致性校驗。很多排障現場出現“policy 是 Active 的但業(yè)務流量沒走它”的怪象追下去就是引流條件沒匹配上BGP 路由的下一跳是環(huán)回地址的 IPv4 形式而 policy endpoint 用的是 IPv6 地址兩者對不上流量自然走不進 policy。記住一個口訣先看路由表下一跳再看 policy endpoint最后看引流規(guī)則三者一致流量才會進隧道。5. SRv6 Policy 落地避坑5 個高頻坑的現象、根因與解法5.1 主路徑閃斷后切不回來業(yè)務長時間懸在備路上現象SBFD 檢測到主路徑故障流量成功切到備用 SList。主路徑幾分鐘后恢復policy 狀態(tài)也顯示 Active但流量一直不回切業(yè)務持續(xù)走在次優(yōu)路徑上。原因多半是關閉了自動回切但沒有配置手動回切路徑或者手動回切時目標 SList 的 SBFD 狀態(tài)還沒完全恢復設備判定它不滿足回切條件。另一種可能是主備路徑的 preference 差值沒有拉開設備在閾值邊界反復比較導致回切判斷失敗。解決配置回切前加一條前置校驗確認目標 SList 連續(xù)三個探測周期無丟包再執(zhí)行把主備 preference 差值保持在 50 以上。割接前在維護窗口里實際演練一次“手動關主路徑→觀察切換→恢復主路徑→手動回切”這一步省不掉。5.2 policy 顯示 Active業(yè)務流量卻完全不進隧道現象policy 狀態(tài)正常SBFD 也在 UP 狀態(tài)但抓包看到業(yè)務流量還是裸路由轉發(fā)完全沒有 SRv6 頭封裝。原因引流規(guī)則沒有真正命中業(yè)務前綴或者 BGP 路由的下一跳與 policy endpoint 不匹配。這種問題隱蔽在路由表里光看 policy 狀態(tài)根本發(fā)現不了我把它叫作“黑匣子式陷阱”。解決按三條線排查。先查 BGP 路由表里業(yè)務前綴的下一跳地址確認和 endpoint 一致再查引流策略的匹配順序看是否有更靠前的 deny 規(guī)則把流量放過了最后在頭端設備上用 packet-tracer 模擬一條業(yè)務報文看它實際匹配到的是 policy 還是普通路由。5.3 單 CP 多 SList 場景下第二條 SList 永遠只在配置里“存在”現象單候選路徑下配置了兩條 SListSLIST_A 和 SLIST_B 都寫在配置里但設備一直只用 SLIST_A 轉發(fā)SLIST_B 連 SBFD 都不建立。原因單 CP 多 SList 的語義不等于裸的負載分擔。如果兩條 SList 沒有配置 weights 或 loadshare 參數設備默認只選擇 preference 最高的那條 SList 作為活躍路徑另一條只在活躍路徑故障后才啟用平時完全是冷備狀態(tài)。解決想讓兩條 SList 同時承載流量需要為每條 SList 配置轉發(fā)權重比如權重 1:1 就是均分。想讓一條為主、一條為輔則不配權重保持現在的冷備邏輯。設計階段把這個語義定清楚別等到流量分布和預期不符才開始猜。5.4 新增一條 SList 導致全網 policy 抖動現象在某個數據中心間 policy 里新增了一條 SList結果不只是這條 policy相鄰機房的幾條 policy 也相繼報錯控制平面日志里全是 SID 異常告警。原因SRv6 的 Locator 和 SID 在規(guī)劃時沒有嚴格區(qū)分新加的 SList 里用了和其他 policy 重疊的 Binding SID 或節(jié)點 SID頭端設備索引 policy 時發(fā)生了沖突。解決給每個數據中心規(guī)劃獨立的 SRv6 Locator 段Binding SID 使用專門保留的區(qū)間在新增 SList 前用命令查一下目標 SID 已經被哪些 policy 占用。這個坑在多個 controller 同時下發(fā)時最常出現人工配置時反而容易注意到。5.5 Underlay ECMP 與 Policy 疊加時延抖動呈鋸齒狀現象業(yè)務流量明明走了 policy但時延曲線一抖一抖的沒有規(guī)律像是在兩條鏈路之間隨機跳。網絡團隊查了兩天最后發(fā)現 Underlay 的等價多路徑一直開著。原因Policy 顯式指定了一條 SList但這條 SList 里的某些節(jié)點之間仍存在 ECMP 等價路徑流量在隧道里被 ECMP 二次打散導致同一條業(yè)務流的兩個報文可能走不同物理路徑時延當然只能跳動。解決兩個方向。要么把 policy 的 SList 寫得更深把每一跳都改成顯式 SID徹底掉 ECMP 的陰影要么把該段鏈路的 ECMP 收斂為單路徑。一般我會傾向后者因為顯式逐跳 SID 會吃不少 SID 資源。判斷標準很簡單抖動段的物理路徑是否只有兩條如果是直接收斂 ECMP 見效最快。6. 割接前把結論一條條驗證進去查路徑、看 BFD、再回切6.1 三張命令表把狀態(tài)釘死進入維護窗口前我習慣先做一輪靜態(tài)體檢。以下三條命令對應三張表policy 總表看路徑狀態(tài)BFD 表看故障探測流量統(tǒng)計表看實際轉發(fā)情況。display segment-routing ipv6 traffic-engineer policy name DC1_TO_DC2 display srv6-policy sbfd brief display segment-routing ipv6 traffic-engineer statistics第一條看 policy 是否 Active、當前活躍的 SList 是哪條第二條看 SBFD 的探測間隔和狀態(tài)間隔在不在預設值第三條看走 policy 的報文計數是否持續(xù)增長。這三張表要連續(xù)觀察十分鐘確認計數單調增長而不是原地抖動。6.2 割接驗證步驟手動故障注入與回切拿到穩(wěn)定基線后再做一次故障注入演練。第一輪手工把主用 SList 的 preference 調低觀察流量是否在幾個探測周期內切到備用 SList統(tǒng)計切換耗時第二輪恢復主用 SList 的 preference確認回切正常第三輪模擬中間節(jié)點宕機觀察 SBFD 在指定間隔內是否完成故障上報。這套流程做完policy 的可靠性才算真正立在數據上而不是立在“配置看著沒什么問題”的直覺上?；厍袆幼魅绻鞘謩拥奈乙话銜鸦厍忻顚懺谶\維腳本里而不是現切現場敲敲錯一個字段在割接窗口里沒有任何后悔藥。SRv6 Policy 在數據中心間的建設方案里不是銀彈它解決的是路徑可控問題解決不了帶寬不足和鏈路質量問題。我踩過的教訓是方案里給 policy 預留的狀態(tài)監(jiān)控點位越多上線后半夜的電話就越少。希望幫到你。本文還有配套的精品資源點擊獲取