GENEVE-Format

Die Generic Network Virtualization Encapsulation (GENEVE) ist ein Netzwerk Datenkapselungsprotokoll, 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 0. Weitere Informationen finden Sie unter Tunnel-Headerfelder. 2 Bit
Opt len Die Länge der Optionsfelder, ausgedrückt in 4-Byte-Vielfachen, ohne den 8-Byte-Tunnel-Header. Weitere Informationen finden Sie unter Tunnel-Headerfelder. 6 Bit
O Das Bit für das Kontrollpaket. Weitere Informationen finden Sie unter Tunnel-Headerfelder. 1 Bit
C Das Bit für kritische Optionen. Weitere Informationen finden Sie unter Tunnel-Headerfelder. 1 Bit
Rsvd Reserviertes Feld, das bei der Übertragung 0 sein muss und beim Empfang ignoriert werden muss. Weitere Informationen finden Sie unter Tunnel-Headerfelder. 6 Bit
Protokolltyp Der Protokolltyp lässt jeden Ethertype zu. Bei der Netzwerksicherheits-Integration sind jedoch nur IPv4 (0x0800) oder IPv6 (0x86DD) zulässig. 16 Bit
ID des virtuellen Netzwerks (Virtual Network Identifier, VNI) Eine eindeutige Kennung für ein Element des virtuellen Netzwerks. Bei der Netzwerksicherheits-Integration wird dieses Feld nicht ausgefüllt. Das bedeutet, dass die VNI auf 0 gesetzt ist. Weitere Informationen finden Sie unter Out-of-Band-Integration GENEVE. 24 Bit
Rsvd Reserviertes Feld, das bei der Übertragung 0 sein muss und beim Empfang ignoriert werden muss. Weitere Informationen finden Sie unter Tunnel-Headerfelder. 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 Typkennung, einem Längenfeld, das die Größe des Werts angibt, und dem Wert selbst codiert wird. Dieses Format ermöglicht Flexibilität und Erweiterbarkeit, da neue Optionen hinzugefügt werden können, ohne bestehende Implementierungen zu stören. In den folgenden Abschnitten werden die Reihenfolge und Anzahl der Optionen beschrieben. Die Anzahl und Reihenfolge der Optionen variieren im Laufe der Produktentwicklung. Damit die Geräteimplementierung zukunftssicher ist, sollten Sie den GENEVE-Header anhand der TLV-Felder parsen.

Die spezifischen GENEVE-Optionen für Google Cloud sind:

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

Netzwerk-ID

Die Option „Netzwerk-ID“, auch „Netzwerk-Cookie“ genannt, identifiziert das virtuelle Netzwerk, das mit dem GENEVE-gekapselten Traffic inverknüpft ist Google Cloud. Diese Option wird durch die Optionsklasse 0x0132 (Google) und den Typ 1 (Netzwerk-ID) identifiziert. Die Optionsdaten enthalten 32 Bit, von denen die ersten 28 eine intransparente Netzwerk-ID darstellen. Der Zweck der verbleibenden 4 Bit 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 dargestellten Optionsfelder beschrieben:

Feld Beschreibung Feldlänge
Optionsklasse Identifiziert die Organisation oder Entität, die die Option definiert hat. Der Wert 0x0132 gibt Google als definierende Entität an. 16 Bit
Typ Identifiziert den Typ der Option innerhalb einer Klasse. Der Wert 0x1 gibt die Option „Netzwerk-ID“ an. Weitere Informationen finden Sie unter Tunneloptionen. 8 Bit
R Die Optionssteuerungs-Flags, die für die zukünftige Verwendung reserviert sind. Diese Bits müssen bei der Übertragung 0 sein und beim Empfang ignoriert werden. 3 Bit
Len Die Länge der Nutzlast der Option in 4-Byte-Schritten. Die Nutzlast der Netzwerk-ID ist 32 Bit (4 Byte). Die Länge für diese Option ist also auf 1 gesetzt. 5 Bit
Netzwerk-Cookie Das intransparente Netzwerk-Cookie, das ein virtuelles Netzwerk identifiziert. 28 Bit
R Für die zukünftige Implementierung reserviert. Muss bei der Übertragung auf 0 gesetzt werden 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. 0 bedeutet Ingress und 1 bedeutet ein Egress-Paket auf der ursprünglichen gespiegelten virtuellen Maschine (VM). 1 Bit

