5.1. VXLAN/NVGRE Encapsulation

5.1. VXLAN/NVGRE Encapsulation (VXLAN/NVGRE Kapselung)

Sowohl VXLAN als auch NVGRE sind Beispiele für Technologien, die eine Datenebenen-Kapselung bereitstellen, die verwendet wird, um ein Paket über die gemeinsame physische IP-Infrastruktur zwischen Network Virtualization Edges (NVEs) zu transportieren, z.B. VXLAN Tunnel End Points (VTEPs) in einem VXLAN-Netzwerk. Beide Technologien enthalten in jedem Paket die Kennung der spezifischen NVO-Instanz, VNI in VXLAN und VSID in NVGRE. Im Rest dieses Dokuments verwenden wir VNI als Darstellung für die NVO-Instanz mit dem Verständnis, dass VSID gleichermaßen verwendet werden kann, wenn die Kapselung NVGRE ist, sofern nicht anders angegeben.

Beachten Sie, dass ein PE einem NVE/VTEP entspricht.

Die VXLAN-Kapselung basiert auf UDP mit einem 8-Byte-Header nach dem UDP-Header. VXLAN stellt einen 24-Bit-VNI bereit, der typischerweise eine Eins-zu-Eins-Zuordnung zur Tenant-VID bietet, wie in [RFC7348] beschrieben. In diesem Szenario enthält der Ingress-VTEP kein inneres VLAN-Tag im gekapselten Frame, und der Egress-VTEP verwirft Frames mit einem inneren VLAN-Tag. Dieser Betriebsmodus in [RFC7348] entspricht dem VLAN-Based Service in [RFC7432], bei dem eine Tenant-VID einem EVI zugeordnet wird.

VXLAN bietet auch eine Option zum Einschließen eines inneren VLAN-Tags im gekapselten Frame, wenn dies am VTEP explizit konfiguriert ist. Dieser Betriebsmodus kann dem VLAN Bundle Service in [RFC7432] zugeordnet werden, da alle getaggten Frames des Tenants einer einzelnen Bridge-Tabelle / MAC-VRF zugeordnet werden und das innere VLAN-Tag nicht für die Suche durch den Disposition-PE bei der Durchführung der VXLAN-Entkapselung verwendet wird, wie in Abschnitt 6 von [RFC7348] beschrieben.

Die [RFC7637]-Kapselung basiert auf GRE-Kapselung und schreibt die Einbeziehung des optionalen GRE-Key-Felds vor, das die VSID trägt. Es gibt eine Eins-zu-Eins-Zuordnung zwischen der VSID und der Tenant-VID, wie in [RFC7637] beschrieben. Die Einbeziehung eines inneren VLAN-Tags ist verboten. Dieser Betriebsmodus in [RFC7637] entspricht dem VLAN Based Service in [RFC7432].

Wie im nächsten Abschnitt beschrieben, gibt es keine Änderung an der Kodierung von EVPN-Routen zur Unterstützung der VXLAN- oder NVGRE-Kapselung, außer der Verwendung der BGP Encapsulation Extended Community zur Angabe des Kapselungstyps (z.B. VXLAN oder NVGRE). Es gibt jedoch potenzielle Auswirkungen auf die EVPN-Verfahren, abhängig davon, wo sich der NVE befindet (d.h. im Hypervisor oder ToR) und ob Multihoming-Fähigkeiten erforderlich sind.

5.1.1. Virtual Identifiers Scope (Bereich virtueller Identifikatoren)

Obwohl VNIs als 24-Bit global eindeutige Werte definiert sind, gibt es Szenarien, in denen es wünschenswert ist, einen lokal signifikanten Wert für den VNI zu verwenden, insbesondere im Kontext einer Rechenzentrumsverbindung.

5.1.1.1. Data-Center Interconnect with Gateway (Rechenzentrumsverbindung mit Gateway)

Wenn NVEs in verschiedenen Rechenzentren verbunden werden müssen und die NVEs VNIs als global eindeutige Identifikatoren innerhalb eines Rechenzentrums verwenden müssen, muss ein Gateway (GW) am Rand des Rechenzentrumsnetzwerks (DCN) eingesetzt werden. Dies liegt daran, dass das Gateway die Funktionalität der Übersetzung des VNI beim Überqueren von Netzwerkgrenzen bereitstellt, die sich mit den Kontrollbereichsgrenzen des Betreibers ausrichten können. Betrachten Sie als Beispiel das Netzwerk von Abbildung 1. Nehmen Sie an, dass es drei Netzbetreiber gibt: einen für jedes der DC1-, DC2- und WAN-Netzwerke. Die Gateways am Rand der Rechenzentren sind für die Übersetzung der VNIs zwischen den in jedem der DCNs verwendeten Werten und den im WAN verwendeten Werten verantwortlich.

                        +--------------+
                        |              |
      +---------+       |     WAN      |       +---------+
