Lösungsarchitektur

Underlay-Attribute

Das übliche enthaltene Underlay ist Segment-Routing MPLS mit Labeled ISIS. TI-LFA ist der Schutzmechanismus der Wahl mit Loose-Modus, der den Übergang zum Link-Schutz ermöglicht, falls der Node-Schutz nicht mehr verfügbar ist.

Zu den Merkmalen des SR-MPLS-Designs gehören:

• ISIS (L1 oder L2) für alle Geräte aktiviert.
• BFD über L-ISIS-Verbindungen.
• Die zusätzliche ISIS-Optimierung umfasst die folgenden Attribute, sollte aber für die Netzwerkbereitstellung entsprechend eingestellt werden, um die Stabilität zu gewährleisten:
  • Das PDU-Intervall für den ISIS-Verbindungsstatus wurde auf 10 ms (standardmäßig 100 ms) verbessert.
  • Die maximale Hello-Größe von ISIS wurde basierend auf der ISO-MTU-Konfiguration der Schnittstelle auf 9106 erhöht, was bei der Identifizierung von MTU-Problemen helfen kann.
  • Die SPF-Optionen sind innerhalb eines bestimmten Bereichs abgestimmt, um Netzwerkinstabilität zu vermeiden.
• Konsistenter SRGB-Label-Bereich zwischen 16000 und 24000. In früheren Junos OS-Implementierungen wurde SRGB unter der IGP-Hierarchie konfiguriert. Dies wird weiterhin unterstützt. SRGB ist jetzt bequem unter der MPLS-Konfigurationshierarchie konfiguriert und konsistent mit anderen Labelbereichskonfigurationen.
• TI-LFA bietet sowohl Link- als auch Node-Schutz mit einem konfigurierten Maximum-Label von 3 für Backup-Pfade.
• Microloop Avoidance ist für alle Geräte aktiviert.

ISIS ist die IGP, die für die Lösungsarchitektur verwendet wird. Das JVD enthält drei IGP-Metrikkombinationen, die anwendungsspezifische Link-Attribute-(ASLA)-Link-Affinitätseinschränkungen für berechnete Pfade verwenden:

1. IGP-Metriken für ungefärbte Pfade (BGP-LU), referenziert als Best Effort.
2. TE-Metriken für Transportklasse Bronze (BGP-CT).
3. Statische Verzögerungsmetriken für Transport Class Gold (BGP-CT).

Flexibler Algorithmus

Der flexible Algorithmus wurde von RFC9350 ratifiziert und ermöglicht controllerlose Leichtbau-Traffic-Engineering-Lösungen bei gleichzeitiger Unterstützung fortschrittlicher Schutzmechanismen wie TI-LFA. TLV-Ankündigungen beschreiben die Schlüsselattribute Berechnungstyp, Metriktyp, Priorität und Satz von Verbindungseinschränkungen, die für IGP-berechnete beste Pfade verwendet werden. Die Koaleszenz dieser Werte definiert die Flexible Algorithm Definition (FAD).

Segment-Routing-Präfix-SIDs werden dann mit der Flex-Algo-Kennung verknüpft und stellen so den berechneten Pfad über die beteiligten Knoten hinweg dar. Durch die Nutzung verschiedener Beschränkungen und Metriktypen können mehrere Abstraktionsebenen erstellt werden, indem farbige Pfade durch das Netzwerk gebildet werden.

Im JVD nehmen alle Knoten an Flex-Algo teil und müssen daher die Sub-TLV-Knotenfunktion des SR-Algorithmus bekannt geben. Die FAD-Sub-TLV-Ansagen werden nicht von jedem Router benötigt. Um Konflikte zu vermeiden, werden FAD-Ankündigungen im JVD auf die Grenzknoten (ABR/ASBR) beschränkt. Beide ABRs sollten so konfiguriert werden, dass sie die FADs ankündigen. Beide Unter-TLVs haben einen Ebenenbereich und werden daher nicht über IGP-Grenzen hinweg angekündigt, ohne dass ein zusätzlicher Mechanismus für die gemeinsame Nutzung von regionsübergreifenden Attributen vorhanden ist, wie weiter unten erläutert wird.

