OSPF故障處理

 OSPF故障處理

本文概述OSPF路由協議的故障處理問題1  OSPF協議綜述

OSPFOpen 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狀態。需要注意的是:在BroadcastNBMA類型的網絡中,兩臺接口狀態是DROther的路由器之間鄰居狀態機停留在“2-Way”狀態,這是正常的,但都應該與DR之間達到Full狀態。兩臺路由器之間達到Full需要一定的時間,一般在幾秒鐘至3分鐘之間爲正常。如果超過這段時間仍舊沒有發現鄰居或沒有達到Full狀態,則可以判斷爲出現故障。若出現故障可按下列幾點來檢查:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.4  系統規劃的故障

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

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

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

2.5  其它疑難雜症

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

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

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

(2)路由表不穩定,時通時斷:

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

網絡中線路質量不好,導致線路時通時斷,造成OSPF 的路由隨之不停的更改。可以通過檢查相應的鏈路層協議是否正常來定位問題的原因。

在撥號的情況下,如果是多臺路由器同時撥一臺路由器時,應將所有的這些撥號的接口類型改爲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/2410.1.2.0/24,在其中的一個ABRRTA)上配置了聚合命令,將這兩條路由聚合爲一條10.1.0.0/16 的路由。而在另一個ABRRTB)上,由於沒有配置聚合命令,所以仍舊向Area 0發送兩條未經聚合的路由10.1.1.0/2410.1.2.0/24。所以在Area 0中會有3條路由同時出現。 

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

可能是由於聚合命令配置錯誤導致。例如在下圖中,Area1中內有兩個網段10.1.1.0/2410.1.2.0/24,被ABRRTA)聚合成一條10.1.0.0/16的路由後發送到Area 0;同時在另一個區域Area 2中有兩個網段10.1.3.0/2410.1.4.0/24,也被ABRRTB)聚合成一條相同的路由10.1.0.0/16後發送到Area 0中。這樣RTARTB同時發佈一條相同的到達10.1.0.0/16的路由。RTC由於距離RTA較近(花費值爲5,而到RTB10),所以選擇RTA爲到達此目的地址的下一跳。如果此時在RTCPING10.1.3.0/24網段中的某個地址,則報文會被錯誤的發送給RTA,導致不可達。修改的方法是去掉某臺ABR上的路由聚合。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章