GENEVE-Format

Die GENEVE-Paketdatenkapselung (Generic Network Virtualization Encapsulation) ist ein Netzwerkdatenkapselungsprotokoll, mit dem das ursprüngliche Paket mit zusätzlichen Metadaten gekapselt wird. Diese zusätzlichen Metadaten ermöglichen eine flexible und erweiterbare Netzwerkvirtualisierung.

Das folgende Diagramm zeigt das Headerformat eines GENEVE-Pakets.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Ver|  Opt len  |O|C|   Rsvd.   |         Protocol type         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Virtual network identifier (VNI)       |     Rsvd.     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   

In der folgenden Tabelle werden die im vorherigen Diagramm dargestellten GENEVE-Headerfelder beschrieben:

Feld Beschreibung Feldlänge
Ver Die Version des GENEVE-Protokolls. Die einzige unterstützte Version ist null (0). Weitere Informationen finden Sie unter Tunnel-Header-Felder. 2 Bit
Opt len Die Länge der Optionsfelder, ausgedrückt in 4-Byte-Vielfachen, ohne den 8-Byte-Tunnelheader. Weitere Informationen finden Sie unter Tunnel-Header-Felder. 6 Bit
O Das Kontrollpaketbit. Weitere Informationen finden Sie unter Tunnel-Header-Felder. 1 Bit
C Das kritische Optionsbit. Weitere Informationen finden Sie unter Tunnel Header Fields. 1 Bit
Rsvd Reserviertes Feld, das bei der Übertragung null (0) sein muss und beim Empfang ignoriert werden muss. Weitere Informationen finden Sie unter Tunnel-Header-Felder. 6 Bit
Protokolltyp Der Protokolltyp lässt jeden Ethertype zu. Die Netzwerksicherheitsintegration unterstützt jedoch nur IPv4 (0x0800) oder IPv6 (0x86DD). 16 Bit
Virtual Network Identifier (VNI) Eine eindeutige Kennung für ein virtuelles Netzwerkelement. Bei der Integration der Netzwerksicherheit wird dieses Feld nicht ausgefüllt. Das bedeutet, dass der VNI auf null (0) gesetzt ist. Weitere Informationen finden Sie unter Out-of-Band-Integration GENEVE. 24 Bit
Rsvd Reserviertes Feld, das bei der Übertragung null (0) sein muss und beim Empfang ignoriert werden muss. Weitere Informationen finden Sie unter Tunnel-Header-Felder. 8 Bit

Google Cloud-spezifische GENEVE-Optionen

Der GENEVE-Header verwendet für seine Optionen das TLV-Format (Type-Length-Value). Das bedeutet, dass jede Option mit einer Typ-ID, einem Längenfeld, das die Größe des Werts angibt, und dem Wert selbst codiert wird. Dieses Format bietet Flexibilität und Erweiterbarkeit, da neue Optionen hinzugefügt werden können, ohne bestehende Implementierungen zu beeinträchtigen. In den folgenden Abschnitten werden die Reihenfolge und Anzahl der Optionen beschrieben. Die Anzahl und Reihenfolge der Optionen können sich im Laufe der Zeit ändern. Um die Vorwärtskompatibilität für Ihre Geräteimplementierung zu gewährleisten, sollten Sie den GENEVE-Header anhand der TLV-Felder parsen.

Die GENEVE-Optionen, die speziell für Google Cloud gelten, sind:

  • Netzwerk-ID (Netzwerk-Cookie)
  • Endpunkt-ID (Endpunkt-Cookie)
  • Profil-ID

Netzwerk-ID

Die Netzwerk-ID-Option, auch als „Netzwerk-Cookie“ bezeichnet, identifiziert das virtuelle Netzwerk, das dem GENEVE-gekapselten Traffic in Google Cloudzugeordnet ist. Diese Option wird durch die Optionsklasse 0x0132 (Google) und den Typ 1 (Network ID) angegeben. Die Optionsdaten enthalten 32 Bit, von denen die ersten 28 eine undurchsichtige Netzwerk-ID darstellen. Der Zweck der verbleibenden 4 Bits wird im folgenden Diagramm und in der folgenden Tabelle beschrieben.

Das folgende Diagramm zeigt das Optionsformat im GENEVE-Paket.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Option class=0x0132 (Google) |    Type=01    |R|R|R|  Len=1  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Network cookie                    |R|R|T|D|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   

