Maximale Übertragungseinheit

Die maximale Übertragungseinheit (MTU) gibt die Bytezahl des größten IP-Pakets an, einschließlich IP-Header, Layer-4-Protokoll-Header und Daten der Layer 4, die in einen Ethernet-Frame passen.

Gültige MTU-Größen für VPC-Netzwerke

VPC-Netzwerke (Virtual Private Cloud) verwenden eine Standard-MTU von 1.460 Byte. Sie können die MTU eines VPC-Netzwerks auf einen beliebigen Wert zwischen 1.300 Byte und 8.896 Byte (einschließlich) festlegen. Gängige benutzerdefinierte MTU-Größen betragen 1.500 Byte (Standard-Ethernet) oder 8.896 Byte (das Maximum). Wir empfehlen, die MTU für jede Netzwerkschnittstelle (NIC) der VM-Instanz so zu konfigurieren, dass sie mit der MTU des VPC-Netzwerks übereinstimmt, mit dem sie verbunden ist. Weitere Informationen finden Sie unter Einstellungen für VMs und MTU.

Kommunikation zwischen Google Cloud-VMs innerhalb von VPC-Netzwerken

Wenn VMs beim Senden und Empfangen dasselbe VPC-Netzwerk oderPeering-VPC-Netzwerke mit identischen MTUs verwenden, können IP-Pakete bis zur MTU-Größe zwischen den beiden VMs gesendet werden, wenn die Schnittstellen für beide VMs so konfiguriert sind, dass sie das VPC-Netzwerk-MTU verwenden.

Um Probleme mit nicht übereinstimmenden MTUs zu vermeiden, empfehlen wir, für alle verbundenen VPC-Netzwerke dieselbe MTU zu verwenden. Dies ist zwar die empfohlene Vorgehensweise, Sie sind jedoch nicht gezwungen, in verbundenen VPC-Netzwerken identische MTUs zu verwenden. Weitere Informationen dazu, wie Protokolle mit einer MTU-Abweichung zwischen VPC-Netzwerken umgehen, finden Sie unter Nicht übereinstimmende MTUs, MSS Clamping, Pfad-MTU-Erkennung.

Aus Sicht einer sendenden VM stellen Pfade zu den folgenden Zielen VM-zu-VM-Traffic dar, der in einem VPC-Netzwerk weitergeleitet wird:

  • Eine regionale interne IPv4-Adresse in einem primären IPv4- oder sekundären Subnetz-IPv4-Adressbereich des Subnetzes, einschließlich privater IPv4-Adressbereiche und privat verwendeter öffentlicher IPv4-Adressbereiche, die von diesen Zielressourcen verwendet werden:
    • Die primäre interne IPv4-Adresse der Netzwerkschnittstelle einer empfangenden VM.
    • Eine interne IPv4-Adresse in einem Alias-IP-Bereich der NIC einer empfangenden VM.
    • Eine interne IPv4-Adresse einer internen Weiterleitungsregel für die Protokollweiterleitung oder den internen Passthrough-Network Load Balancer.
  • Interne IPv6-Subnetzadressbereiche, die von diesen Zielressourcen verwendet werden:
    • Eine IPv6-Adresse aus dem IPv6-Adressbereich /96, die einem Dual-Stack-Empfang der NIC der VM zugewiesen ist.
    • Eine IPv6-Adresse aus dem IPv6-Adressbereich /96 einer internen Weiterleitungsregel für die Protokollweiterleitung oder für einen internen Passthrough-Network Load Balancer.
  • Externe IPv6-Subnetzadressbereiche werden von diesen Zielressourcen verwendetwenn Pakete mithilfe von Subnetzrouten oder Peering-Subnetzrouten innerhalb des VPC-Netzwerks weitergeleitet werden :
    • Eine IPv6-Adresse aus dem IPv6-Adressbereich /96, die einem Dual-Stack-Empfang der NIC der VM zugewiesen ist.
    • Eine IPv6-Adresse aus dem IPv6-Adressbereich /96 einer externen Weiterleitungsregel für die Protokollweiterleitung oder für einen externen Passthrough-Network Load Balancer.

