シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。 ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。 シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版(リンクからアクセス可能)もあわせて参照することを推奨します。
隣接関係の形成に関する 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)
本書の情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、初期(デフォルト)設定の状態から起動しています。稼働中のネットワークで作業を行う場合、コマンドの影響について十分に理解したうえで作業してください。
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
2 台の OSPF 近隣ルータが双方向通信を確立し、DR/BDR 選定が完了すると(マルチアクセス ネットワークの場合)、ルータは exstart 状態に移行します。この状態では、ネイバールータによってマスター/スレーブ関係が確立され、Database Descriptor(DBD; データベース記述子)パケットを交換するときに使用する、初期 DBD シーケンス番号が決定されます。
マスター/スレーブ関係がネゴシエートされると(Router-ID が最も大きいルータがマスター)、ネイバールータは exchange 状態に移行します。この状態では、リンク ステート データベース全体を記述した DBD パケットをルータが交換します。ルータはリンクステートリクエストパケットも送信し、近隣ルータからの最新の Link-State Advertisements(LSA; リンクステートアドバタイズメント)を要求します。
OSPF ネイバールータでは、通常の OSPF 隣接関係構築プロセス中に exstart/exchange 状態を経過しますが、OSPF ネイバールータがこの状態のままになることは異常です。OSPF ネイバールータがこの状態のままになる一般的な理由を次に示します。さまざまな OSPF の状態についての詳細は、『OSPF 近隣ルータの状態』を参照してください。
この問題が最も頻繁に発生するのは、Cisco のルータと他のベンダーのルータとの間で OSPF を実行しようとした際です。ネイバールータのインターフェイスの Maximum Transmission Unit(MTU; 最大伝送ユニット)設定が一致していない場合に、問題が発生します。MTU が大きい側のルータからネイバールータの MTU 設定よりも大きいパケットが送信されると、ネイバールータではそのパケットが無視されます。この問題が発生すると、show ip ospf neighbor コマンドでは次のような出力が表示されます。
このセクションでは、この問題が実際に再現された様子を説明しています。
上記のトポロジで 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 に示します。
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
Router 7 のデバッグ出力:
OSPF NOT ENABLED ON ROUTER7 YET
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
Router 7 のデバッグ出力:
OSPF NOT ENABLED ON ROUTER7 YET
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
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
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
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
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
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
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
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
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
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 7 からの DBD パケットは Router 6 の MTU に対して大きすぎるため、Router 7 は Router 7 からの確認応答を受け取りません。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 7 が DBD パケットのインターフェイス MTU フィールドに自分のインターフェイス MTU を含めているため、Router 6 は MTU の不一致を認識できます。) ルータ6の初期DBDはルータ7によって拒否されます。ルータ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の不一致の検出が導入されました。この検出には、OSPF RFC 2178(付録G.9)に従ってDBDパケットのインターフェイスMTUをアドバタイズするOSPFが含まれます。ルータが受信できるMTUよりも大きいDBDパケットを受信すると、ネイバー状態ははのままになります。これにより隣接関係が形成されなくなります。この問題を解決するには、リンクの両端で MTU を等しくする必要があります。
Cisco IOSソフトウェア12.01(3)では、ip ospf mtu-ignoreインターフェイス設定コマンドも導入され、MTU不一致の検出をオフにしました。ただし、これは次の図に示すように、まれな場合にのみ必要です。
上の図は、Route Switch Module(RSM;ルートスイッチモジュール)がルータ2のFDDIインターフェイスに接続されたCisco Catalyst 5000のFiber Distributed Data Interface(FDDI;ファイバ分散データインターフェイス)ポートを示しています。RSMのVirtual LAN(VLAN;仮想)は)は1115555555500000000000000000000000000000000000000000000000000000000000ルータ2のインターフェイスの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 プロセスが次のいずれかのイベントによって起動されると書かれています(内部ソフトウェアに問題があるとこれらが発生します)。
SequenceNumberMismatch
予期しない DD シーケンス番号
「I」ビットが予期せずに設定される
オプション フィールドが、DBD パケットで受信した最後のオプション フィールドと異なっている
BadLSReq
交換プロセス中に、近隣ルータが認識できない LSA を送信しました。
交換プロセス中にネイバールータが LSA を要求したが、それが見つからない
OSPF でネイバールータが形成されない場合、問題のトラブルシューティングのためには、物理メディアやネットワーク ハードウェアなど、上記の要因を考慮してください。