VMware verursacht, wie jedes Overlay, zusätzlichen Overhead für den Datenverkehr, der das Netzwerk durchläuft. In diesem Abschnitt wird zunächst der in einem herkömmlichen IPsec-Netzwerk hinzugefügte Overhead und der Vergleich mit VMware beschrieben. Anschließend wird erläutert, wie sich dieser zusätzliche Overhead auf die MTU und das Verhalten der Paketfragmentierung im Netzwerk auswirkt.

IPsec-Tunnel-Overhead

In einem herkömmlichen IPSec-Netzwerk wird der Datenverkehr in der Regel in einem IPSec-Tunnel zwischen Endpoints übertragen. Ein Standard-IPsec-Tunnel-Szenario (AES 128-Bit-Verschlüsselung mit ESP [Encapsulating Security Payload]) führt bei der Verschlüsselung des Datenverkehrs wie folgt zu mehreren Arten von Overhead:
  • Auffüllung (Padding)
    • AES verschlüsselt Daten in 16-Byte-Blöcken. Dies wird als Blockgröße bezeichnet.
    • Wenn der Hauptteil eines Pakets kleiner oder nicht durch die Blockgröße teilbar ist, wird er entsprechend der Blockgröße aufgefüllt.
    • Beispiele:
      • Aus einem 1-Byte-Paket werden 16 Byte mit einer Auffüllung von 15 Byte.
      • Aus einem 1400-Byte-Paket werden 1408 Byte mit einer Auffüllung von 8 Byte.
      • Für ein 64-Byte-Paket ist keine Auffüllung erforderlich.
  • IPsec-Header und -Trailer:
    • UDP-Header für NAT Traversal (NAT-T).
    • IP-Header für IPSec-Tunnelmodus.
    • ESP-Header und -Trailer.
Element Größe in Byte
IP-Header 20
UDP-Header 8
IPSec-Sequenznummer 4
IPSec SPI 4
Initialisierungsvektor 16
Auffüllung 0 – 15
Auffüllungslänge 1
Nächste Kopfzeile 1
Authentifizierungsdaten 12
Gesamt 66 – 81
Hinweis: Bei den angegebenen Beispielen wird davon ausgegangen, dass sich mindestens ein Gerät hinter einem NAT-Gerät befindet. Wenn kein NAT verwendet wird, ist der IPSec-Overhead um 20 Byte geringer, da NAT-T nicht benötigt wird. Es gibt keine Änderung am Verhalten von VMware, unabhängig davon, ob NAT vorhanden ist oder nicht (NAT-T ist immer aktiviert).

VMware-Tunnel-Overhead

Zur Unterstützung von Dynamic Multipath Optimization™ (DMPO) kapselt VMware Pakete in einem Protokoll namens VeloCloud Multipath Protocol (VCMP). VCMP fügt 31 Byte Overhead für Benutzerpakete hinzu, um Resequenzierung, Fehlerkorrektur, Netzwerkanalyse und Netzwerksegmentierung innerhalb eines einzelnen Tunnels zu unterstützen. VCMP wird auf dem von der IANA registrierten Port UDP 2426 verwendet. Um ein konsistentes Verhalten in allen möglichen Szenarien zu gewährleisten (unverschlüsselt, verschlüsselt und hinter einem NAT, verschlüsselt aber nicht hinter einem NAT), wird VCMP mit dem Transportmodus IPsec verschlüsselt und erzwingt, dass NAT-T mit dem speziellen NAT-T-Port 2426 „True“ ist.

Pakete, die über das SD-WAN Gateway an das Internet gesendet werden, werden standardmäßig nicht verschlüsselt, da sie bei Verlassen des Gateways ins offene Internet gelangen. Dies hat zur Folge, dass der Overhead für Internet-Multipath-Datenverkehr geringer ist als der VPN-Datenverkehr.

Hinweis: Dienstanbieter haben die Möglichkeit, den Internetdatenverkehr über das Gateway zu verschlüsseln. Wenn sie diese Option verwenden, gilt der VPN-Overhead auch für den Internetdatenverkehr.

VPN-Datenverkehr

Element Größe in Byte
IP-Header 20
UDP-Header 8
IPSec-Sequenznummer 4
IPSec SPI 4
VCMP-Header 23
VCMP-Datenheader 8
Initialisierungsvektor 16
Auffüllung 0 – 15
Auffüllungslänge 1
Nächste Kopfzeile 1
Authentifizierungsdaten 12
Gesamt 97 – 112

Internet-Multipath-Datenverkehr

Element Größe in Byte
IP-Header 20
UDP-Header 8
VCMP-Header 23
VCMP-Datenheader 8
Gesamt 59

MTU-Pfaderkennung (Path MTU Discovery)

