L2TP の MTU チューニング
内容
概要
このドキュメントでは、L2TP リンク上でのフラグメント化と再編成、および Maximum Transmission Unit（MTU; 最大伝送ユニット）をチューニングすることにより、関連する問題をどのように改善できるかを説明します。
前提条件
要件
このドキュメントを読むには、次の知識が必要です。
-
General Virtual Private Dialup Network（VPDN）設定コマンド。
-
フラグメント化、再編成、MTU、カプセル化、ヘッダーなどの一般的な IP 項目。
使用するコンポーネント
ここで説明されている設定拡張および機能拡張の多くは、Cisco IOS(R) ソフトウェア リリース 12.1T または 12.2T 以降で使用できます。ただし詳細については、次の各セクションを参照してください。
このマニュアルの情報は、特定のラボ環境に置かれたデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。実稼動中のネットワークで作業をしている場合、実際にコマンドを使用する前に、その潜在的な影響について理解しておく必要があります。
表記法
ドキュメント表記の詳細は、「シスコ テクニカル ティップスの表記法」を参照してください。
フラグメント化の例
トンネル カプセル化パケットを有線で送信するためには、パケットをフラグメント化する必要がある場合があります。次に例を示します。
L2TP over UDP の場合、すべてのプロトコルのオーバーヘッドには、IP ヘッダー、UDP ヘッダーおよび L2TP ヘッダーの追加セットが含まれます。IP ヘッダーは 20 バイト、UDP ヘッダーは 8 バイト、L2TP ヘッダーは通常 12 バイトです。L2TP ヘッダーの 12 バイトには次のものが含まれます。
-
バージョンとフラグ フィールド（2 バイト）
-
トンネル ID とセッション ID フィールド（各 2 バイト）
-
パディング オフセット（2 バイト）
-
Point-to-Point Protocol（PPP; ポイントツーポイント プロトコル）カプセル化（4 バイト）
次の図に詳細を示します。
データ シークエンシングがイネーブルの場合（Cisco のデバイスではデフォルトでディセーブル）、Ns および Nr の各フィールドに追加の 4 バイトを付け加える必要があります。IP ヘッダー、UDP ヘッダー、L2TP ヘッダーへの追加を行う場合、L2TP over UDP では、プロトコル カプセル化の 40 バイトがパケットに追加されます。
1500 バイトの IP パケットを L2TP にカプセル化する場合、カプセル化されたパケットは 1540 バイト（1500 バイト + 40 バイトの IP、UDP、L2TP の各ヘッダー）になります。 標準イーサネット タイプのインターフェイスを介してパケットを送信するには（MTU は 1500 バイト）、パケットをフラグメント化する必要があります。 カプセル化されたパケットは、2 つにフラグメント化されます。最初のフラグメントは 1500 バイトで構成されます（元の IP パケットの 1460 バイト + L2TP カプセル化の 40 バイト）。 2 番目のフラグメントは、60 バイトで構成されます（元の IP パケットの最後の 40 バイト + IP オーバーヘッドの 20 バイト）。
注：最初のフラグメントにのみL2TPヘッダーが含まれます。2 番目のフラグメントには IP ヘッダーだけが含まれています。このため、L2TP ピアが LAC か LNS かにかかわらず、2 つのフラグメントを元の 1540 バイトのトンネル カプセル化パケットに再編成できます。
問題点
User Datagram Protocol（UDP; ユーザ データグラム プロトコル）や他のレイヤ 2/レイヤ 3 IP ベースのトンネリング プロトコルを介した Layer 2 Tunneling Protocol (L2TP; レイヤ 2 トンネリング プロトコル）が直面している問題の 1 つは、トンネリング プロトコルのオーバーヘッドにより、トンネル カプセル化パケットのサイズが大きくなるということです。元のパケットのサイズがすでに限界いっぱいの場合、トンネル カプセル化パケットを有線で送信するには、パケットをフラグメント化する必要があります。
L2TP Access Concentrator（LAC）と L2TP Network Server（LNS）上で L2TP パケットのフラグメント化と再編成を実行することによって生じる問題の 1 つに、フラグメント化と再編成が Cisco IOS ソフトウェアのプロセス レベルで実行されるということがあります。大量の L2TP セッションとトラフィック フローを LNS 上で集約する場合、プロセス交換によりパフォーマンスが大幅に低下することがあります。このため L2TP スイッチング パスでのフラグメント化と再編成の必要性の削減、あるいは、解消が希求されます。
このドキュメントで説明する方式のいずれかを使って、Maximum Transmission Unit（MTU; 最大伝送ユニット）を調整することで、この問題を解決できます。
MTU の調整方法
L2TP スイッチング パスでのフラグメント化と再編成を、MTU の調整で回避するように、Cisco IOS ソフトウェアではさまざまな設定と機能が設計されています。
手動でより低いIP MTU を設定すること
ip mtu コマンドを使用して、バーチャル テンプレート インターフェイス上で IP MTU を低く設定します。IP MTU を低く設定すると、ルータでは IP MTU を超える IP パケットがすべてドロップされ、IP ヘッダーで DF（Don't Fragment）ビットが設定されます。次に Internet Control Message Protocol（ICMP; インターネット制御メッセージ プロトコル）タイプ 3 Host Unreachable、コード 4 fragmentation needed メッセージが、パケットの送信元（送信元のホスト）に対してルータで生成されます。 このメッセージは、インターフェイスに適合するように送信元がパケット サイズを縮小できるように、インターフェイスの IP MTU を示すものです。このプロセスは、Path MTU Detection（PMTUD; パス最大伝送ユニット検出）とも呼ばれています。 詳細については、RFC 1191 を参照してください。 
フル L2TP ヘッダーが追加される場合、IP MTU は、LAC と LNS 間の PMTU を超えない最大 IP パケット サイズに設定する必要があります。1500 バイトの PMTU と標準の 40 バイトの L2TP ヘッダーの場合、IP MTU を 1460（1500 - 40 バイトのヘッダー）に設定してください。
LAC と LNS 間の PMTU が不明の（または変更された）場合は、vpdn-group の下で ip pmtu コマンドを設定できます。Bug ID CSCds72714（外部ユーザには表示されません）により、Cisco IOS ソフトウェア リリース 12.2(4)T で ip pmtu コマンドが追加されました。 ip pmtu 機能により、内部パケットから外部の L2TP ヘッダーへ DF ビットがコピーされ、ルータとその L2TP トンネル エンドポイント間で PMTUD が有効になります。
Windows PC 上での PMTU の調整
Microsoft Windows には、PMTU ディスカバリのバックオフ機能をイネーブルにするレジストリ設定が備わっています。Windows NT に関する情報は、Microsoft Web サイトの次の記事を参照してください。PMTU Black Hole Detection Algorithm Change for Windows NT 3.51（Q136970）.
Windows 2000/XP については、Microsoft の記事『How to Troubleshoot Black Hole Router Issues（Q314825）』に、この問題を回避するための Windows のさまざまな方式が記載されています。 この記事では、「ブラック ホール」ルータという用語が定義され、ブラック ホール ルータの位置を特定する方法が説明されています。また、ブラック ホール ルータが原因で発生するデータ損失を回避する 3 つの方法が提案されています。
IP MTU の自動調整
IP MTU の自動調節をイネーブルにすることもできます。この機能を使うと、ルータはバーチャルアクセス インターフェイス上で IP MTU を自動調節して、L2TP ヘッダーのサイズと出力インターフェイスの MTU を補填できます。この機能は、Bug ID CSCdr01713（登録ユーザ専用）により、Cisco IOS ソフトウェア リリース 12.1(5)T で追加されました。
注：IP MTUは、仮想テンプレートインターフェイスで手動で設定されたIP MTUがない場合にのみ自動的に調整されます（前のセクションのオプションを使用）。
この機能はデフォルト設定ではイネーブルに設定されていて、ディセーブルにする方法はありませんでした。Cisco IOS ソフトウェア リリース 12.2(3) および 12.2(4)T 以降の Bug ID CSCdt67753（登録ユーザ専用）により、この機能の有効化と無効化を行う [no] ip mtu adjust コマンドが vpdn-group の下に追加されました。この機能はデフォルトでイネーブルに設定されていました。この機能には、デフォルト設定を L2X 接続専用に変更する Command Line Interface（CLI; コマンドライン インターフェイス）がなく、この L2X 接続が vpdn-group（SGBP が開始した L2F または L2TP トンネルなど）にバインドすることはありません。 Multichassis Multilink PPP（MMPPP）トポロジに対してこの機能をディセーブルにできない点は、後述の PMTUD 問題とのからみで、お客様からの苦情を数多く頂いております。このため Cisco IOS ソフトウェア リリース 12.2(6) および 12.2(8)T 以降、Bug ID CSCdu69834（登録ユーザ専用）により、IP MTU 自動調節機能をディセーブルするようにデフォルト設定が変更されました。
MTU の手動調整と自動調整は両方とも、エンド ホスト間の PMTUD に依存しています。これは理論上は問題ないのですが、PMTUD がインターネット上で正常に動作しません。インターネット上での PMTUD の不具合についての詳細は、RFC 2923 を参照してください。 最大の問題は、Web ページのダウンロードが、ミッドストリームでハングしているように見える「ブラック ホール」の存在です。このようなブラックホールは通常、ICMP メッセージを排除するように設定されたファイヤウォールやルータが原因で発生します。MTU を超過したことを意味する「ICMP Host Unreachable」メッセージを、サイズ超過パケットの送信元がルータから受信できない場合、その送信元はパケット サイズを縮小することはできません。その代わり、送信元は DF ビットを設定した状態で、同じパケットを繰り返し再送信し続けます。パケットが PMTU を超えていて、接続が応答を停止しているため、LNS がこれらのパケットをドロップします。
L2TP トンネルには IP MTU が小さすぎることを検出するのに PMTUD に依存しているという問題により、Cisco は TCP Maximum Segment Size（MSS; 最大セグメント サイズ）調節機能を Cisco IOS ソフトウェア リリース 12.2(4)T で追加しました。
TCP MSS の調整
TCP 最大セグメント サイズ調整機能：Bug ID CSCds69577（登録ユーザ専用）で追加され、Cisco IOS ソフトウェア リリース 12.2(4)T 以降で使用可能なこの機能を使うと、エンド ホストが送信する着発信 Synchronize（SYN; 同期）パケットで、アドバイズされた TCP MSS をルータが修正できます。TCP MSS を通常のデフォルト値である 1460 よりも小さな値に修正すると、フルサイズのパケットの原因となっている TCP を排除できます。L2TP over UDP でカプセル化された、TCP/IP ヘッダー付きの TCP セグメントが、出力インターフェイスの IP MTU を超えないように、TCP MSS の値を調整する必要があります。TCP/IP ヘッダーは通常 40 バイトで、L2TP over UDP ヘッダーは追加の 40 バイトです。したがって、TCP MSS は一般的に 1420（1500 - 40 バイトの TCP/IP ヘッダー - 40 バイトの L2TP over UDP ヘッダー）に調整する必要があります。
このために使用されるコマンドは、ip tcp adjust-mss <mss>です。このコマンドはインターフェイス レベルのコマンドです。
L2TP ネットワークでフラグメント化を減らすための最後のオプションは、ポイントツーポイント プロトコル クライアント上での Maximum Receive Unit（MRU; 最大受信ユニット）ネゴシエーションのサポートを必要とします。PPP の MRU オプションを使うと、ピアはその最大受信ユニットについてアドバタイズできます。たとえば、ピアが MRU として 1460 をアドバタイズした場合、そのピアは 1460 バイトを超えるペイロードの PPP フレームを処理しません。Cisco の PPP 実装では、PPP ネゴシエーション中にピアがアドバタイズしたインターフェイスの MTU が、MRU の値として使われます。MTU のデフォルトが 1500 として設定されている場合、この値は PPP の標準のデフォルト値であるため、MRU はアドバタイズされません。ただし MTU が 1460 に設定されている場合、PPP MRU として 1460 がアドバタイズされます。PPP ピアが PPP ネゴシエーション中にアドバタイズされた MRU を受け付け、その PPP リンクに対して MTU（さらに間接的に IP MTU を）を調節した場合、フラグメント化を回避できます。アドバタイズされた PPP MRU が 1460 の場合、ピアは IP MTU を 1460 に設定します。これにより、TCP 接続が確立された場合にピアがアドバタイズする TCP MSS が修正され、L2TP ネットワークを介したフラグメント化が回避されます。
より低いMTU の設定
バーチャル テンプレート インターフェイス上で MTU を低く設定するには、mtu <bytes> コマンドを使用します。この場合も、PPP ネゴシエーション中にアドバタイズされた MRU を受け付けるには、PPP クライアント上でのサポートが必要です。MRU オプションを受け付けることが判明しているクライアントは、Windows XP PPP クライアントです。残念ながら、その他の一般に展開されている PPP クライアントは、アドバタイズされる PPP MRU に適切に準拠していません。PPP クライアントがアドバタイズされる PPP MRU を適切に使用しているかどうかを確認するには、その PPP クライアントのドキュメントを参照してください。プロキシ LCP を使って L2TP を実行している場合、MRU オプションは LCP フェーズ中にネゴシエートされるため、LCP 再ネゴシエーションを実行する必要があります。LCP 再ネゴシエーションを有効にするには、vpdn-group の下で、lcp renegotiation on-mismatch または lcp renegotiation always を設定します。
MTU を低く設定することに関する問題の 1 つは、IP MTU も自動的に低く設定されてしまうことです。現在、バーチャル テンプレート インターフェイスでは、MTU より大きな IP MTU を設定することはできません。これについては、機能/拡張要求として、Bug ID CSCdx39828（外部ユーザには表示されません）により現在追跡中です。
この方式を使用するには、クライアントが LCP ネゴシエーション中に MRU オプションをリスニングする必要があります。たいていの場合、複数のクライアントが混在しています。MRU をリスニングするクライアントもあれば、リスニングしないクライアントもあります。MRU を無視するクライアントでは、「IP MTU の自動調整」のセクションで説明した PMTUD の問題が発生します。こうしたクライアントでは、IP パケット内部の DF ビットをクリアして PMTUD を効果的にオフすることにより、別の回避策を使用できます。次の設定でこれを実行できます。
interface virtual-template1 ip policy route-map clear-df ! route-map clear-df permit 10 match ip address 101 set ip df 0 ! access-list 101 permit tcp any any
結論
Cisco IOS ソフトウェアは、L2TP スイッチング パフォーマンスを最大限に向上させるため、さまざまな方法を提供します。PMTUD は理想的なソリューションです。ただし、インターネット上の問題のため、常にこのソリューションを信頼できるとは限りません。Cisco IOS ソフトウェアは、L2TP スイッチング パフォーマンスを高く維持しつつ、お客様の接続性を最大限に向上させる代替メカニズムを複数提供しています。
フィードバック