このドキュメントでは、通常のネットワーク運用で発生し、ネットワークの接続性が劣化する可能性がある Open Shortest Path First(OSPF)エラー メッセージをトラブルシュートする方法について説明します。
OSPF の知識があることが推奨されます。
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期(デフォルト)設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。
OSPF プロトコルは、企業およびサービス プロバイダー ネットワークで広く導入されている、内部ゲートウェイ プロトコル(IGP)です。
このプロトコルは、TCP/IP プロトコル ファミリとして高機能で非独占的な IGP(内部ゲートウェイ プロトコル)を導入するという、インターネット コミュニティのニーズに応じて開発されました。インターネットのための共通の相互運用可能な IGP の作成についての話し合いは、1988 年に開始されましたが、1991 年まで正式なものにはなりませんでした。この時点で OSPF ワーキング グループは、OSPF をドラフトインターネット標準に提案することを要望しました。
OSPF プロトコルは、リンクステート テクノロジーをベースにしています。このリンクステート テクノロジーは、Routing Information Protocol(RIP)などの従来のインターネット ルーティング プロトコルで使用されている、ベルマンフォード ベクター ベースのアルゴリズムから発展した技術です。
このセクションでは、ネットワークの接続性を低下させる可能性がある、3 つの OSPF 問題について説明します。
OSPF-4-FLOOD_WAR エラー メッセージを受け取ります。OSPF フラッディング ウォーは、ルータが繰り返し独自のリンクステート アドバタイズメント(LSA)を受信し、それをネットワークからフラッシュしたり、その新しいバージョンを送信したりするときに発生します。これはネットワーク内に重複 IP アドレスが存在しているときにはタイプ 2 LSA の問題、または異なる OSPF 領域に重複ルータ ID が存在しているときにはタイプ 5 LSA の問題を検出することを意図しています。
一般的なシナリオとして、ネットワーク内には、LSA を発信する 1 番目のルータと、LSA をフラッシュする 2 番目のルータがあります。
この図は、それら 1 番目と 2 番目のルータ(それぞれ R1 および R2 と示す)の間での、発信イベントとフラッシュ イベントを示しています。
%OSPF-4-CONFLICTING_LSAID エラー メッセージを受け取ります。このエラー メッセージは、LSA の発信が、同じリンクステート ID でありながらサブネット マスクは異なっている現在の LSA と競合するために、妨げられていることを示しています。
同じプレフィックスでマスクは異なる複数の LSA がアドバタイズされるときの競合を解決するために、『RFC 2328』の「付録 E」のアルゴリズムが使用されます。このアルゴリズムが使用されて、ホスト ルートがアドバタイズされると、競合の解決が不可能であり、ホスト ルートまたは競合するプレフィックスがいずれもアドバタイズされないという状況が生じます。
エラー メッセージのスニペットの例を次に示します。
%OSPF-4-CONFLICTING_LSAID: LSA origination prevented by existing LSA with same LSID
but a different mask
Existing Type 5 LSA: LSID 192.168.1.0/31
New Destination: 192.168.1.0/32
Fast Hello パケット機能を使用するために OSPF を設定しますが、これは CPU 使用率が高くなる原因になります。Fast Hello パケット機能の OSPF サポートにより、Hello パケットを 1 秒未満の間隔で送信するように設定できます。これらの設定タイプにより、OSPF ネットワークのコンバージェンスはさらに高速になります。
このコマンドは、少なくとも 1 つの Hello パケットを受け取る必要があり、受け取らない場合にはネイバーがダウンしていると見なされる時間間隔を設定するために使用されます。
ip ospf dead-interval minimal hello-multipliermultiplier
以下が一例です。
Router(config-if)# ip ospf dead-interval minimal hello-multiplier 5
この例では、Fast Hello パケットの OSPF サポートは、minimal キーワード、hello-multiplier キーワード、および値が指定されて有効になっています。multiplier キーワードが 5 に設定されているため、Hello パケットが毎秒 5 回送信されます。
このセクションでは、前のセクションで説明した問題に対して取り得る、いくつかの解決策について説明します。
フラッディング ウォー メッセージのトラブルシューティング時には、エラー メッセージを理解することが重要です。メッセージの表示内容は、発信ルータとフラッシュ ルータでは異なります。このため、LSA タイプごとにトラブルシューティングの方法が異なるので、フラッディング ウォー メッセージが報告される LSA タイプに注目することが重要です。
OSPF フラッディング ウォー メッセージのサンプル スニペットは次のとおりです。
%OSPF-4-FLOOD_WAR: Process 1 re-originates LSA ID 172.16.254.25 type-2 adv-rtr
172.16.253.1 in area 0
%OSPF-4-FLOOD_WAR: Process 1 flushes LSA ID 172.16.254.25 type-2 adv-rtr
172.16.253.1 in area 0
次に示すのは、メッセージ コンポーネントの説明です。
ルータがタイプ 2 ネットワーク LSA を受け取り、その LSA ID が、ルータに関連付けられているいずれかのインターフェイスの IP アドレスと同じ場合には、ルータは LSA をフラッシュすることになります。このシナリオの根本原因は、発信ルータとフラッシュ ルータの重複 IP アドレスにあります。
この問題を解決するには、いずれかのインターフェイスの IP アドレスを再設定するか、または重複 IP アドレスを持つインターフェイスをシャットダウンします。
タイプ 3 LSA でフラッディング ウォー問題が検出されることはまれです。タイプ 3 LSA のフラッディング ウォー エラー メッセージは、過度にフラッピングするリンクの IP サブネットが OSPF ドメイン内で伝達される、というシナリオで記録されたことがあります。
シスコは、タイプ 3 LSA に起因するフラッディング ウォー問題を検出した場合には、Cisco Technical Assistance Center(TAC)でサポート ケースを開くことを推奨しています。
タイプ 5 LSA に起因するフラッディング ウォーは、別のエリアにあるルータ上に重複ルータ ID があると発生します。この場合はいずれかのルータ上の ルータ ID を変更することが必須になります。
タイプ 5 LSA のフラッディング ウォーのさらに別の例として、同じ Border Gateway Protocol(BGP)ネットワーク ステートメントを持つ 2 つのルータがあり、その両方のルータがそれらの BGP ネットワーク ステートメントを OSPF に再配布するという場合があります。これらのいずれかの BGP ルータが OSPF 経由でネットワークにアクセスすると、タイプ 5 LSA に起因するフラッディング ウォーが報告されます。
要約すると、ルータ ID が同じでないことを確認すれば、外部 LSA が正しく再配布され、タイプ 5 LSA に起因するフラッディング ウォー問題は防げるはずです。
OSPF-CONFLICTING_LSAID エラー メッセージを解決するために最初に取るべき手順は、アドバタイズされていないプレフィックスと、競合しているプレフィックスを見つけることです。
これらを見つけるには、show ip route コマンドと show ip ospf database コマンドを CLI に入力します。管理者は、New Destination:192.168.1.0/32 の発信元を追跡し(「問題 2」のセクションで説明されているサンプル ケースで示しています)、ネットワークのサブネット マスクを訂正する必要があります。
通常ケースの競合 LSA ID は、OSPF の最近の変更の後にログに記録され、OSPF ネットワーク ステートメントでサブネット マスク設定を訂正した後に解決されます。
CPU 使用率が高いというケースは、ユーザが OSPF Fast Hello を Cisco Catalyst シリーズ スイッチに導入すると、Cisco TAC でログに記録されます。
Cisco IOS® は非プリエンプティブ モデルで実行し、Fast Hello パケット機能は、OSPF Hello が 1 秒の dead 間隔よりも頻繁に処理されることを要求します。OSPF が、他の長期実行プロセスがあるシステム上で、必要なリソースを取得できないという場合があります。ルータに設定されている環境、その他のプロトコル、アプリケーションに応じて、この機能の使用が問題になる場合があります。
サブセカンド Hello に代わるものは双方向フォワーディング検出(BFD)により導入されましたが、BFD は高速ネイバー ダウン検出用に開発されています。BFD は割り込みモードで実行し、OSPF Fast Hello で観察される問題が発生することはありません。シスコは、高速コンバージェンスには BFD を使用することを推奨しています。
OSPF Fast Hello に起因する 2 つの既知の問題は、次のとおりです。
改定 | 発行日 | コメント |
---|---|---|
1.0 |
01-Apr-2015 |
初版 |