OSPFのネイバーがなかなかFullにならず、ExStartやExchangeで止まってしまう。これはネットワーク運用の現場でかなりよくあるトラブルです。特に更改直後、L3スイッチ追加後、他社ベンダー機器との接続時、あるいはトンネル環境をまたいだ接続で発生しやすく、いざ起きると「Helloは見えているのに上がらない」「疎通はあるのにネイバーだけ張れない」といった、少し嫌な止まり方をします。
OSPFは単にIP疎通があるだけでは隣接関係が完成しません。Helloパケットで互いを見つけたあと、DR/BDRの選出やDatabase Description（DBD）パケットの交換を行い、リンクステートデータベースの同期が進んで、はじめてFullになります。その途中のExStartやExchangeで止まるということは、ルータ同士が「隣接を組もうとしている途中で、何かの条件が合っていない」状態だと考えると分かりやすいです。
そして実務で最も多いのが、MTU不一致です。もちろん、認証不一致、network typeの差分、ACLやフィルタ、L2の問題などもあります。ただ、ExStart/Exchangeで止まると聞いたら、まずMTUを疑うというのはかなり現場寄りの考え方です。
この記事では、OSPFがExStartで止まる意味、よくある原因、確認コマンド、対処法、そして現場でありがちなハマりどころまで、初心者にも分かりやすく整理して解説します。単に用語を並べるだけでなく、実際にどう切り分ければよいかまで分かる内容にしています。
OSPFのExStartとはどんな状態か
まず、OSPFネイバーは最初からいきなりFullになるわけではありません。一般的には、Down、Init、2-Way、ExStart、Exchange、Loading、Fullという順に進みます。
このうちExStartは、DBDパケットを交換する前段階で、どちらがMasterでどちらがSlaveかを決めたり、初期シーケンス番号を決めたりする状態です。言い換えると、「これからLSDB同期を始めるための準備段階」です。ここで止まるなら、同期処理そのものに入る前か、入り始めた直後で問題が起きていると考えられます。
Exchangeは、その名のとおりDBDパケットを交換して、互いが持っているLSA情報の概要を突き合わせていく状態です。この段階で止まる場合は、単純なL3疎通だけでなく、DBD交換に必要な条件がどこかで崩れている可能性があります。
現場感でいうと、2-Wayまでは進むのにFullにならないケースは、物理断や単純なIPアドレスミスよりも、もう少し“設定の噛み合わせ”の問題であることが多いです。だからこそ、ExStartやExchangeで止まったときは、設定差分を丁寧に見たほうが早いです。
OSPFがExStartで止まるときに最初に疑うべき原因
MTU不一致
もっとも有名で、実際によくある原因です。OSPFではDBDパケットにインターフェースMTUの情報が含まれます。片側のMTUが大きく、もう片側がそれを受け入れられない場合、DBDのやり取りが正常に進まず、結果としてExStartやExchangeで止まることがあります。
これは特に、Cisco同士ではなくマルチベンダー環境、物理インターフェースとサブインターフェースが混在する環境、GREやIPsecなどのトンネルを介した環境、VLANタグやMPLS配下で実効MTUが変わっている環境で起きやすいです。
厄介なのは、普通のpingが通ることもある点です。だから「IP疎通はあるからMTUではない」と早合点しやすいのですが、OSPFの隣接形成では別の観点でMTUが効いてきます。
認証設定の不一致
OSPF認証を使っている場合、認証方式やキーが一致していないと隣接形成に失敗します。多くのケースではもっと早い段階で止まりますが、機器や実装差、ログの見え方によっては切り分けが分かりにくくなることがあります。
設定変更直後や、片側だけキーを変えた直後に起きやすいので、MTUだけを見て長時間ハマるより、認証設定も並行して確認したほうが安全です。
Network Typeの差分
ブロードキャスト、ポイントツーポイント、NBMAなど、OSPFのnetwork typeが合っていないと、HelloやDR/BDR選出の前提がずれて、隣接形成がきれいに進まないことがあります。特にサブインターフェースやトンネル系では、意図せず片側だけ設定が違っていることがあります。
一見するとIPアドレスもエリア番号も合っているため見落としやすく、実際にはここが原因だったというケースもあります。
ACLやFirewallによる制御
OSPFはIPプロトコル89を使います。途中にACLやセキュリティポリシーが入っている場合、Helloは通っているように見えても、必要なトラフィックが完全には通っていないことがあります。L3スイッチ直結ではあまり意識しなくてもよいことが多いですが、仮想基盤やFW越し、特殊な中継構成では要注意です。
L2や実効経路の問題
物理的にはリンクアップしていても、片方向通信、VLAN収容ミス、タグ不一致、トンネル配下での断片化、キャリア回線側の制限などで、OSPFのネイバー形成だけが不安定になることがあります。設定が正しそうに見えるのにExStartで止まるときは、L3だけでなくL2の見直しも必要です。
なぜMTU不一致でExStartやExchangeに張り付くのか
ここは仕組みを理解しておくと、切り分けがかなり速くなります。
OSPFは隣接形成の途中でDBDパケットを使って、互いのLSDBの概要を交換します。このとき、送信側は自分のインターフェースで扱えるMTU情報をDBDに載せます。受信側は、その値をもとに受け入れ可否を判断します。もし受信側の前提より大きいMTUが来れば、DBD交換がうまく成立せず、結果として隣接がFullまで進みません。
運用現場では、これを「大きいMTU側が送ったDBDを、小さいMTU側がまともに扱えず同期が進まない」と理解しておくと十分です。細かい実装差はあっても、実務ではこの理解で切り分けに困ることはあまりありません。
特に怖いのは、インターフェース設定の見た目だけでは差が分かりにくいことです。物理ポートは1500でも、トンネルを被せた結果として実効MTUが小さくなっていたり、タグやオーバーヘッドの分だけ片側の条件が変わっていたりします。このため、単に「両方とも1500のはず」で済ませないほうが安全です。
まず見るべき確認コマンド
show ip ospf neighbor
show ip ospf neighbor最初に必ず見るコマンドです。対象ネイバーが本当にExStartなのか、Exchangeなのか、あるいはInitや2-Wayで止まっているのかを確認します。ここで状態を取り違えると、その後の切り分けがずれます。
また、どの隣接だけが問題なのか、複数ネイバーで同時に起きているのかも重要です。1対だけなら個別設定差分を疑いやすく、広範囲ならエリア設計や共通設定の問題も考えられます。
show ip ospf interface
show ip ospf interface
show ip ospf interface briefOSPFのnetwork type、Hello/Dead timer、エリア番号、認証有無、DR/BDR関連の情報などを確認します。ExStartだけを見るとMTUに目が行きがちですが、ここでnetwork typeやタイマーが揃っているかも必ず見てください。
特に、片側がpoint-to-pointで、もう片側がbroadcastのような差分は見落としやすいです。
show interface
show interface GigabitEthernet0/0
show interface Vlan100
show interface Tunnel10ここで物理または論理インターフェースのMTUを確認します。サブインターフェース、SVI、トンネル、Port-Channel配下など、実際にOSPFを有効にしているインターフェース単位で見てください。
「物理IFは合っていたのに、トンネルIF側が違っていた」というのは本当によくあります。
show run interface
show run interface GigabitEthernet0/0
show run interface Vlan100
show run interface Tunnel10設定レベルで、ip mtu、ip ospf network、ip ospf authentication、ip ospf message-digest-key などを確認します。show interfaceだけでは見えない設定差分があるため、実行状態と設定の両方を見るのが基本です。
show ip ospf database
show ip ospf databaseExchangeやLoadingまで進んでいるのにFullにならない場合、LSDB同期の進み方を見るヒントになります。初心者のうちは必須ではありませんが、隣接状態の変化と合わせて見ると理解が深まります。
debug ip ospf adj
debug ip ospf adjより詳細に見るなら有効です。ただし本番機で常時使うのは避けたほうがよく、時間帯と対象を絞って使うのが基本です。ログが多く出るため、周辺情報に埋もれてしまうこともあります。
メンテナンス時間帯や検証環境で使うと、どの段階で隣接形成が止まっているか、かなり分かりやすくなります。
ExStartで止まったときの実務的な確認手順
1. まずネイバー状態を確認する
show ip ospf neighborで、本当にExStartまたはExchangeで止まっているかを見ます。ここでInitや2-Wayなら、見るべきポイントが変わります。
2. 片側だけではなく両端を並べて見る
OSPFトラブルは、片側だけ見ても分からないことが多いです。インターフェース設定、OSPF設定、認証設定、MTUを両端で並べて比較すると、意外とすぐ差分が見つかります。
現場では、片側の設定だけ見て「問題なさそう」と判断して時間を溶かすことがよくあります。隣接プロトコルなので、比較前提で見る癖を付けるとかなり楽です。
3. MTUを最優先で確認する
ExStart/Exchangeなら、まずMTUです。物理IF、論理IF、トンネルIFまで含めて確認します。見た目の設定値だけでなく、どの経路で実際にOSPFが流れているかを意識してください。
特に更改時は、旧機器と新機器でデフォルトMTUが違うことがあります。Cisco同士でも、装置種別やインターフェース種別が違うと、思わぬ差が出ることがあります。
4. タイマーとnetwork typeを確認する
Hello/Dead timer、network typeが一致しているかを見ます。MTUが本命でも、ここがずれていると別の症状も同時に起きるため、まとめて確認したほうが効率的です。
5. 認証設定を確認する
認証方式、キーID、キー文字列、適用インターフェースを確認します。複数人で作業した環境や、保守の途中で片側だけ更新した環境では意外とありがちです。
6. 必要に応じてデバッグを使う
ここまで見ても分からなければ、デバッグでイベントの流れを追います。ただし、デバッグは最初から常用するものではなく、差分確認のあとに絞って使うほうが事故が少ないです。
MTU不一致を直すときの考え方
基本は、両端のMTUを正しく揃えることです。これが王道です。
たとえば、片側が1500、もう片側が1496や1400になっているなら、どちらを基準に合わせるべきかを設計上の都合と経路上の制約から判断します。単に大きい値へ合わせるのではなく、その回線やトンネルで本当に通せるサイズにする必要があります。
VPNやトンネルが絡む場合は、オーバーヘッド込みで考えるのが重要です。インターフェース設定だけ1500に揃えても、実効的には足りず、別の問題を生むことがあります。ここは「OSPFを上げるためだけに値を大きくする」のではなく、通信全体として成立するサイズに合わせる視点が必要です。
設定例
interface GigabitEthernet0/0
ip mtu 1500実際の値は環境に合わせてください。トンネルやWAN回線では、1500より小さくするケースも珍しくありません。
ip ospf mtu-ignoreは使ってよいのか
結論からいうと、応急策としては使うことがあっても、まずはMTUを正しく合わせるのが先です。
ip ospf mtu-ignoreを使うと、DBD交換時のMTUチェックを無視して隣接形成を進められることがあります。そのため、「とりあえずネイバーを上げたい」という場面では便利に見えます。
ただし、根本原因であるMTU差分を解消したわけではありません。OSPF隣接だけFullになっても、実データ通信で断片化や到達性の問題が残ることがあります。つまり、ルーティングだけ直ったように見えて、本番通信で別の障害を生む可能性があります。
現場でも、暫定復旧としてmtu-ignoreを入れて、そのまま長期運用されてしまうケースがありますが、あまりおすすめしません。保守資料に理由が残っていないと、後任が見たときに余計に混乱します。
例
interface GigabitEthernet0/0
ip ospf mtu-ignore使う場合は、なぜ必要だったのか、いつまでの暫定措置なのかを必ず残してください。
現場でよくあるハマりどころ
物理IFのMTUだけ見て安心してしまう
実際には、OSPFが動いているのがSVIやトンネルインターフェースだった、というのはかなり多いです。物理側だけ一致していても、論理側が違えば意味がありません。
Pingが通るのでMTU問題を除外してしまう
サイズ指定なしのpingは通っても、OSPF隣接形成に必要な条件まで満たしているとは限りません。pingが通ることと、OSPFがFullになることは別です。
片側だけ直して終わったつもりになる
OSPFは相互関係なので、変更後は必ず両端で確認します。片側だけ設定して、相手側に反映されていないまま時間を無駄にするのは本当によくあります。
ExStartと2-Wayを混同する
2-Way止まりならDR/BDR選出やnetwork typeを見るべきこともあります。ExStart/Exchangeとは見るポイントが少し違うため、状態を正確に読むことが大事です。
マルチベンダーでデフォルト値を信用しすぎる
ベンダーが違うと、MTUや認証、インターフェース種別の扱いが微妙に違うことがあります。「デフォルトだから同じだろう」は危険です。実際の状態をコマンドで確認するのが確実です。
トラブル時に確認したいコマンドまとめ
show ip ospf neighbor
show ip ospf interface
show ip ospf interface brief
show interface GigabitEthernet0/0
show run interface GigabitEthernet0/0
show ip ospf database
debug ip ospf adjまずはこのあたりを押さえておけば、ExStart/Exchange問題の切り分けはかなり進めやすくなります。慣れてきたら、ログやパケットキャプチャも組み合わせると、さらに原因特定が速くなります。
OSPFがExStartで止まるときの対処法まとめ
OSPFがExStartやExchangeで止まるとき、実務で最初に疑うべきなのはMTU不一致です。もちろん、認証不一致、network type差分、ACLやL2の問題などもありますが、症状的にはまずMTUを見るのが定石です。
確認の基本は、show ip ospf neighborで状態を確認し、show ip ospf interfaceとshow interfaceで両端の条件を並べて比較することです。片側だけ見て判断しないこと、物理IFだけでなく論理IFやトンネルIFも含めて確認することが重要です。
対処としては、まず正しくMTUを揃えるのが本筋です。ip ospf mtu-ignoreは応急策として使える場面があっても、根本解決ではありません。OSPF隣接が上がったあとに本番通信で別問題を起こさないためにも、最終的には通信経路全体として妥当なMTUへ合わせるべきです。
ExStartで止まるトラブルは、仕組みを知っていればそこまで難しくありません。むしろ、やみくもにデバッグへ進むより、状態確認、両端比較、MTU確認という順番を守ったほうが、現場では早く解決できることが多いです。OSPFでハマったときは、まず落ち着いて「ExStartならMTUから」と思い出してみてください。