Nach mehreren Überarbeitungen der Entwürfe wurde der Flex-Algo RFC im Jahr 2023 fertiggestellt. Im Vorfeld entstand jedoch eine Landschaft sich verändernder Standards, insbesondere in Bezug auf Link-Affinitätsattribute, bei denen sich drei Permutationen herauskristallisierten: Legacy (RFC5305 Abschnitt 3.1), Common ASLA (RFC8919 Abschnitt 6.3.1) und schließlich Flex-Algo ASLA (RFC9350).

In Metro EBS JVD enthält die Flex-Algo-Implementierung die neuesten Link-Attributdefinitionen, die in RFC9350 für die Verwendung von anwendungsspezifischen Link-Attributen spezifiziert sind. Zu den Linkattributen, wie sie in RFC8919 für ISIS (oder RFC8920 für OSPF) definiert sind, gehören TE-metric, admin-group und link-delay. Junos OS/Junos OS Evolved unterstützt L-Flag und ermöglicht so die Abwärtskompatibilität mit Legacy-Attributen. Das Standardverhalten ermöglicht einen Fallback von Flex-Algo ASLA auf Common ASLA und schließlich auf Legacy-TE-Attribute. Im JVD werden Legacy-Ankündigungen mit einem Strict-SLA-basierten-Flex-Algorithmus-Knopf deaktiviert, was jedoch keine Voraussetzung für die Lösung ist.

Eine letzte Überlegung ist die IGP-Skalierung, da jeder Flex-Algo seinen eigenen Pfad berechnet. Im JVD definieren wir drei Pfade mit zwei Algos, Gold (128) unter Verwendung von Verzögerungsmetriken, Bronze (129) mit TE-Metriken und Best Effort (inet.3) mit IGP-Metriken.

Transportklassen

Transportklassen definieren eine Reihe allgemeiner Einschränkungsattribute, die zum Erstellen von Transporttunneln verwendet werden. Transportklassen können verschiedenen Underlay-Protokollen zugeordnet werden, z. B. RSVP oder SR-TE. Im JVD verwenden die Transportklassen ISIS Flex-Algo, um mehrere Ebenen der Netzwerkabstraktion über dieselbe physische Infrastruktur zu erstellen. Die Dienste werden dann dem Farbtransport zugeordnet, was eine vereinfachte Methode für die intelligente Verkehrssteuerung ermöglicht.

Mit den neuesten Implementierungen von Classful Transport können Services, die Transportklassentunneln zugeordnet sind, so konfiguriert werden, dass sie je nach Bedarf zwischen Tunnelhierarchien wechseln oder ein Fallback durchführen. Das Auflösungsschemaattribut steuert die zu berücksichtigenden Auflösungstabellen für den nächsten Hop.

Das JVD enthält zwei Arten von Fallback-Methoden für Abwicklungsschemata:

1. Kein Fallback: Mit dieser Methode wird sichergestellt, dass der Datenverkehr der richtigen Farbe zugeordnet wird. Ist dies nicht der Fall, wird Datenverkehr verworfen.
2. Kaskade: Dies ist die bevorzugte validierte Lösung, da sie Fallback für Gold-Pfade zu Bronze und Bronze-Pfade zu Inet.3 (bestes Bemühen) ermöglicht.

BGP-Routing-Richtlinie

BGP-Routing-Richtlinien kennzeichnen alle Routen basierend auf dem ursprünglichen Netzwerksegment, um eine gezielte Umverteilung zu ermöglichen, Schleifen zu vermeiden und die Fehlerbehebung zu vereinfachen. Um Schleifen zu vermeiden, exportieren die Grenzknoten jeder Region nur Routen, die mit der lokalen Regions-Community übereinstimmen, und lehnen Routen ab, die mit den Peer-Region-Communitys übereinstimmen. Für eine verbesserte Fehlererkennung wird BFD in allen BGP-Sitzungen mit einem 300-ms-Erkennungstimer konfiguriert. BFD-Timer sollten auf der Grundlage der Netzwerkleistung, Stabilität und Gerätefunktionen abgestimmt werden.

BGP Best Practices werden, wo relevant, angewendet und umfassen Folgendes:

• BGP path-selection external-router-id ändert den Pfadauswahlalgorithmus so, dass immer die router-ID für die Bestimmung des aktiven Pfads zwischen EBGP-Pfaden verwendet wird, was zu einem konsistenteren BGP-Verhalten beiträgt.
• Die BGP-Haltezeit (standardmäßig 90 Sekunden) wird auf 10 Sekunden reduziert.
• Wenn die BGP-Haltezeit weniger als 20 Sekunden beträgt, sollten Präzisionstimer konfiguriert werden, da dies zu einer erhöhten Arbeitsauslastung der Routing-Engine-CPU führt. Präzisions-Timer ermöglichen einen dedizierten Kernel-Thread für BGP-Berechnungen, um sicherzustellen, dass Keepalives auch bei Scheduler-Slips erhalten bleiben. Dies trägt dazu bei, BGP-Sitzungsstörungen aufgrund des Ablaufs der Haltezeit zu verhindern.
• Mit bgp-error-tolerance werden zusätzliche Standardfehlerbehandlungsmechanismen aktiviert, einschließlich der Begrenzung fehlerhafter versteckter Routen, die im Arbeitsspeicher gespeichert sind, auf 1000 und der Unterdrückung der Protokollierung von fehlerhaften BGP-Aktualisierungsmeldungen für 300 Sekunden.
• Die maximale BGP-Segmentgröße tcp-mss wurde von 500 Byte auf maximal 4096 Byte erhöht, um die Konvergenz zu beschleunigen.

Zur Verbesserung der Konvergenz ist der PE-Verbindungsschutz für EBGP-LU- und BGP-CT-Pfade zusätzlich zu den Profix-Labels aktiviert. Dies kann ein Problem bei der Skalierung sein, aber bei reinen Transportsegmenten ist die Routenskalierung in der Regel überschaubar. Nur labeled-unicast wird mit per-prefix-label konfiguriert, da die BGP-CT-Transportfamilie dieses Verhalten standardmäßig aktiviert.

BGP-Routenreflektoren

Fabric- und Multi-Ring-Regionen sollten redundante BGP-Routenreflektoren für Zugriffsknotenclients verwenden. Um die Intra-Fabric- und Inter-Ring-Kommunikation zwischen Zugriffsknoten in derselben Region zu optimieren, wird die Multiprotokoll-BGP für VPN-Familien die Self-Option für den nächsten Hop nicht enthalten. Eindeutige Cluster-IDs werden verwendet, um die Konvergenz zu maximieren. Im Allgemeinen sind Loopback-Adressen für Zugriffssegmente für die lokale Erreichbarkeit innerhalb der Fabric nur für ISIS erreichbar und werden nicht an BGP weitergegeben. Nur Remote-Loopbacks sollten von BGP gelernt werden.

BGP-Routenreflektoren ermöglichen die Multiprotokollfamilien:

• Labeled-Unicast (BGP-LU)
• Transport (BGP-CT)
• inet-vpn (L3VPN)
• inet6-vpn (6vPE)
• L2VPN-Signalübertragung (L2VPN, VPLS)
• EVPN-Signalisierung (EVPN)
• Route-Target (RTF)

An allen Stellen, an denen Route Target Constraint (RTC) konfiguriert ist, ist die zusätzliche Konfigurationsoption für die Next-Hop-Auflösung ohne Auflösung enthalten, um die Next-Hop-Auflösung für die RIB-Installation zu umgehen. Diese Konfiguration ist nützlich für Routen, die nicht für die Weiterleitung verwendet werden, z. B. nicht weiterleitende RRs. Die JVD-Routenreflektoren befinden sich im Weiterleitungspfad, RTF ist jedoch ausschließlich ein Element der Steuerungsebene. Um die Topologie weiter zu optimieren, kann die Option advertise-default verwendet werden, um nur ein Standardroutenziel an PE-Clients zu senden. Der logische Nutzen wäre die Unterstützung der vorgestellten Zugriffssegmente.

Metro Fabric- und Metro Multi-Ring-Segmente setzen unterschiedliche Routenreflektorstrategien ein. In der Fabric fungieren die Metro-Edge-Gateways (MEG) als Access Node (AN)-Reflektoren für Transport- und Servicerouten (BGP-LU, BGP-CT und MP-BGP). Im Multi-Ring-Segment peeren die Metro Access Nodes (MA) als Routenreflektor-Clients mit den Metro Distribution Routern (MDR), die nur Transportreflektoren sind (BGP-LU, BGP-CT). Alle Services (MP-BGP) nutzen die Multiservices-Edge () Routenreflektoren.

Metro-Ring-Architektur

