OSPFネイバーとは何か

OSPFルーターは、直接接続されたすべてのルーターと無条件に経路情報を交換するわけではありません。 まずHelloパケットを使って相手を発見し、設定条件が一致しているかを確認します。

その後、必要な相手とはリンクステートデータベースを同期します。 データベース同期まで完了した状態が、一般にFullです。

ネイバーとアジャセンシーの違い

OSPFネイバー確立に必要な主な条件

Helloパケットが届くだけでは、必ずFullになるとは限りません。 両ルーター間で複数の条件が一致、または互換性のある状態になっている必要があります。

DownからFullまでの状態遷移

OSPFネイバーの状態は、相手をまだ認識していないDownから始まり、 Helloによる双方向確認、データベース概要の交換、必要なLSAの同期を経てFullへ進みます。

各状態を一つずつ確認する

ネイバー確立で使う5種類のOSPFパケット

OSPFはIPプロトコル番号89を使用し、目的に応じて5種類のパケットを使い分けます。

OSPFネイバーが確立するまでの通信

R1とR2がEthernetで直結され、両方のインターフェースでOSPFが有効になった場合を考えます。

1. 両ルーターがHelloを送信する R1とR2は、OSPFが有効なインターフェースからHelloパケットを送信します。 Broadcastネットワークでは、通常224.0.0.5宛てのマルチキャストが使われます。
2. 相手のHelloを受信してInitになる R1がR2のHelloを初めて受信すると、R2をネイバーとして登録します。 ただし、受信したHelloのNeighbor欄にR1自身のRouter IDがなければInitです。
3. 自分のRouter IDが相手のHelloへ掲載され、2-Wayになる R2がR1を認識すると、R2のHelloにR1のRouter IDが含まれます。 R1がそれを確認すると、Helloが双方向に届いていると判断します。
4. 隣接関係をFullまで進める相手を決める Point-to-Pointでは通常、相手と隣接関係を進めます。 BroadcastではDR・BDRとの関係に応じて、2-Wayのまま維持する相手とFullへ進む相手が分かれます。
5. ExStartでDBD交換の準備をする Router IDなどを基にMaster／Slaveを決め、DBDのシーケンス番号を調整します。 ここではLSDBの内容そのものではなく、交換手順を確立します。
6. ExchangeでDBDを交換する 両ルーターは、自分が保有するLSAのヘッダー情報をDBDで通知します。 相手の一覧を見て、自分に不足しているLSAを判断します。
7. Loadingで不足LSAを同期する 不足しているLSAをLSRで要求し、相手がLSUで送信します。 受信側はLSAckを返し、必要な情報がそろうまで同期します。
8. 同期完了後にFullになる 必要なLSAを受信し、LSDBの同期が完了するとFull状態になります。 以後はHelloで生存確認し、トポロジー変更時にLSAを更新します。

R1                                                    R2
 |                                                     |
 |---------------- Hello ----------------------------->|  Down → Init
 |<--------------- Hello（Neighbor: R1）---------------|  Init → 2-Way
 |                                                     |
 |<============== DBD / DBD ==========================>|  ExStart → Exchange
 |---------------- LSR ------------------------------->|  不足LSAを要求
 |<--------------- LSU -------------------------------|  LSAを受信
 |---------------- LSAck ----------------------------->|  受信確認
 |                                                     |
 |======================== Full ========================|

DR・BDRと2-Wayの関係

複数ルーターが同じEthernetセグメントへ接続されるBroadcastネットワークでは、 すべてのルーター同士がFullになると隣接関係が増え、LSA交換も複雑になります。

そこでOSPFは、代表ルーターとしてDR、待機系としてBDRを選出します。 DROTHERルーターはDR・BDRとはFullになりますが、DROTHER同士は通常2-Wayのままです。

                         ┌─────────────┐
                         │ R1：DR      │
                         └──────┬──────┘
                                │ Full
              Full              │              Full
        ┌───────────────────────┼───────────────────────┐
        │                       │                       │
