ICMP リダイレクト メッセージの概要
目次
概要
この資料はインターネット制御メッセージ プロトコル（ICMP）によって提供されるパケット リダイレクト 機能性を説明します。 ネットワークの ICMP リダイレクト メッセージのどんな存在が通常示し、ICMP リダイレクト メッセージの生成を引き起こすネットワークの状態と関連付けられる否定的な副次的影響を最小に するためにものがすることができるか資料に説明されています。
前提条件
要件
次の項目に関する知識が推奨されます。
- Nexus 7000 プラットフォーム アーキテクチャ
- NX-OS ソフトウェア 設定
- Internet Control Message Protocol（ICMP） Request For Comments（RFC） 792 で文書化されているように
使用するコンポーネント
本書の情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。 稼働中のネットワークで作業を行う場合、コマンドの影響について十分に理解したうえで作業してください。
ICMP はメッセージをリダイレクトします
ICMP リダイレクト 機能性は次の例の RFC 792 で「Internet Control Message Protocol（ICMP）」説明されます
ゲートウェイは次の状況のホストにリダイレクト メッセージを送ります。
ゲートウェイは、G1、からインターネット データグラムをゲートウェイが接続されるネットワークのホスト受け取ります。 ゲートウェイは、G1、ルーティング テーブルをチェックし、データグラムのインターネット 宛先ネットワークに次のゲートウェイのアドレスを、ルートの G2、X.得ます。
G2 およびデータグラムのインターネット 送信元アドレスによって識別されるホストが同じネットワークにある場合、リダイレクト メッセージはホストに送られます。 リダイレクト メッセージはこれが宛先へ最短パスであるのでゲートウェイ G2 にネットワーク X のためのトラフィックを直接送信 するためにホストに助言します。
ゲートウェイはインターネット 宛先にオリジナル データグラムのデータを転送します。
このシナリオはピクチャ 1.ホストおよび 2 人のルータで、G1 および G2 示され、共有イーサネット セグメントに接続され、同じネットワーク 10.0.0.0/24 で IP アドレスがあります
ホストに 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、ルーティング テーブルをチェックし、データパケットの宛先ネットワークへの次のゲートウェイの IP アドレス 10.0.0.2 を、ルートの G2、X.得ます。
3. G2 および IPパケットの送信元アドレスによって識別されるホストが同じネットワークにある場合、ICMP リダイレクト メッセージはホストに送られます。 ICMP リダイレクト メッセージはこれが宛先へ最短パスであるのでゲートウェイ G2 にネットワーク X のためのトラフィックを直接送信 するためにホストに助言します。
4. ゲートウェイ G1 は宛先にオリジナルデータパケットを転送します。
ホスト構成によっては、それは G1 がそれに送る ICMP リダイレクト メッセージを無視することを選択しましたかもしれないです。 ただし、ルーティングキャッシュを調節すればのにホストが ICMP リダイレクト メッセージを使用し、G2 に後続データ パケットを直接送信 し始めれば次の利点はこのシナリオで実現します
- ネットワークによるデータ転送 パスの最適化; トラフィックは desination により速く達します
- 帯域幅およびルータのCPU ロードのようなネットワークリソース 利用のリダクション、
画像 2 に示すように、ホストがネクスト ホップとして G2 でネットワーク X のためのルートキャッシュエントリを作成した後、これらの利点はネットワークで知られます:
- スイッチとルータ G1 間のリンクの帯域利用率は両方向で減少します
- ルータ G1 の CPU稼働率はホストからのネットワーク X へのトラフィックフローがこのノードをもう横断しないので、減ります
- ホストとネットワーク X 間の End-to-End ネットワーク遅延は改良します。
データトラフィックを処理するために早いインターネットルータ 実装が CPU リソースに主に頼ったことを ICMP リダイレクト メカニズムの重要性を理解するために、覚えて下さい。 それ故に、あらゆるシングル ルータおよび特定のトラフィック トラフィック フローが宛先に方法で横断しなければならなかったルータ ホップの数を最小に することによって処理されなければならなかったトラフィック量を減らすことは非常に好ましかったです。 同時に、レイヤ3 フォワーディングと（またルーティングと呼ばれる）比較されたレイヤ2 フォワーディング（別名切り替え）は主に設定され、転送パフォーマンス観点からの比較的「安かったです」カスタマイズされた特定用途向け集積回路（ASIC）で一般目的プロセッサでそれ、またやられました。
より新しい ASIC 生成はレイヤ2 およびレイヤ3 両方パケット転送をすることができます。 実行された レイヤ3 テーブル 索引をハードウェア ヘルプでもらってルータが処理するパケットと関連付けるパフォーマンス コストを削減して下さい。 なお、（統合は今レイヤ3スイッチと呼ばれる）へのレイヤ3 フォワーディング 機能性をレイヤ2スイッチ パケット転送 オペレーション 効率的を作り、「片腕ルータ」（別名「router on a stick」）設計 オプションのための必要を省きおよびそのようなネットワークコンフィギュレーションと関連付けられた制限を避けます。
ピクチャ 1.のシナリオの 3 つのビルドを描写して下さい。 この場合最初に 2 つの別々のノードによって、スイッチおよびルータ G1 提供される、レイヤ2 およびレイヤ3 機能は、Nexus 7000 シリーズ プラットフォームのような単層 3 で切り替えます、強化されます。
ホストが宛先ネットワーク X にパケットを送信 するとき、次はネットワークで起こります
1. IP アドレス 10.0.0.1 とのゲートウェイ L3 スイッチはからデータパケットを接続するネットワークのホスト 10.0.0.100 受信します。
2. ゲートウェイは、L3 スイッチ、ルーティング テーブルをチェックし、データパケットの宛先ネットワークに次のゲートウェイのアドレス 10.0.0.2 を、ルートの G2、X.得ます。
3. G2 および IPパケットの送信元アドレスによって識別されるホストが同じネットワークにある場合、ICMP リダイレクト メッセージはホストに送られます。 ICMP リダイレクト メッセージはこれが宛先へ最短パスであるのでゲートウェイ G2 にネットワーク X のためのトラフィックを直接送信 するためにホストに助言します。
4. ゲートウェイは宛先にオリジナルデータパケットを転送します。
今 ASIC レベルでレイヤ2 およびレイヤ3 両方パケット転送を行えるレイヤ3スイッチがそれは ICMP の利点が両方ともネットワークによって機能性を、（a）遅延の機能強化および（b）ネットワークリソース 利用のリダクション リダイレクトすること、実現します完了することができ、マルチポイント イーサネット セグメントのパス最適化手法への多くの注意を持つこれ以上の必要がありません。
ただし、レイヤ3 で有効に されて ICMP リダイレクト 機能性がこの資料の Nexus プラットフォーム Considerations セクション 以降で説明されるように、マルチポイント イーサネット セグメントを通って、最適でない フォワーディング潜在的なパフォーマンス上のボトルネックを、のに別の理由で示しインターフェイスします続けます。
イーサネットネットワークを通した準最適なパス
Open Shortest Path First（OSPF）のような Interior Gateway Protocols （IGP）は、（OSFP）および Cisco 拡張内部ゲートウェイ ルーティング プロトコル（EIGRP）、ルータ間のルーティング情報を同期し、そのような情報に名誉を与えるすべてのネットワーク ノードで一貫した、予想できるパケット転送 動作を提供するように設計されています。 セグメントのすべてのレイヤ3 ノードが同じルーティング情報を使用し、宛先への同じ出力点に一致すればマルチポイント イーサネットネットワークを一例として奪取 して、そのようなネットワークを渡る最適でない フォワーディングはまれに事実ではないです。
レイヤ3 ノードがパケット転送決定を互いから独立したようにすることをどんなにより最適でない フォワーディングパスを引き起こすか理解するために、覚えて下さい。 すなわち、ルータ B によってなされるパケット転送決定はルータ A.によってなされたパケット転送決定に左右されません。 これはマルチポイント イーサネットネットワークの最適でない フォワーディングパスを調査するときパケット転送を IP ネットワークによってトラブルシューティングするとき覚えるべきキー プリンシパルの 1 つで、留意するべき重要な 1 です。
、最適でない フォワーディングをマルチポイント イーサネット セグメントを通してエンドポイント間のトラフィックを渡すためにすべてのルータが単一 ダイナミック ルーティング プロトコルに頼るネットワークで上記されるように起こるべきではないです。 ただし、さまざまなパケット ルーティングおよび転送メカニズムの組み合せを見つけるために現実の世界ネットワークでそれは非常によくあります。 そのようなメカニズムの例はさまざまな IGP、スタティック ルーティング ポリシーベース ルーティング（PBR）であり。 これらの機能が一般的に ネットワークによって望ましいトラフィック フォワーディングを実現させるのに併用されています。
これらのメカニズムの結合された使用がトラフィックフローを最適化し、特定のネットワーク設計の必要条件を満たすのを助けることができる間、これらのツールがマルチポイント イーサネットネットワークで一緒に引き起こす場合がある見落とし副次的影響は悪く全面的なネットワークパフォーマンスという結果に終るかもしれません。
スタティック ルーティング
これを説明するために、ピクチャ 4.ルータ A のシナリオを持っていますネクスト・ホップとしてルータ B とのネットワーク X にスタティック ルートを考慮して下さい。 同時にルータ B はネットワーク X.にスタティック ルートでネクスト・ホップとしてルータ C を使用します。
トラフィックがルータ A でこのネットワークに入る間、それをルータ C によって残し、宛先ネットワーク X に結局、パケット宛先に方法のこの IPネットワークを二度交差させなければなりません送られます。 これはネットワークリソースの effiencient 使用ではないです。 その代り、ルータ C へルータ A からパケットを直接送信 することはより少ないネットワークリソースを消費している間同じ結果を実現させます。
ポリシー ベース ルーティング
Policy Based Routing（PBR）はイーサネットネットワークを通して準最適なパスを引き起こす場合があるもう一つのメカニズムです。 ただし、スタティック または ダイナミック ルーティングとは違って、PBR はルーティング テーブル レベルで動作しません。 その代り、それはスイッチ ハードウェアでトラフィック リダイレクト Access Control List （ACL）を直接プログラムします。 その結果、選定されたトラフィックフローのために、入力 ラインカードのパケット転送 ルックアップはスタティック または ダイナミック ルーティングによって得られるルーティング情報をバイパスします。
ピクチャ 5 では、ルータ A および B はダイナミック ルーティング プロトコルの 1 つを使用して宛先ネットワーク X についてのルーティング情報を交換します。 両方ともこのネットワークに最もよいネクスト・ホップであるルータ B に一致します。
ただし、無効になるルータ B の PBR 設定とルーティング情報はルーティング プロトコルから受け取り、ネクスト・ホップとしてネットワーク X にルータ C を設定 します、これからの プロセスのための条件は ICMP リダイレクト 機能会いますおよびルータ B の CPU に送信 される パケット gets を引き起こします。
ポイント ツー ポイントリンクの ICMP リダイレクト
これまではこの資料は接続する 3 つの（または多く）レイヤ3 ノードがあるイーサネットネットワークをそれ故にネーム マルチポイント イーサネットネットワーク示しました。 ただし ICMP リダイレクト メッセージがポイントツーポイント イーサネット リンクで同様に生成することができることわかっていてであって下さい。
ルータ B にルータ A.を指すネットワーク X にスタティック ルートがあるがピクチャ 6.ルータ A 使用静的デフォルト ルートのシナリオがルータ B にトラフィックを送信 すると考慮して下さい。
小さい顧客の環境をサービスプロバイダー ネットワークに接続するときこの設計 オプション、別名単一ホーム接続は、普及した選択です。 ここにルータ B は Provider Edge （PE） デバイスであり、ルータ A は Customer Edge （CE） デバイスです。
典型的な CE 設定が Null0 インターフェイスを指す顧客 IP アドレス ブロックに集約スタティック ルートが含まれていることに注目して下さい。 この設定はスタティック ルーティングを用いる単一ホーム CE-PE 接続 オプションのための推奨される最良の方法です。 ただしこの例のそのような設定がないことを、なぜなら目的仮定して下さい。
ルータ A がピクチャに示すようにネットワーク X に接続を失うことを仮定して下さい。 カスタマ ネットワーク Y またはリモートネットワーク Z からのパケットがネットワーク X に到着することを試みる場合値が 1 つに達する、その時点でパケットのそれ以上のルーティングが可能性のあるではないまでルータ A および B は互いの間でトラフィックを跳ねま、各パケットの IP 存続可能時間 フィールドを減少します。
ICMP リダイレクトがポイントツーポイント PE-CE 接続の 1 つまたは両側で有効に なる場合 PE および CE ルータ間のネットワーク X バウンスへのトラフィックはあちこちに、劇的に（および不必要に）増加する CE-PE リンク帯域幅 利用、問題より悪くなるが、この場合。 この場合ネットワーク X に向かう ICMP リダイレクト メッセージの生成を助ける対応した ルータ複数回の CPU でフローの各パケットは処理されます。
Nexus プラットフォーム考慮事項
ICMP リダイレクトがレイヤ3 インターフェイスで有効に なり、着信 データが入力および出力 Layer3 スイッチに両方パケットこのインターフェイスを使用するとき、ICMP リダイレクト メッセージは生成されます。 レイヤ3 パケット転送はハードウェア Nexus 7000 プラットフォームで on Cisco 行われる間、今でも ICMP リダイレクト メッセージを組み立てるスイッチの CPU の責任です。 これをするために、Nexus 7000 監視プログラムモジュールの CPU はネットワークセグメントを通したパスが最適化することができるフローの IP アドレス 情報を得る必要があります。 これは監視プログラムモジュールに入力 ラインカードによって送信 される データパケットの背後にある原因です。
ICMP リダイレクト メッセージの受信者によってがそれを無視し、ICMP リダイレクトが有効に なる Nexus スイッチのレイヤ3 インターフェイスにデータ トラヒックが進めば、ICMP リダイレクト生成プロセスは各データパケットのために引き起こされます。
ラインカード レベルでプロセスはハードウェア転送 例外の形で開始します。 例外は ASIC でパケット転送 オペレーションがラインカード モジュールによって正常に完了することができないとき上がります。 この場合、データパケットは正しいパケット処理のための監視プログラムモジュールに送られる必要があります。
監視プログラムモジュールの CPU は出典に ICMP リダイレクト メッセージを送った後、出力 ラインカード モジュールを通してネクスト ホップに転送データ パケットによって例外処理を完了します。
Nexus 7000 監視プログラムモジュールが大きいトラフィック量を処理することができる強力なCPU プロセッサを使用する間、パケット転送 プロセスの実行スーパバイザの CPU プロセッサなしで水平なラインカードでデータトラフィックのほとんどを処理するように、プラットフォームは設計されています。 これは CPU がラインカードで専用ハードウェア エンジンにパケット転送 オペレーションを任せるコア タスクに焦点を合わせるようにします。
安定したネットワークでは、発生すれば、パケット転送例外はで起こると適度に低いレート期待されます。 この想定を使うと、それらはパフォーマンスの重大な影響なしで Supervisor CPU によって処理することができます。 一方では、高い率に非常に発生するパケット転送例外を除く CPU 取り引きを持っていることは総合 システム 安定性および responsivness に対する悪影響をもたらす場合があります。
Nexus 7000 プラットフォーム 設計は相当数のトラフィック圧倒からスイッチ CPU を保護するためにいくつかのメカニズムを提供します。 これらのメカニズムはシステムの異なるポイントで設定されています。 ラインカード レベルで、ハードウェア 比率振幅制限器およびコントロール プレーン ポリシング（CoPP）機能があります。 両方の一定トラフィックレートしきい値、効果的に制御トラフィック量転送されるべき各ラインカード モジュールからのスーパバイザに。
これらの保護メカニズムはネットワーク 安定性のために重要、管理性を、OSPF、BGP または SSH のような切り替えるさまざまな制御プロトコルのトラフィックにプリファレンスを与えます、積極的にスイッチのコントロール プレーン 機能性に重要ではないトラフィックの種類をフィルタリングしている間。 データトラフィックのほとんどはそのようなメカニズムによって、場合パケット転送例外の結果として CPU に転送された、重くポリシングが行われます。
ハードウェア 比率振幅制限器および CoPP ポリシングがメカニズム スイッチのコントロール プレーンの安定性を強く提供し、常に有効に なるために推奨される間、ネットワークを渡るデータパケット ドロップ、転送 遅延および全面的で悪いアプリケ− ションパフォーマンスの主な理由の 1 つである場合もあります。 こういうわけでできたりおよび/または使用すると期待されるネットワーク設備を監察するためにトラフィックフローがネットワークおよび持っているツールを通って奪取 する知識パスは ICMP リダイレクト 機能性重要です。
モニタリングおよび診察道具
show ip traffic
Cisco IOS と 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 に出入してトラフィック フローをキャプチャ する組み込みツールがあります。
ピクチャ 7 はピクチャ 3.のものと同じようなシナリオを示します。 ここにネットワーク X は 192.168.0.0/24 ネットワークと取替えられます。
ホスト 10.0.0.100 は宛先 IP アドレス 192.168.0.1 に ICMPエコー要求の連続ストリームを送信します。 リモートネットワーク 192.168.0.0/24 へのネクスト ホップとして Nexus 7000 スイッチのホスト使用 Switch Virtual Interface （SVI） 10。 デモ ンストレーション目的で、ホストは ICMP リダイレクト メッセージを無視するために cofigured。
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エコー（PING）要求
- 第 2 パケットはゲートウェイによって生成される ICMP リダイレクト パケットです。 このパケットはホストに送返されます。
2018-09-15 23:45:40.128611 10.0.0.1 - > 10.0.0.100 ICMP リダイレクト（ホストのためのリダイレクト）
- 第 3 パケットは CPU によってルーティングされた後出方向でキャプチャ される データパケットです。 しかし上で示されていなくて、このパケットに減少される計算し直される IP TTL およびチェックサムがあります。
2018-09-15 23:45:40.128659 10.0.0.100 - > 192.168.0.1 ICMPエコー（PING）要求
異なる型およびフローの多くのパケットを持っている Ethanalyzer 大きいキャプチャを通ってナビゲート して いる間、データ トラヒックに ICMP リダイレクト メッセージを関連させることは容易ではないかもしれません。
この場合、部分最適に転送されたトラフィックフローについての情報を検索する ICMP リダイレクト メッセージのフォーカス。 ICMP リダイレクト メッセージはオリジナル データグラムのデータの最初の 64 ビットとインターネット ヘッダが含まれています。 データグラムの出典によってこのデータが適切なプロセスにメッセージを一致させるのに使用されています。
ICMP リダイレクト メッセージのコンテンツを表示する、部分最適に転送されるデータフローの IP アドレス 情報を見つけるのに Detail キーワードと Ethanalyzer パケットキャプチャ ツールを使用して下さい
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, should be 0xcae1]
Identifier: 0xa01d
Sequence number: 36096 (0x8d00)
...
ICMP リダイレクトのディセーブル化
ネットワーク設計がスイッチかルータを入力した同じレイヤ3 インターフェイスからのルーティングされるへのトラフィックフローを必要とすれば、フローが CPU によって明示的に 対応 レイヤ 3 インターフェイスことをの ICMP リダイレクト 機能性を無効に することによってルーティングされることを防ぐことは可能性のあるです。
実際、なぜならほとんどのネットワークそれは予防的に、Port-Channel および SVI インターフェイスのようなイーサネットインターフェイスおよびバーチャルのように、物理的 な両方すべてのレイヤ3 インターフェイスの ICMP リダイレクトを、無効に する 好ましい習慣です。 レイヤ3 インターフェイスの ICMP リダイレクトを無効に する no ip redirects NX-OS interface-level コマンドを使用して下さい。 ICMP リダイレクト 機能性が無効に なることを確認するために次の手順に従って下さい
- no ip redirects コマンドを追加されますインターフェイスコンフィギュレーションに確認して下さい
Nexus7000# show run interface vlan 10 interface Vlan10
no shutdown no ip redirects ip address 10.0.0.1/24
Nexus7000#
- 「無効に なった」ことをインターフェイスの ICMP リダイレクトのステータスが示すようにして下さい
Nexus7000# show ip interface vlan 10 | include redirects IP icmp redirects: disabled Nexus7000#
- ICMP リダイレクトが「NX-OS ソフトウェアコンポーネントによって 0" にフラグを設定 されるスイッチのスーパバイザからのより多くのラインカードの 1 つへのそのプッシュ インターフェイスコンフィギュレーション有効または無効にするようにして下さい
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 Nexus7000#
- ICMP リダイレクトが「1つ以上のラインカードの 0" に特定のレイヤ3 インターフェイスのためのフラグを設定 される有効または無効にするようにして下さい
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
module-7#
要約
ICMP は、RFC 792 に記述されているように、メカニズムを設計されていましたマルチポイント ネットワークセグメントを通してフォワーディングパスを最適化するようにリダイレクトします。 当初インターネットのリンク帯域幅およびルータの CPU サイクルのような高いネットワークリソースを、節約するために助けられるそのような最適化。
ネットワーク帯域幅がより現実的でなったと同時に、に使用した比較的より遅い CPU ベース パケット ルーティングに専用ハードウェア ASIC のより速いレイヤ3 パケット転送に、最適データ中継の重要性減少したマルチポイント ネットワークセグメントを通って展開しネットワーク設計者の同様に多くの関心を今日引いていません。
デフォルトで、ICMP リダイレクト 機能性は各レイヤ3 インターフェイスで有効に なります。 ただし、最適フォワーディングパスについてのマルチポイント イーサネット セグメントのネットワーク ノードを知らせる試みはネットワーク人員によって常に理解されないし、行動されます。
さまざまな転送メカニズムの結合された使用のネットワークでは、ICMP リダイレクト 機能性を適切なモニタリングなしでイネーブルのままにするスタティック ルーティングのようなプロダクション トラフィックを処理するために、ダイナミック ルーティングは通過 ノード CPU の望ましくない使用という結果に Policy Based Routing（PBR）終り。 これにより、それから、プロダクション トラフィック トラフィック フローとネットワークインフラストラクチャのコントロール プレーン 安定性の重大な影響を引き起こすかもしれません。
ほとんどのネットワークに関してはそれは予防的に ネットワークインフラストラクチャのすべてのレイヤ3 インターフェイスの ICMP リダイレクト 機能性を無効に する 好ましい習慣とみなされます。 これはよりよいフォワーディングパスが mutli 点のネットワークセグメントを通ってあるときレイヤ3スイッチおよびルータの CPU で処理される本番データ トラフィックのシナリオを防ぐのを助けます。
フィードバック