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(Database Descriptor)シーケンス番号を決定します。

exchange 状態

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

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

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

この問題は、Ciscoルータと他のベンダーのルータの間でOSPFを実行しようとするときに最も頻繁に発生します。この問題は、neighboringルータインターフェイスの最大伝送ユニット(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パケットの確認応答を試行し続けます。

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パケットを送信します。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は、Router 6が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不一致の検出が導入されています。この検出には、インターフェイスのMTUをDBDパケットでアドバタイズする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インターフェイスでOSPFによるMTU不一致の検出を停止し、隣接関係を形成するのに便利です。

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 ネイバーの問題のトラブルシューティング
• シスコのテクニカルサポートとダウンロード