OSPFネイバーが上がらない原因と対処法を徹底解説｜EXSTART・2WAY・DOWNで止まるときの確認ポイント

2026年3月11日

ネットワーク

OSPFを設定したのにネイバーが上がらない。showコマンドを見るとDOWNのままだったり、INITやEXSTARTで止まったりして、どこを見ればいいのかわからなくなる。こうしたトラブルは、ネットワークの現場ではかなりよくあります。

特に拠点追加や機器更改のタイミングでは、IPアドレスやエリア番号のような基本項目だけでなく、MTU、認証、タイマー、ネットワークタイプなど、見落としやすい差異が原因になりやすいです。しかもOSPFは、片側だけを見ると一見正しく見えることも多く、切り分けに時間がかかりやすいのが厄介なところです。

この記事では、OSPFネイバーが上がらないときに確認すべきポイントを、仕組みから順番に整理しながら解説します。単に「設定例を並べる」だけではなく、なぜその状態になるのか、どのコマンドで確認するのか、どう直せばよいのかまで、現場目線でまとめています。これからOSPFを触る初心者の方はもちろん、障害調査を効率化したい運用担当の方にも役立つ内容です。

目次 [ close ]

OSPFネイバーが上がる仕組みを先に理解しておく

OSPFのトラブルは、状態遷移の意味を知っているかどうかで切り分けの速さがかなり変わります。OSPFは、同じセグメント上にいる隣接ルータ同士がHelloパケットを交換し、条件が一致すればネイバー関係を作り、その後LSDBの同期を進めます。

代表的なネイバー状態には、DOWN、INIT、2WAY、EXSTART、EXCHANGE、LOADING、FULLがあります。ざっくり言えば、Helloが見えていないならDOWN、相手からHelloを受けたが双方向確認が不十分ならINIT、双方向のHello確認ができたら2WAY、その先でDBD交換やLSA同期に進んで最終的にFULLになります。

つまり、どの状態で止まっているかを見ると、原因のあたりをつけやすくなります。たとえばDOWNならL2やIP到達性、Helloの送受信、interface設定を疑いやすいですし、EXSTARTやEXCHANGEならMTUやDBD交換まわりを疑うべき場面が多いです。

OSPFネイバーが上がらないときに最初に見るべきポイント

OSPF障害の調査では、いきなり細かい設定差分を追うより、まず大枠を崩していく方が効率的です。経験上、次の順番で確認すると無駄が少なくなります。

インターフェースが物理的に上がっているか

当然に見えて意外と重要なのが、物理リンクとL2状態の確認です。ケーブル、SFP、speed/duplex不一致、switchport設定、trunk許可VLAN漏れなどがあると、OSPF以前の問題として通信できません。L3プロトコルの設定を一生懸命見ていて、実は下位層の問題だったというのは珍しくありません。

相互にIP到達できるか

OSPFは隣接インターフェース同士でHelloを交換します。/30や/31、あるいは同一セグメントのアドレス設計に誤りがあると、Hello自体が成立しません。まずは隣接IPへpingが通るかを見てください。もちろんACLやセキュリティポリシーで止めていないかも確認が必要です。

同じエリア番号で動作しているか

OSPFの基本ですが、隣接ルータ同士は同じエリアに属している必要があります。片側がarea 0、もう片側がarea 1になっていればネイバーは張れません。設定投入時にinterface配下で明示する機器もあれば、network文で拾う機器もあるため、想定と違うエリアに入っているケースがあります。

Hello/Deadタイマーや認証設定が一致しているか

HelloタイマーとDeadタイマーが不一致だと、隣接関係は形成されません。また、OSPF認証を使っている環境では、認証方式やキーの不一致でもネイバーは上がりません。特に更改時は、旧機器側では平文認証、新機器側ではMD5やHMAC系認証にしてしまうなど、設計書を見ただけでは気づきにくいズレが起きがちです。

OSPFネイバーが上がらない主な原因

ここからは、現場で特に多い原因を順番に見ていきます。原因ごとに、なぜ起きるのか、どんな症状になりやすいのかを整理しておくと、障害対応の再現性が上がります。

エリア番号の不一致

もっとも基本的ですが、実際には今でもよくある原因です。OSPFは同一リンク上でも、隣接対象のエリアが一致しないとネイバーを張れません。設定レビュー時にrouter ospf配下だけ見て安心し、実際には意図しないinterfaceが別エリアに入っていた、というケースもあります。

症状としては、Helloを送っていてもネイバーが確立しない、ログにarea mismatch系のメッセージが出る、という形が典型的です。

サブネットマスクやIP設計の不一致

隣接インターフェースのIPアドレスやマスクが食い違っていると、同一セグメントとして認識できず、Helloが正常に成立しません。片側だけ/30、もう片側が/29になっているようなミスは、設定投入時のコピペやテンプレ流用で起きやすいです。