Nachdem ermittelt wurde, wie viel Overhead angewendet wird, muss der SD-WAN Edge die maximal zulässige MTU ermitteln, um die effektive MTU für Kundenpakete zu berechnen. Um die maximal zulässige MTU zu ermitteln, führt der Edge Path MTU Discovery aus:

  • Für öffentliche Internet-WAN-Verbindungen:
    • Path MTU Discovery wird für alle Gateways ausgeführt.
    • Die MTU für alle Tunnel wird auf die erkannte Mindest-MTU festgelegt.
  • Für private WAN-Verbindungen:
    • Path MTU Discovery wird für alle anderen Edges im Kundennetzwerk durchgeführt.
    • Die MTU für jeden Tunnel wird basierend auf den Ergebnissen von Path MTU Discovery festgelegt.

Der Edge versucht zunächst eine RFC 1191 Path MTU-Erkennung, bei der ein Paket der aktuellen bekannten Link-MTU (Standard: 1500 Byte) an den Peer gesendet wird, wobei das „Don't Fragment“-Bit (DF) im IP-Header gesetzt ist. Wenn dieses Paket auf dem Remote-Edge oder Gateway empfangen wird, wird ein Bestätigungspaket derselben Größe an den Edge zurückgegeben. Wenn das Paket den Remote-Edge oder das Gateway aufgrund der Einschränkungen der MTU nicht erreichen kann, wird erwartet, dass das Zwischengerät eine Meldung über ein nicht erreichbares (Fragmentierung erforderlich) ICMP-Ziel sendet. Wenn der Edge die ICMP-Unerreichbarkeitsmeldung erhält, wird die Meldung validiert (um sicherzustellen, dass der gemeldete MTU-Wert vernünftig ist). Nach der Validierung wird die MTU angepasst. Der Vorgang wird dann wiederholt, bis die MTU erkannt wurde.

In einigen Fällen (z. B. bei USB-LTE-Dongles) sendet das Zwischengerät keine ICMP-Unerreichbarkeitsnachricht, selbst wenn das Paket zu groß ist. Wenn RFC 1191 fehlschlägt (der Edge hat keine Bestätigung erhalten, oder ICMP ist nicht erreichbar), wird auf RFC 4821 Packetization Layer Path MTU Discovery zurückgegriffen. Der Edge versucht, eine binäre Suche auszuführen, um die MTU zu ermitteln.

Wenn eine MTU für einen Peer erkannt wird, werden alle Tunnel zu diesem Peer auf dieselbe MTU festgelegt. Das heißt, wenn ein Edge eine Verbindung mit einer MTU von 1400 Byte und eine Verbindung mit einer MTU von 1500 Byte hat, haben alle Tunnel eine MTU von 1400 Byte. Dadurch wird sichergestellt, dass Pakete jederzeit mit derselben MTU auf einem beliebigen Tunnel gesendet werden können. Diese wird als effektive Edge-MTU bezeichnet. Basierend auf dem Ziel (VPN oder Internet Multipath) wird der oben umrissene Overhead subtrahiert, um die effektive Paket-MTU zu berechnen. Für direktes Internet oder sonstigen zugrunde liegenden Datenverkehr ist der Overhead 0 Byte. Da kein Failover der Verbindung erforderlich ist, ist die effektive Paket-MTU identisch mit der erkannten WAN-Verbindungs-MTU.

Hinweis: RFC 4821 Packetization Layer Path MTU Discovery misst die MTU bis zu einem Minimum von 1300 Byte. Wenn Ihre MTU kleiner als 1300 Byte ist, müssen Sie die MTU manuell konfigurieren.

VPN-Datenverkehr und MTU

Nachdem der SD-WAN Edge die MTU und die Overheads ermittelt hat, kann eine effektive MTU für den Clientdatenverkehr berechnet werden. Der Edge versucht, diese MTU so effizient wie möglich für die verschiedenen potenziellen Arten von empfangenem Datenverkehr durchzusetzen.

TCP-Datenverkehr

Der Edge führt die TCP MSS-Anpassung (Maximum Segment Size) für empfangene TCP-Pakete automatisch durch. Während SYN- und SYN|ACK-Pakete den Edge durchlaufen, wird die MSS auf der Grundlage der effektiven Paket-MTU neu geschrieben.

Kein TCP-Datenverkehr ohne gesetztes DF-Bit

Wenn das Paket größer ist als die effektive Paket-MTU, führt der Edge automatisch die IP-Fragmentierung gemäß RFC 791 durch.

Kein TCP-Datenverkehr mit gesetztem DF-Bit

Wenn das Paket größer ist als die effektive Paket-MTU:

  • Wenn ein Paket zum ersten Mal für diesen Flow (IP 5-Tupel) empfangen wird, verwirft der Edge das Paket und sendet eine Meldung über ein nicht erreichbares (Fragmentierung erforderlich) ICMP-Ziel gemäß RFC 791.
  • Wenn nachfolgende Pakete für denselben Flow empfangen werden, die immer noch zu groß sind, werden diese Pakete in mehrere VCMP-Pakete fragmentiert und vor der Übergabe an das Remote-Ende transparent neu zusammengesetzt.