アカウントをお持ちの場合

  •   パーソナライズされたコンテンツ
  •   製品とサポート

アカウントをお持ちでない場合

アカウントを作成

GRE および IPsec での IP フラグメンテーション、MTU、MSS、PMTUD の問題の解決

ダウンロード オプション

  • PDF     (472.2 KB)
    Adobe Reader を使ってさまざまなデバイスで表示
  • ePub     (326.8 KB)
    iPhone、iPad、Android、ソニーの Reader、または Windows Phone 上で、さまざまなアプリを使って表示
  • Mobi (Kindle)     (936.1 KB)
    Kindle デバイスで、または Kindle アプリを使って複数のデバイスで表示
Updated: 2019 年 1 月 8 日
Document ID:25885
翻訳について

翻訳について

シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。 ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。 シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。

    概要

    このドキュメントでは、IPv4 フラグメンテーションおよび Path Maximum Transmission Unit Discovery（PMTUD; パス最大転送ユニット ディスカバリ）の仕組みを示し、IPv4 トンネルの異なる組み合わせとともに使用される場合の PMTUD の動作に関連するシナリオについて説明します。 インターネットで現在広く普及した IPv4 トンネルの利用により、IPv4 フラグメンテーションおよび PMTUD に関連する問題が顕在化しています。

    IPv4 フラグメンテーションおよびリアセンブル

    IPv4 プロトコルは、さまざまな伝送リンク上で使用する設計になっています。 IPv4 データグラムの最大長は 65535 ですが、ほとんどの伝送リンクでは Maximum Transmission Unit（MTU; 最大伝送ユニット）と呼ばれる、より小規模な最大パケット長の制限が適用されます。 MTU の値は伝送リンクの種類によって決まります。 IPv4 では、ルータによる IPv4 データグラムのフラグメント化を必要に応じて許可するため、異なる MTU に対応する設計になっています。 受信側ステーションには、フラグメントを元の完全なサイズの IPv4 データグラムに再構成する役割があります。

    IPv4 フラグメンテーションでは、データグラムが、後に再構成が可能な多数の断片に分割されます。 IPv4 ヘッダー内の「More Fragments」および「Don't Fragment」フラグとともに、IPv4 送信元、宛先、識別番号、合計長、およびフラグメントのオフセット フィールドが IPv4 フラグメンテーションおよび再構成のために使用されます。 Pv4 フラグメンテーションと再構成のしくみについての詳細は、RFC 791 を参照してください。

    図は IPv4 ヘッダーのレイアウトを示しています。

    識別番号は 16 ビットです。これは、データグラムのフラグメントの再構成を支援するために、IPv4 データグラムの送信者によって割り当てられる値です。

    フラグメント オフセットは 13 ビットであり、元の IPv4 データグラムにおけるフラグメントの位置を示します。 この値は 8 バイトの倍数です。

    IPv4 ヘッダーのフラグ フィールドには、制御フラグとして 3 ビット用意されています。 パケットはフラグメント化することができるかどうか判別するので「Don't Fragment」（DF）ビットが PMTUD の中心的役割を担うことに注意することは重要です。

    ビット 0 は予約済で、常に 0 に設定されています。 ビット 1 は DF ビットです（0 =「May Fragment」、1 =「Do Not Fragment」）。 ビット 2 は MF ビット（0 = 「最後のフラグメント」、1 = 「より多くのフラグメント」）です。

    値 予約されるビット 0 ビット 1 DF ビット 2 MF
    0 0 5 月 Last
    1 0 More

    次のグラフィックはフラグメンテーションの例を示します。 すべての IPv4 フラグメントの長さを合計すると、値は元の IPv4 データグラムの長さを 60 超過します。 全体の長さが 60 増大する理由は、最初のフラグメントの後に、3 つの追加 IPv4 ヘッダー（各フラグメントにつき 1 つ）が作成されたからです。

    最初のフラグメントに 0 のオフセットが、このフラグメントの長さです 1500 あります; これには、わずかに変更された元の IPv4 ヘッダーの 20 バイトが含まれます。

    2 番目のフラグメントのオフセットは 185（185 X 8 = 1480）になっています。これは、このフラグメントのデータ部分が、元の IPv4 データグラムの 1480 バイト目から始まるという意味です。 このフラグメントの長さは 1500 です; これには、このフラグメントのために作成された追加の IPv4 ヘッダーが含まれます。

    3 番目のフラグメントのオフセットは 370（370 X 8 = 2960）になっています。これは、このフラグメントのデータ部分が、元の IPv4 データグラムの 2960 バイト目から始まるという意味です。 このフラグメントの長さは 1500 です; これには、このフラグメントのために作成された追加の IPv4 ヘッダーが含まれます。

    4 番目のフラグメントのオフセットは 555（555 X 8 = 4440）になっています。これは、このフラグメントのデータ部分が、元の IPv4 データグラムの 4440 バイト目から始まるという意味です。 このフラグメントの長さは 700 バイトです; これには、このフラグメントのために作成された追加の IPv4 ヘッダーが含まれます。

    元の IPv4 データグラムのサイズを判断できるのは、最後のフラグメントが受け取られたときだけです。

    最後のフラグメント（555）でのフラグメント オフセットによって、元の IPv4 データグラムに 4440 バイトのデータ オフセット値が渡されます。 続いて、最後のフラグメントからのデータ バイトを追加すると（680 = 700 - 20）、元の IPv4 データグラムのデータ部分である 5120 バイトが渡されたことになります。 続いて、次の図に示すように、IPv4 ヘッダーの 20 バイトが追加され、元の IPv4 データグラムと等しいサイズになります（4440 + 680 + 20 = 5140）。

    IPv4 フラグメンテーションに関する問題

    IPv4 フラグメンテーションで不都合が発生する、いくつかの問題があります。 IPv4 データグラムのフラグメント化は、CPU とメモリのオーバーヘッドをわずかに増大させます。 これは送信側用に、また送信側とレシーバ間のパスのルータのために当てはまります。 フラグメントの作成は、単にフラグメント ヘッダーを作成し、元のデータグラムをフラグメントにコピーするだけです。 フラグメントの作成に必要なすべての情報は、ただちに利用できるので、作成は非常に効率的に実行できます。

    レシーバが到着フラグメントのためのメモリを割り当てる必要があり、それら結局フラグメントの 1 つのデータグラムに再び合体するために受け取られるのでフラグメントを再構成するときフラグメンテーションによりレシーバのためのオーバーヘッドを引き起こします。 ホストには、このタスクに費やす時間とメモリ リソースが備わっているため、ホスト側での再構成は問題とはなりません。

    しかし、再組立ては主要なジョブがパケットをできるだけすぐに転送することルータで非常に非能率的です。 ルータはあらゆる時間いっぱいのためのパケットにしがみつくように設計されていません。 また、再構成を実行しているルータでは、使用可能な最大バッファ（18 K）が処理のために選択されます。この理由は、最後のフラグメントが受け取られるまで、元の IPv4 パケットのサイズがわからないからです。

    別のフラグメンテーション問題は廃棄されたフラグメントがどのように処理されるか含みます。 IPv4 データグラムの 1 つのフラグメントが廃棄されると、元のすべての IPv4 データグラムを再送する必要があり、これが再度フラグメント化されます。 ネットワーク ファイル システム（NFS）とこれの例を参照します。 デフォルトでは、NFS には 8192 の読み取りと書き込みのブロックサイズが用意されるので、 NFS IPv4/UDP データグラムはおよそ 8500 バイトになります（NFS、UDP、IPv4 のヘッダーを含む）。 イーサネット（MTU 1500） に接続された送信側ステーションでは、8500 バイトのデータグラムを 6 つにフラグメント化する必要があります。 5 つの 1500 のバイト フラグメントおよび 1 1100 バイト フラグメント。 輻輳しているリンクが原因でこの 6 つのフラグメントのいずれかが廃棄された場合 、元の完全なデータグラムを再転送する必要があります。つまり、さらに 6 つのフラグメントを作成する必要があります。 このリンクで 6 つのパケットのうち 1 つがドロップされるとすると、各 NFS 8500 バイトの元の IPv4 データグラムから、少なくとも 1 つの IPv4 フラグメントがドロップされることになるため、このリンクを介して NFS データを転送できる可能性は低くなります。

    パケット内のレイヤ 4（L4）からレイヤ 7（L7）の情報に基づいて、パケットをフィルタまたは操作するファイアウォールでは、IPv4 フラグメントの適切な処理に失敗する場合があります。 IPv4 フラグメントの順序が入れ替わると、ファイアウォールによって 1 番目以外のフラグメントがブロックされることがあります。この理由は、これらのフラグメントではパケット フィルタに合致する情報が伝送されないからです。 これは、受信側ホストでは元の IPv4 データグラムの再構成が不可能であることを意味します。 不十分な情報を用いる先頭 以外のフラグメントがきちんとフィルタを一致するようにファイアウォールが設定される場合ファイアウォールによる先頭 以外のフラグメント 攻撃は発生する可能性があります。 またパケットが複数のフラグメント及べば、L7 情報によって L4 に基づくいくつかのネットワークデバイス（コンテンツ スイッチ エンジンのような）直接パケットは、そしてデバイスにポリシーを実施するトラブルがあり。

    IPv4 フラグメンテーションの回避： TCP MSSが何をし、どのように動作するのか

    TCP 最大セグメント サイズ（MSS）では、単一の TCP/IPv4 データグラムでホストが受け取るデータの最大量が定義されます。 TCP/IPv4 データグラムは、IPv4 レイヤにおいてフラグメント化される場合があります。 MSS 値は TCP SYN セグメントのだけ TCP ヘッダーのオプションとして送信 されます。 TCP Connection レポートの各側面反対側への MSS 値。 一般に 信じられている 説への反対はホストの間で、MSS 値ネゴシエートされません。 送信 ホストが受信ホストによって報告される MSS と等しいかまたはそれ以下の値に単一 TCP セグメントのデータのサイズを制限するために必要となります。

    もともと MSS とは、単一の IPv4 データグラム内に含まれた TCP データを格納できるように、受信側ステーションに割り当てられたバッファの大きさ（65496 K 以上）を意味するものでした。 MSS はデータの最大セグメント（チャンクその） TCP レシーバ意志がありました受け入れるでした。 この TCP セグメントは、最大 64 K（最大 IPv4 データグラム サイズ）の大きさになり、ネットワーク経由で受信側ホストに転送されるように、IPv4 レイヤでフラグメント化することが可能です。 受信側ホストでは、IPv4 データグラムを再構成してから、完全な TCP セグメントを TCP レイヤに渡します。

    次に 挙げたいくつかのシナリオでは、MSS 値を設定する方法を示します。また、MSS 値により TCP セグメントのサイズを制限することによって、IPv4 データグラムのサイズを制限する方法も示します。

    シナリオ1 は MSS が最初に設定された方法を説明します。 ホストA に 16K およびホスト B のバッファが 8K のバッファあります。 それらは送信 し、MSS 値を受け取り、データを互いに送信 するができるように送信 MSS を調節します。 Host A および Host B では、インターフェイス MTU より大きな（ただし送信 MSS より小さい）IPv4 データグラムをフラグメント化する必要があることに注意してください。この理由は、TCP スタックにより、スタックにある 16 K または 8 K バイトのデータが IPv4 にわたされる可能性があるからです。 ホスト B ケースでは、パケットはトークンリング LAN に得、再度イーサネット LAN に得るために二度、一度フラグメント化できます。

    シナリオ 1

    1. ホストA はホスト B に 16K の MSS 値を送ります。
    2. ホスト B はホストA から 16K MSS 値を受け取ります。
    3. ホスト B は 16K に送信 MSS 値を設定 します。
    4. ホスト B はホストA に 8K の MSS 値を送ります。
    5. ホストA はホスト B から 8K MSS 値を受け取ります。
    6. ホストA は 8K に送信 MSS 値を設定 します。

    TCP 接続のエンドポイントでの IPv4 フラグメンテーションを回避できるようにするため、MSS 値の選択が最小バッファ サイズおよび発信インターフェイスの MTU（- 40）に変更されました。 MSS の数値は、MTU の数値より 40 バイト小さい値です。MSS が、20 バイトの IPv4 ヘッダーと 20 バイトの TCP ヘッダーを含まない TCP データのサイズと同じであることが、この理由です。 MSS はデフォルトヘッダーサイズに基づいています; 送信者スタックでは、使用されている TCP または IPv4 オプションに応じて、IPv4 ヘッダーおよび TCP ヘッダーのための適切な値を差し引く必要があります。

    方法 MSS 今作業は各ホストが最初に自身のバッファの発信インターフェイス MTU を比較し、MSS として送信 するために最も低い値を選択することです。 ホストはそれから自身のインターフェイスのMTU値に対して受け取った MSS サイズを比較し、再度 2 つの値の下部のを選択します。

    シナリオ 2 はローカル および リモート ワイヤーのフラグメンテーションを回避するために送信側が踏むこの追加手順を説明します。 発信インターフェイスの MTU が各ホストによってどのように考慮に入れられるか表記は（ホストの前に、そしてこれがフラグメンテーションの回避を助けるかどのように互いを MSS 値送信 します）。

    シナリオ2

    1. ホストA は MSS バッファ（16K）および MTU を比較します（1500 - 40 は = 1460）および MSS としてより低い値を使用します（1460） ホスト B に送信 するため。
    2. ホスト B はホスト A 送信 MSS を受け取ります（1460） アウトバウンドインターフェイス MTU の値とそれを- 40 比較し、（4422）。
    3. Host B は、Host A に送信する IPv4 データグラムの MSS  として、より低い値（1460）を設定します。
    4. ホスト B は MSS バッファ（8K）および MTU （4462-40 を = 4422）および MSS として使用 4422 ホストA に送信 するため比較します。
    5. ホストA はホスト B 送信 MSS を受け取ります（4422） アウトバウンドインターフェイス MTU -40 の値とそれを比較し、（1460）。
    6. Host A は、Host B に送信する IPv4 データグラムの MSS として、より低い値（1460）を設定します。

    1460 が両方のホストによって、それぞれの送信 MSS として選択された値になります。 多くの場合送信 MSS 値は TCP 接続の各端に同じです。

    シナリオ 2 では、フラグメンテーションは TCP 接続のエンドポイントで両方発信インターフェイス MTU がホストによって考慮に入れられるので行われません。 パケットはまだどちらかのホストのアウトバウンドインターフェイスのそれより少ないMTU のリンクに出会う場合ルータ A とルータ B 間のネットワークでフラグメント化されるようになることができます。

    PMTUD の概要

    先に記述されているように TCP MSS は TCP 接続の 2 つのエンドポイントでフラグメンテーション処理しますが、これら二つのエンドポイント間の中央により小さい MTU リンクがあるケースを処理しません。 PMTUD はエンドポイント間のパスのフラグメンテーションを回避するために開発されました。 動的にパケットの出典からの宛先にパスに沿う最も低い MTU を判別することを使用します。

    注: PMTUD は TCP および UDP によってだけサポートされます。 他のプロトコルはそれをサポートしません。 PMTUD がホストでイネーブルになっており、ほぼ常にその状態であると、ホストからのすべての TCP および UDP パケットには DF ビットが設定されます。 

    ホストが DF ビットが設定が付いている完全な MSS データパケットを送信 するとき、PMTUD はパケットはフラグメンテーションを必要とすること情報を受け取る場合接続の送信 MSS 値を下げます。 ホストは通常宛先のこの MTU 値でルーティング テーブルの「ホスト」（/32 の）エントリを作成するので MTU 値を「覚えています」。

    ルータが、パケット サイズより低い MTU を持つリンクへ、DF ビットが設定された IPv4 データグラムの転送を試みる場合には、このルータ はパケットを廃棄し、「Fragmentation Needed and DF set」（タイプ 3、コード 4）を示すコードとともに、Internet Control Message Protocol（ICMP; インターネット制御メッセージ プロトコル）の「Destination Unreachable」メッセージをこの IPv4 データグラムの発信元に返します。 ソースステーションは ICMP メッセージを受け取る場合、送信 MSS を下げ、TCP はセグメントを再送信する場合、より小さいセグメント サイズを使用します。

    debug ip icmp コマンドがついた後ルータで見るかもしれない ICMP " fragmentation needed and DF set " メッセージの例はここにあります:

    ICMP: dst (10.10.10.10) frag. needed and DF set 