Die folgenden VM-zu-VM-Pfade werden auf die gleiche Weise behandelt wie die Kommunikation mit Zielen außerhalb eines VPC-Netzwerks:

  • Wenn das Paketziel eine externe IPv4-Adresse der NIC einer empfangenden Google Cloud-VM ist.
  • Wenn das Paketziel eine externe IPv4-Adresse eines externen Passthrough-Network Load Balancers ist.
  • Wenn das Paketziel eine externe IPv4-Adresse einer Weiterleitungsregel für die Protokollweiterleitung ist
  • Wenn das Paketziel eine externe IPv6-Adresse der NIC einer Google Cloud-VM, eines externen Passthrough-Netzwerk-Load-Balancers oder einer Weiterleitungsregel für die externe Protokollweiterleitung und die anwendbare Route im VPC-Netzwerk ein nächstes Hop für das Standard-Internetgateway verwendet. In diesem Szenario befinden sich die empfangenden VMs weder im selben VPC-Netzwerk wie die sendende VM noch in einem VPC-Netzwerk, das über VPC-Netzwerk-Peering mit dem VPC-Netzwerk der sendenden VM verbunden ist.

Kommunikation mit Zielen außerhalb eines VPC-Netzwerks

Google Cloud verarbeitet Pakete, die an Ziele außerhalb des VPC-Netzwerks der sendenden VM gesendet werden, wie in der folgenden Tabelle gezeigt. Zu den Zielen außerhalb des VPC-Netzwerks einer sendenden VM gehören öffentlich routbare IP-Adressen für Ressourcen außerhalb von Google Cloud und vom Kunden verwendbare externe IP-Adressen innerhalb von Google Cloud.

Da das Internet im Allgemeinen eine MTU von 1.500 Byte verwendet, wird bei einer IP-Paketgröße von mindestens 1.500 Byte in der Regel ein MTU-bezogener Paketverlust vermieden.

Situation Verhalten
TCP-SYN- und SYN-ACK-Pakete Google Cloud führt bei Bedarf MSS-Clamping durch und ändert die MSS, um sicherzustellen, dass die Pakete in die MTU passen.
MTU des IP-Pakets zwischen 1.300 Byte und 1.600 Byte (einschließlich) Google Cloud nimmt keine Änderungen am Paket vor, mit Ausnahme von SYN- und SYN-ACK-Paketen, wie in der ersten Zeile erläutert.
IP-Paket größer als 1.600 Byte Google Cloud löscht das Paket und sendet eine Nachricht „Fragmentierung erforderlich“ (ICMP über IPv4) oder „Paket zu groß (ICMPv6)“ sowohl, wenn das Bit „Nicht fragmentieren“ (DF) aktiviert ist als auch wenn das DF-Bit aus ist.

Kommunikation mit Google APIs und Google-Diensten

VMs, die eine gültige VPC-Netzwerk-MTU-Größe verwenden, können Pakete an Google APIs und Google-Dienste senden, auch über den privaten Google-Zugriff und Private Service Connect für Google APIs. Die Informationen in diesem Abschnitt gelten auch für lokale Ressourcen, die Pakete mit dem privaten Google-Zugriff für lokale Hosts an Google APIs und Dienste senden.

Der in diesem Abschnitt beschriebene Traffic-Pfad zu Google APIs und ‑Diensten wird von Google Front Ends (GFEs) implementiert. Diese GFEs verwenden nicht konfigurierbare, feste MTUs. Traffic von Google Cloud zu Google APIs und Diensten verwendet immer das TCP-Protokoll: Wenn eine VM eine Verbindung zu Google APIs und Diensten von einem VPC-Netzwerk aus herstellt, dessen MTU nicht mit der MTU des GFE übereinstimmt, wird die Segmentgröße mithilfe von TCP-MSS-Advertisement ausgehandelt, wie unter Nicht übereinstimmende MTUs, MSS-Clamping, Pfad-MTU-Erkennung beschrieben.

Paketquelle Paketziel

Jede interne IPv4-Adresse: primäre interne IPv4-Adresse oder interne IPv4-Adresse aus einem Alias-IP-Bereich der VM-NIC

