OSPF トラブルシューティング | ネイバー確立と経路情報の切り分け

URLをコピーしました！

はじめに

OSPF は大規模ネットワークでも安定して動作する堅牢なプロトコルですが、一度トラブルが発生すると原因の特定に時間がかかることがあります。「ネイバーが上がらない」「ルート情報が降りてこない」といった事象に直面した際、闇雲に設定を変更するのは危険です。

トラブルシューティングの基本は 「下位レイヤから疑う」 ことです。いきなり OSPF の複雑なパラメータ（LSA タイプなど）を疑う前に、まずは物理結線やインターフェースのステータス（Layer 1）、Ping の疎通（Layer 2/3）を確認しましょう。土台となる通信ができていなければ、OSPF は動きません。

本記事では、基本的な疎通確認が取れていることを前提に、OSPF 特有のパラメータ不一致やステートの停止原因を論理的に切り分ける手順を解説します。

なお、OSPF の基本動作や Cisco ルーターでの設定手順については、以下の記事ですでに解説しています。基礎から振り返りたい方は、併せてご参照ください。

トラブルシューティングの全体フロー

OSPF のトラブルは、大きく分けて「隣接関係（ネイバー）の問題」か「経路情報（LSA）の問題」のどちらかです。以下のフローチャートに従って、現在の状況がどこで止まっているかを確認してください。

まず確認すべきコマンド

トラブルシュートの第一歩は、必ず以下のコマンドから始めます。

show ip ospf neighbor

このコマンドで「対向ルーターが表示されるか」「State（状態）が何か」を確認することで、原因の 8 割は特定できます。

実行例

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

正常な状態（FULL または 2WAY）の定義

OSPF が正常に稼働している場合、State カラムは以下のいずれかになります。

FULL

意味: ネイバーとの LSA 同期が完全に完了している状態。
判定: 正常です。これ以外（Loading など）で止まっている場合は異常です。

2WAY

意味: 双方向の通信はできているが、LSA の同期を行わない関係（DROTHER 同士）
判定: 正常です。ブロードキャストネットワーク（Ethernet）上の DROTHER 同士であれば、この表示で問題ありません。エラーではないので注意してください。

これら以外の状態（例：INIT, EXSTART, EXCHANGE）で止まっている場合や、そもそもネイバーが表示されない場合は、次章以降のチェックポイントを確認してください。

ケース① ネイバーが確立しない（一覧に表示されない / INIT）

show ip ospf neighbor を実行しても何も表示されない（Empty）、または INIT 状態から進まない場合、ルーター同士が「お互いを正しく認識できていない」状態です。以下の 5 つのチェックポイントを順に確認してください。

原因

物理層・L2 の疎通不可（Ping すら通らない）

OSPF のトラブルシューティングといえど、最初は 物理層 です。インターフェースが down していたり、IP アドレスの設定ミスで Ping が通らなければ、当然 OSPF の Hello パケットも届きません。

確認手順

STEP

インターフェースの状態確認（show ip interface brief）

Status / Protocol が両方 up になっているか？

STEP

直結対向への Ping（ping <対向の IP アドレス>）

これが通らない限り、OSPF の設定を見直しても無意味です。

原因

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 （デフォルト値）が、対向ルーターの出力と一致しているか確認してください。

原因

エリア ID の不一致

接続しているインターフェース同士は、同じエリア ID に所属している必要があります。片方が Area 0、もう片方が Area 1 と設定されていると、Hello パケットは無視されます。

確認コマンド

Router# show ip ospf interface GigabitEthernet0/0
...
  Internet Address 10.0.12.1/30, Area 0

💡チェックポイント

Area 0 の部分が対向と一致しているか。
よくあるミス：サブネットマスクの計算違いで、意図せず別の network コマンドにマッチしてしまっているケース。

原因

認証設定の不一致（パスワードミス）

OSPF 認証（MD5 など）を使用している場合、認証タイプ と パスワード（Key） が一致していないとネイバーになりません。鍵番号（Key ID）も一致させる必要があります。

