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

はじめに

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

前提条件

要件

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

使用するコンポーネント

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

• Cisco 2503 ルータ

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

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

表記法

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

背景説明

OSPFは隣接関係(adjacency)を形成するための状態で、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 状態

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

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

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

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

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

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

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パケットを送信します。プライマリ/下位が決定された後、ルータIDが大きいためルータ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が下位として、ルータ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に従っています。アドバタイズされたDBDパケット（ルータで受信可能なMTUよりも大きいMTU）をルータが受信すると、ルータはそのDBDパケットを無視し、ネイバー状態はExstartのままになります。これにより隣接関係が形成されなくなります。この問題を解決するには、リンクの両端で MTU を等しくする必要があります。

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

上の図は、Route Switch Module（RSM；ルートスイッチモジュール）を搭載したCisco Catalyst 5000のFiber Distributed Data Interface（FDDI；ファイバ分散データインターフェイス）ポートが、ルータ2の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がネイバーを形成しない場合、問題をトラブルシューティングするには、物理メディアやネットワークハードウェアなど、前述の要因を考慮します。

関連情報

• OSPFネイバーの状態について
• OSPF ネイバーの問題のトラブルシューティング
• シスコのテクニカルサポートとダウンロード