3.5OSPFv2/v3の構成

OSPFの障害は大きく2種類に分かれます。隣接（アジャセンシー）が成立しないか、隣接は成立しているのに期待した経路が入らないかです。前者は show ip ospf neighbor に相手が出てこない、あるいは EXSTART/EXCHANGE で止まるといった形で現れ、原因は両端のパラメータ不一致にほぼ限られます。後者は集約・フィルタ・エリア種別・network 文の対象範囲といった設計側の意図が絡みます。この節では、どちらの側の問題かをまず切り分け、そこから確認すべきコマンドへ最短で辿り着く手順を作ります。

3.5.1隣接が成立する条件

• 隣接に必須の一致項目は、エリアIDが同一・Hello間隔とDead間隔が同一・認証の種別と鍵が同一・スタブフラグ（エリア種別）が同一・ブロードキャストネットワークでは同一サブネット（マスク一致）・ネットワークタイプが互換であること。加えてルータIDが両者で重複していないことも必要である。1つでも欠けると show ip ospf neighbor に相手が現れない。
• MTU不一致は特徴的な症状を出す：Helloは交換できるので隣接は始まるが、DBDのやり取りで詰まって EXSTART/EXCHANGE 状態のまま停滞する。show ip ospf neighbor の状態が FULL にならずこの2状態を行き来していたら、まず両端の show interface でMTUを比較する。回避策として ip ospf mtu-ignore があるが、根本原因（MTU設計の不整合）を隠すだけなので恒久対処にはしない。
• passive-interfaceの意味を正確に押さえる：そのインタフェースからのHello送出を止めるので隣接は形成されないが、network 文の対象であればそのインタフェースのネットワーク自体は広告され続ける。したがって「端末しかいないLAN側で無駄なHelloと隣接リスクを排除しつつ、そのセグメントは広告したい」という要件に正しく応える。「passiveにすると経路も広告されなくなる」という理解は誤り。

3.5.2ネットワークタイプとDR/BDR

• ブロードキャスト（イーサネットの既定）では、隣接数の爆発を防ぐためDR（代表ルータ）とBDRを選出し、他のルータ（DROTHER）はDR/BDRとのみFULLになる。選出はOSPF優先度（既定1・0なら選出対象外）→ルータIDの順で高いほうが勝ち、先に上がった者が居座る（プリエンプションなし）ため、後から高優先度のルータを入れてもDRは自動では交代しない。
• ポイントツーポイント（P2P）では対向が1台しかいないためDR/BDRを選出しない。イーサネットのL3リンクを2台だけで使う場合、ip ospf network point-to-point を設定するとDR選出の待ち時間がなくなり収束が速くなるうえ、隣接の設計も単純になる。ただし両端で同じネットワークタイプにしないと隣接が成立しない点に注意する。

3.5.3エリア設計・集約・フィルタリング

• 複数のノーマルエリアを作る場合、全エリアはバックボーン（エリア0）に接続しなければならず、物理的に離れているときは仮想リンクで論理的に接続する（恒久設計としては非推奨）。ABRは接続する各エリアごとに別々のLSDBを保持し、エリア間の経路をtype3 LSAとして相互に注入する。
• 経路集約は場所が決まっている：エリア間の集約は ABR で area <id> range <prefix>、外部経路の集約は ASBR で summary-address <prefix>。集約するとLSDBとテーブルが縮み、さらに集約範囲内の個別リンクのフラッピングが外部へ伝播しなくなる（SPF再計算の抑制）という運用上の大きな利点がある。
• フィルタリングはLSDBを壊さない範囲で行うのが原則。ABRでのエリア間フィルタは area <id> filter-list prefix <name> in|out でtype3 LSAの注入自体を止める。一方 distribute-list ... in は自分のルーティングテーブルへの登録を抑えるだけでLSDBやダウンストリームへの広告は止まらない——「隣は経路を持っているのに自分だけ持っていない」という非対称な状態を作りやすいので、用途を取り違えないこと。
• OSPFv3はIPv6に対応した版で、隣接はリンクローカルアドレスを使って形成し、設定はインタフェース単位（ospfv3 1 ipv6 area 0）が基本。アドレスファミリ機能によりIPv4も同一プロセスで扱える。ルータIDは依然として32ビットのドット付き10進なので、IPv4アドレスが1つも無い環境ではrouter-id を手動設定しないとプロセスが起動しない。

あなたは新設の支社ルータR3をエリア1に追加しましたが、ABRであるR2との間でOSPF隣接が FULL になりません。show ip ospf neighbor を見ると、隣接自体は現れており、状態が EXSTART と EXCHANGE を行き来していることが分かります。ここが診断の分岐点です。もし相手が一覧にまったく現れないのであれば、Helloパケットの段階で弾かれている＝エリアIDの相違・Hello/Dead間隔の相違・認証の不一致・サブネットマスクの相違・ネットワークタイプの相違を疑います。しかし今回は隣接が開始しており、Helloの一致項目はすべて揃っていることが逆に証明されています。EXSTART/EXCHANGE はDBD（データベース記述）パケットを交換してLSDBを同期し始める段階で、ここで停滞する典型的な原因がMTU不一致です。両端で show interface を見ると、R2側のインタフェースが1500バイト、R3側がジャンボフレーム設定の名残で9000バイトになっていました。大きなDBDパケットが相手で受け取れず、再送を繰り返して先に進めなかったわけです。ここで ip ospf mtu-ignore を入れれば確かに FULL にはなりますが、これは症状を隠す部分解にすぎません。MTUが実際に不一致のままだと、OSPFは通っても大きなパケットを使う上位アプリケーションでブラックホール的な障害が残ります。正しい対処は両端のMTUを設計値に揃えることです。無事に FULL になった後、今度は「本社側からR3配下の10.1.32.0/24〜10.1.35.0/24が個別に見えてしまい、支社のリンクがフラッピングするたびに本社でSPFが再計算される」という運用課題が出ました。これに対しては、ABRであるR2で area 1 range 10.1.32.0 255.255.252.0 を設定して集約します。集約点をASBRの summary-address と取り違えないことが重要で、summary-address は再配布された外部経路（type5/7）を集約するコマンドです。集約後は、範囲内の個別リンクが上下しても集約経路が消えないため、フラッピングがエリア外へ伝播せずSPF再計算が抑制されます。なお、R3のLAN側インタフェースには端末しかいないため passive-interface を設定しますが、これはHelloを止めて無用な隣接形成とセキュリティリスクを排除するだけで、network 文の対象である限りそのLANのネットワークは引き続き広告される——「passiveにしたから広告も止まる」と誤解して network 文を追加し直す必要はありません。

3.5.4この節のまとめ

• 隣接不成立はHello段階の不一致（エリアID/タイマ/認証/マスク/ネットワークタイプ）、EXSTART/EXCHANGE停滞はMTU不一致が定番
• ブロードキャストはDR/BDRを選出（優先度→ルータID・プリエンプションなし）、P2Pは選出しない。ネットワークタイプは両端一致が必要
• 集約はABRがarea range／ASBRがsummary-addressでフラッピング伝播を抑える。passive-interfaceはHelloのみ停止し経路広告は継続