In den folgenden Abschnitten werden die vorgeschlagenen Metro-Ring-Architekturen beschrieben. Der Entwurf umfasst eine Multi-Ring-Topologie mit Multi-Instanz-ISIS und erbt die zuvor beschriebenen gemeinsamen Elemente.

Wichtige Merkmale des Metro Rings

• Multi-Instanz-ISIS (blaue und grüne Ringe).
• Flex-Algo-Präfix-Metriken (FAPM), die über mehrere ISIS-Instanzen hinweg durchsickern, um die Weiterleitung zwischen den Ringen zu optimieren.
• Domäneninterne Transportklassendienstzuordnung.
• EVPN Floating PW mit Anycast-SID (Migration von Legacy-L2CKT).
• EVPN-ETREE, EVPN-FXC, EVPN-VPWS, EVPN-ELAN
• L2Circuit, L2VPN und BGP-VPLS.
• Lokales Switching (LSW), EVPN-VPWS und L2Circuit
• L3VPN-Internetdienste

Abbildung 2: Metro-Ring-Architekt

Zu den primären gemeinsamen BGP-Communities, die aus Metro-Ringregionen stammen, gehören:

• CM-LOOPBACK (63536:10000)
• CM-SERVICE-EDGE (63536:10)
• CM-METRO-RING (63536:20)
• CM-BEREICH-KANTE (63536:30)
• CM-TC-4000-GOLD (Transport-Ziel:0:4000)
• CM-TC-6000-BRONZE (Transport-Ziel:0:6000)
• CM-INET-DEFAULT (target:63536:11111)
• CM-L3VPN-PUB (Ziel:63536:22222)

ISIS mit mehreren Instanzen

Sowohl blaue als auch grüne Ringe sind funktional identisch mit ISIS-Instanzen der Stufe 2. Die meisten Geräte arbeiten mit einer einzelnen ISIS-Instanz, die unter der normalen globalen Hierarchie konfiguriert ist. Geräte, die an mehrere IGP-Regionen angefügt sind, werden mit mehreren ISIS-Instanzen konfiguriert. Dazu gehören MDR1, MDR2 und MA3. Links zwischen MDR1 und MDR2 teilen sich eine gemeinsame LAG, die logisch nach VLANs zwischen globalen, Metro-A- und Metro-B-ISIS-Instanzen aufgeteilt ist. Die Schnittstellen zwischen MDR1 und MDR2 zu MA3 sind ebenfalls logisch durch VLANs über eine gemeinsame physikalische Schnittstelle getrennt. Alle anderen Links sind domänenspezifisch und existieren nur in einer einzigen IGP-Instanz.

Es ist nicht erforderlich, gemeinsame Schnittstellen in dieser Architektur gemeinsam zu nutzen. Das JVD zeigt, wie diese anspruchsvollen Konnektivitätsszenarien erreicht werden können, indem definitive Haltungen für Routenlecks an den Grenzdemarkationspunkten geschaffen werden.

Abbildung 3: ISIS-Architektur mit mehreren Instanzen

Alle Routenverluste zwischen Instanzen zwischen den Ringen erfolgen an den MDR1- und MDR2-Knoten. Die Logik, nur bei MDRs und nicht bei MA3 zu lecken, kann darauf zurückgeführt werden, dass eine Netzerweiterung mit zusätzlichen Ringen antizipiert wird, was dazu führt, dass MA3 zu einer weniger bevorzugten Leckagestelle wird. Die MDR stellt den idealen Abgrenzungspunkt mit Sichtbarkeit aller Ringe für die Regionen dar. Routen, die zwischen ISIS-Instanzen durchgesickert sind, werden markiert, um Schleifen zu vermeiden. Die MDRs fungieren als BGP-Transportwegreflektoren (BGP-LU und BGP-CT) für alle Ringzugriffsknoten (kein Multiprotokoll-BGP). Bei VPN-Diensten erfolgt der Peering von Zugriffsknoten mittels MP-BGP mit-Routenreflektoren.

Das Durchsickern zwischen der globalen ISIS-Gebiets-ID 005 in die ISIS-Instanzen metro-a (001) und metro-b (002) ist auf BGP beschränkt. An dieser Stelle wird nahtloses SR-MPLS mit BGP-LU und BGP-CT genutzt. Die Lösung könnte stattdessen zwischen den IGP-Domänen undicht werden, die Teil des gemeinsamen autonomen Systems sind, aber hier bietet die Lösung die Möglichkeit, die IGP in kleinere Domänen zu unterteilen und den Explosionsradius zu reduzieren.