In der folgenden Tabelle werden die im vorherigen Diagramm gezeigten Optionsfelder beschrieben:

Feld Beschreibung Feldlänge
Optionsklasse Gibt die Organisation oder Einheit an, die die Option definiert hat. Der Wert 0x0132 gibt Google als definierende Einheit an. 16 Bit
Typ Gibt den Typ der Option innerhalb einer Klasse an. Der Wert 0x1 gibt die Option „Network ID“ an. Weitere Informationen finden Sie unter Tunneloptionen. 8 Bit
R Die Option „control“ wird für die zukünftige Verwendung reserviert. Diese Bits müssen bei der Übertragung null (0) sein und beim Empfang ignoriert werden. 3 Bits
Len Die Länge der Nutzlast der Option in 4‑Byte-Schritten. Die Nutzlast der Netzwerk-ID ist 32 Bit (4 Byte) lang. Die Länge für diese Option ist also auf 1 festgelegt. 5 Bits
Netzwerk-Cookie Das intransparente Netzwerk-Cookie, das ein virtuelles Netzwerk identifiziert. 28 Bit
R Reserviert für zukünftige Implementierung. Muss bei der Übertragung auf null (0) gesetzt und beim Empfang ignoriert werden. 2 Bit
T Gibt die TLS-Auslagerung für das gekapselte Paket an. Nicht verwendet. 1 Bit
D Gibt die Richtung des ursprünglichen Pakets an. Null (0) steht für ein Ingress-Paket und eins (1) für ein Egress-Paket auf der ursprünglichen gespiegelten VM. 1 Bit

Endpunkt-ID

Die Option „Endpunkt-ID“, auch als „Endpunkt-Cookie“ bezeichnet, identifiziert den Erfassungspunkt eindeutig. Das ist ein Netzwerk-Interface-Controller auf einer Google Cloud-VM. Diese Option wird durch die Optionsklasse 0x0132 (Google) und den Typ 2 (Endpoint ID) identifiziert. Die Optionsdaten sind ein 128‑Bit-Opaque-Wert.

Das folgende Diagramm zeigt das Optionsformat im GENEVE-Paket.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Option class=0x0132 (Google) |     Type=02   |R|R|R|  Len=4  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                        Endpoint cookie                        +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   

In der folgenden Tabelle werden die im vorherigen Diagramm gezeigten Optionsfelder beschrieben:

Feld Beschreibung Feldlänge
Optionsklasse Gibt die Organisation oder Einheit an, die die Option definiert hat. Der Wert 0x0132 gibt Google als definierende Einheit an. 16 Bit
Typ Gibt den Typ der Option innerhalb einer Klasse an. Der Wert 0x2 gibt die Option „Endpunkt-ID“ an. Weitere Informationen finden Sie unter Tunneloptionen. 8 Bit
R Die Option „control“ wird für die zukünftige Verwendung reserviert. Diese Bits müssen bei der Übertragung null (0) sein und beim Empfang ignoriert werden. 3 Bits
Len Die Länge der Nutzlast in 4‑Byte-Schritten. Die Nutzlast der Endpunkt-ID ist 128 Bit (16 Byte), daher ist die Länge für diese Option auf 4 festgelegt. 5 Bits
Endpunkt-Cookie Eine intransparente Kennung für den Erfassungspunkt (eine VM-NIC). 128 Bit

Profil-ID

Mit der Option „Profil-ID“ wird die Sicherheitsprofilgruppe für die Spiegelung angegeben, die auf den Traffic angewendet wird. Diese Option wird durch die Optionsklasse 0x0132 (Google) und den Typ 3 (Profil-ID) identifiziert. Die Optionsdaten sind eine 64-Bit-Kennung, die dem Feld data_path_id in der Sicherheitsprofilgruppe entspricht. Auf dem Zielgerät können Sicherheitsrichtlinien basierend auf der Profilgruppen-ID erzwungen werden.

Das folgende Diagramm zeigt das Optionsformat im GENEVE-Paket.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Option class=0x0132 (Google) |    Type=03    |R|R|R|  Len=2  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                           Profile ID                          +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   

In der folgenden Tabelle werden die im vorherigen Diagramm gezeigten Optionsfelder beschrieben:

