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-Netzwerk

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

Kommunikation zwischen Compute-Instanzen in VPC-Netzwerken

IP-Pakete bis zur MTU-Größe können zwischen zwei Compute-Instanzen gesendet werden, wenn Folgendes zutrifft:

  • Sowohl die Sende- als auch die Empfangsinstanz verwenden dasselbe VPC-Netzwerk oder Peering-VPC-Netzwerke mit identischen MTUs.
  • Die Schnittstellen für beide Instanzen sind so konfiguriert, dass sie die MTU des VPC-Netzwerk 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, identische MTUs in verbundenen VPC-Netzwerken zu konfigurieren. Weitere Informationen dazu, wie Protokolle mit Situationen umgehen, in denen eine MTU-Abweichung zwischen VPC-Netzwerken vorliegt, finden Sie unter Nicht übereinstimmende MTUs, MSS-Clamping, Pfad-MTU-Erkennung.

Aus Sicht einer sendenden Instanz stellen Pfade zu den folgenden Zielen den Instanz-zu-Instanz-Traffic dar, der innerhalb eines VPC-Netzwerks 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 (NIC) einer empfangenden Instanz.
    • Eine interne IPv4-Adresse in einem Alias-IP-Bereich der NIC einer empfangenden Instanz.
    • 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 der NIC einer empfangenden Instanz 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 verwendet, wenn Pakete mithilfe von Subnetzrouten oder Peering-Subnetzrouten innerhalb des VPC-Netzwerks weitergeleitet werden:
    • Eine IPv6-Adresse aus dem IPv6-Adressbereich /96, die der NIC einer empfangenden Instanz zugewiesen ist.
    • Eine IPv6-Adresse aus dem IPv6-Adressbereich /96 einer externen Weiterleitungsregel für die Protokollweiterleitung oder für einen regionalen externen Passthrough-Network Load Balancer.

Die folgenden Instanz-zu-Instanz-Pfade werden genauso behandelt wie die Kommunikation mit Zielen außerhalb eines VPC-Netzwerks:

  • Wenn das Paketziel eine externe IPv4-Adresse der NIC einer empfangenden Instanz ist.
  • Wenn das Paketziel eine externe IPv4-Adresse eines regionalen 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 Instanz, eines regionalen externen Passthrough-Network-Load-Balancers oder einer Weiterleitungsregel für die externe Protokollweiterleitung ist und die anwendbare Route im VPC-Netzwerk einen Standard-Internetgateway-Next-Hop verwendet. In diesem Szenario befinden sich die empfangenden Instanzen weder im selben VPC-Netzwerk wie die sendende Instanz noch in einem VPC-Netzwerk, das über VPC-Netzwerk-Peering mit dem VPC-Netzwerk der sendenden Instanz verbunden ist.

Kommunikation mit Zielen außerhalb eines VPC-Netzwerks

Cloud de Confiance verarbeitet Pakete, die von Compute-Instanzen an Ziele außerhalb des VPC-Netzwerk der sendenden Instanz gesendet werden, wie in der folgenden Tabelle dargestellt. Zu den Zielen außerhalb des VPC-Netzwerks einer sendenden Instanz gehören öffentlich routingfähige IP-Adressen für Ressourcen außerhalb vonCloud de Confiance und vom Kunden verwendbare externe IP-Adressen innerhalb von Cloud de Confiance.

Da im Internet im Allgemeinen eine MTU von 1.500 Byte verwendet wird, lässt sich durch eine IP-Paketgröße von maximal 1.500 Byte in der Regel ein MTU-bezogener Paketverlust vermeiden.

Situation Verhalten
TCP-SYN- und SYN-ACK-Pakete Cloud de Confiance führt bei Bedarf MSS-Clamping durch und ändert die MSS, damit die Pakete in die MTU passen.
IP-Paket-MTU zwischen 1.300 Byte und 1.600 Byte (einschließlich) Cloud de Confiance nimmt keine Änderungen am Paket vor, mit Ausnahme von SYN- und SYN-ACK-Paketen, wie in der ersten Zeile erläutert.
IP-Paket mit mehr als 1.600 Byte Cloud de Confiance 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

Compute-Instanzen, 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 Details in diesem Abschnitt gelten auch für lokale Ressourcen, die Pakete über den privaten Google-Zugriff für lokale Hosts an Google APIs und Google-Dienste senden.

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

Paketquelle Paketziel

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

