10. Data-Center Interconnections (DCIs) (Rechenzentrums-Interconnections)

Für DCIs werden die folgenden zwei Hauptszenarien betrachtet, wenn Rechenzentren, die evpn-overlay ausführen (wie hier beschrieben), über ein MPLS/IP-Kernnetzwerk verbunden werden:

Szenario 1: DCI unter Verwendung von GWs
Szenario 2: DCI unter Verwendung von ASBRs

Die folgenden zwei Unterabschnitte beschreiben die Operationen für jedes dieser Szenarien.

10.1. DCI Using GWs (DCI unter Verwendung von Gateways)

Dies ist das typische Szenario für die Verbindung von Rechenzentren über WAN. In diesem Szenario werden EVPN-Routen in jedem GW terminiert und verarbeitet, und MAC/IP-Routen werden immer vom DC zum WAN re-advertised, aber vom WAN zum DC werden sie nicht re-advertised, wenn unbekannte MAC-Adressen (und Standard-IP-Adresse) in den NVEs verwendet werden. In diesem Szenario verwaltet jeder GW eine MAC-VRF (und/oder IP-VRF) für jeden EVI. Der Hauptvorteil dieses Ansatzes besteht darin, dass NVEs keine MAC- und IP-Adressen von entfernten Rechenzentren verwalten müssen, wenn Standard-IP-Routen und unbekannte MAC-Routen verwendet werden; das heißt, sie müssen nur Routen verwalten, die lokal zu ihrem eigenen DC sind. Wenn Standard-IP-Routen und unbekannte MAC-Routen verwendet werden, werden alle unbekannten IP- und MAC-Pakete von NVEs an die GWs weitergeleitet, wo alle VPN-MAC- und IP-Routen verwaltet werden. Dieser Ansatz reduziert die Größe von MAC-VRF und IP-VRF bei NVEs erheblich. Darüber hinaus führt dies zu einer schnelleren Konvergenzzeit bei einem Link- oder NVE-Ausfall in einem Multihomed-Netzwerk- oder Geräteredundanzszenario, da die ausfallbezogenen BGP-Routen (wie Massenabzugsnachricht) nicht bis zu den entfernten NVEs in den entfernten DCs propagiert werden müssen. Dieser Ansatz wird in Abschnitt 3.4 von [DCI-EVPN-OVERLAY] ausführlich beschrieben.

10.2. DCI Using ASBRs (DCI unter Verwendung von ASBRs)

Dieser Ansatz kann als das Gegenteil des ersten Ansatzes betrachtet werden. Er bevorzugt die Vereinfachung bei DCI-Geräten gegenüber NVEs, so dass größere MAC-VRF- (und IP-VRF-) Tabellen auf NVEs verwaltet werden müssen; während DCI-Geräte keine MAC- (und IP-) Weiterleitungstabellen verwalten müssen. Darüber hinaus müssen DCI-Geräte keine Routen im Zusammenhang mit Multihoming terminieren und verarbeiten, sondern diese Nachrichten für die Einrichtung eines End-to-End Label Switched Path (LSP) weiterleiten. Mit anderen Worten, DCI-Geräte in diesem Ansatz arbeiten ähnlich wie ASBRs für Inter-AS Option B (siehe Abschnitt 10 von [RFC4364]). Dies erfordert die Verwendung lokal zugewiesener VNIs, genau wie Downstream-zugewiesene MPLS VPN-Labels, bei denen für alle praktischen Zwecke die VNIs wie 24-Bit-VPN-Labels funktionieren. Dieser Ansatz ist gleichermaßen auf Rechenzentren (oder Carrier Ethernet-Netzwerke) mit MPLS-Kapselung anwendbar.

