内容

概要

前提条件

要件

使用するコンポーネント

表記法

背景説明

exstart 状態

exchange 状態

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

解決方法

関連情報

概要

このドキュメントでは、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パケットの交換時に使用する初期データベース記述子(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を実行しようとすると最も頻繁に発生します。この問題が発生するのは、MTU（最大伝送ユニット）が neighboring ルータインターフェイスが一致しません。MTUの大きいルータが、隣接ルータで設定されているMTUよりも大きいパケットを送信すると、隣接ルータはそのパケットを無視します。この問題が発生した場合は、show ip ospf neighbor コマンドは、次の図に示すような出力を表示します。

ルータ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]

この時点で、ルータ6は引き続きルータ7からの初期DBDパケットの確認応答を試行します。

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 決定すると、ルータ7はルータIDが高いためプライマリとして選出されます。ステップ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は、ルータ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 不一致の検出機能が導入されています。この検出には、OSPFRFC 2178、付録G.9に従ってDBDパケットでインターフェイスMTUをアドバタイズするOSPFが含まれます。ルータが受信できるMTUよりも大きいDBDパケットをアドバタイズすると、ルータはDBDパケットを無視し、ネイバー状態はExstartのままになります。これにより隣接関係が形成されなくなります。この問題を解決するには、リンクの両端で MTU を等しくする必要があります。

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

ファイバ分散データインターフェイス(FDDI)ポート

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

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

- MTU の不一致

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

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

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

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

- NATはルータ上で動作し、ユニキャストパケットを変換します。

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

- 両方のルータのRouter-IDが同じである（設定ミス）。

さらに、OSPFRFC 2328のセクション10.3には、Exstart/Exchangeプロセスが次のいずれかのイベントに対して開始されることが記載されています（これらはいずれも内部ソフトウェアの問題が原因である可能性があります）。

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

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

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

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

- BadLSReq

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

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

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

関連情報

- OSPF ネイバーの状態

- OSPF ネイバーの問題について

- テクニカルサポート - Cisco Systems