IP : IP ルーティング

OSPF ネイバールータが exstart/exchange 状態のままになる理由

2009 年 4 月 17 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2005 年 8 月 10 日) | フィードバック

目次


概要

隣接関係の形成に関する OSPF の状態には、Down、Init、Attempt、2-way、Exstart、Exchange、Loading および Full があります。Open Shortest Path First(OSPF)ネイバールータが exstart/exchange 状態のままになる可能性のある理由は多数あります。このドキュメントでは、exstart/exchange 状態になる原因の OSPF ネイバールータ間の MTU の不一致を取り上げています。OSPF のトラブルシューティングについての詳細は、『OSPF のトラブルシューティング』を参照してください。



前提条件

要件

このドキュメントの読者には、基本的な『OSPF の動作と設定』、特に『OSPF 近隣ルータの状態』に関する知識が必要です。



使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づくものです。

  • Cisco 2503 ルータ

  • 両方のルータで実行される Cisco IOS(R) ソフトウェア リリース 12.2(24a)

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。対象のネットワークが実稼働中である場合には、どのような作業についても、その潜在的な影響について確実に理解しておく必要があります。



表記法

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



exstart 状態

2 台の OSPF ネイバールータが双方向通信を確立し、DR/BDR 選定が完了すると(マルチアクセス ネットワークの場合)、これらのルータは exstart 状態に移行します。この状態では、ネイバールータによってマスター/スレーブ関係が確立され、Database Descriptor(DBD; データベース記述子)パケットを交換するときに使用する、初期 DBD シーケンス番号が決定されます。



exchange 状態

マスター/スレーブ関係がネゴシエートされると(Router-ID が最も大きいルータがマスター)、ネイバールータは exchange 状態に移行します。この状態では、リンク ステート データベース全体を記述した DBD パケットをルータが交換します。ルータではリンク ステート リクエスト パケットも送信され、これによりネイバールータからの最新の Link-State Advertisements(LSA; リンク ステート アドバタイズメント)が要求されます。

OSPF ネイバールータでは、通常の OSPF 隣接関係構築プロセス中に exstart/exchange 状態を経過しますが、OSPF ネイバールータがこの状態のままになることは異常です。OSPF ネイバールータがこの状態のままになる一般的な理由を次に示します。さまざまな OSPF の状態についての詳細は、『OSPF 近隣ルータの状態』を参照してください。



OSPF ネイバールータが exstart/exchange 状態のままになる

この問題が最も頻繁に発生するのは、Cisco のルータと他のベンダーのルータとの間で OSPF を実行しようとした際です。ネイバールータのインターフェイスの Maximum Transmission Unit(MTU; 最大伝送ユニット)設定が一致していない場合に、問題が発生します。MTU が大きい側のルータからネイバールータの MTU 設定よりも大きいパケットが送信されると、ネイバールータではそのパケットが無視されます。この問題が発生すると、show ip ospf neighbor コマンドでは次のような出力が表示されます。

このセクションでは、この問題が実際に再現された様子を説明しています。

Router 6 と Router 7 の構成図

Router 6 と Router 7 の構成図

上記のトポロジで Router 6 と Router 7 はフレームリレー経由で接続され、Router 6 は 5 のスタティック ルートが OSPF に再配布されて設定されています。Router 6 のシリアル インターフェイスのデフォルト MTU は 1500 で、Router 7 のシリアル インターフェイスの MTU は 1450 です。次の表に各ルータの設定を示します(必要な構成情報のみを示してあります)。

Router 6 の設定 Router 7 の設定
interface Serial2

!--- MTU はデフォルト値の 1500 に設定されています。

no ip address
no ip directed-broadcast
encapsulation frame-relay
no ip mroute-cache
frame-relay lmi-type ansi
!
interface Serial2.7 point-to-point
ip address 170.170.11.6 255.255.255.0
no ip directed-broadcast
frame-relay interface-dlci 101
!
router ospf 7
redistribute static subnets
network 170.170.11.0 0.0.0.255 area 0

ip route 192.79.34.0 255.255.255.0 Null0
ip route 192.79.35.0 255.255.255.0 Null0
ip route 192.79.36.0 255.255.255.0 Null0
ip route 192.79.37.0 255.255.255.0 Null0
ip route 192.79.38.0 255.255.255.0 Null0
!
interface Serial0
mtu 1450
no ip address
no ip directed-broadcast
encapsulation frame-relay
frame-relay lmi-type ANSI

