前兩天一位做網(wǎng)絡(luò)集成的朋友給我發(fā)消息說他在實驗環(huán)境里做了一個OSPF與IS-IS雙點雙向路由引入的驗證結(jié)果發(fā)現(xiàn)OSPF域里所有路由器的外部LSA數(shù)量幾乎翻了一倍。更詭異的是明明只有兩臺ASBR可路由表里同一個前綴卻出現(xiàn)了兩條外部路由一條來自源邊的R1另一條居然來自另一臺ASBR R2——問我是哪里配錯了。這個現(xiàn)象就是雙點雙向路由引入里最經(jīng)典也最容易踩的坑路由回饋。只要拓?fù)淅锍霈F(xiàn)兩個邊界點做雙向引入回饋鏈路幾乎是必然形成的。這篇文章我把成因、復(fù)現(xiàn)、解決方案和落地經(jīng)驗一次講透。無論你是剛學(xué)路由引入、正在準(zhǔn)備網(wǎng)絡(luò)割接還是已經(jīng)在現(xiàn)網(wǎng)里遇到類似詭異現(xiàn)象這篇文章都能幫你省下不少排查時間。1. 先看懂回饋鏈路雙點雙向引入里最不該出現(xiàn)的轉(zhuǎn)發(fā)1.1 回饋是怎么一步步形成的先明確一個概念路由回饋全稱應(yīng)該叫路由被重新引入回源協(xié)議域。它和我們常說的路由環(huán)路有關(guān)聯(lián)但又不完全一樣。環(huán)路是數(shù)據(jù)包轉(zhuǎn)發(fā)層面的死循環(huán)而回饋是路由信息層面的回流污染——回饋嚴(yán)重到一定程度才會演變成真正的環(huán)路和路由震蕩。我用OSPF和IS-IS雙點雙向引入來拆解。假設(shè)R1、R2同時運行兩種協(xié)議且都配置了雙向引入也就是R1把OSPF路由引入IS-IS也把IS-IS路由引入OSPFR2同樣把OSPF路由引入IS-IS也把IS-IS路由引入OSPF現(xiàn)在OSPF域內(nèi)有一條前綴1.1.1.1/32由R1在OSPF里發(fā)布。這條路由在R1上被import-route ospf引入到了IS-IS域通過IS-IS的LSP傳播R2學(xué)到了它。到這里一切正常。問題出在第二步。R2上面配置了把IS-IS路由引入OSPF所以R2在IS-IS域里學(xué)到的這條1.1.1.1/32會被當(dāng)作一條普通的IS-IS外部路由再次注入OSPF域。于是OSPF域里出現(xiàn)了兩條1.1.1.1/32的外部LSA一條是R1最初發(fā)布的另一條的通告者變成了R2。這就是回饋的本質(zhì)路由在引出源協(xié)議域的那一刻原始協(xié)議的身份信息已經(jīng)被格式化了。IS-IS不會關(guān)心這條路由的娘家在OSPF它只知道自己學(xué)到了一條外部路由OSPF再次接收時看到的只是一個由R2新引入的外部路由完全不知道它原本就來自自己域內(nèi)。1.2 為什么雙點和雙向缺一不可我把這個坑拆開講是因為很多初學(xué)者會問我只在一臺路由器上做雙向引入為什么沒有出現(xiàn)回饋單點雙向引入確實不會形成回饋。因為只有一臺ASBR時路由引出去再引回來本質(zhì)上還是同一臺設(shè)備在處理它至少能從接口、鄰居、路由表狀態(tài)上判斷出這條路由是自己剛引出去的不會傻到再引回來一遍形成循環(huán)?；仞佇枰獌蓚€點參與一臺引出去另一臺引回來這樣才能在協(xié)議域之間搭起一條完整的閉環(huán)。雙向則是另一個必要條件。如果只有R1做OSPF到IS-IS的引入、R2做IS-IS到OSPF的引入那么R1引出的OSPF路由會經(jīng)過IS-IS域到達(dá)R2再由R2引回OSPF。這同樣構(gòu)成回饋。也就是說嚴(yán)格來說并不需要每一臺ASBR都做雙向引入只需要存在A引出去、B引回來的交叉路徑。只不過實際工程里為了兩個方向的互通性大家?guī)缀醵际莾膳_設(shè)備同時做雙向引入所以雙點雙向就成了這個問題最典型的發(fā)生場景。1.3 回饋帶來的三種典型危害回饋不是多了一條路由那么簡單它的危害體現(xiàn)在三個層面。第一外部路由表膨脹。OSPF域里每個路由器都會多出一批外部路由表項原本只有幾條外部路由翻倍甚至翻幾倍。設(shè)備內(nèi)存和路由表容量被白白浪費。第二次優(yōu)路徑。回饋路由進(jìn)入OSPF后會參與選路。如果原始那條1.1.1.1/32是OSPF域內(nèi)路由優(yōu)先級是10回饋路由是外部路由優(yōu)先級是150正常情況下大家還是會走原始路徑回饋路由只是躺在那不生效。但如果原始路由本身就是外部引入的Type 5路由優(yōu)先級同樣是150那兩臺ASBR就要比metric了。一旦回饋路徑的metric算出來比原始路徑更小全網(wǎng)的流量就會莫名其妙被引到對端ASBR去繞一個大圈。第三LSA反復(fù)刷新導(dǎo)致全網(wǎng)震蕩。這是最隱蔽也最麻煩的?；仞伮酚稍贠SPF域里傳播后R1會再次學(xué)到那條被R2引回的相同前綴路由。R1的IS-IS域里此時可能還殘留著這條路由的舊LSP信息或者因為路由表變化、cost變化而觸發(fā)重新引入。兩個ASBR之間你來我往OSPF的Type 5 LSA和IS-IS的LSP不斷被刷新每一次刷新都會觸發(fā)SPF重算。輕則CPU飆高重則全網(wǎng)路由震蕩表現(xiàn)就是業(yè)務(wù)間歇性丟包。打個比方你在微信群里發(fā)了一條消息朋友把這條消息截圖轉(zhuǎn)發(fā)到另一個群另一個群的人又把截圖轉(zhuǎn)發(fā)回你的原群你還以為這是別人發(fā)的新內(nèi)容于是又轉(zhuǎn)發(fā)了一次。消息在幾個群之間反復(fù)轉(zhuǎn)發(fā)刷屏最后每個人手機(jī)里都多了好幾份相同內(nèi)容——這就是路由回饋在協(xié)議世界里的即視感。2. 最小化復(fù)現(xiàn)eNSP里的雙ASBR場景搭建與現(xiàn)象確認(rèn)理論講完了一定要動手復(fù)現(xiàn)一次。我建議用eNSP或者GNS3都行重點是親眼看到回饋路由是怎么出現(xiàn)的后面配Route Tag方案時才不會被現(xiàn)象繞暈。2.1 拓?fù)渑cIP規(guī)劃整個拓?fù)洳恍枰獜?fù)雜三臺設(shè)備足夠R1與R2通過GE0/0/0互聯(lián)這條鏈路上同時運行OSPF Area 0和IS-IS Level-2R1的Loopback0地址是1.1.1.1/32R2的Loopback0地址是2.2.2.2/32兩個Loopback都宣告進(jìn)OSPF代表OSPF域內(nèi)的業(yè)務(wù)網(wǎng)段R3是OSPF域內(nèi)的一臺普通路由器接在R1的GE0/0/1上R3上有一個Loopback0地址3.3.3.3/32用來觀察域內(nèi)其他路由器視角設(shè)備接口規(guī)劃如下設(shè)備接口IP地址所屬協(xié)議R1GE0/0/010.0.12.1/24OSPF Area 0 IS-ISR1GE0/0/110.0.13.1/24OSPF Area 0R1Loopback01.1.1.1/32OSPF Area 0R2GE0/0/010.0.12.2/24OSPF Area 0 IS-ISR2Loopback02.2.2.2/32OSPF Area 0R3GE0/0/010.0.13.3/24OSPF Area 0R3Loopback03.3.3.3/32OSPF Area 0這里說句題外話一條物理鏈路上同時跑兩種IGP實驗環(huán)境里沒問題現(xiàn)網(wǎng)里幾乎沒人這么干。生產(chǎn)環(huán)境一般會分開鏈路或者用子接口但復(fù)現(xiàn)回饋問題這樣最省設(shè)備。2.2 核心配置雙向引入是關(guān)鍵R1和R2的OSPF、IS-IS基礎(chǔ)配置就不完整貼了重點看引入部分。R1的關(guān)鍵配置ospf 1 router-id 1.1.1.1 import-route isis 1 area 0.0.0.0 network 1.1.1.1 0.0.0.0 network 10.0.12.1 0.0.0.0 network 10.0.13.1 0.0.0.0 # isis 1 is-level level-2 network-entity 49.0001.0000.0000.0001.00 import-route ospf 1 # interface GigabitEthernet0/0/0 isis enable 1 ip address 10.0.12.1 255.255.255.255R2的配置和R1對稱只是router-id和network-entity不同同時把is-is的網(wǎng)絡(luò)實體改為49.0001.0000.0000.0002.00引入方向也保持一致ospf 1 router-id 2.2.2.2 import-route isis 1 area 0.0.0.0 network 2.2.2.2 0.0.0.0 network 10.0.12.2 0.0.0.0 # isis 1 is-level level-2 network-entity 49.0001.0000.0000.0002.00 import-route ospf 1 # interface GigabitEthernet0/0/0 isis enable 1R3就只跑OSPF什么都不引入。注意實驗時先別急著把引入命令敲上去。先把OSPF、IS-IS鄰居都建立好查看路由表確認(rèn)沒有引入前一切正常然后再添加import-route命令這樣出現(xiàn)的現(xiàn)象才是回饋導(dǎo)致的而不是你基礎(chǔ)配置錯了。2.3 兩個命令看清回饋現(xiàn)象配置完成并等OSPF收斂之后在R3上查看1.1.1.1/32的路由R3display ip routing-table 1.1.1.1 32 Route Destination: 1.1.1.1/32 Known via ospf-1, distance: 10, metric: 1, type: intra area Last update : 00:01:23 ago NextHop : 10.0.13.1 Interface: GigabitEthernet0/0/0 Route Destination: 1.1.1.1/32 Known via ospf-1, distance: 150, metric: 1, type: extern Last update : 00:00:05 ago NextHop : 10.0.12.2 Interface: GigabitEthernet0/0/0看到了嗎同一臺路由器上同一個前綴出現(xiàn)了一條OSPF域內(nèi)路由distance 10下一跳是R1和一條OSPF外部路由distance 150下一跳是R2。這條distance 150的外部路由就是回饋路由。用OSPF LSDB命令看得更清楚R3display ospf lsdb ase Type : External LS ID : 1.1.1.1 AdvRouter : 1.1.1.1 LS age : 20 Metric : 1 Tag : 0 Type : External LS ID : 1.1.1.1 AdvRouter : 2.2.2.2 LS age : 200 Metric : 1 Tag : 0同一個LS ID通告路由器一個寫著1.1.1.1一個寫著2.2.2.2。這就是回饋路由最直觀的指紋前綴沒變通告者卻換了一臺設(shè)備。在這個實驗里因為原始路由是OSPF域內(nèi)路由distance 10優(yōu)先級高于外部路由distance 150所以實際轉(zhuǎn)發(fā)不會出問題。但R3的LSDB和路由表已經(jīng)被污染了。如果原始路由也是外部路由或者IS-IS域里引入了更大的OSPF域回饋路由就會開始干擾正常選路出現(xiàn)次優(yōu)路徑甚至環(huán)路。3. Route Tag標(biāo)記法給引出去的路由貼出生證再接回來解決回饋業(yè)界最標(biāo)準(zhǔn)的做法是Route Tag也就是路由標(biāo)記。思路一句話引出去的路由打上一個約定好的標(biāo)簽引回來的時候凡是帶這個標(biāo)簽的一律拒絕。3.1 標(biāo)記法的核心流程還是用剛才的實驗拓?fù)湮叶x回饋標(biāo)簽值為100兩臺設(shè)備上的處理邏輯完全對稱R1在把OSPF路由引入IS-IS時給所有引入路由打上Tag 100R2從IS-IS學(xué)到這些路由時路由上帶著Tag 100R2在把IS-IS路由引入OSPF時凡是匹配Tag 100的路由直接拒絕引入R2自己把OSPF引入IS-IS時同樣給路由打上Tag 100R1在把IS-IS路由引入OSPF時同樣拒絕Tag 100的路由這樣整個閉環(huán)就被切斷了R1引出去的路由帶Tag 100到R2那里想引回OSPF時被攔截R2引出去的路由帶Tag 100到R1那里想引回OSPF時也被攔截。而OSPF域內(nèi)那些沒有Tag 100的原始路由仍然可以正常被引入IS-IS兩個協(xié)議域的互通不受影響。這個方案的關(guān)鍵在于對稱。如果R1檢查Tag 100R2引入回OSPF時卻沒打Tag、或者打了別的值那R1的過濾就永遠(yuǎn)匹配不到東西回饋照舊。3.2 華為VRP上的具體配置R1上的配置如下# 打標(biāo)簽的策略所有放行的路由統(tǒng)一打Tag 100 route-policy TAG_100 permit node 10 apply tag 100 # 拒絕回饋的策略Tag 100的路由直接拒絕其余放行 route-policy DENY_TAG_100 deny node 10 if-match tag 100 route-policy DENY_TAG_100 permit node 20 # IS-IS引入OSPF時打Tag 100 isis 1 import-route ospf 1 route-policy TAG_100 # OSPF引入IS-IS時拒絕Tag 100 ospf 1 import-route isis 1 route-policy DENY_TAG_100R2上的配置和R1完全一樣。對你沒看錯兩臺ASBR用的是同一套route-policy這也是運維上推薦的做法所有邊界設(shè)備的Tag規(guī)則保持一致降低理解和維護(hù)成本。配置完成后記得敲一條reset ospf process重置OSPF進(jìn)程或者等LSA老化讓OSPF域重新收斂。再回到R3上看路由表和LSDBR3display ospf lsdb ase Type : External LS ID : 1.1.1.1 AdvRouter : 1.1.1.1 LS age : 15 Metric : 1 Tag : 0現(xiàn)在只剩一條由R1發(fā)布的1.1.1.1/32了R2發(fā)布的那條回饋LSA已經(jīng)消失。R3的路由表里也只剩OSPF域內(nèi)那條distance 10的路由一切恢復(fù)正常。3.3 一個隱蔽的坑Tag會不會在跨協(xié)議時丟失Route Tag方案的理論很干凈但我在真實設(shè)備上踩過一個坑必須提醒你不同協(xié)議對Tag的傳遞行為有細(xì)微差異不能默認(rèn)它一定帶得過去。OSPF的外部LSA里Tag是External Route Tag字段32位標(biāo)準(zhǔn)支持。IS-IS的LSP里也有路由Tag TLV。但問題在于從OSPF引入IS-IS時Tag會不會從OSPF路由原封不動帶進(jìn)IS-IS從IS-IS引入OSPF時IS-IS的Tag又會不會自動填進(jìn)OSPF外部LSA的Tag字段不同廠商、不同軟件版本的行為不完全一樣。華為設(shè)備上實測OSPF和IS-IS之間的Tag傳遞基本是可靠保留的但有些老版本或者跨廠商設(shè)備對接時Tag可能在你沒注意到的環(huán)節(jié)被重置為0。一旦Tag丟了回饋路由就變成了無標(biāo)簽路由你的DENY策略匹配不到回饋直接漏進(jìn)來。穩(wěn)妥的做法是**在每一個引入方向上都顯式處理Tag不要指望上一步打好的Tag能自動帶過來。**比如引入IS-IS到OSPF時除了拒絕Tag 100還可以給所有從IS-IS進(jìn)入OSPF的路由重新打一個內(nèi)部管理Tag比如Tag 200方便后續(xù)運維排查這條路由到底從哪進(jìn)來的。# 更穩(wěn)的寫法拒絕Tag 100的同時給其他路由打上內(nèi)部管理標(biāo)簽 route-policy DENY_TAG_100 deny node 10 if-match tag 100 route-policy DENY_TAG_100 permit node 20 apply tag 200 ospf 1 import-route isis 1 route-policy DENY_TAG_100這樣即使個別路由的Tag傳遞有異常你也可以通過查看最終路由表里的Tag值快速判斷是哪一段丟的。4. 如果不想用Tag前綴過濾與AD優(yōu)先級調(diào)整的適用邊界Route Tag是標(biāo)準(zhǔn)解法但有些場景下你未必能用它。比如設(shè)備版本太老不支持跨協(xié)議Tag傳遞或者你只是臨時止血還沒有時間規(guī)劃Tag方案。這時候有兩類替代手段前綴過濾和AD優(yōu)先級調(diào)整。4.1 前綴過濾治標(biāo)快但維護(hù)成本高思路很簡單直接在引入方向上把那些回饋過來的特定前綴拒掉。# 定義前綴過濾拒絕1.1.1.1/32放行其余 ip ip-prefix FILTER_RETURN index 10 deny 1.1.1.1 32 ip ip-prefix FILTER_RETURN index 20 permit 0.0.0.0 0 less-equal 32 # OSPF引入IS-IS時調(diào)用 ospf 1 import-route isis 1 route-policy FILTER_RETURN這個方案直觀配置量小前綴少的時候非常高效。但它的維護(hù)成本和Tag方案完全是兩回事每新增一個OSPF域內(nèi)網(wǎng)段你都要同步修改所有ASBR上的過濾列表。漏掉一個回饋就在那個網(wǎng)段上重新出現(xiàn)。而且它只是從方向上阻斷回饋路由進(jìn)入OSPF如果IS-IS域里本身有一條合法的同前綴路由比如用戶網(wǎng)絡(luò)規(guī)劃上刻意讓兩邊有重疊前綴這種過濾會連同合法路由一起拒掉。所以我的結(jié)論是前綴過濾只適合解決明確知道回饋前綴且路由表規(guī)模小的臨時場景不適合作為長期運維手段。4.2 AD優(yōu)先級調(diào)整止血可以根除不行AD優(yōu)先級調(diào)整的思路是讓回饋路由即使進(jìn)入了OSPF域優(yōu)先級也低于原始路由永遠(yuǎn)選不上它。在華為設(shè)備上可以這樣調(diào)# 把OSPF外部路由優(yōu)先級從150調(diào)大到200 ospf 1 preference ase 200這樣回饋路由在OSPF域內(nèi)選路時會被原始域內(nèi)路由或者原始的Type 5路由壓住不會成為最優(yōu)路徑。如果原始路由的優(yōu)先級也是150回饋路由進(jìn)來后兩者平級會去比較metric把回饋路由所在的協(xié)議整體調(diào)低至少能保證回饋路由不會翻盤。但你要明白AD調(diào)整解決的是選路結(jié)果解決不了表項污染。LSDB里依然會有回饋產(chǎn)生的Type 5 LSASPF依然要重算路由表里依然躺著一條多余的外部路由。該震蕩還是震蕩該占內(nèi)存還是占內(nèi)存。所以它只適合變更割接期間的臨時止血不能作為最終方案。4.3 組合拳割接場景下的最小干預(yù)流程現(xiàn)實里我處理過的一個割接場景是這樣的交接班時發(fā)現(xiàn)現(xiàn)網(wǎng)已經(jīng)出現(xiàn)了明顯的回饋現(xiàn)象OSPF域內(nèi)LSA刷屏但這時再從頭規(guī)劃Tag方案已經(jīng)來不及了。我當(dāng)時的操作順序是先在兩臺ASBR上同時用前綴過濾把已經(jīng)識別的回饋前綴拒掉先讓LSDB穩(wěn)定下來同時把OSPF ASE優(yōu)先級調(diào)大到200防止個別漏網(wǎng)的回饋路由影響轉(zhuǎn)發(fā)路徑觀察15分鐘確認(rèn)LSA不再增長、路由表穩(wěn)定等第二天變更窗口再把Tag方案完整落上去撤掉臨時的前綴過濾這個臨時方案保穩(wěn)定、正式方案換根因的思路在現(xiàn)網(wǎng)里比一上來就推倒重來要實用得多。5. 方案落地的取舍與幾個容易翻車的細(xì)節(jié)最后把三種方案放一起做個對比再講講實際操作中我踩過的坑。5.1 方案對比方案阻斷效果運維成本適用場景風(fēng)險點Route Tag徹底阻斷回饋鏈路中需全ASBR對稱配置長期穩(wěn)定運行多ASBR復(fù)雜網(wǎng)絡(luò)跨協(xié)議Tag傳遞依賴設(shè)備實現(xiàn)前綴過濾按前綴定向阻斷高新增網(wǎng)段要同步維護(hù)前綴少、短期方案漏配即回饋復(fù)發(fā)AD優(yōu)先級調(diào)整不阻斷僅控制選路低兩條命令臨時止血表項污染和震蕩仍在5.2 版本差異與協(xié)議特性最容易翻車的地方先說設(shè)備版本差異。不同版本的VRProute-policy的匹配行為在細(xì)節(jié)上可能有差異。比如有些版本里if-match tag對引入路由的匹配是只匹配外部路由Tag有些版本會把內(nèi)部路由的Tag也帶進(jìn)來。遇到這種情況最穩(wěn)妥的辦法是先在模擬器里搭一個一模一樣的雙ASBR拓?fù)浒裈ag方案完整跑通再上生產(chǎn)設(shè)備操作。我堅持的原則是涉及路由策略的變更永遠(yuǎn)先在模擬器里驗證一遍絕不直接在生產(chǎn)設(shè)備上試錯。第二是OSPF特殊區(qū)域。如果OSPF域里有NSSA或Stub區(qū)域回饋路由和7類LSA的轉(zhuǎn)換邏輯會疊加一層復(fù)雜度。比如NSSA區(qū)域里ABR會把7類LSA轉(zhuǎn)換成5類LSA這個轉(zhuǎn)換過程中Tag字段的保留行為、區(qū)域間的ADR都和普通Area 0不同。只要拓?fù)淅锍霈F(xiàn)NSSA我建議你把Tag方案仔細(xì)推演一遍重點觀察7轉(zhuǎn)5時Tag是否保留。很多回饋問題的隱藏變種就藏在這種區(qū)域邊界轉(zhuǎn)換里。第三是路由震蕩期間的LSDB基線?；仞伇l(fā)的時候LSA序列號會不停自增你根本看不出正常的LSA長什么樣。我建議在任何涉及雙ASBR引入的變更前先抓一次LSDB和路由表作為基線變更后對比外部LSA數(shù)量是否和基線一致。我在割接規(guī)范里加了一條硬性要求配置完成后間隔5分鐘統(tǒng)計兩次LSDB中ASE數(shù)量兩次結(jié)果必須一致——這能快速暴露隱藏的回饋循環(huán)。5.3 一個值得養(yǎng)成的設(shè)計習(xí)慣說句大實話回饋問題一旦出現(xiàn)排查起來最花時間的往往不是敲命令而是理清路由到底是從哪個方向、以什么身份進(jìn)入另一個協(xié)議域的。所以我后來給自己定了一個規(guī)矩任何雙點雙向引入的拓?fù)鋭邮峙渲们跋犬嬕粡埪酚闪飨驁D。這張圖上必須標(biāo)注清楚有哪些路由前綴需要從OSPF跨到IS-IS有哪些路由前綴需要從IS-IS跨到OSPF每個引入方向使用什么Tag策略打什么Tag、拒什么Tag是否存在不需要跨協(xié)議的路由比如純內(nèi)部管理網(wǎng)段把這張圖畫完Tag方案其實就已經(jīng)設(shè)計好了剩下的配置只是把圖畫內(nèi)容翻譯成route-policy。這張圖同時還是變更評審和排障時的最重要的參考資料?；仞亞栴}看似復(fù)雜捋清楚路由走向之后解決方案往往就是幾行route-policy的事。我最后再分享一個感受回饋問題最麻煩的地方不在于技術(shù)本身而在于它總喜歡在你以為一切正常的時候悄悄出現(xiàn)。外部LSA數(shù)量緩慢增長、OSPF進(jìn)程CPU偶發(fā)跳高、某些業(yè)務(wù)路徑在割接后才暴露問題——這些溫和的表象背后可能都是回饋鏈路在慢慢發(fā)酵。把Tag方案、基線和驗證步驟提前固化到流程里比出了故障再到處翻命令要劃算得多。希望這篇文章能幫你少走這些彎路。