+----+ |        +---+  +----+        +----+  +---+        |  +----+
|NVE1|-|        |   |  |WAN |        |WAN |  |   |        |-|NVE3|
+----+ |IP      |GW |-|Edge|        |Edge|--|GW | IP     |  +----+
+----+ |Fabric  +---+  +----+        +----+  +---+ Fabric |  +----+
|NVE2|-|         |       |              |       |         |-|NVE4|
+----+ +---------+       +--------------+       +---------+  +----+

|<------ DC 1 ------>                          <------ DC2  ------>|

         Abbildung 1: Rechenzentrumsverbindung mit Gateway

5.1.1.2. Data-Center Interconnect without Gateway (Rechenzentrumsverbindung ohne Gateway)

Wenn NVEs in verschiedenen Rechenzentren verbunden werden müssen und die NVEs lokal zugewiesene VNIs verwenden müssen (z.B. ähnlich wie MPLS-Labels), besteht möglicherweise keine Notwendigkeit, Gateways am Rand des DCN einzusetzen. Genauer gesagt wird der VNI-Wert, der vom sendenden NVE verwendet wird, vom NVE zugewiesen, der den Verkehr empfängt (mit anderen Worten, dies ähnelt einem "downstream-zugewiesenen" MPLS-Label). Dies ermöglicht es, den VNI-Raum zwischen verschiedenen DCNs zu entkoppeln, ohne dass ein dediziertes Gateway am Rand der Rechenzentren erforderlich ist. Dieses Thema wird in Abschnitt 10.2 behandelt.

                         +--------------+
                         |              |
         +---------+     |     WAN      |    +---------+
 +----+ |         |   +----+        +----+  |         |  +----+
 |NVE1|-|         |   |ASBR|        |ASBR|  |         |-|NVE3|
 +----+ |IP Fabric|---|    |        |    |--|IP Fabric|  +----+
 +----+ |         |   +----+        +----+  |         |  +----+
 |NVE2|-|         |     |              |    |         |-|NVE4|
 +----+ +---------+     +--------------+    +---------+  +----+

 |<------ DC 1 ----->                        <---- DC2  ------>|

          Abbildung 2: Rechenzentrumsverbindung mit ASBR

5.1.2. Virtual Identifiers to EVI Mapping (Zuordnung virtueller Identifikatoren zu EVI)

Genau wie in [RFC7432], wo zwei Optionen für die Zuordnung von Broadcast-Domänen (dargestellt durch VLAN-IDs) zu einem EVI existierten, gibt es auch zwei Optionen für die Zuordnung von Broadcast-Domänen, die durch VXLAN VNIs (oder NVGRE VSIDs) dargestellt werden, zu einem EVI, wenn die EVPN-Kontrollebene in Verbindung mit VXLAN (oder NVGRE-Kapselung) verwendet wird:

Option 1: Eine einzelne Broadcast-Domäne pro EVI

Bei dieser Option wird eine einzelne Ethernet-Broadcast-Domäne (z.B. Subnetz), die durch einen VNI dargestellt wird, einem eindeutigen EVI zugeordnet. Dies entspricht dem VLAN-Based Service in [RFC7432], bei dem eine Tenant-zugewandte Schnittstelle, logische Schnittstelle (z.B. dargestellt durch eine VID) oder physische Schnittstelle einem EVI zugeordnet wird. Als solches sind ein BGP Route Distinguisher (RD) und ein Route Target (RT) pro VNI auf jedem NVE erforderlich. Der Vorteil dieses Modells besteht darin, dass es ermöglicht, die BGP-RT-Constraint-Mechanismen zu verwenden, um die Propagierung und den Import von Routen nur auf die NVEs zu beschränken, die an einem bestimmten VNI interessiert sind. Der Nachteil dieses Modells kann der Bereitstellungsaufwand sein, wenn RD und RT nicht automatisch vom VNI abgeleitet werden.

Bei dieser Option wird die MAC-VRF-Tabelle in der Kontrollebene durch das RT und in der Datenebene durch den VNI identifiziert. Bei dieser Option entspricht die spezifische MAC-VRF-Tabelle nur einer einzigen Bridge-Tabelle.

Option 2: Mehrere Broadcast-Domänen pro EVI