unreachable sent to 10.1.1.1

    このダイアグラムは」" Destination Unreachable " メッセージを設定 するのに必要とされる「フラグメンテーションおよび DF の ICMPヘッダーの形式を示します。

    RFC 1191によると、「Fragmentation Needed and DF set」を示す ICMP メッセージを返すルータでは、ICMP 仕様の RFC 792 で「unused」とラベル付けされている ICMP 追加ヘッダー フィールド下位 16 ビット内に、ネクストホップ ネットワークの MTU が含まれる必要があります。

    RFC 1191 の早期 実施はネクスト ホップ MTU 情報を提供しませんでした。 この情報が提供された時でさえ、いくつかのホストはそれを無視します。 このケースに関しては、RFC 1191 はまた MTU が PMTUD の間に下げる必要がある推奨値をリストする表が含まれています。 次の図で示すように、送信 MSS の適切な値でより高速に着信させるため、これはホストによって使用されます。

    PMTUD はすべてのパケットで送信側とレシーバ間のパスが動的に変更できるので絶えずされます。 送信側が（PMTUD を保存するかところ）ルーティング情報をアップデートする ICMP メッセージを「フラグメント化」できない受け取るたびに。

    2 つの可能性のある 事柄は PMTUD の間に起こる場合があります:

    1. パケットはレシーバにフラグメント化しないでずっと到達できます。

    注: DoS攻撃から CPU を保護するルータのためにそれは 2 毎秒に送信 する ICMP 到達不能 メッセージの数を絞ります。 従って以上 2 つの ICMP メッセージ（タイプ = 3 ルータはと対応する必要があると、このコンテキストで、コード = 4） 毎秒（異なるホストはある場合もあります）、IP icmp レート制限 到達不能[df] interface コマンドで ICMP メッセージのスロットリングを無効に したいと思います期待しないネットワークシナリオがあれば。

    2. 送信側はパスに沿うあらゆる（または各）ホップからレシーバに ICMP " Can't Fragment " メッセージを得ることができます。

    PMTUD は TCP フローの両方向のために独自にされます。 フローの片方の PMTUD では、エンド ステーションによる送信 MSS の低下がトリガーされ、もう片方のエンドステーションでは元の送信 MSS が保持される場合があります。この理由は、PMTUD をトリガするだけの大きさを持つ IPv4 データグラムが送信されていないからです。

    これのよい例はシナリオ 3.で下記に描写される HTTP接続です。 TCP クライアントは小さいパケットを送信し、サーバは大きいパケットを送信します。 この場合、サーバの大きいパケットだけ（576 バイト以上）引き起こします PMTUD を。 クライアントのパケットはフラグメンテーションが 576 MTU リンクを渡って得るように要求しないので小さく（576 バイト以下）、引き起こしません PMTUD を。

    シナリオ 3

    パスの 1 つに他より MTU 小さい最小がどこにあるかシナリオ 4 は非対称 ルーティング例に示します。 非対称 ルーティングは 2 つのエンドポイント間のデータを送信 し、受け取るために異なるパスが選択されるとき実行されます。 このシナリオでは、PMTUD は TCP フローの 1 方向のだけ送信 MSS の低下を引き起こします。 TCP クライアントからのサーバへのトラフィックはルータ A およびルータ B をサーバからクライアントに来るリターントラフィックがルータ D およびルータ C をフローする一方、フローします。 TCP サーバがクライアントにパケットを送信する場合、PMTUD はルータ C にそれらを送信できる前にルータ D が 4092 のバイトパケットをフラグメント化する必要があるので送信 MSS を下げるためにサーバを引き起こします。

    クライアントは、一方では、決してルータ B.を通してサーバにそれらを送信 する場合ルータ A がならない断片化パケットので「設定 するのに」必要とされるフラグメンテーションおよび DF を示すコードの ICMP " Destination Unreachable " メッセージを受け取りません。

    シナリオ 4

    注: ルータ（たとえば、BGP および Telnet）によって開始された TCP 接続のための TCP MTU パス ディスカバリを有効にするためには、ip tcp path-mtu-discovery コマンドが使用されます。

    PMTUD における問題

    2 つが珍しく、そのうちの一つがよくある PMTUD を壊すことができる 3 つの事柄があります。

    • ルータはパケットを廃棄し、ICMP メッセージを送信なできます。 （珍しい）

    • ルータは ICMP メッセージを生成し、送信できますが ICMP メッセージはこのルータと送信側間のルータかファイアウォールによってブロックされます。 （コモン）

    • ルータは ICMP メッセージを生成し、送信できますが送信側はメッセージを無視します。 （珍しい）

    上記 3 項目の最初と最後の項目は一般的ではなく、通常はエラーの結果ですが、2 番目の項目は一般的な問題を示しています。 ICMPパケット フィルタを実装する人々はがちである特定の ICMP メッセージ タイプをブロックしますただよりもむしろすべての ICMP メッセージ タイプをブロックし。 パケットフィルタは「到達不能」または「時間超過」。であるパケットフィルタを除くすべての ICMP メッセージ タイプをブロックできます PMTUD が成功したか、失敗したかは、TCP/IPv4 パケットの送信者に到着する ICMP の unreachable メッセージで判定されます。 ICMP の time-exceeded メッセージは、その他の IPv4 問題にとって重要なものです。 ルータで設定されるそのようなパケットフィルタの例はここに示されています。

    access-list 101 permit icmp any any unreachable