Feld Beschreibung Feldlänge
Optionsklasse Gibt die Organisation oder Einheit an, die die Option definiert hat. Der Wert 0x0132 gibt Google als definierende Einheit an. 16 Bit
Typ Gibt den Typ der Option innerhalb einer Klasse an. Der Wert 0x3 gibt die Option „Profil-ID“ an. Weitere Informationen finden Sie unter Tunneloptionen. 8 Bit
R Die Option „control“ wird für die zukünftige Verwendung reserviert. Diese Bits müssen bei der Übertragung null sein und beim Empfang ignoriert werden. 3 Bits
Len Die Länge der Nutzlast der Option in 4‑Byte-Schritten. Die Nutzlast der Profil-ID ist 64 Bit (8 Byte) lang. Die Länge für diese Option ist also auf 2 festgelegt. 5 Bits
Profil-ID Die Kennung der Spiegelungs-Sicherheitsprofilgruppe. 64 Bit

GENEVE-Header-Formate für die Netzwerksicherheits-Integration

In diesem Abschnitt werden die GENEVE-Headerformate beschrieben, die von Diensten zur Integration der Netzwerksicherheit verwendet werden.

IPv4-Header

Das GENEVE-Paketformat kapselt einen kompakten Tunnel-Header in UDP über IPv4. Ein kleiner, fester Tunnelheader enthält Steuerinformationen sowie grundlegende Funktionen und Interoperabilität.

Das folgende Diagramm zeigt die IPv4-Headerfelder für das GENEVE-Paket.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Version|  IHL  |Type of service|          Total length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Identification        |Flags|     Fragment offset     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Time to live | Proto=17 (UDP)|        Header checksum        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Source address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Destination address                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   

In der folgenden Tabelle werden die IPv4-Headerfelder beschrieben, die im vorherigen Diagramm dargestellt sind:

Feld Beschreibung
Proto=17 (immer UDP für GENEVE) Gibt an, dass die gekapselte Nutzlast das UDP-Protokoll verwendet.
Quelladresse Die Gateway-IP-Adresse des lokalen Subnetzes.
Zieladresse Die virtuelle IP-Adresse des vom Kunden bereitgestellten Load Balancers.

UDP-Header

Der UDP-Header RFC 0768 kapselt Daten und behält die verbindungslosen Semantiken von Ethernet und IP-Adresse bei. Außerdem wird für Router, die Equal Cost Multi-Path (ECMP) ausführen, Entropie bereitgestellt.

Das folgende Diagramm zeigt das Headerformat für ein Geneve-Paket, das in einem UDP-Paket gekapselt ist.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Source port = <hash>     |   Dest port = 6081 (Geneve)   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           UDP length          |          UDP checksum         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   

In der folgenden Tabelle werden die UDP-Headerfelder beschrieben, die im vorherigen Diagramm dargestellt sind:

Felder Beschreibung
Quellport Ein undurchsichtiger Hash über den gesamten 16-Bit-Bereich. Der Wert ist für alle Pakete, die zu einem einzelnen gekapselten Flow gehören (beide Richtungen), gleich.
Zielport Die angegebene Zielportnummer für GENEVE-Traffic, die auf 6081 festgelegt ist.
UDP-Länge Die Gesamtlänge des UDP-Datagramms, einschließlich des UDP-Headers und des gekapselten GENEVE-Pakets.
UDP-Prüfsumme Der Prüfsummenwert für das UDP-Datagramm, der zur Fehlererkennung verwendet wird.

Out-of-Band-Integration GENEVE

In diesem Abschnitt werden die GENEVE-Headerformate beschrieben, die von Diensten zur Integration der Netzwerksicherheit verwendet werden, insbesondere von der Out-of-Band-Integration. Bei der Out-of-Band-Integration wird ein GENEVE-Tunnel verwendet, um gespiegelte Pakete zu kapseln und zu übertragen. Die Pakete sind an die virtuelle IP-Adresse (VIP) des internen Load-Balancers des Collectors adressiert und mit Google Cloud-spezifischen Metadaten wie dem Netzwerk-Cookie versehen.

Die Google Cloud-spezifischen GENEVE-Optionen, die bei der Out-of-Band-Integration verwendet werden, sind Netzwerk-Cookie, Endpunkt-Cookie und Profil-ID. Weitere Informationen finden Sie unter GENEVE-Optionen fürGoogle Cloud.