Eine externe IPv4-Adresse, die der Instanz-NIC mit einer 1-1-NAT-Zugriffskonfiguration zugewiesen ist: In diesem Fall führt Cloud de Confiance 1-1-NAT bei ausgehendem Traffic aus und konvertiert eine 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
  • 177.222.88.4/30 (eingeschränkt.s3nsapis.fr)
  • 177.222.88.0/30 (private.s3nsapis.fr)
  • Privater Service Connect-Endpunkt für Google APIs und -Dienste
Externe oder interne IPv6-Adresse für Dual-Stack- oder Nur-IPv6-Instanzen
  • IPv6-Adressen von Google APIs und -Diensten für die Standarddomains
  • 2a13:7500:8302:1::/64 (eingeschränkt.s3nsapis.fr)
  • 2a13:7500:8302::/64 (private.s3nsapis.fr)

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 Nutzlasten und andere Cloud VPN-MTU-Informationen finden Sie in der Cloud VPN-Dokumentation unter Überlegungen zur MTU.

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-Anhang finden Sie unter Cloud Interconnect-MTU.

Kommunikation über Firewall-Endpunkte

Wenn Sie Firewall-Endpunkte verwenden, konfigurieren Sie eine geeignete MTU für Ihr VPC-Netzwerk. Wenn die MTU-Einstellung Ihres VPC-Netzwerk die Paketgröße überschreitet, die Ihr Firewall-Endpunkt unterstützt, kann die Cloud Next Generation Firewall die Layer-7-Prüfung nicht erfolgreich ausführen. Weitere Informationen finden Sie unter Unterstützte Paketgröße.

Unterstützung von Jumbo Frames

Jumbo-Frames haben eine Nutzlast von mehr als 1.460 Byte. In der folgenden Tabelle ist die Unterstützung von Jumbo-Frames für Cloud de Confiance -Produkte und -Features zusammengefasst:

Produkt oder Funktion Unterstützung von Jumbo Frames
Compute Engine Ja
Cloud Interconnect Ja
Firewall-Endpunkte Ja
Cloud VPN Nein
Google APIs Nein

Compute-Instanzen und MTU-Einstellungen

Als Best Practice sollten Sie die MTU der NIC einer Compute-Instanz an die MTU des VPC-Netzwerk anpassen, mit dem die NIC verbunden ist. Die MTU-Konfiguration der NIC variiert je nach Betriebssystem und Konfiguration:

  • Linux-Instanzen, die auf einem öffentlichen Betriebssystem-Image basieren: Die MTU jeder NIC wird mithilfe der DHCP-Option 26 automatisch auf die MTU des jeweiligen VPC-Netzwerk festgelegt.

  • Windows-Instanzen, die auf einem öffentlichen Betriebssystem-Image basieren: Standardmäßig wird jede NIC-MTU mit einer festen MTU von 1,460 Byte konfiguriert. Wenn Sie die MTU eines VPC-Netzwerk ändern, das Windows-Instanzen basierend auf öffentlichen Betriebssystem-Images enthält, müssen Sie die MTU-Einstellung der Windows-Instanzen ändern.

  • Benutzerdefinierte Gastbetriebssystem-Images: Sie müssen NIC-MTUs konfigurieren oder prüfen, ob das Gastbetriebssystem die VPC-Netzwerk-MTU mit DHCP-Option 26 akzeptiert.

  • Instanzen mit mehreren Netzwerkschnittstellen: Legen Sie die MTU jeder NIC auf die MTU des jeweiligen VPC-Netzwerk fest.

Wenn sich die NIC-MTU von der VPC-Netzwerk-MTU unterscheiden muss, legen Sie die NIC-MTU auf einen Wert fest, der kleiner als die VPC-Netzwerk-MTU ist. Das erzwungene Verringern der NIC-MTU ist für einige erweiterte Netzwerkszenarien vorteilhaft.

MTU eines VPC-Netzwerk ändern

Um Verbindungsprobleme zu vermeiden, müssen Sie vor dem Ändern der MTU des VPC-Netzwerk zuerst jede Compute-Instanz beenden. Wenn Sie eine Instanz über das Gastbetriebssystem neu starten, wird die MTU nicht aktualisiert. Wenn Sie Instanzen mit einer niedrigeren MTU als der Netzwerk-MTU konfigurieren, müssen Sie die Instanz weiterhin beenden, bevor Sie die MTU ändern.

