做網(wǎng)絡這行的人大概都有過這樣的時刻一開始整個環(huán)境就一個 OSPF 區(qū)域二十來臺設備跑得好好的配置也簡單network一通宣告完事。等到設備數(shù)量上去、接入層開始頻繁抖動、某臺接入交換機一天重啟三回你就會發(fā)現(xiàn)核心設備的 CPU 和 LSDB 開始不淡定了——一臺邊緣設備接口翻動全網(wǎng)所有設備都要重算一遍 SPF。這時候才會想到要拆 OSPF 多區(qū)域。這篇內容講的就是在 H3C 設備上把單區(qū)域 OSPF 改造成多區(qū)域的具體做法從區(qū)域規(guī)劃的硬性約束、區(qū)域類型怎么挑、匯總和外部路由怎么引到鄰居起不來的時候怎么一步步查。適合已經(jīng)能獨立配通單區(qū)域 OSPF、準備把網(wǎng)絡做分層改造的運維和網(wǎng)絡工程師看也適合在備考或者做實驗環(huán)境練習的人拿來對著敲命令。我不打算復述手冊里那些參數(shù)表重點寫手冊上不會告訴你、但真上手一定會撞上的東西。1. 單區(qū)域 OSPF 撐不住的幾個信號以及多區(qū)域到底封住了什么1.1 一臺邊緣設備抖一下背后的代價比你想的大單區(qū)域 OSPF 最典型的癥狀不是不通而是通但時不時卡一下。我見過一個場景某辦公區(qū)接入層十幾臺小交換機全部塞進區(qū)域 0其中一臺下掛的終端網(wǎng)卡有問題接口反復 up/down。每次狀態(tài)變化這臺交換機都要產生一條新的 Type-1 LSA泛洪到全區(qū)域。所有運行 OSPF 的設備收到后都要把這條 LSA 塞進 LSDB然后重新跑一遍 SPF 計算。二十臺設備跑一遍 SPF 可能也就幾毫秒但如果這個口一分鐘翻十次那就是十輪全量重算核心設備的 CPU 曲線會畫出規(guī)律的尖峰。更麻煩的是這種抖動帶來的路由震蕩會沿著鏈路傳導某些對時延敏感的語音或者視頻流就會出現(xiàn)斷續(xù)。多區(qū)域解決的第一個問題就是這個把不穩(wěn)定的部分關進小籠子里。接入層放進區(qū)域 1接入層的鏈路抖動產生的 Type-1 LSA 只在區(qū)域 1 內泛洪區(qū)域 1 的 ABR 只會在必要的時候、用匯總后的 Type-3 LSA 通知區(qū)域 0。區(qū)域 0 里的核心設備完全感知不到那臺小交換機在抽風SPF 也不用重算。這就是多區(qū)域最本質的價值——不是配置看起來更規(guī)范而是縮小故障域和計算域。1.2 LSDB 規(guī)模和 SPF 開銷是兩筆賬很多人把多區(qū)域的好處只理解成LSDB 變小其實賬要分兩筆算。LSDB 變小確實直觀單區(qū)域下每臺設備的 LSDB 里都有全網(wǎng)所有路由器的 Type-1、所有廣播網(wǎng)的 Type-2加上外部的 Type-5。拆成多區(qū)域后非骨干區(qū)域的普通設備 LSDB 里只剩本區(qū)域的 Type-1/2加 ABR 注入的 Type-3。這是一個存儲和內存的問題。另一筆賬是 SPF 計算的頻率和范圍。OSPF 的 SPF 是按區(qū)域算的一個區(qū)域內的拓撲變化只觸發(fā)本區(qū)域的 SPF。區(qū)域 0 的拓撲變化確實會影響所有區(qū)域因為 Type-3 要重算但反過來區(qū)域 1 內部的變化對區(qū)域 2 來說是不可見的。如果你的網(wǎng)絡里 80% 的不穩(wěn)定因素來自接入層把接入層劃出區(qū)域 0 之后區(qū)域 0 的 SPF 觸發(fā)頻率可能下降一個數(shù)量級。1.3 泛洪范圍收窄之后收斂反而更好做還有個容易被忽視的點LSA 泛洪是需要帶寬和 CPU 的。單區(qū)域里一條 Type-5 外部路由比如一臺邊界設備引入了一條明細要泛洪給所有設備每臺都要判斷自己是不是 ASBR、要不要重算外部路由。拆成多區(qū)域、再用stub或nssa把不需要外部路由的區(qū)域擋掉之后那些區(qū)域的設備連 Type-5 都收不到自然也不用為外部路由的頻繁變化買單。這在引入路由變化比較頻繁的出口環(huán)境里效果特別明顯。2. 劃分之前必須先嚼碎的三個硬約束2.1 區(qū)域 0 不是擺設它是所有區(qū)域間路由的中轉站OSPF 的區(qū)域間路由有一條鐵律非骨干區(qū)域之間不能直接交換 Type-3 LSA。換句話說區(qū)域 1 的路由要去區(qū)域 2路徑必須是區(qū)域 1 → ABR → 區(qū)域 0 → ABR → 區(qū)域 2中間得在區(qū)域 0 里走一趟。這條規(guī)則剛接觸時會覺得多余實際是為了防止區(qū)域間出現(xiàn)環(huán)路——因為 Type-3 LSA 攜帶的是我到某個網(wǎng)段的距離如果允許區(qū)域間任意互傳距離向量式的傳播就可能繞圈。落地時的具體約束就是一臺 ABR 如果要同時連接區(qū)域 1 和區(qū)域 2它必須至少有一個接口留在區(qū)域 0。如果一臺設備只連了區(qū)域 1 和區(qū)域 2、沒有區(qū)域 0 的接口那它就不是 ABR兩個區(qū)域的路由在它這里根本不會互相導入。我在排查中遇到過好幾次兩個區(qū)域都配了、路由就是不通的情況最后發(fā)現(xiàn)是這臺中間的設備接口全劃進非骨干區(qū)域了區(qū)域 0 是空的。2.2 ABR 的兩個身份和三張表ABR區(qū)域邊界路由器在 OSPF 里是個特殊角色它至少連接兩個區(qū)域且其中一個必須是區(qū)域 0。它的關鍵動作有三個把區(qū)域 1 內的 Type-1/2 拓撲轉換成 Type-3 摘要注入?yún)^(qū)域 0把區(qū)域 0 的 Type-3重新注入?yún)^(qū)域 1如果它自己還是 ASBR引入了外部路由它還要為其他區(qū)域生成 Type-4告訴人家ASBR 在這里。所以 ABR 上同時存在三套東西多個區(qū)域的 LSDB、一張區(qū)域間路由表、一張本地計算出的路由表。查 ABR 的問題時display ospf lsdb要配合區(qū)域參數(shù)一起看display ospf routing看的是它最終選出來的路由兩者對不上往往就是匯總或者區(qū)域類型配錯了。2.3 區(qū)域編號的兩種寫法與命令行上的習慣OSPF 的區(qū)域 ID 可以寫成十進制整數(shù)1也可以寫成點分十進制0.0.0.1設備內部把它當作 32 位無符號數(shù)處理所以area 1和area 0.0.0.1是同一個區(qū)域。區(qū)域 0 同理area 0和area 0.0.0.0等價。我的習慣是統(tǒng)一用十進制原因是敲起來短、看配置文件時不容易和 IP 地址混淆。但如果你的區(qū)域劃分是按地理或者按樓層映射的用點分十進制會更有語義比如area 0.0.10.1對應 10.1 網(wǎng)段的那個片區(qū)。關鍵是整個網(wǎng)絡里保持同一種寫法避免有人寫area 1有人寫area 0.0.0.1雖然設備認但看配置的人容易誤判成兩個區(qū)域。3. 在 H3C 設備上把區(qū)域真正切出來的完整動作3.1 開局三件事router-id、參考帶寬、區(qū)域劃分表動手敲命令之前先把三樣東西定下來能省掉后面一大半返工。第一是 router-id。H3C 設備如果沒手動指定會用 Loopback 接口地址最大的那個作為 router-id沒有 Loopback 就用物理接口里地址最大的。這個自動選擇在設備重啟、接口地址調整后可能變化一旦變化這個設備產生的所有 LSA 都要重新生成鄰居關系也要重建。所以生產環(huán)境一定要手動指定通常用 Loopback0 的地址比如router-id 10.0.0.1而且每臺設備的 router-id 必須全網(wǎng)唯一。第二是參考帶寬。H3C 默認的bandwidth-reference是 100單位 Mbps開銷計算公式是參考值 ÷ 接口帶寬小于 1 的取 1。這意味著千兆口算出來 0.1 取整成 1萬兆口算出來 0.01 也取整成 1最后千兆和萬兆的開銷一模一樣選路完全看不出差異?，F(xiàn)在千兆起步、萬兆普及的環(huán)境里這個默認值必須改。我一般改成bandwidth-reference 100000100G這樣千兆口開銷 100、萬兆口開銷 10層次就出來了system-view ospf 1 router-id 10.0.0.1 bandwidth-reference 100000這里有個細節(jié)bandwidth-reference改了之后已經(jīng)建立的鄰居和已計算的路由不會立刻按新開銷重算因為開銷是隨接口的 LSA 一起泛洪出去的。改完要觸發(fā)一次重新計算穩(wěn)妥的做法是在業(yè)務窗口內把所有設備的參考值一次改齊然后逐臺reset ospf process這個命令會斷鄰居慎用或者干脆規(guī)劃階段就定好別等上線后再動。第三是區(qū)域劃分表。哪幾臺設備做 ABR、每個區(qū)域包含哪些網(wǎng)段、區(qū)域類型是什么、要不要匯總這些在一張紙上寫清楚。OSPF 多區(qū)域最怕邊配邊想。3.2 宣告網(wǎng)段的兩種方式用哪種取決于你的排錯習慣H3C 上把接口納入 OSPF 有兩條路。第一條是進入 OSPF 區(qū)域視圖用network命令宣告網(wǎng)段ospf 1 area 0 network 10.0.0.0 0.0.0.255 network 10.1.1.0 0.0.0.3 quit area 1 network 192.168.10.0 0.0.0.255注意這里的掩碼是反掩碼wildcard mask跟 ACL 的寫法一致。0.0.0.255對應 24 位掩碼0.0.0.3對應 30 位掩碼。這里最容易犯的錯是把正掩碼寫進去比如寫成network 10.0.0.0 255.255.255.0設備不報錯但匹配結果完全不對——它會按反掩碼解釋成前 8 位固定、后 24 位任意結果可能把一堆不該進來的接口卷進去或者一個都沒匹配上。判斷標準很簡單配完立刻display ospf interface看一眼該在里面的是不是都在。第二條是在接口視圖下直接掛區(qū)域interface GigabitEthernet1/0/1 port link-mode route ip address 10.1.1.1 255.255.255.252 ospf 1 area 0我個人更傾向第二種原因有兩個。一是所見即所得接口屬于哪個區(qū)域一眼就能看出來不用在 OSPF 視圖和接口視圖之間來回對照。二是不會因為反掩碼寫錯而悄悄漏掉接口。缺點是大批量接口時敲得比較啰嗦而且如果接口地址變了區(qū)域歸屬不會自動跟著變——不過這一點兩種方式都一樣。提示兩種方式不要混用。一旦用network宣告了某個網(wǎng)段又在接口下掛ospf area排查時的判斷依據(jù)會變得很混亂。3.3 silent-interface 和 Loopback 的組合用法多區(qū)域環(huán)境里有一個非常實用的命令silent-interface。它讓某個接口的網(wǎng)段照樣被宣告進 OSPF、照樣產生路由但接口上不發(fā)也不收 OSPF 報文。這個命令的典型場景是連接終端的接口和 Loopback 接口。比如你有一臺三層交換機下掛一堆 PC 的 VLAN 接口這些接口根本不需要跑 OSPF但它們的網(wǎng)段需要讓其他設備學到。用silent-interface處理既宣告了網(wǎng)段又避免了在這些接口上無謂地發(fā) Hello 報文——更重要的是避免有人在這類接口上接個什么設備意外建立起鄰居關系。ospf 1 silent-interface Vlan-interface 10 silent-interface Vlan-interface 20 silent-interface LoopBack 0Loopback 一定要靜默因為它是個環(huán)回口本身不接任何東西發(fā) Hello 是純浪費。而且 Loopback 有個額外好處只要設備活著這個接口就永遠是 up 的用它做 router-id 和宣告管理網(wǎng)段最穩(wěn)定。我習慣每臺設備都配一個 Loopback0地址規(guī)劃成統(tǒng)一的10.0.0.x/32靜默宣告進區(qū)域 0。4. 區(qū)域類型怎么挑stub、stub no-summary、NSSA 的取舍4.1 stub 區(qū)域擋掉的是 4 類和 5 類不是所有外部信息stub 區(qū)域的設計意圖很直白這個區(qū)域里的設備不需要知道外部路由的明細只需要一條默認路由指向 ABR 就夠了。配置上ospf 1 area 2 stub配完之后ABR 會做兩件事一是不再把 Type-4 和 Type-5 注入這個區(qū)域二是自動產生一條 Type-3 的默認路由0.0.0.0/0注入進去。注意這個默認路由是 ABR 自動生成的不需要你手動配default-route-advertise這是 stub 區(qū)域的固有行為。這里有個坑stub 區(qū)域內的所有設備都要配stub漏掉一臺就建不起鄰居。原因在 Hello 報文的 Option 字段里stub 區(qū)域的路由器會在 Hello 里打上 E-bit 置 0 的標記兩端不匹配就停在 Init 或者直接不建立。查這個問題時display ospf peer會顯示鄰居狀態(tài)異常但不會直接告訴你區(qū)域類型不匹配得靠display ospf interface看兩邊區(qū)域的 stub 標記。另外一條硬性限制stub 區(qū)域里不能有 ASBR。因為 stub 的語義就是我不收外部路由你在里面再引入外部路由就自相矛盾了。所以如果這個區(qū)域里有設備需要import-route那就只能用 NSSA。stub no-summary更進一步連 Type-3 的區(qū)域間明細也不收了只保留一條默認路由。這種配置一般用在只有終端、沒有任何跨區(qū)域訪問需求的末梢區(qū)域比如一個獨立的辦公樓層所有流量都往上走沒有任何需要按目的網(wǎng)段精細選路的場景。好處是這類設備的 LSDB 里只剩本區(qū)域的 Type-1/2 和一條默認路由資源占用壓到最低。缺點是萬一以后這個區(qū)域里新增了一臺服務器需要被別的區(qū)域訪問就得回頭改配置。4.2 NSSA既要擋住外部路由又要往里引外部路由NSSA 解決的是 stub 解決不了的矛盾這個區(qū)域需要引入外部路由比如接了條專線、掛了個出口但又不希望接收其他區(qū)域泛洪過來的大量 Type-5。ospf 1 area 3 nssaNSSA 的行為是阻斷 Type-4 和 Type-5 進入但允許區(qū)域內的 ASBR 產生Type-7 LSANSSA 專屬的外部路由類型。Type-7 只在本區(qū)域泛洪到了 NSSA 的 ABR 那里由 ABR 負責把它轉換成 Type-5 再發(fā)到其他區(qū)域去。這里有個默認行為的坑NSSA 的 ABR 默認不會往區(qū)域里注入默認路由這和 stub 不一樣。如果你希望 NSSA 內的設備能通過默認路由訪問外部需要在 ABR 上顯式配ospf 1 area 3 nssa default-route-advertise還有nssa no-summary效果是連 Type-3 明細也擋掉只發(fā)一條默認路由同時保留 Type-7 的能力。這個在末梢 需要引入少量外部路由的場景里比較合適。幾種區(qū)域類型的對比我整理成一張表配的時候對著看區(qū)域類型阻斷的 LSA允許的 LSA默認路由來源是否允許 ASBR普通區(qū)域無1/2/3/4/5需手動default-route-advertise允許stub4、51/2/3ABR 自動注入 Type-3 默認不允許stub no-summary3、4、51/2ABR 自動注入 Type-3 默認不允許NSSA4、51/2/3/7需配nssa default-route-advertise允許NSSA no-summary3、4、51/2/7需配nssa default-route-advertise允許選型上的經(jīng)驗判斷如果這個區(qū)域的設備只有一條出口往上走、也沒有引入外部路由的需求直接stub如果區(qū)域內確實要引入外部路由用nssa如果區(qū)域里全是終端設備連跨區(qū)域精細選路都不需要再考慮no-summary那兩檔。別一上來就上no-summary把路走窄了后面改起來麻煩。5. 匯總和外部引入多區(qū)域配置里最容易埋雷的兩塊5.1 abr-summary 擋的是明細不是路由本身區(qū)域間匯總的目的是把區(qū)域內的多條明細網(wǎng)段合并成一條 Type-3 發(fā)出去減少區(qū)域 0 和其他區(qū)域的路由表規(guī)模。命令在 ABR 的源區(qū)域視圖下配ospf 1 area 1 abr-summary 192.168.0.0 255.255.0.0這里用的是正掩碼跟network的反掩碼相反這是很多人第一次配會寫錯的地方。配這條命令的前提是ABR 在區(qū)域 1 內確實有 192.168.0.0/16 覆蓋范圍內的明細路由。如果明細不存在匯總不會生成。而且匯總只影響 ABR 向外發(fā)出的 Type-3不影響區(qū)域 1 內部的路由區(qū)域 1 里的設備照樣看到明細——這點經(jīng)常被誤解成匯總之后區(qū)域 1 里也變一條了。還有一個隱蔽的問題匯總之后如果區(qū)域 1 內某條明細網(wǎng)段斷了只要還有其他明細存活這條匯總路由就不會撤銷發(fā)往那個斷掉的網(wǎng)段流量會打到 ABR 上然后被丟棄因為 ABR 上那條明細已經(jīng)沒了。如果這條匯總配了not-advertise情況反過來——匯總網(wǎng)段整個被抑制。這個行為在規(guī)劃匯總范圍的時候要考慮清楚別把匯總范圍劃得比實際網(wǎng)段大太多否則會引入一塊黑洞地址。5.2 asbr-summary 和 import-route 的連招順序外部路由的匯總要用asbr-summary位置在OSPF 視圖下不是區(qū)域視圖ospf 1 import-route direct type 1 asbr-summary 172.16.0.0 255.255.0.0asbr-summary只對本機引入的Type-5/Type-7 路由生效對從別的 ASBR 學來的外部路由不管用。所以它通常緊跟在import-route后面配。import-route后面有幾個參數(shù)值得說。type 1和type 2決定外部路由的開銷計算方式Type-1 是外部開銷 到 ASBR 的內部開銷隨內部路徑變化Type-2 是只看外部開銷內部開銷不計入比較。默認是 Type-2。多條外部路徑并存的時候Type-1 更能反映真實遠近我在多出口環(huán)境里一般用 Type-1只有單一出口的時候用默認的 Type-2 就行省事。另外import-route direct這條命令要特別小心。它會把本機所有直連網(wǎng)段都引入成外部路由包括管理口、互聯(lián)口甚至你不想暴露的網(wǎng)段。穩(wěn)妥的做法是用route-policy過濾route-policy EXPORT permit node 10 if-match ip address prefix-list SERVER_NETS quit ospf 1 import-route direct route-policy EXPORT這樣只有匹配前綴列表的網(wǎng)段才會被引入。別嫌麻煩一次性把策略寫對比后面從路由表里一條條往回刪省事得多。5.3 虛連接不連續(xù)骨干區(qū)域的縫合線以及它的代價現(xiàn)實網(wǎng)絡里經(jīng)常遇到一種情況某個區(qū)域因為歷史原因沒有直連區(qū)域 0或者區(qū)域 0 被割裂成了兩塊。OSPF 的解法是虛連接Virtual Link在兩臺 ABR 之間、穿過一個傳輸區(qū)域建立一條邏輯鏈路ospf 1 area 1 vlink-peer 10.0.0.2在另一端對應的 ABR 上也要配vlink-peer 10.0.0.1兩邊的 router-id 互指。配完之后兩臺設備之間會出現(xiàn)一條邏輯上的區(qū)域 0 鏈路display ospf peer里能看到鄰居狀態(tài)是 Full。虛連接有三條限制必須記住第一傳輸區(qū)域必須是普通區(qū)域不能是 stub 或 NSSA因為虛連接的報文要在里面正常泛洪stub 區(qū)域會擋掉必要的 LSA第二虛連接是依賴底層路由的也就是說傳輸區(qū)域里兩臺設備之間必須有可達路由否則虛連接起不來這就是個先有雞還是先有蛋的問題規(guī)劃時要先確認傳輸區(qū)域內的路由是通的第三虛連接會增加復雜度能靠調整物理連接或者區(qū)域劃分解決的就別用虛連接。我見過一個案例兩臺 ABR 之間隔了一個 stub 區(qū)域非要配虛連接結果鄰居一直卡在Init查了半天才發(fā)現(xiàn)是區(qū)域類型不匹配。這種問題在文檔里寫得清楚但真到現(xiàn)場容易忽略因為你腦子里想的是這兩臺設備之間的物理鏈路是通的啊。6. 鄰居起不來、路由算不對按這個鏈路往下查6.1 display 命令的查看順序比命令本身更重要排查 OSPF 問題最怕一上來就display ospf routing看路由表因為路由表是結果不是原因。我固定的查看順序是這樣的第一步display ospf brief看進程狀態(tài)、router-id、區(qū)域數(shù)量、SPF 調度次數(shù)。這里能快速判斷 OSPF 進程本身是不是正常、router-id 有沒有沖突。第二步display ospf interface看每個接口屬于哪個區(qū)域、網(wǎng)絡類型是什么、cost 是多少、DR/BDR 是誰、Hello 和 Dead 定時器數(shù)值。絕大多數(shù)鄰居起不來的問題在這一步就能定位到——要么接口根本沒進 OSPF要么兩邊區(qū)域號不一致要么定時器不匹配。第三步display ospf peer看鄰居狀態(tài)。加上verbose參數(shù)能看到更多協(xié)商細節(jié)包括鄰居的 router-id、DR/BDR 選舉結果、DD 報文交互情況。第四步display ospf lsdb分區(qū)域看。display ospf lsdb router、display ospf lsdb summary、display ospf lsdb ase分別看 Type-1、Type-3、Type-5。注意 Type-3 要在對應區(qū)域下看因為同一個網(wǎng)段的 Type-3 在不同區(qū)域里內容不一樣。第五步才輪到display ospf routing和display ip routing-table對比 OSPF 算出來的路由和實際進表的路由差異往往說明有更優(yōu)的靜態(tài)路由或者路由策略在干擾。6.2 卡在 Init、Two-way、ExStart 分別說明什么鄰居狀態(tài)機停在不同階段指向的原因完全不同這張表可以直接當排查索引鄰居狀態(tài)常見原因排查動作Down接口未啟用 OSPF、網(wǎng)段未宣告、接口 downdisplay ospf interface確認接口存在Init單向收到 Hello對端沒收到我的檢查單向鏈路、ACL 是否擋了組播 224.0.0.5Two-way雙向通信正常但 DR 選舉還沒完成或雙方都是 DROther等待 40 秒 wait timer檢查 dr-priorityExStartMTU 不一致、router-id 沖突檢查兩端接口 MTUdisplay ospf brief看 router-idExchange/Loading報文丟失、鏈路質量差查接口錯包、重傳計數(shù)Full正常無需處理Two-way這個狀態(tài)特別容易被誤判成故障。在廣播網(wǎng)絡里非 DR/BDR 的路由器之間本來就是 Two-way 狀態(tài)這是正常的——它們之間不需要交換完整的 LSA。判斷標準是只要每臺設備都和 DR、BDR 建立了 Full就是正常的。如果你看到某臺設備和 DR 之間也是 Two-way那才是問題。ExStart卡住最常見的原因是 MTU 不一致。H3C 設備的接口默認不檢查 DD 報文里的 MTU 字段但如果有人開了ospf mtu-enable或者兩端設備來自不同廠商、默認行為不同就會出現(xiàn)一方認為 MTU 不匹配、拒絕進入 Exchange 的情況。處理方式是統(tǒng)一兩端 MTU或者在接口下undo ospf mtu-enable關掉檢查。我個人傾向統(tǒng)一 MTU關檢查只是掩蓋問題真到大包傳輸?shù)臅r候還是會炸。6.3 匯總不生效和 cost 一樣的兩個隱蔽坑第一個坑abr-summary配了但display ospf lsdb summary里看不到匯總路由。原因通常有三個——ABR 在這個區(qū)域里沒有對應的明細路由匯總掩碼寫成了反掩碼或者這條命令配在了錯誤的區(qū)域視圖下應該配在產生明細的那個區(qū)域而不是接收匯總的區(qū)域。我吃過一次虧把abr-summary配在了區(qū)域 0 里結果區(qū)域 0 的 Type-3 是收到了一堆明細但是匯總壓根沒生成。第二個坑多區(qū)域配完之后路徑選擇跟預期不一樣明明有萬兆鏈路卻走了千兆。這基本可以斷定是bandwidth-reference沒改。默認值 100 的情況下千兆和萬兆的 cost 都是 1OSPF 只能按其他因素比如 router-id 大小、接口順序來打破平局結果就變成了看運氣選路。改參考帶寬的時候注意這個值要在全網(wǎng)所有 OSPF 設備上保持一致否則各設備算出來的 cost 基準不同選路會變得完全不可預測。7. 配完一套多區(qū)域我會逐項核對的清單每次做完多區(qū)域改造我都習慣按固定順序過一遍核對清單這套動作能把 90% 的低級錯誤擋在上線之前。先看區(qū)域覆蓋是否完整。display ospf interface逐臺設備過一遍確認每個應該跑 OSPF 的接口都在、區(qū)域號正確、沒有多余接口混進來。特別注意互聯(lián)鏈路兩個 ABR 之間的互聯(lián)口如果被漏掉區(qū)域 0 就斷了一截而這種現(xiàn)象在路由表上不一定立刻看得出來。再看鄰居關系是否全 Full。display ospf peer輸出的每一行都要確認狀態(tài)是 Full而且要確認 DR/BDR 的分布符合規(guī)劃。如果某個廣播網(wǎng)段里出現(xiàn)了預期之外的 DR多半是dr-priority忘了配或者配置之后沒重啟 OSPF 進程導致沒生效——優(yōu)先級修改不會立刻觸發(fā)重新選舉。然后看 LSDB 里的 LSA 數(shù)量。display ospf lsdb分區(qū)域統(tǒng)計一下如果某個區(qū)域的 Type-3 數(shù)量遠超預期說明匯總沒配或者配錯位置了如果 stub 區(qū)域里出現(xiàn)了 Type-5那一定是有人在某臺設備上漏配了stub。再看路由表里的路由來源。display ip routing-table protocol ospf過濾一下重點看有沒有預期之外的外部路由、有沒有該匯總沒匯總的明細。這里還能發(fā)現(xiàn)一個常見問題默認路由的出處不對。比如 stub 區(qū)域里應該只有 ABR 注入的一條默認路由如果出現(xiàn)了兩條甚至更多就要查是不是有人手動配了default-route-advertise。最后看 SPF 調度次數(shù)。display ospf brief里的 SPF 計數(shù)隔一段時間看兩次如果數(shù)值在穩(wěn)定期還在快速上漲說明網(wǎng)絡里有東西在頻繁觸發(fā)拓撲變化得回去查是哪個接口在抖。注意整套改造過程中reset ospf process是最后手段。它會清空所有鄰居重建過程可能持續(xù)幾十秒到幾分鐘業(yè)務會中斷。能用undo加redo解決的配置調整就別動這個命令。最后分享一個我自己的小習慣多區(qū)域改造完成后我會把每臺設備的 OSPF 相關配置用display current-configuration configuration ospf導出來和改造前做一次 diff。差異里經(jīng)常能發(fā)現(xiàn)一些順手多配了一條的東西比如某個接口被誤掛進了區(qū)域、某條匯總掩碼少寫了一位。配置文件本身的差異比路由表更容易暴露這類問題因為路由表只反映結果配置才反映意圖。