Bei Inter-AS Option B, wenn ASBR eine EVPN-Route von seinem DC über internal BGP (iBGP) empfängt und sie an andere ASBRs re-advertised, re-advertised es die EVPN-Route, indem es den BGP Next Hop auf sich selbst umschreibt und dabei die Identität des PE verliert, der die Ankündigung ursprünglich gemacht hat. Diese Umschreibung des BGP Next Hop beeinflusst die EVPN-Massenabzugsroute (Ethernet A-D pro ES) und ihr Verfahren negativ. Sie beeinflusst jedoch nicht den EVPN-Aliasing-Mechanismus/-Verfahren, da, wenn die Aliasing-Routen (Ethernet A-D pro EVI) angekündigt werden, der empfangende PE zunächst eine MAC-Adresse für einen bestimmten EVI in sein entsprechendes <ES, EVI> auflöst und anschließend das <ES, EVI> in mehrere Pfade (und ihre zugehörigen Next Hops) auflöst, über die das <ES, EVI> erreichbar ist. Da sowohl Aliasing- als auch MAC-Routen auf EVI-Basis angekündigt werden und dieselben RD und RT (pro EVI) verwenden, kann der empfangende PE sie auf BGP-Pfad-Basis (z.B. pro ursprünglichem PE) zusammen zuordnen. Somit kann er eine rekursive Routenauflösung durchführen, z.B. eine MAC ist über ein <ES, EVI> erreichbar, das wiederum über eine Reihe von BGP-Pfaden erreichbar ist; somit ist die MAC über die Reihe von BGP-Pfaden erreichbar. Aufgrund der EVI-Basis ist die Zuordnung von MAC-Routen und der entsprechenden Aliasing-Route fest und durch dieselben RD und RT bestimmt; es gibt keine Mehrdeutigkeit, wenn der BGP Next Hop für diese Routen umgeschrieben wird, wenn diese Routen durch ASBRs passieren. Das heißt, der empfangende PE kann mehrere Aliasing-Routen für denselben EVI von einem einzelnen Next Hop (einem einzelnen ASBR) erhalten, und er kann trotzdem mehrere Pfade zu diesem <ES, EVI> erstellen.

Wenn jedoch die BGP-Next-Hop-Adresse, die dem ursprünglichen PE entspricht, umgeschrieben wird, kann die Zuordnung zwischen der Massenabzugsroute (Ethernet A-D pro ES) und ihren entsprechenden MAC-Routen nicht auf der Grundlage ihrer RDs und RTs vorgenommen werden, da der RD für die Massenabzugsroute anders ist als der für die MAC-Routen. Daher hängt die bei den ASBRs und den empfangenden PEs benötigte Funktionalität davon ab, ob die Massenabzugsroute ursprünglich erstellt wird und ob es notwendig ist, Routenauflösungsmehrdeutigkeiten für diese Route zu handhaben. Die folgenden zwei Unterabschnitte beschreiben die von den ASBRs und den empfangenden PEs benötigte Funktionalität, je nachdem, ob die NVEs in Hypervisoren oder in ToR-Switches residieren.

10.2.1. ASBR Functionality with Single-Homing NVEs (ASBR-Funktionalität mit Single-Homing-NVEs)

Wenn NVEs in Hypervisoren residieren, wie in Abschnitt 7.1 beschrieben, gibt es kein Multihoming; daher besteht keine Notwendigkeit für den ursprünglichen NVE, Ethernet A-D pro ES- oder Ethernet A-D pro EVI-Routen zu senden. Wie jedoch in Abschnitt 7 erwähnt, um es einem Single-Homing-Ingress-NVE zu ermöglichen, von schneller Konvergenz, Aliasing und Backup Path zu profitieren, wenn er mit Multihoming-Egress-NVEs interagiert, die an einen bestimmten ES angeschlossen sind, sollte der Single-Homing-NVE in der Lage sein, Ethernet A-D pro ES- und Ethernet A-D pro EVI-Routen zu empfangen und zu verarbeiten. Die Handhabung dieser Routen wird im nächsten Abschnitt beschrieben.

10.2.2. ASBR Functionality with Multihoming NVEs (ASBR-Funktionalität mit Multihoming-NVEs)