Für alle ISIS-Instanzen wird dieselbe System-ID verwendet, und eindeutige AREA-IDs sind wie folgt enthalten:

• 0005 – Globale Instanz
• 0001–Metro-A-Instanz
• 0002–Metro-B-Instanz

Das IP-Schema schlägt aggregierte Tags vor, um eine einfachere Routenumverteilung und Schleifenvermeidung wie folgt zu ermöglichen:

• 10.10.0.0/24–TAG2 5: GLOBAL
• 10.10.1.0/24–TAG2 1: METRO-A
• 10.10.2.0/24–TAG2 2: METRO-B

Indichtes Inter-Ring-Flex-Algo-Präfix

Flex-Algo-Inter-Domain-Verfahren werden in RFC9350 Abschnitt 13.1 erläutert. Flex-Algo Prefix Metric (FAPM) ist eine Sub-TLV-Ankündigung, die eine Präfixzuordnung trägt. Flex-Algo-Metriken mit anwendungsspezifischen Linkattributen (ASLA) werden auf allen Knoten definiert, wobei Flex-Algo-Definitionen (FADs) nur von MDR-Grenzknoten angekündigt werden. Application Specific Link Attributes ist die neueste und standardisierte Version für Flex-Algo Metric Advertisement. Das Flex-Algo Prefix Metric (FAPM)-Leck wird zwischen Ringen über MDRs durchgeführt, um Datenströme zwischen den Ringen zu ermöglichen und innerhalb der Region zu optimieren.

MSE1 und MSE2 fungieren als redundante Routenreflektoren für alle Ringknoten und unterstützen zusätzlich Inter-AS-Funktionalitäten, die mit BGP-LU und BGP-CT erweitert wurden. Um sicherzustellen, dass der Datenverkehrsfluss innerhalb und zwischen den Ringen optimiert wird, werden VPN-Dienste (MP-BGP) das Next-Hop-Self an der nicht nutzen. Für LU/CT-Transportrouten ist Next-Hop Self obligatorisch, um die Erreichbarkeit zwischen AS zu erleichtern.

SR-MPLS ist das Underlay der Wahl unter Verwendung von Flex-Algo mit ASLA-Metriken und Transportklassen, die grüne und blaue Pfade durch das Netzwerk definieren. Grüne Pfade verwenden ISIS-Verzögerungsmetriken und blaue Pfade TE-Metriken. Die IGP-Metriken werden für farbunabhängige Pfade verwendet, die erweitert werden können, um farbige oder nicht farbige Pfade zu berücksichtigen. Alle Routen, die zwischen Domänen durchgesickert sind, erhalten ein gemeinsames ISIS-Tag, und alle exportierten Routen, die dieses Tag bereits enthalten, werden zurückgewiesen, um Schleifen zu vermeiden.

Intra-AS-BGP-Classful-Transport und Unicast mit Label

Es gibt mehrere praktikable Strategien für die Kommunikation zwischen IGP-Domänen innerhalb desselben autonomen Systems. Im JVD stellen wir einige Variationen bereit, in denen FAPM verwendet wird, um Präfixe zwischen ISIS-Instanzen durchsickern zu lassen, wobei jede Instanz eine Metro-Ring-Entität bezeichnet. Von den kollektiven ISIS-Domänen mit mehreren Instanzen bis hin zur globalen ISIS-Domäne (die zwischen MDR- und-Segmenten existiert) haben wir uns entschieden, jegliches IGP-Leaking zu verbieten und nur BGP-LU und BGP-CT als Inter-Domain-Stitching-Mechanismen zu verwenden. Dadurch wird sichergestellt, dass der IGP-Explosionsradius innerhalb der spezifischen Bereiche begrenzt ist.

Metro-Fabric-Architektur

