如同任何覆疊，VMware 也會對周遊網路的流量產生額外負荷。本節將先說明在傳統 IPsec 網路中增加的額外負荷，及其與 VMware 的比較，然後說明這些增加的額外負荷與網路中的 MTU 和封包分段行為有何關聯。

IPsec 通道額外負荷

在傳統 IPsec 網路中，通常會在端點之間以 IPsec 通道傳送流量。標準 IPsec 通道案例 (使用 ESP [封裝安全性裝載] 的 AES 128 位元加密) 在加密流量時會產生多種類型的額外負荷，如下所述：
  • 填補
    • AES 會以 16 位元組的區塊 (我們稱之為「區塊」大小) 加密資料。
    • 如果封包的主體小於區塊大小，或無法以此大小整除，則會進行填補以符合區塊大小。
    • 範例：
      • 1 位元組的封包會填補 15 個位元組而變為 16 位元組的封包。
      • 1400 位元組的封包會填補 8 個位元組而變為 1408 位元組的封包。
      • 64 位元組的封包不需要任何填補。
  • IPsec 標頭和尾端：(IPsec headers and trailers:)
    • NAT 周遊 (NAT-T) 的 UDP 標頭。
    • IPsec 通道模式的 IP 標頭。
    • ESP 標頭和尾端。
元素 大小 (以位元組為單位)
IP 標頭 20
UDP 標頭 8
IPsec 序號 4
IPsec SPI 4
初始化向量 16
填補 0 – 15
填補長度 1
下一個標頭 1
驗證資料 12
總計 66-81
備註： 提供的範例假設至少有一個裝置位於 NAT 裝置後方。若未使用 NAT，IPsec 額外負荷將會減少 20 個位元組，因為不需要 NAT-T。無論 NAT 是否存在，都不會變更 VMware 的行為 (一律啟用 NAT-T)。

VMware 通道額外負荷

為了支援 Dynamic Multipath Optimization™ (DMPO)，VMware 會將封包封裝在名為 VeloCloud 多重路徑通訊協定 (VCMP) 的通訊協定中。VCMP 會為使用者封包增加 31 個位元組的額外負荷，以在單一通道內支援重新排序、錯誤修正、網路分析和網路分割。VCMP 會在 IANA 登錄的連接埠 UDP 2426 上運作。為了確保在所有可能的情況下 (未加密、已加密並位於 NAT 後方、已加密但不在 NAT 後方) 都會有一致的行為，VCMP 會使用傳輸模式 IPsec 進行加密，並使用特殊的 NAT-T 連接埠 2426 強制將 NAT-T 設為 true。

依預設不會對透過 SD-WAN 閘道傳送至網際網路的封包加密，因為這些封包會在退出閘道時輸出至開放的網際網路。因此，網際網路多重路徑流量的額外負荷會少於 VPN 流量。

備註： 服務提供者可選擇透過閘道來加密網際網路流量，且他們若選擇使用此選項，「VPN」額外負荷也會套用至網際網路流量。

VPN 流量 (VPN Traffic)

元素 大小 (以位元組為單位)
IP 標頭 20
UDP 標頭 8
IPsec 序號 4
IPsec SPI 4
VCMP 標頭 23
VCMP 資料標頭 8
初始化向量 16
填補 0 – 15
填補長度 1
下一個標頭 1
驗證資料 12
總計 97 – 112

網際網路多重路徑流量 (Internet Multipath Traffic)

元素 大小 (以位元組為單位)
IP 標頭 20
UDP 標頭 8
VCMP 標頭 23
VCMP 資料標頭 8
總計 59

路徑 MTU 探索 (Path MTU Discovery)

在判斷將套用多少額外負荷後，SD-WAN Edge 必須探索允許的 MTU 上限，以計算客戶封包的有效 MTU。為了尋找允許的 MTU 上限，Edge 會執行路徑 MTU 探索：

  • 針對公用網際網路 WAN 連結：
    • 對所有閘道執行路徑 MTU 探索。
    • 所有通道的 MTU 都將設定為探索到的最小 MTU。
  • 針對私人 WAN 連結：
    • 對客戶網路中的所有其他 Edge 執行路徑 MTU 探索。
    • 系統會根據路徑 MTU 探索的結果來設定每個通道的 MTU。

Edge 會先嘗試進行 RFC 1191 路徑 MTU 探索，其中目前已知連結 MTU (預設值：1500 個位元組) 的封包會使用 IP 標頭中設定的「不分段」(DF) 位元以傳送至對等。如果在遠端 Edge 或閘道上接收到此封包，則會將相同大小的確認封包傳回至 Edge。如果封包因 MTU 限制而無法送至遠端 Edge 或閘道，則預期中繼裝置應會傳送 ICMP 目的地無法連線 (需要分段) 的訊息。Edge 在接收到 ICMP 無法連線的訊息時，將會驗證訊息 (以確保報告的 MTU 為正常值)，且一經驗證後就會調整 MTU。然後，此程序會重複執行，直到探索到 MTU 為止。

在某些案例中 (例如 USB LTE Dongle)，即使封包太大，中繼裝置也不會傳送 ICMP 無法連線的訊息。如果 RFC 1191 失敗 (Edge 未接收到確認或 ICMP 無法連線的訊息)，則會回復至 RFC 4821 封包化層路徑 MTU 探索。Edge 會嘗試執行二進位搜尋以探索 MTU。

探索到對等的 MTU 時，此對等的所有通道將會設定為相同的 MTU。這表示，如果 Edge 的一個連結具有 1400 位元組的 MTU，而另一個連結的 MTU 為 1500 位元組，則所有通道都將具有 1400 位元組的 MTU。這可確保隨時都能使用相同的 MTU 在任何通道上傳送封包。我們稱之為有效 Edge MTU (Effective Edge MTU)。根據目的地 (VPN 或網際網路多重路徑)，系統會減去前述的額外負荷，以計算有效封包 MTU (Effective Packet MTU)。直接網際網路或其他底層流量的額外負荷為 0 個位元組，且由於不需要進行連結容錯移轉，有效封包 MTU 與探索到的 WAN 連結 MTU 相同。

備註： RFC 4821 封包化層路徑 MTU 探索可測量到 1300 位元組以上的 MTU。如果您的 MTU 少於 1300 位元組，則必須手動設定 MTU。

VPN 流量和 MTU

SD-WAN Edge 現已探索到 MTU 並計算出額外負荷，接下來即可為用戶端流量計算有效 MTU。Edge 會嘗試盡可能有效地對接收到的各種可能流量類型強制執行此 MTU。

TCP 流量 (TCP Traffic)

Edge 會自動對接收到的 TCP 封包執行 TCP MSS (最大區段大小) 調整。當 SYN 和 SYN|ACK 封包通過 Edge 時，系統會根據有效封包 MTU 重新寫入 MSS。

未設定 DF 位元的非 TCP 流量 (Non-TCP Traffic without DF bit set)

如果封包大於有效封包 MTU，則 Edge 會依據 RFC 791 自動執行 IP 分段。

設定了 DF 位元的非 TCP 流量 (Non-TCP Traffic with DF bit set)

如果封包大於有效封包 MTU：

  • 第一次收到此流量 (IP 5 元組) 的封包時，Edge 會捨棄封包，並根據 RFC 791 傳送 ICMP 目的地無法連線 (需要分段) 的訊息。
  • 如果後續接收到相同流程的封包，但仍然過大，這些封包將會分段為多個 VCMP 封包，並且先明確地進行重組再遞交至遠端。