IP : Open Shortest Path First(OSPF)

OSPF が PRI、BRI、またはダイヤラ インターフェイスの隣接関係を形成しない理由

2016 年 10 月 27 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2015 年 8 月 22 日) | フィードバック


目次


概要

このテクニカル ノートでは、ダイヤラ インターフェイスがポイントツーポイント リンクとして設定されている場合の、OSPF 隣接関係の形成の問題について説明します。

前提条件

要件

このドキュメントに関する固有の要件はありません。

使用するコンポーネント

このドキュメントは、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

問題

一次群速度インターフェイス(PRI)、基本速度インターフェイス(BRI)、およびダイヤラ インターフェイスの OSPF ネットワーク タイプは、ポイントツーポイントです。 PRI、BRI、またはダイヤラ インターフェイスが OSPF 隣接関係を形成しようとするときに共通する問題は、ネイバーが exstart/exchange プロセスで停止してしまうことです。 次に例を示します。

/image/gif/paws/13691/20a.gif

show ip ospf neighborを使用すると、ネイバーの状態が「EXSTART」で停止していることがわかります。

RTR-A# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.3           1   EXSTART/  -     00:00:37    3.3.3.3         Serial6/0:23
3.3.3.4           1   EXSTART/  -     00:00:39    3.3.3.4         Serial6/0:23

RTR-B# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.2           1   EXSTART/  -     00:00:36    3.3.3.2         BRI0

RTR-C# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.2           1   EXSTART/  -     00:00:35    3.3.3.2         BRI0

RTR B の設定は、ネットワーク タイプがポイントツーポイントであることを示しています。

RTR-B# show ip ospf interface bri0 
     BRI0 is up, line protocol is up (spoofing) 
       Internet Address 3.3.3.3/24, Area 2 
       Process ID 1, Router ID 3.3.3.3, Network Type POINT_TO_POINT, Cost: 1562 
       Transmit Delay is 1 sec, State POINT_TO_POINT, 
       Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 
         Hello due in 00:00:06 
       Index 1/1, flood queue length 0 
       Next 0x0(0)/0x0(0) 
       Last flood scan length is 1, maximum is 1 
       Last flood scan time is 0 msec, maximum is 0 msec 
       Neighbor Count is 1, Adjacent neighbor count is 0 
       Suppress hello for 0 neighbor(s) 

この状況は、debug ip ospf adjを使用してデバッグできます。 上の図に示す RTR-B で、このコマンドを実行したときの出力例を調べてみましょう。

1: Send DBD to 3.3.3.2 on BRI0 seq 0xB41 opt 0x42 flag 0x7 len 32 
2: Rcv DBD from 3.3.3.2 on BRI0 seq 0x1D06 opt 0x42 flag 0x7 len 32 
   mtu 1500 state EXSTART 
3: First DBD and we are not SLAVE 
4: Rcv DBD from 3.3.3.2 on BRI0 seq 0xB41 opt 0x42 flag 0x2 len 92 mtu 
   1500 state EXSTART 
5: NBR Negotiation Done. We are the MASTER 
6: Send DBD to 3.3.3.2 on BRI0 seq 0xB42 opt 0x42 flag 0x3 len 92 
7: Database request to 3.3.3.2 
8: sent LS REQ packet to 3.3.3.2, length 12 
9: Rcv DBD from 3.3.3.2 on BRI0 seq 0x250 opt 0x42 flag 0x7 len 32 
   mtu 1500 state EXCHANGE 
10: EXCHANGE - inconsistent in MASTER/SLAVE 
11: Bad seq received from 3.3.3.2 on BRI0 
12: Send DBD to 3.3.3.2 on BRI0 seq 0x2441 opt 0x42 flag 0x7 len 32 
13: Rcv DBD from 3.3.3.2 on BRI0 seq 0x152C opt 0x42 flag 0x2 len 92 
    mtu 1500 state EXSTART 
14: Unrecognized dbd for EXSTART 
15: Rcv DBD from 3.3.3.2 on BRI0 seq 0xB42 opt 0x42 flag 0x0 len 32 
    mtu 1500 state EXSTART 
16: Unrecognized dbd for EXSTART 

1 ~ 3 行目: RTR-B は、シーケンス番号 0xB41 で最初の DBD を 3.3.3.2(RTR-A)に送信し、シーケンス番号 0x1D06 で最初の DBD を 3.3.3.2(RTR-A)から受信しています。 ネイバー ネゴシエーションは、まだ完了していません。