access-list 101 permit icmp any any time-exceeded
access-list 101 deny icmp any any
access-list 101 permit ip any any

    ICMP が完全にブロックされてしまうという問題の緩和に役立つ手法が他にもあります。

    • ルータの DF ビットをクリアし、フラグメンテーションをとにかく許可して下さい（これはしかしよい概念ではないかもしれません。 詳細については IP フラグメンテーションにおいての問題を参照して下さい）。

    • interface コマンド IP TCP adjust-mss <500-1460> の TCP MSS オプション値 MSS を処理して下さい。

    次のシナリオでは、ルータ A およびルータ B は同じ管理ドメインにあります。 ルータ C は得難く、ICMP をブロックします、従って PMTUD は壊れています。 この状況のための回避策はフラグメンテーションを許可するためにルータ B の両方向の DF ビットをクリアすることです。 これはポリシー ルーティングとすることができます。 DF ビットをクリアする構文は Cisco IOS® ソフトウェアリリース 12.1(6) およびそれ以降で利用できます。

    interface serial0 
... 
ip policy route-map clear-df-bit 
route-map clear-df-bit permit 10 
	match ip address 111 
	set ip df 0 
 
access-list 111 permit tcp any any

    別のオプションは、ルータを通過する SYN パケット上の TCP MSS オプションの値を変更することです（Cisco IOS® 12.2(4)T 以降で使用可能）。 これはように値より小さい TCP 同期信号 パケットの MSS オプション値を下げます（1460） ip tcp adjust-mss コマンドで。 結果は TCP 送信側がセグメント化するこの値より大きい送信 しないことです。 IPv4 パケットのサイズは、TCP ヘッダー（20 バイト）と IPv4 ヘッダー（20 バイト）を加えて、MSS 値（1460 バイト）より 40 バイト大きくなります（1500）。

    ip tcp adjust-mss コマンドで TCP Syn パケットの MSS を調節できます。 この構文は 1460 に TCP セグメントの MSS 値を下げます。 このコマンドはインターフェイス serial0 で受信および送信 トラフィックに影響します。

    int s0 