疎通確認では片方向だけpingが見えたり見えなかったりすることもあり、OSPFの設定ミスに見えて、実際にはアドレス設計ミスだったということがあります。

Hello/Deadタイマー不一致

OSPFは隣接条件としてタイマー一致を要求します。WAN回線や特殊なセグメントでチューニングした設定を片側だけ変えてしまうと、Helloは見えていてもネイバーになりません。特に障害時の暫定対応で片側だけtimer変更し、その後戻し忘れて長期間潜伏することがあります。

OSPF認証の不一致

認証を使う環境では、認証方式、キーID、パスワードのいずれかが違うだけでも失敗します。文字列の打ち間違いだけでなく、interface単位認証とarea単位認証のどちらで制御しているかの認識違いも原因になります。

現場では、機器更改後に「旧機器では平気だったのに新機器でだけ隣接しない」という相談がありますが、認証アルゴリズムの違いやコマンド体系の差分が背景にあることが少なくありません。

ネットワークタイプの不一致

OSPFにはbroadcast、point-to-point、non-broadcastなどのネットワークタイプがあります。両端で想定が異なると、DR/BDR選出やHello挙動に差が出て、ネイバー確立に失敗することがあります。特にEthernetだから何も考えずbroadcastのまま、片側だけ明示的にpoint-to-pointに変更、というような食い違いは要注意です。

MTU不一致でEXSTARTまたはEXCHANGEで止まる

かなり現場感のある原因です。Hello交換までは通るため、2WAYまでは進むことがありますが、その後DBD交換の段階でこけてFULLになりません。状態としてはEXSTARTやEXCHANGEで止まりやすいです。

たとえば、片側が1500、もう片側が1496や1400などになっていると、DBD処理で不整合が起きる場合があります。VPNやトンネル、キャリア装置を挟む環境では、インターフェースの見た目は同じでも実効MTUが異なることがあるため、想像以上によく当たります。

ACLやFirewallでOSPFパケットを止めている

OSPFはIPプロトコル番号89を使います。TCP/UDPではないため、ACL設計時に見落とされやすいです。pingは通るのにOSPFだけダメ、というときは、ICMPは許可されていてもOSPFが落ちているケースがあります。ルータ間にFWやL3フィルタを挟む構成では、特に注意が必要です。

passive-interfaceの設定ミス

router ospf配下でpassive-interfaceが有効になっていると、そのinterfaceではHelloを送信しません。経路広告の都合でpassiveを使うこと自体はよくありますが、隣接を張るべきインターフェースまでpassiveにしてしまうミスは定番です。テンプレート導入時や一括設定投入時に起こりやすいです。

重複Router ID

Router IDが重複していると、LSDB同期や隣接形成に悪影響が出ます。特に仮想環境やテンプレ複製でルータを増やしたとき、明示設定したRouter IDを変え忘れることがあります。普段は気づきにくいですが、OSPFでは地味に危険です。

ネイバー状態ごとに疑うべきポイント

OSPFは、止まっている状態から原因をかなり絞れます。ここを覚えておくと、障害対応の初動が速くなります。

DOWNのまま

Helloを受け取れていない可能性が高いです。物理リンク、VLAN、IPアドレス、マスク、ACL、passive-interface、OSPFの有効化漏れを優先して見ます。interfaceはup/upでも、該当セグメントがOSPFプロセスに取り込まれていないことがあります。

INITで止まる

相手のHelloは見えているが、自分が双方向確認できていない状態です。片方向通信、ACL、マルチキャスト転送の問題、network type不一致などを疑います。相手側のHelloに自ルータIDが含まれているかどうかがヒントになります。

2WAYで止まる

broadcastやNBMA環境では、すべての相手とFULLになるとは限りません。DR/BDRとのみFULLになる構成もあるため、2WAYだから即異常とは限りません。ただし、point-to-pointのはずなのに2WAY止まりならnetwork typeや設計の確認が必要です。

EXSTART・EXCHANGEで止まる

MTU不一致、DBD交換異常、master/slave決定まわりの不整合を疑います。現場ではこの段階でハマるケースがかなり多いです。相手のinterface MTUとトンネル構成、途中装置の制限、ベンダ差分を見ます。

LOADINGで止まる

LSA要求や同期処理で問題が出ています。回線品質不良、CPU高騰、メモリ不足、LSDB異常、ソフトウェア不具合の可能性もあります。設定差分だけでなく、装置リソースやログも合わせて確認した方がよいです。

確認に使う代表的なコマンド

実際の障害対応では、showコマンドの順番も重要です。いきなりdebugを入れると、情報量が多すぎてかえって追いにくくなることがあります。まずは安全に見られるshow系から入るのが基本です。