!
interface Serial0.6 point-to-point
ip address 170.170.11.7 255.255.255.0
no ip directed-broadcast
frame-relay interface-dlci 110!
!

router ospf 7
network 170.170.11.0 0.0.0.255 area 0

各ルータでの show ip ospf neighbor コマンドの出力は次のようになります。

router-6# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
170.170.11.7      1   EXCHANGE/  -    00:00:36    170.170.11.7    Serial2.7
router-6#

router-7# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
170.170.11.6      1   EXSTART/  -     00:00:33    170.170.11.6    Serial0.6
router-7#

Router 6 が exchange state のときに、1450 バイト(Router 7 の MTU)よりも大きな DBD パケットを送信すると問題が発生します。各ルータで debug ip packet および debug ip ospf adj コマンドを使用すると、実行中の OSPF 隣接関係プロセスが表示されます。Router 6 および 7 の出力を、ステップ 1 〜 14 に示します。

  1. Router 6 のデバッグ出力:

    ***ROUTER6 IS SENDING HELLOS BUT HEARS NOTHING, 
    STATE OF NEIGHBOR IS DOWN
    00:03:53: OSPF: 170.170.11.7 address 170.170.11.7 on 
    Serial2.7 is dead
    00:03:53: OSPF: 170.170.11.7 address 170.170.11.7 on 
    Serial2.7 is dead, state DOWN
    
  2. Router 7 のデバッグ出力:

    OSPF NOT ENABLED ON ROUTER7 YET
    
  3. Router 6 のデバッグ出力:

    ***ROUTER6 SENDING HELLOS
    00:03:53: IP: s=170.170.11.6 (local), d=224.0.0.5 
    (Serial2.7), len 64, sending broad/multicast, proto=89
    00:04:03: IP: s=170.170.11.6 (local), d=224.0.0.5 
    (Serial2.7), Len 64, sending broad/multicast, proto=89
    
  4. Router 7 のデバッグ出力:

    OSPF NOT ENABLED ON ROUTER7 YET
    
  5. Router 7 のデバッグ出力:

    ***OSPF ENABLED ON ROUTER7, BEGINS SENDING 
    HELLOS AND BUILDING A ROUTER LSA
    00:17:44: IP: s=170.170.11.7 (local), d=224.0.0.5 
    (Serial0.6), Len 64, sending broad/multicast, proto=89
    00:17:44: OSPF: Build router LSA for area 0, 
    router ID 170.170.11.7, seq 0x80000001
    
  6. Router 6 のデバッグ出力:

    ***RECEIVE HELLO FROM ROUTER7
    00:04:04: IP: s=170.170.11.7 (Serial2.7), d=224.0.0.5, 
    Len 64, rcvd 0, proto=89
    00:04:04: OSPF: Rcv hello from 170.170.11.7 area 0 from 
    Serial2.7 170.170.11.7
    00:04:04: OSPF: End of hello processing
    
  7. Router 6 のデバッグ出力:

    ***ROUTER6 SEND HELLO WITH ROUTER7 ROUTERID 
    IN THE HELLO PACKET
    00:04:13: IP: s=170.170.11.6 (local), d=224.0.0.5 
    (Serial2.7), Len 68, sending broad/multicast, proto=89
    
  8. Router 7 のデバッグ出力:

    ***ROUTER7 RECEIVES HELLO FROM ROUTER6 CHANGES 
    STATE TO 2WAY
    00:17:53: IP: s=170.170.11.6 (Serial0.6), d=224.0.0.5, 
    Len 68, rcvd 0, proto=89
    00:17:53: OSPF: Rcv hello from 170.170.11.6 area 0 from 
    Serial0.6 170.170.11.6
    00:17:53: OSPF: 2 Way Communication to 170.170.11.6 on 
    Serial0.6, state 2WAY
    
  9. Router 7 のデバッグ出力:

    ***ROUTER7 SENDS INITIAL DBD PACKET WITH SEQ# 0x13FD
    00:17:53: OSPF: Send DBD to 170.170.11.6 on Serial0.6 
    seq 0x13FD opt 0x2 flag 0x7 Len 32
    00:17:53: IP: s=170.170.11.7 (local), d=224.0.0.5 
    (Serial0.6), Len 52, sending broad/multicast, proto=89
    00:17:53: OSPF: End of hello processing
    
  10. Router 6 のデバッグ出力:

    ***ROUTER6 RECEIVES ROUTER7'S INITIAL DBD PACKET 
    CHANGES STATE TO 2-WAY
    00:04:13: IP: s=170.170.11.7 (Serial2.7), d=224.0.0.5, 
    Len 52, rcvd 0, proto=89
    00:04:13: OSPF: Rcv DBD from 170.170.11.7 on Serial2.7 
    seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state INIT
    00:04:13: OSPF: 2 Way Communication to 170.170.11.7 on 
    Serial2.7, state 2WAY
    
  11. Router 6 のデバッグ出力:

    ***ROUTER6 SENDS DBD PACKET TO ROUTER7 
    (MASTER/SLAVE NEGOTIATION - ROUTER6 IS SLAVE)
    00:04:13: OSPF: Send DBD to 170.170.11.7 on Serial2.7 
    seq 0xE44 opt 0x2 flag 0x7 Len 32
    00:04:13: IP: s=170.170.11.6 (local), d=224.0.0.5 
    (Serial2.7), Len 52, sending broad/multicast, proto=89
    00:04:13: OSPF: NBR Negotiation Done. We are the SLAVE
    
  12. Router 7 のデバッグ出力:

    ***RECEIVE ROUTER6'S INITIAL DBD PACKET 
    (MTU MISMATCH IS RECOGNIZED)
    00:17:53: IP: s=170.170.11.6 (Serial0.6), d=224.0.0.5, 
    Len 52, rcvd 0, proto=89
    00:17:53: OSPF: Rcv DBD from 170.170.11.6 on Serial0.6 
    seq 0xE44 opt 0x2 flag 0x7 Len 32 mtu 1500 state EXSTART
    00:17:53: OSPF: Nbr 170.170.11.6 has larger interface MTU 
    
  13. Router 6 のデバッグ出力:

    ***SINCE ROUTER6 IS SLAVE SEND DBD PACKET WITH 
    LSA HEADERS, 
    SAME SEQ# (0x13FD) TO ACK ROUTER7'S DBD. (NOTE SIZE OF PKT)
    00:04:13: OSPF: Send DBD to 170.170.11.7 on Serial2.7 
    seq 0x13FD opt 0x2 flag 0x2 Len 1472
    00:04:13: IP: s=170.170.11.6 (local), d=224.0.0.5 
    (Serial2.7), Len 1492, sending broad/multicast, proto=89
    
  14. Router 7 のデバッグ出力:

    ***NEVER RECEIVE ACK TO ROUTER7'S INITIAL DBD, 
    RETRANSMIT
    00:17:54: IP: s=170.170.11.7 (local), d=224.0.0.5 
    (Serial0.6), Len 68, sending broad/multicast, proto=89
    00:18:03: OSPF: Send DBD to 170.170.11.6 on Serial0.6 
    seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF: 
    Retransmitting DBD to 170.170.11.6 on Serial0.6 [1]
    