4 ~ 6 行目: RTR-B は、RTR B の最初の DBD を RTR-A が受信したことを示す応答を 3.3.3.2(RTR-A)から受信します。 RTR-A は、RTR-B のルータ ID の方が大きいため自身をスレーブに選択します。 RTR-A からの確認応答を受信した RTR-B は、自身をマスターとして宣言し、データを含む最初の DBD を送信します。 シーケンス番号が 0xB42 である点に注目してください。 RTR-B がマスターであり、シーケンス番号を増分できるのはマスターだけです。

回線 7: RTR-A は送信するデータがまだあることを示していたので(RTR-A から最後に受信した DBD でフラグが 0x2 に設定されていたので)、RTR-B は RTR-A からのデータを要求します。

回線 8: RTR-B は、3.3.3.2(RTR-A)にリンクステート要求パケットを送信します。 これは OSPF パケット タイプ 3 です。 通常、このパケットはネイバーの IP アドレスに送信されます。 この例では、ネイバーの IP アドレスはルータ ID になります。

9 ~ 11 行目: RTR-B は、スレーブ(RTR-A)から、まったく異なるシーケンス番号とフラグ 0x7(init フラグ)が含まれた応答を受信します。 この DBD は、別のルータ(おそらく RTR-C)を対象としていますが、誤って RTR-B が受信しています。 フラグ 0x7 は隣接関係の交換中に MS(マスター/スレーブ)ビットを設定することで、スレーブがその状態をマスターに変更したことを意味します。そのため、RTR-B は不一致があることを宣言します。 さらに、RTR-B はシーケンス番号の順序に間違いがあることを訴えます。 スレーブは、常にマスターのシーケンス番号に従う必要があります。

回線 12: RTR-B は最初の DBD を 3.3.3.2 に送信して、隣接関係を再初期化し、マスターとスレーブを再選択します。

13 ~ 14 行目: RTR-B は、RTR-B のシーケンス番後を認識していない 3.3.3.2(RTR-A)から RTR-A がスレーブであることを示す DBD を受信します。 RTR-B は、マスターとスレーブのネゴシエーションが完了していないため、この DBD を認識しないことを宣言します。 この DBD パケットは、別のルータを対象にしたものです。

回線 15: RTR-B は、古い DBD についての 3.3.3.2(RTR-A)からの応答を受信しますが、隣接関係プロセスは RTR-B によって再初期化されているため、この応答は手遅れになります。

回線 16: この DBD は RTR-B が解消してしまった「古い」隣接関係に関するものであるため、RTR-B は、この DBD の認識に失敗します。

このプロセスが、永遠と繰り返されます。

解決策

RFC 2328 のセクション 8.1 によると、 leavingcisco.com OSPF はインターフェイスが双方向状態を確立した後でも、ポイントツーポイントのネットワーク タイプにマルチキャスト パケットを送信します。 RTR-A は、RTR-B と RTR-C の両方と隣接関係を形成しようとするため、RTR-B は RTR-C に向けられた DBD パケットを受信し、RTR-C は RTR-B に向けられた DBD を受信します。

この問題を解決するには、すべてのルータのネットワーク タイプをポイントツーマルチポイントに変更します。 これにより、双方向状態の確立後に、ユニキャスト パケットを送信するように OSPF の動作を変更します。 この時点で、RTR-B は自身に向けられたパケットだけを受信し、RTR-C は自身に向けられたパケットだけを受信します。 このようにネットワーク タイプを変更すると、OSPF ルータは、PRI、BRI、またはダイヤラ インターフェイスで確実に隣接関係を形成するようになります。

ネットワーク タイプを変更するには、次のコンフィギュレーション コマンドを入力します。各行の最後では Enter を押します。 例として、RTR-B を変更します。

RTR-B# configure terminal 
RTR-B(config)# int bri 0 
RTR-B(config-if)# ip ospf network point-to-multipoint 
RTR-B(config-if)# end 

ここで、showを使用して RTR-B について調べます。ネットワーク タイプがポイントツーマルチポイントになっていて、状態が Full になっていることが確認できます。

RTR-B# show ip ospf interface bri0 
BRI0 is up, line protocol is up (spoofing) 
  Internet Address 3.3.3.3/24, Area 2 
  Process ID 1, Router ID 3.3.3.3, Network Type POINT_TO_MULTIPOINT, Cost: 1562 
  Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT, 
  Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5 
    Hello due in 00:00:16 
  Index 1/1, flood queue length 0 
  Next 0x0(0)/0x0(0) 
  Last flood scan length is 1, maximum is 1 
  Last flood scan time is 0 msec, maximum is 0 msec 
  Neighbor Count is 1, Adjacent neighbor count is 1 
    Adjacent with neighbor 172.16.141.10 
  Suppress hello for 0 neighbor(s) 
  
RTR-B# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
172.16.141.10     1   FULL/  -        00:01:36    3.3.3.2         BRI0 

関連情報


Document ID: 13691