Cisco系での確認例

show ip ospf neighbor
show ip ospf interface
show ip ospf interface brief
show ip protocols
show running-config | section router ospf
show running-config interface GigabitEthernet0/0
show ip route ospf
show log

show ip ospf neighbor では、ネイバーの状態が最優先です。FULLなのか、EXSTARTなのか、そもそも相手が見えていないのかで方向性が決まります。show ip ospf interface では、Hello/Deadタイマー、network type、認証、cost、MTUまわりを確認できます。

interface設定確認の例

interface GigabitEthernet0/0
 description To-R2
 ip address 10.0.12.1 255.255.255.252
 ip ospf 10 area 0
 ip ospf network point-to-point
 ip ospf authentication message-digest
 ip ospf message-digest-key 1 md5 cisco123
 no shutdown

このレベルの設定でも、片側でnetwork typeが違う、認証キーが1文字違う、エリア番号が違うと、簡単にネイバーが上がらなくなります。設定行単体ではなく、対向と並べて差分を見るのが大切です。

MTU確認の例

show interface GigabitEthernet0/0 | include MTU
show ip ospf interface GigabitEthernet0/0

EXSTARTやEXCHANGEで止まるときは、ここを早めに見る価値があります。VPNやトンネル環境では、物理interfaceと論理interfaceで値が違うこともあるため、見た目だけで判断しない方が安全です。

よくある設定ミスと対処法

network文の対象がずれている

OSPFをnetwork文で有効化する機器では、ワイルドカードマスクの指定ミスで対象interfaceが拾われていないことがあります。その結果、interfaceは存在していてIPも正しいのに、OSPF自体がそのポートで有効になっていません。

router ospf 10
 router-id 1.1.1.1
 network 10.0.12.0 0.0.0.3 area 0

この例なら、実際の接続先が10.0.13.0/30なのにnetwork文が10.0.12.0/30のままだと、当然ネイバーは張れません。テンプレート流用時によくあります。

passive-interface defaultを解除し忘れている

セキュリティや設計上の理由で passive-interface default を使う構成はよくあります。ただし、ネイバーを張るinterfaceだけ no passive-interface を忘れると、Helloが出ません。

router ospf 10
 passive-interface default
 no passive-interface GigabitEthernet0/0
 network 10.0.12.0 0.0.0.3 area 0

この解除行が抜けるだけで、見た目にはOSPF設定が入っているのに隣接しない、というわかりにくい状態になります。

認証方式がそろっていない

片側だけ認証あり、または認証種別が違うとネイバーは成立しません。設計書には「OSPF認証あり」とだけ書かれていて、実機ではインターフェース単位設定かエリア単位設定かが異なっていた、ということもあります。

interface GigabitEthernet0/0
 ip ospf authentication message-digest
 ip ospf message-digest-key 1 md5 ExampleKey123

キー文字列だけでなく、キー番号やアルゴリズムも対向と一致させてください。

MTU不一致への対処

根本対処は、両端のMTUを正しく合わせることです。どうしても一時回避が必要な場合、一部ベンダや機種ではMTUチェックを抑制する設定が使えることがありますが、これはあくまで応急処置として扱う方が安全です。根本原因がトンネル設計や回線側制約にある場合、後で別の通信不具合を生むことがあります。

以前、拠点間VPN更改の際にOSPFがEXSTARTで止まり続け、認証やエリアを何度見直しても原因が見えなかったことがありました。最終的にはトンネル側のMTU差分が原因で、値をそろえたらすぐFULLになった、というケースでした。OSPFは一見L3プロトコルの設定問題に見えても、実際には下回りの差分が原因ということがよくあります。

OSPFネイバー障害を効率よく切り分ける手順

ここでは、実務で使いやすい切り分け順をまとめます。焦って細部に潜るより、この順番でつぶしていく方が、結果的に早く終わることが多いです。

1. 物理リンクとL2を確認する

interface status、エラー、VLAN、trunk設定を確認します。L2が不安定ならOSPF以前に直すべきです。

2. 隣接IPへの疎通を確認する

pingが通るか、ARPが乗るか、ACLで止めていないかを確認します。OSPFだけ通らないのか、そもそもL3疎通がないのかを切り分けます。

3. OSPFがそのinterfaceで有効か確認する

network文またはinterface配下設定を見て、想定ポートにOSPFが乗っているか確認します。passive-interfaceも忘れずに見ます。

4. エリア、Hello/Dead、認証、network typeを対向比較する

片側だけを見ても気づけないため、必ず両端を並べて比較します。文章で「合っているはず」と考えるより、設定差分として見る方が確実です。

5. ネイバー状態がEXSTARTやEXCHANGEならMTUを優先確認する