Bei dieser Option werden mehrere Subnetze, die jeweils durch einen eindeutigen VNI dargestellt werden, einem einzelnen EVI zugeordnet. Wenn ein Tenant beispielsweise mehrere Segmente/Subnetze hat, die jeweils durch einen VNI dargestellt werden, werden alle VNIs für diesen Tenant einem einzelnen EVI zugeordnet; in diesem Fall repräsentiert das EVI beispielsweise den Tenant und nicht ein Subnetz. Dies entspricht dem VLAN-aware Bundle Service in [RFC7432]. Der Vorteil dieses Modells besteht darin, dass es die Bereitstellung eines RD/RT pro VNI nicht erfordert. Dies ist jedoch ein umstrittener Punkt im Vergleich zu Option 1, bei der Auto-Derivation verwendet wird. Der Nachteil dieses Modells besteht darin, dass Routen von NVEs importiert würden, die möglicherweise nicht an einem bestimmten VNI interessiert sind.

Bei dieser Option wird die MAC-VRF-Tabelle in der Kontrollebene durch das RT identifiziert; eine spezifische Bridge-Tabelle für diese MAC-VRF wird in der Kontrollebene durch <RT, Ethernet Tag ID> identifiziert. Bei dieser Option ist der VNI in der Datenebene ausreichend, um eine spezifische Bridge-Tabelle zu identifizieren.

5.1.2.1. Auto-Derivation of RT (Auto-Derivation von RT)

Um die Konfiguration zu vereinfachen, kann bei Verwendung der Option eines einzelnen VNI pro EVI das für EVPN verwendete RT automatisch abgeleitet werden. RD kann wie in [RFC7432] beschrieben automatisch generiert werden, und RT kann wie nachfolgend beschrieben automatisch abgeleitet werden.

Da ein Gateway-PE, wie in Abbildung 1 dargestellt, sowohl an den DCN- als auch an den WAN-BGP-Sitzungen teilnimmt, ist es wichtig, dass es, wenn RT-Werte automatisch von VNIs abgeleitet werden, keine Konflikte in RT-Räumen zwischen DCNs und WANs gibt, vorausgesetzt, beide arbeiten innerhalb desselben Autonomous System (AS). Es kann auch Szenarien geben, in denen sowohl VXLAN- als auch NVGRE-Kapselungen innerhalb desselben DCN benötigt werden können und ihre entsprechenden VNIs unabhängig verwaltet werden, was bedeutet, dass VNI-Räume sich überlappen können. Um Konflikte in RT-Räumen zu vermeiden, können die 6-Byte-RT-Werte mit 2-Oktett-AS-Nummer für DCNs wie folgt automatisch abgeleitet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Global Administrator      |    Local Administrator        |
+-----------------------------------------------+---------------+
| Local Administrator (Cont.)   |
+-------------------------------+

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Global Administrator      |A| TYPE| D-ID  | Service ID    |
+-----------------------------------------------+---------------+
|       Service ID (Cont.)      |
+-------------------------------+

Das 6-Oktett-RT-Feld besteht aus zwei Unterfeldern:

Global Administrator-Unterfeld: 2 Oktette. Dieses Unterfeld enthält eine von der IANA zugewiesene AS-Nummer <https://www.iana.org/assignments/as-numbers/>.
Local Administrator-Unterfeld: 4 Oktette
- A: Ein Einzelbit-Feld, das angibt, ob dieses RT automatisch abgeleitet ist
  - 0: automatisch abgeleitet
  - 1: manuell abgeleitet
- Type: Ein 3-Bit-Feld, das den Raum identifiziert, in dem die anderen 3 Bytes definiert sind. Die folgenden Räume sind definiert:
  - 0: VID (802.1Q VLAN ID)
  - 1: VXLAN
  - 2: NVGRE
  - 3: I-SID
  - 4: EVI
  - 5: dual-VID (QinQ VLAN ID)
- D-ID: Ein 4-Bit-Feld, das die Domain-ID identifiziert. Der Standardwert der Domain-ID ist null, was anzeigt, dass nur ein einzelner Nummerierungsraum für eine gegebene Technologie existiert. Wenn jedoch mehr als ein Nummerierungsraum für eine gegebene Technologie existiert (z.B. überlappende VXLAN-Räume), muss jeder der Nummerierungsräume durch seine entsprechende Domain-ID ab 1 identifiziert werden.
- Service ID: Dieses 3-Oktett-Feld ist auf VNI, VSID, I-SID oder VID gesetzt.

Es sollte beachtet werden, dass die RT-Auto-Derivation für 2-Oktett-AS-Nummern anwendbar ist. Für 4-Oktett-AS-Nummern muss das RT manuell konfiguriert werden, da 3-Oktett-VNI-Felder nicht in das 2-Oktett-Local-Administrator-Feld passen können.

5.1.3. Constructing EVPN BGP Routes (Konstruktion von EVPN BGP-Routen)

