1 OSPF協議綜述

OSPF是Open Shortest Path First（即“開放最短路由優先協議”）的縮寫。它是IETF組織開發的一個基于鏈路狀態的自治系統內部路由協議。在IP網絡上，它通過收集和傳遞自治系統中的鏈路狀態來動態地發現并傳播路由；OSPF協議支持IP子網和外部路由信息的標記引入；它支持基于接口的報文驗證以保證路由計算的安全性；OSPF協議使用IP Multicasting方式發送和接收報文。

每個支持OSPF協議的路由器都維護著一份描述整個自治系統拓撲結構的數據庫——這一數據庫是收集所有路由器的鏈路狀態廣播而得到的。每一臺路由器總是將描述本地狀態的信息（如可用接口信息、可達鄰居信息等）廣播到整個自治系統中去。在各類可以多址訪問的網絡中，如果存在兩臺或兩臺以上的路由器，該網絡上要選舉出“指定路由器”(DR)和“備份指定路由器”(BDR)。“指定路由器”負責將網絡的鏈路狀態廣播出去。引入這一概念，有助于減少在多址訪問網絡上各路由器之間鄰接關系的數量。OSPF協議允許自治系統的網絡被劃分成區域來管理，區域間傳送的路由信息被進一步抽象，從而減少了占用網絡的帶寬。

OSPF使用4類不同的路由，按優先順序來說分別是：

l區域內路由

l區域間路由

l第一類外部路由

l第二類外部路由

區域內和區域間路由描述的是自治系統內部的網絡結構，而外部路由則描述了應該如何選擇到自治系統以外目的地的路由。一般來說，第一類外部路由對應于OSPF從其它內部路由協議所引入的信息，這些路由的花費和OSPF自身路由的花費具有可比性；第二類外部路由對應于OSPF從外部路由協議所引入的信息，它們的花費遠大于OSPF自身的路由花費，因而在計算時，將只考慮外部的花費。

根據鏈路狀態數據庫，各路由器構建一棵以自己為根的最短路徑樹，這棵樹給出了到自治系統中各節點的路由。外部路由信息出現在葉節點上，外部路由還可由廣播它的路由器進行標記以記錄關于自治系統的額外信息。

OSPF的區域由BackBone（骨干區域）進行連接，該區域以0.0.0.0標識。所有的區域都必須在邏輯上連續，為此，骨干區域上特別引入了虛連接的概念以保證即使在物理上分割的區域仍然在邏輯上具有連通性。

在同一區域內的所有路由器都應該一致同意該區域的參數配置。因此，應該以區域為基礎來統一考慮，錯誤的配置可能會導致相鄰路由器之間無法相互傳遞信息，甚至導致路由信息的阻塞或者自環等。

2 OSPF排錯步驟

由于OSPF協議自身的復雜性，在配置的過程中可能會出現錯誤。

OSPF協議正常運行的標志是：在每一臺運行該協議的路由器上，應該得到的路由一條也不少，并且都是最優路徑。

2.1 排除故障的步驟：

(1)配置故障處理：檢查是否已經啟動并正確配置了OSPF協議。

(2)局部故障處理：檢查兩臺直接相連的路由器之間協議運行是否正常。

(3)全局故障處理：檢查一下系統設計（主要是指區域的劃分）是否正確。

(4)其它疑難問題：路由時通時斷、路由表中存在路由卻無法PING通該地址。需要針對不同的情況具體分析。

2.2 協議基本配置是否正確

在排除故障之前，應首先檢查基本的協議配置是否正確。

(1) 是否已經配置了Router ID

使用命令router id Router-id

Router-id可以配置為與本路由器一個接口的IP地址相同，需要注意的是：不能有任何兩臺路由器的Router ID是完全相同的。

(2) 檢查OSPF協議是否已成功地被激活

使用命令ospf enable啟動協議的運行。該命令是協議正常運行的前提。

(3) 檢查需要運行OSPF的接口是否已配置屬于特定的區域

使用命令ospf enable area area_id 將接口配置屬于特定區域。可通過命令 display ospf interface interfacename來查看該接口是否已經配置成功。

(4) 檢查是否已正確地引入了所需要的外部路由。

實際運行中可能經常需要引入自治系統外部路由（其他協議如BGP或靜態路由）。如果需要，是否已經通過命令import 配置了引入。

2.3 鄰居路由器之間的故障