┌───────┴───────┐      ┌────────┴───────┐      ┌────────┴───────┐
│ R2：BDR       │      │ R3：DROTHER    │      │ R4：DROTHER    │
└───────────────┘      └────────┬───────┘      └────────┬───────┘
                                └────── 2-Way ──────────┘

基本構成とCisco IOSの設定例

R1とR2を/30のネットワークで接続し、Area 0でOSPFネイバーを確立する例です。 OSPFプロセスIDは、意図的にR1とR2で異なる値にしています。

R1の設定例

R1(config)# interface GigabitEthernet0/0
R1(config-if)# ip address 192.168.12.1 255.255.255.252
R1(config-if)# no shutdown
R1(config-if)# exit

R1(config)# router ospf 10
R1(config-router)# router-id 1.1.1.1
R1(config-router)# network 192.168.12.0 0.0.0.3 area 0

R2の設定例

R2(config)# interface GigabitEthernet0/0
R2(config-if)# ip address 192.168.12.2 255.255.255.252
R2(config-if)# no shutdown
R2(config-if)# exit

R2(config)# router ospf 20
R2(config-router)# router-id 2.2.2.2
R2(config-router)# network 192.168.12.0 0.0.0.3 area 0

show ip ospf neighborの読み方

OSPFネイバーの確認で最初に使用する代表的なコマンドがshow ip ospf neighborです。

R1# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           1   FULL/DR         00:00:34    192.168.12.2    GigabitEthernet0/0

State欄の代表例

関連して確認するコマンド

show ip ospf interface brief
show ip ospf interface GigabitEthernet0/0
show ip ospf
show ip protocols
show ip ospf database
show ip route ospf
show interfaces GigabitEthernet0/0

Helloパケットで確認する項目

WiresharkやパケットキャプチャーでHelloを見ると、ネイバー条件の不一致を直接確認できます。 OSPFv2ではIPプロトコル番号89が使われます。

状態別に見るOSPFネイバー障害の切り分け

障害切り分けでは、設定を上からすべて見直すよりも、現在の状態を起点に確認範囲を絞る方が効率的です。

基本的な確認順序

1. 物理・インターフェース状態を確認する 両端のインターフェースがup/upか、エラーやフラップがないかを確認します。
2. IPアドレスと直接疎通を確認する 同一リンクの相手IPへpingし、サブネットマスクやVLANも確認します。
3. OSPFが対象インターフェースで有効か確認する network文、インターフェース直接設定、passive-interfaceを確認します。
4. 現在のネイバー状態を確認する show ip ospf neighborで停止状態と相手Router IDを確認します。
5. 両端のOSPFインターフェース条件を比較する Area、Hello/Dead、Network Type、認証、MTU、Priorityを照合します。
6. ログとパケットを確認する 状態遷移、認証エラー、MTU問題、HelloやDBDの送受信を確認します。
7. Full後はLSDB・経路表・実通信へ進む ネイバーが正常なら、LSAの有無、経路選択、戻り経路、ACLなどを確認します。

ExStartで止まるMTU不一致の例

R1# show interfaces GigabitEthernet0/0 | include MTU
  MTU 1500 bytes, BW 1000000 Kbit/sec

R2# show interfaces GigabitEthernet0/0 | include MTU
  MTU 1400 bytes, BW 1000000 Kbit/sec

Helloは交換できるため2-Wayまでは進みますが、DBD交換時にMTU情報が問題となり、 ExStartやExchangeを繰り返すことがあります。原則として両端のMTUを正しく統一します。

デバッグコマンドの利用

debug ip ospf hello
debug ip ospf adj
undebug all

設計・運用で押さえる注意点

顧客・上司へ伝える調査結果の例

「OSPFが上がりません」だけでは、確認状況や影響が伝わりません。 現在の状態、確認済み項目、原因候補、次の対応を分けて報告します。

英語ログ・資料でよく使う表現

OSPFネイバーに関するよくある勘違い

自分の言葉で説明する課題