Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

PCEP-Konfiguration

PCEP – Übersicht

Ein Path Computation Element (PCE) ist eine Einheit (Komponente, Anwendung oder Netzwerkknoten), die in der Lage ist, auf der Basis eines Netzwerkdiagramms einen Netzwerkpfad oder eine Route zu erstellen und Berechnungseinschränkungen zu berücksichtigen. Ein Path Computation Client (PCC) ist jede Client-Anwendung, die eine Pfadberechnung an fordert, die von einem PCE ausgeführt werden soll. Das Path Computation Element Protocol (PCEP) ermöglicht die Kommunikation zwischen einem PCC und einem PCE oder zwischen zwei PCEs (definiert in RFC 5440).

PCEP ist ein TCP-basiertes Protokoll, das von der IETF PCE Working Group definiert wird und eine Reihe von Nachrichten und Objekten definiert, die zur Verwaltung von PCEP-Sitzungen und zum Anfordern und Senden von Pfaden für domainübergreifende Traffic Engineered-LSPs (TE-LSPs) verwendet werden. Er bietet einen Mechanismus für eine PCE-Pfadberechnung für externe LSPs eines PCC. Zu den PCEP-Interaktionen gehören LSP-Statusberichte, die von der PCC an das PCE gesendet werden, und PCE-Updates für externe LSPs.

Abbildung 1 zeigt die Rolle von PCEP bei der clientseitigen Implementierung einer Stateful PCE-Architektur in einem MPLS RSVP-TE-fähiges Netzwerk.

Abbildung 1: PCEP-SitzungPCEP-Sitzung

Eine TCP-basierte PCEP-Sitzung verbindet eine PCC mit einem externen PCE. Die PCC initiiert die PCEP-Sitzung und bleibt über die Dauer der PCEP-Sitzung mit dem PCE verbunden. Während der PCEP-Sitzung fordert das PCC LSP-Parameter vom stateful PCE an. Wenn ein oder mehrere LSP-Parameter vom PCE empfangen werden, signalisiert das PCC den TE LSP. Wenn die PCEP-Sitzung beendet wird, wird die zugrunde liegende TCP-Verbindung sofort geschlossen und das PCC versucht, die PCEP-Sitzung erneut herzustellen.

PcEP-Funktionen umfassen daher Folgendes:

  • LSP-Tunnelstatussynchronisierung zwischen einer PCC und einer Stateful-PCE: Wenn eine aktive Stateful-PCE-Verbindung erkannt wird, versucht ein PCC, alle LSPs an dieses PCE in einem Verfahren namens LSP-Statussynchronisierung zu delegieren. PCEP ermöglicht die Synchronisierung des PCC-LSP-Status mit dem PCE.

  • Delegierung der Kontrolle über LSP-Tunnel zu einem Stateful-PCE: Ein aktives Stateful-PCE steuert ein oder mehrere LSP-Attribute für Rechenpfade, wie Bandbreite, Pfad (ERO) und Priorität (Setup und Hold). PCEP ermöglicht eine solche Delegierung von LSPs für die Pfadberechnung.

  • Stateful PCE-Steuerung von Zeitsteuerung und Folge von Pfadberechnungen innerhalb und über PCEP-Sitzungen hinweg: Ein aktiver stateful PCE ändert ein oder mehrere LSP-Attribute, wie Bandbreite, Pfad (ERO) und Priorität (Einrichtung und Hold). PCEP kommuniziert diese neuen LSP-Attribute vom PCE an die PCC, nachdem das PCC den LSP in dem angegebenen Pfad erneut signalisiert.

Unterstützung des Path Computation Element Protocol für RSVP-TE Übersicht

Grundlegende MPLS RSVP-TE

Traffic Engineering (TE) befasst sich mit der Leistungsoptimierung von Betriebsnetzwerken und zeigt hauptsächlich die Datenverkehrsflüsse in einer vorhandenen physischen Topologie auf. Traffic-Engineering bietet die Möglichkeit, den Datenverkehrsfluss von dem vom Interior Gateway Protocol (IGP) ausgewählten kürzesten Pfad weg auf einen potenziell weniger überlasteten physischen Pfad im gesamten Netzwerk zu verschieben.

Für das Traffic-Engineering in großen, dichten Netzwerken können MPLS-Funktionen implementiert werden, da sie möglicherweise die meisten der von einem Overlay-Modell verfügbaren Funktionen integriert und zu niedrigeren Kosten als die derzeit konkurrierenden Alternativen bereitstellen. Der Primäre Grund für die MPLS-Traffic Engineering die Kontrolle von Pfaden, die den Datenverkehr durch ein Netzwerk fließen. Der Hauptvorteil der Implementierung von MPLS-Traffic Engineering ist, dass sie eine Kombination aus den Traffic-Engineering-Fähigkeiten von ATM und der Class-of-Service-Differenzierung (CoS) von IP bietet.

In einem MPLS Netzwerk werden Daten auf der Datenebene über Label Switching weitergeleitet. Auf einem Provider-Edge-Router (PE)-Paket vom Edge-Router des Kunden (CE) werden Labels angewendet und an den Egress PE-Router weitergeleitet. Die Labels werden am Ausgangsrouter entfernt und dann als IP-Paket an das entsprechende Ziel weitergeleitet. Die Label-Switching-Router (LSRs) in der MPLS-Domain verwenden Label-Distributionsprotokolle, um die Bedeutung der Label zu kommunizieren, die für die Übertragung von Datenverkehr zwischen und über die LSRs verwendet werden. RSVP-TE ist ein solches Label distribution Protocol, das einem LSR ermöglicht, mehr über die Labelzuordnungen anderer Peers zu erfahren.

Wenn sowohl MPLS als auch RSVP auf einem Router aktiviert sind, wird MPLS client of RSVP. Der Hauptzweck der Junos OS RSVP-Software ist die Unterstützung einer dynamischen Signalübertragung innerhalb von Label-Switched Paths (LSPs). RSVP behält sich Ressourcen wie IP-Unicast und Multicast-Flows vor und fordert Parameter zur Servicequalität (QoS) für Anwendungen an. Das Protokoll wird in MPLS-Traffic Engineering erweitert, um RSVP die Einrichtung von LSPs zu ermöglichen, die für das Traffic-Engineering in netzwerken MPLS können.

Wenn MPLS und RSVP kombiniert werden, werden Label mit RSVP-Flows verknüpft. Sobald ein LSP eingerichtet wurde, wird der Datenverkehr über diesen Pfad durch das Label definiert, das auf den Ingress-Knoten des LSP angewendet wird. Die Zuordnung von Label und Datenverkehr erfolgt anhand verschiedener Kriterien. Die Pakete, die einem bestimmten Knoten den gleichen Labelwert zuweisen, gehören zur selben Forwarding Equivalence Class (FEC) und definieren effektiv den RSVP-Datenfluss. Wenn der Datenverkehr auf diese Weise einem LSP zugeordnet wird, wird der LSP als LSP-Tunnel bezeichnet.

LSP-Tunnel sind eine Möglichkeit, unidirektionale Label-Switched-Pfade zu erstellen. RSVP-TE baut auf dem RSVP Core-Protokoll auf, indem neue Objekte definiert und vorhandene Objekte, die in PATH- und RESV-Objekten für die LSP-Einrichtung verwendet werden, ändern. Die neuen Objekte – LABEL-REQUEST-Objekt (LRO), RECORD-ROUTE Object (RRO), LABEL Object und EXPLICIT-ROUTE Object (ERO) – sind optional in Bezug auf das RSVP-Protokoll. Es gelten jedoch nicht die LRO- und LABEL-Objekte, die für das Erstellen von LSP-Tunneln erforderlich sind.

Im Allgemeinen stellt RSVP-TE einen Label-Switched-Pfad fest, der eine Frame-Bereitstellung vom Ingress zum Egress-Router sicherstellt. Mit den neuen Traffic-Engineering-Funktionen werden jedoch die folgenden Funktionen in einer MPLS werden:

  • Möglichkeit, einen Label-Switched-Pfad entweder mit einem Full oder Partial Explicit Route (RFC 3209) zu erstellen.

  • Einschränkungsbasierte LSP-Einrichtung über Verbindungen, die Anforderungen erfüllen, wie Bandbreite und Verbindungseigenschaften.

  • Endpunktsteuerung, die mit dem Einrichten und Verwalten von LSP-Tunneln am Ingress- und Egress-Router verbunden ist.

  • Linkverwaltung, die die Verbindungsressourcen für das ressourcenorientierte Routing von Traffic-Engineering-LSPs sowie die MPLS verwaltet.

  • MPLS Fast Reroute (FRR), das die LSPs verwaltet, die Schutz benötigen, und diesen LSPs Backup-Tunnelinformationen zu.

Aktuelle MPLS RSVP-TE Einschränkungen

Obwohl die RSVP-Erweiterungen für Traffic-Engineering eine bessere Netzwerknutzung ermöglichen und die Anforderungen von Datenverkehrsklassen erfüllen, hat die MPLS RSVP-TE-Protokollsuite von heute mehrere Probleme, die ihrem verteilten Charakter eigen sind. Dies verursacht eine Reihe von Problemen während des Streits für die Bisektionskapazität, insbesondere innerhalb einer LSP-Prioritätsklasse, in der eine Teilgruppe von LSPs gemeinsame Einrichtungs- und Hold-Prioritätswerte hat. Zu den Grenzen von RSVP-TE gehören:

  • Mangelnde Visibilität der einzelnen Bandbreitenanforderungen pro LSP pro Gerät: Die eindringenden Router in einem MPLS RSVP-TE-Netzwerk richten LSPs ein, ohne eine globale Ansicht des Bandbreitenbedarfs im Netzwerk zu haben. Informationen zur Auslastung der Netzwerkressourcen sind pro Schnittstelle nur als reservierte Gesamtkapazität je Datenverkehrsklasse verfügbar. Der einzelne LSP-Status ist lokal auf jedem Label-Edge-Router (LER) nur für seine eigenen LSPs verfügbar. Infolgedessen treten eine Reihe von Problemen in Zusammenhang mit Nachfragemustern auf, insbesondere innerhalb einer gemeinsamen Einrichtung und Priorität.

  • Asynchrone und unabhängige Natur der RSVP-Signalübertragung: In RSVP-TE werden die Einschränkungen bei der Pfadeinrichtung von einem Administrator gesteuert. Als solche wird die für einen LSP-Tunnel reservierte Bandbreite vom Administrator festgelegt und bedeutet keinerlei Begrenzung des Datenverkehrs, der über den Tunnel gesendet wird. Die auf einem Traffic-Engineering-Link verfügbare Bandbreite ist daher die für den Link konfigurierte Bandbreite ohne die Summe aller Reservierungen, die im Link vorgenommen wurden. Dadurch führt die ungesignalen Anforderungen an einen LSP-Tunnel zu einer Serviceverschlechterung des LSP, die übermäßige Bandbreite erfordert, sowie der anderen LSPs, die die Bandbreitenanforderungen der Traffic Engineering-Verbindung erfüllen.

  • LSPs wurden basierend auf dynamischen oder expliciten Pfadoptionen in der Reihenfolge der Präferenz eingerichtet: Die Ingress-Router in einem MPLS RSVP-TE-Netzwerk richten LSPs für Anforderungen in der Reihenfolge ihrer Ankunft ein. Da die ein- und anderen Router nicht über eine globale Ansicht des Bandbreitenbedarfs im Netzwerk verfügen, kann die Verwendung der Reihenfolge der Einstellung zum Einrichten von LSPs dazu führen, dass Datenverkehr eingestellt oder gar nicht eingerichtete LSPs bei übermäßigem Bandbreitenbedarf eingerichtet werden.

Ein Beispiel ist mit rsvp-MPLS konfiguriert, in dem A und G die Abbildung 2 Label-Edge TE-Router (LERs) sind. Diese Ingress-Router richten LSPs unabhängig von der Reihenfolge der Anforderungen ein und haben keine Kenntnisse oder Kontrolle über die LSPs voneinander. Die Router B, C und D sind Intermediate- oder Transit-Router, die mit den Egress-Routern E und F verbunden sind.

Abbildung 2: Example MPLS Traffic Engineering Example MPLS Traffic Engineering

Die Ingress-Router richten LSPs in der Reihenfolge ein, in der die Anforderungen eintreffen. Wenn bei Router G zwei Kapazitätsanforderungen von jeweils 5 für G-F erfüllt werden, signalisiert G zwei LSPs – LSP1 und LSP2 – über G-B-D-F. Wenn Router A den dritten Kapazitätsbedarf von 10 für A-E empfängt, signalisiert er dann über A-B-C-E einen LSP, LSP3. Wenn jedoch der Bedarf an dem A-E-LSP von 10 auf 15 steigt, kann Router A den LSP3 nicht über den gleichen (A-B-C-E)-Pfad signalisieren, da die B-C-Verbindung eine geringere Kapazität hat.

Router A sollte über den A-B-D-C-E-Pfad die erhöhte Nachfrage an LSP3 signalisiert haben. Da LSP1 und LSP2 die B-D-Verbindung basierend auf der Reihenfolge der empfangenen Anforderungen verwendet haben, wird das LSP3 nicht signalisiert.

Obwohl für alle LSPs ausreichend Bandbreite max. Datenfluss verfügbar ist, kann der LSP3 möglicherweise durch eine Servicebeeinträchtigung verursachen. Dies ist auf die mangelnde globale Sichtbarkeit der Nachfrage nach Router A und die mangelnde systemische Koordination bei der Bedarfsplatzierung durch die ingress-Router A und G zurück fällig.

Verwendung einer externen Path Computing-Einheit

Als Lösung für die aktuellen Einschränkungen, die im MPLS RSVP-TE-Pfadberechnung zu finden sind, ist eine externe Path Computing-Einheit mit einer globalen Ansicht des Bedarfs pro Gerät im Netzwerk unabhängig von der verfügbaren Kapazität erforderlich.

Derzeit wird in einem RSVP-TE-Netzwerk nur online eine einschränkungsbasierte Routing-Pfadberechnung MPLS Echtzeit bereitgestellt. Jeder Router führt einschränkungenbasierte Routing-Berechnungen unabhängig von den anderen Routern im Netzwerk durch. Diese Berechnungen basieren auf den aktuell verfügbaren Topologieinformationen – Informationen, die in der Regel aktuell, aber nicht vollständig richtig sind. LSP-Platzierungen werden lokal auf Basis des aktuellen Netzwerkstatus optimiert. Die MPLS RSVP-TE werden mithilfe des CLI. Ein Betreiber konfiguriert den TE LSP, der dann vom Ingress-Router signalisiert wird.

Zusätzlich zu den vorhandenen Traffic-Engineering-Funktionen wird die MPLS RSVP-TE um eine externe Path Computing-Einheit namens Path Computation Element (PCE) erweitert. Das PCE berechnet den Pfad für die TE LSPs von Ingress-Routern, die für eine externe Steuerung konfiguriert wurden. Der ingress-Router, der die Verbindung mit einem PCE herstellt, wird als Path Computation Client (PCC) bezeichnet. Die PCC wird mit dem Path Computation Client Protocol (PCEP) konfiguriert, um ein externes Path Computing durch ein PCE zu erleichtern.

Weitere Informationen finden Sie Komponenten von External Path Computing unter.

Um ein externes Path Computing für die LSPs eines PCC TE, include die Aussage lsp-external-controller pccd auf den [edit mpls] und [edit mpls lsp lsp-name] Hierarchieebenen ein.

Komponenten von External Path Computing

Die Komponenten eines externen Path-Computing-Systems sind:

Pfadberechnungselement

Ein Path Computation Element (PCE) kann eine beliebige Komponente (Komponente, Anwendung oder Netzwerkknoten) sein, die in der Lage ist, auf der Basis eines Netzwerkdiagramms einen Netzwerkpfad oder eine Route zu erstellen und Berechnungseinschränkungen zu berücksichtigen. Ein PCE kann jedoch den Pfad nur für die TE LSPs eines PCC berechnet werden, die für eine externe Steuerung konfiguriert wurden.

Ein PCE kann entweder zustandslos oder zustandslos sein.

  • Stateful PCE: Ein Stateful-PCE hält die strikte Synchronisierung zwischen PCE und Netzwerkzuständen (in Bezug auf Topologie und Ressourceninformationen) sowie den Satz von Rechenpfaden und reservierten Ressourcen, die im Netzwerk verwendet werden, aufrecht. Anders ausgedrückt nutzt ein Stateful-PCE bei der Verarbeitung neuer PCC-Anforderungen Informationen aus der Traffic Engineering-Datenbank sowie Informationen über vorhandene Pfade (z. B. TE-LSPs) im Netzwerk.

    Ein Stateful-PCE besteht aus zwei Arten:

    • Passives stateful PCE: Hält die Synchronisierung mit dem PCC aufrecht und lernt den PCC-LSP-Status, um die Pfadberechnungen besser zu optimieren, hat jedoch keine Kontrolle darüber.

    • Aktives stateful PCE – Ändert aktiv die PCC-LSPs und lernt zusätzlich zum PCC-LSP-Status.

      Anmerkung:

      In einer redundanten Konfiguration mit Haupt- und Backup-aktiven Stateful-PCEs kann das aktive Stateful-PCE die Attribute von unterstützten LSPs nicht ändern, bis sie zum Zeitpunkt eines Failover zum Haupt-PCE werden. Im Fall eines Switchovers sind PCEs nicht vorbeachtet. Der Haupt-PCE wird durch ein Backup-PCE gesichert, und wenn der Haupt-PCE aus dem System aus geht, übernimmt der Sicherungs-PCE die Rolle des Haupt-PCE und bleibt das Haupt-PCE selbst nach dem PCE, der zuvor der Haupt-PCE wieder in Betrieb war.

    Ein Stateful-PCE bietet die folgenden Funktionen:

    • Bietet Offline-LSP-Pfadberechnung.

    • Löst das LSP-Umrouten aus, wenn eine Neuoptimierung des Netzwerks notwendig ist.

    • Ändert die LSP-Bandbreite, wenn der Bandbreitenbedarf einer Anwendung steigt.

    • Ändert andere LSP-Attribute auf dem Router, wie ERO, Einrichtungspriorität und Hold-Priorität.

    Ein PCE hat eine globale Ansicht der Bandbreitennachfrage im Netzwerk und verwaltet eine Datenverkehrsdatenbank zur Durchführung von Pfadberechnungen. Er führt mithilfe von SNMP und NETCONF Statistiken von allen Routern in der MPLS durch. Dies ermöglicht die Offline-Kontrolle der PCC-TE-LSPs. Obwohl ein Offline-LSP-Pfadberechnungssystem in einen Netzwerkcontroller eingebettet werden kann, agiert der PCE wie ein vollwertiger Netzwerkcontroller, der nicht nur die Computing-Pfade, sondern auch die TE-LSPs des PCC kontrolliert.

    Obwohl ein Stateful-PCE eine optimale Pfadberechnung und erhöhten Pfadberechnungserfolg ermöglicht, erfordert es zuverlässige Zustandssynchronisierungsmechanismen mit möglicherweise erheblichem Overhead der Steuerungsebene und der Wartung einer großen Anzahl von Daten in Bezug auf Status, wie bei einem Full-Mesh-Netz von TE-LSPs.

  • Stateless PCE: Ein zustandsloses PCE merkt sich keinen datenverarbeitungs erstellten Pfad, und jede Gruppe von Anfragen wird unabhängig voneinander verarbeitet (RFC 5440).

Pfadberechnungs-Client

Ein Path Computation Client (PCC) ist jede Client-Anwendung, die eine Pfadberechnung an fordert, die von einem PCE ausgeführt werden soll.

Ein PCC kann gleichzeitig eine Verbindung zu maximal 10 PCs herstellen. Bei der PCC-zu-PCE-Verbindung kann es sich um eine statische oder TCP-Verbindung zur Erreichbarkeit des Datenverkehrs erhöhen. Die PCC weist jedem angeschlossenen PCE eine Prioritätsnummer zu. Er sendet an alle angeschlossenen PCEs eine Nachricht mit Informationen über seine aktuellen LSPs in einem Prozess namens LSP-Zustandssynchronisierung. Für TE LSPs mit externer Steuerung delegiert der PCC diese LSPs an das Haupt-PCE. Das PCC wählt als Haupt-PCE, ein PCE mit der geringsten Prioritätsnummer oder das PCE, mit dem es beim Fehlen einer Prioritätsnummer zuerst eine Verbindung herstellt.

Das PCC zeigt einen LSP auf der Grundlage des rechnergestützten Pfads, den er von einem PCE erhält, neu an. Wenn die PCEP-Sitzung mit dem Haupt-PCE beendet wird, wählt die PCC ein neues Haupt-PCE, und alle anderen LSPs auf der zuvor Haupt-PCE werden von der neu verfügbaren Haupt-PCE mitgegründet.

Path Computation Element Protocol

Das Path Computation Element Protocol (PCEP) wird für die Kommunikation zwischen PCC und PCE (sowie zwischen zwei PCEs) verwendet (RFC 5440). PCEP ist ein TCP-basiertes Protokoll, das von der IETF PCE Working Group definiert wird und eine Reihe von Nachrichten und Objekten definiert, die zur Verwaltung von PCEP-Sitzungen und zum Anfordern und Senden von Pfaden für Multidomain-TE-LSPs verwendet werden. Die PCEP-Interaktionen umfassen PCC-Nachrichten und Benachrichtigungen über bestimmte Zustände in Zusammenhang mit der Verwendung eines PCE im Kontext MPLS RSVP-TE. Wenn PCEP für die PCE-to-PCE-Kommunikation verwendet wird, übernimmt der anfordernde PCE die Rolle eines PCC.

PcEP-Funktionen umfassen daher Folgendes:

  • LSP-Tunnelstatussynchronisierung zwischen PCC und einem zustands behafteten PCE.

  • Delegierung der Kontrolle über LSP-Tunnel zu einem zustands behafteten PCE

Interaktion zwischen einem PCE und einer PCC mit PCEP

Abbildung 3 beschreibt die Beziehung zwischen PCE, PCC und die Rolle von PCEP im Kontext von MPLS RSVP-TE.

Abbildung 3: PCC- und RSVP-TE PCC- und RSVP-TE

Die PCE-zu-PCC-Kommunikation wird durch das TCP-basierte PCEP aktiviert. Die PCC initiiert die PCEP-Sitzung und bleibt über die Dauer der PCEP-Sitzung mit einem PCE verbunden.

Anmerkung:

Beginnend mit Junos OS Version 16.1 können Sie eine PCEP-Sitzung mithilfe der TCP-MD5-Authentifizierung gemäß RFC 5440 sichern. Um den MD5-Sicherheitsmechanismus für eine PCEP-Sitzung zu aktivieren, wird empfohlen, den MD5-Authentifizierungsschlüssel auf Hierarchieebene für eine PCEP-Sitzung zu definieren und [edit protocols pcep pce pce-id] zu binden. Sie können jedoch auch eine vordefinierte Keychain von der Hierarchieebene verwenden, [edit security authentication-key-chains key-chain] um eine PCEP-Sitzung zu sichern. In diesem Fall sollten Sie die vordefinierte Keychain auf der Hierarchieebene in die PCEP-Sitzung [edit protocols pcep pce pce-id] binden.

PCE und PCC verwenden denselben Schlüssel, um die Authentizität jedes Segments zu überprüfen, das an der TCP-Verbindung der PCEP-Sitzung gesendet wird. Auf diese Weise wird die PCEP-Kommunikation zwischen den Geräten gesichert, die Angriffen unterliegen und die Dienste im Netzwerk unterbrechen kann.

Weitere Informationen zum Sichern von PCEP-Sitzungen mit md5-Authentifizierung finden Sie TCP-MD5-Authentifizierung für PCEP-Sitzungen unter.

Sobald die PCEP-Sitzung eingerichtet wurde, führt das PCC die folgenden Aufgaben aus:

  1. LSP-Zustandssynchronisierung: Der PCC sendet Informationen über alle LSPs (lokal und extern) an alle angeschlossenen PCEs. Bei externen LSPs sendet das PCC Informationen zu Konfigurationsänderungen, RRO-Änderungen, Statusänderungen und so weiter an das PCE.

    Bei PCE-initiierten LSPs ist keine LSP-Konfiguration auf dem PCC vorhanden. Der PCE, der den LSP initiiert, sendet die LSP-Parameter an die PCC, die seine Fähigkeit zur Unterstützung von PCE-initiierten LSPs angegeben hat.

    Anmerkung:

    Unterstützung für PCE-initiierte LSPs wird in Version 13.3 Junos OS neueren Versionen bereitgestellt.

  2. LSP-Delegation: Nachdem die LSP-Statusinformationen synchronisiert wurden, delegiert das PCC die externen LSPs an ein PCE, das hauptaktive stateful PCE. Nur der Haupt-PCE kann Parameter für den externen LSP festlegen. Die Parameter, die von dem Haupt-PCE ändert werden, umfassen Bandbreite, Pfad (ERO) und Priorität (Einrichtung und Hold). Die in der lokalen Konfiguration angegebenen Parameter werden durch die vom Haupt-PCE festgelegten Parameter überschrieben.

    Anmerkung:

    Wenn die PCEP-Sitzung mit dem Haupt-PCE beendet wird, wählt die PCC ein neues Haupt-PCE, und alle anderen LSPs auf der zuvor Haupt-PCE werden von der neu verfügbaren Haupt-PCE mitgegründet.

    Im Fall von von PCE initiierten LSPs erstellt das PCC den LSP mithilfe der von der PCE empfangenen Parameter. Die PCC weist dem PCE-initiierten LSP eine eindeutige LSP-ID zu und delegiert den LSP automatisch an das PCE. Ein PCC kann die Delegierung für die von PCE initiierten LSPs für eine aktive PCEP-Sitzung nicht widerrufen.

    Wenn eine PCEP-Sitzung beendet wird, startet die PCC zwei Timer, ohne die von PCE initiierten LSPs sofort zu löschen. Und – um Unterbrechungen der delegation cleanup timeoutlsp cleanup timer Dienste zu vermeiden. Während dieser Zeit kann ein aktives Stateful-PCE die Kontrolle über die von dem ausgefallenen PCE bereitgestellten LSPs erwerben, indem es eine Create-Anforderung für den LSP sendet.

    Die Steuerung über PCE-initiierte LSPs wird am Ablaufdatum der PCC auf das PCC delegation cleanup timeout um- Wenn das System abläuft und kein anderes PCE die Kontrolle über den LSP von einem fehlerhaften PCE übernommen hat, übernimmt das PCC die lokale Kontrolle über den delegation cleanup timeout nicht-beendeten PCE-initiierten LSP. Wenn das Original-PCE oder ein neuer aktiver PCE später die Kontrolle über die lokal gesteuerten PCE-initiierten LSPs übernehmen möchte, delegiert das PCC diese LSPs an das PCE und der Timer wird lsp cleanup timer beendet.

    Ein PCE kann die Delegation des PCE-initiierten LSP an die PCC zurücksenkt, um die LSP-Übertragung zwischen PCEs zu ermöglichen. Dies löst den lsp cleanup timer von PCE initiierten LSP aus. Das PCC wartet darauf, dass der LSP-Bereinigungs-Timer abläuft, bevor die nicht-nicht-gleichzeitig von PCE initiierten LSPs von dem ausgefallenen PCE entfernt werden.

    Wenn das System abläuft und kein anderes PCE die Kontrolle über die LSPs vom fehlerhaften PCE übernommen hat, löscht das PCC alle vom ausgefallenen PCE bereitgestellten lsp cleanup timer LSPs.

    Anmerkung:

    In Übereinstimmung mit draft-ietf-pce-stateful-pce-09erfolgt der Aufruf von PCE-initiierten LSP-Entscheidungen durch ein PCC make-before-break, bevor die LSPs zu einem alternativen PCE umgesteigert werden. Beginnend mit Junos OS Veröffentlichungsversion 18.1R1, muss der größer oder gleich sein, damit der PCC den lsp-cleanup-timerdelegation-cleanup-timeout LSP-Rechte für sich widerrufen kann. Wenn nicht, kann das Timeout-Zeitintervall für die Erneute Eingabe des PCC auf 2000 gesetzt werden. Die LSP-Werte bleiben in diesem PCE intakt, bis das PCC bestimmte Maßnahmen ergriffen hat, um die von PCE festgelegten Parameter zu ändern.

  3. LSP-Signalübertragung: Wenn ein oder mehrere LSP-Parameter vom hauptaktiven Stateful PCE empfangen werden, signalisiert das PCC den TE LSP basierend auf dem bereitgestellten PCE-Pfad. Wenn das PCC den LSP nicht startet, benachrichtigt es den PCE des Einrichtungsfehlers und wartet, bis das Haupt-PCE neue Parameter für diesen LSP anschlägt, und meldet ihn erneut.

    Wenn das PCE einen unvollständigen oder losen Hop angibt, in dem nur die Pfadendpunkte angegeben sind, führt PCC kein lokales constraintbasiertes Routing durch, um den vollständigen Satz von Hops herauszufinden. Stattdessen stellt das PCC RSVP den von PCE bereitgestellten Pfad für die Signalübertragung zur Verfügung, und der Pfad wird mithilfe von Hop-by-Hop-Routing IGP eingerichtet.