この時点で Router 6 は、Router 7 からの初期 DBD パケットに確認応答し続けています。

00:04:13: IP: s=170.170.11.7 (Serial2.7), d=224.0.0.5,
Len 68, rcvd 0, proto=89
00:04:13: OSPF: Rcv hello from 170.170.11.7 area 0 from
Serial2.7 170.170.11.7
00:04:13: OSPF: End of hello processing

00:04:18: IP: s=170.170.11.7 (Serial2.7), d=224.0.0.5,
Len 52, rcvd 0, proto=89
00:04:18: OSPF: Rcv DBD from 170.170.11.7 on Serial2.7 
seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state EXCHANGE

00:04:18: OSPF: Send DBD to 170.170.11.7 on Serial2.7 
seq 0x13FD opt 0x2 flag 0x2 Len 1472
00:04:18: IP: s=170.170.11.6 (local), d=224.0.0.5 
(Serial2.7), Len 1492, sending broad/multicast, proto=89

00:04:23: IP: s=170.170.11.6 (local), d=224.0.0.5 
(Serial2.7), Len 68, sending broad/multicast, proto=89

00:04:23: IP: s=170.170.11.7 (Serial2.7), d=224.0.0.5,
Len 52, rcvd 0, proto=89
00:04:23: OSPF: Rcv DBD from 170.170.11.7 on Serial2.7
seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state EXCHANGE

