「ネイバーが張れない」を解決する思考法——OSPFのトラブルシューティング
私のロードマップを使って勉強している方から、「Packet Tracerで設定したのにshow ip ospf neighborが空のままです」という相談をもらいました。
こういうとき、闇雲にコマンドを打ち直しても解決しません。
OSPFのトラブルには「見るべき順番」があります。
その順番を守るだけで、原因の8割は特定できます。今回はその診断の流れを体系的に解説します。
OSPFトラブルの2大パターン
OSPFのトラブルは大きく2つに分類できます。
・ パターンA：ネイバーが張れない（show ip ospf neighborに何も出ない、またはFULLにならない）
・ パターンB：ネイバーは張れているのに経路が見えない（show ip route ospfに期待する経路が出ない）
まずどちらのパターンかを確認してから診断に入るのが効率的です。
パターンA：ネイバーが張れない場合
ステップ1 物理層・インターフェースの確認
ネットワークのトラブルは常に下のレイヤーから確認します。OSPFも例外ではありません。
Router# show ip interface brief
対象インターフェースのStatusがup、Protocolもupになっているかを確認します。
どちらかがdownであればOSPFの設定以前の問題です。ケーブル・対向機器の設定を先に直してください。
ステップ2 OSPFへの参加確認
インターフェースがup/upでも、そのインターフェースがOSPFに参加していなければネイバーは張れません。
Router# show ip ospf interface brief
OSPFに参加しているインターフェースの一覧が表示されます。
意図したインターフェースが出ていない場合はnetworkコマンドのアドレスとワイルドカードマスクを見直します。
またpassive-interfaceが誤って設定されていないかも確認します。パッシブインターフェースはHelloを送らないため、ネイバーが張れません。
Router# show ip ospf
「Passive Interface(s)」の欄に意図しないインターフェースが載っていないかを確認します。
ステップ3 ネイバー条件の不一致確認
インターフェースがOSPFに参加しているにもかかわらずネイバーが張れない場合、ほとんどはネイバー条件のどれかが一致していません。
エリアIDの不一致
片方がarea 0、もう片方がarea 1になっているケースは頻出です。show ip ospf interfaceでエリアIDを確認します。
Router# show ip ospf interface GigabitEthernet0/0
サブネットマスクの不一致
OSPFは同一サブネットに属しているかをチェックします。
片方が/24、もう片方が/30になっていると、同じリンクに接続していてもネイバーになれません。
show ip interfaceでマスクを確認します。
Hello interval / Dead intervalの不一致
デフォルト値はブロードキャストネットワークでHello 10秒・Dead 40秒です。
どちらかで手動変更している場合、両端の値が一致していないとネイバーが確立しません。show ip ospf interfaceのHello/Dead欄で確認します。
Router(config-if)# ip ospf hello-interval 5
Router(config-if)# ip ospf dead-interval 20
変更する場合は必ず両端のルーターで同じ値を設定してください。
MTUの不一致
WAN回線やトンネルインターフェースで発生しやすい問題です。
MTUが一致しないとExchangeステートで止まったまま先に進めません。
show interfacesでMTU値を確認し、一致させるか、次のコマンドでMTUチェックを無効化します。
Router(config-if)# ip ospf mtu-ignore
ステップ4 debugコマンドによるリアルタイム確認
ここまでの確認で原因が特定できない場合はdebugコマンドを使います。
Router# debug ip ospf adj
ネイバー確立のやり取りをリアルタイムで表示します。どの段階で止まっているか、どの条件が不一致かがログに出てきます。
必ず使い終わったら止めてください。debugは処理負荷が高く、本番環境では障害を引き起こす可能性があります。
Router# undebug all
パターンB：ネイバーは張れているのに経路が見えない場合
show ip ospf neighborでFULLになっているのに、show ip routeに期待する経路が出ていない場合です。
LSDBに目的のネットワークが届いているか確認する
Router# show ip ospf database
目的のネットワークに対応するLSAがLSDBに存在するかを確認します。
・ LSAがない場合：広告元ルーターのnetworkコマンドを見直します。そのネットワークがOSPFに参加するよう宣言されていない可能性があります。
・ LSAはあるのに経路表に出ない場合：SPFの計算結果として、そのルートが最短経路として選ばれていないことが考えられます。コスト値を確認します。
コスト値の確認と調整
OSPFはコストが最も小さい経路を選びます。コストの計算式は次の通りです。
コスト = 参照帯域幅（デフォルト100Mbps） ÷ インターフェース帯域幅
GigabitEthernet（1Gbps）はデフォルトの参照帯域幅（100Mbps）だとコストが1未満になるため、切り上げられて全て1になります。GbpsクラスのリンクでOSPFを使う場合は参照帯域幅を合わせて変更します。
Router(config-router)# auto-cost reference-bandwidth 1000
この設定はエリア内の全ルーターで統一する必要があります。
一部のルーターだけ変更すると経路計算がずれます。
コスト値を個別に手動設定することもできます。
Router(config-if)# ip ospf cost 10
デフォルトルートが見えない場合
show ip routeに0.0.0.0/0が出てこない場合は、広告元ルーターでdefault-information originateが設定されているかを確認します。またalwaysなしの場合、そのルーター自身がデフォルトルートを持っていないと広告されません。
Router# show ip route
広告元ルーターの経路表にS* 0.0.0.0/0が存在するかを確認してください。
トラブルシューティングの全体フロー
show ip interface brief
└─ down/down → 物理層・L2の問題を先に解決
show ip ospf interface brief
└─ インターフェースが出ない → networkコマンド・passive-interfaceを確認
show ip ospf neighbor
└─ 空 or FULL以外 → エリアID・マスク・Hello/Dead・MTUを確認
└─ FULL → パターンBへ
show ip ospf database
└─ LSAがない → 広告元のnetworkコマンドを確認
└─ LSAはある → コスト値・auto-cost reference-bandwidthを見直す
まとめ
OSPFのトラブルシューティングは「ネイバーが張れていないのか、張れているのに経路が見えないのか」を切り分けるところから始まります。
ネイバーが張れない場合は物理層から順に上がり、条件の不一致を一つずつ潰す。
経路が見えない場合はLSDBとコスト値を確認する。
この診断の流れを手順として覚えておけば、試験のシナリオ問題でも現場のトラブルでも同じように対処できます。
これでOSPFの3本柱——概要・設定・トラブルシューティング——がすべて揃いました。
明日もお会いしましょう。
フォローしてお待ちください。