ip tcp adjust-mss 1460

    IPv4 トンネルがより広く普及するようになったのに従い、IPv4 フラグメンテーションの問題がさらにまん延するようになりました。 トンネルによりより多くのフラグメンテーションを引き起こすという原因はトンネルカプセル化がパケットのサイズに「オーバーヘッド」を追加するということであるといえます。 たとえば、Generic Routing Encapsulation（GRE; 総称ルーティング カプセル化）の付加により、24 バイトがパケットに追加されます。そして、この増加によって、パケットが発信側 MTU より大きくなり、フラグメント化が必要になる場合があります。 このドキュメントの後のセクションで、トンネルと IPv4 フラグメンテーションによリ発生する種類の問題を、例を挙げて説明しています。

    PMTUD を必要とする一般的なネットワークトポロジ

    PMTUD は中間リンクに終わりリンクの MTU より小さい MTU があるネットワーク 状況で必要とされます。 これらのより小さい MTU リンクのプロシージャのための一般的な原因は次のとおりです:

    • トークン リング（か FDDI） -その間のイーサネット接続の接続されたエンドホスト。 トークン リング（か FDDI）端に MTU 中央のイーサネット MTU より大きいです。

    • PPPoE は（ADSL と頻繁に使用される）ヘッダのための 8 バイトを必要とします。 これは 1492 にイーサネットの有効な MTU を減らします（1500 - 8）。

    GRE、IPv4sec、および L2TP などのトンネリング プロトコルでも、それぞれのヘッダーとトレーラのための領域が必要です。 これもまた、発信インターフェイスの有効 MTU を低下させます。

    次の セクションでは、トンネリング プロトコルが両端ホストの間でだいたい使用される PMTUD の影響は調査されます。 3 つの前のケースの、このケースは最も複雑で、その他の場合は見るかもしれない問題すべてをカバーします。

    トンネル

    トンネルは転送 プロトコルの中の乗客パケットをカプセル化する方法を提供する Ciscoルータの論理インターフェイスです。 これは、ポイントツーポイント カプセル化スキームを実装するサービスを提供する設計になっているアーキテクチャです。 トンネリングにこの 3 つの主要コンポーネントがあります:

    • パッセンジャ プロトコル（AppleTalk、Banyan VINES、CLNS、DECnet、IPv4、または IPX）

    • キャリア プロトコル-これらのカプセル化プロトコルの 1 つ:

      • GRE - Cisco のマルチプロトコル キャリア プロトコル。 詳細については RFC 2784 および RFC 1701 を参照して下さい。

      • IPv4 トンネル内の IPv4：詳細は、RFC 2003  を参照してください。

    • トランスポート プロトコル：カプセル化プロトコルを伝送するために使用されるプロトコル

    このセクションで示すパケットは、GRE がカプセル化プロトコルであり、IPv4 がトランスポート プロトコルであるという IPv4 トンネリングの概念を示しています。 また、パッセンジャ プロトコルも IPv4 です。 この場合、IPv4 はトランスポート プロトコルおよびパッセンジャ プロトコル両方です。

    正常なパケット

    IPv4 TCP Telnet

    トンネルパケット

    IPv4 GRE IPv4 TCP Telnet

    • IPv4 はトランスポート プロトコルです。

    • GRE はカプセル化プロトコルです。

    • IPv4 はパッセンジャ プロトコルです。

    次の例では、キャリアとして GRE を使った、パッセンジャ プロトコルとしての IPv4 および DECnet のカプセル化を示しています。 これは、図に示すように、キャリア プロトコルによって複数のパッセンジャ プロトコルのカプセル化が可能であることを示しています。

    IPv4 バックボーンによって隔てられた 2 つの非隣接の非 IPv4 ネットワークが存在する状況では、ネットワーク管理者はトンネリングを検討することができます。 非近接 ネットワークが DECNet を実行する場合、管理者はバックボーンの DECNet の設定によってそれらを接続したいと思わないかもしれません。 管理者は、IPv4 ネットワークのパフォーマンスに影響を及ぼす可能性があるため、バックボーン帯域幅を消費する DECnet ルーティングを許可したくない場合があります。

    実行可能な代案は、IPv4 バックボーンを介して DECnet をトンネル化することです。 トンネリングによって IPv4 内部に DECnet パケットがカプセル化され、バックボーンを介してカプセル化を外すントンネル エンドポイントに送信されます。また、DECnet を介した DECnet パケットの宛先へのルーティングが可能になります。

    別のプロトコルの中のトラフィックをカプセル化することはこれらの長所を提供します:

    • エンドポイントはプライベートアドレス（RFC 1918）を使用し、バックボーンはこれらのアドレスをルーティングすることをサポートしません。

    • WAN またはインターネットを渡る割り当てバーチャル プライベート ネットワーク（VPN）。

    • シングル プロトコル バックボーン上の一緒の加入 隣接しない マルチプロトコルネットワーク。

    • バックボーンまたはインターネット上の暗号化 トラフィック。

    このドキュメントの残りの部分では、パッセンジャ プロトコルとしての IPv4 とトランスポート プロトコルとしての IPv4 を取り上げます。

    トンネルインターフェイスに関する考慮事項

    これらはトンネル伝送するとき考慮事項です。

    • Cisco IOS® リリース 11.1 で、GRE トンネルのファースト スイッチングが導入されました。また、バージョン 12.0 では、CEF スイッチングが導入されています。 マルチポイント GREトンネルのための CEF スイッチングはバージョン 12.2(8)T でもたらされました。 トンネル エンドポイントでのカプセル化とカプセル化解除は、プロセス交換だけがサポートされていた Cisco IOS® の初期バージョンでは処理が低速でした。

    • パケットをトンネル伝送するときセキュリティ および トポロジーの問題があります。 トンネルはアクセス コントロール リスト（ACL）およびファイアウォールをバイパスできます。 ファイアウォールによってトンネル伝送する場合、どんなパッセンジャープロトコルをトンネル伝送している基本的にファイアウォールをのためのバイパスします。 したがって、パッセンジャ プロトコルで任意のポリシーを実施するために、トンネルのエンドポイントにファイアウォール機能を備えることが推奨されます。

    • トンネリングは高められた レイテンシーが理由でタイマーを（たとえば、DECNet）制限した転送 プロトコルで問題を引き起こすかもしれません。

    • 異なる速度リンクの、ファースト FDDIリングのようなおよび遅い 9600 ビット/秒電話線を通した環境を渡ってトンネル伝送して、問題を追加注文するパケットを導入するかもしれません。 いくつかのパッセンジャープロトコルは混合メディア ネットワークで不完全に機能します。

    • ポイントツーポイントトンネルは物理リンクの帯域幅を使うことができます。 複数のポイントツーポイントトンネル上のルーティング プロトコルを用いる場合、各トンネルインターフェイスに帯域幅があること、そしてトンネルが動作する物理インターフェイスに帯域幅があることに留意して下さい。 たとえば 10 Mb リンクに動作する 100 つのトンネルがあった場合、100 Kb にトンネル帯域幅を設定 したいと思います。 トンネルのためのデフォルト帯域幅は 9Kb です。

    • ルーティング プロトコルで、「実」リンクを介したトンネルが優先される場合があります。この理由は、トンネルが、最も低いコスト パスを持つ 1 ホップ リンクであるように誤って認識されるためです。ところが、実際はトンネルにはそれ以上のホップが含まれ、他のパスよりも非常にコスト高です。 これはルーティング プロトコルの適切な設定と軽減することができます。 物理インターフェイスで動作するルーティング プロトコルよりトンネルインターフェイス上の別のルーティング プロトコルを作動させることを考えたいと思うかもしれません。

    • 再帰的ルーティングにおける問題はトンネル宛先への適切な統計ルーティングの設定によって回避することができます。 再帰ルーティングとは、トンネル宛先へのベスト パスがトンネル自体を通っている場合を指します。 この状況によりトンネルインターフェイスは上下にバウンスします。 再帰的ルーティングの問題がある場合このエラーが表示されます。

      %TUN-RECURDOWN Interface Tunnel 0
