VMware では、オーバーレイと同様、ネットワークを通過するトラフィックで追加のオーバーヘッドが発生します。このセクションでは、従来の IPsec ネットワークで追加されるオーバーヘッド、およびそのようなオーバーヘッドと VMware との比較方法について説明します。その後で、追加されたオーバーヘッドがネットワークの MTU やパケットの断片化の動作にどのように関連するかを解説します。

IPsec トンネルのオーバーヘッド

従来の IPsec ネットワークでは、通常、トラフィックはエンドポイント間の IPsec トンネルで伝送されます。標準的な IPsec トンネル シナリオ(ESP [カプセル化セキュリティ ペイロード] を使用した AES 128 ビット暗号化)では、トラフィックを暗号化する場合、次のような各種のオーバーヘッドが発生します。
  • [埋め込み]
    • AES では、データが、「ブロック」サイズと呼ばれる 16 バイト ブロック単位で暗号化されます。
    • パケットの本体がブロック サイズよりも小さい場合や、ブロック サイズで割り切れない場合は、ブロック サイズに一致するように埋め込みが行われます。
    • 例:
      • 1 バイトのパケットは、15 バイトの埋め込みで 16 バイトになります。
      • 1,400 バイトのパケットは、8 バイトの埋め込みで 1,408 バイトになります。
      • 64 バイトのパケットについては、埋め込みは必要ありません。
  • [IPsec ヘッダーとトレーラ]
    • NAT Traversal (NAT-T) 用の UDP ヘッダー
    • IPsec トンネル モード用の IP ヘッダー
    • ESP ヘッダーとトレーラ
要素 サイズ(バイト)
IP ヘッダー 20
UDP ヘッダー 8
IPsec シーケンス番号 4
IPsec SPI 4
初期化ベクトル 16
埋め込み 0 ~ 15
埋め込み長 1
次のヘッダー 1
認証データ 12
[合計] 66 ~ 81
注: この例では、少なくとも 1 つのデバイスが NAT デバイスの背後にあることを前提としています。NAT を使用しない場合、NAT-T は不要であるため、IPsec のオーバーヘッドは 20 バイト分、少なくなります。NAT の有無にかかわらず(NAT-T は常に有効であり)、 VMware の動作に変更はありません。

VMware トンネルのオーバーヘッド

Dynamic Multipath Optimization™ (DMPO) をサポートするため、VMware は VeloCloud Multipath Protocol (VCMP) と呼ばれるプロトコルでパケットをカプセル化します。VCMP では、1 つのトンネル内で再シーケンス、エラー修正、ネットワーク分析、ネットワーク セグメント化をサポートするため、31 バイトのオーバーヘッドがユーザー パケットに追加されます。VCMP は、UDP 2426 の IANA 登録ポートで動作します。考えられるすべてのシナリオ(非暗号化、NAT 背後で暗号化、NAT 背後ではなく暗号化)で動作の一貫性を確保するため、VCMP はトランスポート モード IPsec を使用して暗号化され、NAT-T は強制的に True になって専用の NAT-T ポート 2426 を使用します。

SD-WAN Gateway 経由でインターネットに送信されるパケットは、Gateway から出るときにオープンなインターネットに送信されるため、デフォルトでは暗号化されません。その結果、インターネット マルチパス トラフィックのオーバーヘッドは VPN トラフィックよりも小さくなります。

注: サービス プロバイダには、Gateway 経由でインターネット トラフィックを暗号化するという選択肢もあり、その場合は、インターネット トラフィックにも「VPN」オーバーヘッドが適用されます。

[VPN トラフィック]

要素 サイズ(バイト)
IP ヘッダー 20
UDP ヘッダー 8
IPsec シーケンス番号 4
IPsec SPI 4
VCMP ヘッダー 23
VCMP データ ヘッダー 8
初期化ベクトル 16
埋め込み 0 ~ 15
埋め込み長 1
次のヘッダー 1
認証データ 12
[合計] 97 ~ 112

[インターネット マルチパス トラフィック]

要素 サイズ(バイト)
IP ヘッダー 20
UDP ヘッダー 8
VCMP ヘッダー 23
VCMP データ ヘッダー 8
[合計] 59

IPv6 トンネルによる MTU への影響

VMware SD-WAN は、IPv6 アドレスをサポートして、Edge インターフェイスと Edge WAN オーバーレイの設定を行います。

VCMP トンネルは、IPv4 のみ、IPv6 のみ、およびデュアル スタックの環境で設定できます。詳細については、IPv6 設定を参照してください。

ブランチに少なくとも 1 つの IPv6 トンネルがある場合、DMPO はこのトンネルを他の IPv4 トンネルとともにシームレスに使用します。特定のフローのパケットは、トンネルのリアルタイムの健全性に基づき、任意のトンネル(IPv4 または IPv6)を使用できます。特定のフローの例としては、ロード バランシングされたトラフィックのパス選択スコアがあります。このような場合では、IPv6 ヘッダーのサイズの増大(20 バイトの追加)を考慮する必要があります。その結果、有効なパスの MTU は 20 バイト減少します。また、この減少した有効な MTU は、Gateway を介して他のリモート ブランチに伝達され、他のリモート ブランチからこのローカル ブランチへの受信ルートに、減少した MTU が反映されます。