Endpunkt-ID

Die Option „Endpunkt-ID“, auch „Endpunkt-Cookie“ genannt, identifiziert eindeutig den Erfassungspunkt, der ein Netzwerkschnittstellencontroller auf einer Google CloudVM ist. Diese Option wird durch die Optionsklasse 0x0132 (Google) und den Typ 2 (Endpunkt-ID) identifiziert. Die Optionsdaten sind ein intransparenter 128-Bit-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 dargestellten Optionsfelder beschrieben:

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

Profil-ID

Die Option „Profil-ID“ identifiziert die Gruppe des Sicherheitsprofils für die Spiegelung , 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. Das Zielgerät kann Sicherheitsrichtlinien basierend auf der Kennung der Profilgruppe erzwingen.

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 dargestellten Optionsfelder beschrieben:

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

GENEVE-Headerformate für die Netzwerksicherheits-Integration

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

IPv4-Header

Das GENEVE-Paketformat kapselt einen kompakten Tunnel-Header in UDP über IPv4. Ein kleiner fester Tunnel-Header bietet Kontrollinformationen 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 im vorherigen Diagramm dargestellten IPv4-Headerfelder beschrieben:

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

UDP-Header

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

Das folgende Diagramm zeigt das Headerformat für ein Geneve-Paket, das in UDP 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 im vorherigen Diagramm dargestellten UDP-Headerfelder beschrieben:

Felder Beschreibung
Quellport Ein intransparenter Hash über den gesamten 16-Bit-Bereich. Der Wert ist für alle Pakete gleich, die zu einem einzelnen gekapselten Flow gehören (in beide Richtungen).
Zielport Die angegebene Zielportnummer für GENEVE-Traffic, auf 6081 gesetzt.
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 den Diensten der Netzwerksicherheits-Integration verwendet werden, insbesondere für die 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 -spezifischen Metadaten wie dem Netzwerk-Cookie versehen. Google Cloud

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

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 fürversehen sind, z. B. dem Netzwerk-Cookie.

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 Google Cloud-spezifische GENEVE-Optionen.

Die In-Band-Integration unterstützt die erneute Einspeisung von Paketen in den ursprünglichen Endpunkt über einen logischen bidirektionalen GENEVE-Tunnel, der aus zwei unidirektionalen GENEVE-Tunneln besteht. Nachdem das Netzwerkgerät des Erstellers ein Paket abgefangen und geprüft hat, kann es das Paket entweder verwerfen oder erneut einspeisen. Um das Paket erneut einzuspeisen, führt das Gerät folgende Schritte aus:

  • Das Paket wird mit dem ursprünglichen GENEVE-Header (gleiche Optionen) neu gekapselt.
  • Die Quell- und Zieladressen werden im äußeren IP-Header ausgetauscht.
  • Die Prüfsummen sind korrekt.

Das folgende Diagramm zeigt, wie Google Cloud-spezifische GENEVE-Optionen für 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 (Maximum Transmission Unit, 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 ist eine MTU von 8.896 Byte zulässig. Für die Netzwerksicherheits-Integration müssen jedoch 308 Byte für den Aufwand der GENEVE-Datenkapselung reserviert werden. Diese Reservierung hat Auswirkungen auf die Netzwerke von Nutzern und Erstellern:

  • MTU des Nutzernetzwerks: Die MTU für das Nutzernetzwerk darf nicht mehr als 8.588 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 Erstellernetzwerks: Die MTU für das Erstellernetzwerk muss mindestens 308 Byte mehr als die MTU des Nutzernetzwerks betragen. Diese Zulage berücksichtigt die zusätzliche GENEVE-Datenkapselung.

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

Nächste Schritte