確認コマンド

show running-config でインターフェース設定を確認するのが確実です。

interface GigabitEthernet0/0
 ip ospf authentication message-digest
 ip ospf message-digest-key 1 md5 CISCO123  <-- ここを確認

💡チェックポイント

message-digest （MD5）か null （なし）か、タイプは合っているか？
key 1 の番号と、パスワード文字列は完全一致しているか？

原因

Passive-Interface の設定ミス

前回の記事で紹介した passive-interface ですが、これを設定すると Hello パケットの送信を停止 します。ルーター間の接続ポートに誤って passive-interface を設定してしまうと、自分から挨拶しないため、永遠にネイバー関係になれません。

症状

対向ルーターでは、こちらの Hello が来ないので show ip ospf neighbor に何も表示されません。
こちら側では、対向の Hello を受信できる（設定による）場合、相手が INIT として一瞬見えることがありますが、すぐに消えます。

確認コマンドと対処法

Router# show running-config | section router ospf
 router ospf 1
  passive-interface default  <-- これが入っていると全ポート止まる
  no passive-interface GigabitEthernet0/0  <-- uplinkポートは除外が必要！

ルーター間の接続ポートには、必ず 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 と他社製ルーター（Juniper 等）で、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
  Broadcast address is 255.255.255.255
  Address determined by non-volatile memory
  MTU is 1500 bytes  <-- ここが対向と一致しているかチェック！

ip ospf mtu-ignore での回避策と注意点

最も正しい解決策は、ip mtu <サイズ> コマンドで両端の MTU 値を合わせることです。しかし、キャリア回線の仕様や対向機器の制限で、どうしても MTU 設定を変更できない場合があります。

その場合の回避策（ワークアラウンド）として、MTU チェックを無効化 するコマンドがあります。

設定コマンド

MTU が小さい側のルーター（または両方）のインターフェースで設定します。

Router(config)# interface GigabitEthernet0/0
Router(config-if)# ip ospf mtu-ignore

これにより、MTU 値が不一致でも強引にネイバーを FULL まで進めることができます。

💡【重要】注意点とリスク

このコマンドはあくまで「チェックを無視する」だけで、物理的なパケットサイズ制限を解決するわけではありません。以下のリスクを理解した上で使用してください。

巨大な LSA の消失
- OSPF の経路情報（LSA）が増えてパケットサイズが大きくなった際、実際の回線 MTU を超えてしまい、パケットが破棄される 可能性があります。
「見かけ上の FULL」
- コマンドのおかげでステータスは FULL になりますが、上記の理由で一部の経路情報だけが欠落する（Database が同期できない）という、非常にトラブルシュートが難しい状態に陥るリスクがあります。

推奨: ip ospf mtu-ignore は最終手段です。可能な限り、物理的な MTU 設計を見直して値を一致させることを推奨します。

ケース③ ネイバーは FULL だがルートが学習されない

show ip ospf neighbor は FULL になっているのに、show ip route ospf を叩いても目的の経路が表示されない場合、「OSPF の会話はできているが、中身（LSA）が正しく処理されていない」 状態です。

以下の 3 つの原因が考えられます。

原因

ネットワークタイプ（Network Type）の不一致

イーサネットやトンネルインターフェースなど、OSPF が認識する ネットワークタイプ が対向ルーターと一致していないと、LSA の解釈ができず、経路がインストールされないことがあります。

よくあるパターン

片側が BROADCAST（デフォルトのイーサネット）、もう片側が POINT_TO_POINT（トンネルなど）になっている。
Hello / Dead タイマーを無理やり合わせているためネイバーは 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-point

原因

ワイルドカードマスクの指定ミス（Advertise 漏れ）

「ネイバー関係（隣のルーターへの経路）」は学習できているが、「その奥にある LAN 側のネットワーク」が学習できないケースです。これは単純に、LAN 側のインターフェースを OSPF で宣言（network コマンド）し忘れている ことが原因です。