由于OSPF協議需要整個自治系統中所有路由器的協調工作，所以任意兩臺相鄰路由器之間的故障都會導致網絡中全部或部分路由錯誤。

如何判斷相鄰的路由器之間運行正常：

在兩臺路由器上分別執行display ospf peer命令，查看在相應的接口上是否已發現對端路由器為自己的鄰居，并且鄰居狀態機達到Full狀態。需要注意的是：在Broadcast和NBMA類型的網絡中，兩臺接口狀態是DROther的路由器之間鄰居狀態機停留在“2-Way”狀態，這是正常的，但都應該與DR之間達到Full狀態。兩臺路由器之間達到Full需要一定的時間，一般在幾秒鐘至3分鐘之間為正常。如果超過這段時間仍舊沒有發現鄰居或沒有達到Full狀態，則可以判斷為出現故障。若出現故障可按下列幾點來檢查：

(1)檢查物理連接及下層協議是否正常運行。

OSPF正常運行需要下層協議來發送和接收報文，所以必須確保下層協議運行無誤。可通過ping命令測試，若從本地路由器Ping對端路由器不通，則表明物理連接和下層協議有問題。但需要注意的是：ping命令發送的是單播報文，而OSPF除了在NBMA類型的接口之外，都發送多播報文。所以除了能夠ping通對端之外，還必須具有能夠收發多播報文的能力。

(2)檢查雙方在接口上的配置是否一致

如果物理連接和下層協議正常，則檢查在接口上配置的OSPF參數，必須保證和與該接口相鄰的路由器的參數一致。這些參數包括 ospf timer hello， ospf timer dead和authentication-mode。區域（area）號必須相同。網段與掩碼也必須一致（點到點與虛連接的網段與掩碼可以不同）。這些錯誤可以通過命令display ospf error來查看。關于常用的OSPF錯誤值可以參見附錄的說明。

(3) hello時間與dead時間之間的關系

按照協議規定，接口上的dead的值必須大于hello，并且至少在4倍以上。否則的話會引起鄰居狀態之間的震蕩。

(4)若網絡的類型為廣播或NBMA，至少有一臺路由器的priority應大于零。

協議規定，接口的priorty = 0 的路由器沒有被選舉權，即不能被選為DR或BDR。而在廣播或NBMA類型網絡中所有的路由器只與DR之間交換路由信息，所以至少應有一臺路由器的priority應大于零。

(5)區域的STUB屬性必須一致

如果一個AREA配置成STUB AREA，則在與這個區域相連的所有路由器中都應將該區域配置成STUB AREA。

(6)接口的網絡類型必須一致

兩臺直接相連的路由器，它們之間的接口的網絡類型必須一致。否則可能無法正確計算出路由。查看接口的網絡類型可以使用命令display ospf interface，如果發現雙方類型不一致，可使用接口配置模式下的命令 ospf network-type 來修改。需要特別注意的是：當兩臺路由器的接口類型不一致時，雙方的鄰居狀態機仍舊有可能達到Full狀態，但無法正確計算路由。

(7)在NBMA類型的網絡中是否手工配置了鄰居

協議規定在NBMA類型的網絡中發送單播報文，這樣就不能通過發送多播報文來動態發現鄰居，所以必須手工指定鄰接點的IP地址。

2.4 系統規劃的故障

系統規劃中的故障主要體現在區域化分中的錯誤。協議中對區域劃分的要求是：如果自治系統被劃分成一個以上的區域，則必須有一個區域是骨干區域，并且保證其它區域與骨干區域直接相連或邏輯上相連，且骨干區域自身也必須是連通的。區域劃分錯誤的表現形式是：在一個區域內通常路由都是正常的，但無法得到區域外部的路由。

這是從全局規劃的角度來看的，如果落實到具體的配置上，可以這樣認為：如果在一臺路由器上配置了兩個以上的區域，則至少應該有一個是骨干區域，或者配置了一條虛連接。在上圖中用此方法判斷，配置了兩個以上區域的是RTB和RTC，其中RTB符合要求，RTC上由于沒有配置骨干區域，所以是錯誤的配置。表現的形式可能是在RTD上無法得到RTA和RTB的路由，同理，RTA和RTB上也無法得到RTD的路由。修改的方法是將Area0和Area1互相調換一下位置，或者在RTB和RTC之間配置一條虛連接。但這種判斷方法只是配置正確的必要條件，而非充分條件。