Router 6 からの DBD パケットは Router 7 の MTU に対して大きすぎるため、Router 7 は Router 6 からの確認応答を受け取りません。Router 7 は DBD パケットの再送信を繰り返します。

0:17:58: IP: s=170.170.11.7 (local), d=224.0.0.5
(Serial0.6), Len 52, sending broad/multicast, proto=89
00:18:03: OSPF: Send DBD to 170.170.11.6 on Serial0.6 
seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF: 
Retransmitting DBD to 170.170.11.6 on Serial0.6 [2]

00:18:03: IP: s=170.170.11.7 (local), d=224.0.0.5 
(Serial0.6), Len 52, sending broad/multicast, proto=89
00:18:03: IP: s=170.170.11.6 (Serial0.6), d=224.0.0.5, 
Len 68, rcvd 0, proto=89
00:18:03: OSPF: Rcv hello from 170.170.11.6 area 0 from
Serial0.6 170.170.11.6
00:18:03: OSPF: End of hello processing

00:18:04: IP: s=170.170.11.7 (local), d=224.0.0.5 
(Serial0.6), Len 68, sending broad/multicast, proto=89

00:18:03: OSPF: Send DBD to 170.170.11.6 on Serial0.6 
seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF: 
Retransmitting DBD to 170.170.11.6 on Serial0.6 [3]

00:18:08: IP: s=170.170.11.7 (local), d=224.0.0.5 
(Serial0.6), Len 52, sending broad/multicast, proto=89
router-7#

Router 6 の方が MTU が大きいため、Router 6 では引き続き Router 7 から DBD パケットを受け取り、その確認応答を試み、EXCHANGE 状態のままになります。

Router 7 の方が MTU が小さいため、Router 7 では Router 6 からの確認応答に付属する DBD パケットを無視して、引き続き初期 DBD パケットを再送信し続け、EXSTART 状態のままになります。

上記のステップから取り出して見ていきましょう。ステップ 9 と 11 では、Router 7 と Router 6 から、マスター/スレーブ ネゴシエーションの一環で、フラグ 0x7 を設定した最初の DBD パケットが送信されます。マスター/スレーブ関係が確立されると、Router-ID が高いため Router 7 がマスターに選出されます。ステップ 13 と 14 のフラグでは、Router 7 がマスター(Flag 0x7)であり、Router 6 がスレーブ(Flag 0x2)であることが明確に示されています。

ステップ 10 で、Router 6 は Router 7 の初期 DBD パケットを受信し、自身の状態を 2-way に移行します。

ステップ 12 で、Router 7 は Router 6 の初期 DBD パケットを受信し、MTU の不一致を認識します。(Router 6 が DBD パケットのインターフェイス MTU フィールドに自分のインターフェイス MTU を含めているため、Router 7 は MTU の不一致を認識できます。)Router 6 の初期 DBD は Router 7 で破棄されます。Router 7 は初期 DBD パケットを再送信します。

ステップ 13 は、スレーブの Router 6 が Router 7 のシーケンス番号を採用し、第 2 の DBD パケットを送信しますが、自分の LSA のヘッダーを含んでいるためにパケットのサイズが増加していることを表しています。ところが、この DBD パケットは Router 7 の MTU よりも大きいため、Router 7 はこのパケットを受信しません。

ステップ 13 の後、Router 7 は初期 DBD パケットを Router 6 へ再送信し続け、Router 6 はマスターのシーケンス番号に従った DBD パケットを送信しつづけます。このループが無限に続き、どちらのルータも exstart/exchange 状態から抜け出せなくなります。



ソリューション

問題の原因は MTU の不一致であるため、解決方法はどちらかのルータの MTU をネイバールータの MTU と一致させることです。ただし、Cisco IOS では LAN インターフェイス(イーサネットやトークン リングなど)の物理 MTU の変更がサポートされていません。Cisco のルータと他のベンダーのルータとの間の LAN メディア上で問題が発生した際は、他のベンダーのルータの MTU を調整してください。