Eine externe IPv4-Adresse, die der VM-NIC mit einer 1-1-NAT-Zugriffskonfiguration zugewiesen ist: In diesem Fall führt Google Cloud 1-1-NAT bei ausgehendem Traffic aus und konvertiert eine primäre primäre interne IPv4-Adresse in eine externe IPv4-Quelladresse, die in der Zugriffskonfiguration angegeben ist
  • IPv4-Adressen von Google APIs und -Diensten für die Standarddomains
  • 199.36.153.4/30 (restricted.googleapis.com)
  • 199.36.153.8/30 (private.googleapis.com)
  • Privater Service Connect-Endpunkt für Google APIs und -Dienste
Externe oder interne IPv6-Adresse, für Dual-Stack-VMs
  • IPv6-Adressen von Google APIs und -Diensten für die Standarddomains
  • 2600:2d00:0002:1000::/64 (restricted.googleapis.com)
  • 2600:2d00:0002:2000::/64 (private.googleapis.com)

Kommunikation über Cloud VPN-Tunnel

Cloud VPN hat sowohl eine Gateway-MTU für gekapselte Pakete als auch eine Nutzlast-MTU für Pakete vor und nach der Kapselung.

Genaue MTU-Werte für die Nutzlast und weitere Informationen zur MTU für Cloud VPN finden Sie unter Überlegungen zur MTU in der Cloud VPN-Dokumentation.

Kommunikation über Cloud Interconnect-Anhänge (VLAN)

Google empfiehlt, für alle VLAN-Anhänge, die mit demselben VPC-Netzwerk verbunden sind, dieselbe MTU zu verwenden und für die MTU des VPC-Netzwerks denselben Wert festzulegen. Weitere Informationen zu MTUs für Cloud Interconnect-VLAN-Anhänge finden Sie unter Cloud Interconnect-MTU.

Jumbo Frame-Unterstützung

In der folgenden Tabelle ist die Jumbo Frame-Unterstützung zwischen Google Cloud-Produkten und -Features zusammengefasst:

Produkt oder Funktion Jumbo Frame-Unterstützung
Compute Engine Ja
Cloud Interconnect Ja
Cloud VPN Nein
Google APIs Nein

Einstellungen für VMs und MTU

Als Best Practice sollten Sie die NIC-MTU einer VM der MTU des VPC-Netzwerks zuordnen, mit dem die NIC verbunden ist:

  • Jede NIC-MTU für eine Linux-VM, die auf einem öffentlichen Betriebssystem-Image basiert, wird mithilfe von DHCP-Option 26 automatisch auf die jeweilige VPC-Netzwerk-MTU festgelegt.

  • Jede NIC-MTU für eine Windows-VM, die auf einem öffentlichen Betriebssystem-Image basiert, wird mit einer festen MTU von 1,460 Byte konfiguriert. Wenn Sie die MTU eines VPC-Netzwerks ändern, das Windows-VMs basierend auf von öffentlichen Betriebssystem-Images enthält, müssen Sie die MTU für die Windows-VM ändern.

  • Wenn Sie benutzerdefinierte Gastbetriebssystem-Images verwenden, müssen Sie NIC-MTUs konfigurieren oder mithilfe von DHCP-Option 26 prüfen, ob das Gastbetriebssystem die MTU des VPC-Netzwerks akzeptiert.

  • Wenn eine VM mehrere Netzwerkschnittstellen hat, legen Sie für jede NIC-MTU die entsprechende VPC-Netzwerk-MTU fest.

  • Wenn sich die MTU einer NIC von der MTU des VPC-Netzwerks unterscheiden muss, muss die MTU der NIC kleiner als die MTU des VPC-Netzwerks sein. Das erzwungene Verringern der NIC-MTU ist bei einigen erweiterten Netzwerkszenarien vorteilhaft.

MTU eines VPC-Netzwerks ändern

Wenn Sie die MTU eines VPC-Netzwerks mit laufenden VMs ändern, beachten Sie Folgendes:

  • Wenn Sie die VPC-Netzwerk-MTU reduzieren, müssen Sie jede VM beenden und starten. Durch einen Neustart einer VM innerhalb ihres Gastbetriebssystems wird die MTU nicht aktualisiert.

  • Wenn Sie die VPC-Netzwerk-MTU erhöhen, nutzt das Ausführen von VMs, die das VPC-Netzwerk verwenden, die erhöhte VPC-Netzwerk-MTU erst, wenn die VMs angehalten und gestartet wurden. Solange nicht alle VMs angehalten und neu gestartet wurden, verwendet die VM weiterhin den vorherigen (niedrigeren) MTU-Wert.

