8. Multihoming NVEs - NVE Residing in ToR Switch

8. Multihoming NVEs - NVE Residing in ToR Switch (Multihoming-NVEs - NVE im ToR-Switch)

In diesem Abschnitt diskutieren wir das Szenario, in dem die NVEs in den ToR-Switches residieren UND die Server (wo VMs residieren) mit diesen ToR-Switches multihomed sind. Der Multihoming-NVE arbeitet im All-Active- oder Single-Active-Redundanzmodus. Wenn die Server Single-Homed zu den ToR-Switches sind, wird das Szenario ähnlich dem, bei dem der NVE auf dem Hypervisor residiert, wie in Abschnitt 7 besprochen, was die erforderliche EVPN-Funktionalität betrifft.

[RFC7432] definiert eine Reihe von BGP-Routen, Attributen und Verfahren zur Unterstützung von Multihoming. Wir beschreiben zunächst diese Funktionen und Verfahren, dann diskutieren wir, welche davon durch die VXLAN- (oder NVGRE-) Kapselung beeinflusst werden und welche Modifikationen erforderlich sind. Wie später in diesem Abschnitt zu sehen sein wird, ist das einzige EVPN-Verfahren, das durch Nicht-MPLS-Overlay-Kapselung (z. B. VXLAN oder NVGRE) beeinflusst wird, bei der sie Platz für eine ID anstelle eines Label-Stacks bietet, das Split-Horizon-Filtering für multihomed ESs, das in Abschnitt 8.3.1 beschrieben wird.

8.1. EVPN Multihoming Features (EVPN-Multihoming-Funktionen)

In diesem Abschnitt werden wir die Multihoming-Funktionen von EVPN zusammenfassen, um die Kapselungsabhängigkeiten hervorzuheben. Der Abschnitt beschreibt die Funktionen nur auf hoher Ebene. Für weitere Details sollte der Leser auf [RFC7432] verweisen.

8.1.1. Multihomed ES Auto-Discovery (Multihomed ES Auto-Discovery)

EVPN-NVEs (oder PEs), die mit demselben ES verbunden sind (z. B. demselben Server über Link Aggregation Group (LAG)), können sich mit minimaler bis keiner Konfiguration durch den Austausch von BGP-Routen automatisch gegenseitig entdecken.

8.1.2. Fast Convergence and Mass Withdrawal (Schnelle Konvergenz und Massenrücknahme)

EVPN definiert einen Mechanismus, um Remote-NVEs effizient und schnell zu signalisieren, dass ihre Forwarding-Tabellen beim Auftreten eines Konnektivitätsfehlers zu einem ES (z. B. Link- oder Port-Fehler) aktualisiert werden müssen. Dies geschieht, indem jeder NVE eine Ethernet-A-D-Route pro ES für jedes lokal angeschlossene Segment ankündigt. Bei einem Konnektivitätsfehler zum angeschlossenen Segment zieht der NVE die entsprechende Ethernet-A-D-Route zurück. Dies löst aus, dass alle NVEs, die die Rücknahme erhalten, ihre Next-Hop-Adjacencies für alle MAC-Adressen aktualisieren, die mit dem betreffenden ES verbunden sind. Wenn kein anderer NVE eine Ethernet-A-D-Route für dasselbe Segment angekündigt hatte, dann invalidiert der NVE, der die Rücknahme erhielt, einfach die MAC-Einträge für dieses Segment. Andernfalls aktualisiert der NVE die Next-Hop-Adjacency-Liste entsprechend.

8.1.3. Split-Horizon (Split-Horizon)

Wenn ein Server mit zwei oder mehr NVEs (dargestellt durch ein ES ES1) multihomed ist und im All-Active-Redundanzmodus arbeitet, ein BUM-Paket (d. h. Broadcast, Unknown Unicast oder Multicast) an einen dieser NVEs sendet, dann ist es wichtig sicherzustellen, dass das Paket nicht über einen anderen mit diesem Server verbundenen NVE zum Server zurückgeschleift wird. Der Filtermechanismus auf dem NVE, um eine solche Schleife und Paketduplizierung zu verhindern, wird "Split-Horizon-Filtering" genannt.

8.1.4. Aliasing and Backup Path (Aliasing und Backup-Pfad)

