はじめに
OSPF は大規模ネットワークでも安定して動作するプロトコルですが、一度トラブルが発生すると原因の特定に時間がかかることがあります。「ネイバーが上がらない」「ルート情報が学習されない」といった事象に直面したとき、設定をやみくもに変更すると、かえって状況を悪化させることがあります。
トラブルシューティングの基本は、下位レイヤから順に疑うことです。OSPF の複雑なパラメータ（LSA タイプなど）を疑う前に、まずは物理結線やインターフェースのステータス（Layer 1）、Ping の疎通（Layer 2/3）を確認します。下位の通信が成立していなければ、OSPF は動作しません。
本記事では、基本的な疎通確認が取れていることを前提に、OSPF のネイバーが確立できない原因を状態別に切り分ける手順を解説します。OSPF の基本動作は関連記事『OSPF とは｜仕組みを図解で理解する LSA・エリア・コストの基礎』、Cisco ルーターでの設定手順は関連記事『Cisco ルーターでの OSPF 設定手順とマルチエリア構成のコンフィグ例』で解説しています。
- 切り分けフロー: 物理 → ネイバー → ルートの確認順序
- 状態別の原因: INIT・EXSTART・EXCHANGE・2WAY で止まる原因
- 一致が必要な項目: タイマー・エリア ID・MTU・認証などの確認ポイント
- syslog の読み解き: ネイバーダウンや認証失敗などのログの意味
- ルート未学習: ネイバーは FULL なのに経路が載らない原因
ネイバーが確立できない場合は、まず show ip ospf neighbor の状態（INIT・EXSTART・2WAY・FULL）で原因を絞り込みます。ネイバー確立には Hello / Dead タイマー、エリア ID、ネットワークタイプ、サブネット、認証、MTU などの一致が必要で、これらの不一致が主な原因です。状態と一致条件を対応づけて確認することが、早期解決につながります。
トラブルシューティングの全体フロー
OSPF のトラブルは、大きく分けて「隣接関係（ネイバー）の問題」か「経路情報（LSA）の問題」のどちらかです。以下のフローに従って、現在の状況がどこで止まっているかを確認します。
本記事の切り分けの考え方はベンダーに依存しません。確認コマンドは Cisco IOS を主な例としますが、FortiGate・YAMAHA・NEC など他機種でも確認すべきポイント（タイマー、エリア ID、MTU、認証の一致など）は共通です。機種ごとの確認コマンドは、各機種の設定記事を参照してください。
まず確認すべきコマンド（show ip ospf neighbor）
トラブルシュートの第一歩は、show ip ospf neighbor です。「対向ルーターが表示されるか」「State（状態）が何か」を確認することで、多くの原因をこの出力から絞り込めます。
Router# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
192.168.1.2 1 FULL/DR 00:00:35 10.0.0.2 GigabitEthernet0/0
192.168.1.3 1 2WAY/DROTHER 00:00:32 10.0.0.3 GigabitEthernet0/0
192.168.1.4 1 INIT/DROTHER 00:00:31 10.0.0.4 GigabitEthernet0/0この出力では、192.168.1.2 とは正常（FULL）、192.168.1.3 とは DROTHER 同士で正常（2WAY）、192.168.1.4 とは INIT で停止しており確認が必要、と読み取れます。
ネイバーの状態遷移（Down から Full まで）
OSPF の隣接は、複数の状態を経て FULL（完全な隣接）に至ります。どの状態で停止しているかが、原因の切り分けに直結します。
参考: Cisco「Understand OSPF Neighbor States」
“The states are Down, Attempt, Init, 2-Way, Exstart, Exchange, Loading, and Full.”
（状態は Down、Attempt、Init、2-Way、Exstart、Exchange、Loading、Full です。）
https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13685-13.html
| 状態 | 意味 | 補足 |
|---|---|---|
| Down | Hello を 1 つも受信していない初期状態 | 既存の隣接では Dead 満了で Down に戻る |
| Attempt | 手動指定した隣接へ Hello を送信中 | NBMA でのみ使用 |
| Init | 相手の Hello を受信したが、自分の RID がまだ含まれない（片方向） | ケース①で詳述 |
| 2-Way | 双方向を確認（自分の RID が相手の Hello に含まれる）。マルチアクセスでは DR/BDR を選出 | DROther 同士はここで停止（正常） |
| ExStart | マスター/スレーブと初期シーケンス番号を決定（RID が大きい側がマスター） | MTU 不一致で停止しやすい |
| Exchange | DBD を交換し LSDB の概要を共有 | MTU 不一致で停止しやすい |
| Loading | 不足している LSA を要求（LSR） | |
| Full | LSDB が同期し、隣接が完成した状態 | 目標とする状態 |
INIT や 2WAY で止まる場合はケース①、EXSTART / EXCHANGE で止まる場合はケース②（MTU 不一致）を確認します。
正常な状態（FULL / 2WAY）の見分け方
OSPF が正常に稼働している場合、State カラムは次のいずれかになります。
FULL:
ネイバーとの LSA 同期が完了した状態。これが基本の正常状態です。Loading など FULL 以外で停止している場合は異常です。
2WAY:
双方向の通信はできているが、LSA の同期は行わない関係です。ブロードキャストネットワーク（Ethernet）上の DROther 同士であれば、この表示で正常です。
2WAY/DROTHER はエラーではない点に注意が必要です。DROther 同士は DR / BDR を介して情報を交換するため、直接 FULL になる必要はありません。一方で、DR / BDR との間でも 2WAY のまま FULL に進まない場合は、後述の DR/BDR 選出やケース②の問題が疑われます。これら以外の状態（INIT・EXSTART・EXCHANGE 等）で停止している場合や、ネイバーがそもそも表示されない場合は、次章以降を確認します。
ネイバー確立に一致が必要な項目
OSPF の隣接は、複数のパラメータが両端で一致していないと確立できません。1 つでも不一致があると隣接は成立しないため、まず以下の項目を確認します（参考: Cisco「Troubleshoot OSPF Neighbor Problems」 https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13699-29.html ）
| 項目 | 一致条件 | 不一致時の主な症状 |
|---|---|---|
| Hello / Dead タイマー | 両端で同じ値 | ネイバー不可（INIT または非表示） |
| エリア ID | 接続インターフェース同士で同じ | ネイバー不可 |
| ネットワークタイプ | broadcast / point-to-point 等が整合 | ネイバー不可、またはルート不整合 |
| サブネット / マスク | 同一サブネット上にある | ネイバー不可 |
| 認証（タイプ・鍵・Key ID） | すべて一致 | ネイバー不可 |
| MTU | 両端で同じ値 | EXSTART / EXCHANGE で停止 |
| エリアフラグ（スタブ等） | エリア種別が整合 | ネイバー不可 |
| ルーター ID | 重複していないこと（一致ではなく相違が必要） | 隣接の不安定・エラーログ |
これらのうち、ルーター ID だけは「一致」ではなく「重複しないこと」が条件です。同一の RID が複数のルーターに設定されていると、隣接が不安定になったりエラーログが出力されたりします。次章からは、各症状の確認手順を具体的に見ていきます。
ケース① ネイバーが確立しない（一覧に表示されない / INIT）
show ip ospf neighbor を実行しても何も表示されない、または INIT 状態から進まない場合、ルーター同士が互いを正しく認識できていない状態です。以下の 5 つのチェックポイントを順に確認します。
1. 物理層・L2 の疎通不可
OSPF のトラブルシューティングでも、最初に確認するのは物理層です。インターフェースが down していたり、IP アドレスの設定ミスで Ping が通らなければ、OSPF の Hello パケットも届きません。
インターフェースの状態確認: show ip interface brief で Status / Protocol が両方 up になっているか確認する。
直結対向への Ping: ping <対向の IP アドレス> が通るか確認する。これが通らない限り、OSPF 設定の見直しは効果がありません。
2. Hello / Dead タイマーの不一致
OSPF では、隣接するルーター間で Hello Interval と Dead Interval が一致している必要があります。片側だけタイマーを変更していると、ネイバーは確立しません。
Router# show ip ospf interface GigabitEthernet0/0
...
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5出力内の Hello 10, Dead 40（既定値）が、対向ルーターの出力と一致しているか確認します。
3. エリア ID の不一致
接続しているインターフェース同士は、同じエリア ID に所属している必要があります。片方が Area 0、もう片方が Area 1 だと、Hello パケットは無視されます。
Router# show ip ospf interface GigabitEthernet0/0
...
Internet Address 10.0.12.1/30, Area 0Area 0 の部分が対向と一致しているか確認します。サブネットマスクの計算違いで、意図せず別の network コマンドにマッチしているケースもあるため、あわせて確認します。
4. 認証設定の不一致
OSPF 認証（MD5 など）を使用している場合、認証タイプとパスワード（鍵）、鍵番号（Key ID）がすべて一致していないとネイバーになりません。
interface GigabitEthernet0/0
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 <共有鍵>show running-config でインターフェース設定を確認し、認証タイプ（message-digest か null か）、鍵番号、パスワード文字列が対向と一致しているか確認します。
5. passive-interface の設定ミス
passive-interface を設定すると、そのインターフェースでの Hello 送信が停止します（詳細は関連記事『Cisco ルーターでの OSPF 設定手順とマルチエリア構成のコンフィグ例』を参照）ルーター間の接続ポートに誤って passive-interface を設定すると、自分から Hello を送信しないため、ネイバー関係を確立できません。
Router# show running-config | section router ospf
router ospf 1
passive-interface default
no passive-interface GigabitEthernet0/0passive-interface default を使用している場合は、ルーター対向のポートに no passive-interface が設定されているか確認します。
ケース② ステートが途中で止まる（EXSTART / EXCHANGE）
show ip ospf neighbor の State が FULL にならず、EXSTART や EXCHANGE で止まる（あるいは Up/Down を繰り返す）ことがあります。これは、ルーター同士が LSA の同期を試みているものの、途中で失敗している状態です。最も多い原因は MTU（Maximum Transmission Unit）サイズの不一致です。
MTU サイズの不一致
OSPF は、ネイバー確立のプロセス（EXSTART 状態）で、お互いのインターフェース MTU を確認し合います。両端の MTU が 1 バイトでも異なると、OSPF はネイバー確立を中断します。次のような環境で発生しやすくなります。
- VPN / トンネル環境: IPsec や GRE のオーバーヘッドにより、片側だけ MTU が小さい。
- 異機種接続: Cisco と他社製ルーターで MTU の計算方法（ヘッダーを含むか）が異なる。
- スイッチ経由: 間の L2 スイッチがジャンボフレーム設定で、ルーター側は既定（1500）のまま。
各インターフェースで MTU 値を確認します。
Router# show ip interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
Internet address is 10.0.0.1/30
...
MTU is 1500 bytes参考: Cisco「Troubleshoot OSPF Neighbors Stuck in Exstart/Exchange State」
“the solution is to change either router MTU to match the neighbor MTU”
（解決策は、いずれかのルーターの MTU を対向の MTU に合わせることです。）
https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13684-12.html
ip ospf mtu-ignore による回避策と注意点
最も適切な解決策は、ip mtu <サイズ> で両端の MTU を合わせることです。しかし、キャリア回線の仕様や対向機器の制限で MTU を変更できない場合、回避策として MTU チェックを無効化するコマンドがあります。
Router(config)# interface GigabitEthernet0/0
Router(config-if)# ip ospf mtu-ignoreこれにより、MTU が不一致でもネイバーを FULL まで進められます。ただし、このコマンドは MTU チェックを無視するだけで、物理的なパケットサイズ制限を解決するものではありません。次のリスクを理解した上で使用してください。
大きな LSA の消失:
経路情報（LSA）が増えてパケットサイズが大きくなった際、実際の回線 MTU を超えると、パケットが破棄される可能性があります。
見かけ上の FULL:
ステータスは FULL でも、上記の理由で一部の経路情報が欠落し、データベースが同期できないという切り分けの難しい状態に陥る可能性があります。
ip ospf mtu-ignore は最終手段と位置づけ、可能な限り物理的な MTU 設計を見直して値を一致させることが推奨されます。
主要な syslog メッセージの読み解き
ネイバーの不安定やダウンは、ログにも記録されます。代表的なメッセージと、その原因・確認の方向性を整理します。メッセージ内の <> は環境ごとの値（プロセス ID、隣接 IP、インターフェース等）に置き換わります。
参考: Cisco「What Do %OSPF-4-ERRRCV Error Messages Mean?」
“make sure that both sides have the same area ID”
（両側が同じエリア ID を持つように設定してください。）
https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/6154-19.html
| ログメッセージ（要部） | 主な原因 | 確認・対処 |
|---|---|---|
%OSPF-5-ADJCHG: ... from FULL to DOWN, Neighbor Down: Dead timer expired | Dead 時間内に Hello を受信できず隣接が切断。物理障害・輻輳・タイマー不一致・高 CPU など | L1/L2 の安定性、show ip ospf interface のタイマー、回線品質を確認 |
%OSPF-5-ADJCHG: ... from EXSTART to DOWN, Neighbor Down: Too many retransmissions | DBD 交換の再送多発。MTU 不一致やパケットロス | 両端の MTU、回線のパケットロスを確認（ケース②参照） |
%OSPF-4-ERRRCV: Received invalid packet: mismatch area ID ... | 接続インターフェースのエリア ID 不一致 | 両端の network ... area 指定が同じエリアか確認 |
%OSPF-4-ERRRCV: Received invalid packet: mismatched hello parameters ... | Hello / Dead タイマーの不一致 | 両端のタイマー値を確認（ケース①参照） |
%OSPF-4-ERRRCV: Received invalid packet: mismatched authentication ... | 認証タイプ・鍵・Key ID の不一致 | 両端の認証設定を確認（ケース①参照） |
%OSPF: OSPF not enabled on <インターフェース> | 対象インターフェースが OSPF に参加していない | network 文 / ip ospf area の対象に含まれているか確認 |
ログのメッセージ種別（ADJCHG は隣接状態の変化、ERRRCV は受信パケットの不正）と末尾の理由文字列から、ケース①〜③のどれを確認すべきかを判断できます。
ケース③ ネイバーは FULL だがルートが学習されない
show ip ospf neighbor は FULL なのに、show ip route ospf で目的の経路が表示されない場合、隣接は確立しているものの、LSA が正しく処理されていない状態です。主に次の原因が考えられます。
1. ネットワークタイプの不一致
イーサネットやトンネルインターフェースで、OSPF が認識するネットワークタイプが対向と一致していないと、LSA の解釈やネクストホップの解決で不整合が起き、経路がインストールされないことがあります。タイマーを無理に合わせてネイバーが FULL になっていても、サブネットマスクの扱いや Next Hop で不整合が残るケースがあります。
Router# show ip ospf interface Tunnel0
...
Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 1000両端のネットワークタイプを確認し、必要に応じて明示的に合わせます。
Router(config-if)# ip ospf network point-to-point2. ワイルドカードマスクの指定ミス（広報漏れ）
「隣のルーターへの経路」は学習できるのに「その奥の LAN 側ネットワーク」が学習できないケースです。これは、LAN 側インターフェースを network コマンドで宣言し忘れていることが原因です。
Router_Target# show running-config | section router ospf
router ospf 1
network 10.0.12.0 0.0.0.3 area 0
! network 192.168.10.0 0.0.0.255 area 0 <- これが抜けているOSPF は network コマンドで指定したインターフェースのネットワークだけを広報します。LAN 側のネットワークも宣言されているか確認します。
3. DR/BDR 選出の問題（Priority 0 同士）
ブロードキャスト環境では DR を選出する必要があります。すべてのルーターの OSPF プライオリティを 0 にすると、DR が選出されず、LSA の同期が行われません。
Router# show ip ospf interface GigabitEthernet0/0
...
State DROTHER, Priority 0
Designated Router (ID) 0.0.0.0, Interface address 0.0.0.0Designated Router (ID) 0.0.0.0 は DR が存在しないことを示します。セグメント内の全員が 2WAY で止まっている場合は異常です。少なくとも 1 台のプライオリティを 1 以上に戻し、DR が選出されるようにします。
Router(config-if)# ip ospf priority 14. 戻りの通信・非対称経路
「ルーターからは Ping が通るのに、配下の PC からは通らない」という場合、往路は届いているが復路（戻り経路）が確立していない可能性があります。多くは、対向ルーターで戻り先のネットワークが広報されていない（上記の広報漏れ）か、片方向だけコストを調整したことによる非対称が原因です。経路は往復の両方向で成立している必要があるため、双方のルーターで該当ネットワークが広報されているか、コスト調整が両端で整合しているかを確認します。
OSPFv3（IPv6）での違い
IPv6 を扱う OSPFv3 でも、隣接の状態遷移や一致が必要な項目（タイマー・エリア ID・MTU 等）の考え方は OSPFv2 と共通です。一方で、設定と隣接の確認方法には次の違いがあります。
- 有効化はインターフェース単位で行い、
networkコマンドを使いません。 - 隣接は IPv6 のリンクローカルアドレス（fe80::/10）で確立します。
- 状態確認は
show ipv6 ospf neighbor（またはshow ospfv3 neighbor）を使用します。
「OSPFv3 で network コマンドがない」「隣接が確立しない」という場合は、インターフェースに OSPFv3 が有効化されているか、リンクローカルアドレスが付与されているかを確認します。
よく使う確認コマンド
個別のケースに加えて、状況が分からないときに役立つコマンドを 2 つ紹介します。
show ip ospf interface（パラメータ確認）
OSPF のトラブルシューティングで最も情報量が多いコマンドです。ネイバーが上がらない原因の多く（エリア ID、タイマー、ネットワークタイプ、認証など）は、この出力で確認できます。
Router# show ip ospf interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
Internet Address 10.0.12.1/30, Area 0
Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 1
Transmit Delay is 1 sec, State DR, Priority 1
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
...
Neighbor Count is 1, Adjacent neighbor count is 1設定ファイル（show running-config）を眺めるよりも、ルーターが実際にどう認識しているかをこのコマンドで確認するほうが、原因特定の近道になります。
debug ip ospf adj（リアルタイム解析）
show コマンドが現在の状態を表示するのに対し、debug コマンドはリアルタイムの処理をログとして出力します。adj（adjacency）オプションは、ネイバー確立のプロセス（Hello 受信 → 2WAY → EXSTART …）を追跡できます。
Router# debug ip ospf adj
OSPF adjacency events debugging is on
OSPF-1 ADJ Gi0/0: Send DBD to 2.2.2.2 seq 0x1 opt 0x52 flag 0x7 len 32
OSPF-1 ADJ Gi0/0: Retransmitting DBD to 2.2.2.2 [1]ここで「Retransmitting（再送）」が繰り返されていたり、「Mismatched hello parameters」などのエラーが出ていれば、そこが原因です。
注意: debug コマンドはルーターの CPU に高い負荷をかけます。ネイバーが多数存在するコアスイッチやルート変動が激しい環境で実行すると、コンソールがログで埋まり、操作が困難になる（最悪の場合ルーターがハングアップする）可能性があります。
- 用が済んだら即座に
undebug all（またはu all）で停止する。 - 業務時間中の実行は避け、メンテナンス時に限定する。
まとめ
OSPF のトラブルは、まず下位レイヤの疎通を確認し、show ip ospf neighbor の状態で原因を絞り込むのが基本です。ネイバー確立にはタイマー・エリア ID・MTU・認証などの一致が必要で、状態とログメッセージから原因の所在を判断できます。FULL でもルートが載らない場合は、ネットワークタイプや広報漏れ、DR 選出を確認します。
- 物理・L2/L3 の疎通を最初に確認する切り分けの順序
- INIT・非表示はタイマー・エリア ID・認証・passive の確認
- EXSTART / EXCHANGE 停止は MTU 不一致の確認
- FULL でもルート未学習はネットワークタイプ・広報漏れ・DR 選出
- syslog の種別と理由文字列からの原因の絞り込み
- show ip ospf interface での一致条件の一括確認
- debug ip ospf adj は負荷に注意して短時間で使用
以上、最後までお読みいただきありがとうございました。