Eine Anleitung finden Sie unter MTU-Einstellung eines VPC-Netzwerks ändern.

GKE- und MTU-Einstellungen

Die für eine Pod-Schnittstelle ausgewählte MTU hängt von der von den Clusterknoten verwendeten Container Network Interface (CNI) und der zugrunde liegenden VPC-MTU-Einstellung ab. Weitere Informationen finden Sie unter Pods.

Der MTU-Wert der Pod-Schnittstelle ist entweder 1460 oder wird von der primären Schnittstelle des Knotens übernommen.

CNI MTU GKE Standard
kubenet 1460 Standard
kubenet
(GKE-Version 1.26.1 und höher) 		Übernommen Standard
Calico 1460

Aktiviert mit --enable-network-policy.

Weitere Informationen finden Sie unter Kommunikation zwischen Pods und Services mithilfe von Netzwerkrichtlinien steuern.
netd Übernommen Aktiviert durch Verwendung einer der folgenden Optionen:
GKE Dataplane V2 Übernommen

Aktiviert mit --enable-dataplane-v2.

Weitere Informationen finden Sie unter GKE Dataplane V2 verwenden.

Nicht übereinstimmende MTUs, MSS-Clamping, Pfad-MTU-Erkennung

In diesem Abschnitt wird beschrieben, wie TCP- und Nicht-TCP-Protokolle nicht übereinstimmende MTUs verarbeiten.

TCP-Protokoll

Das TCP-Protokoll verarbeitet MTU-Abweichungen automatisch. Sowohl der Client als auch der Server berechnen bei jedem Öffnen einer TCP-Verbindung einzeln ihre eigenen Werte für die maximale TCP-Segmentgröße (MSS). Client und Server müssen sich nicht auf einen identischen effektiven MSS-Wert einigen.

  • Effektive maximale TCP-Segmentgröße (MSS) des Clients: Die größte Menge an übertragbaren Daten in einem TCP-Segment, das von einem Client an einen Server gesendet wird, ist das Minimum der folgenden beiden Werte:

    • Der Wert des MSS-Felds im SYN-ACK-Paket, das vom Client während des TCP-Verbindungsaufbaus vom Server empfangen wurde.

    • Die MTU der Netzwerkschnittstelle des Clients, abzüglich 40 Byte. Die abgezogenen 40 Byte umfassen 20 Byte für den IP-Header und 20 Byte für den Basis-TCP-Header.

  • Effektive maximale TCP-Segmentgröße (MSS) des Servers: Die größte Menge an übertragbaren Daten in einem TCP-Segment, das von einem Server an einen Client gesendet wird, ist das Minimum der folgenden beiden Werte:

    • Der Wert des MSS-Felds im SYN-Paket, der vom Server während des TCP-Verbindungsaufbaus vom Client empfangen wurde.

    • Die MTU der Netzwerkschnittstelle des Servers, abzüglich 40 Byte. Die abgezogenen 40 Byte umfassen 20 Byte für den IP-Header und 20 Byte für den Basis-TCP-Header.

TCP-MSS-Clamping

Beim TCP-MSS-Clamping ändert ein Netzwerkgerät zwischen einem Client und einem Server die MSS-Werte in SYN- und SYN-ACK-Paketen, während es die Pakete zwischen dem Client und dem Server weiterleitet. Google Cloud verwendet MSS Clamping, wenn Pakete an Ziele außerhalb eines VPC-Netzwerks gesendet werden.

Cloud VPN-Tunnel und Cloud Interconnect-VLAN-Anhänge verwenden ebenfalls die MSS-Begrenzung. Weitere Informationen finden Sie unter Paketkapselung und -verarbeitung in der Cloud VPN-Dokumentation und Cloud Interconnect-MTU.

In VPC-Netzwerken wird kein MSS-Clamping für Pakete durchgeführt, die von den nächsten Hops innerhalb eines VPC-Netzwerks weitergeleitet werden, da das TCP-Protokoll selbst ausreicht.

Nicht-TCP-Protokolle

