Detaillierter Designleitfaden und Konfigurationsbeispiele für eine SR-TE Explicit-Path-Richtlinie mit EVPN VPWS, IOS XR Version 7.5.x
Inhalt
Einleitung
Dieses Dokument beschreibt den detaillierten Designleitfaden mit technischen Beschreibungen, die auf den Anforderungen von XYZ Networks basieren, sowie eine Konfigurationsvorlage und -konfiguration auf niedriger Ebene für die Anwendungsfälle von Segment Routing Traffic Engineering (SR-TE) Explicit Path Policy with Ethernet VPN (EVPN) Virtual Private Wired Service (VPWS).
1. Hintergrundinformationen
1.1. Nicht im Umfang enthalten
In diesem Dokument wird nicht auf die Anforderungen zentralisierter "On-Demand"-SR-TE-Richtlinien eingegangen, die den XTC-Controller, EVPN ELAN usw. verwenden. Der Schwerpunkt liegt jedoch nur auf den Head-End-Node-basierten SR-TE-Richtlinien mit EVPN VPWS-Overlay.
1.2. Annahme
Der Leser dieses Dokuments muss mit den Konzepten von IP/MPLS und Ethernet sowie den Technologien für Segment Routing und Traffic Engineering vertraut sein.
1.3. Technischer Anwendungsbereich
Der technische Anwendungsbereich dieses Dokuments beschränkt sich auf:
- OSPF mit TI-LFA FRR
- Headend-gesteuerte (verteilte) SR-TE-Richtlinien
- Expliziter primärer Pfad und dynamische IGP-basierte Failover-Pfade
- Single-Homed EVPN VPWS
Die in diesem Dokument angegebenen Konfigurationsvorlagen werden als Cisco IOS®-XR 7.5.x bezeichnet.
1.4. Dokumentübersicht
Tabelle 1. Dokumentabschnitte
| Thementyp |
Themenname |
Abschnittsnummer |
| Einleitung |
Hintergrundinformationen |
1 |
| Anforderung |
Benutzeranforderungen |
2 |
| Technologieüberblick |
Segment-Routing |
3 |
| SR-TE - Überblick |
4 |
|
| TI-LFA FRR |
5 |
|
| EVPN-Overlay |
6 |
|
| BOB und Lastenausgleich |
7 |
|
| Konfigurationsvorlagen |
Die komplette Designlösung |
8 |
| Beispielkonfiguration und Befehle anzeigen |
9 |
Anforderung
2. Benutzeranforderungen
2.1. Anforderungsübersicht
Der Service Provider XYZ Networks hat die Anforderung, über Cisco NCS 5500 ein "Green Field"-Netzwerk aufzubauen.
Der Zweck besteht darin, einen Multicast-Datenstrom (Sprache, Video) als Service über ein Layer-2-Transportnetzwerk mit bestimmten Anforderungen zu übertragen. Eine dieser Anforderungen besteht darin, die Datenverkehrspfade durch das Netzwerk zu optimieren.
Sie bevorzugen SR für Transportlabels, SR-TE für Traffic Engineering und EVPN als Overlay zur Bereitstellung von Service-Labels.
2.2. Verwendete Komponenten
Der Benutzer XYZ hat eine Konvergenz auf den NCS 5500-Routern und Linecards erreicht:
Tabelle 2. Hardware-Anforderungen des Projekts
| PE-Knoten |
PID |
| Gehäuse |
NCS-5504 |
| MPA/LCs verbinden P-Knoten |
NC55-36X100G-A-SE |
| MPA/LCs verbinden CE-Knoten |
NC55-36X100G-A-SE |
| P-Knoten |
PID |
| Gehäuse |
NCS-5508 |
| MPA/LCs, die andere P-Knoten verbinden |
NC55-36X100G-A-SE |
| MPA/LCs verbinden PE-Knoten |
NC55-36X100G-A-SE |
In diesem Abschnitt finden Sie eine Übersicht über die zu verwendenden Technologien sowie kurze Beschreibungen.
Technologieüberblick
3. Segment-Routing
3.1. Was ist Segment Routing?
Segment-Routing ist die neueste fortschrittliche MPLS-Technologie, die dabei ist, die traditionellen LDP- und RSVP-TE-Protokolle durch die Einführung von Label Distribution und Traffic Engineering unter einem Dach zu ersetzen und dies nur über Link-State-IGP-/BGP-Protokolle zu ermöglichen.
Segment-Routing ist eine Methode zur Weiterleitung von Paketen im Netzwerk auf Basis des Source-Routing-Paradigmas. Die Quelle wählt einen Pfad aus und kodiert ihn im Paket-Header als eine geordnete Liste von Segmenten. Segmente sind Bezeichner für jede Art von Anweisung. Topologiesegmente identifizieren beispielsweise den nächsten Hop in Richtung eines Ziels. Jedes Segment wird durch die Segment-ID (SID) identifiziert, die aus einer flachen vorzeichenlosen 20-Bit-Ganzzahl besteht.
3.2. Segment-IDs
Abbildung 1. SR-Knoten-SIDs und Adjacency-SIDs
Segmente: Das Interior Gateway Protocol (IGP) verteilt zwei Segmenttypen: Präfix-Segmente und Adjacency-Segmente. Jedem Router (Knoten) und jeder Verbindung (Adjacency) ist eine Segment Identifier (SID) zugeordnet.
Präfix-SID: Ein Präfix-Segment ist ein globales Segment. Daher ist eine Präfix-SID innerhalb der Segment-Routing-Domäne global eindeutig, wie in Abbildung 1 dargestellt. Eine Präfix-SID ist einem IP-Präfix zugeordnet. Die Präfix-SID wird manuell aus dem Segment Routing Global Block (SRGB)-Labelbereich konfiguriert und durch IS-IS oder OSPF verteilt. Das Präfixsegment leitet den Datenverkehr auf dem kürzesten Pfad zum Ziel.
- Verwendet den globalen SR-Block (SRGB)
- SRGB mit Routerfunktionen TLV angekündigt - In der Konfiguration kann Prefix-SID als Absolutwert oder Index konfiguriert werden.
- In der Protokollankündigung wird Präfix-SID immer als global eindeutiger Index codiert. Der Index stellt einen Offset von der SRGB-Basis dar, eine nullbasierte Nummerierung, d. h., 0 ist der 1. Index. Beispiel: Index 1 nach SID ist 16.000 + 1 = 16.001
Knoten-SID: Eine Knoten-SID ist ein spezieller Typ einer Präfix-SID, die einen bestimmten Knoten identifiziert. Er wird unter der Loopback-Schnittstelle konfiguriert, wobei die Loopback-Adresse des Knotens das Präfix ist. Ein Präfixsegment ist ein globales Segment, sodass eine Präfix-SID innerhalb der Segment-Routing-Domäne global eindeutig ist.
Mit anderen Worten: Das Knotensegment ist ein Präfixsegment, das mit einem Hostpräfix verknüpft ist, das einen Knoten identifiziert.
- Entspricht einem Präfix für die Router-ID, d. h. einem Präfix, das einen Knoten identifiziert
- Die Knoten-SID ist die Präfix-SID, und in der Benachrichtigung ist die N-Markierung festgelegt.
- Standardmäßig ist jede konfigurierte Prefix-SID eine Knoten-SID.
- 'normal' (d. h. keine Node-SID) Die Präfix-SID kann für IS-IS konfiguriert werden.
Adjacency-SID: Ein Adjacency-Segment wird durch ein Label identifiziert, das als Adjacency-SID bezeichnet wird und eine bestimmte Adjacency für einen benachbarten Router darstellt, z. B. eine Ausgangsschnittstelle. Die Adjacency-SID wird über IS-IS oder OSPF verteilt. Das Adjacency-Segment leitet den Datenverkehr zu einer bestimmten Adjacency. Ein Adjacency-Segment ist ein lokales Segment, sodass die Adjacency-SID relativ zu einem bestimmten Router lokal eindeutig ist.
- Lokal bedeutsam
- Automatische Zuweisung für jede Adjacency
- Immer als absoluter (d. h. nicht indizierter) Wert codiert
Bindende SID oder BSID: Es handelt sich um eine lokal relevante SID, die mit der SR-Richtlinie verknüpft ist. Er unterstützt die Weiterleitung von Paketen an die zugehörige SR-Richtlinie. Das Bindungssegment ist ein lokales Segment, das eine SR-TE-Richtlinie identifiziert. Jede SR-TE-Richtlinie ist einer Binding Segment ID (BSID) zugeordnet.
Die BSID ist ein lokales Label, das bei Instanziierung der SR-TE-Richtlinie automatisch jeder SR-TE-Richtlinie zugewiesen wird. Die BSID kann verwendet werden, um den Datenverkehr in die SR-TE-Richtlinie und über Domänengrenzen hinweg zu lenken, wodurch nahtlose Ende-zu-Ende-SR-TE-Richtlinien zwischen den Domänen erstellt werden.
4. SR-TE - Überblick
4.1. Was ist SR-TE?
Segment Routing Traffic Engineering (SR-TE) transformiert den einfachen, Stateless Source Routing-Mechanismus von SR auf eine erweiterte Ebene, um den Datenverkehr über vordefinierte Pfade zu programmieren und zu steuern, die Überlastungen vermeiden und alternative Pfade wie eine Express-Wege-Live-Datenverkehrskarte bereitstellen.
Dies wird erreicht, wenn Sie vom Administrator Richtlinien konfigurieren, die über eine Kombination verschiedener Einschränkungen definiert werden, die die primären sowie die Backup-Pfade von den Quell- zu den Zielknoten programmieren. Der Controller kann je nach Netzwerkanforderung zentralisiert (SDN) oder verteilt (Headend) sein.
Betrachten wir nun die in Abbildung 2 dargestellte Topologie. Angenommen, die Kosten für die Verbindungen sind Standardwerte, und der kürzeste Weg, um von A nach D zu gelangen, ist A-B-C-D, aber der Pfad mit niedriger Latenz ist A-E-F-G-H-D. Der Operator kann den vom Traffic-Engineering bestimmten Pfad entsprechend der Anforderung (z. B. Latenz) definieren und ihn in Form einer Segment-ID-Liste (A, E, F, G, H, D) angeben. Im Gegensatz zu RSVP-TE wird der Status dieser Richtlinie nur auf Router A beibehalten, nicht auf den gesamten Routern, auf denen die Pakete übertragen werden (d. h. E, F, G und H).
Abbildung 2. Beispiel eines administrativ definierten SR-TE-Pfads
4.2. SR-TE-Richtlinie
Segment-Routing für Traffic Engineering (SR-TE) verwendet eine Richtlinie, um den Datenverkehr durch das Netzwerk zu steuern. Ein SR-TE-Richtlinienpfad wird als eine Liste von Segmenten ausgedrückt, die den Pfad angibt. Dieser wird als SID-Liste (Segment ID) bezeichnet. Jedes Segment ist ein End-to-End-Pfad von der Quelle zum Ziel und weist die Router im Netzwerk an, dem angegebenen Pfad zu folgen, anstatt dem kürzesten, vom IGP berechneten Pfad zu folgen. Wenn ein Paket in eine SR-TE-Richtlinie gesteuert wird, wird die SID-Liste vom Headend auf das Paket geschoben. Der Rest des Netzwerks führt die in die SID-Liste eingebetteten Anweisungen aus.
Eine SR-TE-Richtlinie wird als geordnete Liste identifiziert (Headend, Farbe, Endpunkt):
- Headend - bei dem die SR-TE-Richtlinie instanziiert wird
- Farbe - Ein numerischer Wert, der zwischen zwei oder mehr Richtlinien für die gleichen Knotenpaare unterscheidet (Headend - Endpunkt)
- Endpunkt - Das Ziel der SR-TE-Richtlinie
- Jede SR-TE-Richtlinie hat einen Farbwert. Jede Richtlinie zwischen denselben Knotenpaaren erfordert einen eindeutigen Farbwert.
Eine SR-TE-Richtlinie wird mit einem oder mehreren potenziellen Pfaden konfiguriert, die primäre und Backup-Pfade enthalten.
Beispielsweise kann der primäre Pfad der Richtlinie explizit mit Adjacency-SIDs definiert werden, und bei Ausfallszenarien kann der Backup-Pfad dynamisch sein, um den sich die IGP-Metrik kümmert.
5. TI-LFA FRR
5.1. Überblick
TI-LFA (Topology Independent Loop-Free Alternate) ist eine Funktion, die Verbindungen, Knoten und SRLGs schützt. Die Konfiguration ist denkbar einfach: Für die Implementierung einer einfachen TI-LFA-Konfiguration auf dem Router sind lediglich zwei Konfigurationszeilen erforderlich. Es sind keine Änderungen an den Protokollen erforderlich, die im Router verwendet werden. Abbildung 3 zeigt den primären Datenverkehrspfad und den vorab berechneten Backup-Pfad nach TI-LFA für Szenarien mit lokalen Verbindungsausfällen und Knotenausfällen.
Abbildung 3: TI LFA-Link-Failover-Szenario
Abbildung 4: Szenario mit TI-LFA-Knoten-Failover
Jeder geschützte Knoten und Pfad verfügt über einen vorab berechneten Backup-Pfad, der schnell aktiviert werden kann. Die Konvergenzzeit für einen geschützten Pfad beträgt maximal 50 Millisekunden. Das bedeutet, dass selbst die Anwendungen mit der höchsten Latenz oder bei Paketverlusten ohne Unterbrechungen funktionieren, falls ein Knoten oder eine Verbindung ausfällt. TI-LFA berechnet den Backup-Pfad und entfernt vorübergehend den geschützten Link oder Knoten aus der Datenbank. Danach wird der Backup-Pfad mit dem kürzesten Pfad zuerst berechnet. Dadurch wird sichergestellt, dass der Backup-Pfad die geringstmöglichen metrischen Kosten verursacht, während der geschützte Pfad vermieden wird. Ein vom Verkehrstechniker entwickelter Tunnel, der dem Backup-Pfad folgt, wird für den Datenverkehr verwendet, wenn ein Fehler auftritt. Eine Reparatur-Labelliste bestimmt den Pfad für die Pakete, die eine neue Route zu ihrem Ziel benötigen. Eine Reparatur-Labelliste ist ein normaler Label-Stack, wird jedoch nur verwendet, wenn in der geschützten Route ein Fehler auftritt.
5.2. Auswirkungen der Ausfallerkennungsmethode auf FRR
Fast Reroute für vom SR-TE-Datenverkehr entwickelte Pfade wird als Mittel zum Umschalten des Datenverkehrs bei Failover-Szenarien vom primären Pfad auf Backup-Pfade konfiguriert, und zwar innerhalb von möglichst 50 ms. Die Funktion für schnelles Umleiten wird unter IGP-Protokoll (OSPF/ISIS) konfiguriert. Die Konvergenzzeit hängt von der Methode ab, mit der Verbindungsausfälle erkannt werden. Im Falle eines Faserschnitts ist die Erkennung sofort und die Möglichkeit, eine Konvergenz von unter 50 ms zu erhalten, ist hoch. Sollte die Erkennung eines Verbindungsausfalls jedoch durch BFD mit einem Intervall von 15 ms erfolgen (Multiplikator x3). Die Konvergenzzeit beträgt meist mehr als 50 ms.
5.3. Mikroschleifenvermeidung mit SR
Microloops sind kurze Paketschleifen, die im Netzwerk nach einer Topologieänderung auftreten (Link Down, Link Up oder Metrikänderungen). Mikroschleifen werden durch die nicht gleichzeitige Konvergenz verschiedener Knoten im Netzwerk verursacht. Wenn Knoten zusammenlaufen und Datenverkehr an einen benachbarten Knoten senden, der noch nicht zusammengeführt wurde, kann der Datenverkehr zwischen diesen beiden Knoten in Schleifen verlaufen, was zu Paketverlusten, Jitter und nicht ordnungsgemäßen Paketen führt.
Die Funktion zur Vermeidung von Segment-Routing-Mikroschleifen erkennt, ob möglicherweise eine Topologieänderung auf Mikroschleifen folgt. Wenn ein Knoten berechnet, dass in der neuen Topologie eine Mikroschleife auftreten kann, erstellt er mithilfe einer Liste von Segmenten einen schleifenfreien SR-TE-Richtlinienpfad zum Ziel. Nach Ablauf des Verzögerungszeitgebers für die RIB-Aktualisierung wird die SR-TE-Richtlinie durch reguläre Weiterleitungspfade ersetzt. Es gibt einen Standard-Timer für die RIB-Aktualisierungsverzögerung, der vom TI-LFA übernommen wird.
6. EVPN-Overlay
EVPN ist eine Technologie, die ursprünglich für Ethernet-Multipoint-Dienste mit erweiterten Multi-Homing-Funktionen entwickelt wurde und bei der mithilfe von BGP Informationen über die Erreichbarkeit von MAC-Adressen über das MPLS-Netzwerk verteilt werden, während L2VPNs dieselben Betriebs- und Skalierungsmerkmale wie IP-VPNs aufweisen. Heute bietet die EVPN-Lösungsfamilie über DCI- und E-LAN-Anwendungen hinaus eine gemeinsame Grundlage für alle Ethernet-Servicetypen, darunter E-LINE, E-TREE sowie Routing- und Bridging-Szenarien für Rechenzentren. EVPN bietet auch Optionen zur Kombination von L2- und L3-Services in derselben Instanz.
EVPN ist eine Lösung der nächsten Generation, die Ethernet-Multipoint-Services über MPLS-Netzwerke bereitstellt. EVPN arbeitet anders als der Virtual Private LAN Service (VPLS), der ein BGP Control Plane-basiertes MAC-Learning im Core ermöglicht. Bei EVPN lernen PEs, die an den EVPN-Instanzen teilnehmen, mithilfe des MP-BGP-Protokolls die MAC-Routen der Benutzer auf der Kontrollebene.
EVPN bietet die folgenden Vorteile:
- Redundanz pro Datenfluss und Lastenausgleich
- Vereinfachte Bereitstellung und Bedienung
- Optimale Weiterleitung
- Schnelle Konvergenz
- Skalierbarkeit von MAC-Adressen
- Lösungen mehrerer Anbieter nach IETF-Standardisierung
Die auf einem Gerät bezogenen MAC-Adressen müssen erfasst oder auf die anderen Geräte in einem VLAN verteilt werden. Die MAC Learning-Funktion der EVPN-Software ermöglicht die Verteilung der von einem Gerät erfassten MAC-Adressen an die anderen Geräte, die mit einem Netzwerk verbunden sind. Die MAC-Adressen werden mithilfe von BGP von den Remote-Geräten abgefragt.
In diesen Abschnitten erfahren Sie mehr über die Vorteile und Routing-Typen von EVPN im Allgemeinen. Anschließend lernen Sie die lösungsspezifischen Komponenten kennen, die für das Design von XYZ Network Services verwendet werden.
6.1. Vorteile von EVPN
L2VPN und L3VPN stellen nicht nur Dienste unter einem Lösungsüberblick mithilfe verschiedener Routentypen bereit, sondern lösen mit EVPNs auch zwei seit langem bestehende Einschränkungen für Ethernet-Services in Service Provider-Netzwerken:
- Multihomed und All-Active Ethernet Access
- Service Provider-Netzwerk - Integration mit der Zentrale oder dem Rechenzentrum
6.1.1. Multihomed und All-Active Ethernet Access
Die Abbildung zeigt die größten Einschränkungen traditioneller L2-Multipoint-Lösungen wie VPLS.
Abbildung 5: EVPN für alle aktiven Zugriffe
Wenn VPLS im Core ausgeführt wird, müssen PE1/PE2 und PE3/PE4 aufgrund der Vermeidung von Loops nur Single-Active-Redundanz zu den jeweiligen CEs bieten. Traditionell wurden mLACP- oder Legacy-L2-Protokolle wie MST, REP, G.8032 usw. verwendet, um eine Single-Active-Zugriffsredundanz bereitzustellen.
Die gleiche Situation tritt bei Hierarchical-VPLS (H-VPLS) auf, bei dem der Zugriffsknoten für den Single-Active-H-VPLS-Zugriff über eine aktive und eine Backup-Spoke-Pseudowire (PW)-Verbindung verantwortlich ist.
All-Active-Access-Redundanzmodelle können nicht bereitgestellt werden, da die VPLS-Technologie nicht in der Lage ist, L2-Schleifen zu verhindern, die sich aus den im Core verwendeten Weiterleitungsmechanismen für bestimmte Datenverkehrskategorien ergeben. Der vom CE generierte Broadcast-, Unknown-Unicast- und Multicast (BUM)-Datenverkehr wird durch den VPLS-Core geleitet und von allen PEs empfangen, die ihn wiederum an alle angeschlossenen CEs weiterleiten. In unserem Beispiel kann PE1 den BUM-Datenverkehr von CE1 an den Core weiterleiten, und PE2 kann ihn an CE1 zurücksenden, wenn er empfangen wird.
EVPN behebt dieses Problem mithilfe BGP-basierter Kontrollebenen-Techniken und ermöglicht Aktiv-Aktiv-Zugriffs-Redundanzmodelle für Ethernet- oder H-EVPN-Zugriff.
6.2. EVPN-Routentypen
EVPN definiert einen neuen BGP NLRI, der für die Übertragung aller EVPN-Routen verwendet wird. EVPN NLRI wird im BGP unter Verwendung von Multiprotokoll-Erweiterungen mit einem AFI von 25 (L2VPN) und einem SAFI von 70 übertragen. Mit der BGP-Funktionsankündigung wird sichergestellt, dass zwei Lautsprecher EVPN NLRI unterstützen.
Abbildung 6: EVPN-NLRI
Die für diese Implementierung erforderlichen relevanten EVPN-Routing-Typen werden hier beschrieben:
6.2.1. Routentyp 1 - Ethernet-Auto-Discovery-Route (AD)
Die Ethernet Auto-Discovery (AD)-Routen werden pro EVI und pro ESI angekündigt. Diese Routen werden per ES gesendet. Sie tragen die Liste der EVIs, die der ES angehören. Das ESI-Feld wird auf Null gesetzt, wenn ein CE Single-Homed ist. Dieser Routing-Typ wird für eine Massenentnahme von MAC-Adressen, für das Aliasing für den Lastenausgleich und für die Split Horizon-Filterung verwendet.
6.2.2. Routentyp 4 - Ethernet-Segment-Route
Ethernet-Segment-Routen ermöglichen die Verbindung eines CE-Geräts mit zwei oder PE-Geräten. Die ES-Route ermöglicht die Erkennung verbundener PE-Geräte, die mit demselben Ethernet-Segment verbunden sind, d. h. die Erkennung von Redundanzgruppen. Es wird auch für die DF-Auswahl (Designated Forwarder) verwendet.
6.3. EVPN-Hostverbindung
Diese EVPN-Modi werden unterstützt:
- Single-Homing: Hiermit können Sie ein Benutzer-Edge-Gerät (CE) mit einem PE-Gerät (Provider Edge) verbinden. In diesem ESI-Wert ist für jede PE-CE-Verbindung Null.
- Multihoming: Sie können ein Benutzer-Edge-Gerät (CE) mit zwei oder mehr Provider Edge-Geräten (PE) verbinden, um redundante Verbindungen bereitzustellen. Ein Interchasis-Link ist nicht erforderlich. Das redundante PE-Gerät stellt sicher, dass bei einem Netzwerkausfall keine Unterbrechung des Datenverkehrs auftritt. Es gibt folgende Arten von Multihoming:
Abbildung 7: EVPN Single Homing
Multihoming - Dies sind die Arten von Multihoming:
1. Single-Active - In einem Single-Active-Modus kann nur ein einzelner PE einer Gruppe von PEs, die mit dem jeweiligen Ethernet-Segment verbunden sind, Datenverkehr zu und von diesem Ethernet-Segment weiterleiten.
Abbildung 8: EVPN Single-Active
2. Aktiv-Aktiv - Im Aktiv-Aktiv-Modus können alle mit dem jeweiligen Ethernet-Segment verbundenen PEs Datenverkehr zu und von diesem Ethernet-Segment weiterleiten.
Abbildung 9: EVPN Dual aktiv
7. BOB und Lastenausgleich
7.1. BFD over Bundle (BoB)
Bidirectional Forwarding Detection (BFD) ermöglicht die Erkennung von Ausfällen im Pfad zwischen benachbarten Forwarding-Engines mit geringem Overhead und kurzer Dauer. Mit BFD kann ein einziger Mechanismus zur Fehlererkennung auf allen Medien und auf allen Protokollschichten verwendet werden, mit einer großen Bandbreite an Erkennungszeiten und Overhead. Die schnelle Fehlererkennung ermöglicht eine sofortige Reaktion auf einen Fehler, wenn eine Verbindung oder ein Nachbar ausfällt.
Dies würde das IGP dazu anregen, den Datenverkehr an den Backup-Pfad weiterzuleiten, der bereits mithilfe von FRR (im Fall von IGP) und PIC (im Fall von BGP) berechnet wurde.
Bei der BFD Over Bundle (BoB)-Funktion wird die IPv4-BFD-Sitzung über jedes aktive Bundle-Mitglied ausgeführt.
Abbildung 10: Logisches BOB-Diagramm
Bundlemgr berücksichtigt neben den vorhandenen L1-/L2-Zuständen auch BFD-Zustände, um die Benutzbarkeit der Mitgliedsverbindung zu bestimmen. Der Mitgliedsstaat des Bündels ist eine Funktion von:
Status L1 (physische Verbindung)
L2-Status (LACP)
L3-Status (BFD)
BFD Agent wird weiterhin auf der Linecard ausgeführt. Die BFD-Status der Mitgliedslinks des Pakets werden auf dem RP konsolidiert. Die Mitglieds-Links müssen Back-to-Back-Verbindungen aufweisen, ohne dass L2-Switches dazwischen geschaltet werden. Die BOB-Funktion wird in allen Paket-Ethernet-Schnittstellen im XYZ-Netzwerk konfiguriert.
7.2. Lastenausgleich
Der Flow ECMP-Lastenausgleich im betroffenen Netzwerk erstreckt sich über Inter-Bundle Ethernet-Schnittstellen und Intra-Bundle Ethernet (zwischen physischen Elementen einer Bundle Interface). Dies gilt für das gesamte Netzwerk, vom PE bis zum PE (Core-Lastenausgleich) sowie vom PE bis zum CE (AC-Lastenausgleich), wie bereits erörtert.
7.2.1. Core Load Balancing mit FAT-Label
Entsprechend dem Umfang des Netzwerks XYZ müssen Sie nur den Lastenausgleich für jeden Flow ECMP (Equal-Cost Multipath) wie erwähnt berücksichtigen:
Router nutzen für den Lastenausgleich in der Regel das unterste Label im Label-Stack, das für alle Datenflüsse in einem bestimmten Pseudowire identisch ist. Dies kann zu einem asymmetrischen Lastenausgleich führen. Der Datenfluss bezieht sich in diesem Zusammenhang auf eine Folge von Paketen, die das gleiche Quell- und Zielpaar aufweisen. Die Pakete werden von einem Quell-Provider-Edge (PE) zu einem Ziel-Provider-Edge-PE übertragen.
Flow-Aware Transport Pseudowire (FAT PW) bietet die Möglichkeit, einzelne Datenflüsse innerhalb eines Pseudodrahts zu identifizieren und Routern die Möglichkeit zu geben, diese Datenflüsse zum Lastenausgleich des Datenverkehrs zu verwenden. FAT-PWs werden zum Lastenausgleich des Datenverkehrs im Core verwendet, wenn ECMP (Equal-Cost Multipath) verwendet wird. Ein Flow-Label wird auf der Grundlage unteilbarer Paketflüsse erstellt, die in eine Pseudowire-Emulation eintreten, und wird als unterstes Label in das Paket eingefügt. Router können das Flow-Label für den Lastenausgleich verwenden, um eine bessere Verteilung des Datenverkehrs über ECMP-Pfade oder über Link-gebündelte Pfade im Core zu ermöglichen.
Dem Stack wird ein zusätzliches Label hinzugefügt, das so genannte Flow-Label, das für jeden eindeutigen eingehenden Fluss auf dem PE generiert wird. Ein Flow-Label ist eine eindeutige Kennung, die einen Flow innerhalb des PW unterscheidet und von Quell- und Ziel-MAC-Adressen sowie Quell- und Ziel-IP-Adressen abgeleitet wird. Das Flow-Label enthält den End-of-Label-Stack (EOS)-Bitsatz. Das Flow-Label wird nach dem VC-Label und vor dem Kontrollwort (falls vorhanden) eingefügt. Der Eingangs-PE berechnet das Flow-Label und leitet es weiter. Die FAT-PW-Konfiguration aktiviert die Flow-Kennung. Der Egress-PE verwirft das Flow-Label, sodass keine Entscheidungen getroffen werden.
7.2.2. Lastenausgleich für Befestigungsschaltungen
Für den Lastenausgleich von Mitgliedern des AC-Pakets ist jedoch ein anderer Ansatz erforderlich, da in diesem Netzwerkabschnitt kein SR-MPLS vorhanden ist.
Der Lastenausgleich pro Fluss kann hier erreicht werden, wenn spezifische l2vpn-Konfigurationsknoten für alle PE-Router explizit angepasst werden. Sie kann pro SRC/DST-MAC- oder SRC/DST-IP gemäß den Anforderungen konfiguriert werden.
Konfigurationsvorlagen und Befehlsbeispiele
8. Die komplette Designlösung
In diesem Abschnitt werden die vollständigen Konstruktionsdetails beschrieben, die durch alle verschiedenen Einzelkomponenten genäht wurden und in den vorherigen Abschnitten erläutert wurden. In diesem Abschnitt werden die Topologie und die entsprechende Konfigurationsvorlage unter Bezugnahme auf Cisco IOS-XR 7.5.x dargestellt.
8.1. Low-Level-Anforderungen
Im normalen Datenverkehrsszenario ist der Datenverkehrsfluss so ausgelegt, dass er immer zwischen den Serviceabschlüssen von PE1 und PE3 und nur zwischen PE2 und PE4 propagiert. Das Hauptziel in dieser Situation besteht darin, den Datenverkehrspfad vollständig unzusammenhängend zu halten, wie in Abbildung 12 dargestellt.
Der betroffene Datenverkehr würde eingekapselte Multicast-Datenflüsse durch das EVPN-Overlay sein. Von CE1- und CE2-Knoten werden die Multicast-Medien-Streams (Sprache/Video) empfangen, in denen sie an den PE1- und PE2-Knoten gekapselt und über das EVPN-L2-Overlay zu CE3- bzw. CE4-Knoten transportiert werden können, nachdem sie an PE3- bzw. PE4-Knoten entkapselt wurden.
Daher wird das Quell-Ziel-Datenverkehrspaar in allen Fällen als PE1-PE3 und PE2-PE4 betrachtet, sofern nicht anders angegeben. Einzelheiten zu den Anforderungen finden Sie im Unterabschnitt 2.2.
8.2. Zusammenfassung des Entwurfs
Um die Anforderungen zu erfüllen, wird OSPF als Underlay-IGP nach Wunsch von XYZ Networks ausgewählt. Um den gekapselten Multicast-Stream über das Quell-Ziel-Datenverkehrspaar durch den gewünschten Pfad zu leiten, muss SR-TE zwischen den PE-Knoten implementiert werden.
Die SR-TE-Richtlinien wurden mit explizitem Pfad und dynamischen IGP-Pfaden entwickelt.
Die expliziten Pfade umfassen Folgendes:
- Normale Datenverkehrsszenarien
- Failover-Szenario bis alternative Pfadoptionen verfügbar sind
Die dynamischen IGP-Pfade umfassen:
- Backup-Pfad für Failover-Szenario, in dem alternative Pfadoptionen NICHT verfügbar sind
Funktionen wie BFD, TI-LFA und Microloop Avoidance werden unter OSPF konfiguriert, wie in den Unterabschnitten zu Konfigurationsvorlagen dargestellt.
Für normale Datenverkehrsszenarien werden die Konfigurationsvorlage und andere Details im Unterabschnitt 8.5.1 erwähnt.
Für Datenverkehrs-Failover-Szenarien werden die Konfigurationsvorlage und andere Details im Unterabschnitt 8.5.2 beschrieben.
Darüber hinaus werden auch die Anforderungen wie die Vermeidung von Mikroschleifen und Konvergenzzeiten von unter 50 ms bei Ausfallszenarien berücksichtigt.
8.3. Bausteine
In diesem Unterabschnitt werden alle Konstruktionsblöcke erfasst, die in diesen Abschnitten anschliessend ausführlich behandelt werden.
Allgemeiner Designüberblick (Layer 1):
- Die MTU-Größe im XYZ-Netzwerk ist auf "9216" festgelegt, mit dem Ziel, bis zu 5 bis 6 SR-Label-Stacks zu unterstützen
- 'BFD over Bundle' wird mit einem Intervall von 15 ms implementiert, um eine Unterbrechung der Glasfaserverbindung unter 50 ms zu erkennen.
OSPF/SR-TE-Design - Übersicht:
- OSPF als IGP-Protokoll, wobei TI-LFA so konfiguriert ist, dass FRR unter 50 ms Konvergenzzeit bereitgestellt wird
- Transport Layer basiert auf Segment Routing als Weiterleitungsebene und OSPF als Routing-Protokoll
- Im Netzwerk XYZ steuert der explizite Pfad Segment Routing Traffic Engineering den Datenverkehr in alle erforderlichen primären Pfadrichtungen. Bei Verbindungs-/Knoten-Failover-Szenarien wird der Datenverkehr über einen dynamischen igp-Pfad geleitet.
- Mikroschleifenvermeidung und OSPF Max-Metric sind ebenfalls Teil dieses Designs.
BGP/RR-Designübersicht:
- In einem Cluster sind zwei RRs konfiguriert, um Redundanz zu gewährleisten.
- Der XYZ-Netzwerk- und BGP-Prozess in jedem PE bildet 'IPv4' und 'L2VPN EVPN' Peering mit beiden RRs getrennt
Überblick über das Service-Design:
- Service-Layer basieren auf der BGP-basierten Kontrollebene und dem Layer-2-Point-to-Point-EVPN (EVPN-VPWS)
- Der Multicast-Videodatenverkehr (UDP) wird gekapselt über die Point-to-Point-EVPN-VPWS-PWs gesendet
- ECMP-Lastenausgleich wird durch Konfiguration des FAT-Labels im EVPN-Abschnitt erreicht.
- Der Service unterstützt bis zu 5 bis 6 SR-Label-Stacks, die SR-Transportlabel, EVPN-Label und FAT-Label für den Lastenausgleich enthalten.
8.4. Beispiel für physische Topologie
Die physische Topologie von XYZ Networks ist in dieser Abbildung dargestellt. Der Einfachheit halber sind nur 4 PE- und 4 P-Knoten dargestellt. Es gibt zwei RR-Knoten, die in Clustern agieren, um Redundanz zu gewährleisten.
Abbildung 11: Physische Topologie
8.5. Layer-1-Designdetails
Im generischen Layer-1-Design ist ein Ethernet-Paket mit mindestens zwei Mitgliedsverbindungen pro Paket konfiguriert. Um Verbindungsausfälle schnell zu erkennen, wählen Sie BFD anstelle der Paketfunktion aus. Das Zeitintervall kann dabei idealerweise zwischen 5-15 msec variiert werden. Das hängt von der Hardwarekapazität ab, die entlastet werden kann.
Weitere Informationen zu BFD finden Sie unter https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/routing/73x/b-routing-cg-ncs5500-73x/implementing-bfd.html. Beachten Sie, dass diese Funktion nur unter der Paket-Ethernet-Schnittstelle konfiguriert werden muss. Eine Konfiguration unter IGP ist nicht erforderlich. Die MTU-Größe ist auf 9216 festgelegt, um bis zu 5 bis 6 SR-Label-Stacks zu unterstützen.
8.5.1. Konfigurationsvorlagen
Die BFD-over-Bundle-Konfigurationsvorlagen für alle Knoten sind wie folgt:
interface Bundle-Ether <Intf-Number>
bfd address-family ipv4 timers start 60
bfd address-family ipv4 timers nbr-unconfig 60
bfd address-family ipv4 multiplier 3
bfd address-family ipv4 destination <Connected-Intf-IP>
bfd address-family ipv4 fast-detect
bfd address-family ipv4 minimum-interval <Time in msec>
mtu <Value as per requirement>
ipv4 address <Intf IP> <Subnet Mask>>
bundle minimum-active links 1
!
8.6. OSPF/SR-TE-Designübersicht
Alle OSPFv2-Router im Netzwerk befinden sich in Bereich 0, sodass das Netzwerk eine einzige IGP-Domäne handhabt.
Unter Router-OSPF ist Segment-Routing aktiviert, und es werden relevante Paket-Ethernet-Schnittstellen konfiguriert. Ebenso sind unter "Bundle Interfaces" (Paketschnittstellen) der Netzwerktyp und Parameter für die schnelle Umleitung aktiviert. Am wichtigsten ist, dass eine Loopback-Schnittstelle im passiven Modus mit konfigurierter Präfix-SID aktiviert wird.
OSPF ist ein Link-State-Protokoll. Daher muss es eine Priorität sein, die Downlinks sofort zu identifizieren und einen Backup-Pfad zu erstellen. Um dies zu gewährleisten, wird BFD over Bundle unter Bundle Interface (Paketschnittstelle) und TI-LFA FRR unter OSPF konfiguriert, wodurch die Konvergenzzeit bei Szenarien mit Glasfaserausfall bei 50 ms gehalten wird.
In den folgenden Unterabschnitten werden Normal- und Failover-Szenarien für die Datenverkehrspfade im Detail beschrieben:
8.6.1. SR-TE: Normales Datenverkehrsszenario
Um einen sehr strikten primären Pfad aufrechtzuerhalten, müssen SR-TE-Richtlinien mit expliziten End-to-End-Pfaden zwischen den zuvor erwähnten Quell-Ziel-Datenverkehrspaaren konzipiert werden. Darüber hinaus sind innerhalb einer SR-TE-Richtlinie mehrere Pfade mit potenziellen Präferenzkandidaten erforderlich, um die Bereitstellung für mehrere Failover-Szenarien zu ermöglichen.
In dieser Abbildung sind die Details des Anwendernetzwerks in Übereinstimmung mit den im Unterabschnitt 8.3 genannten Designblöcken dargestellt.
- Verbindungen zwischen PE-P- und P-P-Knoten
- Loopback-Adressen aller Knoten
- Schnittstellenadressen aller Knoten
- SR-TE: Richtung des normalen Datenverkehrs
- EVPN-Overlay zwischen PE-Knoten
Die RRs wurden nicht absichtlich gezeigt, um Unordnung in der Topologie zu reduzieren.
Die Verbindungen zwischen PE und P sind blau und die Verbindungen zwischen P und P grün markiert. Die OSPF-Kosten für PE-P-Verbindungen betragen 100 und die Kosten für P-P-Verbindungen 10.
Der primäre SR-TE-Datenverkehrsfluss wurde zwischen den PE1-PE3-Paaren mit blauen Pfeilen und zwischen den PE2-PE4-Paaren mit violetten Pfeilen markiert.
Abbildung 12: Topologiedetails
8.6.1.1. Konfigurationsvorlagen
Dieser Unterabschnitt enthält die relevanten Konfigurationsvorlagen für OSPF/SR-TE für die angegebenen PE1- und PE2-Knoten:
# PE1 Node: OSPF & SR-TE configs
router ospf CORE
nsr
distribute link-state Command to distribute OSPF database into SR-TE database
log adjacency changes
router-id <Router-ID-PE1> OSPF Router-ID
segment-routing mpls
nsf cisco
microloop avoidance segment-routing Command to enable microloop avoidance with TI-LFA
area 0
interface Bundle-Ether<Intf-Number> OSPF PE to P Link
cost 100 OSPF PE to P Metric
authentication keychain <Key-Chain> Command to enable OSPF Authentication per link
network point-to-point
fast-reroute per-prefix Commands to enable TI-LFA
fast-reroute per-prefix ti-lfa enable
fast-reroute per-prefix tiebreaker node-protecting index <Index-Value>
prefix-suppression
!
interface Loopback <Loopback-ID-PE1>
passive enable
prefix-sid index <SID-Index-Number1> OSPF Loopback Prefix SID
Der Befehl für die Quelladresse in der gezeigten Segment-Routing-Konfiguration ist in bestimmten Szenarien erforderlich, in denen im selben PE als Quelle der SR-TE-Richtlinie eine Loopback-Adresse aus mehreren Loopbacks ausgewählt werden muss, oder wenn ISIS und OSPF mit separaten Loopbacks ausgeführt werden, und einer dieser Loopbacks muss gesperrt werden. Andernfalls ist die Konfiguration der Quelladresse in normalen Szenarien optional, wenn nur ein IGP mit einem eindeutigen Loopback ausgeführt wird.
segment-routing
global-block 16000 23999 Default SRGB Value (Need not be configured). Needs to be configured only if non-default value is assigned
local-block 15000 15999 Default SRLB Value (Need not be configured). Needs to be configured only if non-default value is assigned
traffic-eng
candidate-paths
all
source-address ipv4Configure SR-TE source address as OSPF loopback (Global Option)
!
!
segment-list name <SIDLIST1> Primary/Normal Path SID-LIST1
index <Index ID> mpls adjacency <Remote-IP-Address-Link1>
index <Index ID> mpls adjacency <Remote-IP-Address-Link2>
index <Index ID> mpls adjacency <Remote-IP-Address-Link3>
!
segment-list name <SIDLIST2> Primary Back Up Path SID-LIST2
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
segment-list name <SIDLIST3> Secondary Back Up Path SID-LIST3
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
policy <Pol-Name1>
source-address ipv4 Configure SR-TE source address as OSPF loopback (Policy Specific Option)
color <Color-ID> end-point ipv4 <Destn-PE3>
candidate-paths
preference 50 Tertiary Back Up Path with least preference
dynamic
metric
type igp
!
!
!
preference 100 Secondary Back Up Path with 3rd highest preference
explicit segment-list <SIDLIST3>
!
!
preference 150 Primary Back Up Path with 2nd highest preference
explicit segment-list <SIDLIST2>
!
!
preference 200 Primary/Normal Path with highest preference (Active Path for PE1 in this scenario)
explicit segment-list <SIDLIST1>
!
!
!
!
!
!
# PE2 Node: OSPF & SR-TE configs
router ospf CORE
nsr
distribute link-state Command to distribute OSPF database into SR-TE database
log adjacency changes
router-id <Router-ID-PE2> OSPF Router-ID
segment-routing mpls
nsf cisco
microloop avoidance segment-routing Command to enable microloop avoidance with TI-LFA
area 0
interface Bundle-Ether<Intf-Number> OSPF PE to P Link
cost 100 OSPF PE to P Metric
authentication keychain <Key-Chain> Command to enable OSPF Authentication per link
network point-to-point
fast-reroute per-prefix Commands to enable TI-LFA
fast-reroute per-prefix ti-lfa enable
fast-reroute per-prefix tiebreaker node-protecting index <Index-Value>
prefix-suppression
!
interface Loopback <Loopback-ID-PE2>
passive enable
prefix-sid index <SID-Index-Number2> OSPF Loopback Prefix SID
segment-routing
traffic-eng
!
!
segment-list name <SIDLIST1> Primary/Normal Path SID-LIST1
index <Index ID> mpls adjacency <Remote-IP-Address-Link1>
index <Index ID> mpls adjacency <Remote-IP-Address-Link2>
index <Index ID> mpls adjacency <Remote-IP-Address-Link3>
!
segment-list name <SIDLIST2> Primary Back Up Path SID-LIST2
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
segment-list name <SIDLIST3> Secondary Back Up Path SID-LIST3
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
policy <Pol-Name1>
source-address ipv4 Configure SR-TE source address as OSPF loopback (Policy Specific Option)
color <Color-ID> end-point ipv4 <Destn-PE4>
candidate-paths
preference 50 Tertiary Back Up Path with least preference
dynamic
metric
type igp
!
!
!
preference 100 Secondary Back Up Path with 3rd highest preference
explicit segment-list <SIDLIST3>
!
!
preference 150 Primary Back Up Path with 2nd highest preference
explicit segment-list <SIDLIST2>
!
!
preference 200 Primary/Normal Path with highest preference (Active Path for PE2 in this scenario)
explicit segment-list <SIDLIST1>
!
!
!
!
!
!
Fällt eine Remote-Verbindung außer der lokalen Verbindung eines PE-Knotens aus, bleibt der Pfad gültig. Diese ist wie vorgesehen und kann erst ab XR 7.5.x geändert werden.
# PE Node: SR-TE configs
router ospf <Process-Name>
address-family ipv4 unicast
area 0
interface <Core BE Intf1>
adjacency-sid absolute <Adj-SID1>
interface <Core BE Intf2>
adjacency-sid absolute < Adj-SID2>
interface <Core BE Intf3>
adjacency-sid absolute < Adj-SID3>
segment-routing
traffic-eng
policy <Pol-Name1>
color <Color-ID> end-point ipv4 <Destn-PE>
candidate-paths
preference 10
explicit segment-list <SIDLIST1>
!
preference 20
dynamic
metric
type igp
!
segment-list name <SIDLIST1>
index 10 mpls label <Adj-SID-Link1>
index 20 mpls label <Adj-SID-Link2>
index 30 mpls label <Adj-SID-Link3>
8.6.2. SR-TE für Failover-Szenarien
Um die Failover-Szenarien für den Datenverkehr zu verstehen, muss der Datenverkehr über den primären Pfad unter normalen Datenverkehrsbedingungen eingehend analysiert werden, wie im Topologiediagramm im vorherigen Unterabschnitt beschrieben.
Das Hauptziel bei Failover-Szenarien besteht darin, die Diskrepanz zwischen den Datenverkehrspfaden in der aktuellen Topologieinfrastruktur so gering wie möglich zu halten. Das XYZ-Netzwerk hat strenge Anforderungen an die administrative Steuerung des Datenverkehrs durch bestimmte Knoten in Backup-Pfaden, um eine maximale Trennung zwischen den Quell- und Ziel-Knotenpaaren zu gewährleisten. Dieses Design soll eine Überlastung der verwendeten Links verhindern und dafür sorgen, dass die Anzahl nicht verwendeter Links auf ein Minimum reduziert wird.
Diese Unterabschnitte zeigen die verschiedenen Failover-Szenarien, wie Single Link, Double Link, Single Node und Double Node mit dem Failover-Pfad, den der Datenverkehr benötigt, um eine maximale Diskrepanz aufrechtzuerhalten.
8.6.3. Failover-Szenario mit einer Verbindung
Hierbei handelt es sich um das Szenario mit Ausfall einer einzelnen Verbindung, bei dem die lokale Verbindung zwischen PE1 und P1 ausfällt und der Datenverkehr über die Core-P2- und -P1-Knoten umgeleitet wird. Die Steuerung erfolgt administrativ über die Segmentliste <SIDLIST1>, die den primären Backup-Pfad zwischen den PE1- und PE3-Knoten bildet.
Abbildung 13: Failover-Szenario mit einer Verbindung
Diskrepanz: Beim Ausfall einer einzelnen Verbindung beträgt die Anzahl der gemeinsam genutzten Verbindungen null (0), wie in der vorherigen Topologie gezeigt.
8.6.3.1. Konfigurationsvorlagen
Dieser Unterabschnitt enthält die relevanten Konfigurationsvorlagen für OSPF/SR-TE für die hier angegebenen PE1- und PE2-Knoten:
# PE1 Node: OSPF & SR-TE configs
segment-routing
traffic-eng
!
!
segment-list name <SIDLIST1> Primary/Normal Path SID-LIST1
index <Index ID> mpls adjacency <Remote-IP-Address-Link1>
index <Index ID> mpls adjacency <Remote-IP-Address-Link2>
index <Index ID> mpls adjacency <Remote-IP-Address-Link3>
!
segment-list name <SIDLIST2> Primary Back Up Path SID-LIST2
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
segment-list name <SIDLIST3> Secondary Back Up Path SID-LIST3
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
policy <Pol-Name1>
source-address ipv4 Configure SR-TE source address as OSPF loopback (Policy Specific Option)
color <Color-ID> end-point ipv4 <Destn-PE3>
candidate-paths
preference 50 Tertiary Back Up Path with least preference
dynamic
metric
type igp
!
!
!
preference 100 Secondary Back Up Path with 3rd highest preference
explicit segment-list <SIDLIST3>
!
!
preference 150 Primary Back Up Path with 2nd highest preference (Active Path for PE1 in this scenario)
explicit segment-list <SIDLIST2>
!
!
preference 200 Primary/Normal Path with highest preference
explicit segment-list <SIDLIST1>
!
!
!
!
!
!
# PE2 Node: OSPF & SR-TE configs
segment-routing
traffic-eng
!
!
segment-list name <SIDLIST1> Primary/Normal Path SID-LIST1
index <Index ID> mpls adjacency <Remote-IP-Address-Link1>
index <Index ID> mpls adjacency <Remote-IP-Address-Link2>
index <Index ID> mpls adjacency <Remote-IP-Address-Link3>
!
segment-list name <SIDLIST2> Primary Back Up Path SID-LIST2
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
segment-list name <SIDLIST3> Secondary Back Up Path SID-LIST3
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
policy <Pol-Name1>
source-address ipv4 Configure SR-TE source address as OSPF loopback (Policy Specific Option)
color <Color-ID> end-point ipv4 <Destn-PE4>
candidate-paths
preference 50 Tertiary Back Up Path with least preference
dynamic
metric
type igp
!
!
!
preference 100 Secondary Back Up Path with 3rd highest preference
explicit segment-list <SIDLIST3>
!
!
preference 150 Primary Back Up Path with 2nd highest preference
explicit segment-list <SIDLIST2>
!
!
preference 200 Primary/Normal Path with highest preference (Active Path for PE2 in this scenario)
explicit segment-list <SIDLIST1>
!
!
!
!
!
!
8.6.4. Double-Link-Failover-Szenario
In diesem Szenario tritt ein Fehler bei doppelter Verbindung auf, wenn die lokale Verbindung zwischen PE1 und P1 und die lokale Verbindung zwischen PE2 und P2 ausfällt. Der Datenverkehr von PE1 erfolgt über die Core-Knoten P2 und P1, der Datenverkehr von PE2 über die Core-Knoten P1 und P2.
Diese werden administrativ über die jeweiligen Segment-Listen <SIDLIST2> von PE1 und PE2 gesteuert, die die sekundären Backup-Pfade zwischen PE1 und PE3 bzw. PE2 und PE4 bilden.
Abbildung 14: Failover-Szenario mit doppelter Verbindung
Disjointness (Disjointness): Bei Ausfall einer doppelten Verbindung beträgt die Anzahl der gemeinsam genutzten Verbindungen 1 (siehe oben).
8.6.4.1. Konfigurationsvorlagen
Dieser Unterabschnitt enthält die relevanten Konfigurationsvorlagen für OSPF/SR-TE für die hier angegebenen PE1- und PE2-Knoten:
# PE1 Node: OSPF & SR-TE configs
#show run router ospf
router ospf CORE
distribute link-state
log adjacency changes
router-id 11.11.11.11
segment-routing mpls
microloop avoidance segment-routing
area 0
interface Bundle-Ether11
cost 100
authentication keychain XYZ-CONT-PE1
network point-to-point
fast-reroute per-prefix
fast-reroute per-prefix ti-lfa enable
fast-reroute per-prefix tiebreaker node-protecting index 200
prefix-suppression
!
interface Bundle-Ether12
cost 100
authentication keychain XYZ-CONT-PE1
network point-to-point
fast-reroute per-prefix
fast-reroute per-prefix ti-lfa enable
fast-reroute per-prefix tiebreaker node-protecting index 200
prefix-suppression
!
interface Loopback0
passive enable
prefix-sid index 11
!
!
!
segment-routing
traffic-eng
!
!
segment-list name <SIDLIST1> Primary/Normal Path SID-LIST1
index <Index ID> mpls adjacency <Remote-IP-Address-Link1>
index <Index ID> mpls adjacency <Remote-IP-Address-Link2>
index <Index ID> mpls adjacency <Remote-IP-Address-Link3>
!
segment-list name <SIDLIST2> Primary Back Up Path SID-LIST2
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
segment-list name <SIDLIST3> Secondary Back Up Path SID-LIST3
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
policy <Pol-Name1>
source-address ipv4 Configure SR-TE source address as OSPF loopback (Policy Specific Option)
color <Color-ID> end-point ipv4 <Destn-PE3>
candidate-paths
preference 50 Tertiary Back Up Path with least preference
dynamic
metric
type igp
!
!
!
preference 100 Secondary Back Up Path with 3rd highest preference
explicit segment-list <SIDLIST3>
!
!
preference 150 Primary Back Up Path with 2nd highest preference (Active Path for PE1 in this scenario)
explicit segment-list <SIDLIST2>
!
!
preference 200 Primary/Normal Path with highest preference
explicit segment-list <SIDLIST1>
!
!
!
!
!
!
# PE2 Node: OSPF & SR-TE configs
segment-routing
traffic-eng
!
!
segment-list name <SIDLIST1> Primary/Normal Path SID-LIST1
index <Index ID> mpls adjacency <Remote-IP-Address-Link1>
index <Index ID> mpls adjacency <Remote-IP-Address-Link2>
index <Index ID> mpls adjacency <Remote-IP-Address-Link3>
!
segment-list name <SIDLIST2> Primary Back Up Path SID-LIST2
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
segment-list name <SIDLIST3> Secondary Back Up Path SID-LIST3
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
policy <Pol-Name1>
source-address ipv4 Configure SR-TE source address as OSPF loopback (Policy Specific Option)
color <Color-ID> end-point ipv4 <Destn-PE4>
candidate-paths
preference 50 Tertiary Back Up Path with least preference
dynamic
metric
type igp
!
!
!
preference 100 Secondary Back Up Path with 3rd highest preference
explicit segment-list <SIDLIST3>
!
!
preference 150 Primary Back Up Path with 2nd highest preference (Active Path for PE2 in this scenario)
explicit segment-list <SIDLIST2>
!
!
preference 200 Primary/Normal Path with highest preference
explicit segment-list <SIDLIST1>
!
!
!
!
!
!
8.6.5. Failover-Szenario für einen Knoten
Hierbei handelt es sich um das Einzelknoten-Ausfallszenario, bei dem der Knoten P1 ausfällt und der Datenverkehr über die Core-Knoten P2 und P4 einen Umweg nimmt. Die Steuerung erfolgt administrativ über die Segment-Liste <SIDLIST3>, die den sekundären Backup-Pfad zwischen den PE1- und PE3-Knoten bildet.
Der Datenverkehr zwischen PE2 und PE4 bleibt jedoch derselbe primäre Pfad, wie in dieser Topologie gezeigt.
Abbildung 15: Failover-Szenario mit einem Knoten
Diskrepanz: Beim Ausfall eines einzelnen Knotens beträgt die Anzahl der gemeinsam genutzten Links (1), wie in der zuvor erwähnten Topologie gezeigt.
8.6.5.1. Konfigurationsvorlagen
Dieser Unterabschnitt enthält die relevanten Konfigurationsvorlagen für OSPF/SR-TE für die angegebenen PE1- und PE2-Knoten:
segment-routing
traffic-eng
!
!
segment-list name <SIDLIST1> Primary/Normal Path SID-LIST1
index <Index ID> mpls adjacency <Remote-IP-Address-Link1>
index <Index ID> mpls adjacency <Remote-IP-Address-Link2>
index <Index ID> mpls adjacency <Remote-IP-Address-Link3>
!
segment-list name <SIDLIST2> Primary Back Up Path SID-LIST2
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
segment-list name <SIDLIST3> Secondary Back Up Path SID-LIST3
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
policy <Pol-Name1>
source-address ipv4 Configure SR-TE source address as OSPF loopback (Policy Specific Option)
color <Color-ID> end-point ipv4 <Destn-PE3>
candidate-paths
preference 50 Tertiary Back Up Path with least preference
dynamic
metric
type igp
!
!
!
preference 100 Secondary Back Up Path with 3rd highest preference (Active Path for PE1 in this scenario)
explicit segment-list <SIDLIST3>
!
!
preference 150 Primary Back Up Path with 2nd highest preference
explicit segment-list <SIDLIST2>
!
!
preference 200 Primary/Normal Path with highest preference
explicit segment-list <SIDLIST1>
!
!
!
!
!
!
# PE2 Node: OSPF & SR-TE configs
segment-routing
traffic-eng
!
!
segment-list name <SIDLIST1> Primary/Normal Path SID-LIST1
index <Index ID> mpls adjacency <Remote-IP-Address-Link1>
index <Index ID> mpls adjacency <Remote-IP-Address-Link2>
index <Index ID> mpls adjacency <Remote-IP-Address-Link3>
!
segment-list name <SIDLIST2> Primary Back Up Path SID-LIST2
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
segment-list name <SIDLIST3> Secondary Back Up Path SID-LIST3
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
policy <Pol-Name1>
source-address ipv4 Configure SR-TE source address as OSPF loopback (Policy Specific Option)
color <Color-ID> end-point ipv4 <Destn-PE4>
candidate-paths
preference 50 Tertiary Back Up Path with least preference
dynamic
metric
type igp
!
!
!
preference 100 Secondary Back Up Path with 3rd highest preference
explicit segment-list <SIDLIST3>
!
!
preference 150 Primary Back Up Path with 2nd highest preference
explicit segment-list <SIDLIST2>
!
!
preference 200 Primary/Normal Path with highest preference (Active Path for PE2 in this scenario)
explicit segment-list <SIDLIST1>
!
!
!
!
!
!
8.6.6. Failover-Szenario mit doppeltem Knoten
Dies ist das Szenario mit doppeltem Knotenausfall, bei dem die Knoten P1 und P3 ausfallen und der Datenverkehr über die Core-Knoten P2 und P4 einen Umweg nimmt. Die Steuerung erfolgt administrativ über die Segment-Liste <SIDLIST3>, die den sekundären Backup-Pfad zwischen den PE1- und PE3-Knoten bildet. Da die expliziten Pfade nur für die zuvor genannten 2 Szenarien definiert sind, bildet hier der dynamische IGP-Pfad den tertiären Backup-Pfad und übernimmt die Rolle des Routings des Verkehrs über die P2- und P4-Knoten.
Der Datenverkehr zwischen PE2 und PE4 bleibt jedoch derselbe primäre Pfad, wie in dieser Topologie gezeigt.
Abbildung 16: Szenario mit doppeltem Knoten-Failover.
Diskrepanz: Bei Ausfall eines doppelten Knotens beträgt die Anzahl der gemeinsam genutzten Links (1), wie in dieser Topologie gezeigt.
8.6.6.1. Konfigurationsvorlagen
Dieser Unterabschnitt enthält die relevanten Konfigurationsvorlagen für OSPF/SR-TE für die angegebenen PE1- und PE2-Knoten:
# PE1 Node: OSPF & SR-TE configs
segment-routing
traffic-eng
!
!
segment-list name <SIDLIST1> Primary/Normal Path SID-LIST1
index <Index ID> mpls adjacency <Remote-IP-Address-Link1>
index <Index ID> mpls adjacency <Remote-IP-Address-Link2>
index <Index ID> mpls adjacency <Remote-IP-Address-Link3>
!
segment-list name <SIDLIST2> Primary Back Up Path SID-LIST2
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
segment-list name <SIDLIST3> Secondary Back Up Path SID-LIST3
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
policy <Pol-Name1>
source-address ipv4 Configure SR-TE source address as OSPF loopback (Policy Specific Option)
color <Color-ID> end-point ipv4 <Destn-PE3>
candidate-paths
preference 50 Tertiary Back Up Path with least preference (Active Path for PE1 in this scenario -
Policy chooses Least Cost IGP Back Up Path in absence of Valid Explicit Path)
dynamic
metric
type igp
!
!
!
preference 100 Secondary Back Up Path with 3rd highest preference
explicit segment-list <SIDLIST3>
!
!
preference 150 Primary Back Up Path with 2nd highest preference
explicit segment-list <SIDLIST2>
!
!
preference 200 Primary/Normal Path with highest preference
explicit segment-list <SIDLIST1>
!
!
!
!
!
!
# PE2 Node: OSPF & SR-TE configs
segment-routing
traffic-eng
!
!
segment-list name <SIDLIST1> Primary/Normal Path SID-LIST1
index <Index ID> mpls adjacency <Remote-IP-Address-Link1>
index <Index ID> mpls adjacency <Remote-IP-Address-Link2>
index <Index ID> mpls adjacency <Remote-IP-Address-Link3>
!
segment-list name <SIDLIST2> Primary Back Up Path SID-LIST2
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
segment-list name <SIDLIST3> Secondary Back Up Path SID-LIST3
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
policy <Pol-Name1>
source-address ipv4 Configure SR-TE source address as OSPF loopback (Policy Specific Option)
color <Color-ID> end-point ipv4 <Destn-PE4>
candidate-paths
preference 50 Tertiary Back Up Path with least preference
dynamic
metric
type igp
!
!
!
preference 100 Secondary Back Up Path with 3rd highest preference
explicit segment-list <SIDLIST3>
!
!
preference 150 Primary Back Up Path with 2nd highest preference
explicit segment-list <SIDLIST2>
!
!
preference 200 Primary/Normal Path with highest preference (Active Path for PE2 in this scenario)
explicit segment-list <SIDLIST1>
!
!
!
!
!
!
8.7. Übersicht über das BGP/RR-Design
Border Gateway Protocol (BGP) ist das Protokoll, das grundlegende Routing-Entscheidungen im Internet trifft. Es verwaltet eine Tabelle mit IP-Netzwerken oder "Präfixen", die die Netzwerkerreichbarkeit zwischen autonomen Systemen (AS) angeben. Es wird als Pfadvektorprotokoll beschrieben. BGP verwendet keine herkömmlichen Interior Gateway Protocol (IGP)-Metriken, trifft Routing-Entscheidungen jedoch auf der Grundlage von Pfad, Netzwerkrichtlinien und/oder Regelsätzen. Aus diesem Grund wird es eher als Reach-ability-Protokoll denn als Routing-Protokoll bezeichnet.
Das MP-BGP kann verwendet werden, um IPv4-, IPv6-, VPNv4-, VPNv6-, EVPN- und Link-State-Präfixe über das Netzwerk zu propagieren. Dazu wird eine Routen-Reflektor-Konfiguration verwendet, die iBGP-Nachbarn mit Core-, Aggregations-, Zugriffs- und SR-PCE-Geräten bildet.
Über den RR werden vom BGP empfangene Präfixe intern über das iBGP propagiert. BGP-Routen werden nie in IGPs neu verteilt. Die Routen-Reflektoren sind vollständig von der Datenebene isoliert und für Kontrollebenenzwecke bestimmt.
8.7.1. Konfigurationsvorlagen
Dieser Unterabschnitt enthält die relevanten Konfigurationsvorlagen für BGP/RR wie folgt:
# PE Node: Relevant BGP configs
router bgp <PE-ASN>
address-family l2vpn evpn
!
neighbor-group <RR-EVPN> Neighbor group of Route Reflector (RR)
remote-as <RR-ASN>
update-source <PE-Self-Loopback>
!
address-family l2vpn evpn AF L2VPN EVPN Neighborship with RR
maximum-prefix <PREFIX> <PERCENT> warning-only
!
address-family ipv4 rt-filter
!
neighbor <RR1-Loopback> Neighborship with RR1 using the above neighbor group
use neighbor-group <RR-EVPN>
neighbor <RR2-Loopback> Neighborship with RR2 using the above neighbor group
use neighbor-group <RR-EVPN>
# RR Nodes: Relevant BGP configs
router bgp <RR-ASN>
address-family l2vpn evpn
!
neighbor-group <PE-EVPN> Neighbor group of Provider Edge (PE)
remote-as <PE-ASN>
update-source <RR-Self-Loopback>
!
address-family l2vpn evpn AF L2VPN EVPN Neighborship with PE
route-reflector-client
!
address-family ipv4 rt-filter
!
neighbor <PE1-Loopback> Neighborship with PE1 using the above neighbor group
use neighbor-group <PE-EVPN>
neighbor <PE2-Loopback> Neighborship with PE2 using the above neighbor group
use neighbor-group <PE-EVPN>
8.8. Überblick über das Service-Design
In diesem Unterabschnitt wird der EVPN VPWS Overlay Service zusammen mit der Darstellung des unterstützten Label-Stacks und der Konfigurationsvorlagen beschrieben.
EVPN-VPWS ist eine BGP-Kontrollebenenlösung für Point-to-Point-Services. Es implementiert die Signalisierungs- und Kapselungstechniken, die eine EVPN-Instanz zwischen zwei PEs einrichten. Er kann Datenverkehr ohne MAC-Suche von einem Netzwerk an ein anderes weiterleiten. Durch den Einsatz von EVPN für VPWS entfallen Signalisierungs-PWs mit einem und mehreren Segmenten für Point-to-Point-Ethernet-Services. Die EVPN-VPWS-Technologie funktioniert mit IP- und MPLS-Core; der IP-Core unterstützt BGP und MPLS-Core für das Switching von Paketen zwischen den Endpunkten.
8.8.1. Etikettenstapeldarstellung
Der Service unterstützt bis zu 5 bis 6 SR-Label-Stacks, einschließlich SR-Transportlabel, EVPN-Label und FAT-Label für den Lastenausgleich. Dies ist die analysierte maximale Anzahl von Labels in normalen Szenarien, in denen Datenverkehr einen expliziten primären Pfad durchläuft:
| ADJ-SID1 |
|
| ADJ-SID2 |
|
| ADJ-SID3 |
|
| EVPN-ETIKETT |
|
| FLUSSETIKETT (S=1) |
Dabei handelt es sich um die analysierte maximale Anzahl von Labels in Failover-Szenarien, bei denen der Datenverkehr über einen expliziten Backup-Pfad oder einen vom IGP definierten dynamischen Backup-Pfad fließt:
| TI-LFA SID1 |
| TI-LFA SID2 |
| TI-LFA SID3 |
| EVPN-ETIKETT |
| FLUSSETIKETT (S=1) |
8.8.2. Konfigurationsvorlagen
Dieser Unterabschnitt enthält die relevanten Konfigurationsvorlagen für EVPN-VPWS, wie dargestellt:
# PE Node: EVPN configs
evpn
evi <EVI-ID> Ethernet Virtual Identifier
bgp
rd <RD-Value>
route-target import <RT-Value>
route-target export <RT-Value>
!
load-balancing
flow-label static Generates bottom-most label (S=1) for load balancing between intra & inter BE end-to-end
!
!
interface <AC-Interface>
l2vpn
pw-class <PW-Class-Name1>
encapsulation mpls
preferred-path sr-te policy <Pol-Name1> Attaching SR-TE policy as the traffic path of EVPN
!
!
xconnect group <Group-Name>
p2p <P2P-Name>
interface <AC-Subinterface> EVPN Attachment Circuit Interface towards CE
neighbor evpn evi <EVI-ID> service <Service-ID> Service ID defined should match at both the end PEs
pw-class <PW-Class-Name1>
!
9. Beispielkonfiguration und Befehle anzeigen
Dieser letzte Abschnitt enthält die relevanten Konfigurations- und Anzeigebefehle von PE-Knoten nur für das normale Datenverkehrsszenario. Diese werden hier in Übereinstimmung mit den in dieser Abbildung angegebenen Parametern als Referenz erfasst, die das Verständnis der in den vorherigen Abschnitten erläuterten Konfigurationsvorlagen erleichtert.
9.1. Beispielkonfiguration an PE-Knoten
Abbildung 17: Topologie mit Konfigurationsparametern
# PE1 Node: OSPF & SR-TE Config
#show run router ospf
router ospf CORE
distribute link-state Command to distribute OSPF database into SR-TE database
log adjacency changes
router-id 11.11.11.11 OSPF Router ID
segment-routing mpls
microloop avoidance segment-routing Command to enable microloop avoidance with TI-LFA
area 0
interface Bundle-Ether111 OSPF PE to P Link
cost 100 OSPF PE to P Metric
authentication keychain XYZ-CONT-PE1 Command to enable OSPF Authentication per link
network point-to-point
fast-reroute per-prefix Commands to enable TI-LFA
fast-reroute per-prefix ti-lfa enable
fast-reroute per-prefix tiebreaker node-protecting index 200
prefix-suppression
!
interface Bundle-Ether211
cost 100
authentication keychain XYZ-CONT-PE1
network point-to-point
fast-reroute per-prefix
fast-reroute per-prefix ti-lfa enable
fast-reroute per-prefix tiebreaker node-protecting index 200
prefix-suppression
!
interface Loopback0
passive enable
prefix-sid index 11 OSPF Loopback Prefix SID
!
!
!
#show run segment-routing
Sat Apr 16 23:22:42.727 UTC
segment-routing
traffic-eng
segment-list PrimaryPath Primary/Normal Path
index 10 mpls adjacency 10.1.11.0
index 20 mpls adjacency 10.1.3.1
index 30 mpls adjacency 10.3.13.1
!
segment-list PrimaryBackUpPath Primary Back Up Path
index 10 mpls adjacency 10.2.11.0
index 20 mpls adjacency 10.1.2.0
index 30 mpls adjacency 10.1.3.1
!
segment-list SecondaryBackUpPath Secondary Back Up Path
index 10 mpls adjacency 10.2.11.0
index 20 mpls adjacency 10.2.4.1
index 30 mpls adjacency 10.3.4.0
!
policy SR-TE_POLICY_PE1-to-PE3 SR-TE Policy Towards PE3
color 10 end-point ipv4 33.33.33.33 SR-TE Policy End-Point PE3 Loopback
candidate-paths
preference 50 Tertiary Back Up Dynamic IGP Path with 4th highest preference
dynamic
metric
type igp
!
!
!
preference 100 Secondary Back Up Path with 3rd highest preference
explicit segment-list SecondaryBackUpPath
!
!
preference 150 Primary Back Up Path with 2nd highest preference
explicit segment-list PrimaryBackUpPath
!
!
preference 200 Primary and Active Path with highest preference
explicit segment-list PrimaryPath
!
!
!
!
!
!
# PE2 Node: OSPF & SR-TE Config
#show run router ospf
router ospf CORE
distribute link-state Command to distribute OSPF database into SR-TE database
log adjacency changes
router-id 22.22.22.22 OSPF Router ID
segment-routing mpls
microloop avoidance segment-routing Command to enable microloop avoidance with TI-LFA
area 0
interface Bundle-Ether112 OSPF PE to P Link
cost 100 OSPF PE to P Metric
authentication keychain XYZ-CONT-PE2
network point-to-point
fast-reroute per-prefix Commands to enable TI-LFA
fast-reroute per-prefix ti-lfa enable
fast-reroute per-prefix tiebreaker node-protecting index 200
prefix-suppression
!
interface Bundle-Ether222
cost 100
authentication keychain XYZ-CONT-PE2 Command to enable OSPF Authentication per link
network point-to-point
fast-reroute per-prefix Commands to enable TI-LFA
fast-reroute per-prefix ti-lfa enable
fast-reroute per-prefix tiebreaker node-protecting index 200
prefix-suppression
!
interface Loopback0
passive enable
prefix-sid index 22 OSPF Loopback Prefix SID
!
!
!
#show run segment-routing
Sat Apr 16 23:22:42.727 UTC
segment-routing
traffic-eng
segment-list PrimaryPath Primary/Normal Path
index 10 mpls adjacency 10.2.12.0
index 20 mpls adjacency 10.2.4.1
index 30 mpls adjacency 10.4.14.1
!
segment-list PrimaryBackUpPath Primary Back Up Path
index 10 mpls adjacency 10.1.12.0
index 20 mpls adjacency 10.1.2.1
index 30 mpls adjacency 10.2.4.1
!
segment-list SecondaryBackUpPath Secondary Back Up Path
index 10 mpls adjacency 10.1.12.0
index 20 mpls adjacency 10.1.3.1
index 30 mpls adjacency 10.3.4.1
!
policy SR-TE_POLICY_PE2-to-PE4 SR-TE Policy Towards PE4
color 10 end-point ipv4 44.44.44.44 SR-TE Policy End-Point PE4 Loopback
candidate-paths
preference 50 Tertiary Back Up Dynamic IGP Path with 4th highest preference
dynamic
metric
type igp
!
!
!
preference 100 Secondary Back Up Path with 3rd highest preference
explicit segment-list SecondaryBackUpPath
!
!
preference 150 Primary Back Up Path with 2nd highest preference
explicit segment-list PrimaryBackUpPath
!
!
preference 200 Primary and Active Path with highest preference
explicit segment-list PrimaryPath
!
!
!
!
!
!
# PE1 Node: BGP Config
#show run router bgp
router bgp 64848
bgp router-id 11.11.11.11 BGP Router-ID
address-family l2vpn evpn
!
neighbor-group RR-EVPN
remote-as 64848
update-source Loopback0
address-family l2vpn evpn BGP AF L2VPN EVPN
!
!
neighbor 10.10.10.10 Neighbor Route Reflector
use neighbor-group RR-EVPN
!
!
# PE2 Node: BGP Config
#show run router bgp
router bgp 64848
bgp router-id 22.22.22.22 BGP Router-ID
address-family l2vpn evpn
!
neighbor-group RR-EVPN
remote-as 64848
update-source Loopback0
address-family l2vpn evpn BGP AF L2VPN EVPN
!
!
neighbor 10.10.10.10 Neighbor Route Reflector
use neighbor-group RR-EVPN
!
!
# PE1 Node: EVPN-VPWS Config
evpn
evi 100 Ethernet Virtual Identifier
bgp
rd 11:11
route-target import 100:100
route-target export 100:100
!
load-balancing Generates bottom-most label (S=1) for load balancing between intra & inter BE end-to-end
flow-label static
!
!
interface Bundle-Ether99 Interface Attachment Circuit
ethernet-segment
identifier type 0 00.00.00.00.00.00.00.00.00
!
!
!
# PE2 Node: EVPN-VPWS Config
evpn
evi 100 Ethernet Virtual Identifier
bgp
rd 11:11
route-target import 100:100
route-target export 100:100
!
load-balancing Generates bottom-most label (S=1) for load balancing between intra & inter BE end-to-end
flow-label static
!
!
interface Bundle-Ether99 Interface Attachment Circuit
ethernet-segment
identifier type 0 00.00.00.00.00.00.00.00.00
!
!
!
9.1. Relevante Show-Befehle an PE-Knoten
# PE1 Node: SR-TE Show Command
#show segment-routing traffic-eng policy
Sat Apr 16 23:35:32.731 UTC
SR-TE policy database
---------------------
Color: 10, End-point: 33.33.33.33
Name: srte_c_10_ep_33.33.33.33
Status:
Admin: up Operational: up for 00:12:54 (since Apr 16 23:22:38.278)
Candidate-paths:
Preference: 200 (configuration) (active) Active Path (Path in use)
Name: SR-TE_POLICY_PE1-to-PE3
Requested BSID: dynamic
Protection Type: protected-preferred
Maximum SID Depth: 12
Explicit: segment-list PrimaryPath (valid) Only the Active Path shows valid
Weight: 1, Metric Type: TE
24007 [Adjacency-SID, 10.1.11.0 - 10.1.11.1]
24007 [Adjacency-SID, 10.1.3.0 - 10.1.3.1]
24005 [Adjacency-SID, 10.3.13.0 - 10.3.13.1]
Preference: 150 (configuration)
Name: SR-TE_POLICY_PE1-to-PE3
Requested BSID: dynamic
Protection Type: protected-preferred
Maximum SID Depth: 12
Explicit: segment-list PrimaryBackUpPath (invalid) All inactive paths show invalid
Weight: 1, Metric Type: TE
Preference: 100 (configuration)
Name: SR-TE_POLICY_PE1-to-PE3
Requested BSID: dynamic
Protection Type: protected-preferred
Maximum SID Depth: 12
Explicit: segment-list SecondaryBackUpPath (invalid)
Weight: 1, Metric Type: TE
Preference: 50 (configuration) All inactive paths show invalid
Name: SR-TE_POLICY_PE1-to-PE3
Requested BSID: dynamic
Protection Type: protected-preferred
Maximum SID Depth: 12
Dynamic (invalid)
Metric Type: IGP, Path Accumulated Metric: 0
Attributes:
Binding SID: 24020
Forward Class: Not Configured
Steering labeled-services disabled: no
Steering BGP disabled: no
IPv6 caps enable: yes
Invalidation drop enabled: no
# PE2 Node: SR-TE Show Command
#show segment-routing traffic-eng policy
Sat Apr 16 23:35:32.731 UTC
SR-TE policy database
---------------------
Color: 10, End-point: 44.44.44.44
Name: srte_c_10_ep_44.44.44.44
Status:
Admin: up Operational: up for 00:12:54 (since Apr 16 23:22:38.278)
Candidate-paths:
Preference: 200 (configuration) (active) Active Path (Path in use)
Name: SR-TE_POLICY_PE1-to-PE3
Requested BSID: dynamic
Protection Type: protected-preferred
Maximum SID Depth: 12
Explicit: segment-list PrimaryPath (valid) Only the Active Path shows valid
Weight: 1, Metric Type: TE
24007 [Adjacency-SID, 10.2.12.0 - 10.2.12.1]
24007 [Adjacency-SID, 10.2.4.0 - 10.2.4.1]
24005 [Adjacency-SID, 10.4.14.0 - 10.4.14.1]
Preference: 150 (configuration)
Name: SR-TE_POLICY_PE1-to-PE3
Requested BSID: dynamic
Protection Type: protected-preferred
Maximum SID Depth: 12
Explicit: segment-list PrimaryBackUpPath (invalid) All inactive paths show invalid
Weight: 1, Metric Type: TE
Preference: 100 (configuration)
Name: SR-TE_POLICY_PE1-to-PE3
Requested BSID: dynamic
Protection Type: protected-preferred
Maximum SID Depth: 12
Explicit: segment-list SecondaryBackUpPath (invalid)
Weight: 1, Metric Type: TE
Preference: 50 (configuration) All inactive paths show invalid
Name: SR-TE_POLICY_PE1-to-PE3
Requested BSID: dynamic
Protection Type: protected-preferred
Maximum SID Depth: 12
Dynamic (invalid)
Metric Type: IGP, Path Accumulated Metric: 0
Attributes:
Binding SID: 24020
Forward Class: Not Configured
Steering labeled-services disabled: no
Steering BGP disabled: no
IPv6 caps enable: yes
Invalidation drop enabled: no
# PE1 Node: BGP Show Command
#show bgp l2vpn evpn summary
Sun Apr 17 07:16:23.574 UTC
Address Family: L2VPN EVPN
--------------------------
BGP router identifier 11.11.11.11, local AS number 64848
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 0
BGP main routing table version 25
BGP NSR Initial initsync version 1 (Reached)
BGP NSR/ISSU Sync-Group versions 25/0
BGP scan interval 60 secs
BGP is operating in STANDALONE mode.
Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer
Speaker 25 25 25 25 25 25
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
10.10.10.10 0 64848 9500 9484 25 0 0 5d16h 1
# PE2 Node: BGP Show Command
#show bgp l2vpn evpn summary
Sun Apr 17 07:16:23.574 UTC
Address Family: L2VPN EVPN
--------------------------
BGP router identifier 22.22.22.22, local AS number 64848
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 0
BGP main routing table version 25
BGP NSR Initial initsync version 1 (Reached)
BGP NSR/ISSU Sync-Group versions 25/0
BGP scan interval 60 secs
BGP wird im STANDALONE-Modus ausgeführt.
Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer
Speaker 25 25 25 25 25 25
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
10.10.10.10 0 64848 9500 9484 25 0 0 5d16h 1
Fehlerbehebung
Für diese Konfiguration sind derzeit keine spezifischen Informationen zur Fehlerbehebung verfügbar.
Zugehörige Informationen
- https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r7-5/segment-routing/configuration/guide/b-segment-routing-cg-asr9000-75x/about-segment-routing.html
- https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r7-5/lxvpn/configuration/guide/b-l2vpn-cg-asr9000-75x/evpn-features.html
- Technischer Support und Dokumentation für Cisco Systeme
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
1.0 |
01-Jul-2022 |
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)