パス MTU 検出 (Path MTU Discovery)

どの程度のオーバーヘッドが適用されるかを判別した後、SD-WAN Edge は、カスタマー パケットに対して有効な MTU を計算するために最大許容 MTU を検出する必要があります。最大許容 MTU を求めるため、Edge はパス MTU 検出を実行します。

  • パブリック インターネット WAN リンクの場合:
    • すべての Gateway に対してパス MTU 検出が実行されます。
    • すべてのトンネルの MTU が、検出された最小 MTU に設定されます。
  • プライベート WAN リンクの場合:
    • カスタマー ネットワーク内の他のすべての Edge に対してパス MTU 検出が実行されます。
    • 各トンネルの MTU が、パス MTU 検出の結果に基づいて設定されます。

Edge は、最初に RFC 1191 パス MTU 検出を試行します。この検出では、現在の既知のリンク MTU のパケット(デフォルトで 1,500 バイト)が、IP ヘッダーに「DF (Don't Fragment)」ビットが設定されている状態でピアに送信されます。このパケットがリモート Edge または Gateway で受信されると、同じサイズの受信確認パケットが Edge に返されます。MTU 制限のためパケットがリモート Edge または Gateway に到達できない場合、中間デバイスが ICMP 宛先到達不能(断片化が必要)メッセージを送信するものと予期されます。Edge は、ICMP 到達不能メッセージを受信すると、(報告された MTU 値が正しいことを確認するため)そのメッセージを検証し、検証が完了したら、MTU を調整します。このプロセスは、MTU が検出されるまで繰り返されます。

状況によっては(たとえば、USB LTE ドングルなどの場合)、パケットが大きすぎるにもかかわらず、中間デバイスから ICMP 到達不能メッセージが送信されないことがあります。RFC 1191 で障害が発生した場合(Edge で受信確認または ICMP 到達不能メッセージが受信されない場合)は、RFC 4821 パケット化レイヤー パス MTU 検出へのフォールバックが行われます。Edge は、バイナリ検索を実行して MTU を検出しようとします。

ピアの MTU が検出されると、そのピアに対するすべてのトンネルが同じ MTU に設定されます。つまり、Edge に MTU が 1,400 バイトのリンクが 1 つ、MTU が 1,500 バイトのリンクが 1 つある場合、すべてのトンネルの MTU が 1,400 バイトになります。これにより、すべてのトンネルで同じ MTU を使用して、パケットをいつでも送信できるようになります。これは [有効 Edge MTU] とも呼ばれています。宛先(VPN またはインターネット マルチパス)に基づき、上記のオーバーヘッドを差し引いて [有効パケット MTU] が計算されます。ダイレクト インターネットまたはその他のアンダーレイ トラフィックの場合、オーバーヘッドは 0 バイトであり、リンク フェイルオーバーは不要であるため、有効パケット MTU は検出された WAN リンク MTU と同じになります。

注: RFC 4821 パケット化レイヤー パス MTU 検出では、最低値を 1,300 バイトとして MTU が測定されます。MTU が 1,300 バイト未満の場合は、MTU を手動で設定する必要があります。

VPN トラフィックと MTU

SD-WAN Edge が MTU を検出し、オーバーヘッドを計算したら、クライアント トラフィックに対して有効な MTU を計算できるようになります。Edge は、想定される各種の受信トラフィックに対して、この MTU を可能な限り効率的に適用しようとします。

[TCP トラフィック]

Edge は、受信する TCP パケットの TCP MSS(最大セグメント サイズ)調整を自動的に実行します。SYN および SYN|ACK パケットが Edge を通過する際に、MSS が有効パケット MTU に基づいて書き換えられます。

[DF ビットが設定されない TCP 以外のトラフィック]

パケットが有効パケット MTU よりも大きい場合、Edge は RFC 791 に従って自動的に IP の断片化を実行します。

[DF ビットが設定される TCP 以外のトラフィック]

パケットが有効パケット MTU よりも大きい場合、次のようになります。

  • このフロー(IP 5 タプル)でパケットを初めて受信したときに、Edge はそのパケットをドロップし、RFC 791 に従って ICMP 宛先到達不能(断片化が必要)メッセージを送信します。
  • その後も依然として同じフローに対して大きすぎるパケットが受信される場合、それらのパケットは、複数の VCMP パケットに断片化され、リモート エンドでのハンドオフの前に透過的に再構築されます。

ジャンボ フレームの制限

リリース 5.0 以降では、VMware SD-WAN はジャンボ フレームをサポートしていません。断片化なしでオーバーレイで送信されるパケットに対してサポートされる最大 IP アドレス MTU は 1,500 です。