Andere Protokolle wie UDP erfordern besondere Sorgfalt, wenn zwei verschiedene VPC-Netzwerk-MTUs beteiligt sind. Ein sendendes System ist dafür verantwortlich, Pakete zu senden, die in die MTU seiner Netzwerkschnittstelle, die MTU der Netzwerkschnittstelle des Empfängersystems und die MTU aller dazwischen liegenden Netzwerke passen. Google Cloud führt keine IP-Fragmentierung für Pakete durch, die von den nächsten Hops innerhalb eines VPC-Netzwerks weitergeleitet werden.

Wenn ein IP-Paket für die Übermittlung zu groß ist, z. B. wenn das Paket die MTU des VPC-Netzwerks überschreitet, in dem sich die NIC der empfangenden VM befindet, löscht Google Cloud das Paket. Wenn das DF-Bit des Pakets festgelegt ist, sendet Google Cloud außerdem eine Nachricht „Fragmentierung erforderlich“ (ICMP über IPv4) oder „Paket zu groß“ (ICMPv6) an den Absender zurück.

Google Cloud sendet in den folgenden Fällen eine Nachricht „Fragmentierung erforderlich“ oder „Paket zu groß“, auch wenn ein DF-Bit deaktiviert ist:

  • Wenn die MTU des VPC-Netzwerks weniger als 1.600 Byte beträgt und das gesendete Paket die MTU des VPC-Netzwerks überschreitet.
  • Wenn die MTU des VPC-Netzwerks mindestens 1.600 Byte beträgt und das gesendete Paket mehr als 1.600 Byte hat.

Nachrichten "ICMP-Fragmentierung erforderlich" oder "Paket zu groß" sind für eine VM erforderlich, die Pakete sendet, um Path MTU Discovery (PMTUD) zu verwenden. Zur Veranschaulichung der Funktionsweise von PMTUD wird das folgende Beispiel mit zwei VMs in verschiedenen VPC-Netzwerken betrachtet, die über VPC-Netzwerk-Peering verbunden sind:

  • Die sendende VM hat eine NIC in einem VPC-Netzwerk mit einer MTU von 8.896 Byte.
  • Die Empfänger-VM hat eine NIC in einem VPC-Netzwerk mit einer MTU von 1.460 Byte.
  • Die sendende VM sendet ein IP-Paket mit 8.000 Byte, dessen Bit „Nicht fragmentieren“ (DF) festgelegt ist. Da das Paket für die Zustellung an die empfangende VM zu groß ist, sendet Google Cloud die Nachricht „Fragmentierung erforderlich“ oder „Paket zu groß“ an die sendende VM. Diese Nachricht gibt die maximal mögliche IP-Paketgröße an, die der Absender verwenden kann, wenn er versucht, Pakete für die Verbindung noch einmal zu übertragen.
  • Das Betriebssystem der sendenden VM verwendet diese Informationen, um die IP-Paketgröße zu verringern, wenn nachfolgende Pakete an die empfangende VM gesendet werden.

Für PMTUD gelten die folgenden zusätzlichen Anforderungen, da von PMTUD generierte Pakete vom Typ „Fragmentierung erforderlich“ oder „Paket zu groß“ das ICMP-Protokoll verwenden und Quellen haben, die mit dem Ziel eines ursprünglichen Pakets übereinstimmen:

  • Sie müssen VPC-Firewallregeln oder Regeln in Firewallrichtlinien für eingehenden Traffic konfigurieren, damit ICMP (für IPv4) oder ICMPv6 (für IPv6) aus Quellen, die mit den ursprünglichen Paketzielen übereinstimmen, erlaubt sind. Um die Firewallkonfiguration zu vereinfachen, sollten Sie ICMP und ICMPv6 aus allen Quellen zulassen.
  • Weiterleitungsregeln für den internen Passthrough-Network Load Balancer und die interne Protokollweiterleitung müssen das L3_DEFAULT-Protokoll verwenden, damit sie sowohl ICMP für Path MTU Discovery (PMTUD) als auch das vom ursprünglichen Paket verwendete Protokoll verarbeiten.

Nächste Schritte

Überzeugen Sie sich selbst

Wenn Sie mit Google Cloud noch nicht vertraut sind, erstellen Sie einfach ein Konto, um die Leistungsfähigkeit von VPC in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.

VPC kostenlos testen