圖5-2 系統規劃例如，每臺路由器的配置都符合上面的條件，但配置仍舊是不正確的。錯誤在于骨干區域自身沒有連通。改正的方法是：在RTB與RTC之間配置一條虛連接。

2.5 其它疑難雜癥

如果經過以上分析之后，仍無法定位錯誤產生的原因，可繼續按以下步驟查找。

(1)路由表中丟失部分路由：

可以查詢一下是否本路由器配置了路由過濾。可查看是否配置了命令distribute list in（在OSPF協議配置模式下）。如果配置，再查詢access-list中的訪問規則，是否丟失的路由恰好是訪問列表中所過濾的。

(2)路由表不穩定，時通時斷：

表現形式為：路由表中的部分或者全部路由表現不穩定，一會兒加上了，一會兒又丟失，且變化很快。這種錯誤不太好分析，可能由以下幾種原因產生：

網絡中線路質量不好，導致線路時通時斷，造成OSPF上一頁 [1] [2] [3] 下一頁

的路由隨之不停的更改。可以通過檢查相應的鏈路層協議是否正常來定位問題的原因。

在撥號的情況下，如果是多臺路由器同時撥一臺路由器時，應將所有的這些撥號的接口類型改為point-to-multipoint。因為缺省的網絡類型是point-to-point，如果不加更改的話，當有多臺路由器同時撥入時，接入方會在這些撥入的路由器之間不停的選擇其中的一個并建立鄰接關系。導致路由不穩定。

有可能是自治系統中有兩臺路由器的Router ID相同了。協議中規定，一臺路由器的Router ID應該在整個自治系統中唯一。如果有兩臺路由器的Router ID相同，協議運行就會出現故障。這兩臺路由器如果是鄰居的話，在相互接收對方的hello報文時會檢測到這一錯誤，導致無法建立鄰接關系。如果這兩臺路由器不是直接相連，而是分別位于自治系統中的兩個不同的地方，則表現出的現象是部分路由時斷時通。可以通過查看這部分不正常的路由所屬的路由器來定位此問題。

(3) 無法引入自治系統外部路由：

某臺路由器引入了自治系統外部路由后，卻無法在其它路由器上發現這些路由。則很可能是由于本路由器處于一個STUB區域之內，因為按照協議規定，STUB區域內不傳播Type5類型的LSA。所以這種類型的LSA即不能由區域外傳播進來，也同樣不能由區域內傳播出去。實際上即使是同一個區域內的其它路由器也無法獲得這些路由信息。

(4)區域間路由聚合的問題：

通過在ABR上配置路由聚合可以大大減少自治系統中的路由信息，但如果配置不當，也會出現如下問題：

某個區域配置了聚合之后，在其它區域中雖然有聚合后的路由，但未聚合前的路由仍舊存在。出現這種現象的原因多半是因為該區域有兩個以上的ABR，用戶只在其中一臺ABR上配置了聚合命令，而沒有在其它的ABR上配置相同的命令。在下圖中，Area1內有兩個網段10.1.1.0/24、10.1.2.0/24，在其中的一個ABR（RTA）上配置了聚合命令，將這兩條路由聚合為一條10.1.0.0/16 的路由。而在另一個ABR（RTB）上，由于沒有配置聚合命令，所以仍舊向Area 0發送兩條未經聚合的路由10.1.1.0/24、10.1.2.0/24。所以在Area 0中會有3條路由同時出現。

配置了路由聚合之后，路由表顯示正常，但卻無法PING通某些目的地址。

可能是由于聚合命令配置錯誤導致。例如在下圖中，Area1中內有兩個網段10.1.1.0/24、10.1.2.0/24，被ABR（RTA）聚合成一條10.1.0.0/16的路由后發送到Area 0；同時在另一個區域Area 2中有兩個網段10.1.3.0/24、10.1.4.0/24，也被ABR（RTB）聚合成一條相同的路由10.1.0.0/16后發送到Area 0中。這樣RTA和RTB同時發布一條相同的到達10.1.0.0/16的路由。RTC由于距離RTA較近（花費值為5，而到RTB為10），所以選擇RTA為到達此目的地址的下一跳。如果此時在RTC上PING10.1.3.0/24網段中的某個地址，則報文會被錯誤的發送給RTA，導致不可達。修改的方法是去掉某臺ABR上的路由聚合。