7. Single-Homing NVEs - NVE Residing in Hypervisor (Single-Homing NVEs - NVE im Hypervisor)

Wenn ein NVE und seine Hosts/VMs im selben physischen Gerät angeordnet sind, z.B. wenn sie sich in einem Server befinden, sind die Verbindungen zwischen ihnen virtuell und sie teilen normalerweise das gleiche Schicksal. Das heißt, die betreffenden Hosts/VMs sind normalerweise nicht multihomed oder, wenn sie multihomed sind, ist das Multihoming eine rein lokale Angelegenheit für den Server, der die VM und die NVEs hostet, und es muss für andere NVEs auf anderen Servern nicht "sichtbar" sein. Daher erfordert es keine spezifischen Protokollmechanismen. Der häufigste Fall hierfür ist, wenn der NVE im Hypervisor residiert.

In den folgenden Unterabschnitten werden wir die Auswirkungen auf EVPN-Verfahren für den Fall diskutieren, wenn der NVE im Hypervisor residiert und die VXLAN- (oder NVGRE-) Kapselung verwendet wird.

7.1. Impact on EVPN BGP Routes & Attributes for VXLAN/NVGRE Encapsulations (Auswirkungen auf EVPN-BGP-Routen und -Attribute für VXLAN/NVGRE-Kapselungen)

In Szenarien, in denen verschiedene Gruppen von Rechenzentren unter verschiedenen administrativen Domänen stehen und diese Rechenzentren über einen oder mehrere Backbone-Core-Provider verbunden sind, wie in [RFC7365] beschrieben, muss der RD ein eindeutiger Wert pro EVI oder pro NVE sein, wie in [RFC7432] beschrieben. Mit anderen Worten, wann immer es mehr als eine administrative Domäne für globale VNI gibt, muss ein eindeutiger RD verwendet werden; oder wann immer der VNI-Wert lokale Bedeutung hat, muss ein eindeutiger RD verwendet werden. Daher wird empfohlen, jederzeit einen eindeutigen RD zu verwenden, wie in [RFC7432] beschrieben.

Wenn die NVEs im Hypervisor residieren, sind die EVPN-BGP-Routen und -Attribute, die mit Multihoming verbunden sind, nicht mehr erforderlich. Dies reduziert die erforderlichen Routen und Attribute auf die folgende Teilmenge von vier von insgesamt acht, die in Abschnitt 7 von [RFC7432] aufgeführt sind:

MAC/IP Advertisement Route
Inclusive Multicast Ethernet Tag Route
MAC Mobility Extended Community
Default Gateway Extended Community

Wie jedoch in Abschnitt 8.6 von [RFC7432] erwähnt, sollte der Single-Homing-Eingangs-NVE in der Lage sein, Routen zu empfangen und zu verarbeiten, die Ethernet A-D per ES und Ethernet A-D per EVI sind, um einem Single-Homing-Eingangs-NVE zu ermöglichen, bei der Interaktion mit multihomed Ausgangs-NVEs, die an einen gegebenen ES angeschlossen sind, von schneller Konvergenz, Aliasing und Backup Path zu profitieren.

7.2. Impact on EVPN Procedures for VXLAN/NVGRE Encapsulations (Auswirkungen auf EVPN-Verfahren für VXLAN/NVGRE-Kapselungen)

Wenn die NVEs auf den Hypervisoren residieren, sind die EVPN-Verfahren, die mit Multihoming verbunden sind, nicht mehr erforderlich. Dies beschränkt die Verfahren auf dem NVE auf die folgende Teilmenge:

Lokales Lernen von MAC-Adressen, die von den VMs empfangen werden, gemäß Abschnitt 10.1 von [RFC7432].
Ankündigung lokal gelernter MAC-Adressen in BGP unter Verwendung der MAC/IP Advertisement-Routen.
Durchführung des Remote-Lernens unter Verwendung von BGP gemäß Abschnitt 9.2 von [RFC7432].
Entdeckung anderer NVEs und Aufbau der Multicast-Tunnel unter Verwendung der IMET-Routen.
Behandlung von MAC-Adress-Mobilitätsereignissen gemäß den Verfahren von Abschnitt 15 in [RFC7432].

Wie jedoch in Abschnitt 8.6 von [RFC7432] erwähnt, sollte ein Single-Homing-Eingangs-NVE, um einem Single-Homing-Eingangs-NVE zu ermöglichen, bei der Interaktion mit multihomed Ausgangs-NVEs, die an einen gegebenen ES angeschlossen sind, von schneller Konvergenz, Aliasing und Backup Path zu profitieren, die Eingangsknoten-Verarbeitung von Routen implementieren, die Ethernet A-D per ES und Ethernet A-D per EVI sind, wie in den Abschnitten 8.2 ("Fast Convergence") und 8.4 ("Aliasing and Backup Path") von [RFC7432] definiert.