ICMP リダイレクトメッセージの理解
はじめに
このドキュメントでは、Internet Control Message Protocol（ICMP）パケットリダイレクト機能について説明します。
前提条件
要件
次の項目に関する知識があることが推奨されます。
- Nexus 7000プラットフォーム アーキテクチャ
- Cisco NX-OSソフトウェアの設定
- Request for Comments（RFC）792 で規定されている Internet Control Message Protocol
使用するコンポーネント
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
- Nexus 7000
- Cisco NX-OS ソフトウェア
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
背景説明
このドキュメントは、Internet Control Message Protocol（ICMP）によって提供されるパケットリダイレクト機能に関するものです。 ネットワーク内に ICMP リダイレクトメッセージが存在することは、通常、何を意味しているのか、また、ICMP リダイレクトメッセージの生成を引き起こしたネットワークの状態に関連する悪影響を最小限に抑えるために何ができるのかを説明します。
ICMP リダイレクトメッセージ
ICMPリダイレクト機能については、次の例を使用して、『RFC 792 Internet Control Message Protocol』で説明されています。
この状況では、ゲートウェイはホストにリダイレクトメッセージを送信します。
ゲートウェイG1は、ゲートウェイが接続されているネットワーク上のホストからインターネットデータグラムを受信します。ゲートウェイG1はルーティングテーブルを確認し、データグラムのインターネット宛先ネットワークXへのルート上にある次のゲートウェイG2のアドレスを取得します
G2と、データグラムのインターネット送信元アドレスによって識別されるホストが同じネットワーク上にある場合、リダイレクトメッセージがホストに送信されます。リダイレクトメッセージはホストに対して、ネットワーク X のトラフィックをゲートウェイ G2 に直接送信することを通知します（宛先までのより短いパスであるため）。
ゲートウェイは、元のデータグラムデータをインターネットの宛先に転送します。
このシナリオを図1に示します。 ホストと2台のルータ（G1およびG2）は、共有イーサネットセグメントに接続され、同じネットワーク10.0.0.0/24内にIPアドレスを持ちます
図1 – マルチポイントイーサネットネットワークでのICMPリダイレクト
マルチポイントイーサネットネットワークでのICMPリダイレクト
ホストの IP アドレスは 10.0.0.100 です。ホストルーティングテーブルには、ルータG1のIPアドレス10.0.0.1をデフォルトゲートウェイとして指すデフォルトルートエントリがあります。ルータ G1 は、宛先ネットワーク X にトラフィックを転送するときに、ルータ G2 の IP アドレス（10.0.0.2）をネクストホップとして使用します。
ホストが宛先ネットワークXにパケットを送信すると、次のようになります。
1. IPアドレス10.0.0.1のゲートウェイG1は、接続先のネットワーク上のホスト10.0.0.100からデータパケットを受信する。
2. ゲートウェイG1は、ルーティングテーブルを確認し、データパケット宛先ネットワークXへのルート上の次のゲートウェイG2のIPアドレス10.0.0.2を取得します。
3. G2と、IPパケットの送信元アドレスで特定されたホストが同じネットワーク上にある場合、ICMPリダイレクトメッセージがホストに送信されます。 ICMP リダイレクトメッセージはホストに対して、ネットワーク X のトラフィックをゲートウェイ G2 に直接送信することを通知します（宛先までのより短いパスであるため）。
4. ゲートウェイG1は、元のデータパケットを宛先に転送する。
ホストの設定によっては、G1から送信されるICMPリダイレクトメッセージを無視することもできます。ただし、ホストがICMPリダイレクトメッセージを使用してルーティングキャッシュを調整し、後続のデータパケットをG2に直接送信し始めると、これらの利点はこのシナリオで実現されます
- ネットワークを介したデータ転送パスの最適化。トラフィックが宛先に迅速に到達する。
- 帯域幅やルータのCPU負荷など、ネットワークリソースの使用率が低下する。
図2 – ホストルーティングキャッシュにインストールされたネクストホップG2
ホストルーティングキャッシュにインストールされたネクストホップG2
図2に示すように、ホストがG2をネクストホップとして使用してネットワークXのルートキャッシュエントリを作成した後、次の利点がネットワークで確認できます。
- スイッチとルータG1間のリンクの帯域幅使用率は、両方向で減少します。
- ホストからネットワークXへのトラフィックフローがこのノードを通過しなくなるため、ルータG1のCPU使用率が低下します。
- ホストとネットワーク X の間のエンドツーエンドのネットワーク遅延が改善されます。
ICMP リダイレクトメカニズムの重要性を理解するには、初期のインターネットルータ実装がデータトラフィックを処理するために主に CPU リソースに依存していたことを思い出す必要があります。したがって、任意の1台のルータで処理する必要があるトラフィック量を減らし、特定のトラフィックフローが宛先に向かう途中で通過しなければならないルータホップ数を最小限に抑えることが望ましくなりました。同時に、レイヤ2フォワーディング（スイッチングとも呼ばれる）はカスタマイズされた特定用途向け集積回路(ASIC)で主に実装され、フォワーディングパフォーマンスの観点からは、レイヤ3フォワーディング（ルーティングとも呼ばれる）と比べて比較的安価でした。これも汎用プロセッサで実行されたものです。
より新しい ASIC 世代は、レイヤ 2 とレイヤ 3 の両方のパケット転送を実行できます。ハードウェアで実行されるレイヤ3テーブルのルックアップは、ルータによるパケット処理に関連するパフォーマンスコストの削減に役立ちます。さらに、レイヤ2スイッチへのレイヤ3転送機能が統合されたとき（現在はレイヤ3スイッチと呼ばれる）、パケット転送動作がより効率的になりました。これにより、ワンアームルータ（router on a stickとも呼ばれる）の設計オプションが不要になり、このようなネットワーク構成に関連する制限を回避できます。
図3は、図1のシナリオに基づいています。 レイヤ 2 機能とレイヤ 3 機能はもともと 2 つの個別のノードであるスイッチとルータ G1 によって提供されていましたが、現在は、Nexus 7000 シリーズ プラットフォームなどの単一のレイヤ 3 スイッチに統合されています。
図3 – レイヤ3スイッチがワンアームルータ構成を置き換える
レイヤ3スイッチがワンアームルータ設定に置き換わる
ホストが宛先ネットワークXにパケットを送信すると、次のようになります。
1. IPアドレスが10.0.0.1のゲートウェイL3スイッチが、接続先のネットワーク上のホスト10.0.0.100からデータパケットを受信する。
2. ゲートウェイL3スイッチは、自身のルーティングテーブルを確認して、データパケット宛先ネットワークXへのルート上の次のゲートウェイG2のアドレス10.0.0.2を取得します。
3. G2と、IPパケットの送信元アドレスで特定されたホストが同じネットワーク上にある場合、ICMPリダイレクトメッセージがホストに送信されます。 ICMP リダイレクトメッセージはホストに対して、ネットワーク X のトラフィックをゲートウェイ G2 に直接送信することを通知します（宛先までのより短いパスであるため）。
4. ゲートウェイは、元のデータパケットを宛先に転送します。
レイヤ3スイッチがレイヤ2とレイヤ3の両方のパケット転送をASICレベルで実行できるようになったため、ICMPリダイレクト機能はどちらも利点があると結論付けられます。1つ目は、ネットワークを介した遅延の改善、2つ目は、ネットワークリソースの使用率の削減を実現し、マルチポイントのイーサネットセグメントにおけるパス最適化技術に対する注意を払う必要がなくなります。
ただし、レイヤ3インターフェイスでICMPリダイレクト機能を有効にすると、マルチポイントイーサネットセグメントを経由する最適でない転送では、別の理由であっても、引き続きパフォーマンスのボトルネックが発生する可能性があります。これについては、このドキュメントの「Nexusプラットフォームに関する考慮事項」の項で説明します。
イーサネットネットワークを介した準最適パス
Open Shortest Path First(OSPF)やCisco Enhanced Interior Gateway Routing Protocol(EIGRP)などのInterior Gateway Protocol(IGP)は、ルータ間でルーティング情報を同期し、これらの情報を受け入れるすべてのネットワークノードで一貫性のある予測可能なパケット転送動作を提供するように設計されています。たとえば、マルチポイントイーサネットネットワークでは、セグメント上のすべてのレイヤ3ノードが同じルーティング情報を使用し、宛先への同じ出力点で合意している場合、このようなネットワークでの最適でない転送はめったにありません。
準最適転送パスの原因を理解するには、レイヤ 3 ノードがパケット転送の決定を相互に独立して行うことを思い出す必要があります。つまり、ルータ B によるパケット転送の決定は、ルータ A によるパケット転送の決定に依存しません。これは、IPネットワークを経由したパケット転送のトラブルシューティングを行う際に覚えておくべき重要な原則の1つであり、マルチポイントイーサネットネットワークで最適でない転送パスを調査する際には注意が必要です。
前述したように、すべてのルータが単一のダイナミックルーティングプロトコルに依存してエンドポイント間のトラフィックを配信するネットワークでは、マルチポイントイーサネットセグメントを経由した準最適な転送は行われません。ただし、実際のネットワークでは、ほとんどの場合、さまざまなパケットルーティング/転送メカニズムが組み合わされています。 このようなメカニズムには、さまざまな IGP、スタティックルーティング、ポリシーベースルーティングなどがあります。これらの機能は、通常、ネットワークを介して必要なトラフィック転送を行うために併用されます。
これらのメカニズムを組み合わせて使用することで、トラフィックフローを微調整し、特定のネットワーク設計の要件を満たすことができますが、これらのツールを組み合わせて使用すると、マルチポイントイーサネットネットワークでネットワーク全体のパフォーマンスが低下する可能性がある副作用を見過ごすことになります。
スタティックルーティング
これを説明するために、図4のシナリオを考えてみます。ルータAには、ネクストホップとしてルータBを持つネットワークXへのスタティックルートがあります。同時に、ルータ B は、ネットワーク X へのスタティックルートでルータ C をネクストホップとして使用します。
図4：スタティックルーティングによる最適でないパス
スタティックルーティングによる最適でないパス
トラフィックは、ルータ A からこのネットワークに入り、ルータ C を通過して、最終的に宛先ネットワーク X に配信されますが、パケットは、宛先に到達するまでにこの IP ネットワークを 2 回通過する必要があります。これはネットワークリソースの効率的な使用ではありません。代わりに、ルータAからルータCにパケットを直接送信しても同じ結果が得られますが、ネットワークリソースの消費は少なくなります。
ポリシー ベース ルーティング
ポリシーベースルーティング（PBR）は、イーサネットネットワークを介した準最適パスを発生させる可能性があるもう一つのメカニズムです。ただし、スタティックルーティングやダイナミックルーティングとは異なり、PBR はルーティングテーブルレベルでは動作しません。 代わりに、トラフィック リダイレクト アクセス コントロール リスト（ACL）がスイッチのハードウェアに直接プログラミングされます。 その結果、選択されたトラフィックフローでは、入力ラインカードでのパケット転送ルックアップにより、スタティックルーティングまたはダイナミックルーティングを介して取得されるルーティング情報がバイパスされます。
図4では、ルータAとルータBが、ダイナミックルーティングプロトコルの1つと宛先ネットワークXに関するルーティング情報を交換しています。 両者は、ルータBがこのネットワークへの最適なネクストホップであることに同意しています。
ただし、ルーティングプロトコルから受信したルーティング情報を上書きし、Router CをネットワークXへのネクストホップとして設定する、Router BでのPBR設定では、ICMPリダイレクト機能をトリガーする条件が満たされ、パケットがさらに処理するためにRouter BのCPUに送信されます。
ポイントツーポイントリンクでの ICMP リダイレクト
これまでのところ、このドキュメントでは、3 つ（またはそれ以上）のレイヤ 3 ノードが接続されたイーサネットネットワーク（そのため、マルチポイント イーサネット ネットワークと呼ばれる）について説明してきました。ただし、ICMPリダイレクトメッセージはポイントツーポイントイーサネットリンクでも生成される可能性があることに注意してください。
図5のシナリオを参照してください。ルータAはスタティックデフォルトルートを使用してトラフィックをルータBに送信しますが、ルータBにはネットワークXへのスタティックルートがあり、これがルータAを指しています。
図5：ポイントツーポイントリンクでのICMPリダイレクト
スタティックルーティングによる最適でないパス
この設計オプションはシングルホーム接続とも呼ばれ、小規模なユーザ環境をサービスプロバイダーネットワークに接続する際によく使用されるオプションです。この例では、ルータBはプロバイダーエッジ(PE)デバイスで、ルータAはユーザエッジ(CE)デバイスです。
一般的なCE設定には、Null0インターフェイスを指すユーザIPアドレスブロックへの集約スタティックルートが含まれていることに注意してください。この設定は、スタティックルーティングを使用したシングルホーム CE-PE 接続オプションの推奨ベストプラクティスです。ただし、この例の目的では、そのような設定は存在しないものとします。
図に示すように、ルータAがネットワークXへの接続を失うと仮定します。ユーザのネットワークYまたはリモートのネットワークZからのパケットがネットワークXに到達しようとすると、ルータAとBは互いにトラフィックをバウンスすることができ、各パケットのIP Time-To-Live（TTL；存続可能時間）フィールドの値が1に達するまで各パケットの値が減少します。この時点で、パケットをさらにルーティングすることはできません。
ネットワークXへのトラフィックがPEルータとCEルータの間を往復する一方で、CE-PEリンクの帯域幅使用率が大幅に（不必要に）増加します。ポイントツーポイントPE-CE接続の一方または両方の側でICMPリダイレクトが有効になっている場合は、問題が悪化します。この場合、ネットワークX宛てのフロー内のすべてのパケットは、各ルータのCPUで複数回処理され、ICMPリダイレクトメッセージの生成に役立ちます。
Nexus プラットフォームに関する考慮事項
ICMPリダイレクトがレイヤ3インターフェイスで有効にされていて、着信データパケットがこのインターフェイスを使用してレイヤ3スイッチの入力と出力の両方を行う場合、ICMPリダイレクトメッセージが生成されます。 レイヤ3パケット転送はCisco Nexus 7000プラットフォームのハードウェアで実行されますが、ICMPリダイレクトメッセージを作成するのはスイッチのCPUの役割です。 これを実行するために、Nexus 7000 スーパーバイザモジュールの CPU は、ネットワークセグメントを通るパスの最適化が可能なフローの IP アドレス情報を取得する必要があります。入力ラインカードからスーパーバイザモジュールにデータパケットが送信されるのはこのためです。
ICMPリダイレクトメッセージの受信者がそれを無視して、ICMPリダイレクトが有効になっているNexusスイッチのレイヤ3インターフェイスにデータトラフィックを転送し続けた場合、ICMPリダイレクト生成プロセスがデータパケットごとにトリガーされます。
ラインカードレベルでは、プロセスはハードウェア転送例外の形式で開始されます。パケット転送操作がラインカードモジュールによって正常に完了できない場合は、ASICで例外が発生します。この場合、データパケットを正常に処理するには、パケットがスーパーバイザモジュールに送信される必要があります。
スーパーバイザモジュールのCPUが送信元にICMPリダイレクトメッセージを送信した後、出力ラインカードモジュールを介してデータパケットをネクストホップに転送することで、例外処理が完了します。
Nexus 7000スーパーバイザモジュールは、大量のトラフィックを処理できる強力なCPUプロセッサを使用しますが、このプラットフォームは、スーパバイザCPUプロセッサをパケット転送プロセスに関与させることなく、ほとんどのデータトラフィックをラインカードレベルで処理するように設計されています。これにより、CPUはコアタスクに集中でき、パケット転送操作はラインカード上の専用ハードウェアエンジンに任されます。
安定したネットワークでは、パケット転送の例外が発生した場合、かなり低いレートで発生することが予想されます。 この前提が満たされている場合、スーパーバイザの CPU はパフォーマンスに大きな影響を与えることなく例外を処理できます。一方、パケット転送例外を処理するCPUが非常に高いレートで発生すると、システム全体の安定性と応答性に悪影響を及ぼす可能性があります。
Nexus 7000プラットフォームの設計には、スイッチのCPUを大量のトラフィックから保護するためのさまざまなメカニズムが備わっています。これらのメカニズムは、システムのさまざまなポイントで実装されます。ラインカードレベルでは、ハードウェアレートリミッタ(HRT)とコントロールプレーン(CoPP)Policing機能があります。どちらもトラフィックレートのしきい値を設定します。これにより、各ラインカードモジュールからスーパーバイザに転送されるトラフィックの量を効果的に制御できます。
これらの保護メカニズムにより、ネットワークの安定性やスイッチの管理性にとって重要な各種の制御プロトコル（OSPF、BGP、SSHなど）のトラフィックが優先されます。また同時に、スイッチのコントロールプレーンの機能にとって重要ではない種類のトラフィックに対しては、積極的にフィルタリングが行われます。ほとんどのデータトラフィックは、パケット転送例外の結果として CPU に転送される場合、そのようなメカニズムによって厳重にポリシングされます。
ハードウェアレートリミッタとCoPPpolicingメカニズムは、スイッチのコントロールプレーンの安定性を提供するため、常に有効にしておくことを強く推奨しますが、データパケットのドロップ、転送遅延、ネットワーク全体のアプリケーションパフォーマンスの全体的な低下の主な原因の1つである可能性があります。このため、トラフィックフローがネットワークを通過するパスを理解し、ICMPリダイレクト機能を使用できる、または使用することが予想されるネットワーク機器を監視するツールを使用することが重要です。
トラフィックを監視および診断するツール
show ip traffic
Cisco IOSとCisco NX-OSソフトウェアの両方に、CPUで処理されるトラフィックの統計情報をチェックする方法があります。これは、show ip trafficコマンドで行います。このコマンドは、レイヤ3スイッチまたはルータによるICMPリダイレクトメッセージの受信または生成を確認するために使用できます。
Nexus7000#show ip traffic | begin ICMP
ICMP Software Processed Traffic Statistics
------------------------------------------
Transmission:
Redirect: 1000, unreachable: 0, echo request: 0, echo reply: 0,
<output omitted for brevity>
ICMP originate Req: 0, Redirects Originate Req: 1000
Originate deny - Resource fail: 0, short ip: 0, icmp: 0, others: 0
Reception:
Redirect: 0, unreachable: 0, echo request: 0, echo reply: 0,
<output omitted for brevity>
Nexus7000#
show ip trafficコマンドを何度か実行して、ICMPリダイレクトカウンタが増えているかどうかを確認します。
Ethanalyzer
Cisco NX-OSソフトウェアには、Ethanalyzerと呼ばれる、スイッチのCPUとの間でやり取りされるトラフィックをキャプチャする組み込みツールflowingがあります。
図6は、図3と同様のシナリオを示しています。ここで、ネットワーク X は 192.168.0.0/24 ネットワークに置き換えられています。
図6:Ethanalyzerキャプチャの実行
Ethanalyzerキャプチャの実行
ホスト10.0.0.100は、宛先IPアドレス192.168.0.1にICMPエコー要求の連続ストリームを送信します。ホストは、リモートネットワーク192.168.0.0/24へのネクストホップとしてNexus 7000スイッチのスイッチ仮想インターフェイス(SVI)10を使用します。デモの目的で、ホストはICMPリダイレクトメッセージを無視するように設定されています。
次のコマンドを使用して、Nexus 7000のCPUによって送受信されたICMPトラフィックをキャプチャします。
Nexus7000#ethanalyzer local interface inband capture-filter icmp limit-captured-frames 1000
Capturing on inband
2018-09-15 23:45:40.124077 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.124477 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.124533 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.126344 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.126607 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.126655 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.128348 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.128611 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.128659 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.130362 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.130621 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.130669 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.132392 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.132652 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.132700 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.134347 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.134612 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.134660 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.136347 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.136598 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.136645 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.138351 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.138607 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.138656 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
...上記の出力のタイムスタンプから、この例で強調表示されている3つのパケット(2018-09-15 23:45:40.128)が同時にキャプチャされたことがわかります。次は、このパケットグループのパケット単位の内訳です
- 最初のパケットは入力データパケットであり、この例では ICMP エコー要求です。
2018-09-15 23:45:40.128348 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
- 2 つ目のパケットは、ゲートウェイによって生成された ICMP リダイレクトパケットです。このパケットはホストに返信されます。
2018-09-15 23:45:40.128611 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
- 3 つ目のパケットは、CPU によってルーティングされた後に出力方向でキャプチャされたデータパケットです。ここまでは示していませんが、このパケットのIP TTLは減分され、チェックサムが再計算されます。
2018-09-15 23:45:40.128659 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
タイプとフローが異なる多数のパケットを含む大規模なEthanalyzerキャプチャを移動する場合、ICMPリダイレクトメッセージとそれらに対応するデータトラフィックを関連付けることは困難な場合があります。
このような場合には、ICMP リダイレクトメッセージに注目して準最適転送トラフィックフローに関する情報を取得します。ICMPリダイレクトメッセージには、インターネットヘッダーと、元のデータグラムデータの最初の64ビットが含まれます。 このデータは、メッセージを適切なプロセスとマッチングするためにデータグラムの送信元によって使用されます。
Ethanalyzerのパケットキャプチャツールとdetailキーワードを使用して、ICMPリダイレクトメッセージの内容を表示し、準最適に転送されるデータフローのIPアドレス情報を見つけます。
Nexus7000#ethanalyzer local interface inband capture-filter icmp limit-captured-frames 1000 detail
...
Frame 2 (70 bytes on wire, 70 bytes captured)
Arrival Time: Sep 15, 2018 23:54:04.388577000
[Time delta from previous captured frame: 0.000426000 seconds]
[Time delta from previous displayed frame: 0.000426000 seconds]
[Time since reference or first frame: 0.000426000 seconds]
Frame Number: 2
Frame Length: 70 bytes
Capture Length: 70 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:icmp:ip:icmp:data]
Ethernet II, Src: 00:be:75:f2:9e:bf (00:be:75:f2:9e:bf), Dst: 00:0a:00:0a:00:0a (00:0a:00:0a:00:0a)
Destination: 00:0a:00:0a:00:0a (00:0a:00:0a:00:0a)
Address: 00:0a:00:0a:00:0a (00:0a:00:0a:00:0a)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Source: 00:be:75:f2:9e:bf (00:be:75:f2:9e:bf)
Address: 00:be:75:f2:9e:bf (00:be:75:f2:9e:bf)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: IP (0x0800)
Internet Protocol, Src: 10.0.0.1 (10.0.0.1), Dst: 10.0.0.100 (10.0.0.100)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 56
Identification: 0xf986 (63878)
Flags: 0x00
0.. = Reserved bit: Not Set
.0. = Don't fragment: Not Set
..0 = More fragments: Not Set
Fragment offset: 0
Time to live: 255
Protocol: ICMP (0x01)
Header checksum: 0xadd9 [correct]
[Good: True]
[Bad : False]
Source: 10.0.0.1 (10.0.0.1)
Destination: 10.0.0.100 (10.0.0.100)
Internet Control Message Protocol
Type: 5 (Redirect)
Code: 1 (Redirect for host)
Checksum: 0xb8e5 [correct]
Gateway address: 10.0.0.2 (10.0.0.2)
Internet Protocol, Src: 10.0.0.100 (10.0.0.100), Dst: 192.168.0.1 (192.168.0.1)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 84
Identification: 0xf986 (63878)
Flags: 0x00
0.. = Reserved bit: Not Set
.0. = Don't fragment: Not Set
..0 = More fragments: Not Set
Fragment offset: 0
Time to live: 254
Protocol: ICMP (0x01)
Header checksum: 0xa8ae [correct]
[Good: True]
[Bad : False]
Source: 10.0.0.100 (10.0.0.100)
Destination: 192.168.0.1 (192.168.0.1)
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0 ()
Checksum: 0x02f9 [incorrect,shouldbe 0xcae1]
Identifier: 0xa01d
Sequence number: 36096 (0x8d00)
...
ICMP リダイレクトのディセーブル化
ネットワーク設計で、スイッチまたはルータに着信した同じレイヤ3インターフェイスからトラフィックフローをルーティングする必要がある場合、それに対応するレイヤ3インターフェイスでICMPリダイレクト機能を無効にすると、フローがCPUを介してルーティングされないようにすることができます。
実際に、ほとんどのネットワークでは、すべてのレイヤ 3 インターフェイス（イーサネット インターフェイスなどの物理的なものとポートチャネル インターフェイスや SVI インターフェイスなどの仮想的なものの両方）で ICMP リダイレクトを事前に無効にすることが推奨されます。Cisco NX-OSインターフェイスレベルコマンドのno ip redirectsを使用して、レイヤ3インターフェイスでICMPリダイレクトを無効にします。ICMPリダイレクト機能が無効になっていることを確認するには、次の手順を実行します。
- no ip redirectsコマンドがインターフェイスコンフィギュレーションに追加されていることを確認します。
Nexus7000#show run interface vlan 10 interface Vlan10
no shutdown no ip redirects ip address 10.0.0.1/24
- インターフェイス上のICMPリダイレクトのステータスがdisabledになっていることを確認します。
Nexus7000#show ip interface vlan 10 | include redirects IP icmp redirects: disabled
- スイッチのスーパーバイザから1つ以上のラインカードにインターフェイス設定をプッシュするCisco NX-OSソフトウェアコンポーネントによって、ICMP Redirect enable/disableフラグが0に設定されていることを確認します。
Nexus7000#show system internal eltm info interface vlan 10 | i icmp_redirect per_pkt_ls_en = 0, icmp_redirect = 0, v4_same_if_check = 0
- 1つ以上のラインカードで、特定のレイヤ3インターフェイスのICMPリダイレクト有効/無効フラグが0に設定されていることを確認します。
Nexus7000#attach module 7
Attaching to module 7 ...
To exit type 'exit', to abort type '$.'
Last login: Wed Sep 15 23:56:25 UTC 2018 from 127.1.1.1 on pts/0
module-7#
!--- Optionally, jump to non-admin Virtual Device Context (VDC) if verification needs to be done in one of the custom VDCs
module-7#vdc 6
module-7#show system internal iftmc info interface vlan 10 | include icmp_redirect
icmp_redirect : 0x0 ipv6_redirect : 0x1
要約
RFC 792 で規定されている ICMP リダイレクトメカニズムは、マルチポイント ネットワーク セグメントを介した転送パスを最適化するように設計されています。インターネットの導入当初は、このような最適化によって、リンク帯域幅やルータのCPUサイクルなど、高価なネットワークリソースを保護できました。 ネットワーク帯域幅が手頃な価格になり、比較的低速なCPUベースのパケットルーティングが、専用ハードウェアASICでの高速なレイヤ3パケット転送に進化するにつれて、マルチポイントネットワークセグメントを介した最適なデータ転送の重要性は減少しました。 デフォルトでは、すべてのレイヤ 3 インターフェイスで ICMP リダイレクト機能が有効になっています。ただし、その機能が最適転送パスに関してマルチポイント イーサネット セグメント上のネットワークノードに通知する試みをネットワーク担当者が理解して対処していない場合があります。 スタティックルーティング、ダイナミックルーティング、ポリシーベースルーティングなど、さまざまな転送メカニズムを組み合わせて使用するネットワークでは、ICMPリダイレクト機能を有効のままにして、適切に監視しないと、中継ノードのCPUが実稼働トラフィックを処理するために望ましくない方法で使用される可能性があります。これは、実稼働トラフィックフローと、ネットワークインフラストラクチャのコントロールプレーンの安定性の両方に大きな影響を与える可能性があります。
ほとんどのネットワークでは、ネットワーク インフラストラクチャのすべてのレイヤ3インターフェイスで ICMP リダイレクト機能を事前に無効にすることが推奨されます。これにより、マルチポイントネットワークセグメントを通じて優れた転送パスが存在する場合に、レイヤ3スイッチおよびルータのCPUで処理される実稼働データトラフィックのシナリオを防ぐことができます。
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
4.0 |
14-May-2025
|
書式を更新。 |
3.0 |
31-Oct-2023
|
ブランディング要件、フォーマット、寄稿者リストを更新。 |
2.0 |
22-Sep-2022
|
再認定 |
1.0 |
17-Oct-2018
|
初版 |
フィードバック