Das folgende Diagramm zeigt, wie Google Cloud-spezifische GENEVE-Optionen bei der Out-of-Band-Integration verwendet werden.

       0                    1                   2                  3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |V=0|  Opt len  |O|C|   Rsvd    |         Protocol type         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Virtual network identifier (VNI) = 0   |     Rsvd.     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Option class=0x0132 (Google) |    Type=01    |R|R|R|  Len=1  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Network cookie                    |R|R|T|D|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Option class=0x0132 (Google) |    Type=02    |R|R|R|  Len=4  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                        Endpoint cookie                        +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Option class=0x0132 (Google) |    Type=03    |R|R|R|  Len=2  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                           Profile ID                          +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   

In-Band-Integration GENEVE

Bei der In-Band-Integration wird ein GENEVE-Tunnel verwendet, um abgefangene Pakete zu kapseln und zu übertragen. Die virtuelle IP-Adresse (VIP) des internen Load-Balancers des Erstellers empfängt die Pakete, die mit Google Cloud-spezifischen Metadaten wie dem Netzwerk-Cookie versehen sind.

Bei der In-Band-Integration werden die folgenden Google Cloud-spezifischen GENEVE-Optionen verwendet: Netzwerk-Cookie, Endpunkt-Cookie und Profil-ID. Weitere Informationen finden Sie unter GENEVE-Optionen fürGoogle Cloud.

Die In-Band-Integration unterstützt die erneute Einfügung von Paketen in den ursprünglichen Endpunkt über einen logischen bidirektionalen GENEVE-Tunnel, der aus zwei unidirektionalen GENEVE-Tunneln besteht. Nachdem die Netzwerk-Appliance des Producers ein Paket abgefangen und geprüft hat, kann sie es entweder verwerfen oder wieder einfügen. Um das Paket noch einmal einzufügen, geht die Appliance so vor:

  • Das Paket wird mit dem ursprünglichen GENEVE-Header (mit denselben Optionen) neu gekapselt.
  • Tauscht die Quell- und Zieladressen im äußeren IP-Header.
  • Prüft, ob die Prüfsummen korrekt sind.

Das folgende Diagramm zeigt, wie Google Cloud-spezifische GENEVE-Optionen bei der In-Band-Integration verwendet werden.

       0                    1                   2                  3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |V=0|  Opt len  |O|C|   Rsvd    |         Protocol type         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Virtual network identifier (VNI) = 0   |     Rsvd.     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Option Class=0x0132 (Google) |    Type=01    |R|R|R|  Len=1  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Network Cookie                    |R|R|T|D|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Option Class=0x0132 (Google) |    Type=02    |R|R|R|  Len=4  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                        Endpoint Cookie                        +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Option Class=0x0132 (Google) |    Type=03    |R|R|R|  Len=2  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                           Profile ID                          +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   

GENEVE-Datenkapselung und MTU-Anforderungen

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. Weitere Informationen finden Sie unter Maximale Übertragungseinheit.

In Google Cloud Netzwerken beträgt die zulässige MTU 8.896 Byte. Bei der Netzwerksicherheits-Integration müssen jedoch 396 Bytes für den Aufwand für die GENEVE-Datenkapselung reserviert werden. Diese Aufbewahrungsanforderung hat Auswirkungen auf Verbraucher- und Erstellernetzwerke:

  • MTU des Nutzer-Netzwerks: Die MTU für das Nutzer-Netzwerk darf maximal 8.500 Byte betragen. Dieses Limit sorgt dafür, dass genügend Platz für den GENEVE-Overhead vorhanden ist, ohne die maximale MTU zu überschreiten.

  • MTU des Produzentennetzwerks: Die MTU für das Produzentennetzwerk muss mindestens 396 Byte mehr als die MTU des Nutzernetzwerks betragen. Diese Toleranz berücksichtigt die zusätzliche GENEVE-Kapselung.

Wenn nicht genügend MTU-Limits für die GENEVE-Datenkapselung vorhanden sind, kann das Paket verworfen werden. Dies kann entweder auf der Ebene des virtuellen Netzwerks oder im Betriebssystem der VM erfolgen.

Nächste Schritte