初次調試路由的驚險

驚險一：遠端路由器無法連接

A地市局報告說，下面所有的縣局網絡無法訪問省局的“省政務一體化平臺”，而地市局訪問此平臺沒有問題。地市局網絡結構如圖1所示。該應用系統平臺部署在政務外網，IP地址59.225.200.123，在地市局的路由器AR3260上已配置了相關的靜態路由，下一跳為政務外網防火墻的接口地址，但在縣局PC端用命令tracert跟蹤路由居然走到省局去了，所以A地市局IT負責人認為問題出在省局。

圖1 網絡拓撲結構

遠程登錄到A地市局的路由器查看路由表，到政務一體化平臺的路由有2條，一條靜態路由到59.0.0.0/8的下一跳為地市局政務外網防火墻的接口地址，優先級默認為60。另一條是O_ASE路由到59.225.200.0/24的下一跳為省局IDC機房路由器接口地址，優先級為150。正是后面一條路由，導致A市的縣局網絡訪問走到了省局。當時就沒弄明白，為什么優先級高的靜態路由沒有生效（按路由優先級的數字越低其優先級越高），反而在tracert中路由匹配了優先級低的O_ASE路由條目。而測試確認，另一條靜態路由59.223.0.0/24段到政務外網防火墻是正常的。

再分析A地市局網絡正常訪問政務外網的原因，是因為直接走的市局核心交換機到政務外網防火墻，完全沒有經過市局邊界路由器。所轄縣局訪問線路必須經過該路由器，而路由器上莫名其妙串出一條O_ASE路由將訪問政務外網引到了省局網絡。

剛好前一段時間在華為網站上看到一個在線視頻，介紹了OSPF路由過濾的問題，心想把這條O_ASE路由過濾掉不就解決問題了嗎？有了這個解決問題的思路，但具體操作卻想不起來了，網上搜索關鍵字“OSPF路由過濾”，在H3C的論壇里找到一個貼子，華為和H3C（華三）網絡設備的配置命令基本類似，所以就拿來一用。

在AR3260上輸入sys進入配置模式，ip ip-prefix test1 index 10 deny 59.225.200.0 24 ；輸入ospf 1進入ospf進程，filterpolicy ip-prefix test1 import，配置命令輸入后回車，悲劇了，通過secureCRT連接到A地市局路由器瞬間斷開。聯系對方IT人員后，得知此時市局無法訪問省局的服務器。由于沒有保存配置，可重啟路由器解決該問題。由于此路由器并不在我的管理范圍內，怕重啟引出更多問題而放棄該辦法。

出現緊急情況向主管報告，他讓我通過在省局IDC路由器上登錄A地市局路由器的直連接口IP，看能否登錄。由于地市局路由器只是開啟SSH服務，而在路由器上使用SSH協議登錄遠程路由器還不知道怎么操作，只得主管親自緊急處理。他查閱華為電子手冊，很快找到所需的配置命令，ssh client first-time enable；stelnet 172.27.254.98回車，輸入用戶名密碼完成登錄。再進入OSPF進程，undo filter-policy ip-prefix test1 import，完美解除緊急狀況，此刻又能正常遠程連接A市局路由器了，對方到省局的網絡也恢復正常。

梳理一下通過路由器的SSH客戶端登錄遠程路由器的配置原理，ssh client first-time enable是因為華為交換機默認情況，SSH客戶端首次認證功能是關閉的。使能SSH客戶端首次認證功能的目的，是當STelnet客戶端第一次登錄SSH服務器時不對SSH服務器的RSA公鑰進行有效性檢查，因為此時STelnet客戶端還沒有保存SSH服務器的RSA公鑰。如果沒有使能SSH客戶端首次認證功能，則STelnet客戶端第一次登錄SSH服務器時，由于對SSH服務器的RSA公鑰有效性檢查失敗，導致無法登錄遠程路由器。

最后，還得解決A地市局訪問“政務一體化”平臺的問題。主管看了遠端路由器上的路由配置，給出立桿見影還不費勁的解決辦法。在AR3260上加一條主機的靜態路由，配置命令是ip routestatic 59.225.200.123 32 10.10.10.101，再和對方IT確認，縣局都能正常訪問“政務一體化”平臺了。可見，實際工作中不僅要對網絡知識能夠透徹理解，還要在實踐中不斷積累經驗，方能快速有效地解決問題。

驚險二：配置不當引發路由環路