注:Cisco IOS ソフトウェア リリース 12.0(3) では、インターフェイスの MTU 不一致の検出機能が導入されています。この検出機能にはインターフェイスの MTU を DBD パケット中で OSPF アドバタイジングすることが含まれており、これは OSPF RFC 2178 leavingcisco.com の、付録 G.9 に従っています。ルータは、そのルータで受信可能なものよりも大きな MTU をアドバタイジングする DBD パケットを受信すると、その DBD パケットを無視し、ネイバールータの状態は exstart のままになります。これにより隣接関係が形成されなくなります。この問題を解決するには、リンクの両端で MTU を等しくする必要があります。

Cisco IOS ソフトウェア 12.1(3) では、MTU の不一致検出をオフにするために、ip ospf mtu-ignore インターフェイス設定コマンドも導入されていますが、これが必要になるのは次の図に示すまれな状況だけです。

MTU の不一致検出をオフにする必要のある構成例

MTU の不一致検出をオフにする必要のある構成例

上の図では、Route Switch Module(RSM; ルート スイッチ モジュール)を搭載した Cisco Catalyst 5000 の Fiber Distributed Data Interface(FDDI; ファイバ分散データ インターフェイス)ポートが、Router 2 の FDDI インターフェイスに接続されています。RSM の Virtual LAN(VLAN; 仮想 LAN)は MTU が 1500 の仮想イーサネット インターフェイスで、Router 2 の FDDI インターフェイスの MTU は 4500 です。スイッチの FDDI ポートでパケットを受信すると、パケットがバックプレーンに送られ、FDDI からイーサネットへの変換およびフラグメンテーションがスイッチ内で行われます。これは有効な設定ですが、MTU 不一致検出機能のために、ルータと RSM の間で OSPF 隣接関係は形成されません。FDDI とイーサネットの MTU が異なるため、OSPF で MTU 不一致の検出を停止して隣接関係を形成するためには、RSM の VLAN インターフェイスに対してこの ip ospf mtu-ignore コマンドが便利です。

OSPF ネイバールータが exstart/exchange 状態のままになる理由としては MTU の不一致が最も一般的ですが、それだけではないことに注意してください。この問題が起きる最大の原因は、DBD パケットを正常に交換できないことです。ただし、根本的な原因として次のものが考えられます。

  • MTU の不一致

  • ユニキャストの障害。exstart 状態で、マスターおよびスレーブの選出を行うため、ルータからネイバールータにユニキャスト パケットが送信されます。これはポイントツーポイント リンク以外の場合の動作で、ポイントツーポイント リンクの場合はマルチキャスト パケットが送信されます。考えられる原因には次のものがあります。

    • 冗長度の高いネットワークでの、Asynchronous Transfer Mode(ATM; 非同期転送モード)またはフレームリレー環境での Virtual Circuit(VC; 仮想回線)のマッピングの誤り

    • MTU に関する問題。ルータが特定の長さのパケットでしか ping を実行できない

    • アクセス リストによってユニキャスト パケットがブロックされている

    • ルータで NAT が実行され、ユニキャスト パケットが変換されている

  • PRI および BRI/ダイヤラ間のネイバー関係

  • 両方のルータのルータ ID が同じである(設定の誤り)

また、OSPF RFC 2328 leavingcisco.com のセクション 10.3 には、exstart/exchange プロセスが次のいずれかのイベントによって起動されると書かれています(内部ソフトウェアに問題があるとこれらが発生します)。

  • SequenceNumberMismatch

    • 予期しない DD シーケンス番号

    • 「I」ビットが予期せずに設定される

    • オプション フィールドが、DBD パケットで受信した最後のオプション フィールドと異なっている

  • BadLSReq

    • 交換プロセス中に、ネイバールータが認識できない LSA を送信した

    • 交換プロセス中にネイバールータが LSA を要求したが、それが見つからない

OSPF でネイバールータが形成されない場合、問題のトラブルシューティングのためには、物理メディアやネットワーク ハードウェアなど、上記の要因を考慮してください。




関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報




Document ID: 13684