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
- 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 |
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.
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 |
Auswirkungen von IPv6-Tunnel auf MTU
VMware SD-WAN unterstützt IPv6-Adressen, um die Edge-Schnittstellen und die Edge-WAN-Overlay-Einstellungen zu konfigurieren.
Der VCMP-Tunnel kann in den folgenden Umgebungen eingerichtet werden: nur IPv4, nur IPv6 und Dual-Stack. Weitere Informationen finden Sie unter IPv6-Einstellungen.
Wenn eine Zweigstelle über mindestens einen IPv6-Tunnel verfügt, verwendet DMPO diesen Tunnel nahtlos zusammen mit anderen IPv4-Tunneln. Die Pakete für einen bestimmten Flow können je nach Echtzeit-Integrität des Tunnels jeden Tunnel, IPv4 oder IPv6, verwenden. Ein Beispiel für einen bestimmten Flow ist die Pfadauswahlpunktzahl für Datenverkehr mit Lastausgleich. In solchen Fällen sollte die erhöhte Größe für den IPv6-Header (zusätzliche 20 Byte) berücksichtigt werden, und infolgedessen beträgt die effektive Pfad-MTU 20 Byte weniger. Darüber hinaus wird diese verringerte effektive MTU über das Gateway an die anderen Remote-Zweigstellen propagiert, sodass die eingehenden Routen zu dieser lokalen Zweigstelle von anderen Remote-Zweigstellen den reduzierten MTU-Wert widerspiegeln.
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.
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.
Jumbo Frame-Einschränkung
VMware SD-WAN unterstützt ab Version 5.0 keine Jumbo-Frames mehr. Die maximale IP-MTU, die für Pakete unterstützt wird, die über das Overlay ohne Fragmentierung gesendet werden, ist 1500.
