運用・構築者向けOSPFトラブルシューティング1

運用や構築の現場で遭遇するかも知れない問題の見つけ方と対処方法のまとめ1弾目です。次のような構成を想定しています。

スポンサーリンク
スポンサーリンク

ネイバーが張れない

ワイルドカード設定ミス

R1はネイバーが張れていません。

「show ip ospf interface」コマンドで、OSPFが有効になっているインタフェースを確認します。

OSPFが有効になっていません。この結果から、OSPFの設定に誤りがあることが分かります。OSPFの設定を見てみます。

このnetworkコマンドはワイルドカード指定に誤りがあり、172.16.0.0-172.16.0.255までしかカバーしません。ワイルドカードを設定し直す必要があります。次のように修正します。

ネイバーを張れるようになった事を確認します。

passive interfaceが有効になっている

R1はR3とネイバーが張れていません。

「show ip ospf interface」コマンドで、f0/1でOSPFが有効になっているか確認します。

OSPFは有効になっていますね。でもちょっと待ってください。気になる出力があります。

No Hellos (Passive interface)

R1のOSPF設定を見てみます。

passive-interfaceが設定されています。この設定を外してみます。

これでネイバーを張れるようになった事を確認します。

ACL設定ミス

R1はR3とネイバーを張れていません。

fa0/1でOSPFが有効になっているか確認します。

デバッグコマンドでhelloパケットの送受信を確認します。

R1では、FastEthernet0/1でhelloを送信しているにも関わらず受信はできていません。一方、R3はどうでしょうか。

R3はhelloの送受信ができているように見えます。ただ、このネットワーク環境で「Send immediate hello」が出るのはおかしいです。しかし、とりあえず送受信はできています。という事は、R1でhelloをフィルタリングしている可能性があります。アクセスリストが怪しいですね。確認してみます。

原因がわかりました。access-list 101にOSPFを許可する設定が入っていません。設定を修正します。

これでネイバーを張れるようになった事を確認します。

hello interval設定ミス

R1はR3とネイバーが張れていません。

fa0/1でOSPFが有効になっていることを確認します。

一見すると問題ないように見えます。debugコマンドでhelloのやり取りを確認します。

気になる出力があります。

Mismatched hello parameters from 172.16.2.2
Dead R 40 C 20, Hello R 10 C 5 Mask R 255.255.255.0 C 255.255.255.0

「R」はネイバーの設定、「C」はdebugコマンドを実行したルーターの設定です。このデバッグ出力を見ると、hello intervalの設定がR1とR3で異なっている事がわかります。

念のため、R1とR3で「show ip ospf interface」コマンドを実行してみます。

R1のhello intervalを修正しましょう。

これでネイバーを張れるようになった事を確認します。

サブネット不一致

R1はR3とネイバーが張れていません。

R1のfa0/1でOSPFが有効になっている事を確認します。

問題ないようです。次にdebugコマンドでhelloが正常にやり取りされている事を確認します。

気になる出力がありますね。

Mismatched hello parameters from 172.16.2.2
Dead R 40 C 40, Hello R 10 C 10 Mask R 255.255.255.0 C 255.255.255.252

前章でも書いた通り「R」はネイバーの設定、「C」はこのルーターの設定です。このデバッグ出力を見るとsubnet maskが異なっている事がわかります。R1とR3のインタフェース設定を見てみましょう。

構成図通りR1のインタフェース設定を修正して、ネイバーが正常に張れる事を確認します。

認証設定不一致

R1はR3とネイバーが張れていません。

R1のfa0/1でOSPFが有効になっている事を確認します。

問題は見られません。「debug ip ospf event」コマンドで確認をしてみます。

気になる出力があります。

Rcv pkt from 172.16.2.2, FastEthernet0/1 : Mismatch Authentication Key

どうやら認証設定に問題があるようです。出力の結果からfa0/0では認証設定をしておらず、fa0/1で認証設定をしているものの、認証エラーとなっている事がわかります。ではR1とR3の設定を確認してみます。

パスワードが「Cisco」と「cisco」で異なっています。R1のパスワードを「cisco」に修正してネイバーが張れるようにしましょう。

修正後、ネイバーが正常に張れる事を確認します。

エリア不一致

R3はR1とネイバーを張れていません。

R3のfa0/1でOSPFが有効になっている事を確認します。

問題は見られません。「debug ip ospf event」コマンドで確認をしてみます。

エリアIDに問題がある事がわかります。正しくはエリア0ですが、R1のエリアは1に設定されている事がわかります。R1の設定を確認してみます。

エリア設定を修正します。

修正後、ネイバーが正常に張れる事を確認します。

FULL Stateにならない

みんなPriority 0

R1とR3は「2WAY」のままになっています。

デフォルトではPriority値は1で、DR/BDRの選出はルーターIDで決まります。しかし、あるルーターを意図的に代表ルーターにするためにPriority値0を設定する事はよくあります。では双方のルーターでPriority値を0にするとどうなるのかというと、互いにFULL Stateになる事ができなくなります。

この問題を解決するためには、双方もしくはどちらかのPriority値を0以外にする必要があります。それでは、R3のプライオリティ値をデフォルトに戻してFULL Stateに遷移する事を確認します。

これでFULL Stateに遷移するはずです。

スポンサーリンク
スポンサーリンク
スポンサーリンク

フォローする