Open Shortest Path First(OSPF)ネイバーがExstart/Exchange状態のままになる問題のトラブルシューティング

ダウンロード オプション

  • PDF     (388.2 KB)
    Adobe Reader を使ってさまざまなデバイスで表示
  • ePub     (91.8 KB)
    iPhone、iPad、Android、ソニーの Reader、または Windows Phone 上で、さまざまなアプリを使って表示
  • Mobi (Kindle)     (105.9 KB)
    Kindle デバイスで、または Kindle アプリを使って複数のデバイスで表示
Updated: 2023 年 9 月 18 日
Document ID:13684

偏向のない言語

この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。

翻訳について

シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。

    概要

    このドキュメントでは、Open Shortest Path First(OSPF)ネイバーがExstartおよびExchange状態のままになる状況をトラブルシューティングする方法について説明します。 

    前提条件

    要件

    OSPFの基本的な動作と設定、特にOSPFネイバーの状態に精通していることが推奨されます。

    使用するコンポーネント

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

    • Cisco 2503 ルータ

    • 両方のルータで稼働するCisco IOS®ソフトウェアリリース12.2(24a)

    このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

    表記法

    表記法の詳細については、『シスコ テクニカル ティップスの表記法』を参照してください。

    背景説明

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

    exstart 状態

    2台のOSPF隣接ルータが双方向通信を確立し、（マルチアクセスネットワークで）DR/BDR選定を完了した後、ルータはExstart状態に移行します。この状態では、ネイバールータがプライマリ/サブテンド関係を確立し、DBDパケットの交換時に使用する初期Database Descriptor(DBD)シーケンス番号を決定します。

    exchange 状態

    1度だけ Primary/Subordinate 関係がネゴシエートされ（最も高いルータIDを持つルータがプライマリになる）、ネイバールータがExchange状態に移行します。この状態では、リンク ステート データベース全体を記述した DBD パケットをルータが交換します。ルータはリンクステートリクエストパケットも送信し、近隣ルータからの最新の Link-State Advertisements（LSA; リンクステートアドバタイズメント）を要求します。

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

    OSPF 隣接ルータが exstart/exchange 状態のままになる

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

    Router 6 and Router7 Connect via Frame Relayルータ6とルータ7がフレームリレー経由で接続する

    このセクションでは、この問題の実際の再現について説明します。

    この図のRouter 6とRouter 7はフレームリレー経由で接続され、Router 6にはOSPFに再配布された5つのスタティックルートが設定されています。Router 6 のシリアル インターフェイスのデフォルト MTU は 1500 で、Router 7 のシリアル インターフェイスの MTU は 1450 です。各ルータの設定を表に示します（必要な設定情報のみを示します）。

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

!--- MTU is set to its default value of 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 10.170.10.6 255.255.255.0
 no ip directed-broadcast
 frame-relay interface-dlci 101
!
router ospf 7
 redistribute static subnets
 network 10.170.10.0 0.0.0.255 area 0
!
ip route 192.168.0.10 255.255.255.0 Null0
ip route 192.168.10.10 255.255.255.0 Null0
ip route 192.168.10.0 255.255.255.0 Null0
ip route 192.168.37.10 255.255.255.0 Null0
ip route 192.168.38.10 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 172.16.7.11 255.255.255.0
 no ip directed-broadcast
 frame-relay interface-dlci 110
!
router ospf 7
 network 172.16.11.6 0.0.0.255 area 0

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

    router-6#show ip ospf neighbor

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

router-7#show ip ospf neighbor

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

    ルータ 6 が exchange 状態のときに、1450 バイト（ルータ 7 の MTU）よりも大きな DBD パケットを送信すると問題が発生します。 debug ip packet と debug ip ospf adj コマンドを各ルータで発行して、OSPFアジャセンシー関係プロセスの発生を確認します。Router 6 および 7 の出力を、ステップ 1 ～ 14 に示します。

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

      <<<ROUTER 6 IS SENDING HELLOS BUT HEARS NOTHING, STATE OF NEIGHBOR IS DOWN>>>
      