IP-Fabrics werden von Hyperscalern gut verstanden und eingesetzt, um das Versprechen einer hohen Bandbreite, Ausfallsicherheit und praktisch unbegrenzten Skalierbarkeit zu liefern. Metro Fabrics sind ein häufiger Diskussionspunkt, aber im Allgemeinen fehlen klare Definitionen. Die Platzierung der Infrastruktur wird zu einem wichtigen Aspekt. Während IP-Fabrics in der Regel innerhalb einer Datencenter-Umgebung aufgebaut werden, wodurch die damit verbundenen Glasfasertransportkosten praktisch entfallen, überbrücken die Metro-Netzwerke in der Regel größere Entfernungen zwischen physischen Kollokationen, was zu teureren Glasfasern führen kann. Daher kann die Implementierung einer Metro-Fabric von Dienstanbieter zu Dienstanbieter variieren und wird durch die damit verbundenen Transportkosten bestimmt.

Das vom Metro EBS JVD vorgeschlagene Modell betrachtet eine Infrastruktur, die flexibel genug ist, um kosteneffiziente Scale-out-Lösungen zu unterstützen, die sich in einem einzigen physischen Standort befinden und/oder Spine-and-Leaf-Metro-Zugangsknotenstandorte unterstützen. Im Allgemeinen stellen wir eine zweistufige Fabric bereit, bei der MPLS als Underlay-Transport der Wahl verwendet wird.

In der Topologie bezieht sich die Metro-Fabric auf die orangefarbene Region. Der Metro-Kern ist der graue Bereich.

Abbildung 4: Metro-Fabric-Architektur

Wichtige Metro Fabric-Funktionen

• Schlanke Aggregation von Edge-Services
• Metro-Edge-Gateway mit Multiaccess-Edge-Compute-Interkonnektivität
• Optimierte Weiterleitungspfade über 2-stufige MPLS-Fabric
• EVPN-FXC (bewusst + unbewusst), EVPN-VPWS, EVPN-ELAN
• L2Circuit, L2VPN, BGP-VPLS
• Dedizierter Internetzugang (DIA): L3VPN, EVPN Typ-5, EVPN, IRB, VGA
• Allaktive ESI-LAG-Lastverteilung auf drei PEs
• Aktiv-Aktiv- und Hot-Standby-Services
• Logische Schnittstellen-Policer

Zur Optimierung der VPN-Flows innerhalb der Metro Fabric wird ein Paar Routenreflektoren (gehostet von Border Leaf Nodes MEG1/MEG2) verwendet. Während sie im Weiterleitungspfad arbeiten, müssen wir vermeiden, Next-Hop für die Multiprotokoll-BGP-Fabric-Services auf self zu setzen, damit der Intra-Fabric-Datenverkehr im Spine verbleiben kann. Lean-Spine-Knoten (AG1.1, AG1.2) sind BGP-frei und verfügen nur über eine SR-MPLS-Konfiguration. Die IGP-Domäne umfasst ISIS-Level 1 im Metro-Fabric-Zugriffsnetzwerk und Level 2 im Metro-Core. Die gesamte Metro-Fabric-Infrastruktur implementiert dieselbe Bereichs-ID:

• 0000–Globale Instanz

Datenverkehr, der zwischen L1 und L2 ISIS leckt, kann mit IGP-Maschinen und Flex Algo-Präfix-Lecks unter Verwendung von Flex-Algo Prefix Metric (FAPM) oder IGP-Lecks untergebracht werden, die ausdrücklich eingeschränkt sind und sich nur auf BGP als Inter-Domain-Protokoll der Wahl verlassen.

Die Flexible Algorithm Definitions (FADs) werden nur von den Grenzknoten an MEG1- und MEG2-Positionen beworben. Ähnlich wie beim Metro-Ring-Design werden nur zwei Transportklassen erstellt: Gold und Bronze. Auflösungsschemata ermöglichen es Gold-Services, Failover auf Bronze-Pfade zu kaskadieren, wenn ein Gold-Pfad nicht verfügbar ist, und Bronze ist für das Failover auf ungefärbte Pfade nach bestem Wissen aktiviert (inet.3). Wenn kein benutzerdefiniertes Auflösungsschema konfiguriert ist, besteht das Standardverhalten darin, allen Transportklassen ein Failover auf nicht farbige Pfade zu ermöglichen, die von der inet.3-Tabelle aufgelöst werden.

Ähnlich wie beim Metro-Ring-Design verwenden wir Community-basiertes BGP-Routing, um zu steuern, wie Routen über die verschiedenen Domänen hinweg importiert und exportiert werden. Zu den primären gemeinsamen BGP-Communities aus Metro-Fabric-Regionen gehören:

• CM-LOOPBACK (63535:10000)
• CM-METRO-FABRIC (63535:1)
• CM-ACCESS-FABRIC (63535:2)
• CM-REGIONALGRENZE (63535:3)
• CM-TC-4000-GOLD (Transport-Ziel:0:4000)
• CM-TC-6000-BRONZE (Transport-Ziel:0:6000)
• CM-INET-DEFAULT (target:63536:11111)
• CM-L3VPN-PUB (Ziel:63536:22222)

Das IP-Schema für die Core-Schnittstelle wird mit einem Aggregat-Tag delegiert:

• 10.10.0.0/24 – TAG2 10: GLOBAL

Overlay-Attribute

In den folgenden Abschnitten werden die Implementierung und Anwendungsfälle von Services beschrieben, die im Metro Ethernet Business Services JVD enthalten sind. Dazu gehören die Endpunkte und wie sich diese Dienste auf MEF-Definitionen beziehen. Es ist jedoch wichtig zu beachten, dass die MEF-Ausrichtung keine Voraussetzung für die Nutzung eines der beschriebenen Dienste ist. Es sind mehrere Permutationen enthalten, um verschiedene Kundenanwendungsfälle abzudecken, aber viele weitere Optionen sind möglich und werden unterstützt.

Metro EBS-Servicebereitstellungsmodelle

Über zwanzig Anwendungsszenarien werden für die Bereitstellung von Metro Ethernet-Services abgedeckt. Herkömmliche Layer-2-VPN-Services sind ebenso enthalten wie L2Circuit mit Hot-Standby, L2VPN und VPLS. Dies zeigt die Fähigkeit zur Koexistenz mit neueren EVPN-VPWS-, EVPN-FXC-, EVPN-ELAN- und EVPN-ETREE-Services über gängige moderne Metro-Ring- und Fabric-Infrastrukturen. Darüber hinaus bietet die Floating-PW-Lösung ein massives Upgrade gegenüber dem statischen älteren L2Circuit, indem sie Anycast-SID mit all-active virtual ESI (vESI) für Aktiv-Aktiv-Multihoming nutzt. Layer-3-Services werden mit herkömmlichen L3VPN-, EVPN-ELAN-Typ-5- und EVPN IRB Virtual Gateway Address (VGA)-Modellen unterstützt. Hochverfügbarkeitsservices wie Aktiv-Aktiv-EVPN und Hot-Standby-L2KKT sind enthalten.

Serviceverbindungsmodelle werden für bestimmte Segmente rund um Lean Edge für die Metro-Edge-Compute-Übergabe in Betracht gezogen, bei denen mehrere Optionen wie EVPN-VXLAN oder SRv6 für IP-Fabric-Interworking vorhanden sind. Für diese erste Phase haben wir jedoch eine Q-in-Q-Übergabe gewählt, die es ermöglicht, Dienste basierend auf innerer und/oder äußerer Tagübereinstimmung mit den komplexen Edge-Ressourcen zu verbinden. Den Betreibern steht es frei, VLAN-Manipulationen durchzuführen, um dieses Ziel zu erreichen. Ähnliche Überlegungen werden für Multiservices-Edge-Konnektivität angestellt, um Internetservices zu erleichtern, oder SP-Core für Layer-2-Konnektivität in zusätzliche Netzwerksegmente. Frühere 5G Metro JVDs deckten über 80 Kombinationen von VLAN-Manipulationsoperationen ab, die hier immer noch anwendbar sind.

Abbildung 5: Metro EBS-Servicebereitstellungsmodelle

Service Provider migrieren zunehmend zu EVPN als einer leistungsfähigeren Lösung unter einem einzigen Technologiedach im Vergleich zu herkömmlichen VPN-Diensten, einschließlich der verschiedenen Varianten von L2Circuit, VPLS und L2VPN. Betreiber benötigen jedoch weiterhin Legacy-Services als eigenständige und koexistierende Lösungen. Das validierte Design von Metro EBS berücksichtigt eine Reihe moderner und traditioneller Carrier Ethernet-Services, erstellt eine vergleichende Leistungsanalyse und bietet einige Methoden, die Legacy-Protokolle erheblich modernisieren, indem sie die Vorteile neuerer Lösungsentwicklungen nutzen.

Abbildung 6: Service-Endpunkte