temporarily disabled due to recursive routing

    トンネルのエンドポイントにおいて PMTUD 参加者に関与するルータ

    それがトンネルのエンドポイントのときルータに果たすべき 2 つの異なる PMTUDの役割があります。

    • 1 番目の役割では、ルータはホスト パケットを転送します。 PMTUD 処理に関しては、ルータは必要なときオリジナルデータパケットの DF ビットおよびパケットサイズをチェックし、適切な行動を奪取 する必要があります。

    • 2 番目の役割は、ルータがトンネル パケット内に元の IPv4 パケットをカプセル化した後、実行されます。 この段階では、ルータは PMTUD およびトンネル IPv4 パケットに関して、ホストのような動作をします。

    PMTUD に関して 、ホスト IPv4 パケットを転送する 1 番目の役割でルータが動作している場合の状況について解説します。 この役割は、ルータがトンネル パケット内にホスト IPv4 パケットをカプセル化する前に実行されます。

    ホスト パケットのフォワーダがそれこれらの操作を完了するのでルータが加われば:

    • DF ビットが設定されているかどうかの確認

    • トンネルが対応できるパケット サイズの確認

    • フラグメント（パケットが余りに大きく、DF がビット 設定 されなければ）、カプセル化するフラグメントおよび送信; または

    • パケットのドロップ（パケットが大きすぎて DF ビットが設定されている場合）および送信者への ICMP メッセージの送信

    • カプセル化（パケットが大きすぎない場合）および送信

    一般的に次に次に、カプセル化の選択がおよびフラグメンテーション（送信 2 つのカプセル化フラグメント）またはフラグメンテーションおよびカプセル化（送信 2 つのカプセル化されたフラグメント）あります。

    次のいくつかの例では、IPv4 パケット カプセル化とフラグメント化のしくみ、および、例として挙げられたネットワークを通過するパケットと PMTUD とのインタラクションを示す 2 つのシナリオを説明します。

    ルータが転送ルータのロールで（トンネル ソースで）機能するときパケットがどうなるか最初の例に示されています。 PMTUD を処理するためにそれをルータ オリジナルデータパケットの DF ビットおよびパケットサイズをチェックし、適切な行動を奪取 する必要があります忘れないようにして下さい。 この例はトンネルのために GRE カプセル化を使用します。 見られる場合があるように GRE はカプセル化の前にフラグメンテーションをします。 より遅い例はフラグメンテーションがカプセル化の後で行われるシナリオを示します。

    例 1 では DF ビットが設定されておらず（DF = 0）、GRE トンネル IPv4 MTU は 1476（1500 - 24）です。

    例 1

    1. 転送ルータは（トンネル ソースで） DF ビット オフが付いている 1500 バイト データグラムを受け取ります（送信 ホストからの DF = 0）。 このデータグラムは 1480 バイト TCP ペイロードと 20 バイト IP ヘッダーで構成されます。

    IPv4 1480 バイト TCP + データ

     2. GRE オーバーヘッド（24 バイト）が追加されると、パケットは IPv4 MTU に対して大きくなりすぎるため、転送ルータによってデータグラムが 1476 バイト（20 バイトの IPv4 ヘッダー + 1456 バイトの IPv4 ペイロード）および 44 バイト（20 バイトの IPv4 ヘッダー + 24 バイトの IPv4 ペイロード）の 2 つのフラグメントに分割されます。これにより、GRE カプセル化による追加があっても、パケットは発信物理インターフェイス MTU より大きくはなりません。

    IP0 1456 バイト TCP + データ
    IP1 24 バイト データ

     3. 転送ルータでは、GRE カプセル化による追加があります。元の IPv4 データグラムの各フラグメントに対して、4 バイトの GRE ヘッダーと 20 バイトの IPv4 ヘッダーが追加分になります。 これにより、これら 2 つの IPv4 データグラムは 1500 バイトおよび 68 バイトの長さとなります。これらのデータグラムはフラグメントとしてではなく、個々の IPv4 データグラムとして認識されます。

    IPv4 GRE IP0 1456 バイト TCP + データ
    IPv4 GRE IP1 24 バイト データ

    4. トンネルの宛先側ルータでは、GRE カプセル化による付加分が元のデータグラムの各フラグメントから削除され、1476 バイトと 24 バイトの長さの 2 つの IPv4 フラグメントが残されます。 これらの IPv4 データグラム フラグメントは、このルータによって受信側のホストに別々に転送されます。

    IP0 1456 バイト TCP + データ
    IP1 24 バイト データ

    5. 受信側ホストは、これら 2 つのフラグメントを元のデータグラムに再構成します。

    IPv4 1480 バイト TCP + データ

    シナリオ 5 はネットワーク トポロジという点において転送ルータのロールを描写します。

    この例では、ルータは転送ルータと同じ役割を果たしますが、この場合は DF ビットが設定されています（DF = 1）。

    例 2

    1. トンネル ソースの転送ルータは送信 ホストから 1500 バイト データグラムをとの DF = 1 受け取ります。

    IPv4 1480 バイト TCP + データ

    2. DF ビットが設定され、データグラム サイズ（1500 バイト）が GRE トンネル IPv4 MTU（1476）より大きいので、ルータはデータグラムを廃棄し、「ICMP Fragmentation Needed but DF set」メッセージをデータグラムの送信元に送信します。 ICMP メッセージは MTU が 1476 であること送信側を警告 します。

    IPv4 ICMP MTU 1476

    3. 送信側ホストは ICMP メッセージを受け取り、元のデータを送信する際に 1476 バイトの IPv4 データグラムを使用します。

    IPv4 1456 バイト TCP + データ

    4. この IPv4 データグラムの長さ（1476 バイト）は、今回は GRE トンネル IPv4 MTU の値に等しいため、ルータはこの IPv4 データグラムに GRE カプセル化を行います。

    IPv4 GRE IPv4 1456 バイト TCP + データ

    5. （トンネル宛先側の）受信側ルータは、IPv4 データグラムの GRE カプセル化による付加分を削除してから、それを受信側ホストに送信します。

    IPv4 1456 バイト TCP + データ

    次に、PMTUD およびトンネル IPv4 パケットに関して、ルータが送信側ホストとして 2 番目の役割を果たしている場合の状況を説明します。 この役割は、ルータがトンネル パケット内に元の IPv4 パケットをカプセル化した後で実行されることを思い出してください。

    注: デフォルトでは、 ルータは生成する GRE トンネル パケットに対して PMTUD を実行しません。 tunnel path-mtu-discovery コマンドを使用して、GRE-IPv4 トンネル パケットに対して PMTUD を有効にできます。

    例 3 では、GRE トンネル インターフェイス上の IPv4 MTU に収まるほど小さい IPv4 データグラムをホストが送信している場合の状況を示します。 DF ビットはこの場合設定 されるか、またはクリアである場合もあります（1 または 0）。 この GRE トンネル インターフェイスでは tunnel path-mtu-discovery コマンドが設定されていないので、ルータによる GRE-IPv4 パケットへの PMTUD は実行されません。

    例 3

    1. トンネル ソースの転送ルータは送信 ホストから 1476 バイト データグラムを受け取ります。

    IPv4 1456 バイト TCP + データ

    2. このルータでは GRE 内で 1476 バイトの IPv4 データグラムがカプセル化されて、1500 バイトの GRE IPv4 データグラムが作成されます。 GRE IPv4 ヘッダー内の DF ビットはクリアされます（DF = 0）。 このルータはトンネル宛先にそれからこのパケットを転送します。

    IPv4 GRE IPv4 1456 バイト TCP + データ

    3. 1400 のリンク MTU のトンネル ソースと宛先間にルータがあることを仮定して下さい。 このルータは DF ビットがクリアであるのでトンネルパケットを断片化します（DF = 0）。 この例では、最も外側の IPv4 がフラグメント化されるので、GRE、内側の IPv4、および TCP ヘッダーは最初のフラグメントだけに表示されていることを憶えておいてください。

    IP0 GRE IP 1352 バイト TCP + データ
    IP1 104 バイト データ

    4. トンネル宛先ルータは GREトンネルパケットを再構成する必要があります。

    IP GRE IP 1456 バイト TCP + データ

    5. GRE トンネル パケットが再構成されると、ルータは GRE IPv4 ヘッダーを削除し、元の IPv4 データグラムをその宛先に送信します。

    IPv4 1456 バイト TCP + データ

    次の例では、PMTUD およびトンネル IPv4 パケットに関して、ルータが送信側ホストの役割を果たしている場合の状況を説明します。 この場合、元の IPv4 ヘッダー内で DF ビットがセットされ（DF = 1）、tunnel path-mtu-discovery コマンドが設定されているので、内側の IPv4 ヘッダーから外側の（GRE + IPv4）ヘッダーに DF ビットがコピーされます。

    例 4

    1. トンネル ソースの転送ルータは送信 ホストから 1476 バイト データグラムをとの DF = 1 受け取ります。

    IPv4 1456 バイト TCP + データ

    2. このルータでは GRE 内で 1476 バイトの IPv4 データグラムがカプセル化されて、1500 バイトの GRE IPv4 データグラムが作成されます。 元の IPv4 データグラムの DF ビットが設定されているため、この GRE IPv4 ヘッダーでは DF ビットが設定されます（DF = 1）。 このルータはトンネル宛先にそれからこのパケットを転送します。

    IPv4 GRE IPv4 1456 バイト TCP

    3. 再度 1400 のリンク MTU のトンネル ソースと宛先間にルータがあることを、仮定して下さい。 DF ビットが設定されている（DF = 1）ので、このルータではトンネル パケットのフラグメント化が行われません。 このルータはパケットをドロップし、ICMP エラー メッセージをトンネル送信元ルータに送信する必要があります。この理由は、これがパケット上の送信元 IPv4 アドレスであるからです。

    IPv4 ICMP MTU 1400

    4. トンネル送信元の転送ルータは、この ICMP エラー メッセージを受信し、GRE トンネル IPv4 MTU を 1376（1400 - 24）に低下させます。 送信側ホストが次にデータを 1476 バイトの IPv4 パケットで再送信すると、このパケットは大きすぎることになるため、このルータは 1376 の MTU 値を付けて ICMP エラー メッセージを送信者に送ります。 送信側ホストがデータを再送信する際には、1376 バイトの IPv4 パケットで送信し、このパケットは GRE トンネルを介して受信側ホストに到着します。

    シナリオ 5

    このシナリオは GRE フラグメンテーションを説明します。 GRE のカプセル化の前にフラグメント化し、次にデータ パケットの PMTUD を実行することと、IPv4 パケットが GRE によってカプセル化される場合には、DF ビットがコピーされないことを憶えておいてください。 このシナリオでは、DF ビットは設定 されません。 GRE トンネル インターフェイスの IPv4 MTU は、デフォルトでは物理インターフェイスの IPv4 MTU より 24 バイト少ないので、図のように、GRE インターフェイスの IPv4 MTU は 1476 となります。

    1. 送信者は 1500 バイトのパケット（20 バイト IPv4 ヘッダー + 1480 バイトの TCP ペイロード）を送信します。
    2. GRE トンネルの MTU は 1476 なので、1500 バイトのパケットは 1476 バイトと 44 バイトの 2 つの IP フラグメントに分割されます。それぞれの IPv4 フラグメントには、24 バイトの GRE ヘッダーが付加されることを見込んでいます。
    3. 24 バイトの GRE ヘッダーが各 IPv4 フラグメントに付加されます。 この場合フラグメントは 1500 です（1476 + 24）および 68 （44 + 24） バイトそれぞれ。
    4. 2 つの IPv4 フラグメントを含む GRE + IPv4 パケットが、GRE トンネル ピア ルータに転送されます。
    5. GREトンネル ピアルータは 2 つのパケットから GRE ヘッダを削除します。
    6. このルータは宛先ホストに 2 つのパケットを転送します。
    7. 宛先ホストは、この IPv4 フラグメントを元の データグラムに再構成します。

    シナリオ 6

    このシナリオはシナリオ 5 に類似したですが、今回 DF ビットは設定 されます。 シナリオ 6 では、ルータは GRE + IPv4 トンネル パケットに PMTUD を実行するように、tunnel path-mtu-discovery コマンドで設定されています。また、DF ビットは元の IPv4 ヘッダーから GRE IPv4 ヘッダーにコピーされます。 ルータでは、GRE + IPv4 パケットの ICMP エラーを受信すると、GRE トンネル インターフェイス上の IPv4 MTU を低下させます。 再度、デフォルトでは GRE トンネル IPv4 MTU が物理インターフェイス MTU より 24 バイト少なく設定されているので、GRE IPv4 MTU が 1476 であることを思い出してください。 さらに、図に示すように、GRE トンネル パス内に 1400 の MTU リンクが存在することにも注意してください。

    1. ルータは、1500 バイトのパケット（20 バイトの IPv4 ヘッダー + 1480 バイトの TCP ペイロード）を受信し、このパケットをドロップします。 ルータがこのパケットをドロップする理由は、これが GRE トンネル インターフェイス上の IPv4 MTU（1476）よりも大きいためです。
    2. ルータはそれに告げる送信側にネクスト・ホップ MTU が 1476 であることを ICMP エラーを送ります。 ホストはこの情報を、通常のでルーティング テーブルの宛先のためのホスト ルート記録します。
    3. 送信 ホストはデータを送り直すとき 1476 バイト パケットサイズを使用します。 GRE ルータは 24 バイトの GRE カプセル化および初期設定するを 1500 バイト パケット追加します。
    4. 1500 バイト パケットは 1400 バイト リンクを横断できません従って中間ルータによって廃棄されます。
    5. 中間ルータは ICMP （型を = 3、1400 のネクスト・ホップ MTU の GRE ルータへのコード = 4） 送信 します。 GRE ルータでは、これを 1376（1400 - 24）に低下させて、GRE インターフェイスでの内部 IPv4 MTU 値を設定します。 この変更は debug tunnel コマンドを使用するとき見られるただ場合があります; それは show ip interface tunnel<#> コマンドからの出力で見られる場合がありません。
    6. ホストが次に 1476 バイトのパケットを再送信する場合、このパケットは GRE トンネル インターフェイスの現在の IPv4 MTU（1376）より大きいので、GRE ルータはこれをドロップします。
    7. GRE ルータは別の ICMP を送信 します（タイプは = 1376 のネクスト・ホップ MTU の送信側への 3、コード = 4）およびホスト New 値の現在の情報をアップデートします。
    8. ホストは再度データを送り直しますが、今より小さい 1376 バイト パケットで、GRE は 24 バイトのカプセル化を追加し、それを転送します。 今回パケットはパケットが宛先ホストにカプセル化を解除され、送信 される GREトンネル ピアにそれを作ります。

    注: このシナリオにおいて、転送ルータ上で tunnel path-mtu-discovery コマンドが設定されておらず、さらに GRE トンネルを介して転送されたパケット内で DF ビットが設定されている場合、Host 1 は TCP/IPv4 パケットを Host 2 に送信できますが、これらのパケットは途中、1400 MTU リンクでフラグメント化されます。 また GREトンネル ピアはそれらのカプセル化を解除し、転送する可能性がある前にそれらを再構成しなければなりません。

    純粋な IPSec トンネルモード

    IPv4 セキュリティ（IPv4sec）プロトコルは、IPv4 ネットワークを介して転送される情報にプライバシ、整合性、および信憑性を提供する、標準ベースのメソッドです。 IPv4sec では、IPv4 ネットワーク層での暗号化が提供されます。 IPv4sec では、少なくとも 1 つの IPv4 ヘッダー（トンネル モード）が追加されるので、IPv4 パケットが長くなります。 付加されたヘッダは依存 IPv4sec コンフィギュレーションモードの長さが異なりますが、~58 バイトを超過しません（Encapsulating Security Payload（ESP）および ESP 認証（ESPauth）） パケットごと。

    IPv4sec には、トンネル モードおよびトランスポート モードの 2 つのモードがあります。

    1. トンネルモードはデフォルトモードです。 トンネル モードでは、元の IPv4 パケットはすべて保護され（暗号化、認証、またはその両方）、IPv4sec のヘッダーとトレーラでカプセル化されます。 次に、新規の IPv4 ヘッダーがパケットの先頭に付加されて、送信元および宛先に IPv4sec エンドポイント（ピア）が指定されます。 トンネル モードは任意のユニキャスト IPv4 トラフィックで使用でき、IPv4sec がホストからのトラフィックを IPv4sec ピアの後方で保護している場合に使用する必要があります。 たとえば、トンネル モードはバーチャル プライベート ネットワーク（VPN）で使用されます。この場合、保護されたあるネットワーク上のホストが保護された別のネットワーク上のホストにパケットを送信するのに、一対の IPv4sec ピアが経由されます。 VPN では、IPv4sec「トンネル」は IPv4sec ピア ルータ間のこのトラフィックを暗号化することにより、ホスト間の IPv4 トラフィックを保護します。
    2. （トランスフォーム定義で、サブコマンド mode transport で設定される）トランスポート モードでは、元の IPv4 パケットのペイロードだけが保護（暗号化、認証、またはその両方）されます。 ペイロードは、IPv4sec のヘッダーとトレーラでカプセル化されます。 IPv4 プロトコル フィールドの ESP（50）への変更を除き、元の IPv4 ヘッダーはそのままの状態です。また、元のプロトコル値は、パケットが復号される際の復元のために IPv4sec トレーラに保存されます。 トランスポート モードは、IPv4 トラフィックが IPv4sec ピア自体の間で保護される場合にだけ使用され、パケット上の送信元および宛先の IPv4 アドレスは、IPv4sec ピア アドレスと同じになります。 IPv4sec トランスポート モードが使用されるのは、通常、最初の IPv4 データ パケットをカプセル化に別のトンネリング プロトコル（GRE など）が使用され、次に IPv4sec により GRE トンネル パケットを保護するような場合だけです。

    IPv4sec では常に、データ パケットおよび IPsec 自体のパケットのために PMTUD が実行されます。 IPv4sec IPv4 パケットの PMTUD 処理を変更するために、IPv4sec 設定コマンドがあります。IPv4sec では DF ビットに関して、クリア、設定、またはデータ パケットの IPv4 ヘッダーから IPv4sec の IPv4 ヘッダーへのコピーが可能です。 これは" DF Bit ト Override Functionality " 機能と呼ばれます。

    注: IPv4sec でハードウェアでの暗号化を行う場合、カプセル化の後のフラグメンテーションを必ず回避する必要があります。 ハードウェアでの暗号化では、ハードウェアによっては約 50 Mbps のスループットが提供されますが、IPv4sec パケットがフラグメント化される場合、このスループットの 50 ～ 90% が失われます。 フラグメント化された IPv4sec パケットが再構成のためにプロセス交換された後、復号のためにハードウェア暗号化エンジンに渡されることがこの損失の原因です。 スループットのこの損失はソフトウェア暗号化（2-10 MBS）のパフォーマンスレベルにハードウェア 暗号化 スループットをダウンさせることができます。

    シナリオ 7

    このシナリオでは、実行中の IPv4sec フラグメンテーションを図示します。 このシナリオでは、全体のパスに沿う MTU は 1500 です。 このシナリオでは、DF ビットは設定 されません。

    1. ルータは、Host 2 を宛先とした 1500 バイトのパケット（20 バイト IPv4 ヘッダー + 1480 バイトの TCP ペイロード）を受信します。
    2. 1500 バイトのパケットが IPv4sec によって暗号化され、52 バイトのオーバーヘッド（IPv4sec ヘッダー、トレーラ、および追加の IPv4 ヘッダー）が追加されます。 これにより、IPv4sec は 1552 バイトのパケットを送信する必要があります。 発信 MTU が 1500 であるので、このパケットはフラグメント化しなければなりません。
    3. この IPv4sec パケットから 2 つのフラグメントが作成されます。 フラグメンテーション中、2 番目のフラグメントに対してさらに 20 バイトの IPv4 ヘッダーが追加され、結果として 1500 バイトのフラグメントと 72 バイトの IPv4 フラグメントになります。
    4. IPv4sec トンネル ピア ルータはこれらのフラグメントを受信し、追加の IPv4 ヘッダーを取り除き、さらに、これらの IPv4 フラグメントを結合して元の IPv4sec パケットに戻します。 次に、IPv4sec によってこのパケットが復号されます。
    5. ルータはそれから 2.をホストするためにオリジナル 1500 バイト データパケットを転送します。

    シナリオ 8

    このシナリオはシナリオ 6 に類似しています。ただし、この場合は元のデータ パケットに DF ビットが設定されており、IPv4sec トンネル ピア間のパスにその他のリンクより低い MTU を持つリンクが存在する点が異なります。 このシナリオでは、「トンネルのエンドポイントにおいて PMTUD に関与するルータ」のセクションで説明したような、両方の PMTUD の役割を果たす IPv4sec ピア ルータの動作を説明します。

    このシナリオでは、フラグメンテーションに必要となる、IPv4sec PMTU の低い値への変更の状況を示します。 IPv4sec がパケットを暗号化する時に、DF ビットが内側の IPv4 ヘッダーから外側の IPv4 ヘッダーにコピーされることに注意してください。 メディア MTU および PMTU の値は、IPv4sec Security Association（SA; セキュリティ結合）内に格納されます。 メディア MTU は、アウトバウンド ルータ インターフェイスの MTU に基づいています。また、PMTU は、IPv4sec ピア間のパスで発生する最小 MTU に基づいています。 図に示すように、IPv4sec では、フラグメント化の前に、パケットがカプセル化/暗号化されることに注意してください。

    1. ルータは、1500 バイトのパケットを受信して廃棄します。この理由は、IPv4sec オーバーヘッドが追加される場合、パケットが PMTU（1500）より大きくなるからです。
    2. ルータはネクスト・ホップ MTU が 1442 であることをそれに告げる 1 をホストするために ICMP メッセージを送信 します（1500 - 58 = 1442）。 この 58 バイトとは、IPv4sec ESP および ESPauth を使用する場合の最大 IPv4sec オーバーヘッドです。 実際の IPv4sec オーバーヘッドは、この値より最大 7 バイト小さい値となる場合があります。 ホスト 1 はこの情報を、通常ように宛先（ルーティング テーブルのためのホスト ルートの 2） ホスト、記録します。
    3. 3. ホスト 1 はホスト 2 に 1442 のための PMTU を下げます、従って 2.をホストするためにデータを再送信する場合ホスト 1 はより小さい（1442 バイト）パケットを送信します。 ルータは 1442 バイトのパケットを受信し、IPv4sec は 52 バイトの暗号化オーバーヘッドを追加するので、結果として IPv4sec のパケットは 1496 バイトとなります。 このパケットにヘッダで DF ビットが設定があるので 1400 バイト MTU リンクの中間ルータによってドロップされます。
    4. パケットをドロップするこの中間ルータは、ICMP メッセージを IPv4sec パケットの送信者（1 番目のルータ）に送り、ネクスト ホップの MTU が 1400 バイトであることを伝えます。 この値は、IPv4sec SA PMTU 内に記録されます。
    5. 次に Host 1 が 1442 バイトのパケットを再送信する（この確認応答は受信していません）と、IPv4sec はパケットをドロップします。 ルータはパケットを再度ドロップします。この理由は、IPv4sec オーバーヘッドがパケットに追加される場合、パケットが PMTU（1400）より大きくなるからです。
    6. ルータはネクスト・ホップ MTU が今 1342 であることをそれに告げる 1 をホストするために ICMP メッセージを送信 します。 （1400 - 58 = 1342）。 ホスト 1 は再度この情報を記録します。
    7. ホスト 1 が再度データを再送信する場合、小型パケットを使用します（1342）。 このパケットはフラグメンテーションを必要とせず、IPv4sec トンネルを介して Host 2 に到達します。

    GRE と IPv4sec の使用

    GRE トンネルの暗号化に IPv4sec が使用される場合、フラグメンテーションと PMTUD のより複雑なインタラクションが発生します。 IPv4sec では IPv4 マルチキャスト パケットがサポートされていないため、IPv4sec と GRE が次の方法で組み合されることになります。これは、IPv4sec VPN ネットワークではダイナミック ルーティング プロトコルを実行できないことを意味します。 GRE トンネルはマルチキャストをサポートしているので、まず GRE トンネルを使用して、GRE IPv4 ユニキャスト パケット内のダイナミック ルーティング プロトコル マルチキャスト パケットをカプセル化できます。次に、これを IPv4sec により暗号化できます。 これを実行すると、多くの場合、GRE に加えて IPv4sec がトランスポート モードで展開されます。この理由は、IPv4sec ピアと GRE トンネルのエンドポイント（ルータ）は同じものであり、トランスポート モードでは IPv4sec オーバーヘッドの 20 バイトが節約されるからです。

    注目すべき状況の 1 つに、IPv4 パケットが 2 つのフラグメントに分割され、GRE によってカプセル化される場合があります。 この場合、IPv4sec では 2 つの独立した GRE + IPv4 のパケットに対応することになります。 多くの場合暗号化された後フラグメント化するには必要があるこれらのパケットのデフォルト 設定 1 で十分に大きくであって下さい。 IPv4sec ピアは、復号化の前にこのパケットを再構成する必要があります。 送信側ルータでの、この「2 重のフラグメンテーション」（GRE の前に 1 回、IPv4sec の後に 1 回）は、遅延を増大させ、スループットを低下させます。 また、再組立てはこれが起こる時はいつでも受信ルータの CPUヒット プロセス交換されましたり、そうそこにです。

    この状況は、GRE と IPv4sec 両方からのオーバーヘッドに対処するほど低く、GRE トンネル インターフェイス上の「ip mtu」を設定することによって回避できます（デフォルトでは、GRE トンネル インターフェイスの「ip mtu」は、実際の送信インターフェイスの MTU である GRE オーバーヘッドのバイトに設定されています）。

    この表は発信 物理インターフェイスに 1500 の MTU があることを仮定する各トンネル/モードの組合せの推奨される MTU 値をリストしたものです。

    トンネル 組み合せ 必要とされる仕様 MTU 推奨される MTU
    GRE + IPv4sec（トランスポート モード） 1440 バイト 1400 バイト
    GRE + IPv4sec（トンネル モード） 1420 バイト 1400 バイト

    注: 一般的な GRE + IPv4sec モードの組合せの大部分に対応しているため、MTU 値には 1400 が推奨されます。 また、認識される下げ気味はオーバーヘッド余分 20 か 40 バイトを可能にすることへありません。 1 つの値およびこの値送付すべてのシナリオをほとんど覚え、設定 することは容易です。

    シナリオ 9

    IPv4sec が GRE に加えて展開されています。 発信物理 MTU は 1500、IPv4sec PMTU は 1500、そして GRE IPv4 MTU は 1476（1500 - 24 = 1476）です。 このため、TCP/IPv4 パケットは 2 回フラグメント化されます。GRE の前に 1 回と IPv4sec の後に 1 回です。 パケットは GRE カプセル化の前にフラグメント化され、フラグメント化された GRE パケットの 1 つが IPv4sec 暗号化の後で再度フラグメント化されます。

    GRE トンネル上で「ip mtu 1440」（IPv4sec トランスポート モード）または「ip mtu 1420」（IPv4sec トンネル モード）を設定すると、このシナリオでの 2 重のフラグメンテーションの可能性が解消されます。

    1. ルータは 1500 バイト データグラムを受け取ります。
    2. カプセル化の前に、GRE により、1500 バイトのパケットが 1476 バイト（1500 - 24 = 1476）と 44 バイト（24 データ + 20 IPv4 ヘッダー）の 2 つの断片にフラグメント化されます。
    3. GRE では IPv4 フラグメントをカプセル化し、各パケットに 24 バイトが追加されます。 この結果として、それぞれ 1500 バイト（1476 + 24 = 1500）および 68 バイト（44 + 24）の、2 つの GRE + IPv4sec パケットとなります。
    4. この 2 つのパケットは IPv4sec により暗号化され、カプセル化オーバーヘッドの 52 バイト（IPv4sec トンネル モード）がそれぞれに追加されて、1552 バイトと 120 バイトのパケットが作成されます。
    5. 1552 バイトの IPv4sec パケットは送信 MTU（1500）より大きいため、ルータによりフラグメント化されます。 1552 バイトのパケットは、1500 バイトのパケットと 72 バイトのパケットに分割されます（後者のフラグメントには、52 バイトの「ペイロード」に加えて、追加の 20 バイト IPv4 ヘッダーが含まれる）。 1500 バイト、72 バイト、および 120 バイトの 3 つのパケットが、IPv4sec + GRE ピアに転送されます。
    6. 受信側ルータでは、2 つの IPv4sec フラグメント（1500 バイトと 72 バイト）が再構成されて、元の 1552 バイトの IPv4sec + GRE パケットが取得されます。 120 バイトの IPv4sec + GRE パケットに対しては、必要な処理はありません。
    7. IPv4sec で 1552 バイトと 120 バイトの両方の IPv4sec + GRE パケットが復号され、1500 バイトと 68 バイトの GRE パケットが取得されます。
    8. GRE では、1500 バイトと 68 バイトの GRE パケットがカプセル化解除され、1476 バイトと 44 バイトの IPv4 パケット フラグメントが取得されます。 これらの IPv4 パケット フラグメントが、宛先ホストに転送されます。
    9. Host 2 は、これらの IPv4 フラグメントを再構成して、元の 1500 バイトの IPv4 データグラムを取得します。

    トンネル パスに少ないMTU リンクがある以外シナリオ 10 はシナリオ 8 に類似したです。 これは、Host 1 から Host 2 に最初のパケットを送信する場合のワーストケース シナリオです。 このシナリオの最後の手順を完了すると、Host 1 は Host 2 の正しい PMTU を設定し、Host 1 と Host 2 との間の TCP 接続はすべて良好となります。 Host 1 と他のホスト間の（IPv4sec + GRE トンネルを介して到達可能な）TCP フローに関しては、シナリオ 10 の最後の 3 つの手順だけを実行する必要があります。

    このシナリオでは、tunnel path-mtu-discovery コマンドが GRE トンネルに設定され、Host 1 で生成される TCP/IPv4 パケット上に DF ビットが設定されます。

    シナリオ 10

    • ルータは 1500 バイト パケットを受信します。 このパケットは GRE によって DF ビットが設定 され、パケットサイズが GRE オーバーヘッド（24 バイト）を追加した後アウトバウンドインターフェイス「IP MTU」を超過するので GRE がパケットをフラグメント化するか、または転送できないので廃棄されます。
    • ルータはそれにネクスト・ホップ MTU が 1476 であることを知らせるために 1 をホストするように ICMP メッセージを送信 します（1500 - 24 = 1476）。
    • 1 つを変更し、ホスト 2 にパケットを再送信するとき 1476 のための PMTU を送信 します小型をホストして下さい。 GRE でこれがカプセル化され、1500 バイトのパケットが IPv4sec に渡されます。 IPv4sec はパケットをドロップします。この理由は、GRE によって（設定状態の）DF ビットが内側の IPv4 ヘッダーからコピーされており、IPv4sec オーバーヘッド（最大 38 バイト）を付加したパケットは大きすぎて、物理インターフェイスから転送できないためです。
    • IPv4sec は ICMP メッセージを GRE に送信し、ネクスト ホップの MTU が 1462 バイト（暗号化と IPv4 オーバーヘッドに最大 38 バイトが追加されるため）であることを通知します。 GRE は値 1438 （トンネルインターフェイスの「IP MTU」として 1462 を- 24）記録します。
    • 注: show ip interface tunnel<#> コマンドの出力の値のこの変更は内部で保存され、見られる場合がありません。 使用を debug tunnel コマンド回す場合その時だけこの変更を見ます。
    • 次にホスト 1 は 1476 バイト パケットを、GRE 廃棄しますそれを再送信します。
    • ルータは 1438 はネクスト・ホップ MTU であることを示す 1 をホストするために ICMP メッセージを送信 します。
    • ホスト 1 はホスト 2 のための PMTU を下げ、1438 バイト パケットを再送信します。 今回は、GRE はパケットを受け入れてカプセル化し、暗号化のために IPv4sec に渡します。 IPv4sec パケットは中継ルータに転送されますが、中継ルータの発信インターフェイス MTU が 1400 なので、ドロップされます。
    • 中継ルータは、ネクスト ホップの MTU が 1400 であることを通知する ICMP メッセージを IPv4sec に送信します。 この値は、関連する IPv4sec SA の PMTU 値内に IPv4sec により記録されます。
    • Host 1 が 1438 バイトのパケットを再送信すると、GRE はこれをカプセル化して IPv4sec に渡します。 IPv4sec はその PMTU を 1400 に変更しているので、このパケットをドロップします。
    • IPv4sec は ICMP エラーを GRE に送信し、ネクスト ホップの MTU が 1362 であることを通知し、GRE はこの値 1338 を内部に記録します。
    • （確認応答を受け取らなかったので）ホスト 1 がオリジナルパケットを再送信する時、GRE はそれを廃棄します。
    • ルータはネクスト・ホップ MTU は 1338 であることを示す 1 をホストするために ICMP メッセージを送信 します（1362 - 24 バイト）。 ホスト 1 はホスト 2 に 1338 のための PMTU を下げます。
    • ホスト 1 は最終的に 2.をホストすることを完全に取得できる今回および 1338 バイト パケットを再送信します。

    その他の推奨事項

    GRE と IPv4sec が同じルータ上に設定されている場合、トンネル インターフェイス上で tunnel path-mtu-discovery コマンドを設定することは、それらのインタラクションに有用です。 tunnel path-mtu-discovery コマンドを設定していないと、GRE IPv4 ヘッダー内の DF ビットが常にクリアされることに注意してください。 これにより、カプセル化されたデータ IPv4 ヘッダーで DF ビットが設定されていた場合（この場合、通常はパケットのフラグメント化が許可されません）でも、GRE IPv4 パケットのフラグメント化が許可されます。

    tunnel path-mtu-discovery コマンドが GREトンネル インターフェイスで設定される場合、これは起こります。

    1. GRE では、データ IPv4 ヘッダーから GRE IPv4 ヘッダーに、DF ビットをコピーします。
    2. GRE IPv4 ヘッダー内で DF ビットが設定されていると、IPv4sec 暗号化後のパケットが物理発信インターフェイスの IPv4 MTU に対して「大きすぎる」場合、IPv4sec はそのパケットをドロップし、GRE トンネルに IPv4 MTU サイズを縮小するように通知します。
    3. IPv4sec はそれ自体のパケットに対して PMTUD を実行しますが、IPv4sec PMTU が変更（縮小）されても、これは即座には、IPv4sec から GRE に通知されません。ところが、別の「大きすぎる」パケットが到着すると、ステップ 2 の処理が発生します。
    4. この場合、GRE の IPv4 MTU はさらに小さいので、DF ビットが設定された大きすぎるデータ IPv4 パケットをすべて廃棄し、送信側ホストに ICMP メッセージを送信します。

    ip mtu コマンドを使用した静的な設定とは異なり、tunnel path-mtu-discovery コマンドは、GRE インターフェイスが IPv4 MTU を動的に設定するのに有効です。 コマンドが両方とも使用されることが実際に推奨されます。 ip mtu コマンドは、ローカルの物理発信インターフェイスの IPv4 MTU に関連する、GRE と IPv4sec のオーバーヘッドのためのスペースを確保するのに使用されます。 tunnel path-mtu-discovery コマンドでは、IPv4sec ピア間のパスにさらに低い IPv4 MTU のリンクが存在する場合に、GRE トンネルの IPv4 MTU をさらに低下させることができます。

    GRE + IPv4sec トンネルが設定されたネットワーク内で、PMTUD に問題が発生する場合に実行可能な対応を、ここに示します。

    このリストは最も好ましいソリューションから始まります。

    1. はたらかない通常 ICMP をブロックするルータかファイアウォールによって引き起こされる PMTUD における問題を解決して下さい。
    2. ルータが TCP 同期信号 パケットの TCP MSS 値を下げるようにトンネルインターフェイスの ip tcp adjust-mss コマンドを使用して下さい。 これは PMTUD が必要ではないように十分に小さいパケットを使用するために両端ホストを（TCP 送信側およびレシーバ）助けます。
    3. ルータの入力インターフェイスでポリシー ルーティングを使用し、さらに、ルート マップを設定して、データ IPv4 ヘッダー内の DF ビットが GRE トンネル インターフェイスに到着する前にクリアされるようにします。 これにより、データ IPv4 パケットを、GRE カプセル化の前にフラグメント化できるようになります。
    4. アウトバウンドインターフェイス MTU と等しいために GREトンネル インターフェイスの「IP MTU」を増加して下さい。 これにより、フラグメント化を先に実行しないでも、データ IPv4 パケットの GRE でのカプセル化ができるようになります。 次に、GRE パケットに対して IPv4sec 暗号化が実行され、物理アウトバウンド インターフェイスから送信するためにフラグメント化されます。 この場合 GREトンネル インターフェイスの tunnel path-mtu-discovery コマンドを設定しません。 これによりスループットが極端に下がる場合があります。これは、IPv4sec ピアでの IPv4 パケットの再構成がプロセス交換モードで実行されることが原因です。

    関連情報

    TAC Authored

    シスコ エンジニア提供

    • Catherine Wu
      Cisco TAC エンジニア
    • Eric Vyncke
      Cisco 設計

    このドキュメントは役に立ちましたか?

    Feedbackフィードバック

    シスコに問い合わせ

    関連するシスコ コミュニティ ディスカッション

    このドキュメントは次の製品に対応しています

    シスコをフォロー
    News Roomイベントブログコミュニティ
    シスコについて
    お問い合わせ
    採用情報