Weitere Informationen zum Ändern der Netzwerk-MTU 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 mit nicht übereinstimmenden MTUs umgehen.

TCP-Protokoll

Das TCP-Protokoll verarbeitet MTU-Abweichungen automatisch. Sowohl der Client als auch der Server berechnen jedes Mal, wenn eine TCP-Verbindung geöffnet wird, ihre eigenen effektiven Werte für die maximale TCP-Segmentgröße (MSS). Der Client und der 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 der Client während des Aufbaus der TCP-Verbindung vom Server empfangen hat.

    • 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, das der Server während des TCP-Verbindungsaufbaus vom Client empfangen hat.

    • Die MTU der Netzwerkschnittstelle des Servers minus 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

TCP-MSS-Clamping ist ein Prozess, bei dem ein Netzwerkgerät zwischen einem Client und einem Server die MSS-Werte in SYN- und SYN-ACK-Paketen ändert, während es die Pakete zwischen dem Client und dem Server weiterleitet. Cloud de Confiance 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 MSS-Clamping. Weitere Informationen finden Sie unter Paketkapselung und -verarbeitung in der Cloud VPN-Dokumentation und unter Cloud Interconnect-MTU.

VPC-Netzwerke führen kein MSS-Clamping für Pakete durch, die von den nächsten Hops innerhalb eines VPC-Netzwerk weitergeleitet werden, da das TCP-Protokoll selbst ausreicht.

Nicht-TCP-Protokolle

Andere Protokolle wie UDP erfordern besondere Aufmerksamkeit, wenn zwei verschiedene VPC-Netzwerk-MTUs beteiligt sind. Es liegt in der Verantwortung eines sendenden Systems, Pakete auszugeben, die in die MTU seiner Netzwerkschnittstelle, die MTU der Netzwerkschnittstelle des empfangenden Systems und die MTU aller Netzwerke dazwischen passen. Cloud de Confiance führt keine IP-Fragmentierung für Pakete durch, die von den nächsten Hops innerhalb eines VPC-Netzwerk weitergeleitet werden.

Wenn ein IP-Paket zu groß ist, um zugestellt zu werden, z. B. wenn das Paket die MTU des VPC-Netzwerk überschreitet, in dem sich die NIC der empfangenden Compute-Instanz befindet, wird das Paket von Cloud de Confiance verworfen. Wenn das DF-Bit des Pakets festgelegt ist, sendet Cloud de Confiance auch eine Nachricht „Fragmentierung erforderlich“ (ICMP über IPv4) oder „Paket zu groß“ (ICMPv6) an den Absender zurück.

Cloud de Confiance 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-Netzwerk kleiner als 1.600 Byte ist und das gesendete Paket 1.600 Byte überschreitet.
  • Wenn die MTU des VPC-Netzwerk 1.600 Byte oder mehr beträgt und das gesendete Paket die MTU des VPC-Netzwerk überschreitet.

Die Nachrichten „ICMP-Fragmentierung erforderlich“ oder „Paket zu groß“ sind für eine Compute-Instanz erforderlich, die Pakete sendet, um Path MTU Discovery (PMTUD) zu verwenden. Zur Veranschaulichung der Funktionsweise von PMTUD sehen Sie sich das folgende Beispiel mit zwei Compute-Instanzen in verschiedenen VPC-Netzwerken an, die über VPC-Netzwerk-Peering verbunden sind:

  • Die sendende Instanz hat eine NIC in einem VPC-Netzwerk mit einer MTU von 8.896 Byte.
  • Die empfangende Instanz hat eine NIC in einem VPC-Netzwerk mit einer MTU von 1.460 Byte.
  • Die sendende Instanz gibt ein 8.000-Byte-IP-Paket aus,dessen Bit „Nicht fragmentieren“ (DF) festgelegt ist. Da das Paket zu groß ist, um an die empfangende Instanz zugestellt zu werden, sendet Cloud de Confiance eine Nachricht „Fragmentierung erforderlich“ oder „Paket zu groß“ an die sendende Instanz. Diese Nachricht gibt die größtmö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 Instanz verwendet diese Informationen, um die IP-Paketgröße beim Senden nachfolgender Pakete an die empfangende Instanz zu verringern.

Für PMTUD gelten die folgenden zusätzlichen Anforderungen, da von PMTUD generierte „Fragmentierung erforderlich“- oder „Paket zu groß“-Pakete 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, können Sie ICMP und ICMPv6 von 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