Im Fall, dass eine Station mit mehreren NVEs multihomed ist, ist es möglich, dass nur ein einzelner NVE eine Reihe von MAC-Adressen lernt, die mit Verkehr verbunden sind, der von der Station übertragen wird. Dies führt zu einer Situation, in der Remote-NVEs MAC-Advertisement-Routen für diese Adressen von einem einzelnen NVE empfangen, obwohl mehrere NVEs mit der multihomed Station verbunden sind. Infolgedessen sind die Remote-NVEs nicht in der Lage, Verkehr effektiv zwischen den mit dem multihomed ES verbundenen NVEs zu verteilen. Dies könnte beispielsweise der Fall sein, wenn die NVEs Datenpath-Lernen auf dem Zugang durchführen und die Load-Balancing-Funktion auf der Station Verkehr von einer gegebenen Quell-MAC-Adresse zu einem einzelnen NVE hasht. Ein weiteres Szenario, in dem dies auftritt, ist, wenn die NVEs sich auf Control-Plane-Lernen auf dem Zugang verlassen (z. B. mit ARP), da ARP-Verkehr zu einem einzelnen Link im LAG gehasht wird.

Um dieses Problem zu mildern, führt EVPN das Konzept des "Aliasing" ein. Dies bezieht sich auf die Fähigkeit eines NVE, zu signalisieren, dass er Erreichbarkeit zu einem gegebenen lokal angeschlossenen ES hat, auch wenn er keine MAC-Adressen von diesem Segment gelernt hat. Die Ethernet-A-D-Route pro EVI wird zu diesem Zweck verwendet. Remote-NVEs, die MAC-Advertisement-Routen mit Nicht-Null-ESIs empfangen, sollten die MAC-Adresse als über alle NVEs erreichbar betrachten, die Erreichbarkeit zum relevanten Segment mit Ethernet-A-D-Routen mit demselben ESI und mit zurückgesetztem Single-Active-Flag ankündigen.

Backup-Pfad ist eine eng verwandte Funktion, obwohl sie auf den Fall anwendbar ist, in dem der Redundanzmodus Single-Active ist. In diesem Fall signalisiert der NVE, dass er Erreichbarkeit zu einem gegebenen lokal angeschlossenen ES hat, ebenfalls unter Verwendung der Ethernet-A-D-Route. Remote-NVEs, die die MAC-Advertisement-Routen mit Nicht-Null-ESI empfangen, sollten die MAC-Adresse als über den ankündigenden NVE erreichbar betrachten. Darüber hinaus sollten die Remote-NVEs einen Backup-Pfad für die genannte MAC zu dem NVE installieren, der Erreichbarkeit zum relevanten Segment mit einer Ethernet-A-D-Route mit demselben ESI und mit gesetztem Single-Active-Flag angekündigt hatte.

8.1.5. DF Election (DF-Wahl)

Wenn ein Host mit zwei oder mehr NVEs auf einem ES multihomed ist, das im All-Active-Redundanzmodus arbeitet, dann ist für einen gegebenen EVI nur einer dieser NVEs, der als "Designated Forwarder" (DF) bezeichnet wird, dafür verantwortlich, ihm Broadcast-, Multicast- und, falls für diesen EVI konfiguriert, Unknown-Unicast-Frames zu senden.

Dies ist erforderlich, um eine doppelte Zustellung von Multi-Destination-Frames zu einem multihomed Host oder einer VM im Fall von All-Active-Redundanz zu verhindern.

In NVEs, wo Frames, die als IEEE 802.1Q [IEEE.802.1Q] getaggt sind, von Hosts empfangen werden, sollte die DF-Wahl auf Basis von Host-VIDs gemäß Abschnitt 8.5 von [RFC7432] durchgeführt werden. Darüber hinaus KÖNNEN multihoming PEs eines gegebenen ES die DF-Wahl unter Verwendung konfigurierter IDs wie VNI, EVI, normalisierte VIDs usw. durchführen, solange die IDs konsistent über die multihoming PEs konfiguriert sind.

In GWs, wo VXLAN-gekapselte Frames empfangen werden, wird die DF-Wahl auf VNIs durchgeführt. Wiederum wird angenommen, dass für ein gegebenes Ethernet-Segment VNIs eindeutig und konsistent sind (z. B. keine doppelten VNIs existieren).