B地市局的縣局因類似的工作需要訪問“省政務一體化平臺”，故障現象和A地市局情況一樣，地市局PC都能正常訪問，而所有縣局PC都無法訪問。由于管理人員技術欠缺的個人因素，加之歷史上曾經由省局直接管理過地市局路由器的原因，對方強烈要求省局解決此問題，而且對方還無法提供B市局的網絡拓撲圖。

有了前面A地市局路由問題的解決經驗，心想摸著石頭過河也能輕松搞定。雖然對方沒有給出網絡拓撲，猜想同一機關系統的網絡架構也差不多。從secureCRT登錄B地市局的路由器，和對方溝通了解到，政務外網防火墻接口地址 為10.10.10.109，添 加一條靜態路由，當時想如果還是只加一個主機路由，以后若還有其他需要走政務外網防火墻的路由，還要手動添加，這次何不加一條網段 路 由，ip route-static 59.225.200.0 24 10.10.10.109。

配置好后讓對方確認，仍然不能訪問“政務一體化”平臺，而且連市局都不能正常訪問了。讓對方tracert跟蹤路由才發現，剛才那條配置引起了路由環路（如圖2）。因為B地市局不能提供網絡拓撲圖，暫時無法解釋環路是如何形成的。趕快撤消前面的配置undo ip routestatic 59.225.200.0 24 10.10.10.109，看來只能加上主機路由了，ip routestatic 59.225.200.123 32 10.10.10.109。再和對方確認，B地市局訪問恢復正常，下面的縣局也都能正常訪問“政務一體化”平臺。

路由問題治標還需治本

圖2 tracert跟蹤路由發現路由環路

其他地市陸續報出以上類似問題，有技術能力的地市局就加主機路由自行解決了訪問故障，而大部分地市局都需要我們協助處理。經過排查，發現該問題的根本原因還是因為省局網絡中有路由器在OSPF引入了一條外部路由，改變了地市局網絡訪問“政務一體化”的路由走向。原本走地市局政務外網防火墻出去，現在就被這條O_ASE路由引到省局，又被省局政務外網防火墻阻止，最終無法正常訪問“政務一體化”平臺。

為了治本，得仔細看一下這條路由為什么被引入，在哪臺路由器上引入，可否直接在源路由器上過濾掉此條路由對其他路由器的傳播。

在A地市局邊界路由器上查詢OSPF鏈路數據庫dis ospf lsdb | in 59.225.200，到59.225.200.0網絡連接類型為External，宣告路由器為172.27.254.2，正是省局管理機房的1臺路由器宣告的外部路由。再登錄該路由器檢查配置，發現如下相關條目：

圖3 OSPF骨干區域area0

再檢查省局管理機房的核心交換機，也開啟了OSPF路由，與省局網絡出口路由器同在區域area0。進一步分析，上面的配置目的是為了省局網絡用戶的計算機訪問政務外網服務器指定了出口路由，省去了在核心交換機上配置靜態路由到政務外網防火墻。估計后來省局網絡在IDC新建了機房，又將IDC路由器和核心交換機劃入了OSPF骨干區域area0，通過動態路由打通省局網絡機房和IDC各網段的連接（如圖3）。同時，這條路由又被宣告到其他OSPF區域，影響了地市局訪問政務外網服務器路由走向，當大家訪問“政務一體化”平臺時問題就出現了。

理清了O_ASE路由的來弄去脈，對于該問題的治本辦法也就簡單了。首先在省局核心交換機上配置靜態路由ip route-static 59.223.0.0 24 211.211.211.1，ip route-static 59.225.0.0 24 211.211.211.1，讓省局網絡通過靜態路由訪問政務外網指定網段。然后在省局出口路由器上進入OSPF視圖，撤消之前引入到政務外網的靜態路由undo import-route static route-policy 2011，最 后undo num 2011，保存配置。

在排查過程中搜索互聯網關于OSPF路由發現一好帖子在此分享：http://support.huawei.com/huaweiconnect/enterprise/thread-251907.html，路 由過濾分為對路由表的過濾和阻止lsa生成兩種方式。上述問題還有其他更好的解決辦法，由于路由器軟件版原因，未能測試成功。還有華為HCNP在線視頻教程也值得分享：http://support.huawei.com/learning/Certi ficate!showCertificate?pb iPath=term1000025451&id=N ode1000004373。

經驗總結

經過這幾次路由調試和排查，深刻理解了網絡路由條目的匹配除了優先級、開銷值外，讓我掌握了最長配原則,還有靜態路由是逐跳傳遞、雙向有去也要有回的數據包才能通。