Guest

OSPFネイバーが Exstart/Exchange 状態のままでいるのはなぜですか。

ダウンロード オプション

  • PDF     (199.0 KB)
    Adobe Reader を使ってさまざまなデバイスで表示
  • ePub     (85.3 KB)
    iPhone、iPad、Android、ソニーの Reader、または Windows Phone 上で、さまざまなアプリを使って表示
  • Mobi (Kindle)     (106.8 KB)
    Kindle デバイスで、または Kindle アプリを使って複数のデバイスで表示
Updated: 2005 年 8 月 10 日
Document ID:13684
翻訳について

翻訳について

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

概要

隣接関係の形成に関する 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 ® ソフトウェア リリース 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 コマンドでは次のような出力が表示されます。

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

12a_01.gif

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

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

!--- MTU sets to it's 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 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#

ルータ 6 が exchange 状態のときに、1450 バイト（ルータ 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 の不一致を認識できます。） 最初の DBD がルータ 7.ルータ 7 によって拒否されるルータ 6 は最初の 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 の、付録 G.9 に従っています。leavingcisco.com ルータは、そのルータで受信可能なものよりも大きな MTU をアドバタイジングする DBD パケットを受信すると、その DBD パケットを無視し、近隣ルータの状態は exstart のままになります。 これにより隣接関係が形成されなくなります。 この問題を解決するには、リンクの両端で MTU を等しくする必要があります。

Cisco IOSソフトウェア 12.01(3) では MTU ミスマッチ 検出を消す、ip ospf mtu-ignore インターフェイスコンフィギュレーションコマンドはまたもたらされました; ただし、これはこのダイアグラムに示すようにだけ必要まれに、です:

12b.gif

上の図では、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 のセクション 10.3 には、exstart/exchange プロセスが次のいずれかのイベントによって起動されると書かれています（内部ソフトウェアに問題があるとこれらが発生します）。leavingcisco.com

  • SequenceNumberMismatch

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

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

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

  • BadLSReq

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

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

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

関連情報

シスコ エンジニア提供

  • sshamim
    aboinpal

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

Feedbackフィードバック

お問い合わせ先

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