8.2. Impact on EVPN BGP Routes and Attributes (Auswirkungen auf EVPN-BGP-Routen und -Attribute)

Da Multihoming in diesem Szenario unterstützt wird, wird der gesamte Satz von BGP-Routen und Attributen, die in [RFC7432] definiert sind, verwendet. Die Einstellung des Ethernet-Tag-Felds in den MAC-Advertisement-, Ethernet-A-D-pro-EVI- und IMET-Routen folgt der in Abschnitt 5.1.3. Darüber hinaus folgt die Einstellung des VNI-Felds in den MAC-Advertisement- und Ethernet-A-D-pro-EVI-Routen der in Abschnitt 5.1.3.

8.3. Impact on EVPN Procedures (Auswirkungen auf EVPN-Verfahren)

Zwei Fälle müssen hier untersucht werden, abhängig davon, ob die NVEs im Single-Active- oder im All-Active-Redundanzmodus arbeiten.

Erstens betrachten wir den Fall des Single-Active-Redundanzmodus, bei dem die Hosts mit einem Satz von NVEs multihomed sind; jedoch ist nur ein einzelner NVE zu einem gegebenen Zeitpunkt für einen gegebenen VNI aktiv. In diesem Fall ist Aliasing nicht erforderlich, und Split-Horizon-Filtering ist möglicherweise nicht erforderlich, aber andere Funktionen wie multihomed ES Auto-Discovery, schnelle Konvergenz und Massenrücknahme, Backup-Pfad und DF-Wahl sind erforderlich.

Zweitens betrachten wir den Fall des All-Active-Redundanzmodus. In diesem Fall beeinflussen von allen in Abschnitt 8.1 aufgelisteten EVPN-Multihoming-Funktionen die Verwendung der VXLAN- oder NVGRE-Kapselung die Split-Horizon- und Aliasing-Funktionen, da diese beiden auf der MPLS-Client-Schicht beruhen. Da diese MPLS-Client-Schicht bei diesen Arten von Kapselungen fehlt, sind alternative Verfahren und Mechanismen erforderlich, um die erforderlichen Funktionen bereitzustellen. Diese werden als nächstes im Detail diskutiert.

8.3.1. Split Horizon (Split-Horizon)

In EVPN wird ein MPLS-Label für Split-Horizon-Filtering verwendet, um All-Active-Multihoming zu unterstützen, wobei ein Ingress-NVE ein Label hinzufügt, das dem Ursprungsstandort entspricht (auch bekannt als ESI-Label), wenn das Paket gekapselt wird. Der Egress-NVE überprüft das ESI-Label, wenn versucht wird, einen Multi-Destination-Frame über eine Schnittstelle weiterzuleiten, und wenn das Label dem gleichen Standortidentifikator (ESI) entspricht, der mit dieser Schnittstelle verbunden ist, wird das Paket verworfen. Dies verhindert das Auftreten von Forwarding-Loops.

Da VXLAN- und NVGRE-Kapselungen das ESI-Label nicht enthalten, müssen andere Mittel zur Durchführung der Split-Horizon-Filtering-Funktion für diese Kapselungen entwickelt werden. Der folgende Ansatz wird für Split-Horizon-Filtering empfohlen, wenn VXLAN- (oder NVGRE-) Kapselung verwendet wird.

Jeder NVE verfolgt die IP-Adresse(n), die mit dem/den anderen NVE(s) verbunden sind, mit denen er gemeinsame multihomed ESs hat. Wenn der NVE einen Multi-Destination-Frame aus dem Overlay-Netzwerk empfängt, untersucht er die Quell-IP-Adresse im Tunnel-Header (die dem Ingress-NVE entspricht) und filtert den Frame auf allen lokalen Schnittstellen heraus, die mit ESs verbunden sind, die mit dem Ingress-NVE geteilt werden. Bei diesem Ansatz ist es erforderlich, dass der Ingress-NVE eine lokale Replikation zu allen direkt angeschlossenen Ethernet-Segmenten durchführt (unabhängig vom DF-Wahlstatus) für allen gefluteten Verkehr, der von den Zugangsschnittstellen eingeht (d. h. von den Hosts). Dieser Ansatz wird als "Local Bias" bezeichnet und hat den Vorteil, dass nur eine einzelne IP-Adresse pro NVE für Split-Horizon-Filtering verwendet werden muss, im Gegensatz zur Anforderung einer IP-Adresse pro Ethernet-Segment pro NVE.