Wenn NVEs in ToR-Switches residieren und im Multihoming-Redundanzmodus arbeiten, besteht, wie in Abschnitt 8 beschrieben, die Notwendigkeit für den ursprünglichen Multihoming-NVE, Ethernet A-D pro ES-Route(n) (verwendet für Massenabzug) und Ethernet A-D pro EVI-Routen (verwendet für Aliasing) zu senden. Wie oben beschrieben, erzeugt die Umschreibung des BGP Next Hop durch ASBRs Mehrdeutigkeiten, wenn Ethernet A-D pro ES-Routen vom entfernten NVE in einem anderen AS empfangen werden, da der empfangende NVE diese Route nicht mit den MAC/IP-Routen dieses ES zuordnen kann, die vom selben ursprünglichen NVE angekündigt wurden. Diese Mehrdeutigkeit verhindert die Funktion des Massenabzugs pro ES durch den empfangenden NVE in einem anderen AS.

Als Beispiel betrachten Sie ein Szenario, in dem ein CE an PE1 und PE2 multihomed ist, wobei diese PEs über ASBR1 und dann ASBR2 mit dem entfernten PE3 verbunden sind. Betrachten Sie außerdem, dass PE1 M1 von CE1 empfängt, aber nicht PE2. Daher kündigt PE1 Ethernet A-D pro ES1, Ethernet A-D pro EVI1 und M1 an; während PE2 nur Ethernet A-D pro ES1 und Ethernet A-D pro EVI1 ankündigt. ASBR1 empfängt alle diese fünf Ankündigungen und leitet sie an ASBR2 weiter (mit sich selbst als BGP Next Hop). ASBR2 wiederum leitet sie an den entfernten PE3 weiter, mit sich selbst als BGP Next Hop. PE3 empfängt diese fünf Routen, wobei alle denselben BGP Next Hop haben (d.h. ASBR2). Darüber hinaus haben die beiden von PE3 empfangenen Ethernet A-D pro ES-Routen dieselben Informationen, d.h. denselben ESI und denselben BGP Next Hop. Obwohl beide dieser Routen vom BGP-Prozess in PE3 verwaltet werden (weil sie unterschiedliche RDs haben und daher als unterschiedliche BGP-Routen behandelt werden), werden Informationen von nur einer von ihnen in der L2-Routingtabelle (L2 RIB) verwendet.

                  PE1
                 /   \
                CE     ASBR1---ASBR2---PE3
                 \   /
                  PE2

                Abbildung 3: Inter-AS Option B

Wenn nun der AC zwischen PE2 und dem CE ausfällt und PE2 einen Network Layer Reachability Information (NLRI) Rückzug für die Ethernet A-D pro ES-Route sendet und dieser Rückzug propagiert und von PE3 empfangen wird, entfernt der BGP-Prozess in PE3 die entsprechende BGP-Route; er entfernt jedoch nicht die zugehörigen Informationen (nämlich ESI und BGP Next Hop) aus der L2-Routingtabelle (L2 RIB), da er immer noch die andere Ethernet A-D pro ES-Route (ursprünglich von PE1) mit denselben Informationen hat. Deshalb funktioniert der Massenabzugsmechanismus beim DCI mit Inter-AS Option B nicht. Wie jedoch zuvor beschrieben, funktioniert die Aliasing-Funktion und ebenso der "Massenabzug pro EVI" (der mit dem Rückzug der EVPN-Route verbunden ist, die mit Aliasing verbunden ist, d.h. Ethernet A-D pro EVI-Route).