In Berücksichtigung der hier verwendeten Topologie wird die Abbildung 2Abbildung 4 teilweise clientseitige PCE-Implementierung im RSVP-TE-fähigen Netzwerk der MPLS veranschaulicht. Die ingress-Router A und G sind die PCCs, die für die Verbindung mit einem externen Stateful-PCE über eine TCP-Verbindung konfiguriert sind.

Der PCE verfügt über eine globale Ansicht des Bandbreitenbedarfs im Netzwerk und führt externe Pfadberechnungen durch, nachdem die Traffic-Engineering-Datenbank durchdrungen ist. Der aktive stateful PCE ändert dann ein oder mehrere LSP-Attribute und sendet eine Aktualisierung an das PCC. Das PCC verwendet die Parameter, die es vom PCE empfängt, um den LSP erneut zu signalisieren.

Abbildung 4: Beispiel-PCE für MPLS RSVP-TE Beispiel-PCE für MPLS RSVP-TE

Auf diese Weise bietet das Stateful-PCE einen kooperativen Betrieb verteilter Funktionen zur Bewältigung bestimmter Herausforderungen bei einer Interdomain-Eingeschränkten Pfadberechnung mit kürzester Kapazität. Damit werden Engpässe eliminiert, in denen Datenverkehrsströme ineffizient auf verfügbare Ressourcen abgebildet werden. Dies führt zu einer Überauslastung einiger Teilgruppen von Netzwerkressourcen, während andere Ressourcen nicht ausgelastet sind.

LSP-Verhalten mit externem Computing

LSP-Typen

In einer clientseitigen PCE-Implementierung gibt es drei Arten von TE LSPs:

  • CLI LSPs: LSPs, für die keine Anweisung konfiguriert ist, werden als lsp-external-controller pccd CLI-gesteuerte LSPs bezeichnet. Obwohl diese LSPs unter lokaler Kontrolle stehen, aktualisiert der PCC die angeschlossenen PCEs während der ersten LSP-Synchronisierung mit Informationen über die CLI-gesteuerten LSPs. Nach der ersten LSP-Synchronisierung informiert der PCC den PCE auch über neue und gelöschte LSPs.

  • PCE-gesteuerte LSPs: Die LSPs mit der Anweisungseinstellung werden lsp-external-controller pccd PCE-gesteuerte LSPs genannt. Die PCC delegiert die von PCC initiierten LSPs zur externen Pfadberechnung an die Haupt-PCE.

    Das PCC informiert den PCE über die konfigurierten Parameter eines PCE-gesteuerten LSP, wie Bandbreite, ERO und Prioritäten. Darüber hinaus informiert der PCE über die tatsächlichen Werte, die für diese Parameter zum Einrichten des LSP einschließlich des RRO verwendet werden, wenn vorhanden.

    Das PCC sendet solche LSP-Statusberichte nur dann an das PCE, wenn eine Neukonfiguration eintrat oder eine Änderung in den ERO, RRO oder dem Status der PCE-gesteuerten LSPs mit externer Steuerung erfolgt.

    Es gibt zwei Arten von Parametern, die aus der CLI eines LSP für ein PCE stammen:

    • Parameter, die nicht durch ein PCE gelöscht werden und umgehend angewendet werden.

    • Parameter, die durch ein PCE überschrieben werden. Diese Parameter umfassen Bandbreite, Pfad und Priorität (Einrichtung und Hold-Werte). Wenn die Switches des Steuerungsmodus von extern auf lokal umschalten, werden die CLI konfigurierten Werte für diese Parameter bei der nächsten Gelegenheit angewendet, um den LSP neu zu signalisieren. Die Werte werden nicht sofort angewandt.

  • Von außen bereitgestellte LSPs (oder PCE-initiierte LSPs): Die LSPs mit der Konfiguration der Anweisung werden lsp-provisioning PCE-initiierte LSPs genannt. Ein PCE-initiiertes LSP wird dynamisch von einem externen PCE erstellt. daher ist keine LSP-Konfiguration auf der PCC vorhanden. Das PCC erstellt den von PCE initiierten LSP mit den vom PCE bereitgestellten Parametern und delegiert den LSP automatisch an das PCE.

    Anmerkung:

    Unterstützung für PCE-initiierte LSPs wird in Version 13.3 Junos OS neueren Versionen bereitgestellt.

Die CLI LSPs, PCE-gesteuerte LSPs und PCE-initiierte LSPs können auf einem PCC koexistieren.

Die CLI LSPs mit PCE-gesteuerten und PCE-gesteuerten LSPs können auf einem PCC koexistieren.

LSP-Steuerungsmodus

In einer PCE-Implementierung auf der Clientseite gibt es zwei Arten von Steuerungsmodi für einen PCC-gesteuerten LSP:

  • Extern: Standardmäßig werden alle PCE-gesteuerten LSPs einer externen Kontrolle übertragen. Wenn ein LSP einer externen Steuerung steht, verwendet das PCC die von PCE bereitgestellten Parameter zur Einrichtung des LSP.

  • Lokal: Ein PCE-gesteuerter LSP kann vor Ort kontrolliert werden. Wenn die LSP-Switches von der externen Steuerung zur lokalen Steuerung umschalten, wird die Pfadberechnung mithilfe von konfigurierten Parametern CLI und constraint-basiertem Routing durchgeführt. Ein solcher Switchover erfolgt nur, wenn ein Trigger besteht, um den LSP erneut zu signalisieren. Bis zu diesem Punkt verwendet das PCC die von PCE bereitgestellten Parameter, um den PCE-gesteuerten LSP zu signalisieren. Der LSP bleibt jedoch weiterhin unter lokaler Steuerung.

Ein PCE-gesteuerter LSP-Switch wird vom externen Standardsteuerungsmodus auf die lokale Steuerung umgestellt, wenn beispielsweise keine Verbindung zu einem PCE erfolgt oder wenn ein PCE die Übertragung von LSPs zurück zum PCC zurückgibt.

Weitere Informationen über CLI LSPs und PCE-gesteuerte LSPs finden Sie LSP-Typen unter.

Von externem Computing unterstützte Konfigurationserklärungen

Tabelle 1 Listen Sie den MPLS und vorhandene LSP-Konfigurationserklärungen auf, die für einen PCE-gesteuerten LSP gelten.

Tabelle 1: Anwendbarkeit von MPLS und vorhandenen LSP-Konfigurationen auf einen PCE-gesteuerten LSP

Unterstützung für PCE-gesteuerten LSP

Geltende LSP-Konfigurationserklärungen

Zutreffende MPLS Konfigurationserklärungen

Diese Konfigurationseinstellungen können zusammen mit der PCE-Konfiguration konfiguriert werden. Sie wirken sich jedoch nur dann aus, wenn die lokale Konfiguration verwendet wird. Während der PCE-Steuerung bleiben diese Konfigurationseinstellungen inaktiv.

  • Admin-Gruppe

  • automatische Bandbreite

  • Hop-Limit

  • am wenigsten füllende

  • meistfüllte

  • Zufällige

  • Admin-Gruppe

  • Admin-Gruppen

  • Admin Group – erweitert

  • Hop-Limit

  • no-cspf

  • Intelligente Timer-Optimierung

Diese Konfigurationseinstellungen können zusammen mit der PCE-Konfiguration konfiguriert werden, werden aber durch die PCE-gesteuerten LSP-Attribute außer Kraft gesetzt. Wenn jedoch die lokale Konfiguration verwendet wird, werden die konfigurierten Werte für diese Konfigurationserklärungen angewendet.

Anmerkung:

Änderungen an der lokalen Konfiguration mithilfe des CLI während der LSP von einem zustands behafteten PCE kontrolliert wird, haben keine Auswirkungen auf den LSP. Diese Änderungen werden nur bei Anwendung der lokalen Konfiguration umgesetzt.

  • Bandbreite

  • primary

  • Priorität

  • Priorität

Diese Konfigurationseinstellungen können nicht zusammen mit der PCE-Konfiguration konfiguriert werden.

  • p2mp

  • Vorlage

  • p2mp-lsp-next-hop

Der Rest der LSP-Konfigurationserklärungen ist genauso anwendbar wie für vorhandene LSPs. Beim Konfigurieren einer der oben genannten Konfigurationserklärungen für einen PCE-gesteuerten LSP wird eine Protokollnachricht MPLS generiert, die ankning, wenn die konfigurierten Parameter in Kraft treten.

PCE-gesteuerter LSP-Schutz

Die Schutzpfade, einschließlich Fast Reroute und Bypass-LSPs, werden von der PCC lokal über einschränkungsbasiertes Routing berechnet. Ein zustandsbehaftete PCE gibt nur den primären Pfad (ERO) an. Ein PCE kann auch einen nicht Standby-sekundären Pfad auslösen, auch wenn die lokale Konfiguration nicht über einen nicht Standby-sekundären Pfad zum LSP-Schutz verfügt.

PCE-gesteuerter LSP-ERO

Für PCE-gesteuerte LSPs (PCC-ührige LSPs und PCE-initated LSPs) muss nur ein komplettes ERO-Objekt (Explicit Route Object) vom PCE an das PCC gesendet werden. andernfalls wird die PCUpdate- oder PCCreate-Nachricht für diese PCEP-Sitzung abgelehnt.

Ab Version Junos OS 17.2 werden zusätzlich zwei neue Pfadberechnungstypen für external cspf PCE-gesteuerte LSPs eingeführt: local cspf und no cspf .

  • local cspf— Ein PCC verwendet den Berechnungstyp nur, wenn das PCE einen serverspezifischen TLV Juniper local cspf sendet (Unternehmensnummer: 0x0a4c) typ 5.

  • no cspf- Weder PCE noch PCC führt eine Pfadberechnung mit eingeschränkten Pfaden durch. Die Endpunkte und Beschränkungen werden an das RSVP-Modul für die Einrichtung des LSP mit dem IGP gehen.

    Ein PCC verwendet no cspf in den folgenden Fällen den Berechnungstyp:

    • Wenn das PCE TLV sendet und wenn die Konfigurations Junos OS oder entsprechende Vorlage für diese LSP im local cspfno-cspf PCC-unterstützten LSP enthalten ist.

    • Wenn das PCE TLV sendet und wenn die Junos OS Konfigurationsvorlage für diesen LSP im local cspfno-cspf PCE-initiierten LSP enthalten ist.

    • Wenn das PCE TLV nicht mit einem leeren ERO oder losem ERO (mit losem Bitsatz im local cspf ERO-Objekt) sendet.

Bei diesen neuen Berechnungstypen kann ein PCC ein ERO-Objekt entweder als losen ERO oder als leerer ERO akzeptieren. Eine externe Path-Computing-Einheit, die nicht in der Lage ist, einen Pfad zu erstellen, kann anhand der Analyse Parameter wie Bandbreite und Farbe ändern. In solchen Fällen wird ein leeres ERO-Objekt oder ein loses ERO verwendet, und der zu wählende Pfad wird durch das PCC entschieden.

PCE-gesteuerte Point-to-Multipoint RSVP-TE-LSPs

Nachdem eine PCEP-Sitzung zwischen einem PCE und einem PCC eingerichtet wurde, meldet das PCC alle LSPs im System dem PCE für die LSP-Zustandssynchronisierung. Dazu gehören PCC-gesteuerte, PCE-gesteuerte und PCE-initiierte Point-to-Point-LSPs. Beginnend mit Junos OS Release 15.1F6 und 16.1R1 wird diese Funktion auch auf Point-to-Multipoint-LSPs ausgeweitet. In einem PCE ist der Point-to-Multipoint LSP vergleichbar mit dem RSVP Point-to-Multipoint LSP, in dem der Point-to-Multipoint LSP wie eine Sammlung von Point-to-Point-LSPs behandelt wird, die zu einer Point-to-Multipoint-Kennung gruppieren.

Standardmäßig wird die PCE-Steuerung von Point-to-Multipoint-LSPs auf einer PCC nicht unterstützt. Um diese Funktion hinzuzufügen, fügen Sie die p2mp-lsp-report-capability Anweisung auf den oder [edit protocols pcep pce pce-name][edit protocols pcep pce-group group-id] Hierarchieebenen hinzu. Nachdem die Point-to-Multipoint-Berichtsfunktion auf einer PCC konfiguriert wurde, gibt PCC diese Funktion auf dem PCE aus. Wenn das PCE dieselbe Point-to-Multipoint-Berichtfunktion im Gegenzug ankläbt, meldet das PCC dem PCE für die LSP-Zustandssynchronisierung das vollständige Point-to-Multipoint-LSP-Tree an das PCE.

Ein PCC mit der Point-to-Multipoint TE-LSP-Funktion unterstützt die Berichterstellung von Point-to-Multipoint TE-LSPs für zustandsbehaftete PCEs, Point-to-Multipoint-Aktualisierung und die LSP-Datenbank, die den Point-to-Multipoint LSP-Namen als Schlüssel unterstützt. Folgende Funktionen werden für Version Junos OS 15.1F6 16.1 jedoch nicht unterstützt:

  • Statische Point-to-Multipoint-LSPs

  • PCE-orientierte und PCE-initiierte Point-to-Multipoint-LSPs

  • Automatische Bandbreite

  • TE++

  • PCE-Anfrage und Antwortnachricht

  • Erstellen von Point-to-Multipoint-LSPs mit Vorlagen

  • Konfigurieren eines Vorwärtseinstiegs auf den von PCE initiierten Point-to-Multipoint-LSPs

  • Konfigurieren eines Forward-Eintrags auf dem Router, der auf einen bereitgestellten LSP verweisen kann

PCE-initiierte Point-to-Point-LSPs

Beginnend mit Junos OS Version 16.1 wird die PCEP-Funktion erweitert, um ein stateful PCE zu ermöglichen, Traffic Engineering-LSPs über eine PCC zu initiieren und zu provisionieren. Früher wurden die LSPs auf dem PCC konfiguriert, und die PCC-Überwachung übernimmt die Kontrolle externer LSPs zu einem PCE. Die Eigentümer des LSP-Status wurden von der PCC verwaltet. Mit der Einführung der von PCE initiierten LSPs kann ein PCE dynamisch einen Traffic-Engineering-Point-to-Point-LSP initiieren und bereitstellen, ohne einen lokal konfigurierten LSP auf dem PCC zu benötigen. Beim Empfang einer PCCreate-Nachricht von einem PCE erstellt das PCC den PCE-initiierten LSP und delegiert den LSP automatisch an das PCE.

Standardmäßig lehnt ein PCC die Anfrage zur Bereitstellung von PCE-initiierten Punkt-zu-Punkt-LSPs von einem PCE ab. Um die Unterstützung von PCE-initierten LSPs auf der PCC zu ermöglichen, schließen Sie die lsp-Provisioning-Anweisung auf den oder [edit protocols pcep pce pce-id][edit protocols pcep pce-group group-id] Hierarchieebenen ein.

Ein PCC gibt an, dass es PcE-initiierte Punkt-zu-Punkt-LSPs unterstützt und gleichzeitig die Path Computation Element Protocol (PCEP)-Sitzung mit dem PCE eingibt. Ein PCE wählt ein PCC mit dieser Funktion aus, um einen LSP zu initiieren. Der PCE stellt dem PCC die PCE-initiierten LSP-Parameter zur Hand. Beim Empfang der von PCE initiierten Punkt-zu-Punkt-LSP-Parameter richtet das PCC die LSP ein, weist eine LSP-ID zu und delegiert den LSP automatisch an das PCE.

Wenn der PCE, der den LSP initiiert, keine Point-to-Point-LSP-Parameter für PCE bereitstellen, verwendet das PCC die Standardparameter. Eine optionale LSP-Vorlage kann auch so konfiguriert werden, dass Werte für den vom PCE initiierten Punkt-zu-Punkt-LSP angegeben werden, wenn die LSP-Parameter nicht vom PCE bereitgestellt werden. Um eine LSP-Vorlage für von PCE initiierte Point-to-Point-LSPs auf dem PCC zu konfigurieren, fügen Sie die Label-Switched-Path-Template-Anweisung auf der [edit protocols mpls lsp-external-controller lsp-external-controller] Hierarchieebene ein.

Nach Beenden einer PCEP-Sitzung startet die PCC zwei Timer, ohne die von PCE initiiertenLSPs sofort zu löschen. Und — um delegation cleanup timeoutlsp cleanup timer Serviceunterbrechungen zu vermeiden. Während dieser Zeit kann ein aktives Stateful-PCE die Kontrolle über die durch das ausgefallene PCE bereitgestellten LSPs übernehmen.

Ein PCE kann die Delegierung des PCE-initiierten Point-to-Point-LSP an das PCC zurückkehren, um die LSP-Übertragung zwischen PCEs zu ermöglichen. Die Steuerung über PCE-initiierte LSPs wird am Ablaufdatum der Bereinigungszeit auf das PCC um- Wenn die Delegierungs-Bereinigung abläuft und kein anderes PCE die Kontrolle über den LSP von einem ausgefallenen PCE übernommen hat, übernimmt die PCC die lokale Kontrolle des nicht-übernommenen PCE-initiierten LSP. Später, wenn das Original oder ein neues aktives pcful PCE die Kontrolle über die lokal gesteuerten PCE-initiierten Point-to-Point-LSPs übernehmen möchte, delegiert das PCC diese LSPs an das PCE und der LSP-Bereinigungs-Timer wird beendet.

Das PCC wartet darauf, dass der LSP-Bereinigungs-Timer abläuft, bevor er die nicht-ungunserweckten, von PCE initiierten Punkt-zu-Punkt-LSPs von dem ausgefallenen PCE entfernt wird. Wenn der LSP-Bereinigungszeitpunkt abläuft und kein anderes PCE die Kontrolle über die LSPs des ausgefallenen PCE übernommen hat, löscht das PCC alle vom ausgefallenen PCE bereitgestellten LSPs.

Wir unterstützen Junos OS 21.1R1 nonstop Active Routing (NSR) für PCE-initiierte RSVP-basierte Point-to-Point- und Point-to-Multipoint-LSPs. Nur der primäre Routing-Engine verwaltet die PCEP-Sitzung mit dem Controller. Er synchronisiert alle von PCEs initiierten RSVP-LSPs, einschließlich Multicast-Datenflussspezifikationen für alle PCE-initiierten P2MP-LSPs mit dem Backup-Routing-Engine. Während eines Switchovers läuft die PCEP-Sitzung aus und stellt sie wieder her, wenn die Backup-Routing-Engine oberster Routing-Engine. So wird der Datenverkehrsverlust bei Datenverkehr, der über PCE-initiierte RSVP-LSPs übertragen wird, während Routing-Engine reduziert. Diese Funktion ist aktiviert, wenn NSR konfiguriert ist.

PCE-initiierter Bypass-LSP

Grundlegende Informationen zu PCE-initiierten Bypass-LSPs

Zum Zeitpunkt eines Verbindungs- oder Knotenausfalls kann es zu Datenverkehrsausfällen kommen, da die Backup-Schutzpfade im Netzwerk nicht genügend Bandbreite zur Handhabung von Datenverkehr haben. In solchen Netzwerken kann ein PCE für die Berechnung aller Pfade und die Optimierung der Netzwerkleistung verwendet werden. Allerdings müssen auch die lokalen Schutzpfade über das PCE gesteuert werden.

Junos OS Release 19.2R1 und neuere Versionen bieten teilweise Unterstützung für Internet Draft-cbrt-pce-stateful-local-protection-01 (läuft am Dezember 2018 ab), PCEP-Erweiterungen für RSVP-TE Local-Protection mit PCE-Stateful,wobei die PCEP-Funktionalität erweitert wird, um ein zustandsbezogenes PCE zu ermöglichen, LSPs für eine geschützte Schnittstelle zu initiieren, zu implementieren und zu verwalten. Mehrere Bypass-LSPs mit Bandbreitenreservierung können vom PCE initiiert werden, um eine Verbindung oder einen Knoten zu schützen. Es wird erwartet, dass die Bandbreite des Bypass-LSP geringer ist als die Gesamtbandbreite der primären LSPs, die geschützt werden könnten.

Der vorhandene Bypass-Auswahlmechanismus, der manuelle Bypass-LSPs (falls vorhanden) über dynamische Bypass-LSPs bevorzugt, wird auf pcE-bereitgestellte Bypass-LSPs (falls vorhanden) gegenüber dynamischen Bypass-LSPs erweitert. Die über PCE bereitgestellten Bypass-LSPs haben eine höhere Präferenz gegenüber dynamischen Bypass-LSPs, sind jedoch weniger bevorzugt als manuelle Bypass-LSPs.

Die Abläufe, die für alle betrieblichen Bypass-LSPs ausgeführt werden, wie etwa, können auch auf den clear rsvp session PCE-initiierten Bypass-LSPs ausgeführt werden. Sie können Befehle wie show path-computation-client status extensiveshow path-computation-client lsp PCE-initiierte Umgehung von LSP-Statistiken verwenden und diese anzeigen.

Mit Unterstützung von PCE-initiierten Bypass-LSP können Sie:

  • Von einem externen Controller einen RSVP-Bypass-LSP durch PCEP erstellen, wobei der Bypass-LSP:

    • zum Schutz von Verbindungen oder Knoten verwendet werden.

    • nicht-Null-Bandbreite haben.

    • einen festgelegten, strengen ERO haben.

  • Aktualisieren Sie die Bandbreite und den ERO für einen vorhandenen PCE-erstellten Bypass-LSP.

  • Überbeschriftet den Bypass-LSP-Bandbreite für die Zugangskontrolle der primären LSPs. Dabei muss es sich um Einen Parameter pro Bypass geben und die Aktualisierung des Abonnement für einen Bypass-LSP ermöglichen.

Vorteile von PCE-initiierten Bypass-LSP

Die VON PCE initiierten Bypass-LSPs bieten die folgenden Vorteile:

  • Bessere Kontrolle des Datenverkehrs nach einem Ausfall und deterministischere Pfadberechnung von Schutzpfaden.

  • Erfüllung komplexer Einschränkungen und Vielfältiger Anforderungen, wie die Aufrechterhaltung unterschiedlicher Pfade für LSPs und ihre lokalen Schutzpfade.

  • Stellen Sie sicher, dass die Verbindungen bei Ausfällen nicht überlastet sind.

Verhalten von PCE-initiierten Bypass-LSPs während Fehler bei PCEP-Sitzungen

Zum Zeitpunkt eines Fehlers einer PCEP-Sitzung werden die von PCE initiierten Bypass-LSPs bis zum Ablaufdatum des State Timeout-Timers in barem Zustand aufgenommen. Die PCE-initiierten Bypass-LSPs werden am Ablaufdatum des State Timeout-Timers bereinigt. Um die Kontrolle eines PCE-initiierten Bypass-LSP (nach einem Fehler der PCEP-Sitzung) zu erhalten, sendet ein PCE (entweder das primäre PCE oder ein sekundäres PCE) eine PCInitiate-Nachricht vor dem Ablaufdatum des State Timeout-Timer.

PCE-initiierte Point-to-Multipoint-LSPs

Mit der Einführung von von Point-to-Multipoint PCE initiierten LSPs kann ein PCE dynamisch einen Point-to-Multipoint-LSP initiieren und bereitstellen, ohne dass auf dem PCC eine lokale LSP-Konfiguration erforderlich ist. So kann das PCE die Zeitsteuerung und Abfolge der Point-to-Multipoint-Pfadberechnungen innerhalb und über Path Computation Element Protocol (PCEP)-Sitzungen hinweg steuern und so ein dynamisches Netzwerk erstellen, das zentral gesteuert und bereitgestellt wird.