ここで時間を大きく節約できます。認証やエリア確認を何周もするより、状態に応じて疑う対象を変える方が実戦的です。

6. ログと必要最小限のdebugを使う

showだけで見えない場合はログを確認し、メンテナンス影響を考慮しながらdebugを最小限で使います。本番環境では負荷やログ量に注意が必要です。

再発防止のためにやっておきたいこと

OSPFネイバー障害は、その場で直して終わりにすると再発しやすいです。設定不備の背景には、設計書の曖昧さ、テンプレートの粒度不足、レビュー不足が隠れていることが多いからです。

まず、OSPFの設計項目をテンプレート化しておくと効果的です。少なくとも、area、network type、認証、Hello/Dead、MTU、Router ID、passive-interface方針は、機器投入前に対向とセットで確認できるようにしておくべきです。

また、機器更改や拠点追加の際は、show ip ospf neighborがFULLになることを作業完了条件に含めると、見逃しが減ります。経路がたまたま別経路で通っているだけで、OSPF隣接不良に気づかず本番化してしまうケースもあるためです。

運用面では、障害時の確認コマンドを手順書化しておくと、担当者によるばらつきが減ります。OSPFは知っている人には単純でも、慣れていない人には状態遷移が見えにくいため、最初の観点を標準化する価値があります。

OSPFネイバーが上がらないときによくある質問

2WAYで止まっています。これは障害ですか

必ずしも障害ではありません。broadcastネットワークでは、DR/BDR以外の相手と2WAY止まりになることがあります。ただし、point-to-point回線のはずなのに2WAYから進まないなら、network typeや設計の見直しが必要です。

pingは通るのにOSPFだけネイバーになりません

よくあります。ACLでIPプロトコル89が止まっている、passive-interfaceになっている、認証不一致、Hello/Dead不一致などが代表例です。pingとOSPFでは通る条件が違うため、ping成功だけで安心しない方がよいです。

EXSTARTで止まるときは何から見るべきですか

まずMTUを疑ってください。もちろん認証やnetwork typeも可能性はありますが、EXSTARTやEXCHANGEで止まるなら、MTU差分はかなり優先度が高いです。

OSPFのdebugはすぐ使ってよいですか

本番環境では慎重に扱うべきです。まずshowコマンドとログで絞り込み、それでも足りない場合に限定的に使うのが安全です。装置負荷やログ量の増加も考慮してください。

まとめ

OSPFネイバーが上がらない原因は、エリア不一致や認証ミスのような基本設定から、MTUやnetwork typeのような見落としやすい項目まで幅広く存在します。ただし、闇雲に設定全体を見直すのではなく、ネイバー状態に応じて疑うポイントを変えることで、切り分けはかなり速くなります。

特に重要なのは、まずL1/L2とIP疎通を確認し、そのうえでOSPFがそのinterfaceで有効か、エリア・タイマー・認証・network typeが一致しているかを両端比較することです。そして、EXSTARTやEXCHANGEで止まっているなら、MTUを早めに確認する。この流れを押さえるだけで、OSPF障害対応の精度は大きく上がります。

OSPFは企業ネットワークでも今なお広く使われるプロトコルです。だからこそ、ネイバーが上がらないときの定番原因と確認順を、自分の中でパターン化しておく価値があります。現場で慌てないためにも、設定例だけでなく、状態ごとの見方までセットで覚えておくのがおすすめです。

SEO向け補足情報

想定読者

OSPFの設定や障害対応を担当するネットワークエンジニア、インフラ運用担当者、CCNA〜CCNP学習者を想定しています。

検索意図

「OSPF ネイバー上がらない」「OSPF EXSTART 原因」「OSPF 2WAY 止まり」「OSPF 認証不一致」「OSPF MTU 不一致」などの検索に対し、原因と確認方法、対処法を知りたい読者向けの内容です。

狙う主キーワード

OSPF ネイバー上がらない

メタディスクリプション案

OSPFネイバーが上がらない原因を、エリア不一致、認証、Hello/Dead、MTU、network typeなどの観点からわかりやすく解説。DOWN・INIT・2WAY・EXSTARTごとの確認ポイントやコマンド例、対処法まで現場目線でまとめています。

内部リンク候補

OSPFとは何かを初心者向けに解説した記事
MTUとMSSの違いをわかりやすく解説した記事
ルーティングループの原因と対策をまとめた記事
VLAN間通信できないときの確認ポイントを解説した記事

アイキャッチ画像タイトル案

OSPFネイバーが上がらない原因と対処法

VLAN間通信ができない原因と対処法をわかりやすく解説｜確認ポイントと設定ミスの見つけ方

現場でよくあるIPv6接続不具合の切り分け手順：アドレス自動取得・DNS関連の確認ポイントにフォーカス