00:03:53: OSPF: 172.16.7.11 address 172.16.7.11 on 
Serial2.7 is dead
00:03:53: OSPF: 172.16.7.11 address 172.16.7.11 on 
Serial2.7 is dead, state DOWN

    2. Router 7 のデバッグ出力：

      <<<OSPF NOT ENABLED ON ROUTER7 YET>>>

    3. Router 6 のデバッグ出力：

      <<<ROUTER 6 SENDING HELLOS>>>
      
00:03:53: IP: s=10.170.10.6 (local), d=224.0.0.5 
(Serial2.7), len 64, sending broad/multicast, proto=89
00:04:03: IP: s=10.170.10.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 ROUTER 7, BEGINS SENDING HELLOS AND BUILDING A ROUTER LSA>>>
      
00:17:44: IP: s=172.16.7.11 (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 172.16.7.11, seq 0x80000001

    6. Router 6 のデバッグ出力：

      <<<RECEIVE HELLO FROM ROUTER7>>>
      
00:04:04: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5, 
Len 64, rcvd 0, proto=89
00:04:04: OSPF: Rcv hello from 172.16.7.11 area 0 from 
Serial2.7 172.16.7.11
00:04:04: OSPF: End of hello processing

    7. Router 6 のデバッグ出力：

      <<<ROUTER 6 SEND HELLO WITH ROUTER7 ROUTERID IN THE HELLO PACKET>>>
      
00:04:13: IP: s=10.170.10.6 (local), d=224.0.0.5 
(Serial2.7), Len 68, sending broad/multicast, proto=89

    8. Router 7 のデバッグ出力：

      <<<ROUTER 7 RECEIVES HELLO FROM ROUTER6 CHANGES STATE TO 2WAY>>>
      
00:17:53: IP: s=10.170.10.6 (Serial0.6), d=224.0.0.5, 
Len 68, rcvd 0, proto=89
00:17:53: OSPF: Rcv hello from 10.170.10.6 area 0 from 
Serial0.6 10.170.10.6
00:17:53: OSPF: 2 Way Communication to 10.170.10.6 on 
Serial0.6, state 2WAY

    9. Router 7 のデバッグ出力：

      <<<ROUTER 7 SENDS INITIAL DBD PACKET WITH SEQ# 0x13FD>>>
      
00:17:53: OSPF: Send DBD to 10.170.10.6 on Serial0.6 
seq 0x13FD opt 0x2 flag 0x7 Len 32
00:17:53: IP: s=172.16.7.11 (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 のデバッグ出力：

      <<<ROUTER 6 RECEIVES ROUTER7'S INITIAL DBD PACKET CHANGES STATE TO 2-WAY>>>
      
00:04:13: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5, 
Len 52, rcvd 0, proto=89
00:04:13: OSPF: Rcv DBD from 172.16.7.11 on Serial2.7 
seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state INIT
00:04:13: OSPF: 2 Way Communication to 172.16.7.11 on 
Serial2.7, state 2WAY

    11. Router 6 のデバッグ出力：

      <<<ROUTER 6 SENDS DBD PACKET TO ROUTER 7 (PRIMARY/SUBORDINATE NEGOTIATION - ROUTER 6 IS SUBORDINATE)>>>

      00:04:13: OSPF: Send DBD to 172.16.7.11 on Serial2.7 
      seq 0xE44 opt 0x2 flag 0x7 Len 32 
      00:04:13: IP: s=10.170.10.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 ROUTER 6'S INITIAL DBD PACKET (MTU MISMATCH IS RECOGNIZED)>>>
      
00:17:53: IP: s=10.170.10.6 (Serial0.6), d=224.0.0.5, 
Len 52, rcvd 0, proto=89
00:17:53: OSPF: Rcv DBD from 10.170.10.6 on Serial0.6 
seq 0xE44 opt 0x2 flag 0x7 Len 32 mtu 1500 state EXSTART
00:17:53: OSPF: Nbr 10.170.10.6 has larger interface MTU

    13. Router 6 のデバッグ出力：

      <<<SINCE ROUTER 6 IS SUBORDINATE SEND DBD PACKET WITH LSA HEADERS, SAME SEQ# (0x13FD) TO ACK ROUTER 7'S DBD. (NOTE SIZE OF PKT)>>>

      00:04:13: OSPF: Send DBD to 172.16.7.11 on Serial2.7 
      seq 0x13FD opt 0x2 flag 0x2 Len 1472 
      00:04:13: IP: s=10.170.10.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=172.16.7.11 (local), d=224.0.0.5 
(Serial0.6), Len 68, sending broad/multicast, proto=89
00:18:03: OSPF: Send DBD to 10.170.10.6 on Serial0.6 
seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF: 
Retransmitting DBD to 10.170.10.6 on Serial0.6 [1]

    この時点で、Router 6はRouter 7からの初期DBDパケットに対してACKを試行し続けます。

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

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

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

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

00:04:23: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5,
Len 52, rcvd 0, proto=89
00:04:23: OSPF: Rcv DBD from 172.16.7.11 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=172.16.7.11 (local), d=224.0.0.5
(Serial0.6), Len 52, sending broad/multicast, proto=89
00:18:03: OSPF: Send DBD to 10.170.10.6 on Serial0.6 
seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF: 
Retransmitting DBD to 10.170.10.6 on Serial0.6 [2]

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

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

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

00:18:08: IP: s=172.16.7.11 (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パケットを送信します。After Primary/Subordinate 判断すると、Router-IDの方が大きいため、Router 7がプライマリとして選出されます。手順13と14のフラグは、ルータ7がプライマリ（フラグ0x7）、ルータ6が下位（フラグ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は、ルータ6がルータ6のIPアドレスを subordinateはRouter 7のシーケンス番号を採用し、LSAのヘッダーを含む2番目のDBDパケットを送信するため、パケットのサイズが増加します。ところが、この DBD パケットは Router 7 の MTU よりも大きいため、Router 7 はこのパケットを受信しません。

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

    解決方法

    問題の原因は MTU の不一致であるため、解決方法はどちらかのルータの MTU をネイバールータの MTU と一致させることです。

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

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

    Fiber Distributed Data Interface (FDDI) Portファイバ分散データインターフェイス(FDDI)ポート

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

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

    • MTU の不一致

    • ユニキャストの障害。Exstart状態では、ルータはネイバーにユニキャストパケットを送信して、プライマリと下位を選出します。これはポイントツーポイント リンク以外の場合の動作で、ポイントツーポイント リンクの場合はマルチキャスト パケットが送信されます。考えられる原因を次に示します。

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

      • MTUの問題です。つまり、ルータは特定の長さのパケットにしかpingを実行できません。

      • アクセスリストはユニキャストパケットをブロックします。

      • NATはルータで実行され、ユニキャストパケットを変換します。

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

    • 両方のルータのルータIDが同じ（設定ミス）。

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

    • シーケンス番号が一致しません。

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

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

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

    • BadLSReq

      • 交換プロセス中に、近隣ルータが認識できない LSA を送信しました。

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

    OSPFがネイバーを形成しない場合、問題をトラブルシューティングするために、物理メディアやネットワークハードウェアなど、前述の要因を考慮します。

    関連情報

    更新履歴

    改定 発行日 コメント
    2.0
    18-Sep-2023
    再認定
    1.0
    10-Dec-2001
    初版
    TAC Authored

    シスコ エンジニア提供

    • Julio Jimenez
      Cisco TACエンジニア

    このドキュメントは役に立ちましたか?

    Feedbackフィードバック

    シスコに問い合わせ