In EVPN wird beispielsweise ein MPLS-Label, das die Weiterleitungstabelle identifiziert, vom Egress-PE über die EVPN-Kontrollebene verteilt und vom Ingress-PE in den MPLS-Header eines gegebenen Pakets platziert. Dieses Label wird beim Empfang dieses Pakets vom Egress-PE für die Disposition dieses Pakets verwendet. Dies ist der Verwendung des VNI durch den Egress-NVE sehr ähnlich, mit dem Unterschied, dass ein MPLS-Label lokale Bedeutung hat, während ein VNI typischerweise globale Bedeutung hat. Entsprechend und speziell zur Unterstützung der Option lokal zugewiesener VNIs werden das MPLS-Label1-Feld in der MAC/IP Advertisement-Route, das MPLS-Label-Feld in der Ethernet A-D per EVI-Route und das MPLS-Label-Feld im P-Multicast Service Interface (PMSI) Tunnel-Attribut der Inclusive Multicast Ethernet Tag (IMET)-Route verwendet, um den VNI zu transportieren. Für den Rest dieses Memos werden die oben genannten MPLS-Label-Felder als VNI-Feld bezeichnet. Das VNI-Feld wird sowohl für lokale als auch für globale VNIs verwendet; in beiden Fällen wird das gesamte 24-Bit-Feld verwendet, um den VNI-Wert zu kodieren.

Für den VLAN-Based Service (ein einzelner VNI pro MAC-VRF) MUSS das Ethernet-Tag-Feld in den MAC/IP Advertisement-, Ethernet A-D per EVI- und IMET-Routen auf Null gesetzt werden, genau wie beim VLAN-Based Service in [RFC7432].

Für den VLAN-Aware Bundle Service (mehrere VNIs pro MAC-VRF, wobei jeder VNI mit seiner eigenen Bridge-Tabelle verbunden ist) MUSS das Ethernet-Tag-Feld in den MAC Advertisement-, Ethernet A-D per EVI- und IMET-Routen eine Bridge-Tabelle innerhalb einer MAC-VRF identifizieren; die Menge der Ethernet-Tags für dieses EVI muss auf allen PEs innerhalb dieses EVI konsistent konfiguriert werden. Für lokal zugewiesene VNIs MUSS der im Ethernet-Tag-Feld beworbene Wert auf eine VID gesetzt werden, genau wie beim VLAN-aware Bundle Service in [RFC7432]. Eine solche Einstellung muss auf allen PE-Geräten, die an diesem EVI innerhalb einer gegebenen Domäne teilnehmen, konsistent erfolgen. Für globale VNIs SOLLTE der im Ethernet-Tag-Feld beworbene Wert auf einen VNI gesetzt werden, solange er der vorhandenen Semantik des Ethernet-Tags entspricht, d.h. er identifiziert eine Bridge-Tabelle innerhalb einer MAC-VRF und die Menge der VNIs ist auf jedem PE in diesem EVI konsistent konfiguriert.

Um anzugeben, welcher Typ der Datenebenen-Kapselung (d.h. VXLAN, NVGRE, MPLS oder MPLS in GRE) verwendet werden soll, ist die in [RFC5512] definierte BGP Encapsulation Extended Community in allen EVPN-Routen (d.h. MAC Advertisement, Ethernet A-D per EVI, Ethernet A-D per ESI, IMET und Ethernet Segment) enthalten, die von einem Egress-PE beworben werden. Fünf neue Werte wurden von der IANA zugewiesen, um die Liste der in [RFC5512] definierten Kapselungstypen zu erweitern; sie sind in Abschnitt 11 aufgeführt.

Der MPLS-Kapselungs-Tunneltyp, der in Abschnitt 11 aufgeführt ist, wird benötigt, um zwischen einem werbenden Knoten zu unterscheiden, der nur Nicht-MPLS-Kapselungen unterstützt, und einem, der MPLS- und Nicht-MPLS-Kapselungen unterstützt. Ein werbender Knoten, der nur MPLS-Kapselung unterstützt, muss keine Kapselungs-Tunneltypen bewerben; d.h. wenn die BGP Encapsulation Extended Community nicht vorhanden ist, wird entweder MPLS-Kapselung oder eine statisch konfigurierte Kapselung angenommen.

Das Next-Hop-Feld des MP_REACH_NLRI-Attributs der Route MUSS auf die IPv4- oder IPv6-Adresse des NVE gesetzt werden. Die verbleibenden Felder in jeder Route werden gemäß [RFC7432] gesetzt.

Beachten Sie, dass das hier definierte Verfahren - das MPLS-Label-Feld zu verwenden, um den VNI in Gegenwart einer Tunnel Encapsulation Extended Community, die die Verwendung eines VNI spezifiziert, zu transportieren - mit den in Abschnitt 8.2.2.2 von [TUNNEL-ENCAP] beschriebenen Verfahren ("When a Valid VNI has not been Signaled") übereinstimmt.