Im obigen Beispiel empfängt PE3 zwei Aliasing-Routen mit demselben BGP Next Hop (ASBR2), aber unterschiedlichen RDs. Eine der Aliasing-Routen hat denselben RD wie die angekündigte MAC-Route (M1). PE3 folgt dem in [RFC7432] spezifizierten Routenauflösungsverfahren beim Empfang der zwei Aliasing-Routen; das heißt, es löst M1 in <ES, EVI1> auf und löst anschließend <ES, EVI1> in eine BGP-Pfadliste mit zwei Pfaden zusammen mit den entsprechenden VNIs/MPLS-Labels auf (einer, der mit PE1 verbunden ist, und der andere, der mit PE2 verbunden ist). Es sollte beachtet werden, dass, obwohl beide Pfade vom selben BGP Next Hop (ASRB2) angekündigt werden, der empfangende PE3 sie ordnungsgemäß handhaben kann. Daher ist M1 über zwei Pfade erreichbar. Dies erstellt zwei End-to-End-LSPs, von PE3 zu PE1 und von PE3 zu PE2, für M1, so dass, wenn PE3 Verkehr für M1 weiterleiten möchte, es zwischen den zwei LSPs Load-Balance durchführen kann. Obwohl die Routenauflösung für Aliasing-Routen mit demselben BGP Next Hop in [RFC7432] nicht ausdrücklich erwähnt wird, ist dies die erwartete Operation; daher wird sie hier erläutert.

Wenn der AC zwischen PE2 und dem CE ausfällt und PE2 NLRI-Rückzug für Ethernet A-D pro EVI-Routen sendet und diese Rückzüge propagiert und von PE3 empfangen werden, entfernt PE3 die Aliasing-Route und aktualisiert die Pfadliste; das heißt, es entfernt den Pfad, der PE2 entspricht. Daher haben alle entsprechenden MAC-Routen für dieses <ES, EVI>, die auf diese Pfadliste zeigen, jetzt die aktualisierte Pfadliste mit einem einzelnen Pfad, der mit PE1 verbunden ist. Diese Aktion kann als Massenabzug auf EVI-Ebene betrachtet werden. Der Massenabzug auf EVI-Ebene hat eine längere Konvergenzzeit als der Massenabzug auf ES-Ebene; er ist jedoch viel schneller als die Konvergenzzeit, wenn der Rückzug auf MAC-Basis durchgeführt wird.

Wenn ein PE von einem bestimmten ES getrennt wird, MUSS er zusätzlich zum Rückzug seiner zuvor angekündigten Ethernet A-D pro ES-Routen auch seine zuvor angekündigten Ethernet A-D pro EVI-Routen für diesen ES zurückziehen. Für einen entfernten PE, der vom zurückziehenden PE durch einen oder mehrere EVPN Inter-AS Option B ASBRs getrennt ist, ist der Rückzug der Ethernet A-D pro ES-Routen nicht umsetzbar. Ein entfernter PE ist jedoch in der Lage, eine zuvor angekündigte Ethernet A-D pro EVI-Route mit allen MAC/IP Advertisement-Routen zu korrelieren, die auch vom zurückziehenden PE für dieses <ES, EVI, BD> angekündigt wurden. Wenn er daher den Rückzug einer Ethernet A-D pro EVI-Route empfängt, SOLLTE er den zurückziehenden PE als Next Hop für alle MAC-Adressen entfernen, die mit diesem <ES, EVI, BD> verbunden sind.

Im vorherigen Beispiel, wenn der AC zwischen PE2 und dem CE ausfällt, wird PE2 seine Ethernet A-D pro ES- und pro EVI-Routen zurückziehen. Wenn PE3 den Rückzug einer Ethernet A-D pro EVI-Route empfängt, entfernt er PE2 als gültigen Next Hop für alle MAC-Adressen, die mit dem entsprechenden <ES, EVI, BD> verbunden sind. Daher haben alle MAC-Next-Hops für dieses <ES, EVI, BD> jetzt einen einzelnen Next Hop, nämlich den LSP zu PE1.

Zusammenfassend kann man sehen, dass die Aliasing- (und Backup Path-) Funktionalität wie sie ist für Inter-AS Option B funktionieren sollte, ohne dass zusätzliche Funktionalität in ASBRs oder PEs erforderlich ist. Die Massenabzugsfunktionalität fällt jedoch vom ES-Modus zum EVI-Modus für Inter-AS Option B zurück. Das heißt, PEs, die eine Massenabzugsroute vom selben AS empfangen, ergreifen Maßnahmen bei der Ethernet A-D pro ES-Route; während PEs, die Massenabzugsrouten von verschiedenen ASes empfangen, Maßnahmen bei der Ethernet A-D pro EVI-Route ergreifen.