Weitere Informationen finden Sie unter Understanding Path Computation Element Protocol for MPLS RSVP-TE with Support for PCE-Initiated Point-to-Multipoint LSPs (Verstehen des Pfadberechnungselementprotokolls für MPLS RSVP-TE mit Unterstützung für PCE-initiierte Point-to-Multipoint-LSPs.

Automatische Bandbreite und PCE-gesteuerter LSP

Beginnend im Junos OS Release 14.2R4 Unterstützung automatischer Bandbreite für PCE-gesteuerte LSPs. In früheren Versionen gilt die Option mit automatischer Bandbreite nicht für PCE-gesteuerte LSPs, obwohl LSPs, die von Auto-Bandwdith und Constraint-basiertem Routing kontrolliert werden, mit PCE-gesteuerten LSPs koexistieren könnten. Die Erfassung von Statistiken für die automatische Bandbreite wurde nur dann wirksam, wenn der Steuerungsmodus eines PCE-gesteuerten LSP von einem externen zum lokalen geändert wurde. Dies geschieht beispielsweise ohne Verbindung mit einem PCE oder wenn ein PCE die Übertragung von LSPs zurück zum PCC wiedergibt.

TCP-MD5-Authentifizierung für PCEP-Sitzungen

Ein Stateful PCE-Server automatisiert die Erstellung von netzwerkübergreifenden Traffic-Engineering-Pfaden, wodurch die Netzwerknutzung verbessert und eine angepasste programmierbare Netzwerkerfahrung durch die Verwendung von PCEP-Kommunikation mit einem PCC ermöglicht wird. Ein PCC sendet LSP-Berichte an einen PCE-Server, und die PCE-Updates oder stellt LSPs zurück an das PCC bereit. Die Daten, die über eine PCEP-Sitzung gesendet werden, sind für die Durchführung eines externen Path Computing durch einen PCE-Server entscheidend. Daher kann ein Angriff auf die PCEP-Kommunikation die Netzwerkservices unterbrechen. Wenn geänderte PCEP-Nachrichten an eine PCC gesendet werden, können unangemessene LSPs eingerichtet werden. Wenn geänderte PCEP-Nachrichten an ein PCE gesendet werden, lernt das PCE in ähnlicher Weise eine falsche Ansicht des Netzwerks.

Da die PCEP-Kommunikation zwischen PCE und PCC bei der effektiven Ausführung der PCE-Funktionen von Junos OS sehr wichtig ist, bietet Version 16.1 die Funktionen zur Sicherung einer PCEP-Sitzung mithilfe der TCP-MD5-Authentifizierung gemäß RFC 5440. Diese Funktion schützt die Kommunikation zwischen einem PCE und PCC über eine PCEP-Sitzung, die möglicherweise angegriffen wird und die Netzwerkservices unterbrechen kann.

Um den MD5-Sicherheitsmechanismus für eine PCEP-Sitzung zu aktivieren, wird empfohlen, den MD5-Authentifizierungsschlüssel auf Hierarchieebene für eine PCEP-Sitzung zu definieren und [edit protocols pcep pce pce-id] zu binden. Sie können jedoch auch eine vordefinierte Keychain von der Hierarchieebene verwenden, [edit security authentication-key-chains key-chain] um eine PCEP-Sitzung zu sichern. In diesem Fall sollten Sie die vordefinierte Keychain auf der Hierarchieebene in die PCEP-Sitzung [edit protocols pcep pce pce-id] binden.

Die folgende Konfiguration wird auf der PCC ausgeführt, um eine sichere PCEP-Sitzung mit einem PCE zu erstellen:

  • Verwenden des MD5-Authentifizierungsschlüssels:

  • Verwendung einer vordefinierten Authentifizierungs-Keychain:

Damit sichere PCEP-Sitzungen erfolgreich eingerichtet werden können, sollte die MD5-Authentifizierung mit dem vorinstallierten Authentifizierungsschlüssel sowohl auf dem PCE-Server als auch auf dem PCC konfiguriert werden. PCE und PCC verwenden denselben Schlüssel, um die Authentizität jedes Segments zu überprüfen, das an die TCP-Verbindung der PCEP-Sitzung gesendet wird.

Anmerkung:
  • Junos OS Version 16.1 unterstützt nur die TCP-MD5-Authentifizierung für PCEP-Sitzungen, ohne die Unterstützung von TLS und TCP-AO, wie z. B. Schutz vor Abhören, Manipulation und Nachrichtenverdrungen, zu erweitern.

  • Die anfängliche Anwendung des Sicherheitsmechanismus auf eine PCEP-Sitzung bewirkt, dass die Sitzung zurückgesetzt wird.

  • Wenn MD5 auf einer Seite der PCEP-Sitzung falsch konfiguriert oder nicht konfiguriert ist, wird die Sitzung nicht eingerichtet. Stellen Sie sicher, dass die Konfigurationen auf PCC und PCE übereinstimmen.

  • Diese Funktion unterstützt keine Sitzungsauthentifizierungsverfahren.

  • Verwenden Sie die Und-Befehlsausgänge, um die von der PCEP-Sitzung verwendete Authentifizierungs-Keychain show path-computation-client statusshow protocols pcep anzuzeigen.

  • Verwenden Sie den Befehl, um die Anzahl der Pakete zu anzeigen, die aufgrund von Authentifizierungsfehlern durch show system statistics tcp | match auth TCP verworfen werden.

  • Die Funktionsweise der Keychain kann mithilfe der show security keychain detail Befehlsausgabe verifiziert werden.

Auswirkung der Client-Side-PCE-Implementierung auf die Netzwerkleistung

Die Verwaltung einer zustandsorientierten Datenbank kann nicht einfach sein. In einer einzigen zentralisierten PCE-Umgebung muss ein Stateful-PCE einfach nur alle TE-LSPs, die für das PCE berechnet wurden, die tatsächlich eingerichteten TE-LSPs (falls dies bekannt ist) und an den Abbruch der TE-LSPs erinnern. Diese Anforderungen verursachen jedoch einen erheblichen Steuerungsprotokoll-Aufwand in Bezug auf Status, Netzwerknutzung und -verarbeitung sowie die Optimierung von Verbindungen global im gesamten Netzwerk. Die Probleme einer zustandsbehafteten PCE-Implementierung umfassen daher Folgendes:

  • Jeder zuverlässige Synchronisierungsmechanismus führt zu erheblichem Overhead auf der Steuerungsebene. PCEs können den Status synchronisieren, indem sie miteinander kommunizieren. Wenn die TE-LSPs mit verteilten, für mehrere PCs durchgeführten Berechnungen eingerichtet werden, werden die Probleme der Synchronisierung und Race-Bedingungsvermeidung größer und komplexer.

  • Out-of-Band-Traffic-Engineering-Datenbanksynchronisierung kann komplex sein, mit mehreren PCEs, die in einem verteilten PCE-Berechnungsmodell eingerichtet sind, und kann anfällig für Race-Bedingungen, Skalierbarkeitsbedenken und so weiter sein.

  • Die Berechnung des Pfads, auf dem der gesamte Netzwerkstatus berücksichtigt wird, ist sehr komplex, auch wenn die PCE detaillierte Informationen zu allen Pfaden, Prioritäten und Schichten auf dem PCE bietet.

Trotz der oben genannten Bedenken ist die teilweise clientseitige Implementierung des zustandsbehafteten PCE in großen Traffic-Engineering-Systemen extrem effektiv. Sie bietet schnelle Konvergenz und erhebliche Vorteile im Hinblick auf eine optimale Ressourcennutzung, da globale Visibilität des TE-LSP-Status und geordnete Kontrolle von Pfadreservierungen zwischen Geräten innerhalb des Systems, das kontrolliert wird, erforderlich sind.

Beispiel: Konfigurieren des Path Computation Element Protocol für MPLS RSVP-TE

In diesem Beispiel wird gezeigt, wie ein externes Path Computing durch ein Path Computation Element (PCE) für Traffic Engineered Label Switched Paths (TE LSPs) auf einem Path Computation Client (PCC) ermöglicht wird. Darüber hinaus wird gezeigt, wie das Path Computation Element Protocol (PCEP) auf der PCC konfiguriert wird, um PCE zu PCC-Kommunikation zu ermöglichen.

Anforderungen

In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:

  • Drei Router, die aus routern der ACX-Serie, den M Series Multiservice Edge-Routern, 5G Universelle Routing-Plattformen der MX-Serie, den T-Serie Core-Routern oder einem Transportrouter der PTX-Serie, von denen einer als PCC konfiguriert ist, kombiniert werden können.

  • Eine TCP-Verbindung zu einem externen Stateful-PCE vom PCC.

  • Junos OS Version 12.3 oder höher auf dem PCC zusammen mit dem JSDN-Add-on-Paket ausgeführt.

Anmerkung:

Das Add-on-Paket JSDN muss zusammen mit dem Core-Installationspaket Junos OS installiert werden.

Bevor Sie beginnen:

  1. Konfigurieren Sie die Geräteschnittstellen.

  2. Konfiguration MPLS und RSVP-TE.

  3. Konfigurieren IS-IS oder eines anderen IGP Protokolls.

Überblick

Beginnend mit Junos OS Version 12.3 wird die MPLS RSVP-TE-Funktionalität erweitert, um eine partielle clientseitige Implementierung der stateful PCE-Architektur (draft-ietf-pce-stateful-pce) auf einem PCC zur Verfügung zu stellen.

Anmerkung:

Die teilweise clientseitige Implementierung der Stateful PCE-Architektur basiert auf Version 2 des Internet Draft-ietf-pce-stateful-pce. Diese Implementierung beginnt mit Junos OS Version 16.1 und wird auf die in Internet draft-ietf-pce-stateful-pce-07 definierte Unterstützung der Version 7 aktualisiert. Versionen vor Version 16.1 unterstützen die ältere Version des PCE-Draft. Dies verursacht Interoperabilitätsprobleme zwischen einem PCC, auf dem eine vorherige Version ausgeführt wird, und einem Stateful PCE-Server, der den Internet draft-ietf-pce-stateful-pce-07 entspricht.

Um ein externes Path Computing durch ein PCE zu ermöglichen, geben Sie die Anweisung auf der PCC auf den lsp-external-controller und [edit mpls][edit mpls lsp lsp-name] Hierarchieebenen ein.

Ein mit der Anweisung konfigurierter LSP wird standardmäßig als PCE-gesteuerter LSP bezeichnet und wird standardmäßig der externen Steuerung eines lsp-external-controller PCE übertragen. Ein aktives Stateful-PCE kann die vom CLI festgelegten Parameter wie Bandbreite, Pfad (ERO) und Priorität für solche PCE-gesteuerten LSPs des PCC überschreiben.

Um PCE für die PCC-Kommunikation zu aktivieren, konfigurieren Sie PCEP auf der PCC auf der [edit protocols] Hierarchieebene.

Beachten Sie bei der PCEP-Konfiguration auf einer PCC die folgenden Überlegungen:

  • Das Add-on-Paket JSDN muss zusammen mit dem Core-Installationspaket Junos OS installiert werden.

  • Junos OS Version 12.3 unterstützt nur Stateful-PCEs.

  • Eine PCC-Verbindung kann mit maximal 10 zustands behafteten PCEs hergestellt werden. Zu jedem Zeitpunkt kann es nur ein Haupt-PCE (das PCE mit dem geringsten Prioritätswert) oder das PCE, das beim Fehlen einer PCE-Priorität zuerst eine PCC-Priorität verbindet, an die der PCC LSPs zur Pfadberechnung delegiert.

  • Für Junos OS Version 12.3 initiiert die PCC immer die PCEP-Sitzungen. PCEP-Sitzungen, die von Remote-PCEs initiiert wurden, werden von der PCC nicht akzeptiert.

  • Vorhandene LSP-Funktionen wie LSP-Schutz und Make-before-Break können für PCE-gesteuerte LSPs verwendet werden.

  • Die Option mit automatischer Bandbreite wird für PCE-gesteuerte LSPs ausgeschaltet. LSPs, die von Auto-Bandwdith und Constraint-basiertem Routing kontrolliert werden, können jedoch mit PCE-gesteuerten LSPs koexistieren.

  • PCE-gesteuerte LSPs können von anderen CLI-Konfigurationen wie lsp-nexthop für Routen, Weiterleitungsbindungen, CCC-Verbindungen und logische Tunnel bezeichnet werden.

  • PCE-gesteuerte LSPs unterstützen GRES nicht.

  • PCE-gesteuerte LSPs in logischen Systemen werden nicht unterstützt.

  • PCE-gesteuerte LSPs können keine Point-to-Multipoint-LSPs sein.

  • Bidirektionale LSPs werden nicht unterstützt.

  • PCE-gesteuerte LSPs können ohne einen primären Pfad keine sekundären Pfade haben.

  • PCE-gesteuerte LSPs sind von einer externen Pfadberechnung abhängig, die sich auf die Gesamteinrichtungszeit, Die Routen und Make-before-Break-Funktionen insgesamt wirkt.

  • Die Einrichtungszeit und Konvergenzzeit (Umleiten, MBB) zum Exisiern von LSPs ist die gleiche wie in früheren Versionen, ohne PCE-gesteuerte LSPs. In PCE-gesteuerten LSPs ist jedoch ein kleinerEr Einfluss zu erkennen.

  • Es wird erwartet, dass die ERO-Berechnungszeit wesentlich höher als die lokale CSPF ist.

Topologie

Abbildung 5: Konfigurieren von PCEP für MPLS RSVP-TEKonfigurieren von PCEP für MPLS RSVP-TE

In diesem Beispiel ist PCC der Ingress-Router, der mit dem externen active stateful PCE verbunden ist.

Die externen LSPs von Router-PCC werden wie folgt berechnet:

  1. Router-PCC empfängt die LSP-Tunnelkonfiguration, die mithilfe des Routers CLI. Wenn die empfangene Konfiguration mit externem Path Computing aktiviert wird, wird Router PCC bewusst, dass einige der LSP-Attribute (Bandbreite, Pfad und Priorität) dem stateful PCE unterstellt sind und den LSP an das PCE delegieren.

    In diesem Beispiel wird der externe LSP aufgerufen und von Router PCC zu PCC-to-R2 Router R2 eingerichtet. Der CLI ERO PCC-to-R2 für PCC-R0-R1-R2. Die Bandbreite für beträgt 10 m und sowohl die Einrichtungs- als auch PCC-to-R2 die Hold-Prioritätswerte beträgt 4.

  2. Router PCC versucht, die PCE-gesteuerten LSP-Attribute abzurufen. Hierzu sendet Router PCC eine PCRpt-Nachricht an das Stateful-PCE, wenn der LSP konfiguriert wurde. Die PCRpt-Nachricht kommuniziert den Status des LSP und enthält die lokalen Konfigurationsparameter des LSP.

  3. Der statusbehaftete PCE ändert einen oder mehrere der anderen LSP-Attribute und sendet die neuen LSP-Parameter über die PCUpd-Nachricht an Router PCC.

  4. Beim Empfang der neuen LSP-Parameter richtet der Router PCC einen neuen LSP ein und gibt ihn über den von PCE bereitgestellten Pfad neu an.

    In diesem Beispiel ist PCC-R3-R2 der von PCE bereitgestellte PCC-to-R2 ERO. Die Bandbreite für beträgt 8 m, und sowohl die Einrichtungs- als auch PCC-to-R2 die Hold-Prioritätswerte sind 3.

  5. Router PCC sendet ein PCRpt mit der neuen RRO an das stateful PCE.

Konfiguration

CLI-Konfiguration

Um dieses Beispiel schnell konfigurieren zu können, kopieren Sie die folgenden Befehle, fügen Sie diese in eine Textdatei ein, entfernen Sie alle Zeilenbrüche, ändern Sie alle Details, die zur Übereinstimmung mit der Netzwerkkonfiguration erforderlich sind, und kopieren Sie die Befehle, und fügen Sie die Befehle CLI der Hierarchieebene [edit] ein.

Pcc

R0

R1

R2

R3

Verfahren

Schritt-für-Schritt-Verfahren

Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zur Navigation in CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus.

So konfigurieren Sie Router-PCC:

Anmerkung:

Wiederholen Sie dieses Verfahren für jeden Juniper Networks-Router in der MPLS-Domäne, nachdem Sie die entsprechenden Schnittstellennamen, Adressen und andere Parameter für jeden Router geändert haben.

  1. Konfigurieren Sie die Schnittstellen.

    Um die MPLS zu aktivieren, fügen Sie die Protokollfamilie an die Schnittstelle ein, sodass die Schnittstelle den eingehenden Datenverkehr nicht MPLS verwerfen kann.

  2. Aktivieren von RSVP auf allen Schnittstellen von Router-PCC, außer der Verwaltungsschnittstelle.

  3. Konfigurieren Sie den Label Switched Path (LSP) von Router-PCC zu Router R2 und aktivieren Sie die externe Steuerung von LSPs über das PCE.

  4. Konfigurieren Sie den LSP von Router-PCC zum Router R2, der über eine lokale Steuerung verfügt und durch die PCE-bereitgestellten LSP-Parameter außer Kraft gesetzt wird.

  5. Aktivieren MPLS auf allen Schnittstellen von Router-PCC, nicht jedoch auf der Verwaltungsschnittstelle.

  6. Konfiguration IS-IS auf allen Schnittstellen von Router-PCC außer auf der Verwaltungsschnittstelle.

  7. Definieren Sie das PCE, mit dem der Router PCC eine Verbindung herstellt, und konfigurieren Sie die IP-Adresse des PCE.

  8. Konfigurieren Sie den Zielport für Router-PCC, der mit einem PCE mit dem TCP-basierten PCEP verbindet.

  9. PCE-Typ konfigurieren.

Ergebnisse

Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie die Befehle show interfacesshow protocols eingeben. Wenn in der Ausgabe nicht die beabsichtigte Konfiguration angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Wenn Sie die Konfiguration des Geräts bereits durchgeführt haben, geben Sie commit sie im Konfigurationsmodus ein.

Überprüfung

Stellen Sie sicher, dass die Konfiguration ordnungsgemäß funktioniert.

Überprüfung des PCEP-Sitzungsstatus

Zweck

Überprüfen Sie den PCEP-Sitzungsstatus zwischen PCE und Router-PCC, wenn der PCE-Status verfügbar ist.

Aktion

Führen Sie im Betriebsmodus den show path-computation-client active-pce Befehl aus.

Bedeutung

Die Ausgabe zeigt Informationen über das aktuelle aktive pcful PCE an, mit dem der Router PCC verbunden ist. Das PCE status Ausgabefeld gibt den aktuellen Status der PCEP-Sitzung zwischen dem PCE und dem Router-PCC an.

Der Status der PCEP-Sitzung ist , was bedeutet, dass die PCEP-Sitzung zwischen den pce1PCE_STATE_UP PCEP-Peers eingerichtet wurde.

Die Statistiken zur Angabe der Anzahl nachrichten, die von Router-PCC an den PCE gesendet werden, um den aktuellen Status von PCRpts LSPs zu melden. Die PCUpdates Statistiken geben die Anzahl an Nachrichten an, die von Router-PCC von der PCE empfangen werden. Die PCUpdates Nachrichten enthalten die modifizierten PCE-Parameter für die PCE-gesteuerten LSPs.

Überprüfung des PCE-gesteuerten LSP-Status, wenn die LSP-Steuerung extern ist

Zweck

Überprüfen Sie den Status des PCE-gesteuerten LSP, vom Router-PCC bis zum Router R2, wenn der LSP einer externen Steuerung überwacht wird.

Aktion

Führen Sie im Betriebsmodus den show mpls lsp name PCC-to-R2 extensive Befehl aus.

Bedeutung

In den Ausgangs- LSPtype und LSP Control Status Ausgabefeldern wird deutlich, dass der LSP extern gesteuert wird. Die Ausgabe zeigt auch ein Protokoll der PCEP-Nachrichten, die zwischen Router-PCC und PCE gesendet werden.

Die PCEP-Sitzung zwischen PCE und Router-PCC ist verfügbar, und Der Router-PCC empfängt die folgenden PCE-gesteuerten LSP-Parameter:

  • ERO (Pfad) – 20.31.4.2 und 20.31.5.2

  • Bandwidth—8Mbps

  • Prioritäten: 3 3 (Einrichtung und Hold-Werte)

Überprüfung des PCE-gesteuerten LSP-Status, wenn LSP-Steuerung lokal ist

Zweck

Überprüfen Sie den Status des PCE-gesteuerten LSP vom Router-PCC bis zum Router R2, wenn die LSP-Steuerung lokal wird.

Aktion

Führen Sie im Betriebsmodus den show mpls lsp name PCC-to-R2 extensive Befehl aus.

Bedeutung

In der Ausgabe zeigt das LSP Control Status Ausgabefeld, dass der LSP vor Ort kontrolliert wird. Obwohl der PCE-gesteuerte LSP lokal kontrolliert wird, verwendet der Router-PCC weiterhin die von PCE bereitgestellten Parameter, bis die nächste Gelegenheit besteht, den LSP erneut zu signalisieren.

Die Ausgabe zeigt jetzt die LSP-Parameter an, die mithilfe des CLI konfiguriert wurden, sowie die von PCE bereitgestellten Parameter, die zum Erstellen des LSP als tatsächlichen verwendeten Wert verwendet werden.

  • Bandbreite – 10 Mbps (Tatsächliche Bandbreite: 8Mbit/s)

  • Prioritäten– 4 4 (tatsächliche Prioritäten 3 3)

Am Trigger zur erneuten Signalübertragung des LSP verwendet der Router PCC die lokalen Konfigurationsparameter, um den PCE-gesteuerten LSP zu erstellen.

Dies Computed ERO ist 20.31.1.2, 20.31.2.2 und 20.31.8.2. Der PCE-gesteuerte LSP wird mithilfe der lokalen Konfigurationsparameter eingerichtet.

Beispiel: Configuring Path Computation Element Protocol for MPLS RSVP-TE with Support of PCE-Initiated Point-to-Point-LSPs (Konfiguration des Pfadberechnungselementprotokolls für MPLS RSVP-TE mit Unterstützung von PCE-initiierten Point-to-Point-LSPs

In diesem Beispiel wird gezeigt, wie der Path Computation Client (PCC) mit der Unterstützung von VON PCE (Path Computation Element) initiierten Traffic-Engineered Point-to-Point Label Switched Paths (LSPs) konfiguriert wird.

Anforderungen

In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:

  • Drei Router, die eine Kombination aus ACX-Serie, Routern M Series MX-Serie oder Routern T-Serie können.

  • Eine TCP-Verbindung zu zwei externen Stateful-PCEs vom Ingress-Router (PCC).

  • Junos OS 16.1 oder höher, die auf PCC ausgeführt wird.

Bevor Sie beginnen:

  • Konfigurieren Sie die Geräteschnittstellen.

  • Konfigurieren MPLS und RSVP-TE (RSVP-Traffic Engineering).

  • Konfigurieren OSPF oder eines anderen IGP Protokolls.

Überblick

Beginnend mit Junos OS Version 16.1 wird die PCEP-Funktion erweitert, um ein stateful PCE zu ermöglichen, Traffic Engineering-LSPs über eine PCC zu initiieren und zu provisionieren. Früher wurden die LSPs auf dem PCC konfiguriert, und die PCC-Überwachung übernimmt die Kontrolle externer LSPs zu einem PCE. Die Eigentümer des LSP-Status wurden von der PCC verwaltet. Mit der Einführung der von PCE initiierten LSPs kann ein PCE dynamisch einen Traffic-Engineering-Point-to-Point-LSP initiieren und bereitstellen, ohne einen lokal konfigurierten LSP auf dem PCC zu benötigen. Beim Empfang einer PCCreate-Nachricht von einem PCE erstellt das PCC den PCE-initiierten LSP und delegiert den LSP automatisch an das PCE.

Wenn Sie die Unterstützung von von PCE initiierten Point-to-Point-LSPs für ein PCC konfigurieren, müssen Sie sich der folgenden Überlegungen bewusst sein:

  • Junos OS Version 13.3 unterstützt nur Stateful-PCEs.

  • Zur Junos OS Version 13.3 initiiert die PCC immer die PCEP-Sitzungen. PCEP-Sitzungen, die von Remote-PCEs initiiert wurden, werden von der PCC nicht akzeptiert.

  • Vorhandene LSP-Funktionen wie LSP-Schutz und Make-before-Break sind für PCE-initiierte LSPs verfügbar.

  • PCE-initiierte LSPs unterstützen keine Graceful Routing-Engine Switchover (GRES).

  • PCE-initiierte LSPs unter logischen Systemen werden nicht unterstützt.

  • Von PCE initiierte LSPs können keine Point-to-Multipoint-LSPs sein.

  • Bidirektionale LSPs werden nicht unterstützt.

  • RSVP-TE für Nicht-Nummer-Links wird nicht unterstützt. Von PCE initiierte LSPs unterstützen nur nummerierte Links.

  • Der PCE, der einen Segment-Routing-LSP gestartet hat, kann die binding Segment ID (SID)-Labels verwenden, die mit nicht-segmentierten LSPs für die Bereitstellung der PCE-initiierten Segment-Routing-LSP-Pfade verbunden sind.

    Beginnend mit Junos OS Release 18.2R1 werden statisch konfigurierte Segment-Routing-LSPs auf dem Ingress-Gerät über eine PCEP-Sitzung einem PCE gemeldet. Diese nicht-vollständigen Segment-Routing-LSPs verfügen möglicherweise über zugehörige SID-Label. Mit dieser Funktion kann der PCE dieses binding SID-Label im Labelstack verwenden, um PCE-initiierte Segment-Routing-LSP-Pfade zu bereitstellen.

Topologie

Abbildung 6: Beispiel PCE-initated Point-to-Point LSP für MPLS RSVP-TEBeispiel PCE-initated Point-to-Point LSP für MPLS RSVP-TE

In diesem Beispiel ist PCC der Ingress-Router, der mit zwei externen Stateful-PCEs verbunden ist: PCE1 und PCE2.

Bei einer neuen Nachfrage initiiert das aktive pcful PCE dynamisch einen LSP, um diese Anforderung zu erfüllen. Da PCC mit der Unterstützung des PCE-initiierten LSP konfiguriert ist, wird die Pfadberechnung auf PCC wie folgt ausgeführt:

  1. Ein PCE sendet eine PCCreate-Nachricht an das PCC, um einen LSP zu initiieren und zu bereitstellen. Das PCC richtet den von PCE initiierten LSP mithilfe der vom PCE empfangenen Parameter ein und delegiert den PCE-initiierten LSP automatisch an das initiierte PCE.

    In diesem Beispiel ist PCE1 ein aktiver pcful PCE, der den PCE-initiierten LSP auf PCC initiiert und einschlägig. Beim Empfang der PCE-initiierten LSP-Parameter richtet PCC den LSP ein und delegiert den PCE-initiierten LSP automatisch an PCE1.

  2. Wenn die PCEP-Sitzung zwischen PCC und PCE1 beendet wird, startet PCC zwei Timer für den PCE1-initiierten LSP: Delgation Cleanup Timeout und der LSP Cleanup Timer. Während dieser Zeit kann PCE1 oder PCE2 die Kontrolle über den PCE-initiierten LSP erwerben.

  3. Wenn PCE2 die Kontrolle über den PCE-initiierten LSP übernimmt, bevor der LSP-Cleanup-Timer abläuft, delegiert PCC den PCE-initiierten LSP an PCE2, und der LSP-Bereinigungs-Timer und die Bereinigung der Übertragung werden beendet.

  4. Wenn die Delegierungs-Bereinigung abgelaufen ist und weder PCE1 noch PCE2 die Kontrolle über den PCE-initiierten LSP übernommen haben, übernimmt PCC die lokale Kontrolle des nicht-anderen, von PCE initiierten LSP bis zum Ablaufdatum des LSP-Bereinigungszeiters.

  5. Nach Ablauf des LSP-Bereinigungszeiters löscht PCC den von PCE initiierten und von PCE1 bereitgestellten LSP.

Konfiguration

CLI-Konfiguration

Um dieses Beispiel schnell konfigurieren zu können, kopieren Sie die folgenden Befehle, fügen Sie diese in eine Textdatei ein, entfernen Sie alle Zeilenbrüche, ändern Sie alle Details, die zur Übereinstimmung mit der Netzwerkkonfiguration erforderlich sind, und kopieren Sie die Befehle, und fügen Sie die Befehle CLI der Hierarchieebene [edit] ein.

Pcc

R1

R2

Verfahren

Schritt-für-Schritt-Verfahren

Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zur Navigation in CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus.

So konfigurieren Sie den PCC-Router:

Anmerkung:

Wiederholen Sie dieses Verfahren für jeden Juniper Networks-Router in der MPLS-Domäne, nachdem Sie die entsprechenden Schnittstellennamen, Adressen und andere Parameter für jeden Router geändert haben.

  1. Konfigurieren Sie die Schnittstellen.

    Um die MPLS zu aktivieren, fügen Sie die Protokollfamilie an die Schnittstelle ein, sodass die Schnittstelle den eingehenden Datenverkehr nicht MPLS verwerfen kann.

  2. Aktivieren sie RSVP auf allen Schnittstellen des PCC, außer auf der Verwaltungsschnittstelle.

  3. Ermöglichen die externe Steuerung von LSPs durch die PCEs.

  4. Aktivieren MPLS auf allen Schnittstellen des PCC, außer auf der Verwaltungsschnittstelle.

  5. Konfiguration OSPF auf allen Schnittstellen des PCC, außer auf der Verwaltungsschnittstelle.

  6. Definieren Sie die PCE-Gruppe, und aktivieren Sie die Unterstützung von PCE-initiierten LSPs für die PCE-Gruppe.

  7. Definieren Sie die PEs, die eine Verbindung mit PCC herstellen.

Ergebnisse

Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie die Befehle show interfacesshow protocols eingeben. Wenn in der Ausgabe nicht die beabsichtigte Konfiguration angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Wenn Sie die Konfiguration des Geräts bereits durchgeführt haben, geben Sie commit sie im Konfigurationsmodus ein.

Überprüfung

Stellen Sie sicher, dass die Konfiguration ordnungsgemäß funktioniert.

Überprüfung des PCC-Status

Zweck

Überprüfen Sie den PCEP-Sitzungsstatus und die LSP-Zusammenfassung zwischen dem PCC und den verbundenen PCEs.

Aktion

Führen Sie im Betriebsmodus den show path-computation-client status Befehl aus.

Bedeutung

Die Ausgabe zeigt den Status der PCEP-Sitzung zwischen den aktiven Zustands-PCEs und dem PCC an. Darüber hinaus werden Informationen über die verschiedenen LSPs auf dem PCC sowie über die Anzahl der von den verbundenen PCEs bereitgestellten LSPs angezeigt, die sie bereitstellen.

PCE1 ist der aktive Haupt-PCE und verfügt über einen PCE-initiierten LSP, der automatisch von der PCC initiiert wurde.

Überprüfung des PCE1-Status

Zweck

Überprüfen Des Hauptstatus des aktiven zustands behafteten PCE

Aktion

Führen Sie im Betriebsmodus den show path-computation-client active-pce detail Befehl aus.

Bedeutung

Die Ausgabe zeigt Informationen über das aktuelle aktive stateful PCE an, mit dem das PCC verbunden ist. Das PCE status Ausgabefeld gibt den aktuellen Status der PCEP-Sitzung zwischen einem PCE und PCC an.

Für PCE1 ist der Status der PCEP-Sitzung der , was bedeutet, dass die PCEP-Sitzung mit der PCE_STATE_UP PCC eingerichtet wurde.

Überprüfung des PCE-initiierten LSP-Status, wenn der LSP extern bereitgestellt wird

Zweck

Überprüfen des Status des PCE-initiierten LSP.

Aktion

Führen Sie im Betriebsmodus den show mpls lsp externally-provisioned detail Befehl aus.

Bedeutung

In der Ausgabe zeigt das LSPtype Ausgabefeld, dass der LSP extern bereitgestellt ist.

Die PCEP-Sitzung zwischen PCC und PCE1 ist verfügbar, und die PCC empfängt die folgenden PCE-initiierten LSP-Parameter:

  • ERO (Pfad) – 10.0.102.10 und 10.0.101.9

  • Bandbreite – 8 Mbit/s

  • Priorität: 7 0 (Einrichtungs- und Hold-Werte)

Configuring Path Computation Element Protocol for MPLS RSVP-TE with Support of PCE-Initiated Point-to-Point-LSPs (Konfiguration des Pfadberechnungselementprotokolls für MPLS RSVP-TE mit Unterstützung von PCE-initiierten Point-to-Point-LSPs

Sie können einen Path Computation Client (PCC) konfigurieren, der dynamisch erstellte Label Switched Paths (LSPs) von einer zentralisierten externen Pfad-Computing-Einheit unterstützt. Ein Stateful Path Computaiton-Element (PCE) kann zur Durchführung einer externen Pfadberechnung und zur Generierung dynamischer LSPs bei Bedarf verwendet werden.

Ein PCC erstellt die von PCE initiierten Point-to-Point-LSP mithilfe der PCE-bereitgestellten LSP-Parameter oder Parameter aus einer vorkonfigurierten LSP-Vorlage, wenn der PCE den LSP nicht bereitgestellt hat, und delegiert automatisch den PCE-initiierten Point-to-Point-LSP an das entsprechende PCE. Daher sind für PCE-initiierte LSPs kein lokal konfigurierter LSP auf dem PCC notwendig.

Ein CLI LSP, PCE-gesteuerten LSP und PCE-initiierten LSP kann auf einem PCC nebeneinander koexistieren.

Bevor Sie beginnen:

  • Konfigurieren Sie die Geräteschnittstellen.

  • Konfiguration MPLS und RSVP-TE.

  • Konfigurieren OSPF oder eines anderen IGP Protokolls.

Führen Sie die folgenden Aufgaben aus, um PCC zur Unterstützung von von PCE initiierten Punkt-zu-Punkt-LSPs zu konfigurieren:

  1. Gehen Sie im Konfigurationsmodus zu der folgenden Hierarchieebene:
  2. Geben Sie die Anzahl der Nachrichten pro Minute an, die das PCC maximal empfangen kann.
  3. Geben Sie die Anzahl der extern bereitgestellten Label Switched Paths (LSPs) über alle angeschlossenen PCEs an, die das PCC maximal akzeptieren kann.
  4. Geben Sie die eindeutige benutzerdefinierte ID für das verbundene PCE an, um die PCE-Parameter zu konfigurieren.
  5. Geben Sie den Zeitraum (in Sekunden) an, den das PCC warten muss, bevor die Steuerung von LSPs nach der Trennung einer PCEP-Sitzung zum Routingprotokollprozess zurücksendet wird.
  6. Geben Sie die zu verbindende IPv4-Adresse des PCE an.
  7. Geben Sie die TCP-Portnummer an, die der PCE verwendet

    Der Wert kann zwischen 1 und 65535 und der Standardwert 4189 sein.

  8. Geben Sie den Zeitraum (in Sekunden) an, den das PCC warten muss, bevor es andere PCE-initiierte LSPs von einem ausgefallenen PCE löscht, nachdem eine PCEP-Sitzung beendet wurde.
  9. PcC-Konfiguration zur Annahme von SPs, die extern von angeschlossenen PCEs bereitgestellt werden. Standardmäßig lehnt das PCC PCE-initiierte LSPs ab.
  10. Geben Sie die Anzahl unbekannter Nachrichten pro Minute an, die das PCC maximal nach dem Schließen der PCEP-Sitzung empfangen kann.

    Der Wert kann zwischen 1 und 16384 liegen und der Standardwert ist 0 (deaktiviert oder keine Begrenzung).

  11. Geben Sie die Anzahl unbekannter Anforderungen pro Minute an, die das PCC maximal nach dem Beenden der PCEP-Sitzung empfangen kann.

    Der Wert kann zwischen 0 und 16384 liegen und der Standardwert ist 5. Dieser Wert wird deaktiviert.

  12. PCE-Typ konfigurieren.
  13. Geben Sie den Zeitraum (in Sekunden) an, in dem das PCC auf eine Antwort warten muss, bevor sie eine Anfrage erneut senden.

    Der Wert kann zwischen 0 und 65535 Sekunden liegen.

  14. Überprüfen und Commit der Konfiguration.

Beispielausgabe

Beispiel: Configuring Path Computation Element Protocol for MPLS RSVP-TE with Support for PCE-Controlled Point-to-Multipoint LSPs

In diesem Beispiel wird gezeigt, wie der Path Computation Client (PCC) mit der Fähigkeit konfiguriert wird, Point-to-Multipoint Traffic Engineered Label-Switched Paths (TE LSPs) zu einem Path Computation Element (PCE) zu melden.

Anforderungen

In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:

  • Drei Router, die eine Kombination aus ACX-Serie, Routern M Series MX-Serie oder Routern T-Serie können.

  • Eine virtuelle Maschine, die mit der Virtual Route Reflector (VRR)-Funktion konfiguriert ist.

  • Eine TCP-Verbindung zu einem externen Stateful-PCE vom VRR.

  • Junos OS 16.1 oder höher, die auf PCC ausgeführt wird.

Bevor Sie beginnen:

  • Konfigurieren Sie die Geräteschnittstellen.

  • Konfiguration MPLS und RSVP-TE.

  • Konfigurieren OSPF oder eines anderen IGP Protokolls.

Überblick

Nachdem eine PCEP-Sitzung zwischen einem PCE und einem PCC eingerichtet wurde, meldet das PCC alle LSPs im System dem PCE für die LSP-Zustandssynchronisierung. Dazu gehören PCC-gesteuerte, PCE-gesteuerte und PCE-initiierte Point-to-Point-LSPs. Beginnend mit Junos OS Release 15.1F6 und 16.1R1 wird diese Funktion auch auf Point-to-Multipoint-LSPs ausgeweitet.

Standardmäßig wird die PCE-Steuerung von Point-to-Multipoint-LSPs auf einer PCC nicht unterstützt. Um diese Funktion hinzuzufügen, fügen Sie die p2mp-lsp-report-capability Anweisung auf den oder [edit protocols pcep pce pce-name][edit protocols pcep pce-group group-id] Hierarchieebenen hinzu.

Topologie

Abbildung 7: Beispiel-PCE-Gesteuerte Point-to-Multipoint-LSPsBeispiel-PCE-Gesteuerte Point-to-Multipoint-LSPs

In diesem Beispiel ist PCC der Ingress-Router, Router R1 der Transit-Router und Router R2 der Egress-Router. PCC ist mit einem Virtual Route Reflector (VRR) verbunden, der mit einem PCE verbunden ist. Zwischen PCC, Router R1 und Router R2 gibt es viele Point-to-Multipoint-Schnittstellen.

Die Berichte von Point-to-Multipoint-LSPs werden wie folgt ausgeführt:

  1. Wenn der Router-PCC mit Punkt-zu-Punkt- und Punkt-zu-Multipoint-LSPs konfiguriert ist, ohne dass Point-to-Multipoint-Berichtsfunktionen unterstützt werden, werden nur die Punkt-zu-Punkt-LSPs dem verbundenen PCE gemeldet. Standardmäßig unterstützt ein PCC keine Point-to-Multipoint-LSP-Berichterstellungsfunktion.

  2. Wenn der Router PCC mit einer Point-to-Multipoint LSP-Berichterstellungsfunktion konfiguriert ist, gibt PCC diese Funktion für PCE zuerst über eine Berichtsnachricht an.

  3. Standardmäßig bietet ein PCE Unterstützung für Point-to-Multipoint LSP-Funktionen. Nach dem Empfang der Anzeige des PCC in Punkt-zu-Multipoint-LSP-Funktionen gibt der PCE im Gegenzug seine Funktion für das PCC aus.

  4. Nach Empfang der Anzeige der Point-to-Multipoint-Funktion durch pcE meldet PCC mithilfe der Update-Nachricht alle Zweigniederlassungen von Point-to-Multipoint-LSPs an das PCE.

  5. Sobald alle LSPs dem PCE gemeldet werden, wird der LSP-Status zwischen PCE und PCC synchronisiert.

Konfiguration

CLI-Konfiguration

Um dieses Beispiel schnell konfigurieren zu können, kopieren Sie die folgenden Befehle, fügen Sie diese in eine Textdatei ein, entfernen Sie alle Zeilenbrüche, ändern Sie alle Details, die zur Übereinstimmung mit der Netzwerkkonfiguration erforderlich sind, und kopieren Sie die Befehle, und fügen Sie die Befehle CLI der Hierarchieebene [edit] ein.

Pcc

R1

R2

R3

Verfahren

Schritt-für-Schritt-Verfahren

Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zur Navigation in CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus.

So konfigurieren Sie den PCC-Router:

  1. Konfigurieren Sie die Schnittstellen von Router-PCC. Um die MPLS zu aktivieren, fügen Sie die Protokollfamilie an die Schnittstelle ein, sodass die Schnittstelle den eingehenden Datenverkehr nicht MPLS verwerfen kann.

  2. Konfigurieren Sie die autonome Systemnummer für Router-PCC.

  3. Aktivieren von RSVP auf allen Schnittstellen von Router-PCC, außer der Verwaltungsschnittstelle.

  4. Aktivieren MPLS auf allen Schnittstellen von Router-PCC außer auf der Verwaltungsschnittstelle.

  5. Konfigurieren Sie einen dynamischen LSP und deaktivieren Sie die automatische Pfadberechnung für den LSP.

  6. Konfigurieren Sie Point-to-Multipoint-LSPs und definieren Sie eine externe Path Computing-Einheit für den LSP.

  7. Aktivieren Sie externe Path Computing für die MPLS LSPs, und weisen Sie eine Vorlage für extern bereitgestellte LSPs zu.

  8. Konfigurieren Sie die LSPs, die über eine lokale Steuerung verfügen und durch PCE-bereitgestellte LSP-Parameter überlastet werden.

  9. Konfigurieren MPLS Richtlinien für administrative Gruppen für die LSP-Berechnung mit eingeschränkten Pfaden.

  10. Weisen Sie die konfigurierten Richtlinien für administrative Gruppen Router-PCC-Schnittstellen zu.

  11. Konfigurieren Sie eine Traffic Engineering Database (TED)-Importrichtlinie.

  12. Konfigurieren Sie eine BGP Gruppe.

  13. Konfigurieren Sie Traffic-Engineering für BGP und weisen Sie die Exportrichtlinie zu.

  14. Konfiguration OSPF Area 0 auf allen Point-to-Multipoint-Schnittstellen von Router-PCC.

  15. Konfiguration OSPF Area 0 auf der Point-to-Point-Schnittstelle von Router-PCC.

  16. Traffic-Engineering für OSPF.

  17. Definieren Sie das PCE, mit dem der Router PCC eine Verbindung herstellt, und konfigurieren Sie die PCE-Parameter.

  18. Konfiguration von Router-PCC zur Aktivierung der Point-to-Multipoint LSP-Funktion für externes Path Computing.

  19. Konfigurieren Sie die Traffic-Engineering-Richtlinie.

Ergebnisse

Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie die Befehle show interfacesshow protocols eingeben. Wenn in der Ausgabe nicht die beabsichtigte Konfiguration angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Überprüfung

Stellen Sie sicher, dass die Konfiguration ordnungsgemäß funktioniert.

Verifizierung der LSP-Konfiguration auf dem PCC

Zweck

Prüfen Sie den LSP-Typ und den Ausführungsstatus des Point-to-Multipoint LSP.

Aktion

Führen Sie im Betriebsmodus den show mpls lsp extensive Befehl aus.

Bedeutung

Die Ausgabe zeigt lsp2-pcc LSP als PCE-gesteuerten LSP an.

Überprüfung der PCE-Konfiguration auf dem PCC

Zweck

Überprüfen sie die Konfiguration der PCE-Parameter und den PCE-Status.

Aktion

Führen Sie im Betriebsmodus den show path-computation-client active-pce Befehl aus.

Bedeutung

Die Ausgabe zeigt das aktive PCE, mit dem der Router PCC verbunden ist, sowie die PCE-Parameter und der Status des PCE-Parameters pce1 an.

Understanding Path Computation Element Protocol for MPLS RSVP-TE with Support for PCE-Initiated Point-to-Multipoint LSPs

Mit der Einführung von von Point-to-Multipoint PCE initiierten LSPs kann ein PCE dynamisch einen Point-to-Multipoint-LSP initiieren und bereitstellen, ohne dass auf dem PCC eine lokale LSP-Konfiguration erforderlich ist. So kann das PCE die Zeitsteuerung und Abfolge der Point-to-Multipoint-Pfadberechnungen innerhalb und über Path Computation Element Protocol (PCEP)-Sitzungen hinweg steuern und so ein dynamisches Netzwerk erstellen, das zentral gesteuert und bereitgestellt wird.

Vorteile von PCE-initiierten Point-to-Multipoint-LSPs

Erfüllt die Anforderungen der Point-to-Multipoint Traffic Engineering LSP-Platzierung in Reaktion auf Anwendungsanforderungen durch dynamische Erstellung und Abschaltung von Point-to-Multipoint-LSPs und erstellt so ein dynamisches Netzwerk, das zentral gesteuert und bereitgestellt wird.

Signalübertragung von PCE-initiierten Point-to-Multipoint-LSPs

Folgende Signalübertragungen werden von PCE initiierte Point-to-Multipoint-LSPs:

  • When a new branch is added (Grafting)—Nur die neue Unter-LSP-Zweigstelle wird signalisiert und führt nicht zu einer Neusignalisierung des gesamten Point-to-Multipoint Tree.

    Wenn vor der Bereitstellung des neuen Sub-LSP Topologie-Änderungen aufgetreten sind, berechnet der Path Computation Server (PCS) den gesamten Point-to-Multipoint Tree neu und aktualisiert den Point-to-Multipoint LSP mit einer PC-Aktualisierungsnachricht.

  • When a branch is deleted (Pruning)— Der gelöschte Sub-LSP des Zweigniederlassungs ist abgerissen und führt nicht zu einer erneuten Signalübertragung des gesamten Point-to-Multipoint Tree.

  • When a branch sub-LSP parameter is changed— Änderungen in Parametern unter LSP, wie Explicit Route Object (ERO), Bandbreite oder Priorität, können entweder aufgrund der Optimierung oder auf Benutzeranfrage geschehen. Wenn eine Anforderung für einen Sub-LSP um eine Erneute Signalübertragung erfolgt, wird das gesamte Point-to-Multipoint Tree-Signal neu signalisiert, und der Wechsel zur neuen Instanz erfolgt, sobald die neuen Instanzen aller Zweigstellen verfügbar sind.

  • When a branch sub-LSP path fails— Bei dem ausgefallenen Sub-LSP in Zweigniederlassungen wird ein Fehler an das PCS gemeldet. Beim Empfang des neuen ERO vom PCS wird der gesamte Point-to-Multipoint Tree zusammen mit dem ausgefallenen Sub-LSP der Zweigstelle neu signalisiert, und der Wechsel zur neuen Instanz erfolgt nach einer Make-before-Break (MBB)-Weise.

Verhalten von PCE-initiierten Point-to-Multipoint-LSPs nach PcEP-Sitzungsfehler

Wenn eine PCEP-Sitzung ausfällt, werden die von PCE initiierten Point-to-Multipoint-LSPs bis zum Ablaufdatum des state timeout Timers beendet. Nach Ablauf des Timer werden die state timeout PCE-initiierten LSPs bereinigt.

Um nach einem PCEP-Sitzungsfehler die Kontrolle eines von PCE initiierten Point-to-Multipoint LSP zu erhalten, sendet das primäre oder sekundäre PCE eine Nachricht, bevor der PCInitiatestate timeout Timer abläuft.

Konfigurieren der PCE-initiierten Point-to-Multipoint LSP-Funktion

Standardmäßig wird die Erstellung und Bereitstellung von Point-to-Multipoint-LSPs durch ein PCE auf einer PCC nicht unterstützt. Um diese Fähigkeit zu aktivieren, fügen Sie die p2mp-lsp-init-capability Anweisungen und Anweisungen p2mp-lsp-update-capability auf den oder auf den [edit protocols pcep pce pce-name][edit protocols pcep pce-group group-id] Hierarchieebenen ein.

Diese p2mp-lsp-init-capability Anweisung bietet die Möglichkeit, Point-to-Multipoint RSVP-TE-LSPs über ein PCE zur Bereitstellung zu machen. Diese p2mp-lsp-update-capability Anweisung bietet die Möglichkeit, Point-to-Multipoint RSVP-TE LSP-Parameter durch ein PCE zu aktualisieren.

Unterstützte und nicht mehr unterstützte Funktionen für PCE-initiierte Point-to-Multipoint-LSPs

Von PCE initiierte Point-to-Multipoint-LSPs werden folgende Funktionen unterstützt:

  • Teilweise Kompatibilität mit dem Internet draft-ietf-pce-stateful-pce-p2mp (läuft ab Oktober 2018 ab), Path Computation Element (PCE) Protokollerweiterungen für Stateful PCE-Nutzung für Point-to-Multipoint Traffic Engineering Label Switched Paths.

  • Wir unterstützen Junos OS 21.1R1 nonstop Active Routing (NSR) für PCE-initiierte RSVP-basierte Point-to-Multipoint-LSPs. Nur der primäre Routing-Engine verwaltet die PCEP-Sitzung mit dem Controller. Er synchronisiert alle von PCEs initiierten RSVP-LSPs, einschließlich Multicast-Datenflussspezifikationen für alle PCE-initiierten P2MP-LSPs mit dem Backup-Routing-Engine. Während eines Switchovers läuft die PCEP-Sitzung aus und stellt sie wieder her, wenn die Backup-Routing-Engine oberster Routing-Engine. So wird der Datenverkehrsverlust bei Datenverkehr, der über PCE-initiierte RSVP-LSPs übertragen wird, während Routing-Engine reduziert. Diese Funktion ist aktiviert, wenn NSR konfiguriert ist.

Die folgenden Funktionen werden von PCE-initiierten Point-to-Multipoint-LSPs nicht unterstützt:

  • Delegation des lokal gesteuerten Point-to-Multipoint-LSP.

  • LSP-Steuerungsdelegierung.

  • Interior Gateway Protocol (IGP) Erweiterung für PCE-Erkennung innerhalb einer IGP Routingdomäne.

  • Anfrage-/Antwort-E-Mail.

  • Direkte Bewegung von Sub-LSP-Zweigstellen von einem Punkt-zu-Multipoint-Tree zu einem anderen.

    DasSelbe kann erreicht werden, indem ein Sub-LSP in einer Zweigstelle vom ersten Point-to-Multipoint Tree entfernt und einer anderen hinzugefügt wird, nachdem die Nachricht die LSP-Entfernung vom Gerät angegeben PCReport hat.

  • IPv6 wird nicht unterstützt.

  • SERO-basierte Signalübertragung wird nicht unterstützt.

  • Leere ERO-Funktion wird nicht unterstützt.

  • Der Verbindungsschutz wird nicht unterstützt.

Zuordnung VON PCE-initiierten Point-to-Multipoint-LSPs zu MVPN

Sie können eine einzelne oder breite Palette von MVPN-Multicast-Flows (S,G) einem dynamisch erstellten PCE-initiierten Point-to-Multipoint Label Switched Path (LSP) zuordnen. Sie können nur selektive Arten von Datenflüssen für diese Funktion angeben. Die Themen umfassen:

  • Route Distinguisher (RD), der der MVPN-Routinginstanz zugeordnet wird.

  • (S,G), die die Quelle eines Multicastpakets und der Ziel-Multicastgruppenadresse ist. Dies wird verwendet, um eingehenden Datenverkehr für die Zuordnung zum Tunnel zu filtern.

  • Point-to-Multipoint-LSP, der zum Senden von Datenverkehr verwendet wird, der der oben genannten Datenflussspezifikation entspricht.

Weitere Informationen finden Sie im Internet-Entwurf draft-ietf-pce-pcep-flowspec-05 (läuft am 16. Februar 2020 ab) PCEP-Erweiterungfür Datenstromspezifikation.

Die aktuelle Implementierung dieser Funktion implementiert die folgenden Abschnitte des Entwurfs nicht:

  • Abschnitt 3.1.2– PCE-Capabilitäten in der IGP

  • Section 3.2: PCReq- und PCRep-Nachricht

  • Abschnitt 7: Die meisten Datenstromspezifikationen, mit Ausnahme von Routen-DistinguDie aktuelle Implementierung dieser Funktion supporisher- und IPv4-Multicast-Datenstromspezifikationen wird nicht unterstützt.

Um die Zuordnung von PCE-initiierten Point-to-Multipoint-LSPs zu MVPN zu ermöglichen:

  • Fügen Sie die Anweisung auf der Hierarchieebene ein, um die Unterstützung der Flussspezifikationsfunktion (auch als Datenverkehrssteuerung bezeichnet) durch das pce_traffic_steering[edit protocols pcep pce pce-id] PCC anzuzeigen.

  • Geben Sie external-controller die Anweisung auf der [edit routing-instances routing-instance-name provider-tunnel] Hierarchieebene an.

    Die Präsenz in der Provider-Tunnel-Konfiguration für MVPN gibt an, dass die external-controller Point-to-Multipoint LSP und (S,G) für diese MVPN-Instanz vom externen Controller bereitgestellt werden können. Dies ermöglicht dem externen Controller die dynamische Konfiguration (S,G) und Point-to-Multipoint LSP für MVPN.

Berücksichtigen Sie die folgenden Punkte für die Zuordnung von PCE-initiierten Point-to-Multipoint-LSPs zu MVPN:

  • Wenn Sie die Anweisung für eine bestimmte MVPN-Instanz nicht aktivieren, dann konfiguriert external-controller pccd der PCCD-Prozess (S,G) nicht dynamisch.

  • Wenn Sie die Konfiguration vom CLI deaktivieren, werden die dynamisch erlernten Multicast-Flows (S,G) für diese bestimmte MVPN-Instanz gelöscht und dem externen Controller external-controller pccd gemeldet.

  • Wenn (S,G) bereits vom CLI konfiguriert wird, kann das PCC (S,G) nicht dynamisch konfigurieren, da lokale Konfiguration eine höhere Priorität hat.

  • Wenn bestimmte Informationen (S,G) dynamisch von einem externen Controller gelernt werden und Sie dann dasselbe (S,G) für die gleiche MVPN-Instanz konfigurieren, wird der dynamisch erlernte (S,G) gelöscht und über das PCC an den externen Controller gemeldet.

  • Wenn der Routingprotokollprozess neu gestartet wird, konfiguriert der PCCD-Prozess alle (S,G) erneut.

  • Wenn der PCCD-Prozess neu gestartet wird, meldet MVPN alle konfigurierten PCCD-Daten (S,G) dem externen Controller.

  • Wenn der Benutzer die Aktivierung für eine bestimmte MVPN-Instanz macht, fordert MVPN den PCCD-Prozess zur Konfiguration external-controller pccd (S,G) an, falls vorhanden.

  • Wenn es größere Konfigurationsänderungen an einer bestimmten MPVN-Instanz gibt, fordert MVPN den PCCD-Prozess zur Neukonfiguration aller (S,G) für diese bestimmte MVPN-Instanz an.

  • Alle Flussspezifikationen, die mit einem PCE-initiierten Point-to-Multipoint LSP verknüpft sind, müssen über dasselbe RdSP verfügen. Während des PC-Initiierungs wird die initiierte PC-Nachricht mit einem Fehler verworfen, wenn nicht alle Datenflussdaten über dieselbe RD verfügen.

  • Sie können einen Point-to-Multipoint-LSP nur mit selektiven Typ von Datenflussspezifikationen verknüpfen, andernfalls wird die vom PC initiierte Nachricht durch einen Fehler verworfen.

  • Wenn beim PC-Update aufgrund einer neuen Datenstromspezifikation oder aufgrund einer Aktualisierung der Datenflussspezifikation nicht alle Datenstromspezifikationen über dieselben Datenflüsse verfügen, wird die Update-Nachricht von PCC verfällt.

  • Wenn beim PC-Update alle Datenstromspezifikationen aufgrund einer neuen Datenstromspezifikation oder aufgrund vorhandener Datenflussspezifikationen nicht den selektiven Zustand erfüllen, wird die Update-Nachricht von PCC verfällt.

  • Das Verhalten für die Zuordnung von PCE-initiierten Point-to-Multipoint LSP mit MVPN-Routing-Instanz und die Zuordnung statischer (lokal konfigurierter) Point-to-Multipoint LSP mit MVPN-Instanz ist auf Benutzerebene gleich.

  • Eine Datenstrom-Spezifikations-ID kann mit nur einem Point-to-Multipoint LSP verknüpft werden. Um die gleichen FE und (S,G) mit mehreren Point-to-Multipoint-LSPs zu verknüpfen, können Sie mehrere Datenflussspezifikationen mit verschiedenen IDs und derselben FE & (S,G) hinzufügen.

  • Für PCEP-zugeordnete dynamische (S,G) ist der Grenzwert immer der Standardwert 0.

  • Die Anzahl der Datenflussspezifikationen, die einem einzelnen PCE-initiierten Point-to-Multipoint-LSP zugeordnet wurden, ist nicht limitiert.

  • Die aktuelle Implementierung dieser Funktion unterstützt nicht:

    • Berichterstellung für Weiterleitungszustände, die mit dem Point-to-Multipoint LSP verknüpft sind.

    • Inklusive dynamische Konfiguration von Provider-Tunneln

    • Zuordnung für MVPN-Ingress-Replikations-Tunnel

    • Programmierbarer Routingprotokollprozess (PRPD)

    • Berichterstellung CLI konfigurierten Point-to-Multipoint LSP, der MVPN-Multicast-Flows (S,G) zugeordnet wird.

Aktivieren des Segment-Routings für das Path Computation Element Protocol

SUMMARY Segment-Routing oder Source Packet Routing in Networking (SPRING) Traffic-Engineering (SR-TE) mit dem Path Computation Element Protocol (PCEP) für die Steuerung des Datenverkehrs kann aktiviert werden. Durch diese Unterstützung werden die Vorteile des Segment-Routing auf Label-Switched Paths (LSPs) ausgeweitet, die extern durch ein Path Computation Element (PCE) kontrolliert werden.

Segment-Routing für den Pfadberechnungselementprotokoll – Übersicht

Vorteile von Segment-Routing für PCEP

  • Das Einrichten von LSPs über einen externen Controller bietet eine globale Ansicht des Bedarfs an Bandbreite pro LSP und pro Gerät im Netzwerk und ermöglicht die Online- und Echtzeit-Constraint-basierte Pfadberechnung.

    Die Vorteile des Segment-Routing werden auf LSPs ausgeweitet, die von einem externen Controller initiiert werden, auch als Path Computation Element (PCE) bezeichnet, um die Vorteile des externen Path Computing in einem Netzwerk MPLS erweitern.

  • Ein Path Computation Client (PCC, ein Ingress-Router der MX-Serie) mit Delegierungsfunktion kann die Kontrolle des zielseitigen Segment-Routing-LSPs aus dem PCE übernehmen, wenn die PCEP-Sitzung ausläuft. würden die LSPs andernfalls aus dem PCC gelöscht. Sie können somit den LSP-Datenschutz gewährleisten, indem Sie eine Situation abwenden, in der Pakete unbewollt verworfen oder verworfen werden (auch als Null-Routenbedingung bekannt).

Segment-Routing für Traffic Engineering

Segment-Routing kann über eine IPv4- oder IPv6-Datenebene betrieben werden und unterstützt Multipath zu gleichen Kosten (ECMP). Die integrierten IGP integrieren das Segment-Routing in die reichhaltigen Multiservice-Funktionen von MPLS, darunter Layer 3-VPN, Virtual Private Wire Service (VPWS), Virtual Private LAN Service (VPLS) und Ethernet VPN (EVPN).

Zu den High-Level-Komponenten der SR-TE-Lösung (Segment Routing– Traffic Engineering) gehören:

  • Verwendung einer IGP für Werbelink-Merkmale. Diese Funktionen sind mit RSVP-TE.

  • Verwendung von Constrained Shortest Path First (CSPF) auf dem Ingress-Gerät oder dem PCE.

  • Verwendung einer IGP zur Beschriftung von Links.

    In SR-TE Funktionalität:

    1. Das Ingress-Gerät errichtet einen LSP, indem es die Label der Verbindungen stapelt, die es durchlaufen möchte.

    2. Die anzeigebasierte IGP pro Link wird mit Label-Stacking kombiniert, um Source-Route-LSPs auf dem Gerät zu erstellen, die in das Netzwerk eindringen, sodass die Transitgeräte die End-to-End-LSPs nicht kennen.

    3. LSPs werden zwischen Edge-Knoten erstellt, ohne dass irgendwelche Pro-LSP-Speicheranforderungen auf den Transitgeräten platziert werden. (Die Erstellung solcher LSPs ist aktiviert, da keine LSP-Signalübertragung pro LSP in SR-TE.)

    4. Die Label pro Nachbar werden über einen Stack gestapelt. Dies führt zur Verwaltung einer großen Anzahl von Labels, was zu einer Skalierung der Steuerungsebene führt.

Junos OS Implementierung von Segment-Routing für PCEP

Junos OS implementiert Segment-Routing für PCEP für zwei Arten von LSPs: PCE-initiierte LSPs und PCE-orientierte LSPs.

PCE-initiierte Segment-Routing-LSPs

Bei den von PCE initiierten Segment-Routing-LSPs handelt es sich um LSPs, die vom PCE für die Adjacency- und Node-Segmente erstellt werden.

Das PCE führt die folgenden Funktionen aus:

  1. Berechnet den Pfad des Segment-Routing-LSP.

  2. Provisionsiert den LSP auf dem Path Computation Client (PCC) mit PCEP-Segment-Routing-Erweiterungen.

  3. Analysiert PCEP-Segment-Routing-Erweiterungen.

  4. Erstellt eine Tunnelroute auf dem PCC, die ihren eigenen Einstellungswert hat und in der inet.3-Routingtabelle verfügbar gemacht wird, um IP-Datenverkehr und -Dienste wie jede andere Tunnelroute zu lösen.

Das PCC führt die folgenden Funktionen aus:

  1. Wählt die ausgehende Schnittstelle basierend auf der ersten Network Access Identifier (NAI) im Source Explicit Route Object (S-ERO) aus.

    Junos OS unterstützt S-EROs, die den ersten Hop als Strict Hop enthalten. Junos OS unterstützt keine Auswahl der ausgehenden Schnittstelle an der PCC basierend auf einer Segment-ID des Loose-Hop-Knotens (SID). Die restlichen Hops können jedoch lose sein. Für die S-EROs, die sich außerhalb des ersten Hops befinden, wird keine spezielle Verarbeitung durchgeführt. Es ist nicht möglich, das Label einfach für die Erstellung des nächsten Hops zu verwenden.

  2. S-ERO wird abgelehnt, wenn:

    • S-ERO ist nicht als Label enthalten.

    • Der S-ERO überträgt mehr als sechs Hops.

    Das PCC erstellt eine Equal-Cost-Multipath-Route (ECMP), wenn mehrere LSPs zum selben Ziel mit derselben Kennzahl verfügbar sind.

  3. Wartet darauf, dass das PCE alle Ereignisse verarbeiten kann, die zu einer Änderung des Segment-Routing-LSP nach der Bereitstellung führen. Das kann beispielsweise der Fall sein, wenn das Label geändert oder zurückgenommen wird oder wenn eine der vom LSP durchquerten Schnittstellen ausb fallt.

Wenn die PCEP-Sitzung ausläuft, führt das PCE-initiierte Segment-Routing LSP:

  1. Bleibt 300 Sekunden bestehen.

  2. Wird nach 300 Sekunden aus dem PCC gelöscht.

Weitere Details finden Sie unter Internet-Entwürfe draft-ietf-pce-lsp-setup-type-03.txt (läuft am 25. Dezember 2015 ab), Übertragung des Pfadeinrichtungstyps in PCEP-Nachrichten; und draft-ietf-pce-segment-routing-06.txt (läuft am 10. Februar 2016 ab), PCEP-Erweiterungen für Segment-Routing.

PCE-orientierte Segment-Routing-LSPs

Bei pcE-orientiertem Segment-Routing handelt es sich um LSPs, die von PCC lokal konfiguriert und dann an einen PCE-Controller delegiert werden.

Anmerkung:

Junos OS Release 20.1R1 unterstützt:

  • PCE-Delegierungsfunktion nur für nichtfarbige Segment-Routing-LSPs mit IPv4-Zielen.

  • Delegierung und Berichterstattung nur des ersten Segments einer Segmentliste an einen externen Controller. Mehrere Segmente werden nicht für die PCE-Delegierung unterstützt.

Die PCC kann ein Segment-Routing-LSP auf folgende Weise an einen externen Controller (PCE) delegieren:

  • Initial delegation— Die lokalen LSPs müssen noch nicht auf dem PCC konfiguriert werden, und die Delegierung des LSP erfolgt zu dem Zeitpunkt, an dem der LSP konfiguriert ist.

  • Delegation of existing LSP— Die lokalen LSPs werden auf dem PCC konfiguriert, und die Delegierung des LSP erfolgt, nachdem der Source-Routing-Pfad konfiguriert wurde. Das heißt, die Delegierungsfunktion ist auf vorhandenen Segment-Routing-LSPs aktiviert.

Nach der Delegierung eines Segment-Routing-LSP steuert das PCE die anderen LSPs und kann die LSP-Attribute für die Pfadberechnung ändern. Wenn die PCEP-Sitzung zwischen PCC und PCE ausbehrt, wird die LSP-Steuerung wieder auf das PCC zurückverwendet. Die PCE-orientierte LSPs haben einen Vorteil gegenüber von PCE initiierten LSPs, wenn die PCEP-Sitzung aus fall fallabläuft. Bei PCE-initiierten LSPs, wenn die PCEP-Sitzung ausfällt, werden die LSPs aus dem PCC gelöscht. Bei PCE-orientiertem LSPs, wenn die PCEP-Sitzung ausläuft, übernimmt das PCC die Kontrolle über die anderen LSPs vom PCE. Mit PCE-orientierte lSPs können wir so eine Situation abwenden, in der Pakete unbeschwert verworfen werden (auch als Null-Route-Bedingung bezeichnet), wenn die Sitzung ausläuft.

Die PCE-Delegierungsfunktion wird von den folgenden Segment-Routing-LSPs unterstützt:

  • Static LSPs– Statisch konfigurierte Source-Routing-Pfade, bei denen der gesamte Label-Stack statisch konfiguriert ist.

  • Auto-translated LSPs– Statisch konfigurierte Source-Routing-Pfade, die automatisch übersetzt werden.

  • Computed LSPs– Statisch konfigurierte Source-Routing-Pfade, die mit Distributed Constrained Shortest Path First (CSPF) berechnet werden.

  • Dynamic LSPs— Dynamisch erstellte Tunnel, die durch das Dynamic Tunnel Module ausgelöst werden und über eine ERO-Auflösung im letzten Hop verfügen.

Je nach der Quelle des Segment-Routing-LSP können Sie die Delegierungsfunktion auf dem PCC konfigurieren. Um eine Delegierung von Segment-Routing-LSPs zu ermöglichen, fügen Sie die Anweisung auf der lsp-external-controller pccd entsprechenden Ebene innerhalb der Hierarchie [edit protocols source-packet-routing] bei.

Tabelle 2 zeigt eine Zuordnung der LSP-Quelle zur entsprechenden Konfigurationshierarchieebene an, in der die Delegierungsfunktion aktiviert ist.

Anmerkung:

Sie müssen die Anweisung auf den Hierarchieebenen und den Anweisungen enthalten, bevor Sie die lsp-external-controller pccd[edit protocols source-packet-routing][edit protocols mpls] Delegierungsfunktion auf dem PCC konfigurieren.

Tabelle 2: Zuordnung der Segment-Routing-LSP-Quelle mit Konfigurationshierarchie

Quelle des Segment-Routing-LSP

Konfigurationshierarchie

  • Automatisch übersetzte LSPs

  • Statische LSPs

Primäre Segmentliste unter [edit protocols source-packet-routing source-routing-path lsp-name primary path-name]

Computed LSPs (verteiltes CSPF)

Primäre Segmentliste des Quell-Routing-Pfads unter:

  • [edit protocols source-packet-routing source-routing-path lsp-name primary path-name compute profile-name]

  • [edit protocols source-packet-routing source-routing-path lsp-name primary path-name]

Dynamische LSPs

Primäre Segmentliste der Vorlage für Quell-Routing-Pfade unter:

  • [edit protocols source-packet-routing source-routing-path-template template-name primary primary-segment-list-name]

  • [edit protocols source-packet-routing source-routing-path-template template-name]

Sie können den Steuerungsstatus der SR-TE LSPs von der Spring Traffic-Engineering-Befehlsausgabe anzeigen.

Tabelle 3 zeigt die PCEP-Interaktion an, wenn die lsp-external-controller Anweisung für einen Source-Routing-Pfad konfiguriert wurde.

Tabelle 3: PCEP-Interaktion LSP-Delegation

Konfigurationshierarchie für lSP-External Controller

Source-Routing-Path-Delegation State

PCEP-Interaktion zwischen PCC und PCE

Hauptsegmentliste des Quell-Routing-Pfads

Initiale Delegierung

  1. Eine PCE-Nachricht wird zur Delegation an das PCE gesendet. Pc Eine Liste mit Einschränkungen und Pfaddetails (z. B. ERO).

  2. PCE berechnet den Pfad für den LSP und den Pfad für den Bericht in dem Status unten.

  3. Keine Route wird vom lokalen LSP programmiert, bis der Controller den ERO berechnet und das Ergebnis über PCUpdate an das PCC benachrichtigt.

Dasselbe Verhalten wird beim Neustart des Routingprotokollprozesses (rpd) oder bei einem Routing-Engine umgeschaltet.

Hauptsegmentliste des Quell-Routing-Pfads

Delegierung bestehender Pfade

  1. Eine PC2000 wird zur Delegation an das PCE gesendet. Pc Eine Liste mit Einschränkungen und Pfaddetails (z. B. ERO).

  2. Ein entsprechendes Primäres Segment wird vom PCE nicht genannt.

  3. PCE berechnet den Pfad für den LSP.

  4. Das Hauptsegment trägt weiterhin zu der Route bei, die von der lokalen Konfiguration oder Berechnung bestimmt wird, bis eine PCUpdate vom PCE empfangen wird.

    • Wenn Seamless BFD (S-BFD) nicht für das Primärsegment konfiguriert ist, wird der Routen nicht weiter aktualisiert und der LSP-Status wird auch nicht überwacht und dem PCE gemeldet. Der LSP-Status zu diesem Zeitpunkt wird als auf- oder abwärts gemeldet, je nachdem, ob die Pfadberechnung zu diesem Zeitpunkt erfolgreich war.

    • Wird S-BFD für das Hauptsegment konfiguriert, wird der Status des primären Segments verfolgt und dem PCE gemeldet. Wenn das BFD erkennt, dass das primäre Segment nach unten liegt, wird der entsprechende primäre Pfad aus der Route entfernt. Wenn dieser Pfad jetzt ist, wird dieselbe Route, die zuvor berechnet wurde, neu programmiert.

  5. Wenn eine PCUpdate-Nachricht von pcE empfangen wird, verwendet sr-TE den empfangenen Parameter, um den Pfad, für den die PCE-Nachricht gesendet wurde, einzu richten. Der programmierte Pfad enthält dann nur die vom PCE empfangene Segmentliste, und alle anderen zuvor programmierten Segmentlisten werden entfernt. Diese Umprogrammierung der Route erfolgt nach einer Make-Before-Break-Weise.

Hauptsegment des Source-Routing-Pfads

Delegierung wird nicht konfiguriert oder wurde gelöscht.

Die Segmentliste aus dem PCE (falls vorhanden) wird nicht mehr verwendet, und das Berechnungsergebnis aus der lokalen Konfiguration wird verwendet. Wenn das lokale Ergebnis für die Segmentliste verfügbar ist, wird die entsprechende Segmentliste verwendet, um die Route make-before-break zu programmieren.

Segmentliste des Quell-Routing-Pfads

Die Delegierung ist aktiviert, nachdem LSP konfiguriert wurde.

Delegierungsfunktion wird für die primäre Segmentliste unter dem Source-Routing-Pfad ausgelöst.

Segmentliste des Quell-Routing-Pfads

Delegierung wird nicht konfiguriert oder wurde gelöscht.

Die Delegierungsfunktion wird aus der primären Segmentliste des Quellroutingpfads entfernt.

Primäre Segmentliste der Vorlage für Quell-Routing-Pfade

Die Delegierung ist aktiviert, nachdem LSP konfiguriert wurde.

  • In der Vorlage für den Source-Routing-Pfad wird eine Delegierungsfunktion für den gesamten Source-Routing-Pfad ausgelöst.

    Vorlagenkonfigurationen können nur auf das Dynamic Tunnel-Modul angewendet werden.

  • Unter dem Hauptpfad in der Vorlage für den Quellroutingpfad wird je nach Konfiguration eine Delegierungsfunktion für diesen bestimmten primären Pfad ausgelöst.

Primäre Segmentliste der Vorlage für Quell-Routing-Pfade

Delegierung wird nicht konfiguriert oder wurde gelöscht.

Die Delegierungsfunktion wird aus allen Source-Routing-Pfaden und primären Pfaden, die der Vorlagenkonfiguration übereinstimmen, entfernt.

Segment-Routing für PCEP-Einschränkungen und nicht mehr unterstützte Funktionen

Die Unterstützung von Segment-Routing für PCEP führt nicht zu einer Leistungsbelastung des Systems. Sie hat jedoch folgende Einschränkungen:

  • Ein SR-TE LSP wird nicht lokal auf dem PCC geschützt. Wenn der LSP mehr als sechs Hops bespricht, wird auf dem LSP kein anderer Dienst bereitgestellt, als nur ip-Datenverkehr zu tragen.

  • Graceful Routing-Engine Switchover (GRES) und einheitliches In-Service Software Upgrade (Unified ISSU) werden nicht unterstützt.

  • Nonstop Active Routing (NSR) wird nicht unterstützt.

  • IPv6 wird nicht unterstützt.

  • PCE-orientierte LSPs unterstützen folgende Punkte nicht:

    • Sr-sr-TE-LSPs

    • IPv6-LSPs

    • Sekundäre Segmentliste des Source-Routing-Pfads. Es kann nicht sein, einen einzigen Pfad in der Segmentliste auf den Weg zu bringen.

    • Multisegment-Standard. Nur das erste Segment der Segmentliste wird so genannt und wird dem Controller gemeldet.

Beispiel: Konfiguration des Segment-Routing für das Path Computation Element Protocol

In diesem Beispiel wird gezeigt, wie Segment-Routing oder Source Packet Routing in Networking (SPRING) Traffic-Engineering (SR-TE) für das Path Computation Element Protocol (PCEP) konfiguriert wird. Bei der Konfiguration nutzen wir die Vorteile des Segment-Routing mit den Vorteilen des externen Path Computing für effizientes Traffic-Engineering.

Anforderungen

In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:

  • Vier 5G-Router der MX-Universelle Routing-Plattformen- Serie, bei denen der Router der MX-Serie als Path Computation Client (PCC) gilt.

  • Eine TCP-Verbindung vom PCC zu einem externen stateful Path Computation Element (PCE).

  • Junos OS Version 17.2 oder höher, die zur Implementierung von PCE-initiierten LSPs auf dem PCC ausgeführt wird.

    Zur PCE-Delegierung müssen Sie Junos OS einer 20.1R1 oder einer späteren Version ausführen.

Bevor Sie beginnen:

  • Konfigurieren Sie die Geräteschnittstellen.

  • Konfiguration MPLS.

  • Konfiguration IS-IS.

Überblick

Die Junos OS Implementierung von Segment-Routing für PCEP umfasst PCE-initiierte und PCE-orientierte SR-TE LSPs.

  • Die Implementierung von PCE-initiierten LSPs wird im Junos OS Release 17.2R1 eingeführt, in dem die Traffic-Engineering-Fähigkeiten des Segment-Routing in PCEP-Sitzungen für LSPs unterstützt werden, die von einem PCE initiiert werden. Das PCE erstellt die LSPs für die Adjacency- und Node-Segmente. Tunnelrouten werden in der inet.3-Routingtabelle des PCC erstellt, die den VON PCE initiierten SR-TE LSPs entspricht.

  • Die Implementierung von PCE-unterstützten LSPs wird in Junos OS Release 20.1R1 eingeführt, wo die lokal konfigurierten IPv4-nicht-farblich konfigurierten Segment-Routing-LSPs auf dem PCC von einem PCE-Controller unterstützt werden. Der PCE steuert dann den LSP und kann die LSP-Attribute zur Pfadberechnung ändern.

Die PCE-orientierte LSPs haben zum Zeitpunkt des Abtritts der PCEP-Sitzung einen Vorteil gegenüber von PCE-initiierten LSPs. Bei PCE-initiierten LSPs, wenn die PCEP-Sitzung ausfällt, werden die LSPs aus dem PCC gelöscht. Bei PCE-orientiertem LSPs, wenn die PCEP-Sitzung ausläuft, übernimmt das PCC die Kontrolle über die anderen LSPs vom PCE. Mit PCE-orientierte lSPs können wir so eine Situation abwenden, in der Pakete unbeschwert verworfen werden (auch als Null-Route-Bedingung bezeichnet), wenn die PCEP-Sitzung ausläuft.

So aktivieren Sie Segment-Routing für PCEP:

Für VOM PCE initiierte Segment-Routing-LSPs:

  1. Ermöglichen externes Path Computing für MPLS die Einbeziehung der lsp-external-controller Anweisung auf der [edit protocols mpls] Hierarchieebene.

    Diese Konfiguration ist für PCEP mit RSVP-TE erforderlich. PCEP kann nicht mit RSVP-TE deaktiviert werden, wenn Segment-Routing für PCEP aktiviert ist.

  2. Ermöglichen externes Path Computing für SR-TE durch Einschleutung der lsp-external-controller pccd Aussage auf Der [edit protocols spring-traffic-engineering] Hierarchieebene.

  3. Aktivieren Sie Segment-Routing für PCE durch Einführung der spring-capability Anweisung auf der [edit protocols pcep pce pce-name] Hierarchieebene.

  4. Optionale Konfiguration der maximalen SID-Tiefe für PCE durch Angabe der max-sid-depth number Anweisung auf [edit protocols pcep pce pce-name] der Hierarchieebene.

    Die maximale SID-Tiefe ist die Anzahl der SIDs, die von einem Knoten oder einer Verbindung auf einem Knoten unterstützt werden. Bei nicht konfigurierter Konfiguration wird ein maximaler SID-Wert von 5 angewendet.

  5. Optionale Konfiguration des Einstellungswerts für Segment-Routing durch Einbeziehung preference preference-value der [edit protocol spring-te] Hierarchieebene.

    Der Präferenzwert gibt die Reihenfolge an, in der ein Pfad als aktives Pfadformular zwischen Kandidatenpfaden ausgewählt wird, bei dem ein höherer Wert eine höhere Präferenz hat. Bei nicht konfigurierter Konfiguration wird ein Standardpräferenzwert 8 angewendet.

  6. Optionale Konfiguration der Segment-Routing-Protokollierung zur Problembehandlung durch Angabe der traceoptions Aussage auf [edit protocols spring-te] Hierarchieebene.

Gehen Sie zur PCE-Delegation von Segment-Routing-LSPs zusätzlich zu den oben genannten Schritten wie folgt vor:

  1. Definieren Sie eine Segmentliste mit Label-Parametern. Dadurch wird ein Segment-Routing-LSP lokal auf dem PCC erzeugt.

  2. Aktivieren der Delegierungsfunktion des lokal konfigurierten LSP auf der PCC durch Angabe der Anweisung in einer der folgenden Hierarchien, abhängig von der lsp-external-controller pccd LSP-Segment-Routing-Quelle:

    • Für statisch konfigurierte Source-Routing-Pfade, die mit verteilten CSPF- und [edit protocols source-packet-routing source-routing-path lsp-name primary path-name compute profile-name][edit protocols source-packet-routing source-routing-path lsp-name primary path-name] Hierarchieebenen berechnet werden.

    • Für statisch konfigurierte Source-Routing-Pfade mit dem gesamten Labelstack statisch konfigurierten und Source-Routing-Pfaden, die automatisch übersetzt werden – [edit protocols source-packet-routing source-routing-path lsp-name primary path-name] Hierarchieebene.

    • Für dynamisch erstellte Tunnel, die über das Dynamic Tunnel Module mit Last-Hop-ERO-Auflösung – [edit protocols source-packet-routing source-routing-path-template template-name primary primary-segment-list-name] und [edit protocols source-packet-routing source-routing-path-template template-name] Hierarchieebenen – ausgelöst werden.

Topologie

Abbildung 8 zeigt eine Beispiel-Netzwerktopologie mit einer PCEP-Sitzung zwischen PCE und PCC (dem Ingress-Router der MX-Serie). Die Router R1, R2 und R3 sind die anderen Router der MX-Serie im Netzwerk. In diesem Beispiel konfigurieren wir Segment-Routing für PCEP auf der PCC. Wir konfigurieren auch eine statische Route auf der PCC zu Router R3, um die Verwendung von SR-TE-Tunnel-Routen beim Routing von Datenverkehr für die statische Route zu überprüfen.

Abbildung 8: Segment-Routing für PCEPSegment-Routing für PCEP

Konfiguration

CLI-Konfiguration

Um dieses Beispiel schnell konfigurieren zu können, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenbrüche, ändern Sie alle Details, die zur Übereinstimmung mit Ihrer Netzwerkkonfiguration erforderlich sind, kopieren Sie die Befehle, kopieren Sie die Befehle in die CLI der Hierarchieebene, und geben Sie sie dann im Konfigurationsmodus [edit]commit ein.

Obwohl wir in diesem Abschnitt die Konfiguration aller Geräte (PCC und der drei Router) präsentieren, wird im Schritt-für-Schritt-Verfahren nur die Konfiguration des PCC dokumentiert.

Pcc

Router R1

Router R2

Router R3

Verfahren
Schritt-für-Schritt-Verfahren

In diesem Beispiel konfigurieren wir nur PCC.

Für die folgenden Schritte müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zur Navigation auf der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI Benutzerhandbuch.

So konfigurieren Sie das PCC:

  1. Konfigurieren Sie die Schnittstellen des PCC.

  2. Konfigurieren Sie die Router-ID und weisen Sie dem PCC eine autonome Systemnummer zu.

  3. Konfigurieren Sie eine statische Route von PCC zu Router R3.

    Die statische Route wird nur zu Überprüfungszweck erstellt und beeinträchtigt nicht die Funktionen.

  4. Konfigurieren Sie RSVP auf allen Schnittstellen des PCC, außer auf der Verwaltungsschnittstelle.

  5. Konfiguration MPLS auf allen Schnittstellen des PCC außer auf der Verwaltungsschnittstelle.

  6. Ermöglichen Sie externe Path Computing-Funktionen für MPLS.

  7. Konfiguration IS-IS Level 2 auf allen Schnittstellen des PCC, außer an Verwaltungs- und Loopback-Schnittstellen.

  8. Konfiguration von globalen Segment-Routing-Block-Attributen (SRGB) für Segment-Routing

  9. Ermöglichen Sie externe Path Computing-Funktionen für SR-TE.

  10. Konfigurieren Sie die PCE-Parameter und aktivieren Sie die Bereitstellung des LSP durch das PCE und die Segment-Routing-Funktion.

  11. Ermöglichen die Bereitstellung von Segment-Routing-LSPs über das PCE.

  12. Aktivieren der Segment-Routing-Funktion für den PCE.

  13. Definieren Sie die statischen static_seg_list_1 Segmentlistenparameter.

  14. Konfigurieren Sie ein statisches Segment-Routing LSP von PCC zu Router R3 zur PCE-Delegierung.

  15. Aktivieren der Delegierungsfunktion für den static_srte_lsp_1 Source-Routing-Pfad

    In Abschluss der Schritte 13, 14 und 15 können Sie dem PCC die Segment-Routing-LSPs an das PCE delegieren.

  16. Commit für die Konfiguration.

Ergebnisse

Bestätigen Sie Ihre Konfiguration im Konfigurationsmodus, indem Sie die show interfacesshow routing-options , und Befehle show protocols eingeben. Wenn in der Ausgabe nicht die beabsichtigte Konfiguration angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Wenn Sie die Konfiguration des Geräts (des PCC) erledigt haben, geben Sie commit diesen aus dem Konfigurationsmodus ein.

Überprüfung

Stellen Sie sicher, dass die Konfiguration ordnungsgemäß funktioniert.

Überprüfen der IS-IS von Adjacency und Labels
Zweck

Überprüfen Sie IS-IS auf dem PCC. Beachten Sie den SRGB-Labelbereich, Adjacency- und Node-Segmentwerte sowie DIE SPRING-Funktion-Ausgabefelder.

Aktion

Führen Sie im Betriebsmodus die show isis adjacency extensive , show isis database extensive und Befehle show isis overview aus.

Bedeutung

Die IS-IS zwischen PCC und PCE und die zwischen PCC und Router R1 sind einsatzbereit. Die Ausgabe zeigt auch die Labelzuweisungen für die benachbarten Segmente und Knotensegmente an.

Überprüfen der Traffic Engineering-Datenbank
Zweck

Überprüfen der Einträge der Traffic-Engineering-Datenbank auf dem PCC

Aktion

Führen Sie im Betriebsmodus den show ted database extensive Befehl aus.

Bedeutung

Die Traffic-Engineering-Datenbank enthält einträge der Router R1, R2 und R3, die der PCE für externe Path Computing für das PCC verwendet.

SR-TE-LSPs überprüfen
Zweck

Überprüfen Sie die Erstellung von SR-TE-LSPs auf dem PCC.

Aktion

Führen Sie im Betriebsmodus die show path-computation-client lsp , show spring-traffic-engineering lsp detail und Befehle show route protocol spring-te aus.

Bedeutung

Die Ausgänge zeigen, dass zwei SR-TE-LSPs bzw. von der PCE für die adj_sid_lspnode_sid_lsp Adjacency- bzw. Node-Segmente erstellt wurden.

Der Segment-Routing-LSP static_srte_lsp_1 wird mit der Delegierungsfunktion aktiviert. Das Feld zeigt den Steuerungs- und Routingstatus PCE-kursion von LSPs. gibt an, dass das PCE die Kontrolle über die LSPs hat. 5000 PCE hat den ERO für den Delegation infoExternally controlledExternally routed Source-Routing-Pfad bereitgestellt.

Überprüfung der Tunnelroutenerstellung
Zweck

Überprüfen Sie die Tunnelrouten, die für die SR-TE-LSPs erstellt wurden, die in der inet.3-Routingtabelle auf dem PCC enthalten sind.

Aktion

Führen Sie im Betriebsmodus den show route table inet.3 extensive Befehl aus.

Bedeutung

Tunnelrouten wurden für das PCE-gesteuerte LSP-Ziel mit SR-TE als Protokoll-Label erstellt.

Einträge der Weiterleitungstabelle überprüfen
Zweck

Stellen Sie sicher, dass das SR-TE LSP-Ziel zu Router R3 in der Weiterleitungstabelle des PCC installiert ist.

Aktion

Führen Sie im Betriebsmodus den show route forwarding-table destination ip-address extensive Befehl aus.

Bedeutung

Die SR-TE-Ziel-IP-Adresse von LSP zu Router R3 wird als Weiterleitungseingabe installiert.

Überprüfen der Verwendung von Tunnelrouten für die statische Routenweiterleitung
Zweck

Stellen Sie sicher, dass die statische Route die für die SR-TE-LSPs erstellte Tunnelroute nimmt.

Aktion

Führen Sie im Betriebsmodus die und show route ip-address die show route forwarding-table destination ip-address Befehle aus.

Bedeutung

Die Ausgaben zeigen, dass die statische Route zu Router R3 den für den SR-TE LSP erstellten Tunnelroute verwendet.

Statisches Segment-Routing Label Switched Path

Die Segment-Routing-Architektur ermöglicht es den Ingress-Geräten in einem Core-Netzwerk, den Datenverkehr über explizite Pfade zu lenken. Sie können diese Pfade mithilfe von Segmentlisten konfigurieren, um die Pfade zu definieren, die der eingehende Datenverkehr nehmen soll. Der eingehende Datenverkehr kann gekennzeichnet sein oder IP-Datenverkehr, sodass der Weiterleitungsbetrieb auf dem Eingangsgerät entweder als Label Swap oder als zielbasierte Suche bezeichnet wird.

Verständnis des statischen Segment-Routing LSP in MPLS Netzwerken

Source Packet Routing bzw. Segment-Routing ist eine Architektur der Steuerungsebene, die es einem Ingress-Router ermöglicht, Pakete über eine bestimmte Gruppe von Knoten und Verbindungen im Netzwerk zu lenken, ohne sich auf die Zwischenknoten im Netzwerk verlassen zu müssen, um den tatsächlichen Pfad zu bestimmen.

Einführung in Segment-Routing-LSPs

Segment-Routing nutzt das Source-Routing-Paradigma. Ein Gerät steuert ein Paket durch eine geordnete Liste von Anweisungen, die als Segmente bezeichnet werden. Ein Segment kann jede anweisungs-, topologische oder servicebasierte Anweisung darstellen. Ein Segment kann lokalen Semantik zu einem Segment-Routingknoten oder einem globalen Knoten innerhalb einer Segment-Routing-Domäne haben. Segment-Routing setzt einen Datenstrom durch alle topologischen Pfade und Serviceketten durch, wobei der Zustand pro Datenfluss nur am ingress-Gerät zur Segment-Routing-Domäne aufrechterhalten wird. Segment-Routing kann direkt auf die MPLS Routing-Architektur angewendet werden, ohne dass Änderungen an der Weiterleitungsebene möglich sind. Ein Segment wird als Label MPLS codiert. Eine geordnete Reihe von Segmenten wird als Stack von Labels codiert. Das zu verarbeitende Segment ist oben auf dem Stack. Nach Abschluss eines Segments wird das zugehörige Label aus dem Stack entfernt.

Segment-Routing-LSPs können sowohl dynamisch als auch statisch sein.

Dynamic segment routing LSPs—Wenn ein Segment-Routing LSP entweder von einem externen Controller erstellt und über PCEP-Erweiterungen (Path Computation Element Protocol) oder über BGP BGP-Segment-Routing-Erweiterungen auf ein Ingress-Gerät heruntergeladen wird, wird der LSP dynamisch bereitgestellt. Die Segmentliste des dynamischen Segment-Routing-LSP ist im PCEP Explicit Route Object (ERO) oder der BGP-Routing-Richtlinie des LSP enthalten.

Static segment routing LSPs—Wenn ein Segment-Routing-LSP über eine lokale Konfiguration auf dem ingress-Gerät erstellt wird, wird der LSP statisch bereitgestellt.

Ein statisches Segment-Routing LSP kann anhand der Konfiguration der Anweisung auf Hierarchieebene außerdem als nicht-orientierte und nicht-orientierte LSPs color[edit protocols source-packet-routing source-routing-path lsp-name] klassifiziert werden.

Zum Beispiel:

[edit protocols]
    source-packet-routing {
    source-routing-path lsp_name {
        to destination_address;
        color color_value;
        binding-sid binding-label;
        primary segment_list_1_name weight weight;
        ...
        primary segment_list_n_name weight weight;
        secondary segment_list_n_name;
        sr-preference sr_preference_value;
    }
}

Hier bezieht sich jede primäre und sekundäre Aussage auf eine Segmentliste.

[edit protocols]
source-packet-routing {
    segment-list segment_list_name {
        hop_1_name label sid_label;
        ...
        hop_n_name label sid_label;
    }
}

Vorteile bei der Verwendung von Segment-Routing-LSPs

  • Statisches Segment-Routing ist nicht auf den LSP-Weiterleitungsstatus auf Transitroutern angewiesen. So müssen sie nicht mehr pro LSP-Weiterleitungsstatus im Kern bereitgestellt und aufrechterhalten werden.

  • Höhere Skalierbarkeit für die MPLS bereitstellen.

statisches Segment-Routing LSP

Ein statisches Segment-Routing mit der Anweisung wird color als statischer LSP bezeichnet.

Verständnis des statischen Segment-Routing lSPs

Ähnlich wie BGP-Richtlinie für das Segment-Routing wird auch der Ingress-Routing-Weg des gleichzeitig in den oder den Routing-Tabellen installierten LSP, mit dem Schlüssel für die Zuordnung von inetcolor.0inet6color.0destincation-ip-address, color IP-Datenverkehr.

Statisches Segment-Routing LSP kann über ein bindings SID verfügen, für das eine Route in der mpls.0 Routingtabelle installiert wird. Diese Sid-Label-Binding werden verwendet, um gekennzeichneten Datenverkehr dem Segment-Routing-LSP zuordnen. Die Gateways der Route stammen aus den Segmentlistenkonfigurationen der primären und sekundären Pfade.

Segmentliste der Segment-Routing-LSPs

Die statischen Segment-Routing-LSPs haben bereits die Unterstützung für den first Hop Label-Modus des Auflösens eines LSP widerlegt. Der IP-Modus im ersten Hop wird jedoch nicht unterstützt, um Segment-Routing-LSPs zu unterstützen. Ab dem Junos OS Veröffentlichungs-19.1R1 wird eine Commit-Prüfung-Funktion eingeführt, um sicherzustellen, dass alle Segmentlisten, die zu den Routen beitragen, über das minimale Label für alle Hops verfügen. Wird diese Anforderung nicht erfüllt, wird das Commit blockiert.

Nicht-statisches Segment-Routing LSP

Ein statischer Segment-Routing-LSP, der ohne die Anweisung konfiguriert color ist, ist ein nicht-nicht-kanner LSP. Ähnlich wie bei PCEP-Segment-Routing-Tunneln wird auch der Ingress-Route in den bzw. den inet.3inet6.3 Routing-Tabellen installiert.

Junos OS unterstützt statische Segment-Routing-LSPs auf Ingress-Routern. Sie können nicht-statisches Segment-Routing LSP bereitstellen, indem Sie einen Gerouteten Pfad aus einer Quelle und eine oder mehrere Segmentlisten konfigurieren. Diese Segmentlisten können für mehrere nicht-orientierte Segment-Routing-LSPs verwendet werden.

Nicht-orientierte Segment-Routing-LSPs verstehen

Das nicht-orientierte Segment-Routing LSP hat einen eindeutigen Namen und eine Ziel-IP-Adresse. Ein Ingress-Route zum Ziel wird in der inet.3-Routingtabelle mit einer Standardpräferenz von 8 und einer Kennzahl von 1 installiert. Auf diese Weise können Services, die nicht zu einer bestimmten Methode gehören, dem LSP des Segment-Routings zugeordnet werden, der sich auf das Ziel bezieht. Wenn der nicht-orientierte Segment-Routing-LSP keine Ingress-Route erfordert, kann die Ingress-Route deaktiviert werden. Ein nicht-zielorientiertes Segment-Routing LSP verwendet ein bindes SID-Label, um Das Segment-Routing LSP-Stitching zu erreichen. Diese Bezeichnung kann verwendet werden, um das Segment-Routing LSP als Segment zu modellieren, das weiter zur hierarchischen Errichtung anderer Segment-Routing-LSPs verwendet werden kann. Der Transit des verbindlichen SID-Labels hat standardmäßig die Einstellung 8 und die Kennzahl 1.

Beginnend mit Junos OS Release 18.2R1 werden statisch konfigurierte nicht-orientierte Segment-Routing-LSPs auf dem ingress-Gerät wird der Path Computation Element (PCE) über eine Path Computation Element Protocol (PCEP)-Sitzung gemeldet. Diese nicht-vollständigen Segment-Routing-LSPs verfügen möglicherweise über zugehörige Sid-Label (Service Identifier). Mit dieser Funktion kann der PCE dieses binding SID-Label im Labelstack verwenden, um PCE-initiierte Segment-Routing-LSP-Pfade zu bereitstellen.

Ein nicht-zielorientiertes Segment-Routing LSP kann maximal 8 primäre Pfade haben. Wenn es mehrere primäre Betriebspfade gibt, verteilt die Packet Forwarding Engine (PFE) den Datenverkehr über die Pfade basierend auf den Lastausgleichsfaktoren wie das auf dem Pfad konfigurierte Gewicht. Dies ist das gleiche Kosten-Multi-Path-System (ECMP), wenn keiner der Pfade über eine Gewichtung verfügt, die darauf konfiguriert ist, oder wenn mindestens ein Pfad ein Nullgewicht auf den Pfaden konfiguriert hat. In beiden Fällen, wenn ein oder ein Teil der Pfade ausfällt, bringt das PFE den Datenverkehr über die verbleibenden Pfade ins Gleichgewicht, was automatisch zum Schutz des Pfads führt. Ein nicht-segmentiertes Routing LSP kann einen sekundären Pfad zum dedizierten Pfadschutz haben. Bei einem Ausfall eines Primärpfads führt das PFE einen Ausgleich des Datenverkehrs zu den restlichen funktionalen Primärpfaden durch. Andernfalls wechselt die PFE den Datenverkehr zum Backup-Pfad und erreicht so den Pfadschutz. Ein nicht-segmentiertes Routing LSP kann eine Kennzahl für seine [edit protocols source-packet-routing source-routing-path lsp-name] Ingress- und Binding-SID-Routen angeben. Mehrere nicht-orientierte Segment-Routing-LSPs haben dieselbe Zieladresse, die zum nächsten Hop der ingress-Route beikommt.

Mehrere nicht-orientierte Segment-Routing-LSPs haben dieselbe Zieladresse, die zum nächsten Hop der ingress-Route beikommt. Jeder (primäre oder sekundäre) Pfad jedes Segment-Routing LSP wird als Gateway-Kandidat angesehen, wenn dieser Pfad funktionsfähig ist und der Segment-Routing-LSP die bevorzugte Lösung für alle diese Segment-Routing-LSPs hat. Die maximale Anzahl von Gateways, die im nächsten Hop enthalten sein kann, kann jedoch die RpD-Begrenzung auf mehreren Pfaden (standardmäßig 128) nicht überschreiten. Neue Pfade werden beschnitten, zuerst sekundäre Pfade und dann primäre Pfade. Eine bestimmte Segmentliste kann von diesen Segment-Routing-LSPs mehrmals als primäre oder sekundäre Pfade bezeichnet werden. In diesem Fall gibt es mehrere Gateways mit jeweils einer eindeutigen LSP-Tunnel-ID für Segment-Routing. Diese Gateways sind unterschiedlich, obwohl sie den identischen ausgehenden Labelstack und die Schnittstelle haben. Ein nicht-zielorientiertes Segment-Routing LSP und ein gleichzeitiger Segment-Routing-LSP hat eventuell dieselbe Zieladresse. Sie korrespondieren jedoch zu unterschiedlichen Zieladressen für die Ingress-Routen, da das Zieladresse des Segment-Routings sowohl mit seiner Zieladresse als auch mit seiner Farbe erstellt wird.

Anmerkung:

Wenn ein statisches nicht-protokolliertes Segment-Routing LSP und ein von PCEP erstelltes Segment-Routing vorhanden ist, gibt es LSP und diese gleichzeitig die gleiche Adresse haben, die zum selben Ingress-Routing bei trägt, wenn sie dieselbe Präferenz haben. Andernfalls wird der LSP für das Segment-Routing mit der besten Einstellung für die Route installiert.

Segmentliste nicht-orientierte Segment-Routing-LSPs

Eine Segmentliste besteht aus einer Liste von Hops. Diese Hops basieren auf dem SID-Label oder einer IP-Adresse. Die Anzahl der SID-Label in der Segmentliste sollte die maximale Anzahl von Segmentlisten nicht überschreiten. Die maximale Segmentlistenbindung an einen LSP-Tunnel wird von 8 auf 128 erhöht, mit max. 1.000 Tunneln pro System. Pro statischem Segment-Routing-LSP werden maximal 128 primäre Pfade unterstützt. Sie können die maximale Begrenzung der Segmentliste auf der [edit protocols source-packet-routing] Hierarchieebene konfigurieren.

Bevor Junos OS 19.1R1 veröffentlicht wurde, musste der erste Hop der Segmentliste eine IP-Adresse einer ausgehenden Schnittstelle und der zweite bis n thHops SID-Labels sein, damit ein statischer Segment-Routing-LSP verwendet werden kann. Ab dem Junos OS Veröffentlichungs-19.1R1 gilt diese Anforderung nicht mehr, da der erste Hop der statischen LSPs nicht-statische lSPs neben IP-Adressen auch SID-Labels unterstützt. Durch die Unterstützung des ersten Hop-Labels ist MPLS Fast Reroute (FRR) und Weighted Equal-Cost-Multipath zum Lösen der statischen nicht-unserenkenden Segment-Routing-LSPs aktiviert, ähnlich wie statische LSPs.

Damit der First-Hop-Labelmodus wirksam wird, müssen Sie die Anweisung global oder individuell für eine Segmentliste angeben, und der erste Hop der Segmentliste muss sowohl IP-Adresse als auch Label inherit-label-nexthops enthalten. Wenn der erste Hop nur die IP-Adresse enthält, hat die inherit-label-nexthops Anweisung keine Auswirkungen.

Sie können in inherit-label-nexthops jeder der folgenden Hierarchien konfigurieren. Die Aussage wird nur dann wirksam, wenn der erste Hop inherit-label-nexthops der Segmentliste sowohl IP-Adresse als auch Label enthält.

  • Segment list level- Auf [edit protocols source-packet-routing segment-list segment-list-name] Hierarchieebene.

  • Globally- Auf [edit protocols source-packet-routing] Hierarchieebene.

Wenn die Anweisung global konfiguriert wird, hat sie Vorrang vor der Konfiguration auf Segmentlisteebene und die Konfiguration wird auf inherit-label-nexthopsinherit-label-nexthops alle Segmentlisten angewendet. Wenn die Anweisung nicht global konfiguriert ist, werden nur Segmentlisten mit sowohl den Labels als auch der IP-Adresse im ersten Hop gelöst und mit Anweisungen konfiguriert mithilfe von inherit-label-nexthopsinherit-label-nexthops SID-Labels gelöst.

Bei dynamischen nicht-statischen LSPs, d. b. PCEP-gesteuerten Segment-Routing-LSPs, muss die Anweisung global aktiviert werden, da die Konfiguration auf Segmentebene inherit-label-nexthops nicht angewendet wird.

Tabelle 4 beschreibt den Modus der Segment-Routing-LSP-Auflösung basierend auf der First Hop-Spezifikation.

Tabelle 4: Nicht-statische LSP-Auflösung basierend auf First Hop-Spezifikation

First Hop-Spezifikation

Modus der LSP-Auflösung

Nur IP-Adresse

Zum Beispiel:

segment-list path-1 {
    hop-1 ip-address 172.0.12.2;
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

Die Segmentliste wird über die IP-Adresse gelöst.

Nur SID

Zum Beispiel:

segment-list path-2 {
    hop-1 label 1000011;
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

Die Segmentliste wird mithilfe von SID-Labels gelöst.

IP-Adresse und SID (ohne inherit-label-nexthops Konfiguration)

Zum Beispiel:

segment-list path-3 {
    hop1 {
        label 801006;
        ip-address 172.24.1.2;
    }
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

Standardmäßig wird die Segmentliste mithilfe der IP-Adresse gelöst.

IP-Adresse und SID (mit inherit-label-nexthops der Konfiguration)

Zum Beispiel:

segment-list path-3 {
    inherit-label-nexthops;
    hop1 {
        label 801006;
        ip-address 172.24.1.2;
    }
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

Die Segmentliste wird mithilfe von SID-Labels gelöst.

Sie können mit dem Befehl die show route ip-address protocol spring-te active-path table inet.3 nicht-orientierte Segment-Routing-Datenverkehrs-LSPs anzeigen, die mehrere Segmentlisten in der inet.3-Routingtabelle installiert haben.

Zum Beispiel:

Anmerkung:

Der erste Hop der Segmentliste eines statischen Segment-Routing LSP kann zu einem Commit-Fail führen, wenn:

  • Die verschiedenen Segmentlisten eines Tunnels haben unterschiedliche Typen von First Hop-Auflösungen. Dies gilt sowohl für statische Segment-Routing-LSPs als auch für nicht-statische Segment-Routing-LSPs. Dies gilt jedoch nicht für PCEP-gesteuerte LSPs. eine Systemprotokollnachricht wird generiert, wenn der Typ der ersten Hop-Auflösung zum Zeitpunkt der Berechnung des Pfads nicht stimmen wird.

    Zum Beispiel:

    Das Commit von Tunnel lsp1 schlägt fehl, da Pfad 1 vom IP-Adressmodus und pfad 2 im Label-Modus ist.

  • Die Bindung von SID ist für den statischen nicht-inverfingierten LSP aktiviert, dessen Segmentlistentyp ein SID-Label ist.

    Zum Beispiel:

    Die Konfiguration von SID über Label-Segmentliste wird nur für statische LSPs unterstützt, nicht aber für statische LSPs, die keine statischen LSPs haben.

Statisches Segment-Routing LSP-Bereitstellung

Die Segmentbereitstellung wird je nach Router durchgeführt. Für ein bestimmtes Segment auf einem Router wird ein eindeutiger Sid-Label (Service Identifier) von einem gewünschten Label-Pool zugewiesen, der aus dem dynamischen Labelpool für ein SID-Label (Adjacency) oder aus dem segment routing global Block (SRGB) eines Prefix-SID oder eines Sid-Knotens enthalten sein kann. Das SID-Label zur Adjacency kann dynamisch zugewiesen werden, was das Standardverhalten ist, oder von einem lokalen statischen Label-Pool (SRLB) zugewiesen werden. Ein Route für das SID-Label wird dann in der mpls.0-Tabelle installiert.

Junos OS statische Segment-Routing-LSPs durch Konfiguration der segment Anweisung auf [edit protocols mpls static-label-switched-path static-label-switched-path] Hierarchieebene. Ein statisches Segment-LSP wird durch ein eindeutiges SID-Label identifiziert, das unter den statischen Junos OS Label-Pool fällt. Sie können den statischen Junos OS Label-Pool konfigurieren, indem Sie die static-label-range static-label-range Anweisung auf der [edit protocols mpls label-range] Hierarchieebene konfigurieren.

Statisches Segment-Routing LSP-Einschränkungen

  • Junos OS hat derzeit eine Einschränkung, dass der nächste Hop nicht so erstellt werden kann, dass er mehr als die Label mit maximaler Segmentlistentiefe unterstützt. Daher ist eine Segmentliste mit mehr als den maximalen SID-Labeln (außer dem SID-Label des ersten Hops, der zum Lösen des Weiterleitungs-Next-Hops verwendet wird) nicht für segmentierte oder nicht-bare Segment-Routing-LSPs nutzbar. Zudem liegt die tatsächliche Anzahl eines bestimmten Segment-Routing-LSP sogar unter der maximal zulässigen Grenze. Wenn ein MPLS-Service auf dem Segment-Routing-LSP oder der Segment-Routing-LSP auf einer Verbindung oder einem Knotenschutzpfad liegt. In jedem Fall darf die Gesamtanzahl an Service-Labeln, SID-Labels und Verbindungs- bzw. Node-Schutz-Labels nicht die maximale Tiefe der Segmentliste übersteigen. Sie können die maximale Begrenzung der Segmentliste auf [edit protocols source-packet-routing] Hierarchieebene konfigurieren. Mehrere nicht-unserentorientierte Segment-Routing-LSPs, die weniger oder gleich die maximalen SID-Labels sind, können zum Aufbau eines längeren Segment-Routing-LSP miteinander verbinden. Dies wird als Segment-Routing und LSP-Stitching bezeichnet. Das lässt sich mit einem Binding-SID-Label erreichen.

  • Das Segment-Routing LSP-Stitching wird tatsächlich auf Pfadebene ausgeführt. Wenn ein nicht-orientiertes Segment-Routing mehrere Pfade hat, die mehrere Segmentlisten enthalten, kann jeder Pfad unabhängig von einem nicht-orientierten Segment-Routing-LSP an einem Stitching-Punkt unabhängig miteinander genähet werden. Ein nicht-orientiertes Segment-Routing LSP, der speziell für Stitching verwendet wird, kann die Installation des Ingress-Route deaktivieren, indem Anweisungen no-ingress auf [edit protocols source-packet-routing source-routing-path lsp-name] Hierarchieebene konfiguriert werden.

  • Pro statischem Segment-Routing-LSP werden maximal 12 8 Primärpfade und 1 sekundärer Pfad unterstützt. Bei einem Konfigurationsverstoß schlägt die Commit-Prüfung mit einem Fehler fehl.

  • Die maximale Segmentlistenbindung an einen LSP-Tunnel wird von 8 auf 128 erhöht, mit max. 1.000 Tunneln pro System. Pro statischem Segment-Routing-LSP werden maximal 128 primäre Pfade unterstützt. Als Einschränkung gilt, dass die maximale Sensorunterstützung für den LSP-Pfad nur 32000 beträgt.

  • Wenn eine Segmentliste mit mehr Labeln als die maximale Segmentlistentiefe konfiguriert ist, schlägt die Commit-Prüfung der Konfiguration mit einem Fehler fehl.

Dynamische Erstellung von Segment-Routing-LSPs

In Segment-Routing-Netzwerken, in denen die einzelnen Provider-Edge-Geräte (PE-Geräte) mit jedem anderen PE-Gerät verbunden sind, ist eine große Menge an Konfigurationen für die Einrichtung der Segment-Routing Label-Switched Paths (LSPs) erforderlich. Es darf jedoch nur einige wenige Segment Routing Traffic-Engineered (SR-TE)-Pfade verwenden. Sie können die BGP die dynamische Erstellung dieser LSPs aktivieren, um die Konfigurationsmenge in solchen Bereitstellungen zu reduzieren.

Konfigurieren der dynamischen Segment-Routing-LSP-Vorlage

Um die Vorlage zum Aktivieren der dynamischen Erstellung von Segment-Routing-LSPs zu konfigurieren, müssen Sie die Spring-te-Anweisung in der Hierarchie [edit routing-options dynamic-tunnels] enthalten.

  • Im Folgenden finden Sie eine Beispielkonfiguration für die LSP-Vorlage für dynamisches Segment-Routing:

  • Im Folgenden finden Sie eine Beispielkonfiguration für die dynamische LSP-Vorlage für dynamisches Segment-Routing:

Auflösen dynamischer Segment-Routing-LSPs
Auflösen des dynamischsten Segment-Routing-LSP

Wenn die BGP-Präfixe mit einer Farbgemeinschaft zugewiesen werden, werden sie zunächst über die Catch-all-Route-for-that-color-Richtlinie gelöst, und wiederum wird die SR-TE-Vorlage, in der das BGP-Präfix gelöst werden soll, identifiziert. Das Ziel-SID wird dann vom Payload-BGP-Attribut Next-Hop abgeleitet. Wenn der nächste Hop des BGP Payload-Präfixs beispielsweise eine IP-Adresse ist, die zu Gerät A gehört, dann wird das Node-SID von Gerät A aufgenommen und ein entsprechendes Label vorbereitet und an den unteren Rand des Stacks verschoben. Das BGP Payload-Präfix wird im Farbmodus gelöst, wobei sich das Node-SID von Gerät A auf dem letzten Labelstack befindet und die SR-TE-Pfadlabel oben.

Der letzte Name der LSP-Vorlage ist eine Kombination aus Präfix, Farbe und Tunnelname. zum Beispiel <prefix>:<color>:dt-srte-<tunnel-name> . Die Farbe im LSP-Namen wird im Hexadezimalformat angezeigt, und das Format des Tunnelnamens ist mit den von o RSVP ausgelösten Tunnel-LSP-Namen vergleichbar.

Um ein Zielnetzwerk erfolgreich zu lösen, sollte die Farbe über eine gültige Vorlagenzuordnung verfügen, entweder auf eine bestimmte Farbe oder über die color-any Vorlage. Ohne eine gültige Zuordnung wird der Tunnel nicht erstellt, und der BGP, der eine Lösung anfordern soll, bleibt ungeklärt.

Auflösen unfarbiger dynamischer Segment-Routing-LSPs

Die "Catch-all"-Routen für nicht-orientierte LSPs werden der inet.3-Routingtabelle hinzugefügt. Das nicht-zielorientierte Tunnelziel muss in einer anderen Konfiguration mit nur einem Vorlagennamen in der spring-te Zuordnungsliste konfiguriert werden. Dieser Vorlagenname wird für alle Tunnelrouten verwendet, die einem der Zielnetzwerke entsprechend der gleichen Konfiguration spring-te übereinstimmen. Diese Tunnel sind den RSVP-Tunneln in Funktionen ähnlich.

Der letzte Name der LSP-Vorlage ist eine Kombination aus Prefix und Tunnelname. zum Beispiel <prefix>:dt-srte-<tunnel-name> .

Dynamic Segment Routing LSP-Beispielkonfiguration

Die dynamische Segment-Routing-LSP-Vorlage über trägt immer einen teilweisen Pfad. Der SID des letzten Hop-Knotens wird automatisch zum Zeitpunkt der Tunnelerstellung generiert, abhängig vom PNH-Knoten (Protocol Next-Hop Address) des Protokolls. Dieselbe Vorlage kann von mehreren Tunneln zu verschiedenen Zielen verwendet werden. In solchen Fällen bleibt der partielle Pfad gleich, und nur der letzte Hop ändert sich je nach PNH. Dynamisches Segment-Routing LSP-Vorlagen sind nicht in einem einzigen Tunnel enthalten, daher kann ein vollständiger Pfad nicht darüber getragen werden. Wenn ein vollständiger Pfad verwendet werden soll, können Sie eine Segmentliste verwenden.

Dynamische Segment-Routing-LSPs von Überdrungen

Beispielkonfiguration für dynamische Segment-Routing-LSPs:

Für die Beispielkonfiguration oben sind die Routeneinträge wie folgt:

  1. inetcolor.0 tunnel route: 22.33.44.0-0/24 --> RT_NH_TUNNEL

  2. inetcolor6.0 tunnel route: ffff::22.33.44.0-0/120 --> RT_NH_TUNNEL

  3. BGP prefix to tunnel mapping:

    R1 (prefix) -> 22.33.44.55-101(PNH) LSP Tunnel Name = 22.33.44.55:65:dt-srte-tunnel1

    R1(prefix) -> ffff::22.33.44.55-101(PNH) LSP-Tunnelname = 22.33.44.55:65:dt-srte-tunnel1

    R1(prefix) -> ffff::22.33.44.55-124(PNH) LSP-Tunnelname = 22.33.44.55:7c:dt-srte-tunnel1

  4. inetcolor.0 tunnel route:

    22.33.44.55-101/64 --><next-Hop>

    22.33.44.55-124/64 --><next-Hop>

  5. inetcolor6.0 tunnel route:

    ffff::22.33.44.55-101/160 --><next-hop>

    ffff::22.33.44.55-124/160 --><next-Hop>

Nicht-orientierte dynamische Segment-Routing-LSPs

Beispielkonfiguration für nicht-orientierte dynamische Segment-Routing-LSPs:

Für die Beispielkonfiguration oben sind die Routeneinträge wie folgt:

  1. inet.3 tunnel route: 22.33.44.0/24 --> RT_NH_TUNNEL

  2. inet6.3 tunnel route: ffff::22.33.44.0/120 --> RT_NH_TUNNEL

  3. BGP prefix to tunnel mapping:

    R1 (Prefix) - > 22.33.44.55(PNH) LSP-Vorlage Name = LSP1 --- 22.33.44.55:dt-srte-tunnel2

    R1(prefix) -> ffff::22.33.44.55(PNH) LSP-Vorlage Name = LSP1 --- 22.33.44.55:dt-srte-tunnel2

  4. inet.3 tunnel route: 22.33.44.55/32 --><next-Hop>

  5. inet6.3 tunnel route: ffff::22.33.44.55/128 --><next-Hop>

Nicht gelöster dynamischer Segment-Routing-LSP

Beispielkonfiguration für nicht gelöste dynamische Segment-Routing-LSPs:

Für die Beispielkonfiguration oben sind die Routeneinträge wie folgt:

  1. inetcolor.0 tunnel route: 22.33.44.0 - 0/24 --> RT_NH_TUNNEL 1.1.1.0 - 0/24 --> RT_NH_TUNNEL

  2. inetcolor6.0 tunnel route: ffff::22.33.44.0 - 0/120 --> RT_NH_TUNNEL ffff::1.1.1.0 - 0 /24 --> RT_NH_TUNNEL

  3. BGP prefix to tunnel mapping: R1(prefix) -> 22.33.44.55-124(PNH) Tunnel wird nicht erstellt. (Vorlage für die Farbe nicht gefunden).

Überlegungen zur Konfiguration der dynamischen Erstellung von Segment-Routing-LSPs

Berücksichtigen Sie bei der Konfiguration der dynamischen Erstellung von Segment-Routing-LSPs Folgendes:

  • Einer Vorlage kann ein Farbobjekt zugewiesen werden. Wenn die dynamische Tunnelkonfiguration eine Vorlage mit einem Farbobjekt umfasst, müssen Sie spring-te auch alle anderen Vorlagen mit Farbobjekten konfigurieren. Es wird davon ausgegangen, dass alle Ziele innerhalb dieser Konfiguration unterstützt werden.

  • Eine Vorlage kann eine Liste von Farben enthalten, die darauf definiert sind, oder mit dieser Option konfiguriert color-any werden. Beide Optionen können in derselben Konfiguration koexistär spring-te sein. In solchen Fällen haben Vorlagen, die mit bestimmten Farben zugewiesen wurden, eine höhere Präferenz.

  • In einer spring-te Konfiguration kann nur eine Vorlage mit dieser Option definiert color-any werden.

  • Die Zuordnung von Vorlage zu Vorlage erfolgt 1:1. Eine Farbe kann nicht mehreren Vorlagen zuordnen.

  • Der Vorlagenname sollte in der Anweisung unter der Hierarchie konfiguriert werden und diese spring-te[edit protocols] Option aktiviert primary sein.

  • Zielorte, die nicht zu einem anderen Ziel werden, können nicht in derselben Konfiguration spring-te kovergiert werden.

  • Unter verschiedenen Konfigurationseinstellungen können Sie nicht dasselbe Zielnetzwerk mit oder ohne spring-te Farbe konfigurieren.

  • Bei einer nicht-orientierten Konfiguration kann nur spring-te eine Vorlage ohne Farbobjekt konfiguriert werden.

Services, die über Dynamic Segment Routing-LSPs unterstützt werden

Folgende Services werden über dynamische Segment-Routing-LSPs unterstützt:

  • Layer 3-VPN

  • BGP EVPN

  • Richtliniendienste exportieren

Die folgenden Services werden von dynamischen Segment-Routing-LSPs unterstützt, die keine Angebote finden:

  • Layer 3-VPN

  • Layer 2-VPN

  • Multipath-Konfigurationen

Verhalten mit mehreren Tunnelquellen im Segment-Routing

Wenn zwei Quellen Routen vom Segment-Routing zu dem selben Ziel herunterladen (z. B. statische und dynamische Tunnel mit Quellen), wird bei der Auswahl des aktiven Route-Eintrags die Segment-Routingpräferenz verwendet. Ein höherer Wert hat eine bessere Präferenz. Falls die Präferenz dieselben bleibt, wird die Tunnelquelle verwendet, um den Route-Eintrag zu bestimmen.

Dynamic Segment Routing LSPs Limitations

Die dynamischen SR-TE-LSPs unterstützen nicht die folgenden Funktionen:

  • IPv6-Segment-Routing-Tunnel.

  • Statische Tunnel.

  • 6PE wird nicht unterstützt.

  • Verteilte CSPF.

  • sBFD- und LDP-Tunnelling werden für dynamische SR-TE-LSPs und in einer Vorlage nicht unterstützt.

  • Installieren und B-SID-Routen in einer Vorlage.

Farbbasierte Zuordnung von VPN-Services

Sie können Farbe als Protokoll-Next Hop-Einschränkung (zusätzlich zur IPv4- oder IPv6-Adresse) angeben, um Transport-Tunnel über statische Sollen- und BGP SRTE-LSPs (Segment Routing Traffic-Engineered) zu lösen. Dies wird als Next Hop-Auflösung des Color-IP-Protokolls bezeichnet, bei der Sie eine Auflösungszuordnung konfigurieren und auf die VPN-Services anwenden müssen. Mit dieser Funktion können Sie die farbbasierte Steuerung des Datenverkehrs von Layer 2- und Layer 3-VPN-Services aktivieren.

Junos OS unterstützt SRTE-LSPs, die mit einer einzigen Farbe verknüpft werden. Die farbbasierte Zuordnung der VPN-Services-Funktion wird auf statischen nicht statischen LSPs und BGP SRTE-LSPs unterstützt.

VPN Service Coloring

Im Allgemeinen kann einem VPN-Service eine Farbe auf dem Ausgangsrouter zugewiesen werden, für den das VPN-NLRI angekündigt wird, oder auf einem Ingress-Router, auf dem das VPN-NLRI empfangen und verarbeitet wird.

Sie können vpn-Diensten auf verschiedenen Ebenen eine Farbe zuweisen:

  • Pro Routing-Instanz.

  • Pro BGP Gruppe.

  • Pro BGP Nachbar.

  • Pro Präfix.

Sobald Sie eine Farbe zuweisen, wird die Farbe einem VPN-Dienst in Form einer erweiterten BGP zugeordnet.

Sie können einem VPN-Dienst mehrere Farben zuweisen, die als Multi-Color-VPN-Dienste bezeichnet werden. In solchen Fällen wird die zuletzt angehängte Farbe als die Farbe des VPN-Dienstes betrachtet, und alle anderen Farben werden ignoriert.

Verschiedene Farben werden von Ausgangs- und/oder Ingress-Geräten über mehrere Richtlinien in der folgenden Reihenfolge zugewiesen:

  • BGP-Richtlinie auf dem Ausgangsgerät.

  • BGP die Richtlinie auf dem Gerät importieren, das in das Gerät einfing.

  • VRF-Importrichtlinie auf dem Ingress-Gerät.

Die beiden Modi der VPN-Dienstfarbe sind:

Ausgangs-Farbzuweisung

In diesem Modus ist das Ausgangsgerät (d. h. der Inserent des VPN NLRI) für die Colorierung des VPN-Dienstes verantwortlich. Zur Aktivierung dieses Modus können Sie eine Routingrichtlinie definieren und diese auf der Routinginstanz, dem Gruppenexport oder dem Export von Gruppennachbar auf der Hierarchieebene des VPN-Dienstes vrf-export[edit protocols bgp] anwenden. Das VPN NLRI wird von BGP mit der angegebenen farb erweiterten Community ausgeschrieben.

Zum Beispiel:

Oder

Anmerkung:

Wenn Sie die Routingrichtlinie als Exportrichtlinie einer BGP-Gruppe oder eines BGP-Nachbarn anwenden, müssen Sie die Anweisung auf der BGP-, BGP-Gruppe oder BGP-Nachbarebene beinhalten, damit die Richtlinie eine Auswirkung auf das vpn-apply-export VPN-NLRI hat.

Die Routing-Richtlinien werden auf Layer 3 VPN Prefix NLRIs, Layer 2 VPN NRLIs und EVPN NLRIs angewendet. Die farblich erweiterte Community wird von allen VPN-Routen übernommen, importiert und auf einem oder mehreren Ingress-Geräten in die Ziel-VRFs installiert.

Color Assignment (Ingress-Farbzuweisung)

In diesem Modus ist das Ingress-Gerät (d. h. der Empfänger des VPN-NLRI) für die Colorierung des VPN-Dienstes verantwortlich. Um diesen Modus zu aktivieren, können Sie eine Routingrichtlinie definieren und auf die Routinginstanz, den Gruppenimport oder den Import von Gruppennachbar auf der Hierarchieebene vrf-import[edit protocols bgp] anwenden. Alle VPN-Routen, die der Routing-Richtlinie übereinstimmen, werden mit der angegebenen erweiterten Farbgemeinschaft verbunden.

Zum Beispiel:

Oder

Angeben des VPN-Servicezuordnungsmodus

Um flexible Modi für die Zuordnung von VPN-Services festzulegen, müssen Sie eine Richtlinie mithilfe der Anweisung definieren und die Richtlinie in der Routinginstanz, dem Gruppenimport oder dem Import einer Gruppennachbar in der Hierarchieebene eines resolution-map VPN-Dienstes vrf-import[edit protocols bgp] verweisen. Alle VPN-Routen, die der Routingrichtlinie übereinstimmen, werden mit der angegebenen Auflösungszuordnung verbunden.

Zum Beispiel:

Sie können die Importrichtlinie auf die Routinginstanz des VPN-Dienstes anwenden.

Sie können die Importrichtlinie auch auf eine Gruppe oder einen BGP oder BGP anwenden.

Anmerkung:

Jeder VPN-Dienstzuordnungsmodus sollte einen eindeutigen Namen haben, der in der Auflösungszuordnung definiert ist. Die Auflösungskarte unterstützt nur einen einzigen IP-Color-Eintrag, bei dem die VPN-Routen mithilfe eines einheitlichen IP-Protokolls in Form von ip-address:color gelöst werden.

Color-IP-Protocol Next Hop-Auflösung

Der Protokoll-Next-Hop-Auflösungsprozess wird erweitert, um einehilfe-IP-Protokoll-Next-Hop-Auflösung zu unterstützen. Für einen sicheren VPN-Service nimmt der Protokoll-Next-Hop-Auflösungsprozess eine Farbe und eine Auflösungszuordnung, baut einen geistigen IP-Protokoll-Next-Hop in Form von IP-Adresse:colorauf und löst das Protokoll nächsten Hop in der inet6color.0-Routingtabelle.

Sie müssen eine Richtlinie zur Multipath-Lösung konfigurieren, um layer-2-VPN, Layer-3-VPN oder EVPN-Services über mehrfache LSPs zu unterstützen. Die Richtlinie muss dann als Resolver-Importrichtlinie in die entsprechende RIB-Tabelle angewendet werden.

Zum Beispiel:

Fallback zu IP-Protokoll-Next Hop-Auflösung

Wenn für einen vpn-Service eine Lösungszuordnung nicht angewendet wird, ignoriert der VPN-Service seine Farbe und fällt auf die Next-Hop-Auflösung des IP-Protokolls zurück. Im Gegenzug wird die Auflösungszuordnung ignoriert, wenn ein nicht-wiegege vpn-Service eine Lösungszuordnung angewendet wird und der VPN-Service die Next-Hop-Auflösung des IP-Protokolls verwendet.

Das Fallback ist ein einfacher Prozess, der SRTE-LSPs zu LDP-LSPs durch die Verwendung einer RIB-Gruppe für LDP zur Installation von Routen inet{6}color.0-Routingtabellen. Eine längste Prefix-Übereinstimmung für einen 2016-SRTE-Protokoll-Next Hop stellt sicher, dass eine LDP-Route mit einer passenden IP-Adresse zurückgegeben werden sollte, wenn keine SRTE-LSP-Route vorhanden ist.

BGP Unicast Color-basierte Zuordnung über SR-TE

Beginnend mit Junos OS Release 20.2R1 kann BGP Labeled Unicast (BGP-LU) IPv4- oder IPv6-Routen über Segment Routing– Traffic Engineering (SR-TE) für IPv4- und IPv6-Adressfamilien lösen. BGP-LU unterstützt die Zuordnung einer BGP Community-Farbe und das Definieren eines für resolution map SR-TE. Ein erstes Protokoll des nächsten Hops wird in einem SR-TE-Tunnel in der oder der inetcolor.0 Tabelle inet6color.0 gelöst. BGP und inet.3 Tabellen inet6.3 für nicht-farbbasierte Zuordnung. Auf diese Weise können Sie die IPv6- und IPv4-Präfixe von BGP-LU mit einer IPv6-Next-Hop-Adresse in IPv6-Netzwerken anzeigen, in denen auf Routern keine IPv4-Adressen konfiguriert sind. Mit dieser Funktion unterstützen wir derzeit IPv6 BGP LU über SR-TE mit IS-IS Underlay.

In konfiguriert der Controller vier Tunnel in einem Abbildung 9 IPv6-Core-Netzwerk, das mit SR-TE. Jeder Pfad des Tunnels nimmt je nach Definition der Auflösungskarte einen anderen Pfad zum Ziel-Router D. Der Controller konfiguriert einen Zeitsteuerungs-SR-TE-Tunnel zu abcd:3701:2d05 Schnittstelle in Router D. BGP Import von Richtlinien, um dem empfangenen Präfix abcd::3700:6/128 eine Farb- und Auflösungskarte zu zuweisen. Basierend auf der zugewiesenen Community-Farbe löst BGP-LU den nächsten Hop für BGP IPv6 LU-Präfix gemäß der zugewiesenen Auflösungszuordnungsrichtlinie.

Abbildung 9: BGP IPv6 LU über rund um IPv6 SR-TEBGP IPv6 LU über rund um IPv6 SR-TE

BGP-LU unterstützt die folgenden Szenarien:

  • BGP IPv4 LU über 502 BGP IPv4 SR-TE mit ISIS/OSPF IPv4 SR-Erweiterungen.

  • BGP IPv4 LU über statische statische und nicht-orientierte IPv4 SR-TE mit ISIS/OSPF IPv4 SR-Erweiterungen.

  • BGP IPv6 LU über einer BGP IPv6 SR-TE mit ISIS IPv6 SR-Erweiterungen.

  • BGP IPv6 LU über statische nicht-orientierte IPv6 SR-TE mit ISIS IPv6 SR-Erweiterungen.

  • IPv6 Layer 3 VPN-Services mit lokaler IPv6-Adresse und IPv6-Nachbaradresse.

  • IPv6 Layer 3 VPN-Services über BGP IPv6 SR-TE mit ISIS IPv6 SR-Erweiterungen.

  • IPv6 Layer 3 VPN-Services über statisches und nicht-orientiertes IPv6 SR-TE mit ISIS IPv6 SR-Erweiterungen.

Unterstützte und nicht mehr unterstützte Funktionen für die farbbasierte Zuordnung von VPN-Diensten

Bei der farbbasierten Zuordnung von VPN-Services werden die folgenden Funktionen und Merkmale unterstützt:

  • BGP Layer 2 VPN (Kompella Layer 2 VPN)

  • BGP EVPN

  • Lösungszuordnung mit einer Option mit nur IP-Farbe.

  • IPv4- und IPv6-Protokoll-Next-Hop-Auflösung unterstützen.

  • Routing Information Base (auch als Routing-Tabelle bekannt) basierend auf Fallback zu LDP LSP inetcolor.0 Routing-Tabelle.

  • SrTE-LSP von Zeit zu Zeit.

  • Virtuelle Plattformen.

  • 64-Bit-Junos OS.

  • Logische Systeme.

  • BGP-Label.

Die folgenden Funktionen werden bei der farbbasierten Zuordnung von VPN-Services nicht unterstützt:

  • Daher MPLS LSPs wie RSVP, LDP, BGP-LU, statisch.

  • Layer-2-Verbindung

  • FEC-129 BGP Layer 2-VPN mit automatischer Entdeckung und LDP-Signalen.

  • VPLS

  • MVPN

  • IPv4 und IPv6 mit Auflösungszuordnung.

Tunnelvorlagen für vom PCE initiierte Segment-Routing-LSPs

Sie können eine Tunnelvorlage für vom PCE initiierte Segment-Routing-LSPs konfigurieren, um zwei zusätzliche Parameter für diese LSPs weiter zu geben: Bidirectional Forwarding Detection (BFD) und LDP-Tunneling.

Beim Erstellen eines PCE-initiierten Segment-Routing-LSP wird der LSP gegen Richtlinien anweisungen geprüft (falls enthalten). Wenn eine Übereinstimmung besteht, wendet die Richtlinie die konfigurierte Vorlage für diesen LSP an. Die Vorlagenkonfiguration wird nur übernommen, wenn sie nicht von der LSP-Quelle (PCEP) bereitgestellt wird. beispielsweise die Metrik.

So konfigurieren Sie eine Vorlage:

  1. Fügen Sie die Anweisung der Quell-Routingpfad-Vorlage auf der [edit protocols source-packet-routing] Hierarchieebene bei. Sie können die zusätzlichen BFD- und LDP-Tunnelparameter hier konfigurieren.

  2. Fügen Sie die Anweisung source-routing-path-template-map auf der Hierarchieebene hinzu, um die Richtlinien anweisungen auflisten zu können, für die der [edit protocols source-packet-routing] PCE-initiierte LSP geprüft werden soll.

  3. Definieren Sie eine Richtlinie, die auf die LSPs auflistet, auf die die Vorlage angewendet werden soll.

    Die from Anweisung kann entweder den LSP-Namen oder den regelmäßigen LSP-Ausdruck mithilfe der und den Bedingungen lsplsp-regex enthalten. Diese Optionen schließen sich gegenseitig aus, sodass Sie nur eine Option zu einem bestimmten Zeitpunkt angeben können.

    Der then Statement muss die Option mit einer sr-te-template Accept-Aktion enthalten. Dies wendet die Vorlage auf den PCE-initiierten LSP an.

Berücksichtigen Sie bei der Konfiguration einer Vorlage für PCE-initiierte LSPs Folgendes:

  • Die Vorlage ist nicht auf statisch konfigurierte Segment-Routing-LSPs oder andere Segment-Routing-LSP-Clients anwendbar.

  • Die PCEP-bereitgestellte Konfiguration hat Vorrang vor der Vorlagenkonfiguration.

  • PCEP LSP erbt nicht die Konfiguration von Vorlagensegmentlisten.

Beispiel: Konfigurieren des statischen Segment-Routing Label Switched Path

In diesem Beispiel wird gezeigt, wie Sie statische Segment-Routing-Label-Switched Paths (LSPs) in netzwerken MPLS konfigurieren. Mit dieser Konfiguration wird die Skalierbarkeit von Netzwerken MPLS verbessert.

Anforderungen

In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:

  • Sieben 5G-5G-Universelle Routing-Plattformen

  • Junos OS Version 18.1 oder höher, die auf allen Routern ausgeführt wird

Bevor Sie damit beginnen, konfigurieren Sie die Geräteschnittstellen.

Überblick

Junos OS auf dem Ingress-Router eines statischen Segment-Routing-Tunnels, der die Anweisung auf der Hierarchieebene konfiguriert, eine Reihe von Explicit Segment Routing-Pfaden segment-list [edit protocols source-packet-routing] konfiguriert. Sie können Segment-Routing-Tunnel konfigurieren, indem Sie die source-routing-path Anweisung auf [edit protocols source-packet-routing] Hierarchieebene konfigurieren. Der Segment-Routing-Tunnel verfügt über eine Zieladresse und einen oder mehrere Primärpfade sowie optional sekundäre Pfade, die sich auf die Segmentliste beziehen. Jede Segmentliste besteht aus einer Folge von Hops. Bei nicht-statischem Segment-Routing-Tunnel gibt der erste Hop der Segmentliste eine sofortige IP-Adresse für den nächsten Hop an, und der zweite an Nth-Hop gibt das Segment an, das die SID-Label identifiziert, die dem Link oder Knoten, über den der Pfad führt, entspricht. Die Route zum Ziel des Segment-Routing-Tunnels wird in der Inet.3-Tabelle installiert.

Topologie

In diesem Beispiel konfigurieren Sie Layer 3-VPN auf den Provider-Edge-Routern PE1 und PE5. Konfigurieren Sie MPLS auf allen Routern. Der Segment-Routing-Tunnel wird von Router-PE1 zu Router-PE5 mit einem auf Router-PE1 und Router-PE5 konfigurierten primären Pfad konfiguriert. Router-PE1 ist zum Pfadschutz auch mit sekundären Pfaden konfiguriert. Die Transitrouter PE2 to PE4 sind mit SID-Adjacency-Labels mit Label-Pop und einer ausgehenden Schnittstelle konfiguriert.

Abbildung 10: Statisches Segment-Routing Label Switched PathStatisches Segment-Routing Label Switched Path

Konfiguration

CLI-Konfiguration

Um dieses Beispiel schnell konfigurieren zu können, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenbrüche, ändern Sie alle Details, die zur Übereinstimmung mit Ihrer Netzwerkkonfiguration erforderlich sind, kopieren Sie die Befehle, kopieren Sie die Befehle in die CLI der Hierarchieebene, und geben Sie sie dann im Konfigurationsmodus [edit]commit ein.

PE1

PE2

PE3

PE4

PE5

CE1

CE2

Gerät-PE1-Konfiguration
Schritt-für-Schritt-Verfahren

Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zur Navigation auf der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI Benutzerhandbuch.

So konfigurieren Sie Geräte-PE1:

  1. Konfigurieren Sie die Schnittstellen.

  2. Konfigurieren Sie autonome Systemnummer und -optionen zur Steuerung der Paketweiterleitungs-Routing-Optionen.

  3. Konfigurieren Sie die Schnittstellen mit dem MPLS protokoll und konfigurieren Sie den MPLS Labelbereich.

  4. Konfigurieren Sie den Typ einer Peergruppe, lokalen Adresse, Protokollfamilie für NLRIs in Updates und die IP-Adresse eines Nachbarn der Peergruppe.

  5. Konfigurieren Sie die Schnittstellen für den Protokollbereich.

  6. Konfigurieren Sie die IPv4-Adressen und -Labels der primären und sekundären Pfade für das Source Routing Traffic Engineering (TE)-Richtlinien des Protocol Source Packet Routing (SPRING).

  7. Konfigurieren der Ziel-IPv4-Adresse, Bindung von SID-Label, primärem und sekundären Quellroutingpfad für Protokoll SPRING.

  8. Konfigurieren Sie Richtlinienoptionen.

  9. Konfiguration BGP Community-Informationen.

  10. Konfigurieren Sie Routing-Instanz VRF1 mit Instanztyp, Schnittstelle, Router-Distinguisher, VRF-Import, Export und Tabellen-Label. Konfigurieren Sie die Exportrichtlinie und die Schnittstelle von Area für die OSPF.

Ergebnisse

Bestätigen Sie Ihre Konfiguration im Konfigurationsmodus, indem Sie die show interfaces , , und Befehle show policy-optionsshow protocolsshow routing-optionsshow routing-instances eingeben. Wenn in der Ausgabe nicht die beabsichtigte Konfiguration angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Geräte-PE2 konfigurieren
Schritt-für-Schritt-Verfahren

Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zur Navigation auf der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI Benutzerhandbuch.

  1. Konfigurieren Sie die Schnittstellen.

  2. Konfigurieren Sie den statischen LSP für MPLS.

  3. Konfiguration von Schnittstellen und statischem Label-Bereich für MPLS.

  4. Schnittstellen für Protokoll-OSPF.

Ergebnisse

Bestätigen Sie Ihre Konfiguration im Konfigurationsmodus auf Router-PE2, indem Sie die show interfacesshow protocols Und-Befehle eingeben. Wenn in der Ausgabe nicht die beabsichtigte Konfiguration angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Überprüfung

Stellen Sie sicher, dass die Konfiguration ordnungsgemäß funktioniert.

Überprüfung des Routeneinstiegs von Routing-Tabelle inet.3 von Router-PE1
Zweck

Überprüfen Sie den Routeneinstieg der Routing-Tabelle inet.3 von Router-PE1.

Aktion

Geben Sie im Betriebsmodus den Befehl show route table inet.3 ein.

Bedeutung

Die Ausgabe zeigt die Ingress-Routen der Segment-Routing-Tunnel an.

Überprüfung von Routentabellen-Einträgen von Routing-Tabelle mpls.0 von Router-PE1
Zweck

Überprüfen der Routeneinträge von Routing-Tabelle mpls.0

Aktion

Geben Sie im Betriebsmodus den Befehl show route table mpls.0 ein.

Bedeutung

Die Ausgabe zeigt die SID-Label der Segment-Routing-Tunnel an.

Überprüfung von SPRING Traffic Engineered LSP von Router-PE1
Zweck

Überprüfen der SPRING Traffic Engineered-LSPs auf den Ingress-Routern

Aktion

Geben Sie im Betriebsmodus den Befehl show spring-traffic-engineering overview ein.

Bedeutung

Die Ausgabe zeigt den Überblick über spring traffic engineered LSPs auf dem Ingress-Router an.

Überprüfung von SPRING Traffic Engineered-LSPs auf dem Ingress-Router von Router-PE1
Zweck

Überprüfen der SPRING Traffic Engineered-LSPs auf dem Ingress-Router

Aktion

Geben Sie im Betriebsmodus den Befehl show spring-traffic-engineering lsp detail ein.

Bedeutung

Die Ausgabe zeigt Details zu SPRING Traffic Engineered-LSPs auf dem Ingress-Router an

Überprüfen der Routing-Tabelleneinträge von Routing-Tabelle mpls.0 von Router-PE2
Zweck

Überprüfen der Routing-Tabelleneinträge von Routing-Tabelle mpls.0 von Router-PE2.

Aktion

Geben Sie im Betriebsmodus den Befehl show route table mpls.0 ein.

Überprüfung des Status statischer Netzwerk MPLS LSP-Segmente von Router-PE2
Zweck

Überprüfen des Status der MPLS LSP-Segmente von Router-PE2

Aktion

Geben Sie im Betriebsmodus den Befehl show mpls static-lsp ein.

Bedeutung

Die Ausgabe zeigt den Status statischer Netzwerksegmente MPLS LSP-Segmenten von Router-PE2 an.

Ermöglichung verteilter CSPF für Segment-Routing-LSPs

Bevor Junos OS Version 19.2R1S1 für das Traffic-Engineering von Segment-Routing-Pfaden veröffentlicht wurde, können Sie entweder statische Pfade explizit konfigurieren oder Computerpfade von einem externen Controller verwenden. Mit der distributed Constrained Shortest Path First (CSPF) für Segment-Routing-LSP-Funktion können Sie einen Segment-Routing-LSP lokal auf dem Ingress-Gerät entsprechend den konfigurierten Einschränkungen berechnet. Mit dieser Funktion werden die LSPs auf Grundlage der konfigurierten Einschränkungen und des metrikbasierten Typs (Traffic-Engineering oder Traffic-Engineering oder IGP) optimiert. Die LSPs werden zur Nutzung der verfügbaren ECMP-Pfade zum Ziel berechnet, bei aktivierter oder deaktivierter Segment-Routing-Labelstack-Komprimierung.

Verteilte CSPF-Berechnungseinschränkungen

Die LSP-Pfade für Segment-Routing werden berechnet, wenn alle konfigurierten Einschränkungen erfüllt werden.

Die verteilte CSPF-Berechnungsfunktion unterstützt die folgenden Im Internet-Entwurf festgelegten Einschränkungen, draft-ietf-spring-segment-routing-policy-03.txt, Segment Routing-Richtlinie für Traffic Engineering:

  • Einbeziehung und Ausschluss administrativer Gruppen.

  • Einbeziehung von losen oder Strict-Hop-IP-Adressen.

    Anmerkung:

    Sie können nur Router-IDs in losen oder strengen Hop-Einschränkungen angeben. Label und andere IP-Adressen können nicht als lose oder strikte Hop-Beschränkungen in Junos OS Release 19.2R1-S1 festgelegt werden.

  • Maximale Anzahl von Segment-IDs (SIDs) in der Segmentliste.

  • Maximale Anzahl von Segmentlisten pro Kandidaten-Segment-Routingpfad.

Die verteilte CSPF-Berechnungsfunktion für Segment-Routing-LSPs unterstützt nicht die folgenden Arten von Beschränkungen und Implementierungsszenarien:

  • IPV6-Adressen

  • Inter-Domain-Segment-Routing Traffic Engineering (SRTE)-LSPs.

  • Nicht innummerierte Schnittstellen.

  • Mehrere Protokolle für Routing, wie OSPF, ISIS und BGP-LS, sind gleichzeitig aktiviert.

  • Berechnung mit Präfixen oder Anycast-Adressen als Ziele.

  • Einschließlich und Ausschluss von Schnittstellen-IP-Adressen als Einschränkungen.

Verteilter CSPF-Berechnungsalgorithmus

Die verteilte CSPF-Berechnungsfunktion für Segment-Routing-LSPs verwendet den Label Stack-Komprimierungsalgorithmus mit CSPF.

Label Stack-Komprimierung möglich

Ein komprimierter Labelstack stellt einen Satz von Pfaden von einer Quelle zu einem Ziel dar. Sie besteht im Allgemeinen aus Node-SIDs und Adjacency-SIDs. Wenn die Label Stack-Komprimierung aktiviert ist, wird das Ergebnis der Berechnung eine Reihe von Pfaden ergeben, die ECMP zum Ziel maximieren und dabei eine minimale Anzahl von SIDs im Stack berücksichtigen und dabei den Beschränkungen entsprechen.

Label Stack-Komprimierung deaktiviert

Die Multipath-CSPF-Berechnung mit einer deaktivierten Label Stack-Komprimierung findet bis zu N-Segmentlisten zum Ziel:

  • Die Kosten aller Segmentlisten sind gleich und gleich der kürzesten Traffic-Engineering-Kennzahl zum Erreichen des Ziels.

  • Jede Segmentliste besteht aus Adjacency-SIDs.

  • Der Wert von N ist die maximale Anzahl von Segmentlisten, die dem Kandidatenpfad nach Konfiguration zulässig ist.

  • Keine beiden Segmentlisten sind identisch.

  • Jede Segmentliste erfüllt alle konfigurierten Bedingungen.

Verteilte CSPF-Berechnungsdatenbank

Die Datenbank, die für die SRTE-Berechnung verwendet wird, besteht aus allen Links, Knoten, Präfixen und deren Eigenschaften, unabhängig davon, ob Traffic-Engineering in diesen Werbeknoten aktiviert ist. Anders gesagt, es ist die Union der Traffic-Engineering-Datenbank (TED) und der IGP-Verbindungsstatusdatenbank aller Domänen, von denen der Computing-Knoten gelernt hat.

Konfigurieren verteilter CSPF-Berechnungseinschränkungen

Sie können ein Rechenprofil verwenden, um die Recheneinschränkungen logisch zu gruppieren. Diese Datenverarbeitungsprofile werden von den Segment-Routing-Pfaden für die Berechnung der primären und sekundären Segment-Routing-LSPs referenziert.

Um ein Rechenprofil zu konfigurieren, fügen Sie die Compute-Profile-Anweisung auf der [edit protocols source-packet-routing] Hierarchieebene ein.

Die Konfiguration der unterstützten Berechnungseinschränkungen umfasst:

  • Administrative groups

    Sie können Admin-Gruppen unter der [edit protocols mpls] Hierarchieebene konfigurieren. Junos OS wendet die Konfiguration der administrativen Gruppe auf die SRTE-Schnittstellen (Segment Routing Traffic-Engineering) an.

    Um die Berechnungseinschränkungen zu konfigurieren, können Sie drei Kategorien für eine Gruppe von administrativen Gruppen angeben. Die Konfiguration mit Computation Constraint kann allen Kandidaten-Segment-Routing-Pfaden gemeinsam sein oder auf den einzelnen Kandidatenpfaden ausgeführt werden.

    • include-any— Gibt an, dass jede Verbindung mit mindestens einer der konfigurierten administrativen Gruppen in der Liste akzeptabel ist, wenn der Pfad quert.

    • include-all— Gibt an, dass alle Verbindungen mit allen konfigurierten administrativen Gruppen in der Liste für den Pfad zur Überquerung akzeptabel sind.

    • exclude— Gibt an, dass verbindungen, die keine der konfigurierten administrativen Gruppen in der Liste haben, für den Pfad akzeptabel sind.

  • Explicit path

    Sie können eine Reihe von Router-IDs im Rechenprofil als Einschränkung für die Berechnung der SRTE-Kandidatenpfade festlegen. Jeder Hop muss eine IPv4-Adresse sein und kann sehr streng oder lose sein. Wenn der Typ eines Hops nicht konfiguriert ist, wird Strict verwendet. Bei der Angabe der Explicit Path-Einschränkung müssen Sie die Option in die Segmentliste compute aufgenommen. segment-list

  • Maximum number of segment lists (ECMP paths)

    Sie können einen Kandidatenpfad mit einer Reihe dynamischer Segmentlisten verknüpfen. Die Pfade sind ECMP-Pfade, bei denen jede Segmentliste in ein Next Hop-Gateway mit aktiver Gewicht übersetzt wird. Diese Pfade sind das Ergebnis der Pfadberechnung mit oder ohne Komprimierung.

    Sie können dieses Attribut mithilfe der maximum-computed-segment-lists maximum-computed-segment-lists Option unter der Konfigurationsauszugsoption für das Rechnerprofil konfigurieren. Diese Konfiguration bestimmt die maximale Anzahl solcher Segmentlisten, die für einen bestimmten primären und sekundären LSP berechnet werden.

  • Maximum segment list depth

    Der maximale Parameter der Segmentliste stellt sicher, dass unter allen ECMP-Pfaden, die alle anderen Einschränkungen erfüllen (z. B. administrative Gruppe), nur die Pfade verwendet werden, die über Segmentlisten weniger als oder gleich der maximalen Tiefe der Segmentliste verfügen. Wenn Sie diesen Parameter als Einschränkung unter dem Compute-Profile konfigurieren, setzt er falls vorhanden die Konfiguration in der maximum-segment-list-depth[edit protocols source-packet-routing] Hierarchieebene außer Kraft.

    Sie können dieses Attribut mithilfe der maximum-segment-list-depth maximum-segment-list-depth Option unter der Konfigurationsauszugsoption für das Rechnerprofil konfigurieren.

  • Protected or unprotected adjacency SIDs

    Sie können unter dem Rechenprofil geschütztes oder nicht geschütztes Adjacency-SID als Einschränkung konfigurieren, um Verbindungen mit dem angegebenen SID-Typ zu vermeiden.

  • Metric type

    Sie können die Art der Metrik für die zu verwendende Verbindung zur Berechnung angeben. Standardmäßig nutzen SR-TE-LSPs Traffic-Engineering-Metriken der Verbindungen für die Berechnung. Die Traffic-Engineering-Kennzahl für Verbindungen wird durch Traffic-Engineering-Erweiterungen IGP Protokollen angekündigt. Sie können jedoch auch die Kennzahl IGP Berechnung verwenden, indem Sie die Metriktypkonfiguration im Rechenprofil verwenden.

    Sie können dieses Attribut mithilfe der metric-type (igp | te) Option unter der Konfigurationsauszugsoption für das Rechnerprofil konfigurieren.

Verteilte CSPF-Berechnung

Die SRTE-Kandidatenpfade werden lokal berechnet, um die konfigurierten Einschränkungen zu erfüllen. Wenn die LabelStack-Komprimierung deaktiviert ist, führt die Multi-Path CSPF-Berechnung zu einer Reihe von Adjacency-SID-Stacks. Wenn die LabelStack-Komprimierung aktiviert ist, entsteht eine Gruppe komprimierter Labelstacks (bestehend aus benachbarten SIDs und Node-SIDs).

Bei der Berechnung sekundärer Pfade werden die Verbindungen, Knoten und SRLGs, die von den primären Pfaden verwendet werden, nicht zur Berechnung vermieden. Weitere Informationen zu primären und sekundären Pfaden finden Sie unter Konfigurieren primärer und sekundärer LSPs.

Für alle LSPs mit erfolglosen Berechnungsergebnis wird die Berechnung erneut als Änderungen der Traffic-Engineering-Datenbank (TED) angezeigt.

Interaktion zwischen verteilter CSPF-Berechnung und SRTE-Funktionen

Gewichtung der mit Pfaden einer SRTE-Richtlinie verknüpften Gewichtung

Sie können die Gewichtung im Gegenwert von berechneten und statischen SRTE-Pfaden konfigurieren, die zum nächsten Hop der Route beitragen. Doch die Berechnung eines einheitlichen Pfads kann zu mehreren Segmentlisten führen. Diese Computed-Segment-Listen werden untereinander als ECMP behandelt. Sie können diesen Segmenten hierarchische ECMP-Gewichtungen zuweisen, unter Berücksichtigung der Gewichtung, die jedem der konfigurierten Voreinstellungen zugewiesen wird.

BFD Liveliness Detection

Sie können die BFD-Livelineerkennung für die berechneten primären oder sekundären Pfade konfigurieren. Jeder berechnete primäre oder sekundäre Pfad kann zu mehreren Segmentlisten führen, so dass die mit der Segmentliste konfigurierten BFD-Parameter auf alle Computed-Segmentlisten angewendet werden. Wenn alle aktiven primären Pfade heruntergehen, wird der vorprogrammierte sekundäre Pfad (falls angegeben) aktiv.

inherit-label-nexthops

Es ist nicht erforderlich, die Konfiguration unter der Hierarchie für die berechneten primären oder sekundären Pfade explizit zu aktivieren, da es sich um inherit-label-nexthops[edit protocols source-packet-routing segment-list segment-list-name] ein Standardverhalten handelt.

Automatische Übersetzung von Funktionen

Sie können die Funktion automatisch in die Segmentliste und die primären oder sekundären Pfade mit dem Feature-Referenzabschnitt in diesen Segmentlisten automatisch übersetzen. Auf der anderen Seite kann die primäre oder sekundäre Rechenfunktion nicht auf eine Segmentliste verweisen. Daher können Sie nicht sowohl die Rechnerfunktion als auch die automatische Übersetzungsfunktion für einen bestimmten primären oder sekundären Pfad aktivieren. Möglicherweise ist jedoch ein LSP mit einem Hauptpfad mit Rechentyp konfiguriert, ein anderer mit automatischer Übersetzung.

Verteilte CSPF-Berechnungsbeispielkonfigurationen

Beispiel 1

In Beispiel 1

  • Der nicht berechnete Primärpfad bespricht eine konfigurierte Segmentliste. In diesem Beispiel wird auf die konfigurierte static_sl1 Und auch der Name dieses primären Pfads angezeigt.

  • Eine auf der Berechnung primäre Liste sollte einen Namen haben und auf diesen Namen darf nicht auf eine konfigurierte Segmentliste Bezugiert werden. In diesem Beispiel compute_segment1 keine konfigurierte Segmentliste.

  • Das compute_profile_red Compute-Profile wird auf den primären Pfad mit dem Namen compute_segment1.

  • Das compute_profile_red Compute-Profile enthält eine Segmentliste des Typs, anhand derer die compute explizite Pfadeinschränkung für die Berechnung angegeben wird.

Die Gewichtungen für rechnerbasierte Pfad-Next-Hops und statische Next-Hops sind 2 bzw. 3. Wenn die nächsten Hops für rechnerbasierte Pfade comp_nh1,comp_nh2und comp_nh3und der nächste Hop für den statischen Pfad static_nhliegen, werden die Gewichtungen wie folgt angewendet:

Nächster Hop

Gewicht

comp_nh1

2

comp_nh2

2

comp_nh3

2

static_nh

9

Beispiel 2

In Beispiel 2 können sowohl primäre als auch sekundäre Pfade von einer Rechnerart sein und über eigene Rechnerprofile verfügen.

Beispiel 3

Beispiel 3: Wenn die Rechenleistung in einem primären oder sekundären Pfad erwähnt wird, führt dies zu einer lokalen Berechnung eines Pfads zum Ziel ohne Einschränkungen oder andere Parameter für die Berechnung.

Beispiel: Konfigurieren CoS-basierten Forwarding und richtlinienbasiertem Routing für SR-TE-LSPs

SUMMARY CoS-basierte Weiterleitung (CBF) und richtlinienbasiertes Routing (PBR, auch als filterbasierte Weiterleitung bekannt) können für nicht-unserentwegen Segment Routing Traffic Engineered (SR-TE) LSPs aktiviert werden, um selektiven Datenverkehr über einen explicit SR-TE-Pfad zu lenken, damit Sie den Vorteil haben, den Datenverkehr basierend auf Class-of-Service oder einer Richtlinie zu verbessern.

CoS-basierte Weiterleitung und richtlinienbasiertes Routing für SR-TE-LSPs Übersicht

Vorteile von CoS-Based Forwarding (CBF) und Policy-Based Routing (PBR) für SR-TE-LSPs

Mit CBF und PBR können Sie:

  • Nutzen Sie die Kombination von SR-TE-Pfaden (Segment Routing-Traffic Engineering), um den Service-Datenverkehr im Kern zu lenken.

  • Wählen Sie die unterstützenden Services aus, um die ausgewählten SR-TE pfade zu lösen.

Segment-Routing-Pfadquellen, die CBF und PBR unterstützen

Die folgenden Quellen für Segment-Routing-Pfade unterstützen CoS-basierte Weiterleitung und richtlinienbasiertes Routing:

  • Static SR–TE paths– Statisch konfigurierte Source-Routing-Pfade, bei denen der gesamte Label-Stack statisch konfiguriert ist.

  • PCEP— Dynamische Bereitstellung von auf einem Controller erstellten Source-Routing-Pfaden, die entweder über PCEP-Segment-Routing-Erweiterungen oder in einer BGP-Segment-Routing-Richtlinie über BGP-Segment-Routingerweiterungen an einen Ingress-Router in einem ERO heruntergeladen werden.

  • Dynamic LSPs— Dynamisch erstellte Tunnel, die durch das Dynamic Tunnel Module ausgelöst werden und über eine ERO-Auflösung im letzten Hop verfügen.

  • Auto-translated paths– Statisch konfigurierte Source-Routing-Pfade, die automatisch übersetzt werden.

Überlegungen zur Konfiguration von CBF und PBR für SR-TE-LSPs

merken:

  • CBF und PBR sind nur auf nicht-orientierte SR-TE-LSPs aktiviert, die statisch oder dynamisch konfiguriert sind.

  • Sowohl CBF- als auch PBR-Konfigurationen für SR-TE-LSPs können auf einem Gerät kovergiert sein. die Reihenfolge der Konfiguration entscheidet über den Typ, in dem die Routen weitergeleitet werden.

  • Wenn für PBR der erste Hop des SR-TE LSP ein Label ist, müssen Sie die Anweisung resolution preserve-nexthop-hiearchy auf der [edit routing-options] Hierarchieebene enthalten.

  • Die klassenbasierte Weiterleitung von Routen für CBF ist nur in der Weiterleitungstabelle und nicht in den Routen sichtbar.

  • Die richtlinienbasierte Weiterleitung von Routen für PBR erfolgt auf den Routen und wird in der show route Befehlsausgabe gesehen.

Konfiguration CoS-basierter Weiterleitung und richtlinienbasierter Weiterleitung für SR-TE-LSPs

SUMMARY CoS-basierte Weiterleitung (CBF) und richtlinienbasiertes Routing (PBR, auch als filterbasierte Weiterleitung bekannt) können verwendet werden, um selektiven Datenverkehr mithilfe eines Explicit Segment Routing Traffic Engineered (SR-TE) Label Swtiched Path (LSP) zu lenken. Nur nicht-orientierte Segment-Routing-LSPs, bei denen der nächste Hop als First Hop-Label oder IP-Adresse konfiguriert wurde, unterstützen CBF und PBR.

Bevor Sie mit der

  • Sie müssen version Junos OS 20.1 und höher ausführen, um CBF und PBR für nicht-unserendorientierte SR-TE LSPs zu ermöglichen.

  • Konfigurieren Sie die Geräteschnittstellen und stellen Sie sicher, dass die Geräte mit dem Netzwerk verbunden sind.

  • Segmentlisten definieren und SR-TE-LSPs und die zugehörigen Parameter konfigurieren.

Gehen Sie wie folgt vor, um einen SR-TE-LSP zu konfigurieren:

  1. Segmentliste mit Label-Parametern definieren.

    Zum Beispiel:

  2. Konfigurieren Sie den Source-Routing-Pfad für die SR-TE-LSPs, und geben Sie den Präferenzwert und das primäre Segment für diesen Pfad an.

    Zum Beispiel:

Jetzt können Sie CBF und PBR für die konfigurierten SR-TE-LSPs konfigurieren.

Um CBF zu konfigurieren, gehen Sie wie folgt vor:

  1. Definieren von DSCP-Klassifizierern (Differentiated Services Code Point) zur Handhabung eingehender IPv4-Pakete, Weiterleitungsklassen und Optionswerte.

    Zum Beispiel:

  2. Definition von Weiterleitungsklassen (Forwarding Classes, FCs) zur Gruppierung von Paketen zur Übertragung und Zuweisung von Paketen zu Ausgangswarteschlangen.

    Zum Beispiel:

  3. Weisen Sie die konfigurierten Klassifizierer den Geräteschnittstellen zu.

    Zum Beispiel:

  4. Definieren CoS-basierten Weiterleitungsrichtlinieoptionen mit LSP-Next-Hop als SR-TE LSP.

    Zum Beispiel:

  5. Verwerfen Sie Datenverkehr, der nicht einer Weiterleitungsklasse in der Next-Hop-Karte gerecht wird.

    Zum Beispiel:

  6. Konfigurieren Sie eine Richtlinienauszug, die angibt, dass Routen, die dem Routenfilter entsprechend sind, für die CoS-Next-Hop-Zuordnung gelten, die für Map-Name angegeben ist.

    Zum Beispiel:

  7. Wenden Sie die Richtlinie auf Routen an, die aus der Routing-Tabelle in die Weiterleitungstabelle exportiert werden. Dies ermöglicht CBF für SR-TE LSPs.

    Zum Beispiel:

  8. Commit für die Konfiguration.

Verify CBF Configuration

Sie können die CBF-Konfiguration mit dem Befehl show route forwarding-table destination ip-address vpn vpn-name extensive überprüfen.

Bei CBF ist die klassenbasierte Weiterleitung von Routen nur in der Weiterleitungstabelle sichtbar, im Gegensatz zu PBR, bei der die gefilterten Routen in der show route Befehlsausgabe sichtbar sind.

Gehen Sie wie folgt vor, um PBR zu konfigurieren:

  1. Konfigurieren Sie eine Richtlinienauszug, die angibt, dass Routen, die dem Protokoll- und Routenfilter entsprechend sind, dem LSP-Next-Hop unterliegen, oder ein Lastausgleich als Equal-Cost-Multipath (ECMP) in der Weiterleitungstabelle.

    Zum Beispiel:

  2. Konfigurieren Sie das Gerät, um eine benutzerdefinierte Routenauflösung für Protokoll-Next-Hops von Routen durchzuführen.

    Anmerkung:

    Die Aussage ist erforderlich, damit PBR funktioniert, wenn der erste Hop des resolution preserve-nexthop-hierarchy SR-TE LSP ein Label ist.

  3. Wenden Sie die Richtlinie auf Routen an, die aus der Routing-Tabelle in die Weiterleitungstabelle exportiert werden. Dies ermöglicht PBR für SR-TE-LSPs.

    Zum Beispiel:

  4. Commit für die Konfiguration.

Verify PBR Configuration

Sie können die PBR-Konfiguration mit dem Befehl show route destination-prefix überprüfen.

Die Ausgabe zeigt alle nächsten Hops für das Ziel-Präfix 4.0.0.1 an. Die expanded-nh extensive Optionen werden die gefilterten nächsten Hops im Krt_inh Ausgabefeld angezeigt.

Für PBR übernimmt show route die Befehlsausgabe die richtlinienbasierte Filterung von Routen.

Release-Verlaufstabelle
Release
Beschreibung
21.R1
ab Junos OS Version 21.1R1 unterstützt Junos OS nonstop Active Routing (NSR) für PCE-initiierte RSVP-basierte Point-to-Point- und Point-to-Multipoint-LSPs.
21.R1
ab Junos OS Version 21.1R1 unterstützt Junos OS nonstop Active Routing (NSR) für PCE-initiierte RSVP-basierte Point-to-Multipoint-LSPs.
20.2R1
Beginnend mit Junos OS Release 20.2R1 kann BGP Labeled Unicast (BGP-LU) IPv4- oder IPv6-Routen über Segment Routing– Traffic Engineering (SR-TE) für IPv4- und IPv6-Adressfamilien lösen.
19.4R1
Sie können eine einzelne oder breite Palette von MVPN-Multicast-Flows (S,G) einem dynamisch erstellten PCE-initiierten Point-to-Multipoint Label Switched Path (LSP) zuordnen.
19.4R1
Sie können eine Tunnelvorlage für vom PCE initiierte Segment-Routing-LSPs konfigurieren, um zwei zusätzliche Parameter für diese LSPs weiter zu geben: Bidirectional Forwarding Detection (BFD) und LDP-Tunneling.
19.1R1
Ab dem Junos OS Veröffentlichungs-19.1R1 wird eine Commit-Prüfung-Funktion eingeführt, um sicherzustellen, dass alle Segmentlisten, die zu den Routen beitragen, über das minimale Label für alle Hops verfügen.
19.1R1
Ab dem Junos OS Veröffentlichungs-19.1R1 gilt diese Anforderung nicht mehr, da der erste Hop der statischen LSPs nicht-statische lSPs neben IP-Adressen auch SID-Labels unterstützt. Durch die Unterstützung des ersten Hop-Labels ist MPLS Fast Reroute (FRR) und Weighted Equal-Cost-Multipath zum Lösen der statischen nicht-unserenkenden Segment-Routing-LSPs aktiviert, ähnlich wie statische LSPs.
18.2R1
Beginnend mit Junos OS Release 18.2R1 werden statisch konfigurierte nicht-orientierte Segment-Routing-LSPs auf dem ingress-Gerät wird der Path Computation Element (PCE) über eine Path Computation Element Protocol (PCEP)-Sitzung gemeldet.
17.2R1
Ab Version Junos OS 17.2 werden zusätzlich zwei neue Pfadberechnungstypen für external cspf PCE-gesteuerte LSPs eingeführt: local cspf und no cspf .
16.1
Beginnend mit Junos OS Version 16.1 können Sie eine PCEP-Sitzung mithilfe der TCP-MD5-Authentifizierung gemäß RFC 5440 sichern.
16.1
Junos OS Version 16.1 bietet eine Einführung in die Funktion der Sicherung einer PCEP-Sitzung mithilfe der TCP-MD5-Authentifizierung gemäß RFC 5440.
14.2R4
Beginnend im Junos OS Release 14.2R4 Unterstützung automatischer Bandbreite für PCE-gesteuerte LSPs.