OSPFを組んでるのにネイバーが確立しない。show ip ospf neighborを叩いても Init か ExStart で止まったまま、あるいはそもそも何も出てこない。現場で「設定は合ってるはずなのに…」と夜中のメンテ中に頭を抱えた経験、ネットワークエンジニアなら一度は通る道です。
この記事では、Catalyst 9300とISR4431の検証環境で実際に遭遇した事例をベースに、OSPFネイバーが確立しない主な原因トップ5と、1分で切り分けられる手順をまとめました。MTU不一致・エリア番号ズレ・Hello/Deadタイマーのミスマッチ・認証パスワードの食い違い・ネットワークタイプの不一致——この5つを順番に潰せば、ほぼ確実に復旧します。
OSPFは「条件が1つでも違えばネイバーを組まない」という仕様
OSPFは動的ルーティングの中でもかなり厳格なプロトコルです。BGPみたいに多少のズレは許してくれません。RFC 2328の定義どおり、両側の一致すべきパラメータがちょっとでも違うとネイバーはDownか、悪くてInit止まり。
具体的にどのパラメータが一致していないとダメか、下の表にまとめました。これは暗記しなくていいので、ブックマークして切り分け時に見返してください。
| 確認項目 | 一致が必須か | 不一致時の挙動 |
|---|---|---|
| エリア番号 | 必須 | Helloが落とされる（ログ出力あり） |
| Hello/Deadインターバル | 必須 | Helloパケットが無効と判断される |
| サブネットマスク | 必須（point-to-point除く） | Helloが落とされる |
| 認証タイプ・パスワード | 必須 | debugログにmismatchの警告 |
| MTU | 必須 | ExStartまでは進むがDBD交換で止まる |
| スタブフラグ | 必須 | stub/normal混在はネイバー不可 |
| ネットワークタイプ | 推奨一致 | DR選出が期待通りに動かない |
| Router-ID | 重複NG | 両機で重複していると組めない |
OSPFのネイバー状態はDown → Init → 2-Way → ExStart → Exchange → Loading → Full の順に遷移する。どのステートで止まっているかを特定できれば、原因はかなり絞れる。ExStartで止まれば多くの場合MTU不一致が犯人。
まずは状態確認。3つのコマンドでほぼ解決する
OSPFのトラブルで私が最初に叩くコマンドは決まっています。この3つだけで8割方切り分けが終わる。
R1# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 192.168.1.2 1 EXSTART/DR 00:00:37 10.0.0.2 GigabitEthernet0/0
StateがEXSTARTで固まっているのが分かる。ここで止まるのはMTU不一致のサインなので、次のインターフェース詳細確認に進みます。
R1# show ip ospf interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
Internet Address 10.0.0.1/24, Area 0, Attached via Network Statement
Process ID 1, Router ID 192.168.1.1, Network Type BROADCAST, Cost: 1
Topology-MTID Cost Disabled Shutdown
0 1 no no
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 192.168.1.1, Interface address 10.0.0.1
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:03
Neighbor Count is 0, Adjacent neighbor count is 0
Suppress hello for 0 neighbor(s)
このコマンドでArea番号・Hello/Dead・Network Type・Costが全部見える。両方のルーターで叩いて並べれば、不一致パラメータが一発で分かる。
R1# debug ip ospf adj OSPF adjacency debugging is on *Apr 23 10:15:22.123: OSPF-1 ADJ Gi0/0: Rcv DBD from 192.168.1.2 seq 0x1B46 opt 0x52 flag 0x7 len 32 mtu 1500 state EXSTART *Apr 23 10:15:22.124: OSPF-1 ADJ Gi0/0: Nbr 192.168.1.2 has larger interface MTU
debugコマンドは本番環境のCPUに負荷をかける。必ず作業が終わったらundebug allで止めること。広域コアスイッチでdebug ip ospf adjを出しっぱなしにして怒られた先輩の話、今でも教訓にしてます。
現場で実際にハマった頻度順ランキング
過去5年で私が遭遇したOSPFネイバー障害、延べ30件以上を原因別に集計してみました。感覚的にはこんな割合。
図1: OSPFネイバー不成立の原因別発生頻度
80%
65%
45%
40%
25%
MTU絡みが圧倒的に多い。特にL3スイッチ同士をトランクで繋いだり、IPsec VPN越しにOSPFを組むときはまず疑うべきポイント。で、2位のエリア番号は「area 0と書いたつもりがarea 10だった」みたいなヒューマンエラー。正直なところ、私も2回やらかしています。
以前、データセンター間のOSPFが突然切れて、深夜2時に呼び出された。調べるとISP側のキャリア機器がJumbo FrameからMTU 1500に戻されていた。こっち側はinterface MTU 9216のまま。ExStartで固まってた。ip ospf mtu-ignoreで応急処置しつつ、翌朝キャリアに問い合わせ。ちなみにこれ、キャリア側のファーム更新でMTUが初期値に戻る事故、年に1〜2件は聞きます。
5ステップで順番に潰せば必ず直る
| 現象 | 主な原因 | 対処方針 |
|---|---|---|
| ネイバーが全く見えない | Helloが届いていない | L1/L2疎通・network文確認 |
| Initで止まる | 片側だけHelloを受信 | ACL/認証・対向の送信を確認 |
| ExStartで止まる | MTU不一致 | MTU合わせる or mtu-ignore |
| Exchangeで止まる | DBD交換のタイミング問題 | 回線品質・リンク断を疑う |
| Full/Downを繰り返す | フラッピング | 物理層とタイマー調整 |
どんなルーティングトラブルでも、物理層から見るのが鉄則。OSPFはネットワーク層の話なんだけど、リンクが上がってない可能性、ケーブルが抜けてる可能性、L2でVLANが通ってない可能性。これを先に潰す。
R1# show interface GigabitEthernet0/0 | include line|address GigabitEthernet0/0 is up, line protocol is up Internet address is 10.0.0.1/24 R1# ping 10.0.0.2 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
pingが通らないならOSPF以前の話。L1/L2でまず解決する。通るなら次のStep2へ。
両方のルーターでshow ip protocolsかshow run | section router ospfを叩く。エリアがズレてると問答無用で切れる。
R1# show run | section router ospf router ospf 1 router-id 192.168.1.1 network 10.0.0.0 0.0.0.255 area 0 R2# show run | section router ospf router ospf 1 router-id 192.168.1.2 network 10.0.0.0 0.0.0.255 area 10 ← これが違う！
R2側をarea 0に直せば即復旧。下のコマンドでサクッと治せます。
R2(config)# router ospf 1 R2(config-router)# no network 10.0.0.0 0.0.0.255 area 10 R2(config-router)# network 10.0.0.0 0.0.0.255 area 0 R2(config-router)# end R2# clear ip ospf process
デフォルトではBROADCAST/POINT-TO-POINTでHello 10秒・Dead 40秒、NBMAやPoint-to-Multipointだと30/120秒。ネットワークタイプが違うと自動的にタイマーも変わるので、ここが見落とされがち。
R1(config)# interface GigabitEthernet0/0 R1(config-if)# ip ospf hello-interval 10 R1(config-if)# ip ospf dead-interval 40
ExStartで止まっていたら、ほぼMTU。本来はリンク両端で同じMTUに揃えるべきなんだけど、相手がキャリア機器とかで手を出せない場合はip ospf mtu-ignoreで逃げる。
R1(config)# interface GigabitEthernet0/0 R1(config-if)# ip ospf mtu-ignore ! 確認 R1# show ip ospf interface GigabitEthernet0/0 | include MTU MTU Mismatch detection is disabled
mtu-ignoreは応急処置。根本原因を放置するとDBDの断片化で不安定になり、Full/Downを繰り返すフラッピングに発展することがある。本番環境では必ず物理MTUを揃える方向で根本対応すること。
MD5認証を使っている環境は、keyIDとパスワードを厳密に揃える。1文字でも違うとNG。
R1(config)# interface GigabitEthernet0/0 R1(config-if)# ip ospf message-digest-key 1 md5 MySecret123 R1(config-if)# ip ospf authentication message-digest R2(config)# interface GigabitEthernet0/0 R2(config-if)# ip ospf message-digest-key 1 md5 MySecret123 R2(config-if)# ip ospf authentication message-digest
Fullが見えたら終わり、ではない
ネイバーがFullになっても、そこで油断しないこと。私が現場でやる最終チェックは次の通り。
R1# 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 R1# show ip ospf database | include 192.168 192.168.1.1 192.168.1.1 0x80000005 0x00A4B2 0x002 192.168.1.2 192.168.1.2 0x80000004 0x0089E1 0x002 R1# show ip route ospf O 192.168.2.0/24 [110/2] via 10.0.0.2, 00:02:17, GigabitEthernet0/0
LSDBとルートテーブルに相手側の経路が入っているか。これが抜けていると、Fullに見えてもLSAが同期されていないケースがある（たまにある）。
図2: 復旧後の安定度チェック項目
必須
必須
必須
推奨
ぶっちゃけ、直した直後5分くらいはshow ip ospf neighborを叩き続けて、StateがFullのままか、Dead Timeが定期的にリセットされているか、確認してから撤収するのが癖になってます。
ベスト5に入らないけどハマる原因たち
passive-interface defaultを入れたあと、no passive-interface Gi0/0を忘れるパターン。ネイバーと繋がるインターフェースがpassive扱いだとHelloを一切送らない。これ、私も導入作業で1回やりました。ドキュメント通りの順番で叩いたつもりが、no passive-interfaceの行がコピペで抜けていた。
224.0.0.5と224.0.0.6。OSPFはこのマルチキャストアドレスを使うので、インターフェースにACLを当ててて暗黙deny anyがあると切られる。HSRPで同じトラブルを踏んだ人は記憶にあると思います。
IP unnumberedを使っているPoint-to-Pointリンクでは、相手のサブネットマスクチェックがスキップされる。ただしLoopbackインターフェースのIPアドレスが重複していると最悪ルーター全体が落ちる。これは検証が足りてないので、機会があれば追記する予定。
OSPFネイバー障害は「どこで止まったか」が全て
ネイバーが立たない時はまずshow ip ospf neighborでStateを確認。Init止まりならHelloの片方向性、ExStart止まりならMTU、Exchange止まりなら回線品質を疑う。原因TOPはMTU不一致、次いでエリア番号のヒューマンエラー。show ip ospf interfaceを両側で並べて差分を探すのが最短ルート。
よくある質問（FAQ）
Q. OSPFがEXSTARTから動かないのはなぜ？
ほぼ確実にMTU不一致です。両インターフェースのshow ip ospf interfaceでMTUを比較し、物理的に揃えるかip ospf mtu-ignoreで逃げる。根本対応はMTUを揃えること。
Q. ネイバーは見えるがFULLにならない場合は？
Exchange状態で止まる場合はLSA交換の不具合。回線のパケットロスやDBDシーケンスのタイムアウトを疑う。debug ip ospf adjで詳細ログが出る。
Q. Router-IDの重複で組めないことはある？
あります。OSPFのRouter-IDは一意である必要があり、router-id X.X.X.Xを明示的に設定した上でclear ip ospf processで再起動すれば解決。
Q. VRF内のOSPFでも同じ切り分け方でOK？
基本は同じですが、show ip ospf vrf VRF名 neighborのようにVRFを指定して確認します。ルーティングテーブルもshow ip route vrf VRF名でチェック。
Q. IPsec VPN越しでOSPFを組む時の注意点は？
トンネル越しだとMTUが1400前後まで下がるので、OSPFのDBD交換でMTU不一致が頻発します。両側のトンネルインターフェースにip mtu 1400とip ospf mtu-ignoreを併用するのが定石。
