OSPF の不具合は、「ネイバー（隣接）が Full にならない」か「隣接は Full なのに経路が載らない」かの2つに大きく分かれます。前者はネイバーがどの状態で止まっているかを見れば原因の候補が数個に絞れ、後者は LSA データベースとエリアの設計を見ていきます。この記事では、状態ごとの原因と確認方法、直し方を起きやすい順に説明します。コマンドは Linux で使われる FRRouting（vtysh）と Cisco IOS を例にしますが、ほかの機器でも確認する項目は同じです。
設定の変更は隣接の張り直しを伴い、経路が一時的に消えることがあります。変更前に設定を保存し、影響の少ない時間帯に、可能であれば検証環境で手順を確かめてから行ってください。
最初に見るコマンド
# FRRouting（vtysh 内で実行。Cisco IOS でも同名のコマンドがほぼ使える）
show ip ospf neighbor
show ip ospf interface
show ip ospf database
show ip route ospfshow ip ospf neighbor でネイバーが一覧に出るか、出るならどの状態か、を最初に確認します。一覧に出ない場合は、Hello パケットが互いに届いていないか、届いても受け入れられていません。
隣接の変化を記録しておくと、不安定な隣接の調査に役立ちます。FRRouting では router ospf の設定に log-adjacency-changes detail を入れると、状態の遷移がログに残ります。
状態の流れと、止まる場所の意味
OSPF のネイバーは、おおむね Down → Init → 2-Way → ExStart → Exchange → Loading → Full と進みます。止まっている状態から、原因の見当がつきます。
- 一覧に出ない／Down：Hello が届いていない
- Init：相手の Hello は届くが、相手は自分の Hello を受け取っていない（片方向）
- 2-Way：ブロードキャスト型のネットワークでは、DR・BDR 以外のルーター同士の正常な状態
- ExStart／Exchange で止まる：データベースの交換に失敗している（MTU の不一致が代表例）
- Full と Down を繰り返す：Hello の間隔、回線品質、CPU 負荷、ルーター ID の重複など
原因1：Hello が届かない（ネイバーが出ない・Init のまま）
確認
インターフェースで OSPF が有効か、passive になっていないかを show ip ospf interface で確認します。passive にしたインターフェースでは Hello を送らないため、隣接は張れません。
Linux で動かしている場合は、ファイアウォールを疑います。OSPF は TCP や UDP ではなく IP プロトコル番号 89 を使い、Hello はマルチキャストの 224.0.0.5（DR・BDR 宛ては 224.0.0.6）に送られます。ポート番号を許可するルールでは通りません。
# OSPF のパケットが届いているかを確認
sudo tcpdump -ni eth1 ip proto 89クラウドの仮想ネットワークではマルチキャストが使えないことが多く、その場合は相手を明示する設定（ネットワークタイプを point-to-point や non-broadcast にする、ネイバーを手で指定する）が要ります。対応状況はサービスごとに違うため、利用中のクラウドのドキュメントで確かめてください。
Init で止まる場合は、片方向でしか届いていません。相手側でも tcpdump を取り、自分の Hello が届いているか、届いていても破棄されていないかを確認します。
原因2：Hello の中身が一致しない
Hello は届いていても、次の値が両側で一致しないと受け入れられません。
- エリア ID
- Hello 間隔と Dead 間隔
- 認証の方式と鍵
- サブネットマスク（ブロードキャスト型や NBMA のネットワーク。ポイントツーポイントでは検査されないのが一般的）
- エリアの種類（stub かどうかなどの設定）
show ip ospf interface で両側の値を並べて見比べるのが確かです。FRRouting では、debug ospf packet hello などのデバッグを有効にすると、不一致で破棄した理由がログに出ます。デバッグは出力が多いため、確認が終わったら無効にしてください。
Hello と Dead の間隔は、片方だけ変えると隣接が切れます。変更するときは、両側に同じ値を入れてから反映します。
原因3：MTU の不一致（ExStart／Exchange で止まる）
ExStart や Exchange から進まない場合、もっとも多いのはインターフェースの MTU の不一致です。OSPF はデータベースの記述（DBD）パケットに MTU の値を入れており、相手の MTU が自分より大きいと受け入れません。トンネルや VLAN、ジャンボフレームを使う構成で起きやすい問題です。
確認と直し方
# Linux 側のインターフェースの MTU
ip link show dev eth1両側の MTU を同じ値に揃えるのが本来の直し方です。ip ospf mtu-ignore をインターフェースに設定すると MTU の検査を省けますが、実際に大きなパケットが通らない状態を隠すことになるため、一時的な回避にとどめます。
原因4：ルーター ID の重複（隣接や経路が不安定）
ルーター ID が重複すると、同じ ID の LSA が互いに上書きされ、経路が出たり消えたりします。機器の設定を複製して増設したときに起きやすい問題です。show ip ospf で各ルーターのルーター ID を確認し、重複していればループバックのアドレスなどを使って一意の値を明示的に設定します。ルーター ID の変更は、OSPF プロセスの再起動など、機器ごとに決まった方法で反映が要ります。
原因5：隣接は Full なのに経路が載らない
LSA が届いているか
show ip ospf database で、目的のネットワークを表す LSA が届いているかを確認します。届いていなければ、広報する側の設定を見直します。
- 広報したいネットワークで OSPF が有効になっているか（
network文の範囲、またはインターフェース単位の設定） - 再配布（redistribute）の設定とフィルター
- エリアの境界（ABR）での集約やフィルター
LSA はあるがルーティングテーブルに入らない
- 同じ宛先を、より優先度の高い経路（静的経路、ほかのプロトコル）が持っていないか。
show ip routeで宛先を指定して確認します - エリア 0（バックボーン）に接していないエリアが孤立していないか。OSPF ではエリア間の経路はバックボーンを経由するため、バックボーンにつながっていないエリアの経路は他エリアに伝わりません
- stub エリアや NSSA では、外部経路が意図的に入らないことを確認します
Linux のカーネルに経路が入らない
FRRouting の show ip route には載っているのに、ip route には出ない場合は、zebra とカーネルの連携を確認します。FRRouting のログに経路の登録の失敗が出ていないか、ほかのソフトウェアが同じ経路を管理していないかを見ます。
不安定な隣接の切り分け
Full と Down を繰り返す場合は、隣接が落ちた時刻と理由をログで確認します。Dead 間隔のタイムアウトで落ちているなら、Hello が途中で失われています。回線の損失や、ルーターの CPU 負荷が高くて Hello の処理が遅れていないかを確かめます。仮想マシンでは、ホスト側の負荷で一時的に処理が止まることもあります。
障害の検知を速めたい場合、Hello 間隔を極端に短くするよりも、BFD を併用するほうが一般的です。FRRouting でも BFD のデーモンが用意されています。対応状況は機器や版によるため、導入前に確認してください（2026年10月現在）。
まとめ
- まず
show ip ospf neighborで状態を確認し、止まっている状態から原因を絞ります。 - 一覧に出ない・Init は Hello が届いていないことが多く、passive の設定と、IP プロトコル 89・マルチキャストを通すファイアウォールを確認します。
- Hello の中身（エリア、間隔、認証、サブネット、エリアの種類）は両側で一致が要ります。ExStart・Exchange で止まるなら MTU を揃えます。
- Full なのに経路が載らないなら、LSA の有無、より優先度の高い経路、バックボーンとのつながりを順に確認します。
- 変更は隣接の張り直しを伴うため、設定を保存し、影響の少ない時間帯に行います。