確認コマンド

対向ルーターの設定を確認します。

Router_Target# show running-config | section router ospf
 router ospf 1
  network 10.0.12.0 0.0.0.3 area 0      <-- リンク用はOK
  ! network 192.168.10.0 0.0.0.255 area 0  <-- これが抜けている！

OSPF は network コマンドで指定されたインターフェースのネットワークだけを広告します。LAN 側のネットワークも忘れずに宣言されているか確認しましょう。

原因

DR/BDR 選出の問題（Priority 0 同士）

イーサネット（ブロードキャスト）環境では、代表ルーター（DR）を選出する必要があります。しかし、設定ですべてのルーターの OSPF Priority を 0 にしてしまうと、「誰も DR になりたくない」状態になり、LSA の同期が行われません。

症状

正確にはステータスは FULL にならず、永遠に 2WAY のまま止まります。
2WAY は通常（DROTHER 同士）なら正常ですが、セグメント内の 全員が 2WAY なのは異常です。誰も情報を集約（DR 動作）しないため、ルート情報が交換されません。

確認コマンド

Router# show ip ospf interface GigabitEthernet0/0
...
  State DROTHER, Priority 0  <-- ここを確認
  Designated Router (ID) 0.0.0.0, Interface address 0.0.0.0  <-- DRが存在しない

対処法

少なくとも 1 台（通常はセンタールーターやハイスペックなルーター）の Priority を 1 以上（デフォルトは 1）に戻し、DR に選出されるようにします。

Router(config-if)# ip ospf priority 1

よく使う確認コマンド

ここまで個別のケースを見てきましたが、現場で「何が起きているか分からない」時に役立つ、確認コマンドを 2 つ紹介します。

show ip ospf interface（パラメータ確認コマンド）

OSPF のトラブルシューティングにおいて、最も情報量が多く、かつ原因特定に役立つコマンド です。ネイバーが上がらない原因の 9 割（エリア 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   <-- エリアIDとIPマスク
  Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 1 <-- N/Wタイプ
  Transmit Delay is 1 sec, State DR, Priority 1 
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 <-- タイマー値
  Hello due in 00:00:04
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 1, Adjacent neighbor count is 1 
    Adjacent with neighbor 2.2.2.2  (Backup Designated Router)
  Suppress hello for 0 neighbor(s)

「設定を見直してもミスが見つからない」という時は、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 に高い負荷をかけます。特にネイバーが多数存在するコアスイッチや、ルート変動が激しい環境で実行すると、コンソールがログで埋め尽くされ、操作不能になる（最悪の場合、ルーターがハングアップする） リスクがあります。

事前の準備: terminal monitor でログを表示させるか確認する。
停止方法: 用が済んだら即座に undebug all (または u all) で停止する。
本番環境: 業務時間中の実行は避け、メンテナンス時に限定する。

まとめ

本記事では、OSPF のトラブルシューティング手法について解説しました。

基本はレイヤ1から: 物理結線と Ping が通らなければ OSPF は動きません。
ネイバー不可の5大原因: タイマー、エリアID、認証、パスワード、Passive設定を確認しましょう。
ステート停止の罠: EXSTART で止まる場合は MTU 不一致を疑いましょう。
ルート未学習: ネイバーが FULL でもネットワークタイプが違うと通信できません。

以上、最後までお読みいただきありがとうございました。

よかったらシェアしてね！

URLをコピーしました！

Cisco OSPF 設定手順 | 基本からマルチエリア、冗長構成の実践パターン

この記事を書いた人

とも

インフラ（クラウド/NW/仮想化）から Web 開発まで、技術領域を横断して活動するエンジニア💻 コンシューマー向けエンタメ事業での新規開発・運営経験を活かし、実戦的な技術ノウハウを発信中

[ Certs ] CCIE Lifetime Emeritus / VCAP-DCA ✒️ [ Life ] 技術書・ビジネス書愛好家📖 / 小・中学校で卓球コーチ👟