Um einen ordnungsgemäßen Betrieb des Split-Horizon-Filtering unter derselben Gruppe von multihoming PE-Geräten zu ermöglichen, DARF NICHT eine Mischung aus PE-Geräten mit MPLS-über-GRE-Kapselungen, die die Verfahren aus [RFC7432] für Split-Horizon-Filtering ausführen, einerseits und VXLAN/NVGRE-Kapselung, die Local-Bias-Verfahren ausführt, andererseits auf einem gegebenen Ethernet-Segment konfiguriert werden.

8.3.2. Aliasing and Backup Path (Aliasing und Backup-Pfad)

Die Aliasing- und Backup-Path-Verfahren für VXLAN/NVGRE-Kapselung sind den Verfahren für MPLS sehr ähnlich. Im Fall von MPLS wird die Ethernet-A-D-Route pro EVI für Aliasing verwendet, wenn der entsprechende ES im All-Active-Multihoming arbeitet, und dieselbe Route wird für Backup-Pfad verwendet, wenn der entsprechende ES im Single-Active-Multihoming arbeitet. Im Fall von VXLAN/NVGRE wird dieselbe Route für Aliasing und Backup-Pfad verwendet, mit dem Unterschied, dass die Ethernet-Tag- und VNI-Felder in der Ethernet-A-D-Route pro EVI wie in Abschnitt 5.1.3 beschrieben gesetzt werden.

8.3.3. Unknown Unicast Traffic Designation (Unknown-Unicast-Traffic-Designation)

In EVPN verwendet, wenn ein Ingress-PE Ingress-Replikation verwendet, um Unknown-Unicast-Traffic zu Egress-PEs zu fluten, der Ingress-PE ein anderes EVPN-MPLS-Label (von dem für Known-Unicast-Traffic verwendeten), um solchen BUM-Traffic zu identifizieren. Die Egress-PEs verwenden dieses Label, um solchen BUM-Traffic zu identifizieren und somit DF-Filtering für All-Active multihomed Sites anzuwenden. In Abwesenheit einer Unknown-Unicast-Traffic-Designation und in Anwesenheit der Aktivierung von Unknown-Unicast-Flooding kann es transienten doppelten Traffic zu All-Active multihomed Sites unter der folgenden Bedingung geben: Die Host-MAC-Adresse wird von den Egress-PE(s) gelernt und an den Ingress-PE angekündigt; jedoch wurde das MAC-Advertisement vom Ingress-PE noch nicht empfangen oder verarbeitet, was dazu führt, dass die Host-MAC-Adresse auf dem Ingress-PE unbekannt, aber auf den Egress-PE(s) bekannt ist. Daher, wenn ein Paket, das für diese Host-MAC-Adresse bestimmt ist, am Ingress-PE ankommt, flutet er es über Ingress-Replikation zu allen Egress-PE(s), und da sie den Egress-PE(s) bekannt sind, werden mehrere Kopien an die All-Active multihomed Site gesendet. Es sollte beachtet werden, dass solche transiente Paketduplizierung nur auftritt, wenn a) der Ziel-Host über All-Active-Redundanzmodus multihomed ist, b) Flooding von Unknown Unicast im Netzwerk aktiviert ist, c) Ingress-Replikation verwendet wird und d) Verkehr für den Ziel-Host am Ingress-PE ankommt, bevor er die Host-MAC-Adresse über BGP-EVPN-Advertisement lernt. Wenn es gewünscht wird, das Auftreten solcher transienten Paketduplizierung zu vermeiden (wie gering die Wahrscheinlichkeit auch sein mag), dann muss VXLAN-GPE-Kapselung zwischen diesen PEs verwendet werden, und der Ingress-PE muss das BUM Traffic Bit (B-Bit) [VXLAN-GPE] setzen, um anzuzeigen, dass dies ein Ingress-replizierter BUM-Traffic ist.