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 Entität (Komponente, Anwendung oder Netzwerkknoten), die in der Lage ist, einen Netzwerkpfad oder eine Netzwerkroute basierend auf einem Netzwerkdiagramm zu berechnen und Rechenbeschränkungen anzuwenden. Ein Path Computation Client (PCC) ist jede Clientanwendung, die eine Pfadberechnung zur Durchführung durch einen PCE anfordert. 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 Multidomain Traffic Engineered LSPs (TE LSPs) verwendet werden. Es bietet einen Mechanismus für einen PCE zur Berechnung des Pfads für die externen LSPs eines PCC. Zu den PCEP-Interaktionen gehören LSP-Statusberichte, die vom PCC an den PCE gesendet werden, und PCE-Aktualisierungen für die externen LSPs.

Abbildung 1 veranschaulicht die Rolle von PCEP bei der clientseitigen Implementierung einer stateful PCE-Architektur in einem MPLS RSVP-TE-fähigen Netzwerk.

Abbildung 1: PCEP-SitzungPCEP-Sitzung

Eine TCP-basierte PCEP-Sitzung verbindet ein PCC mit einem externen PCE. Das PCC initiiert die PCEP-Sitzung und bleibt für die Dauer der PCEP-Sitzung mit dem PCE verbunden. Während der PCEP-Sitzung fordert der PCC LSP-Parameter vom zustandsbehafteten PCE an. Wenn ein oder mehrere LSP-Parameter vom PCE empfangen werden, sendet der PCC das TE-LSP erneut an. Wenn die PCEP-Sitzung beendet wird, wird die zugrunde liegende TCP-Verbindung sofort geschlossen, und der PCC versucht, die PCEP-Sitzung erneut einzurichten.

Daher umfassen die PCEP-Funktionen:

  • LSP-Tunnelstatussynchronisierung zwischen einem PCC und einem stateful PCE: Wenn eine aktive Zustands-PCE-Verbindung erkannt wird, versucht ein PCC, alle LSPs in einer Prozedur namens LSP-Zustandssynchronisierung an diesen PCE zu delegieren. PCEP ermöglicht die Synchronisierung des PCC LSP-Zustands mit dem PCE.

  • Delegierung der Kontrolle über LSP-Tunnel an einen zustandsbehafteten PCE: Ein aktiver Zustandsbehafteter PCE steuert ein oder mehrere LSP-Attribute für Rechenpfade, wie Bandbreite, Pfad (ERO) und Priorität (Setup und Halten). PCEP ermöglicht eine solche Delegierung von LSPs für die Pfadberechnung.

  • Stateful-PCE-Steuerung des Timings und der Reihenfolge von Pfadberechnungen innerhalb und über PCEP-Sitzungen hinweg: Ein aktiver Zustandsbehafteter PCE ändert ein oder mehrere LSP-Attribute, wie Bandbreite, Pfad (ERO) und Priorität (Setup und Halten). PCEP kommuniziert diese neuen LSP-Attribute vom PCE an das PCC, danach signalisiert der PCC den LSP im angegebenen Pfad erneut.

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

Grundlegendes zu MPLS RSVP-TE

Traffic Engineering (TE) befasst sich mit der Leistungsoptimierung von betrieblichen Netzwerken und bezieht hauptsächlich die Datenverkehrsströme auf eine vorhandene physische Topologie ab. Traffic Engineering bietet die Möglichkeit, den Datenverkehr von dem kürzesten Pfad, der vom Interior Gateway Protocol (IGP) ausgewählt wurde, auf einen potenziell weniger überfüllten physischen Pfad durch ein 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 in einem Overlay-Modell verfügbaren Funktionen auf integrierte Weise und zu niedrigeren Kosten als die derzeit konkurrierenden Alternativen bereitstellen. Der Hauptgrund für die Implementierung von MPLS Traffic Engineering ist die Steuerung der Pfade, auf denen der Datenverkehr durch ein Netzwerk fließt. Der Hauptvorteil der Implementierung von MPLS Traffic Engineering besteht darin, dass es eine Kombination aus den Traffic-Engineering-Funktionen von ATM und der Class-of-Service -Differenzierung (CoS) von IP bietet.

In einem MPLS-Netzwerk werden Datenebeneninformationen über Label Switching weitergeleitet. Ein Paket, das auf einem Provider-Edge -Router (PE) vom Kunden-Edge -Router (CE) ankommt, werden mit Denketiketten versehen und dann an den Ausgangs-PE-Router weitergeleitet. Die Label werden am Ausgangsrouter entfernt und dann als IP-Paket an das entsprechende Ziel weitergeleitet. Die Label-Switching-Router (LSRs) in der MPLS-Domäne verwenden Label-Verteilungsprotokolle, um die Bedeutung von Labeln zu kommunizieren, die zur Weiterleitung des Datenverkehrs zwischen und über die LSRs verwendet werden. RSVP-TE ist ein solches Protokoll zur Label-Verteilung, das es einem LSR-Peer ermöglicht, mehr über die Labelzuordnungen anderer Peers zu erfahren.

Wenn sowohl MPLS als auch RSVP auf einem Router aktiviert sind, wird MPLS zu einem Client von RSVP. Der Hauptzweck der Junos OS RSVP-Software besteht darin, dynamische Signalübertragung innerhalb von Label-Switched Paths (LSPs) zu unterstützen. RSVP reserviert Ressourcen, z. B. für IP-Unicast- und Multicast-Datenströme, und fordert Quality-of-Service -Parameter (QoS) für Anwendungen an. Das Protokoll wird im MPLS Traffic Engineering erweitert, damit RSVP LSPs einrichten kann, die für das Traffic-Engineering in MPLS-Netzwerken verwendet werden können.

Wenn MPLS und RSVP kombiniert werden, werden Label mit RSVP-Datenströmen verknüpft. Sobald ein LSP eingerichtet ist, wird der Datenverkehr durch den Pfad durch das Label definiert, das auf den Eingangsknoten des LSP angewendet wird. Die Zuordnung des Etiketts zum Datenverkehr erfolgt nach unterschiedlichen Kriterien. Die Paketmenge, denen von einem bestimmten Knoten derselbe Labelwert zugewiesen wird, gehören derselben FEC (Forwarding Äquivalenzklasse) und definieren effektiv den RSVP-Datenfluss. Wenn der Datenverkehr auf diese Weise auf einem LSP abgebildet wird, wird der LSP als LSP-Tunnel bezeichnet.

LSP-Tunnel sind eine Möglichkeit, unidirektionale Label-Switched-Pfade einzurichten. RSVP-TE baut auf dem RSVP-Core-Protokoll auf, indem neue Objekte definiert und vorhandene Objekte geändert werden, die in den PATH- und RESV-Objekten für die LSP-Einrichtung verwendet werden. Die neuen Objekte – LABEL-REQUEST Object (LRO), RECORD-ROUTE Object (RRO), LABEL Object und EXPLICIT-ROUTE Object (ERO) – sind in Bezug auf das RSVP-Protokoll optional, mit Ausnahme der LRO- und LABEL-Objekte, die beide für den Aufbau von LSP-Tunneln obligatorisch sind.

Im Allgemeinen richtet RSVP-TE einen Label-Switched-Pfad ein, der die Framebereitstellung vom Eingangs- zum Ausgangsrouter gewährleistet. Mit den neuen Traffic-Engineering-Funktionen werden jedoch die folgenden Funktionen in einer MPLS-Domäne unterstützt:

  • Möglichkeit, einen Label-Switched-Pfad mit einer vollständigen oder teilweisen expliziten Route einzurichten (RFC 3209).

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

  • Endpunktsteuerung, die mit dem Einrichten und Verwalten von LSP-Tunneln an den Eingangs- und Ausgangsroutern verbunden ist.

  • Link-Management, das Linkressourcen verwaltet, um ressourcenorientiertes Routing von Traffic-Engineering-LSPs zu tun und MPLS-Label zu programmieren.

  • MPLS Fast Reroute (FRR), das die schutzbedürftigen LSPs verwaltet und diesen LSPs Backup-Tunnelinformationen zuweist.

Aktuelle EINSCHRÄNKUNGEN VON MPLS RSVP-TE

Obwohl die RSVP-Erweiterungen für das Traffic-Engineering eine bessere Netzwerkauslastung ermöglichen und die Anforderungen von Datenverkehrsklassen erfüllen, hat die heutige MPLS RSVP-TE-Protokollsuite mehrere Probleme, die mit ihrer verteilten Natur verbunden sind. Dies verursacht eine Reihe von Problemen während des Streits um die Bisektionskapazität, insbesondere innerhalb einer LSP-Prioritätsklasse, bei der eine Teilmenge von LSPs gemeinsame Setup- und Prioritätswerte hat. Zu den Einschränkungen von RSVP-TE gehören:

  • Mangelnde Visibilität der einzelnen Bandbreitenanforderungen pro LSP und pro Gerät: Die Eingangsrouter in einem MPLS-RSVP-TE-Netzwerk stellen LSPs ein, ohne einen globalen Überblick über den Bandbreitenbedarf im Netzwerk zu haben. Informationen zur Netzwerkressourcenauslastung sind nur als insgesamt reservierte Kapazität nach Datenverkehrsklasse auf Schnittstellenbasis verfügbar. Der individuelle LSP-Status ist lokal auf jedem Label Edge Router (LER) nur für seine eigenen LSPs verfügbar. Infolgedessen treten eine Reihe von Problemen im Zusammenhang mit der Nachfragestruktur auf, insbesondere innerhalb einer gemeinsamen Einrichtung und haben Priorität.

  • Asynchrone und unabhängige Art der RSVP-Signalübertragung: In RSVP-TE werden die Einschränkungen für die Pfadeinrichtung durch einen Administrator gesteuert. Daher wird die für einen LSP-Tunnel reservierte Bandbreite vom Administrator festgelegt und bedeutet nicht automatisch eine Begrenzung des über den Tunnel gesendeten Datenverkehrs. Daher ist die auf einem Traffic-Engineering-Link verfügbare Bandbreite die für den Link konfigurierte Bandbreite, ohne die Summe aller Reservierungen, die für den Link vorgenommen wurden. Daher führen die nicht signalisierten Anforderungen an einen LSP-Tunnel zu einer Serviceverschlechterung des LSP, der eine übermäßige Bandbreite benötigt, sowie der anderen LSPs, die die Bandbreitenanforderungen der Traffic-Engineering-Verbindung erfüllen.

  • LSPs basierend auf dynamischen oder expliziten Pfadoptionen in der reihenfolge der Voreinstellung eingerichtet: Die Eingangsrouter in einem MPLS-RSVP-TE-Netzwerk richten LSPs für Anforderungen basierend auf der Reihenfolge der Ankunft ein. Da die eingehenden Router keinen globalen Überblick über den Bandbreitenbedarf im Netzwerk haben, kann die Verwendung der voreingesetzten Reihenfolge zur Einrichtung von LSPs dazu führen, dass der Datenverkehr unterbrochen wird oder LSPs überhaupt nicht eingerichtet werden, wenn es einen übermäßigen Bandbreitenbedarf gibt.

Abbildung 2 Beispielsweise wird mit MPLS RSVP-TE konfiguriert, in dem A und G die Label Edge Router (LERs) sind. Diese Eingangsrouter richten unabhängig nach der Reihenfolge der Anforderungen LSPs ein und haben keine Kenntnis oder Kontrolle über die LSPs des jeweils anderen. Die Router B, C und D sind Zwischen- oder Transitrouter, die eine Verbindung zu den Ausgangsroutern E und F herstellen.

Abbildung 2: Beispiel MPLS Traffic Engineering Beispiel MPLS Traffic Engineering

Die Eingangsrouter richten LSPs in der Reihenfolge ein, in der die Anforderungen ankommen. Wenn Router G zwei Anforderungen mit je 5 Kapazität für G-F erhält, dann signalisiert G zwei LSPs – LSP1 und LSP2 – über G-B-D-F. Wenn Router A die dritte Anforderung der Kapazität 10 für A-E empfängt, signalisiert er auch einen LSP, LSP3, über A-B-C-E. Wenn jedoch die Nachfrage an den A-E-LSP von 10 auf 15 steigt, kann Router A LSP3 nicht mit demselben Pfad (A-B-C-E) signalisieren, da der B-C-Link eine geringere Kapazität hat.

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

Obwohl für alle LSPs ausreichend Maximale-Flow-Bandbreite verfügbar ist, unterliegt LSP3 möglicherweise längeren Serviceverschlechterungen. Dies liegt an der mangelnden globalen Nachfragetransparenz von Router A und der fehlenden systemischen Koordination bei der Bedarfsplatzierung durch die Eingangsrouter A und G.

Verwendung einer externen Path-Computing-Entität

Als Lösung für die aktuellen Einschränkungen der MPLS-RSVP-TE-Pfadberechnung ist eine externe Pfad-Computing-Entität mit einer globalen Ansicht der nachfrage pro LSP pro Gerät im Netzwerk erforderlich, unabhängig von der verfügbaren Kapazität.

Derzeit wird in einem MPLS RSVP-TE-Netzwerk nur online- und echtzeitbasierte Routing-Pfadberechnungen bereitgestellt. Jeder Router führt unabhängig von den anderen Routern im Netzwerk einschränkungensbasierte Routing-Berechnungen durch. Diese Berechnungen basieren auf derzeit verfügbaren Topologieinformationen – Informationen, die in der Regel aktuell sind, aber nicht vollständig korrekt sind. LSP-Platzierungen werden lokal optimiert, basierend auf dem aktuellen Netzwerkstatus. Die MPLS RSVP-TE-Tunnel werden über die CLI eingerichtet. Ein Betreiber konfiguriert den TE-LSP, der dann vom Eingangsrouter signalisiert wird.

Zusätzlich zu den vorhandenen Traffic-Engineering-Funktionen wird die MPLS RSVP-TE-Funktionalität um eine externe Pfad-Computing-Entität erweitert, die als Path Computation Element (PCE) bezeichnet wird. Der PCE berechnet den Pfad für die TE-LSPs der Eingangsrouter, die für die externe Steuerung konfiguriert wurden. Der Eingangsrouter, der eine Verbindung zu einem PCE herstellt, heißt Path Computation Client (PCC). Das PCC wird mit dem Path Computation Client Protocol (PCEP) konfiguriert, um die externe Pfadverarbeitung durch einen PCE zu ermöglichen.

Weitere Informationen finden Sie unter Komponenten des External Path Computing.

Um das externe Path Computing für die TE-LSPs eines PCC zu ermöglichen, fügen Sie die lsp-external-controller pccd Anweisung auf der Hierarchie- und [edit mpls lsp lsp-name] Hierarchieebene [edit mpls] ein.

Komponenten des External Path Computing

Ein externes Pfad-Computing-System besteht aus folgenden Komponenten:

Pfadberechnungselement

Ein Path Computation Element (PCE) kann eine beliebige Entität (Komponente, Anwendung oder Netzwerkknoten) sein, die in der Lage ist, einen Netzwerkpfad oder eine Netzwerkroute basierend auf einem Netzwerkdiagramm zu berechnen und Rechenbeschränkungen anzuwenden. Ein PCE kann jedoch nur den Pfad für die TE-LSPs eines PCC berechnen, die für die externe Steuerung konfiguriert wurden.

Ein PCE kann entweder zustandsbehaftet oder zustandslos sein.

  • Stateful PCE: Ein zustandsbehafteter PCE behält eine strikte Synchronisierung zwischen dem PCE und dem Netzwerkstatus (in Bezug auf Topologie- und Ressourceninformationen) zusammen mit den im Netzwerk verwendeten berechneten Pfaden und reservierten Ressourcen bei. Mit anderen Worten, ein stateful PCE nutzt Informationen aus der Traffic-Engineering-Datenbank sowie Informationen über vorhandene Pfade (z. B. TE-LSPs) im Netzwerk, wenn neue Anforderungen vom PCC verarbeitet werden.

    Ein zustandsbehafteter PCE hat zwei Arten:

    • Passiver Zustandsbehafteter PCE: Behält die Synchronisierung mit dem PCC bei und lernt die PCC-LSP-Zustände, um Pfadberechnungen besser zu optimieren, hat aber keine Kontrolle darüber.

    • Aktives Stateful-PCE: Ändert aktiv die PCC-LSPs und lernt außerdem mehr über die PCC-LSP-Zustände.

      HINWEIS:

      In einer redundanten Konfiguration mit Haupt- und Backup-aktiven Stateful-PCEs kann das Backup Active Stateful-PCE die Attribute der delegierten LSPs erst ändern, wenn es zum Zeitpunkt eines Failovers zum Haupt-PCE wird. Bei einem Switchover gibt es keine Vorbehauptung von PCEs. Der Haupt-PCE wird durch ein Backup-PCE unterstützt, und wenn der Haupt-PCE ausfällt, übernimmt das Backup-PCE die Rolle des Haupt-PCE und bleibt der Haupt-PCE auch nach dem PCE, das zuvor der Haupt-PCE war wieder betriebsbereit.

    Ein stateful PCE bietet die folgenden Funktionen:

    • Bietet Offline-LSP-Pfadberechnung.

    • Löst eine LSP-Re-Route aus, wenn das Netzwerk neu optimiert werden muss.

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

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

    Ein PCE hat einen globalen Überblick über den Bandbreitenbedarf im Netzwerk und unterhält eine datenverkehrsbasierte Datenbank, in der Pfadberechnungen durchgeführt werden können. Es führt Statistiken von allen Routern in der MPLS-Domäne mithilfe von SNMP und NETCONF durch. Dies bietet einen Mechanismus für die Offline-Steuerung der TE-LSPs des PCC. Obwohl ein Offline-LSP-Pfadberechnungssystem in einen Netzwerkcontroller eingebettet werden kann, fungiert der PCE wie ein vollwertiger Netzwerkcontroller, der zusätzlich zu den Rechenpfaden die Kontrolle über die TE-LSPs des PCC bietet.

    Obwohl ein Stateful-PCE eine optimale Pfadberechnung und einen erhöhten Erfolg der Pfadberechnung ermöglicht, erfordert es zuverlässige Zustandssynchronisierungsmechanismen mit potenziell erheblichem Overhead auf der Steuerungsebene und der Wartung einer großen Menge an Daten in Bezug auf den Status, wie im Fall eines vollständigen Meshs von TE-LSPs.

  • Zustandslose PCE: Ein zustandsloser PCE erinnert sich nicht an einen berechneten Pfad, und jede Reihe von Anforderungen wird unabhängig voneinander verarbeitet (RFC 5440).

Pfadberechnungs-Client

Ein Path Computation Client (PCC) ist jede Clientanwendung, die eine Pfadberechnung zur Durchführung durch einen PCE anfordert.

Ein PCC kann auf einmal mit maximal 10 PCEs verbunden werden. Die PCC-zu-PCE-Verbindung kann eine konfigurierte statische Route oder eine TCP-Verbindung sein, die die Erreichbarkeit herstellt. Der PCC weist jedem angeschlossenen PCE eine Prioritätsnummer zu. Es sendet eine Nachricht an alle angeschlossenen PCEs mit Informationen über seine aktuellen LSPs in einem Prozess namens LSP-Zustandssynchronisierung. Für die TE-LSPs mit aktivierter externer Kontrolle delegiert der PCC diese LSPs an den Haupt-PCE. Das PCC wählt als Haupt-PCE einen PCE mit der niedrigsten Prioritätsnummer oder den PCE, mit dem es zuerst verbunden ist, wenn keine Prioritätsnummer vorhanden ist.

Der PCC signalisiert einen LSP basierend auf dem berechneten Pfad, den er von einem PCE empfängt. Wenn die PCEP-Sitzung mit dem Haupt-PCE beendet wird, wählt das PCC einen neuen Haupt-PCE, und alle delegierten LSPs an den zuvor Haupt-PCE werden an das neu verfügbare Haupt-PCE delegiert.

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 Domänenübergreifende TE-LSPs verwendet werden. Zu den PCEP-Interaktionen gehören PCC-Nachrichten sowie Benachrichtigungen über bestimmte Zustände im Zusammenhang mit der Verwendung eines PCE im Kontext von MPLS RSVP-TE. Wenn PCEP für die PCE-to-PCE-Kommunikation verwendet wird, übernimmt der anfordernde PCE die Rolle eines PCC.

Daher umfassen die PCEP-Funktionen:

  • LSP-Tunnelstatussynchronisierung zwischen PCC und einem Stateful-PCE.

  • Delegierung der Kontrolle über LSP-Tunnel an einen Zustandsbehafteten PCE.

Interaktion zwischen einem PCE und einem PCC mit PCEP

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

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

Die Kommunikation zwischen PCE und PCC wird durch das TCP-basierte PCEP ermöglicht. Das PCC initiiert die PCEP-Sitzung und bleibt für die Dauer der PCEP-Sitzung mit einem PCE verbunden.

HINWEIS:

Ab Junos OS Version 16.1 können Sie eine PCEP-Sitzung mit 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 [edit protocols pcep pce pce-id] Hierarchieebene für eine PCEP-Sitzung zu definieren und zu binden. Sie können jedoch auch einen vordefinierten Schlüsselbund aus der [edit security authentication-key-chains key-chain] Hierarchieebene verwenden, um eine PCEP-Sitzung zu sichern. In diesem Fall sollten Sie den vordefinierten Schlüsselbund an die PCEP-Sitzung auf [edit protocols pcep pce pce-id] Hierarchieebene binden.

PCE und PCC verwenden denselben Schlüssel, um die Echtheit jedes Segments, das über die TCP-Verbindung der PCEP-Sitzung gesendet wird, zu überprüfen, um die PCEP-Kommunikation zwischen den Geräten zu sichern, die Angriffe ausgesetzt sein und Dienste im Netzwerk unterbrechen können.

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

Sobald die PCEP-Sitzung eingerichtet ist, führt der PCC folgende Aufgaben aus:

  1. LSP-Zustandssynchronisierung: Der PCC sendet Informationen über alle LSPs (lokal und extern) an alle angeschlossenen PCEs. Für externe LSPs sendet der PCC Informationen über jede Konfigurationsänderung, RRO-Änderung, Zustandsänderung usw. an den PCE.

    Für PCE-initiierte LSPs ist auf dem PCC keine LSP-Konfiguration vorhanden. Der PCE, der den LSP initiiert, sendet die LSP-Parameter an den PCC, der angezeigt hat, dass er PCE-initiierte LSPs unterstützt.

    HINWEIS:

    Unterstützung für PCE-initiierte LSPs wird in Junos OS Version 13.3 und höher bereitgestellt.

  2. LSP-Delegierung: Nach der Synchronisierung der LSP-Statusinformationen delegiert das PCC die externen LSPs an einen PCE, den wichtigsten aktiven Status-PCE. Nur der Haupt-PCE kann Parameter für den externen LSP festlegen. Zu den Parametern, die der HAUPT-PCE ändert, gehören Bandbreite, Pfad (ERO) und Priorität (Setup und Halten). Die in der lokalen Konfiguration angegebenen Parameter werden durch die Parameter überschrieben, die vom Haupt-PCE festgelegt werden.

    HINWEIS:

    Wenn die PCEP-Sitzung mit dem Haupt-PCE beendet wird, wählt das PCC einen neuen Haupt-PCE, und alle delegierten LSPs an den zuvor Haupt-PCE werden an das neu verfügbare Haupt-PCE delegiert.

    Im Fall von PCE-initiierten LSPs erstellt der PCC den LSP unter Verwendung der parameter, die vom PCE erhalten wurden. Der PCC weist dem PCE-initiierten LSP eine eindeutige LSP-ID zu und delegiert den LSP automatisch an den PCE. Ein PCC kann die Delegierung der PCE-initiierten LSPs für eine aktive PCEP-Sitzung nicht widerrufen.

    Wenn eine PCEP-Sitzung beendet wird, startet der PCC zwei Timer, ohne die PCE-initiierten LSPs sofort zu löschen – delegation cleanup timeout und lsp cleanup timer – um Eine Unterbrechung der Services zu vermeiden. Während dieser Zeit kann ein aktiver zustandsbehafteter PCE die Kontrolle über die von dem ausgefallenen PCE bereitgestellten LSPs übernehmen, indem eine Create-Anforderung für den LSP gesendet wird.

    Die Kontrolle über PCE-initiierte LSPs wird nach Ablauf von delegation cleanup timeout. Wenn das delegation cleanup timeout Ablaufdatum abläuft und kein anderer PCE die Kontrolle über den LSP von dem ausgefallenen PCE übernommen hat, übernimmt das PCC die lokale Kontrolle über den nicht delegierte PCE-initiierten LSP. Wenn später der ursprüngliche oder ein neuer aktiver Stateful-PCE die Kontrolle über die lokal kontrollierten PCE-initiierten LSPs erlangen möchte, delegiert das PCC diese LSPs an den PCE und der lsp cleanup timer Timer wird angehalten.

    Ein PCE kann die Delegierung des PCE-initiierten LSP an den PCC zurückschicken, um die LSP-Übertragung zwischen PCEs zu ermöglichen. Dies löst für den lsp cleanup timer PCE-initiierten LSP aus. Der PCC wartet, bis der Timer für die LSP-Bereinigung abläuft, bevor die nicht delegierte PCE-initiierten LSPs aus dem ausgefallenen PCE entfernt werden.

    Wenn das lsp cleanup timer Ablaufen abläuft und kein anderer PCE die Kontrolle über die LSPs von dem ausgefallenen PCE übernommen hat, löscht das PCC alle LSPs, die von dem ausgefallenen PCE bereitgestellt wurden.

    HINWEIS:

    In Übereinstimmung mit Draft-ietf-pce-stateful-pce-09 erfolgt das Widerrufen von PCE-initiierten LSP-Delegationen durch einen PCC in einer Make-before-Break-Weise, bevor die LSPs zu einem alternativen PCE neu delegiert werden. Ab Junos OS Version 18.1R1 muss die lsp-cleanup-timer Version größer oder gleich dem delegation-cleanup-timeout des PCC sein, um die LSP-Delegierungen zu widerrufen. Wenn nicht, kann das Timeout-Intervall für die Neulegation für den PCC auf unendlich festgelegt werden, wobei die LSP-Delegierungen an diesen PCE intakt bleiben, bis eine bestimmte Aktion vom PCC zur Änderung der vom PCE festgelegten Parameter durchgeführt wird.

  3. LSP-Signalübertragung: Wenn der PCC einen oder mehrere LSP-Parameter vom hauptaktiven Zustandsstatus-PCE empfängt, sendet der PCC den TE-LSP basierend auf dem von PCE bereitgestellten Pfad neu. Wenn der PCC den LSP nicht einrichten kann, benachrichtigt es den PCE über den Setup-Fehler und wartet, bis der Haupt-PCE neue Parameter für diesen LSP bereitstellt, und signalisiert ihn dann erneut.

    Wenn der PCE einen Pfad angibt, der unvollständig ist oder lose Hops hat, bei denen nur die Pfadendpunkte angegeben sind, führt der PCC kein auf Einschränkungen basierendes Routing durch, um den vollständigen Satz von Hops zu ermitteln. Stattdessen stellt der PCC RSVP den PCE-bereitgestellten Pfad für die Signalübertragung bereit, und der Pfad wird mithilfe von IGP Hop-by-Hop-Routing eingerichtet.

Unter Berücksichtigung der in Abbildung 2verwendeten Topologie veranschaulicht Abbildung 4 die partielle clientseitige PCE-Implementierung im MPLS RSVP-TE-fähigen Netzwerk. Die Eingangsrouter A und G sind die PCCs, die so konfiguriert sind, dass sie über eine TCP-Verbindung eine Verbindung mit dem externen Stateful-PCE herstellen.

Der PCE hat einen globalen Überblick über den Bandbreitenbedarf im Netzwerk und führt externe Pfadberechnungen durch, nachdem er die Traffic-Engineering-Datenbank durchgeblickt hat. Der aktive Stateful-PCE ändert dann ein oder mehrere LSP-Attribute und sendet ein Update an den PCC. Der 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 der Stateful-PCE einen kooperativen Betrieb verteilter Funktionen, die zur Bewältigung spezifischer Herausforderungen einer kürzesten interdomainbeschränkten Pfadberechnung verwendet werden. Es eliminiert Überlastungsszenarien, in denen Datenverkehrsströme ineffizient auf verfügbaren Ressourcen abgebildet werden, was zu einer Überauslastung einiger Teilmengen von Netzwerkressourcen führt, während andere Ressourcen unterbelastet bleiben.

LSP-Verhalten mit externem Computing

LSP-Typen

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

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

  • PCE-gesteuerte LSPs: Die LSPs, für die die lsp-external-controller pccd Anweisung konfiguriert ist, heißt PCE-gesteuerte LSPs. Der PCC delegiert die PCC-initiierten LSPs zur externen Pfadberechnung an den Haupt-PCE.

    Das PCC informiert den PCE über die konfigurierten Parameter eines PCE-gesteuerten LSP, wie Bandbreite, ERO und Prioritäten. Es informiert die PCE auch über die tatsächlichen Werte, die für diese Parameter verwendet wurden, um den LSP einschließlich der RRO einzurichten, sofern verfügbar.

    Das PCC sendet solche LSP-Statusberichte nur an das PCE, wenn eine Neukonfiguration stattgefunden hat oder wenn eine Änderung des ERO, der RRO oder des Status der PCE-gesteuerten LSPs unter externer Kontrolle erfolgt.

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

    • Parameter, die nicht von einem PCE überschrieben werden und sofort angewendet werden.

    • Parameter, die von einem PCE überschrieben werden. Diese Parameter umfassen Bandbreite, Pfad und Priorität (Setup- und Haltewerte). Wenn die Steuermodus-Switches von extern zu lokal wechseln, werden die CLI-konfigurierten Werte für diese Parameter bei der nächsten Gelegenheit angewendet, um das LSP erneut zu signalisieren. Die Werte werden nicht sofort angewendet.

  • Extern bereitgestellte LSPs (oder PCE-initiierte LSPs): Die LSPs, auf denen die lsp-provisioning Anweisung konfiguriert ist, werden als PCE-initiierte LSPs bezeichnet. Ein PCE-initiierter LSP wird dynamisch von einem externen PCE erstellt. daher ist auf dem PCC keine LSP-Konfiguration vorhanden. Der PCC erstellt den PCE-initiierten LSP unter Verwendung der vom PCE bereitgestellten Parameter und delegiert den LSP automatisch an den PCE.

    HINWEIS:

    Unterstützung für PCE-initiierte LSPs wird in Junos OS Version 13.3 und höher bereitgestellt.

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

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

LSP-Steuerungsmodus

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

  • Extern: Standardmäßig unterliegen alle PCE-gesteuerten LSPs einer externen Kontrolle. Wenn ein LSP unter externer Kontrolle steht, verwendet der PCC die von PCE bereitgestellten Parameter, um den LSP einzurichten.

  • Lokal: Ein PCE-gesteuerter LSP kann unter lokaler Kontrolle stehen. Wenn die LSP-Switches von der externen Steuerung zur lokalen Steuerung wechseln, erfolgt die Pfadberechnung mithilfe der CLI-konfigurierten Parameter und des einschränkungensbasierten Routing. Ein solcher Switchover erfolgt nur, wenn es einen Trigger gibt, um den LSP erneut zu signalisieren. Bis dahin nutzt das PCC die von PCE bereitgestellten Parameter, um den PCE-gesteuerten LSP zu signalisieren, obwohl der LSP unter lokaler Kontrolle bleibt.

Ein PCE-gesteuerter LSP wechselt von seinem externen Standardsteuerungsmodus zur lokalen Steuerung, wenn z. B. keine Verbindung zu einem PCE besteht oder wenn ein PCE die Delegierung von LSPs zurück an den PCC zurückgibt.

Weitere Informationen zu CLI-gesteuerten LSPs und PCE-gesteuerten LSPs finden Sie unter LSP-Typen.

Konfigurationsanweisungen, die für externes Computing unterstützt werden

Tabelle 1 listet die MPLS- und vorhandenen LSP-Konfigurationsanweisungen auf, die für einen PCE-gesteuerten LSP gelten.

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

Unterstützung für PCE-gesteuerte LSP

Anwendbare LSP-Konfigurationsanweisungen

Zutreffende MPLS-Konfigurationsanweisungen

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

  • Admin-Gruppe

  • automatische Bandbreite

  • Hop-Limit

  • Geringste Füllung

  • Meistgefüllte

  • Zufällige

  • Admin-Gruppe

  • Admin-Gruppen

  • erweiterte Admin-Gruppe

  • Hop-Limit

  • no-cspf

  • intelligenter Timer zur Optimierung

Diese Konfigurationsanweisungen können zusammen mit der PCE-Konfiguration konfiguriert werden, werden aber durch die PCE-gesteuerten LSP-Attribute überschrieben. Wenn jedoch die lokale Konfiguration verwendet wird, werden die konfigurierten Werte für diese Konfigurationsanweisungen angewendet.

HINWEIS:

Änderungen an der lokalen Konfiguration über die CLI, während der LSP unter der Kontrolle eines Zustandsbehafteten PCE steht, haben keine Auswirkungen auf den LSP. Diese Änderungen treten nur in Kraft, wenn die lokale Konfiguration angewendet wird.

  • Bandbreite

  • primary

  • Priorität

  • Priorität

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

  • p2mp

  • Vorlage

  • p2mp-lsp-next-hop

Die restlichen LSP-Konfigurationsanweisungen sind genauso anwendbar wie für vorhandene LSPs. Bei der Konfiguration einer der oben genannten Konfigurationsanweisungen für einen PCE-gesteuerten LSP wird eine MPLS-Protokollmeldung generiert, die anzeigt, wann die konfigurierten Parameter in Kraft treten.

PCE-gesteuerter LSP-Schutz

Die Schutzpfade, einschließlich Fast Reroute und Bypass-LSPs, werden lokal vom PCC unter Verwendung von einschränkungensbasiertem Routing berechnet. Ein zustandsbehafteter 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 keinen nicht-Standby-sekundären Pfad zum LSP-Schutz hat.

PCE-gesteuerter LSP-ERO

Für PCE-kontrollierte LSPs (PCC-delegierte LSPs und PCE-initated LSPs) muss nur ein vollständiges Explicit Route Object (ERO)-Objekt vom PCE an das PCC gesendet werden; andernfalls lehnt der PCC die PcUpdate- oder PCCreate-Nachricht für diese PCEP-Sitzung ab.

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

  • local cspf—Ein PCC verwendet den local cspf Berechnungstyp nur, wenn der PCE einen Juniper Vendor TLV sendet (Unternehmensnummer: 0x0a4c) des Typs 5.

  • no cspf— Weder PCE noch PCC führt eine Berechnung des eingeschränkten Pfads durch. Die Endgeräte und Einschränkungen werden dem RSVP-Modul für die Einrichtung des LSP mit dem IGP-Pfad angegeben.

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

    • Wenn der PCE TLV sendet local cspf , und wenn die Junos OS-Konfiguration oder entsprechende Vorlage für diesen LSP im PCC-delegierten LSP enthalten ist no-cspf .

    • Wenn der PCE TLV sendet local cspf , und wenn die Junos OS-Konfigurationsvorlage für diesen LSP in den PCE-initiierten LSP enthalten ist no-cspf .

    • Wenn der PCE keine TLV mit einem leeren ERO oder einer losen ERO (mit losem Bit im ERO-Objekt) sendet local cspf .

Mit diesen neuen Berechnungstypen kann ein PCC ein ERO-Objekt entweder als loses ERO oder als leeres ERO akzeptieren. Eine externe Pfad-Computing-Entität, die nicht in der Lage ist, einen Pfad zu berechnen, kann Parameter wie Bandbreite und Farbe basierend auf den Analysen ändern. In solchen Fällen wird ein leeres ERO-Objekt oder ein loses ERO verwendet, deren Pfad vom PCC bestimmt wird.

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

Nachdem eine PCEP-Sitzung zwischen einem PCE und einem PCC eingerichtet wurde, meldet der PCC alle LSPs im System an die PCE für die LSP-Zustandssynchronisierung. Dazu gehören PCC-gesteuerte, PCE-delegierte und PCE-initiierte Point-to-Point-LSPs. Ab Junos OS Version 15.1F6 und 16.1R1 wird diese Funktion auch auf Point-to-Multipoint-LSPs erweitert. Bei einem PCE ähnelt der Point-to-Multipoint-LSP dem des RSVP-Point-to-Multipoint-LSP, bei dem der Point-to-Multipoint-LSP als Eine Sammlung von Punkt-zu-Punkt-LSPs behandelt wird, die unter einem Punkt-zu-Multipoint-Bezeichner gruppiert sind.

Standardmäßig wird die PCE-Steuerung von Point-to-Multipoint-LSPs auf einem PCC nicht unterstützt. Um diese Funktion hinzuzufügen, fügen Sie die p2mp-lsp-report-capability Anweisung auf der [edit protocols pcep pce pce-name] Hierarchie- oder [edit protocols pcep pce-group group-id] Hierarchieebene ein. Nachdem die Point-to-Multipoint-Berichtfunktion auf einem PCC konfiguriert ist, kündigt das PCC diese Funktion dem PCE an. Wenn PCE dieselbe Point-to-Multipoint-Berichtsfunktion im Gegenzug ankündigen, meldet der PCC die vollständige Point-to-Multipoint-LSP-Struktur an den PCE für die LSP-Zustandssynchronisierung.

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-Update und LSP-Datenbank, die Point-to-Multipoint-LSP-Namen unterstützt. Die folgenden Funktionen und Funktionen werden für Junos OS Version 15.1F6 und 16.1 jedoch nicht unterstützt:

  • Statische Point-to-Multipoint-LSPs

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

  • Automatische Bandbreite

  • TE++

  • PCE-Anforderungs- und Antwortnachricht

  • Erstellung von Point-to-Multipoint-LSPs mithilfe von Vorlagen

  • Konfigurieren des Vorwärtseintrags auf den PCE-initiierten Point-to-Multipoint-LSPs

  • Konfigurieren der Weiterleitungseingabe auf dem Router, der auf einen bereitgestellten LSP hinweist.

PCE-initiierte Point-to-Point-LSPs

Ab Junos OS Version 16.1 wird die PCEP-Funktionalität erweitert, um einem Stateful-PCE die Initiierung und Bereitstellung von Traffic-Engineering-LSPs über ein PCC zu ermöglichen. Zuvor wurden die LSPs auf dem PCC konfiguriert und der PCC die Kontrolle über die externen LSPs an einen PCE delegiert. Das Eigentum des LSP-Staates wurde vom PCC gehalten. Mit der Einführung der PCE-initiierten LSPs kann ein PCE einen Point-to-Point-LSP des Datenverkehrs dynamisch initiieren und bereitstellen, ohne dass ein lokal konfigurierter LSP auf dem PCC erforderlich ist. Beim Erhalt einer PCE-Nachricht erstellt das PCC den PCE-initiierten LSP und delegiert den LSP automatisch an den PCE.

Standardmäßig lehnt ein PCC die Anforderung zur Bereitstellung pcE-initiierter Punkt-zu-Punkt-LSPs von einem PCE ab. Um die Unterstützung von PCE-initierten LSPs auf dem PCC zu ermöglichen, fügen Sie die lsp-Provisioning-Anweisung auf der [edit protocols pcep pce pce-id] Hierarchie- oder [edit protocols pcep pce-group group-id] Hierarchieebene ein.

Ein PCC gibt an, dass er PCE-initiierte Point-to-Point-LSPs unterstützt und gleichzeitig die Path Computation Element Protocol (PCEP)-Sitzung mit dem PCE aufbaut. Ein PCE wählt einen PCC mit dieser Funktion aus, um einen LSP zu initiieren. Der PCE stellt dem PCC die PCE-initiierten LSP-Parameter zur Verfügung. Nach dem Erhalt der PCE-initiierten Point-to-Point-LSP-Parameter richtet das PCC den LSP ein, weist eine LSP-ID zu und delegiert den LSP automatisch an den PCE.

Wenn der PCE, der den LSP initiiert, die PCE-initiierten Punkt-zu-Punkt-LSP-Parameter nicht bereitstellt, verwendet der PCC die Standardparameter. Eine optionale LSP-Vorlage kann auch konfiguriert werden, um Werte für den PCE-initiierten Punkt-zu-Punkt-LSP anzugeben, wenn die LSP-Parameter nicht vom PCE bereitgestellt werden. Um eine LSP-Vorlage für PCE-initiierte Punkt-zu-Punkt-LSPs auf dem PCC zu konfigurieren, fügen Sie die Label-switched-path-template-Anweisung auf Hierarchieebene [edit protocols mpls lsp-external-controller lsp-external-controller] ein.

Wenn eine PCEP-Sitzung beendet wird, startet der PCC zwei Timer, ohne die PCE-initiiertenLSPs sofort zu löschen –delegation cleanup timeout und lsp cleanup timer–, um Eine Unterbrechung der Services zu vermeiden. Während dieser Zeit kann ein aktiver zustandsbehafteter PCE die Kontrolle über die von dem ausgefallenen PCE bereitgestellten LSPs erlangen.

Ein PCE kann die Delegierung des PCE-initiierten Point-to-Point-LSP an den PCC zurückschicken, um die LSP-Übertragung zwischen PCEs zu ermöglichen. Die Kontrolle über PCE-initiierte LSPs wird nach Ablauf des Timeouts der Delegationsbereinigung auf das PCC zurückgesetzt. Wenn das Timeout für die Delegierungsbereinigung abläuft und kein anderer PCE die Kontrolle über den LSP von dem ausgefallenen PCE übernommen hat, übernimmt das PCC die lokale Kontrolle über den nicht delegierte PCE-initiierten LSP. Wenn später das ursprüngliche oder ein neuer aktiver Stateful-PCE die Kontrolle über die lokal kontrollierten PCE-initiierten Point-to-Point-LSPs erlangen möchte, delegiert das PCC diese LSPs an das PCE und der LSP-Bereinigungs-Timer wird angehalten.

Das PCC wartet, bis der Timer für die LSP-Bereinigung abläuft, bevor die nicht delegierte PCE-initiierten Punkt-zu-Punkt-LSPs aus dem ausgefallenen PCE gelöscht werden. Wenn der LSP-Bereinigungs-Timer abläuft und kein anderer PCE die Kontrolle über die LSPs aus dem ausgefallenen PCE übernommen hat, löscht das PCC alle LSPs, die vom ausgefallenen PCE bereitgestellt wurden.

Ab Junos OS Version 21.1R1 unterstützen wir Nonstop Active Routing (NSR) für PCE-initiierte RSVP-basierte Point-to-Point- und Point-to-Multipoint-LSPs. Nur die primäre Routing-Engine unterhält die PCEP-Sitzung mit dem Controller. Es synchronisiert alle RSVP-LSPs, die von PCEs initiiert wurden, einschließlich Multicast-Flow-Spezifikationen für alle PCE-initiierten P2MP-LSPs, mit der Backup-Routing-Engine. Während eines Switchovers stürzt die PCEP-Sitzung ab und stellt erneut fest, wenn die Backup-Routing-Engine zur primären Routing-Engine wird. Dies reduziert den Datenverkehrsverlust für den Datenverkehr, der über PCE-initiierte RSVP-LSPs während Routing-Engine-Switchovers übertragen wird. Diese Funktion wird aktiviert, wenn NSR konfiguriert ist.

PCE-initiierter Bypass-LSP

Grundlegendes zu PCE-initiierten Bypass-LSPs

Zum Zeitpunkt eines Verbindungs- oder Knotenausfalls kann es zu Datenverkehrsausfällen kommen, weil die Backup-Schutzpfade im Netzwerk nicht über ausreichend Bandbreite verfügen, um den Datenverkehr zu bewältigen. In solchen Netzwerken kann zwar ein PCE verwendet werden, um alle Pfade zu berechnen, um die Netzwerkleistung zu optimieren, müssen die lokalen Schutzpfade auch über den PCE gesteuert werden.

Junos OS Version 19.2R1 und höher bieten teilweise Unterstützung für den Internet-Entwurf draft-cbrt-pce-stateful-local-protection-01 (läuft ab Dezember 2018), PCEP-Erweiterungen für RSVP-TE Local-Protection mit PCE-Stateful, wobei die PCEP-Funktionen erweitert werden, um es einem stateful PCE zu ermöglichen, LSPs für eine geschützte Schnittstelle zu initiieren, bereitzustellen 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 auf dem Bypass-LSP kleiner ist als die Gesamtbandbreite der primären LSPs, die sie schützen könnte.

Der bestehende Bypass-Auswahlmechanismus, der manuelle Bypass-LSPs (falls vorhanden) gegenüber dynamischen Bypass-LSPs bevorzugt, wird erweitert, um (falls vorhanden) von PCE bereitgestellte Bypass-LSPs gegenüber dynamischen Bypass-LSPs zu bevorzugen. Die über PCE bereitgestellten Bypass-LSPs haben eine höhere Präferenz gegenüber dynamischen Bypass-LSPs, werden aber weniger bevorzugt als manuelle Bypass-LSPs.

Die Für die Ausführung von Betriebsumgehungs-LSPs verwendeten Vorgänge, wie clear rsvp sessionz. B. , können auch auf den PCE-initiierten Bypass-LSPs ausgeführt werden. Sie können Befehle verwenden, z show path-computation-client status extensive . B. zur show path-computation-client lsp Anzeige von PCE-initiierten Umgehungs-LSP-Statistiken.

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

  • Erstellen Sie einen RSVP-Bypass-LSP über PCEP von einem externen Controller, wobei der Bypass-LSP:

    • kann zum Schutz von Verbindungen oder Knoten sein.

    • muss eine Nicht-Null-Bandbreite haben.

    • muss eine festgelegte strenge ERO haben.

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

  • Überschreiben Sie die Bypass-LSP-Bandbreite für die Zugangskontrolle der primären LSPs. Dies muss ein Parameter pro Umgehung sein und sollte die Aktualisierung des Abonnements pro Bypass-LSP ermöglichen.

Vorteile von PCE-initiierter Bypass-LSP

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

  • Bessere Kontrolle über den Datenverkehr nach einem Ausfall und deterministischere Pfadberechnung von Schutzpfaden.

  • Erfüllen Sie komplexe Einschränkungen und Anforderungen an die Vielfalt, wie z. B. die Aufrechterhaltung unterschiedlicher Pfade für LSPs sowie deren lokale Schutzpfade.

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

Verhalten von PCE-initiierten Bypass-LSPs während eines Ausfalls der PCEP-Sitzung

Wenn eine PCEP-Sitzung ausfällt, werden die von PCE initiierten Bypass-LSPs bis zum Ablauf des Status-Timeout-Timers verwaist. Die PCE-initiierten Bypass-LSPs werden nach Ablauf des Status-Timeout-Timer bereinigt. Um die Kontrolle über einen PCE-initiierten Bypass-LSP zu erhalten (nachdem die PCEP-Sitzung ausfällt), sendet ein PCE (entweder der primäre PCE oder eine andere sekundäre PCE) vor Ablauf des Status-Timeouts eine PCInitiate-Nachricht.

PCE-initiierte Point-to-Multipoint-LSPs

Mit der Einführung von Point-to-Multipoint-PCE-initiierten LSPs kann ein PCE einen Point-to-Multipoint-LSP dynamisch initiieren und bereitstellen, ohne dass eine lokale LSP-Konfiguration auf dem PCC erforderlich ist. Auf diese Weise kann der PCE den Zeitpunkt und die Reihenfolge der Punkt-zu-Multipoint-Pfadberechnungen innerhalb und über Path Computation Element Protocol (PCEP)-Sitzungen steuern und so ein dynamisches Netzwerk schaffen, das zentral gesteuert und bereitgestellt wird.

Weitere Informationen finden Sie unter Grundlegendes zum Path Computation Element Protocol für MPLS RSVP-TE mit Unterstützung für PCE-initiierte Point-to-Multipoint-LSPs.

SRv6 LSP in PCEP

Segment-Routing kann sowohl auf MPLS- als auch auf IPv6-Weiterleitungsebene angewendet werden. Das Path Computation Element (PCE) berechnet SR-Pfade für MPLS- und IPv6-Weiterleitungsebene. Segment-Routing für PCEP unterstützt SR-LSPs wie PCE-initiierte, lokal erstellte und delegierte SR-LSPs in der IPv6-Weiterleitungsebene.

Vorteile von SRv6-LSPs in PCEP

  • Ermöglicht die Erstellung von PCE-initiierten SRv6-LSPs.
  • Delegieren der auf dem Router erstellten SRv6-LSPs an den Controller.
  • Melden Sie die lokal auf dem Router erstellten LSPs dem Controller.
  • Die SRv6-Netzwerkprogrammierung bietet die Flexibilität, Segment-Routing ohne MPLS zu nutzen.

PCEP unterstützt das Erstellen, Updieren und Löschen von PCE initiierten farbigen und unfarbigen SRv6-LSPs. Wenn ein PCE initiierter SRv6-LSP zusammen mit einem statischen SRv6-LSP für dieselbe IP oder farbbasierte IP vorhanden ist, wird die statische SRv6 TE LSP-mitwirkende Route gegenüber der PCE-initiierten SRv6 TE LSP-Mitwirkenden Route bevorzugt.

Um eine PCEP-Sitzung so zu konfigurieren, dass sie SRv6-fähig ist, müssen Sie die srv6-capability Konfigurationsaussage unter [Edit protocols pce pce-id] oder auf [edit protocols pcep pce-group pce-id] Hierarchieebene aktivieren. Wenn die srv6-capability Konfigurationsaussage aktiviert ist, müssen Sie die Srv6-Konfigurationsaussage auch auf der Hierarchieebene [edit protocols source-packet-routing] aktivieren, andernfalls wird während des Commits der Fehler angezeigt.

Um SRv6 für SR-TE zu konfigurieren, müssen Sie die Konfigurationsaussage srv6 auf der Hierarchieebene [Edit protocols Source-Packet-Routing] hinzufügen.

[Weitere Informationen finden Sie unter Understanding SR-TE Policy for SRv6 Tunnel .

Um die maximale Segmentlistentiefe für SRv6-LSP zu konfigurieren, müssen Sie die maximum-srv6-segment-list-depth Konfigurationsaussage auf Hierarchieebene [edit protocols pcep] aktivieren.

Automatischer Bandbreiten- und PCE-gesteuerter LSP

Ab Junos OS Version 14.2R4 wird Unterstützung für automatische Bandbreite für PCE-gesteuerte LSPs bereitgestellt. In früheren Versionen galt die Option für automatische Bandbreite nicht für PCE-gesteuerte LSPs, obwohl LSPs unter der Kontrolle von Auto-Bandwdith und einschränkungensbasiertem Routing mit PCE-gesteuerten LSPs koexistieren konnten. Die Statistikerfassung für die automatische Bandbreite wurde nur wirksam, wenn der Steuerungsmodus eines PCE-gesteuerten LSP von extern auf lokal geändert wurde. Dies geschah in Fällen, wie z. B. keine Verbindung zu einem PCE oder wenn ein PCE die Delegation von LSPs zurück an den PCC zurückschickt.

TCP-MD5-Authentifizierung für PCEP-Sitzungen

Ein Stateful PCE-Server automatisiert die Erstellung von Traffic-Engineering-Pfaden im gesamten Netzwerk, erhöht die Netzwerkauslastung und ermöglicht ein maßgeschneidertes programmierbares Netzwerkerlebnis mit der Verwendung von PCEP-Kommunikation mit einem PCC. Ein PCC sendet LSP-Berichte an einen PCE-Server, und der PCE aktualisiert oder stellt LSPs zurück an den PCC. Die über eine PCEP-Sitzung gesendeten Daten sind für einen PCE-Server entscheidend, um externe Pfadberechnungen durchzuführen. Infolgedessen kann ein Angriff auf die PCEP-Kommunikation Netzwerkservices unterbrechen. Wenn geänderte PCEP-Nachrichten an einen PCC gesendet werden, können unangemessene LSPs eingerichtet werden. Wenn geänderte PCEP-Meldungen an einen PCE gesendet werden, wird vom PCE eine falsche Ansicht des Netzwerks gelernt.

In Anbetracht der Bedeutung der PCEP-Kommunikation zwischen einem PCE und PCC für die effektive Ausführung der PCE-Funktionen bietet Junos OS Version 16.1 die Funktion, eine PCEP-Sitzung mit TCP-MD5-Authentifizierung gemäß RFC 5440 zu sichern. Diese Funktion schützt die Kommunikation zwischen einem PCE und PCC über eine PCEP-Sitzung, die einem Angriff ausgesetzt sein und Netzwerkservices unterbrechen kann.

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

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

  • Verwendung des MD5-Authentifizierungsschlüssels:

  • Verwendung vordefinierter Authentifizierungs-Keychains:

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

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

  • Die erste Anwendung eines 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 bietet keine Unterstützung für einen Sitzungsauthentifizierungsmechanismus.

  • Verwenden show path-computation-client status Sie die Befehlsausgaben, show protocols pcep um den von der PCEP-Sitzung verwendeten Authentifizierungsschlüssel anzuzeigen.

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

  • Der Betrieb des Schlüsselbundes kann mithilfe der show security keychain detail Befehlsausgabe überprüft werden.

Auswirkungen der clientseitigen PCE-Implementierung auf die Netzwerkleistung

Die Pflege einer zustandsbehafteten Datenbank kann nicht trivial sein. In einer einzigen zentralisierten PCE-Umgebung muss ein Zustandsbehafteter PCE lediglich alle TE-LSPs, die vom PCE berechnet wurden, die tatsächlich eingerichteten TE-LSPs (falls dies bekannt sein kann) und an die Zeit, als die TE-LSPs abgerissen wurden, erinnern. Diese Anforderungen verursachen jedoch einen erheblichen Overhead für das Kontrollprotokoll in Bezug auf Zustand, Netzwerknutzung und -verarbeitung sowie die Optimierung von Verbindungen weltweit im gesamten Netzwerk. Daher umfassen die Bedenken einer stateful PCE-Implementierung:

  • Jeder zuverlässige Synchronisierungsmechanismus führt zu einem erheblichen Overhead auf der Steuerungsebene. PCEs können den Status synchronisieren, indem sie miteinander kommunizieren, aber wenn TE-LSPs mithilfe einer verteilten Berechnung zwischen mehreren PCEs eingerichtet werden, werden die Probleme bei der Synchronisierung und Vermeidung von Race-Bedingungen größer und komplexer.

  • Die Out-of-Band Traffic Engineering-Datenbanksynchronisierung kann komplex sein, wenn mehrere PCEs in einem verteilten PCE-Berechnungsmodell eingerichtet sind, und kann anfällig für Rennensbedingungen, Skalierbarkeitsbedenken usw. sein.

  • Pfadberechnungen unter Einbeziehung des Gesamtzustands des Netzwerks sind sehr komplex, selbst wenn der PCE detaillierte Informationen zu allen Pfaden, Prioritäten und Ebenen enthält.

Trotz der oben genannten Bedenken ist die teilweise clientseitige Implementierung des Stateful PCE in großen Traffic-Engineering-Systemen äußerst effektiv. Sie bietet eine schnelle Konvergenz und erhebliche Vorteile in Bezug auf die optimale Ressourcennutzung, indem sie die Anforderungen an globale Visibilität eines TE-LSP-Zustands und eine geordnete Steuerung der Pfadreservierungen über alle Geräte innerhalb des zu kontrollierenden Systems bietet.

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

Dieses Beispiel zeigt, wie sie das externe Path Computing durch ein Path Computation Element (PCE) für datenverkehrsbasierte Label-Switched Paths (TE LSPs) auf einem Path Computation Client (PCC) aktivieren. Außerdem wird gezeigt, wie Sie das Path Computation Element Protocol (PCEP) auf dem PCC konfigurieren, um die Kommunikation zwischen PCE und PCC zu ermöglichen.

Anforderungen

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

  • Drei Router, die eine Kombination aus Routern der ACX-Serie, Multiservice-Edge-Routern der M-Serie, universellen 5G-Routing-Plattformen der MX-Serie, Core-Routern der T-Serie oder Transport-Routern der PTX-Serie sein können, von denen einer als PCC konfiguriert ist.

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

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

HINWEIS:

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

Bevor Sie beginnen:

  1. Konfigurieren Sie die Geräteschnittstellen.

  2. Konfigurieren Sie MPLS und RSVP-TE.

  3. Konfigurieren Sie IS-IS oder ein anderes IGP-Protokoll.

Überblick

Ab Junos OS Version 12.3 wird die MPLS RSVP-TE-Funktionalität erweitert, um eine teilweise clientseitige Implementierung der stateful PCE-Architektur (Draft-ietf-pce-stateful-pce) auf einem PCC bereitzustellen.

HINWEIS:

Die teilweise clientseitige Implementierung der stateful PCE-Architektur basiert auf Version 2 des Internet Draft-ietf-pce-stateful-pce. Ab Junos OS Version 16.1 wird diese Implementierung aktualisiert, um Version 7 zu unterstützen, wie in Internet Draft-ietf-pce-stateful-pce-07 definiert. Versionen vor 16.1 unterstützen die ältere Version des PCE-Entwurfs, was zu Interoperabilitätsproblemen zwischen einem PCC mit einer vorherigen Version und einem zustandsbehafteten PCE-Server führt, der internet draft-ietf-pce-stateful-pce-07 einhält.

Um die externe Pfadverarbeitung durch einen PCE zu ermöglichen, fügen Sie die lsp-external-controller Anweisung auf PCC auf der [edit mpls] Hierarchieebene ein [edit mpls lsp lsp-name] .

Ein mit der lsp-external-controller Anweisung konfigurierter LSP wird als PCE-gesteuerter LSP bezeichnet und unterliegt standardmäßig der externen Kontrolle eines PCE. Ein aktiver Stateful-PCE kann die von der CLI festgelegten Parameter wie Bandbreite, Pfad (ERO) und Priorität für solche PCE-gesteuerten LSPs des PCC außer Kraft setzen.

Um die Kommunikation zwischen PCE und PCC zu ermöglichen, konfigurieren Sie PCEP auf der PCC-Hierarchieebene [edit protocols] .

Beachten Sie bei der Konfiguration von PCEP auf einem PCC die folgenden Überlegungen:

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

  • Junos OS Version 12.3 unterstützt nur stateful PCEs.

  • Ein PCC kann sich mit maximal 10 Stateful-PCEs verbinden. Zu einem bestimmten Zeitpunkt kann es nur einen Haupt-PCE (den PCE mit dem niedrigsten Prioritätswert oder den PCE, der sich bei Fehlen einer PCE-Priorität zuerst mit dem PCC verbindet) geben, an die der PCC LSPs für die Pfadberechnung delegiert.

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

  • Vorhandene LSP-Funktionen wie LSP-Schutz und Make-before-Break sind für PCE-gesteuerte LSPs geeignet.

  • Die automatische Bandbreitenoption ist für PCE-gesteuerte LSPs deaktiviert, obwohl LSPs unter der Kontrolle von Auto-Bandwdith und einschränkungensbasiertem Routing mit PCE-gesteuerten LSPs koexistieren können.

  • PCE-gesteuerte LSPs können durch andere CLI-Konfigurationen wie lsp-nexthop zu Routen, Weiterleitungsadjacencies, CCC-Verbindungen und logische Tunnel verwiesen werden.

  • PCE-gesteuerte LSPs unterstützen GRES nicht.

  • PCE-gesteuerte LSPs unter 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 auf externe Pfadberechnungen angewiesen, was sich auf die gesamte Einrichtungszeit, Umleitungen und Make-before-Break-Funktionen auswirkt.

  • Einrichtungszeit und Konvergenzzeit (Reroute, MBB) für bestehende LSPs sind die gleichen wie in früheren Versionen, wenn es keine PCE-gesteuerten LSPs gibt. Ein kleiner Einfluss ist jedoch in Anwesenheit von PCE-gesteuerten LSPs zu sehen.

  • Es wird erwartet, dass die ERO-Berechnungszeit deutlich höher sein wird als lokal-CSPF.

Topologie

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

In diesem Beispiel ist PCC der Eingangsrouter, der eine Verbindung zum externen aktiven Zustands-PCE herstellt.

Die externen LSPs des Routers PCC werden wie folgt berechnet:

  1. Router PCC empfängt die LSP-Tunnelkonfiguration, die über die CLI eingerichtet wurde. Wenn die empfangene Konfiguration mit externem Path Computing aktiviert wird, wird Router PCC bewusst, dass einige der LSP-Attribute – Bandbreite, Pfad und Priorität – unter der Kontrolle des zustandsbehafteten PCE stehen und delegiert den LSP an den PCE.

    In diesem Beispiel wird der externe LSP aufgerufen PCC-to-R2 und von Router PCC zu Router R2 eingerichtet. Der CLI-konfigurierte ERO für PCC-to-R2 ist PCC-R0-R1-R2. Die Bandbreite für PCC-to-R2 beträgt 10 m, und sowohl die Prioritäts- als auch die Haltepriorität sind 4.

  2. Router PCC versucht, die PCE-gesteuerten LSP-Attribute abzurufen. Um dies zu tun, sendet Router PCC eine PCRpt-Nachricht an den Stateful-PCE, in der angegeben wird, dass der LSP konfiguriert wurde. Die PCRpt-Nachricht kommuniziert den Status des LSP und enthält die lokalen Konfigurationsparameter des LSP.

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

  4. Nach dem Erhalt der neuen LSP-Parameter richtet Router PCC einen neuen LSP ein und signalisiert ihn über den VON PCE bereitgestellten Pfad.

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

  5. Router PCC sendet einen PCRpt mit der neuen RRO an den Stateful PCE.

Konfiguration

CLI-Schnellkonfiguration

Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen sie in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, und kopieren Sie dann die Befehle und fügen sie auf Hierarchieebene in die [edit] CLI ein.

PCC

R0

R1

R2

R3

Verfahren

Schritt-für-Schritt-Verfahren

Im folgenden Beispiel müssen Sie auf verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus.

So konfigurieren Sie Router PCC:

HINWEIS:

Wiederholen Sie diese Prozedur für jeden Eingangsrouter von Juniper Networks in der MPLS-Domäne, nachdem Sie die entsprechenden Schnittstellennamen, Adressen und sonstigen Parameter für jeden Router geändert haben.

  1. Konfigurieren Sie die Schnittstellen.

    Um MPLS zu aktivieren, fügen Sie die Protokollfamilie in die Schnittstelle ein, damit die Schnittstelle eingehenden MPLS-Datenverkehr nicht verwirft.

  2. Aktivieren Sie RSVP auf allen Schnittstellen von Router PCC, mit Ausnahme der Verwaltungsschnittstelle.

  3. Konfigurieren Sie den Label-Switched Path (LSP) vom Router PCC zum Router R2 und ermöglichen Sie die externe Steuerung von LSPs durch den PCE.

  4. Konfigurieren Sie den LSP von Router PCC zu Router R2, der über eine lokale Kontrolle verfügt und von den PCE-bereitgestellten LSP-Parametern außer Kraft gesetzt wird.

  5. Aktivieren Sie MPLS auf allen Schnittstellen von Router PCC mit Ausnahme der Verwaltungsschnittstelle.

  6. Konfigurieren Sie IS-IS auf allen Schnittstellen des Router-PCC mit Ausnahme der Verwaltungsschnittstelle.

  7. Definieren Sie den PCE, mit dem Router PCC verbunden ist, und konfigurieren Sie die IP-Adresse des PCE.

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

  9. Konfigurieren Sie den PCE-Typ.

Ergebnisse

Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie die show interfaces befehle eingeben show protocols . Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Wenn Sie mit der Konfiguration des Geräts fertig sind, geben Sie im Konfigurationsmodus ein commit .

Überprüfung

Bestätigen Sie, 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 ist.

Aktion

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

Bedeutung

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

Für pce1ist der Status der PCEP-Sitzung PCE_STATE_UP, was angibt, dass die PCEP-Sitzung zwischen den PCEP-Peers eingerichtet wurde.

Die Statistik zeigt PCRpts die Anzahl der Nachrichten an, die vom Router PCC an den PCE gesendet werden, um den aktuellen Status der LSPs zu melden. Die PCUpdates Statistik zeigt die Anzahl der Nachrichten an, die Router PCC vom PCE empfangen. Die PCUpdates Meldungen enthalten die PCE-geänderten 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 von Router PCC zu Router R2, wenn der LSP unter externer Kontrolle steht.

Aktion

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

Bedeutung

In der Ausgabe zeigen die Felder und LSP Control Status die LSPtype Ausgabefelder, 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 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 (Werte für Einrichtung und Halten)

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

Zweck

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

Aktion

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

Bedeutung

In der Ausgabe zeigt das LSP Control Status Ausgabefeld, dass der LSP unter lokaler Kontrolle steht. Obwohl der PCE-gesteuerte LSP unter lokaler Kontrolle steht, verwendet Router PCC weiterhin die von PCE bereitgestellten Parameter, bis die nächste Gelegenheit, den LSP neu zu signalisieren.

Die Ausgabe zeigt nun die LSP-Parameter an, die mit der CLI konfiguriert wurden, zusammen mit den PCE-bereitgestellten Parametern, die verwendet werden, um den LSP als die tatsächlich verwendeten Werte festzulegen.

  • Bandbreite – 10 Mbit/s (tatsächlicheBandbreite: 8 Mbit/s)

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

Auf dem Trigger, um den LSP erneut zu signalisieren, verwendet Router PCC die lokalen Konfigurationsparameter, um den PCE-gesteuerten LSP einzurichten.

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: Konfigurieren des Path Computation Element Protocol für MPLS RSVP-TE mit Unterstützung von PCE-initiierten Point-to-Point-LSPs

Dieses Beispiel zeigt, wie Sie den Path Computation Client (PCC) mit der Fähigkeit konfigurieren, von Path Computation Element (PCE) initiierte, datenverkehrsgesteuerte Punkt-zu-Punkt-Label-Switched Paths (LSPs) zu unterstützen.

Anforderungen

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

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

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

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

Bevor Sie beginnen:

  • Konfigurieren Sie die Geräteschnittstellen.

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

  • Konfigurieren Sie OSPF oder ein anderes IGP-Protokoll.

Überblick

Ab Junos OS Version 16.1 wird die PCEP-Funktionalität erweitert, um einem Stateful-PCE die Initiierung und Bereitstellung von Traffic-Engineering-LSPs über ein PCC zu ermöglichen. Zuvor wurden die LSPs auf dem PCC konfiguriert und der PCC die Kontrolle über die externen LSPs an einen PCE delegiert. Das Eigentum des LSP-Staates wurde vom PCC gehalten. Mit der Einführung der PCE-initiierten LSPs kann ein PCE einen Point-to-Point-LSP des Datenverkehrs dynamisch initiieren und bereitstellen, ohne dass ein lokal konfigurierter LSP auf dem PCC erforderlich ist. Beim Erhalt einer PCE-Nachricht erstellt das PCC den PCE-initiierten LSP und delegiert den LSP automatisch an den PCE.

Beachten Sie bei der Konfiguration der Unterstützung von PCE-initiierten Punkt-zu-Punkt-LSPs für ein PCC die folgenden Überlegungen:

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

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

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

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

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

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

  • Bidirektionale LSPs werden nicht unterstützt.

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

  • Der PCE, der einen Segment-Routing-LSP initiiert, kann die Bindungs-Segment-ID (SID)-Label verwenden, die mit nicht farbigen Segment-Routing-LSPs verknüpft sind, um die PCE-initiierten Segment-Routing-LSP-Pfade bereitzustellen.

    Ab Junos OS Version 18.2R1 werden statisch konfigurierte nicht farbige Segment-Routing-LSPs auf dem Eingangsgerät über eine PCEP-Sitzung an einen PCE gemeldet. Diesen nicht farbigen Segment-Routing-LSPs sind möglicherweise verbindliche SID-Label zugeordnet. Mit dieser Funktion kann der PCE dieses verbindliche SID-Label im Labelstack verwenden, um PCE-initiierte Segment-Routing-LSP-Pfade bereitzustellen.

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 Eingangsrouter, der eine Verbindung zu zwei externen zustandsbehafteten PCEs herstellt: PCE1 und PCE2.

Wenn eine neue Nachfrage besteht, initiiert der aktive Stateful-PCE dynamisch einen LSP, um die Anforderung zu erfüllen. Da PCC mit der Fähigkeit konfiguriert ist, den PCE-initiierten LSP zu unterstützen, wird die Pfadberechnung auf PCC wie folgt durchgeführt:

  1. Ein PCE sendet eine PCCreate-Nachricht an den PCC, um einen LSP zu initiieren und bereitzustellen. Der PCC richtet den PCE-initiierten LSP unter Verwendung der vom PCE empfangenen Parameter ein und delegiert den PCE-initiierten LSP automatisch an den PCE, der ihn initiiert hat.

    In diesem Beispiel ist PCE1 der aktive Stateful-PCE, der den PCE-initiierten LSP auf PCC initiiert und bereitgestellt. Nach erhalt der PCE-initiierten LSP-Parameter richtet PCC den LSP ein und delegiert automatisch den PCE-initiierten LSP an PCE1.

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

  3. Wenn PCE2 vor Ablauf des LSP-Bereinigungs-Timers die Kontrolle über den PCE-initiierten LSP erhält, delegiert PCC den PCE-initiierten LSP an PCE2, und der LSP-Bereinigungs-Timeout und die Zeitüberschreitung für die Delegierungsbereinigung werden angehalten.

  4. Wenn das Timeout für die Delegierungsbereinigung abgelaufen ist und weder PCE1 noch PCE2 die Kontrolle über den PCE-initiierten LSP übernommen haben, übernimmt PCC die lokale Kontrolle über den nicht delegierte PCE-initiierten LSP bis zum Ablauf des LSP-Bereinigungs-Timers.

  5. Nach Ablauf des LSP-Bereinigungs-Timers löscht PCC den PCE-initiierten LSP, der von PCE1 bereitgestellt wird.

Konfiguration

CLI-Schnellkonfiguration

Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen sie in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, und kopieren Sie dann die Befehle und fügen sie auf Hierarchieebene in die [edit] CLI ein.

PCC

R1

R2

Verfahren

Schritt-für-Schritt-Verfahren

Im folgenden Beispiel müssen Sie auf verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus.

So konfigurieren Sie den PCC-Router:

HINWEIS:

Wiederholen Sie diese Prozedur für jeden Eingangsrouter von Juniper Networks in der MPLS-Domäne, nachdem Sie die entsprechenden Schnittstellennamen, Adressen und sonstigen Parameter für jeden Router geändert haben.

  1. Konfigurieren Sie die Schnittstellen.

    Um MPLS zu aktivieren, fügen Sie die Protokollfamilie in die Schnittstelle ein, damit die Schnittstelle eingehenden MPLS-Datenverkehr nicht verwirft.

  2. Aktivieren Sie RSVP auf allen Schnittstellen des PCC mit Ausnahme der Verwaltungsschnittstelle.

  3. Ermöglichen Sie die externe Kontrolle von LSPs durch die PCEs.

  4. Aktivieren Sie MPLS auf allen Schnittstellen des PCC mit Ausnahme der Verwaltungsschnittstelle.

  5. Konfigurieren Sie OSPF auf allen Schnittstellen des PCC mit Ausnahme 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 PCEs, die mit dem PCC verbunden sind.

Ergebnisse

Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie die show interfaces befehle eingeben show protocols . Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Wenn Sie mit der Konfiguration des Geräts fertig sind, geben Sie im Konfigurationsmodus ein commit .

Überprüfung

Bestätigen Sie, 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 angeschlossenen PCEs.

Aktion

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

Bedeutung

Die Ausgabe zeigt den Status der PCEP-Sitzung zwischen den aktiven Stateful-PCEs und dem PCC an. Außerdem werden Informationen über die verschiedenen Arten von LSPs auf dem PCC und die Anzahl der LSPs angezeigt, die von den angeschlossenen PCEs bereitgestellt und an sie delegiert werden.

PCE1 ist der wichtigste aktive PCE und verfügt über einen PCE-initiierten LSP, der automatisch vom PCC delegiert wurde.

Überprüfung des PCE1-Status

Zweck

Überprüfen Sie den Status des hauptaktiven Status-PCE.

Aktion

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

Bedeutung

Die Ausgabe zeigt Informationen über den aktuellen aktiven Zustands-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 PCE_STATE_UPder Status der PCEP-Sitzung , was angibt, dass die PCEP-Sitzung mit dem PCC eingerichtet wurde.

Überprüfung des PCE-initiierten LSP-Status bei externer Bereitstellung des LSP

Zweck

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

Aktion

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

Bedeutung

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

Die PCEP-Sitzung zwischen PCC und PCE1 ist verfügbar, und das 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 (Setup- und Haltewerte)

Konfigurieren des Path Computation Element Protocol 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 Path Computing-Entität unterstützt. Ein Stateful Path Computaiton Element (PCE) kann verwendet werden, um externe Pfadberechnungen durchzuführen und bei steigender Nachfrage dynamische LSPs zu generieren.

Ein PCC erstellt den PCE-initiierten Point-to-Point-LSP unter Verwendung der von PCE bereitgestellten LSP-Parameter oder Parameter aus einer vorkonfigurierten LSP-Vorlage, wenn der PCE den LSP nicht bereitstellt, und delegiert automatisch den PCE-initiierten Punkt-zu-Punkt-LSP an den jeweiligen PCE. Daher ist für PCE-initiierte LSPs kein lokal konfigurierter LSP auf dem PCC erforderlich.

Ein CLI-gesteuerter LSP, PCE-gesteuerter LSP und PCE-initiierter LSP können auf einem PCC koexistieren.

Bevor Sie beginnen:

  • Konfigurieren Sie die Geräteschnittstellen.

  • Konfigurieren Sie MPLS und RSVP-TE.

  • Konfigurieren Sie OSPF oder ein anderes IGP-Protokoll.

Führen Sie die folgenden Aufgaben aus, um PCE-initiierte Punkt-zu-Punkt-LSPs zu konfigurieren:

  1. Wechseln Sie im Konfigurationsmodus zur folgenden Hierarchieebene:
  2. Geben Sie die Anzahl der Nachrichten pro Minute an, die der PCC maximal empfangen darf.
  3. Geben Sie die Anzahl der extern bereitgestellten Label Switched Paths (LSPs) über alle angeschlossenen PCEs an, die der PCC maximal akzeptieren kann.
  4. Geben Sie die eindeutige benutzerdefinierte ID für den angeschlossenen PCE zur Konfiguration der PCE-Parameter an.
  5. Geben Sie den Zeitraum (in Sekunden) an, den der PCC warten muss, bevor die Steuerung der LSPs an den Routingprotokollprozess zurückgegeben wird, nachdem eine PCEP-Sitzung getrennt wurde.
  6. Geben Sie die IPv4-Adresse des PCE an, mit dem eine Verbindung hergestellt werden soll.
  7. Geben Sie die TCP-Portnummer an, die der PCE verwendet

    Der Wert kann zwischen 1 und 65535 liegen und der Standardwert ist 4189.

  8. Geben Sie den Zeitraum (in Sekunden) an, den das PCC warten muss, bevor nicht delegierte PCE-initiierte LSPs nach dem Beenden einer PCEP-Sitzung aus dem ausgefallenen PCE gelöscht werden.
  9. Konfigurieren Sie das PCC so, dass SPs akzeptiert werden, die extern von verbundenen PCEs bereitgestellt werden. Standardmäßig lehnt der PCC PCE-initiierte LSPs ab.
  10. Geben Sie die Anzahl der unbekannten Nachrichten pro Minute an, die der PCC maximal empfangen kann, nach dem die PCEP-Sitzung geschlossen wird.

    Der Wert kann zwischen 1 und 16384 liegen, und der Standardwert ist 0 (deaktiviert oder kein Limit).

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

    Der Wert kann von 0 bis 16384 liegen, der Standardwert ist 5. Der Wert 0 deaktiviert diese Anweisung.

  12. Konfigurieren Sie den PCE-Typ.
  13. Geben Sie den Zeitraum (in Sekunden) an, für den der PCC auf eine Antwort warten muss, bevor eine Anfrage erneut gesendet wird.

    Der Wert kann zwischen 0 und 65535 Sekunden liegen.

  14. Überprüfen und bestätigen Sie die Konfiguration.

Beispielausgabe

Beispiel: Konfigurieren des Path Computation Element Protocol für MPLS RSVP-TE mit Unterstützung für PCE-gesteuerte Point-to-Multipoint-LSPs

In diesem Beispiel wird gezeigt, wie Sie den Path Computation Client (PCC) mit der Möglichkeit konfigurieren, Point-to-Multipoint-Datenverkehr entwickelte 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 Routern der ACX-, M-, MX- oder T-Serie sein können.

  • Eine virtuelle Maschine mit Virtual Route Reflector (VRR)-Funktion konfiguriert.

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

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

Bevor Sie beginnen:

  • Konfigurieren Sie die Geräteschnittstellen.

  • Konfigurieren Sie MPLS und RSVP-TE.

  • Konfigurieren Sie OSPF oder ein anderes IGP-Protokoll.

Überblick

Nachdem eine PCEP-Sitzung zwischen einem PCE und einem PCC eingerichtet wurde, meldet der PCC alle LSPs im System an die PCE für die LSP-Zustandssynchronisierung. Dazu gehören PCC-gesteuerte, PCE-delegierte und PCE-initiierte Point-to-Point-LSPs. Ab Junos OS Version 15.1F6 und 16.1R1 wird diese Funktion auch auf Point-to-Multipoint-LSPs erweitert.

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

Topologie

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

In diesem Beispiel ist PCC der Eingangsrouter, Router R1 der Transitrouter und Router R2 der Ausgangsrouter. PCC ist mit einem Virtual Route Reflector (VRR) verbunden, der mit einem PCE verbunden ist. Es gibt viele Point-to-Multipoint-Schnittstellen zwischen PCC, Router R1 und Router R2.

Die Berichterstattung von Point-to-Multipoint-LSPs erfolgt wie folgt:

  1. Wenn Router PCC mit Point-to-Point- und Point-to-Multipoint-LSPs ohne Unterstützung für Point-to-Multipoint-Berichtfunktion konfiguriert ist, werden nur die Punkt-zu-Punkt-LSPs an den angeschlossenen PCE gemeldet. Standardmäßig unterstützt ein PCC keine Point-to-Multipoint-LSP-Berichtfunktion.

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

  3. Standardmäßig bietet ein PCE Unterstützung für Point-to-Multipoint-LSP-Funktionen. Nach Erhalt der Ankündigung des PCC für Point-to-Multipoint-LSP-Funktion, der PCE im Gegenzug seine Funktion gegenüber dem PCC.

  4. Wenn PCE die Point-to-Multipoint-Funktion ansinnen hat, meldet PCC alle Zweigstellen von Point-to-Multipoint-LSPs an den PCE mithilfe der Update-Meldung.

  5. Sobald alle LSPs an den PCE gemeldet sind, wird der LSP-Zustand zwischen PCE und PCC synchronisiert.

Konfiguration

CLI-Schnellkonfiguration

Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen sie in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, und kopieren Sie dann die Befehle und fügen sie auf Hierarchieebene in die [edit] CLI ein.

PCC

R1

R2

R3

Verfahren

Schritt-für-Schritt-Verfahren

Im folgenden Beispiel müssen Sie auf verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der 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 MPLS zu aktivieren, fügen Sie die Protokollfamilie in die Schnittstelle ein, damit die Schnittstelle eingehenden MPLS-Datenverkehr nicht verwirft.

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

  3. Aktivieren Sie RSVP auf allen Schnittstellen von Router PCC, mit Ausnahme der Verwaltungsschnittstelle.

  4. Aktivieren Sie MPLS auf allen Schnittstellen von Router PCC mit Ausnahme 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 externe Pfad-Computing-Entität für den LSP.

  7. Aktivieren Sie das 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 lokale Kontrolle verfügen und von den PCE-bereitgestellten LSP-Parametern außer Kraft gesetzt werden.

  9. Konfigurieren Sie MPLS-Gruppenrichtlinien für die LSP-Berechnung mit eingeschränktem Pfad.

  10. Weisen Sie die konfigurierten administrativen Gruppenrichtlinien Router-PCC-Schnittstellen zu.

  11. Konfigurieren Sie eine Importrichtlinie für die Traffic Engineering-Datenbank (TED).

  12. Konfigurieren Sie eine interne BGP-Gruppe.

  13. Konfigurieren Sie traffic engineering für BGP und weisen Sie die Exportrichtlinie zu.

  14. Konfigurieren Sie OSPF-Bereich 0 auf allen Point-to-Multipoint-Schnittstellen des Router PCC.

  15. Konfigurieren Sie OSPF-Bereich 0 auf der Point-to-Point-Schnittstelle des Router PCC.

  16. Ermöglichen Sie Traffic-Engineering für OSPF.

  17. Definieren Sie den PCE, mit dem Router PCC verbunden ist, und konfigurieren Sie die PCE-Parameter.

  18. Konfigurieren Sie Router-PCC, um Point-to-Multipoint-LSP-Funktionen für externes Pfad-Computing zu aktivieren.

  19. Konfigurieren Sie die Traffic-Engineering-Richtlinie.

Ergebnisse

Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie die show interfaces befehle eingeben show protocols . Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Überprüfung

Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.

Überprüfung der LSP-Konfiguration auf dem PCC

Zweck

Überprüfen Sie den LSP-Typ und den Laufenden Zustand des Point-to-Multipoint-LSP.

Aktion

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

Bedeutung

Der Ausgang zeigt den 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-Zustand.

Aktion

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

Bedeutung

Die Ausgabe zeigt den aktiven PCE an, mit dem Router PCC verbunden ist, und die pce1 PCE-Parameter und den Status.

Grundlegendes zum Path Computation Element Protocol für MPLS RSVP-TE mit Unterstützung für PCE-initiierte Point-to-Multipoint-LSPs

Mit der Einführung von Point-to-Multipoint-PCE-initiierten LSPs kann ein PCE einen Point-to-Multipoint-LSP dynamisch initiieren und bereitstellen, ohne dass eine lokale LSP-Konfiguration auf dem PCC erforderlich ist. Auf diese Weise kann der PCE den Zeitpunkt und die Reihenfolge der Punkt-zu-Multipoint-Pfadberechnungen innerhalb und über Path Computation Element Protocol (PCEP)-Sitzungen steuern und so ein dynamisches Netzwerk schaffen, 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 als Reaktion auf Anwendungsanforderungen durch dynamische Erstellung und Abschaltung von Point-to-Multipoint-LSPs, wodurch ein dynamisches Netzwerk entsteht, das zentral gesteuert und bereitgestellt wird.

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

Die Signalisierung von PCE-initiierten Point-to-Multipoint-LSPs ist wie folgt:

  • When a new branch is added (Grafting)– Nur der neue Zweigstellen-Sub-LSP wird signalisiert und führt nicht zu einer erneuten Signalübertragung des gesamten Punkt-zu-Multipoint-Baumes.

    Wenn vor der Bereitstellung des neuen Sub-LSP Änderungen in der Topologie aufgetreten sind, berechnet der Path Computation Server (PCS) die gesamte Point-to-Multipoint-Struktur neu und aktualisiert den Point-to-Multipoint-LSP mithilfe einer PC-Updatemeldung.

  • When a branch is deleted (Pruning)— Der gelöschte Zweigstellen-Sub-LSP wird heruntergerissen und führt nicht zu einer Erneutübertragung des gesamten Punkt-zu-Mehrpunkt-Baumes.

  • When a branch sub-LSP parameter is changed— Änderungen in Sub-LSP-Parametern, wie Explicit Route Object (ERO), Bandbreite oder Priorität, können entweder aufgrund der Optimierung oder auf Benutzeranfrage erfolgen. Wenn es eine Anfrage für eine Sub-LSP gibt, wird die gesamte Point-to-Multipoint-Struktur neu signalisiert, und der Switchover zur neuen Instanz erfolgt, sobald die neuen Instanzen aller Zweigstellen aktiviert sind.

  • When a branch sub-LSP path fails– Ein Fehler wird dem PCS für den ausgefallenen Zweigstellen-Sub-LSP gemeldet. Nach dem Erhalt des neuen ERO von den PCS wird die gesamte Point-to-Multipoint-Struktur zusammen mit dem ausgefallenen Zweigstellen-Sub-LSP erneut signalisiert, und der Switchover zur neuen Instanz erfolgt in einer Make-before-Break -Art (MBB).

Verhalten von PCE-initiierten Point-to-Multipoint-LSPs nach pcEP-Sitzungsfehlern

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

Um die Kontrolle über einen PCE-initiierten Point-to-Multipoint-LSP nach einem PCEP-Sitzungsfehler zu erhalten, sendet der primäre oder sekundäre PCE eine PCInitiate Nachricht, bevor der state timeout Timer abläuft.

Konfigurieren von PCE-initiierten Point-to-Multipoint-LSP-Funktionen

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

Die p2mp-lsp-init-capability Anweisung bietet die Möglichkeit, Point-to-Multipoint-RSVP-TE-LSPs von einem PCE bereitzustellen. Die p2mp-lsp-update-capability Anweisung bietet die Möglichkeit, Point-to-Multipoint-RSVP-TE LSP-Parameter durch einen PCE zu aktualisieren.

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

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

  • Teilweise Konformität mit dem Internet Draft-ietf-pce-stateful-pce-p2mp (läuft im Oktober 2018 ab), Path Computation Element (PCE) Protocol Extensions für Stateful PCE-Verwendung für Point-to-Multipoint Traffic Engineering Label Switched Paths.

  • Ab Junos OS Version 21.1R1 unterstützen wir Nonstop Active Routing (NSR) für PCE-initiierte RSVP-basierte Point-to-Multipoint-LSPs. Nur die primäre Routing-Engine unterhält die PCEP-Sitzung mit dem Controller. Es synchronisiert alle RSVP-LSPs, die von PCEs initiiert wurden, einschließlich Multicast-Flow-Spezifikationen für alle PCE-initiierten P2MP-LSPs, mit der Backup-Routing-Engine. Während eines Switchovers stürzt die PCEP-Sitzung ab und stellt erneut fest, wenn die Backup-Routing-Engine zur primären Routing-Engine wird. Dies reduziert den Datenverkehrsverlust für den Datenverkehr, der über PCE-initiierte RSVP-LSPs während Routing-Engine-Switchovers übertragen wird. Diese Funktion wird aktiviert, wenn NSR konfiguriert ist.

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

  • Delegierung von Point-to-Multipoint-LSP.

  • LSP-Kontrolldelegation.

  • Interior Gateway Protocol (IGP)-Erweiterung für die PCE-Erkennung innerhalb einer IGP-Routing-Domain.

  • Anfrage-/Antwort-Messaging.

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

    Das gleiche kann erreicht werden, indem ein Zweigstellen-Sub-LSP aus der ersten Punkt-zu-Multipoint-Struktur entfernt und erneut zu einer anderen hinzugefügt wird, nachdem die Meldung angibt, dass PCReport LSP vom Gerät entfernt wird.

  • IPv6 wird nicht unterstützt.

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

  • Empty-ERO-Funktion wird nicht unterstützt.

  • Der Linkschutz wird nicht unterstützt.

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

Sie können einen einzelnen oder einen Bereich 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 Datenströmen angeben, für die diese Funktion funktionieren soll. Die Themen umfassen:

  • Route Distinguisher (RD), der der MVPN-Routing-Instanz zugeordnet ist.

  • (S,G), die die Quelle eines Multicast-Pakets und einer Ziel-Multicast-Gruppenadresse ist. Dies wird verwendet, um eingehenden Datenverkehr zu filtern, um ihn dem Tunnel zuzuordnen.

  • Point-to-Multipoint-LSP, der verwendet wird, um Datenverkehr zu senden, der der oben genannten Datenstromspezifikation entspricht.

Weitere Informationen finden Sie im Internet Draft-ietf-pce-pcep-flowspec-05 (läuft ab 16. Februar 2020) PCEP Extension for Flow Specification.

In der aktuellen Implementierung dieser Funktion werden die folgenden Abschnitte des Entwurfs nicht implementiert:

  • Abschnitt 3.1.2 — Werbung für PCE-Kapazität in der IGP

  • Abschnitt 3.2 – PCReq- und PCRep-Meldung

  • Abschnitt 7 – Die meisten Datenstromspezifikationen, außer Route DistinguDie aktuelle Implementierung dieser Funktion wird nicht unterstützt, und IPv4-Multicast-Datenstromspezifikationen werden nicht unterstützt.

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

  • Fügen Sie die pce_traffic_steering Anweisung auf der [edit protocols pcep pce pce-id] Hierarchieebene ein, um die Unterstützung der Datenstromspezifikationsfunktion (auch Traffic Steering genannt) durch den PCC anzugeben.

  • Fügen Sie die external-controller Anweisung auf Hierarchieebene [edit routing-instances routing-instance-name provider-tunnel] ein.

    Das Vorhandensein in external-controller der Provider-Tunnel-Konfiguration für MVPN zeigt an, dass der Point-to-Multipoint-LSP und (S,G) für diese MVPN-Instanz vom externen Controller bereitgestellt werden können. Auf diese Weise kann der externe Controller dynamisch (S,G) und Point-to-Multipoint-LSP für MVPN konfigurieren.

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

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

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

  • Wenn (S,G) bereits über die CLI konfiguriert ist, kann das PCC nicht dynamisch (S,G) konfiguriert werden, da die lokale Konfiguration eine höhere Priorität hat.

  • Wenn ein bestimmtes (S,G) vom externen Controller dynamisch gelernt wird und Sie dann dasselbe (S,G) für dieselbe MVPN-Instanz konfigurieren, wird das dynamisch gelernte (S,G) gelöscht und dem externen Controller über den PCC 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 (S,G) an den externen Controller.

  • Wenn der Benutzer eine bestimmte MVPN-Instanz aktiviert external-controller pccd , fordert MVPN den PCCD-Prozess an, (S,G) zu konfigurieren, falls vorhanden.

  • Wenn größere Konfigurationsänderungen an einer bestimmten MPVN-Instanz vorgenommen werden, fordert MVPN den PCCD-Prozess an, alle (S,G) für diese bestimmte MVPN-Instanz neu zu konfigurieren.

  • Alle Datenstromspezifikationen, die mit einem PCE-initiierten Point-to-Multipoint-LSP verknüpft sind, müssen den gleichen RD haben. Während der PC-Initiierung, wenn nicht alle Datenstromspezifikationen über dasselbe RD verfügen, wird die Pc-Initiierungsnachricht mit einem Fehler gelöscht.

  • Sie können einen Point-to-Multipoint-LSP nur mit selektiven Datenstromspezifikationen verknüpfen, andernfalls wird die Pc-Initiierungsnachricht mit einem Fehler gelöscht.

  • Wenn während der PC-Aktualisierung nicht alle Datenstromspezifikationen aufgrund einer neuen Datenstromspezifikation oder aufgrund einer aktualisierung der Datenstromspezifikationen nicht in allen Datenstromspezifikationen identisch sind, löst der PCC die Update-Meldung aus.

  • Wenn während der PC-Aktualisierung nicht alle Datenstromspezifikationen die selektive Bedingung erfüllen, entweder aufgrund des Hinzufügens einer neuen Datenstromspezifikation oder aufgrund einer Aktualisierung der Datenstromspezifikationen, setzt der PCC die Update-Meldung ab.

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

  • Eine Datenstromspezifikations-ID kann nur einem Point-to-Multipoint-LSP zugeordnet werden. Um dieselbe RD und (S,G) mehreren Point-to-Multipoint-LSPs zu zuordnen, können Sie mehrere Datenstromspezifikationen mit verschiedenen IDs und derselben RD & (S,G) hinzufügen.

  • Für PCEP-mapped dynamic (S,G) ist der Schwellenwert immer der Standardwert von 0.

  • Es gibt keine Begrenzung für die Anzahl der Datenstromspezifikationen, die einem einzelnen PCE-initiierten Point-to-Multipoint-LSP zugeordnet sind.

  • Die aktuelle Implementierung dieser Funktion unterstützt nicht:

    • Berichterstellung von Weiterleitungsstatus, die dem Point-to-Multipoint-LSP zugeordnet sind.

    • Dynamische Konfiguration eines inklusiven Provider-Tunnels

    • Zuordnung für MVPN-Replikationstunnel

    • Programmierbarer Routing-Protokollprozess (prpd)

    • Berichterstellung von Point-to-Multipoint-LSP mit CLI-Konfiguration, der auf MVPN-Multicast-Datenströme (S,G) abgebildet ist.

Aktivieren von Segment-Routing für das Path Computation Element Protocol

SUMMARY Sie können Segment-Routing oder Source Packet Routing in Networking (SPRING) Traffic-Engineering (SR-TE) mit dem Path Computation Element Protocol (PCEP) zur Traffic Steering aktivieren. Mit dieser Unterstützung werden die Vorteile des Segment-Routing auf die Label-Switched Paths (LSPs) erweitert, die extern durch ein Path Computation Element (PCE) gesteuert werden.

Segment-Routing für die Path Computation Element Protocol – Übersicht

Vorteile von Segment-Routing für PCEP

  • Die Einrichtung von LSPs über einen externen Controller bietet einen globalen Überblick über den Bandbreitenbedarf pro LSP und Pro Gerät im Netzwerk und ermöglicht eine einschränkungsbasierte Pfadberechnung in Online- und Echtzeit.

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

  • Ein Path Computation Client (PCC, ein eingehender Router der MX-Serie) mit Delegierungsfunktion kann die Kontrolle über die delegierten Segment-Routing-LSPs vom PCE zurückerlegen, wenn die PCEP-Sitzung ausfällt. andernfalls würden die LSPs aus dem PCC gelöscht. So können Sie den Schutz von LSP-Daten gewährleisten, indem Sie eine Situation verhindern, in der Pakete unbemerkt verworfen oder gelöscht werden (auch bekannt als Null-Route-Bedingung).

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). Mit den integrierten IGP-Erweiterungen lässt sich das Segment-Routing in die umfangreichen Multiservice-Funktionen von MPLS integrieren, einschließlich Layer 3 VPN, Virtual Private Wire Service (VPWS), Virtual Private LAN Service (VPLS) und Ethernet VPN (EVPN).

Zu den übergeordneten Komponenten der SR-Te-Lösung (Segment Routing-Traffic Engineering) gehören:

  • Verwendung einer IGP für Werbe-Link-Merkmale. Diese Funktionalität ist ähnlich wie RSVP-TE.

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

  • Verwendung einer IGP für Werbeetiketten für Links.

    In SR-TE-Funktionen:

    1. Das Eingangsgerät erstellt einen LSP, indem es die Label der Verbindungen stapelt, die es passieren möchte.

    2. Die IGP-Ankündigung per Link wird mit Label-Stacking kombiniert, um Source-Routing-LSPs auf dem Eingangsgerät zu erstellen, sodass die Transitgeräte die End-to-End-LSPs nicht kennen.

    3. LSPs werden zwischen Edge-Knoten erstellt, ohne auf die Transitgeräte pro LSP Speicheranforderungen zu stellen. (Die Erstellung solcher LSPs ist aktiviert, da es in SR-TE keine Signalübertragung pro LSP gibt.)

    4. Die Label pro Nachbarn werden gestapelt, was zur Verwaltung einer großen Anzahl von Labeln führt, 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-delegierte LSPs.

PCE-initiierte Segment-Routing-LSPs

Die VON PCE initiierten Segment-Routing-LSPs sind die LSPs, die der PCE für die Adjacency- und Node-Segmente erstellt.

Der PCE führt die folgenden Funktionen aus:

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

  2. Stellt den LSP auf dem Path Computation Client (PCC) unter Verwendung von PCEP-Segment-Routing-Erweiterungen bereit.

  3. Analysiert die PCEP-Segment-Routing-Erweiterungen.

  4. Erstellt eine Tunnelroute auf dem PCC, die ihren eigenen Präferenzwert hat und in der Routingtabelle inet.3 zur Verfügung gestellt wird, um IP-Datenverkehr und -Services wie jede andere Tunnelroute aufzulösen.

Das PCC führt folgende Funktionen aus:

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

    Junos OS unterstützt S-EROs, die den ersten Hop als strikten Hop enthalten; Junos OS unterstützt die Auswahl der ausgehenden Schnittstelle auf dem PCC basierend auf einem Lose-Hop Node Segment ID (SID). Die restlichen Hops können jedoch lose sein. Für die S-EROs, die über den ersten Hop hinausgehen, wird keine spezifische Verarbeitung durchgeführt, außer das Label einfach für die Erstellung des nächsten Hops zu verwenden.

  2. Lehnt den S-ERO ab, wenn:

    • Der S-ERO hat keine Label darin.

    • Der S-ERO enthält mehr als sechs Hops.

    Der PCC erstellt eine Multipath-Route zu gleichen Kosten (ECMP), wenn mehrere LSPs zum gleichen Ziel mit derselben Metrik kommen.

  3. Wartet darauf, dass der PCE alle Ereignisse verarbeitet, die nach der Bereitstellung zu einer Änderung des Segment-Routing-LSP führen, z. B. wenn das Label geändert oder zurückgezogen wird oder wenn eine der schnittstellen, die vom LSP durchlaufen werden, ausfällt.

Wenn die PCEP-Sitzung ausfällt, wird der vom PCE initiierte Segment-Routing-LSP:

  1. Bleibt 300 Sekunden betriebsbereit.

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

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

PCE-delegierte Segment-Routing-LSPs

Die PCE-delegierten Segment-Routing-LSPs sind die LSPs, die vom PCC lokal konfiguriert und dann an einen PCE-Controller delegiert werden.

HINWEIS:

Junos OS Version 20.1R1 unterstützt:

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

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

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

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

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

Nach dem Delegieren eines Segment-Routing-LSP steuert der PCE die delegierten LSPs und kann die LSP-Attribute für die Pfadberechnung ändern. Die LSP-Steuerung wird auf das PCC zurückgesetzt, wenn die PCEP-Sitzung zwischen dem PCC und dem PCE ausfällt. Die PCE-delegierten LSPs haben einen Vorteil gegenüber PCE-initiierten LSPs, wenn die PCEP-Sitzung ausfällt. Im Fall von PCE-initiierten LSPs werden die LSPs aus dem PCC gelöscht, wenn die PCEP-Sitzung ausfällt. Im Fall von PCE-delegierten LSPs übernimmt das PCC jedoch, wenn die PCEP-Sitzung ausfällt, die Kontrolle über die delegierten LSPs aus dem PCE zurück. Infolgedessen verhindern wir mit PCE-delegierten LSPs eine Situation, in der Pakete unbemerkt verworfen werden (auch als Null-Route-Bedingung bezeichnet), wenn die Sitzung ausfällt.

Die folgenden Arten von Segment-Routing-LSPs unterstützen die PCE-Delegierungsfunktion:

  • Static LSPs— Statisch konfigurierte Quell-Routing-Pfade, die den gesamten Labelstack statisch konfiguriert haben.

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

  • Computed LSPs— Statisch konfigurierte Quell-Routing-Pfade, die mit distributed Constrained Shortest Path First (CSPF) berechnet werden.

  • Dynamic LSPs— Dynamisch erstellte Tunnel, die durch das dynamische Tunnelmodul ausgelöst werden und eine Last-Hop-ERO-Auflösung haben.

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

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

HINWEIS:

Sie müssen die lsp-external-controller pccd Anweisung auf der [edit protocols source-packet-routing] Hierarchie- und [edit protocols mpls] Hierarchieebene einschließen, bevor Sie die Delegierungsfunktion auf dem PCC konfigurieren.

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

Quelle für Segment-Routing-LSP

Konfigurationshierarchie

  • Automatisch übersetzte LSPs

  • Statische LSPs

Liste der primären Segmente bei [edit protocols source-packet-routing source-routing-path lsp-name primary path-name]

Computed LSPs (distributed CSPF)

Liste des primären Segments des Source-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

Primary Segment List der Source-Routing-Pfadvorlage 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 aus der Befehlsausgabe "Show Spring-Traffic-Engineering" anzeigen.

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

Tabelle 3: PCEP Interaktion LSP-Delegation

Konfigurationshierarchie für lsp-externer Controller

Quell-Routing-Pfad Delegierungsstatus

PCEP-Interaktion zwischen PCC und PCE

Liste des primären Segments des Quell-Routing-Pfads

Erste Delegierung

  1. Eine PCReport-Nachricht wird zur Delegierung an den PCE gesendet. Der PCReport enthält nur Einschränkungen und Pfaddetails (z. B. ERO).

  2. PCE berechnet den Pfad für LSP und meldet, dass sich der Pfad im Down-Zustand befindet.

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

Das gleiche Verhalten wird beobachtet, wenn der Routing-Protokollprozess (rpd) neu gestartet wird oder ein Switchover der Routing-Engine stattfindet.

Liste des primären Segments des Quell-Routing-Pfads

Delegierung vorhandener Pfade

  1. Ein PCReport wird zur Delegierung an den PCE gesendet. Der PCReport enthält nur Einschränkungen und Pfaddetails (z. B. ERO).

  2. Ein entsprechendes primäres Segment wird an den PCE delegiert.

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

  4. Das primäre Segment trägt weiterhin zur Route bei, wie von der lokalen Konfiguration oder Berechnung bestimmt, bis ein PCUpdate vom PCE empfangen wird.

    • Wenn Seamless BFD (S-BFD) nicht für das primäre Segment konfiguriert ist, wird die Route nicht weiter aktualisiert und der LSP-Status wird auch nicht überwacht und an den PCE gemeldet. Der LSP-Status an dieser Stelle wird als hoch oder unten gemeldet, je nachdem, ob die Pfadberechnung zu diesem Zeitpunkt erfolgreich war.

    • Wenn S-BFD für das primäre Segment konfiguriert ist, wird der Status des primären Segments verfolgt und an den PCE gemeldet. Wenn BFD feststellt, dass das primäre Segment ausfällt, wird der entsprechende primäre Pfad aus der Route entfernt. Dieselbe Route, die zuvor berechnet wurde, wird neu programmiert, wenn dieser Pfad jetzt verfügbar ist.

  5. Wenn eine PCUpdate-Nachricht vom PCE empfangen wird, verwendet SR-TE den empfangenen Parameter, um den Pfad einzurichten, für den die PCReport-Nachricht gesendet wurde. Der programmierte Pfad enthält dann nur die vom PCE empfangene Segmentliste, und alle anderen Segmentlisten, die zuvor programmiert wurden, werden entfernt. Diese Neuprogrammierung der Route erfolgt nach dem Make-before-Break-Prinzip.

Primäres Segment des Source-Routing-Pfads

Die Delegierung ist nicht konfiguriert oder wurde gelöscht.

Die Segmentliste aus dem PCE (sofern 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 nach dem Make-before-Break-Prinzip zu programmieren.

Segmentliste des Quell-Routing-Pfads

Die Delegierung ist aktiviert, nachdem LSP konfiguriert wurde.

Die Delegierungsfunktionen werden für die primäre Segmentliste unter dem Quell-Routing-Pfad ausgelöst.

Segmentliste des Quell-Routing-Pfads

Die Delegierung ist nicht konfiguriert oder wurde gelöscht.

Die Delegierungsfunktionen werden aus der primären Segmentliste unter dem Quell-Routing-Pfad entfernt.

Primäre Segmentliste der Quell-Routing-Pfadvorlage

Die Delegierung ist aktiviert, nachdem LSP konfiguriert wurde.

  • Unter der Quell-Routing-Pfadvorlage wird die Delegierungsfunktion für den gesamten Quell-Routing-Pfad ausgelöst.

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

  • Unter dem primären Pfad in der Quell-Routing-Pfadvorlage wird die Delegierungsfunktion für diesen bestimmten primären Pfad entsprechend der Konfiguration ausgelöst.

Primäre Segmentliste der Quell-Routing-Pfadvorlage

Die Delegierung ist nicht konfiguriert oder wurde gelöscht.

Die Delegierungsfunktionen werden von allen Quell-Routing-Pfaden und primären Pfaden entfernt, die der Vorlagenkonfiguration entsprechen.

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

Die Unterstützung von Segment-Routing für PCEP trägt nicht zur Leistungsbelastung des Systems bei. Es hat jedoch die folgenden Einschränkungen:

  • Ein SR-TE LSP ist auf dem PCC nicht lokal geschützt. Wenn der LSP mehr als sechs Hops hat, wird auf dem LSP außer der Übertragung von einfachem IP-Datenverkehr kein Service auf dem LSP bereitgestellt.

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

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

  • IPv6 wird nicht unterstützt.

  • PCE-delegierte LSPs unterstützen Folgendes nicht:

    • Farbige SR-TE-LSPs

    • IPv6-LSPs

    • Sekundäre Segmentliste des Source-Routing-Pfads. Es kann nur ein Pfad der Segmentliste delegiert werden.

    • Multisegment-Standard. Nur das erste Segment der Segmentliste wird delegiert und an den Controller gemeldet.

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

Dieses Beispiel zeigt, wie Sie Segment-Routing oder SPRING Traffic-Engineering (SOURCE Packet Routing in Networking) (SR-TE) für das Path Computation Element Protocol (PCEP) konfigurieren. In der Konfiguration nutzen wir die Vorteile des Segment-Routing mit den Vorteilen des externen Path Computing für ein effizientes Traffic-Engineering.

Anforderungen

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

  • Vier universelle 5G-Routing-Plattformen der MX-Serie, bei denen der eingehende Router der Path Computation Client (PCC) ist.

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

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

    Für PCE-Delegierungsfunktionen müssen Sie Junos OS Version 20.1R1 oder höher ausführen.

Bevor Sie beginnen:

  • Konfigurieren Sie die Geräteschnittstellen.

  • Konfigurieren Sie MPLS.

  • Konfigurieren Sie IS-IS.

Überblick

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

  • Die Implementierung von PCE-initiierten LSPs wird in Junos OS Version 17.2R1 eingeführt, wo die Traffic-Engineering-Funktionen des Segment-Routing in PCEP-Sitzungen für LSPs unterstützt werden, die von einem PCE initiiert werden. Der PCE erstellt die LSPs für die Adjacency- und Node-Segmente. Tunnelrouten werden in der Routing-Tabelle inet.3 des PCC erstellt, die den PCE-initiierten SR-TE-LSPs entspricht.

  • Die Implementierung von PCE-delegierten LSPs wird in Junos OS Version 20.1R1 eingeführt, wo die lokal konfigurierten nicht farbigen IPv4-Segment-Routing-LSPs auf dem PCC an einen PCE-Controller delegiert werden können. Der PCE steuert dann den LSP und kann LSP-Attribute für die Pfadberechnung ändern.

Die PCE-delegierten LSPs haben einen Vorteil gegenüber PCE-initiierten LSPs, wenn die PCEP-Sitzung ausfällt. Im Fall von PCE-initiierten LSPs werden die LSPs aus dem PCC gelöscht, wenn die PCEP-Sitzung ausfällt. Im Fall von PCE-delegierten LSPs übernimmt das PCC jedoch, wenn die PCEP-Sitzung ausfällt, die Kontrolle über die delegierten LSPs aus dem PCE zurück. Infolgedessen verhindern wir mit PCE-delegierten LSPs eine Situation, in der Pakete unbemerkt verworfen werden (auch als Null-Route-Bedingung bezeichnet), wenn die PCEP-Sitzung ausfällt.

So aktivieren Sie Das Segment-Routing für PCEP:

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

  1. Ermöglichen Sie das externe Path Computing für MPLS, indem Sie die lsp-external-controller Anweisung auf Hierarchieebene [edit protocols mpls] angeben.

    Diese Konfiguration ist auch für PCEP mit RSVP-TE-Erweiterungen erforderlich. Sie können PCEP mit RSVP-TE nicht deaktivieren, wenn das Segment-Routing für PCEP aktiviert ist.

  2. Ermöglichen Sie das externe Path Computing für SR-TE, indem Sie die lsp-external-controller pccd Anweisung auf Hierarchieebene [edit protocols spring-traffic-engineering] einberechnen.

  3. Aktivieren Sie das Segment-Routing für PCE, indem Sie die spring-capability Anweisung auf Hierarchieebene [edit protocols pcep pce pce-name] einbesteigen.

  4. Konfigurieren Sie optional die maximale SID-Tiefe für den PCE, indem Sie die max-sid-depth number Anweisung auf Hierarchieebene [edit protocols pcep pce pce-name] angeben.

    Die maximale SID-Tiefe ist die Anzahl der SIDs, die von einem Knoten oder einem Link auf einem Knoten unterstützt werden. Wenn nicht konfiguriert, wird ein standardmäßiger maximaler SID-Wert von 5 angewendet.

  5. Konfigurieren Sie optional den Voreinstellungswert für Segment-Routing, indem Sie den preference preference-value Wert auf [edit protocol spring-te] Hierarchieebene einbesteigen.

    Der Voreinstellungswert gibt die Reihenfolge an, in der ein Pfad als aktives Pfadformular unter den Kandidatenpfaden ausgewählt wird, wobei ein höherer Wert eine höhere Präferenz hat. Wenn die Konfiguration nicht konfiguriert ist, wird der Standardeinstellungswert 8 angewendet.

  6. Konfigurieren Sie optional die Segment-Routing-Protokollierung für die Fehlerbehebung, indem Sie die traceoptions Anweisung auf Hierarchieebene [edit protocols spring-te] angeben.

Führen Sie für die PCE-Delegierung von Segment-Routing-LSPs zusätzlich zu den oben genannten Schritten Folgendes aus:

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

  2. Aktivieren Sie die Delegierungsfunktion des lokal konfigurierten LSP auf dem PCC, indem Sie die lsp-external-controller pccd Anweisung in eine der folgenden Hierarchien aufnehmen, abhängig von der LSP-Quelle des Segment-Routing:

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

    • Für statisch konfigurierte Quell-Routing-Pfade, bei denen der gesamte Labelstack statisch konfiguriert ist, und Quell-Routing-Pfade, 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 ausgelöst werden und die 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 haben.

Topologie

Abbildung 8 veranschaulicht eine Beispiel-Netzwerktopologie, in der eine PCEP-Sitzung zwischen dem PCE und dem PCC (eingehender Router der MX-Serie) ausgeführt wird. Die Router R1, R2 und R3 sind die anderen Router der MX-Serie im Netzwerk. In diesem Beispiel konfigurieren wir das Segment-Routing für PCEP auf dem PCC. Außerdem konfigurieren wir eine statische Route auf dem PCC zum Router R3, um die Verwendung von SR-TE-Tunnelrouten beim Routing des Datenverkehrs für die statische Route zu überprüfen.

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

Konfiguration

CLI-Schnellkonfiguration

Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen sie in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, kopieren Sie die Befehle, fügen Sie sie auf Hierarchieebene in die [edit] CLI ein, und geben Sie dann aus dem Konfigurationsmodus ein commit .

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

PCC

Router R1

Router R2

Router R3

Verfahren
Schritt-für-Schritt-Verfahren

In diesem Beispiel konfigurieren wir nur den PCC.

Für die folgenden Schritte müssen Sie auf verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in 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 vom PCC zum Router R3.

    Die statische Route wird nur zu Verifizierungszwecken erstellt und wirkt sich nicht auf die Funktionsfunktionalität aus.

  4. Konfigurieren Sie RSVP auf allen Schnittstellen des PCC mit Ausnahme der Verwaltungsschnittstelle.

  5. Konfigurieren Sie MPLS auf allen Schnittstellen des PCC mit Ausnahme der Verwaltungsschnittstelle.

  6. Aktivieren Sie externe Path Computing-Funktionen für MPLS.

  7. Konfigurieren Sie IS-IS-Ebene 2 auf allen Schnittstellen des PCC, mit Ausnahme der Verwaltungs- und Loopback-Schnittstellen.

  8. Konfigurieren Sie SRGB-Attribute (Segment Routing Global Block) für Das Segment-Routing.

  9. Aktivieren Sie externe Path Computing-Funktionen für SR-TE.

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

  11. Ermöglichen Sie die Bereitstellung von Segment-Routing-LSPs durch den PCE.

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

  13. Definieren Sie die statischen Parameter der Segmentliste static_seg_list_1 .

  14. Konfigurieren Sie einen statischen Segment-Routing-LSP vom PCC zum Router R3 für die PCE-Delegierung.

  15. Aktivieren Sie die Delegierungsfunktion für den static_srte_lsp_1 Quell-Routing-Pfad.

    Indem Sie die Schritte 13, 14 und 15 abschließen, ermöglichen Sie dem PCC, die Segment-Routing-LSPs an den PCE zu delegieren.

  16. Commit der Konfiguration.

Ergebnisse

Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie die show interfacesBefehle und show protocolsshow routing-optionsdie Befehle eingeben. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Wenn Sie mit der Konfiguration des Geräts (des PCC) fertig sind, geben Sie im Konfigurationsmodus ein commit .

Überprüfung

Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.

Überprüfen der IS-IS-Adjacency und -Label
Zweck

Überprüfen Sie die IS-IS-Nachbarschaft auf dem PCC. Notieren Sie sich den SRGB-Labelbereich, die Adjacency- und Node-Segmentwerte sowie die Ausgabefelder der SPRING-Funktion.

Aktion

Führen Sie im Betriebsmodus die show isis adjacency extensiveBefehle show isis database extensiveund show isis overview Befehle aus.

Bedeutung

Die IS-IS-Verbindung zwischen PCC und PCE und die zwischen PCC und Router R1 sind in Betrieb. Die Ausgabe zeigt auch die Labelzuweisungen für die angrenzenden und Knotensegmente an.

Traffic Engineering-Datenbank überprüfen
Zweck

Überprüfen Sie die Traffic-Engineering-Datenbankeinträge auf dem PCC.

Aktion

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

Bedeutung

Die Traffic-Engineering-Datenbank enthält Einträge, die von den Routern R1, R2 und R3 angekündigt werden, die der PCE für das externe Path Computing für den 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 lspBefehle show spring-traffic-engineering lsp detailund show route protocol spring-te Befehle aus.

Bedeutung

Die Ausgaben zeigen, dass zwei SR-TE-LSPs –adj_sid_lsp und node_sid_lsp– vom PCE für die Adjacency- bzw. Node-Segmente erstellt wurden.

Der Segment-Routing-LSP static_srte_lsp_1, , wird mit der Delegierungsfunktion aktiviert. Das Delegation info Feld zeigt den Steuerungs- und Routing-Status von PCE-delegierten LSPs. Externally controlled bedeutet, dass der PCE die Kontrolle über die LSPs hat. Externally routed Bedeutet, dass der PCE den ERO für den Quell-Routing-Pfad bereitgestellt hat.

Tunnelroutenerstellung überprüfen
Zweck

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

Aktion

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

Bedeutung

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

Überprüfen von Weiterleitungstabelleneinträgen
Zweck

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

Aktion

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

Bedeutung

Die SR-TE LSP-Ziel-IP-Adresse für Router R3 wird als Weiterleitungseintrag installiert.

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

Stellen Sie sicher, dass die statische Route die Tunnelroute übernimmt, die für die SR-TE-LSPs erstellt wurde.

Aktion

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

Bedeutung

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

Statisches Segment-Routing Label Switched Path

Die Segment-Routing-Architektur ermöglicht es den Eingangsgeräten in einem Core-Netzwerk, den Datenverkehr über explizite Pfade zu steuern. 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 oder IP-Datenverkehr sein, was dazu führt, dass der Weiterleitungsvorgang am Eingangsgerät entweder ein Label-Swap oder eine zielbasierte Suche ist.

Grundlegendes zu statischem Segment-Routing-LSP in MPLS-Netzwerken

Quellpaket-Routing oder Segment-Routing ist eine Architektur auf Steuerungsebene, die es einem Eingangsrouter ermöglicht, ein Paket durch eine bestimmte Gruppe von Knoten und Verbindungen im Netzwerk zu steuern, ohne sich auf die Zwischenknoten im Netzwerk zu verlassen, um den tatsächlichen Pfad zu bestimmen.

Einführung in Segment-Routing-LSPs

Segment-Routing nutzt das Quell-Routing-Paradigma. Ein Gerät lenkt ein Paket durch eine geordnete Liste von Anweisungen, die als Segmente bezeichnet werden. Ein Segment kann jede Anweisung, topologische oder servicebasiert darstellen. Ein Segment kann eine lokale Semantik zu einem Segment-Routing-Knoten oder zu einem globalen Knoten innerhalb einer Segment-Routing-Domäne haben. Segment-Routing erzwingt einen Datenfluss durch alle topologischen Pfade und Serviceketten, während der Status pro Datenstrom nur am Eingangsgerät zur Segment-Routing-Domäne beibehalten wird. Segment-Routing kann direkt auf die MPLS-Architektur angewendet werden, ohne dass sich dies auf der Weiterleitungsebene ändert. Ein Segment wird als MPLS-Label codiert. Eine geordnete Liste von Segmenten wird als Stapel von Labeln codiert. Das zu verarbeitene Segment steht ganz oben auf dem Stack. Nach Abschluss eines Segments wird das entsprechende Label aus dem Stack geknallt.

Segment-Routing-LSPs können entweder dynamisch oder statisch sein.

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

Static segment routing LSPs– Wenn ein Segment-Routing-LSP auf dem Eingangsgerät durch eine lokale Konfiguration erstellt wird, wird der LSP statisch bereitgestellt.

Ein statischer Segment-Routing-LSP kann außerdem basierend auf der Konfiguration color der Anweisung auf [edit protocols source-packet-routing source-routing-path lsp-name] Hierarchieebene als farbige und nicht-farbige LSPs 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 Anweisung 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 der Verwendung von Segment-Routing-LSPs

  • Statisches Segment-Routing hängt nicht vom LSP-Weiterleitungsstatus auf Transit-Routern ab. Dadurch entfällt die Notwendigkeit der Bereitstellung und Aufrechterhaltung pro LSP-Weiterleitungsstatus im Core.

  • Bieten Sie MPLS-Netzwerken eine höhere Skalierbarkeit.

Farbiger statischer Segment-Routing-LSP

Ein statischer Segment-Routing-LSP, der mit der color Anweisung konfiguriert ist, wird als farbiger LSP bezeichnet.

Grundlegendes zu farbigen statischen Segment-Routing-LSPs

Ähnlich wie bei einer BGP-Segment-Routing-Richtlinie wird die Eingangsroute des farbigen LSP in den Routing-Tabellen oder inet6color.0 Routing-Tabellen mit destincation-ip-address, color schlüssel für die inetcolor.0 Zuordnung des IP-Datenverkehrs installiert.

Ein statischer gefärbter Segment-Routing-LSP kann eine Bindungs-SID haben, für die eine Route in der mpls.0 Routing-Tabelle installiert ist. Dieses verbindliche SID-Label wird verwendet, um gekennzeichneten Datenverkehr dem Segment-Routing-LSP zuzuordnen. Die Gateways der Route werden aus den Segmentlistenkonfigurationen unter den primären und sekundären Pfaden abgeleitet.

Segmentliste der farbigen Segment-Routing-LSPs

Die farbigen statischen Segment-Routing-LSPs unterstützen bereits den Ersten Hop-Label-Modus zur Auflösung eines LSP. Der First-Hop-IP-Modus wird jedoch für farbige Segment-Routing-LSPs nicht unterstützt. Ab Junos OS Version 19.1R1 wird eine Commit-Check-Funktion eingeführt, um sicherzustellen, dass alle Segmentlisten, die zu den farbigen Routen beitragen, das Mindestetikett für alle Hops aufweisen. Wenn diese Anforderung nicht erfüllt ist, wird das Commit blockiert.

Nicht farbiger statischer Segment-Routing-LSP

Ein statischer Segment-Routing-LSP, der ohne die color Anweisung konfiguriert wird, ist ein nicht farbiger LSP. Ähnlich wie PCEP-Segment-Routing-Tunnel wird die Eingangsroute in den inet.3 Routing-Tabellen oder inet6.3 Routing-Tabellen installiert.

Junos OS unterstützt nicht farbige statische Segment-Routing-LSPs auf Eingangsroutern. Sie können nicht farbige statische Segment-Routing-LSP bereitstellen, indem Sie einen Quell-Routing-Pfad und eine oder mehrere Segmentlisten konfigurieren. Diese Segmentlisten können von mehreren nicht farbigen Segment-Routing-LSPs verwendet werden.

Verständnis von nicht farbigen Segment-Routing-LSPs

Der nicht farbige Segment-Routing-LSP hat einen eindeutigen Namen und eine Ziel-IP-Adresse. Eine Eingangsroute zum Ziel wird in der Routingtabelle inet.3 mit einer Standardeinstellung von 8 und einer Metrik von 1 installiert. Mit dieser Route können nicht farbige Services dem Segment-Routing-LSP zugeordnet werden, der sich auf das Ziel bezieht. Falls der nicht farbige Segment-Routing-LSP keine Eingangsroute erfordert, kann die Eingangsroute deaktiviert werden. Ein nicht farbiger Segment-Routing-LSP verwendet verbindliches SID-Label, um Segment-Routing-LSP-Stitching zu erreichen. Dieses Label kann verwendet werden, um den Segment-Routing-LSP als Segment zu modellieren, das weiter verwendet werden kann, um andere Segment-Routing-LSPs hierarchisch zu erstellen. Der Transit des bindenden SID-Labels hat standardmäßig eine Präferenz von 8 und eine Metrik von 1.

Ab Junos OS Version 18.2R1 werden statisch konfigurierte nicht farbige Segment-Routing-LSPs auf dem Eingangsgerät über eine Path Computation Element Protocol (PCE)-Sitzung an das Path Computation Element Protocol (PCE) gemeldet. Diesen nicht farbigen Segment-Routing-LSPs sind möglicherweise SID-Label (Binding Service Identifier) zugeordnet. Mit dieser Funktion kann der PCE dieses verbindliche SID-Label im Labelstack verwenden, um PCE-initiierte Segment-Routing-LSP-Pfade bereitzustellen.

Ein nicht farbiger Segment-Routing-LSP kann maximal 8 primäre Pfade haben. Wenn mehrere primäre Pfade für den Betrieb vorhanden sind, verteilt die Packet Forwarding Engine (PFE) den Datenverkehr über die Pfade basierend auf Load Balancing-Faktoren wie der auf dem Pfad konfigurierten Gewichtung. Dies ist equal cost Multi Path (ECMP), wenn auf keinem der Pfade eine Gewichtung konfiguriert oder ein gewichtetes ECMP konfiguriert wird, wenn mindestens einer der Pfade eine Nicht-Null-Gewichtung auf den Pfaden konfiguriert hat. In beiden Fällen, wenn einer oder einige der Pfade ausfällt, stellt die PFE den Datenverkehr über die verbleibenden Pfade neu aus, was automatisch zum Schutz des Pfads führt. Ein nicht farbiger Segment-Routing-LSP kann einen sekundären Pfad für dedizierten Pfadschutz haben. Wenn ein primärer Pfad ausfällt, stellt der PFE den Datenverkehr zu den verbleibenden funktionalen primären Pfaden neu aus. Andernfalls wechselt die PFE den Datenverkehr in den Backup-Pfad, wodurch der Pfad geschützt wird. Ein nicht farbiger Segment-Routing-LSP kann eine Metrik für [edit protocols source-packet-routing source-routing-path lsp-name] seine Eingangs- und Bindungs-SID-Routen angeben. Mehrere nicht farbige Segment-Routing-LSPs haben dieselbe Zieladresse, die zum nächsten Hop der Eingangsroute beiträgt.

Mehrere nicht farbige Segment-Routing-LSPs haben dieselbe Zieladresse, die zum nächsten Hop der Eingangsroute beiträgt. Jeder primäre oder sekundäre Pfad jedes Segment-Routing-LSP wird als Gateway-Kandidat betrachtet, wenn der Pfad funktionell ist und der Segment-Routing-LSP die beste Wahl all dieser Segment-Routing-LSPs hat. Die maximale Anzahl von Gateways, die der nächste Hop halten kann, darf jedoch die RPD-Grenze für mehrere Pfade nicht überschreiten, die standardmäßig 128 beträgt. Zusätzliche Pfade werden beschnitten, zuerst sekundäre Pfade und dann primäre Pfade. Eine bestimmte Segmentliste kann von diesen Segment-Routing-LSPs mehrfach als primäre oder sekundäre Pfade bezeichnet werden. In diesem Fall gibt es mehrere Gateways, die jeweils eine eindeutige Segment-Routing-LSP-Tunnel-ID haben. Diese Gateways sind unterschiedlich, obwohl sie den gleichen ausgehenden Label-Stack und dieselbe Schnittstelle haben. Ein nicht farbiger Segment-Routing-LSP und ein farbiger Segment-Routing-LSP können auch die gleiche Zieladresse haben. Sie entsprechen jedoch verschiedenen Zieladressen für Eingangsrouten, da die Farbadresse des Segment-Routing-LSP sowohl mit ihrer Zieladresse als auch mit ihrer Farbe erstellt wird.

HINWEIS:

Wenn ein statischer, nicht farbiger Segment-Routing-LSP und ein von PCEP erstelltes Segment-Routing-LSP zusammen existieren und dieselbe Adressierung haben, die zur gleichen Eingangsroute beiträgt, wenn sie auch dieselbe Präferenz haben. Andernfalls wird der Segment-Routing-LSP mit der besten Präferenz für die Route installiert.

Segmentliste der nicht farbigen 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 Begrenzung der Segmentliste nicht überschreiten. Die maximale Bindung von Segmentlisten an einen LSP-Tunnel wird von 8 auf 128 erhöht, mit maximal 1000 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 [edit protocols source-packet-routing] Hierarchieebene konfigurieren.

Vor Junos OS Version 19.1R1 musste der erste Hop der Segmentliste eine IP-Adresse einer ausgehenden Schnittstelle sein, und der zweite zu nth Hop konnte SID-Label sein, damit ein nicht farbiger statischer Segment-Routing-LSP nutzbar war. Ab Junos OS Version 19.1R1 gilt diese Anforderung nicht, da der erste Hop der nicht farbigen statischen LSPs jetzt zusätzlich zu DEN IP-Adressen auch SID-Label unterstützt. Mit der Unterstützung des ersten Hop-Label werden MPLS Fast Reroute (FRR) und weighted equal-cost Multipath aktiviert, um die statischen nicht-farbigen Segment-Routing-LSPs zu lösen, ähnlich wie farbige statische LSPs.

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

Sie können in jeder der folgenden Hierarchien konfigurieren inherit-label-nexthops . Die inherit-label-nexthops Anweisung wird nur wirksam, wenn der erste Hop 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 inherit-label-nexthops Anweisung global konfiguriert ist, hat sie Vorrang vor der Konfiguration auf Segmentlistenebene, und die inherit-label-nexthops Konfiguration wird auf alle Segmentlisten angewendet. Wenn die inherit-label-nexthops Anweisung nicht global konfiguriert ist, werden nur Segmentlisten mit beiden Labeln und IP-Adresse im ersten Hop und mit inherit-label-nexthops Anweisung konfiguriert, mithilfe von SID-Labeln aufgelöst.

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

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

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

Erste Hop-Spezifikation

Modus der LSP-Auflösung

Nur IP-Adresse

Zum Beispiel:

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

Die Segmentliste wird über die IP-Adresse aufgelö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-Labeln aufgelöst.

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

Zum Beispiel:

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

Standardmäßig wird die Segmentliste über die IP-Adresse aufgelöst.

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

Zum Beispiel:

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

Die Segmentliste wird mithilfe von SID-Labeln aufgelöst.

Sie können den show route ip-address protocol spring-te active-path table inet.3 Befehl verwenden, um die nicht farbigen Datenverkehrs-LSPs für Segment-Routing anzuzeigen, die mehrere Segmentlisten in der Routingtabelle inet.3 installiert haben.

Zum Beispiel:

HINWEIS:

Der erste Hop-Typ von Segmentlisten eines statischen Segment-Routing-LSP kann dazu führen, dass ein Commit fehlschlägt, wenn:

  • Verschiedene Segmentlisten eines Tunnels haben unterschiedliche Arten der ersten Hop-Auflösung. Dies gilt sowohl für gefärbte als auch für nicht farbige statische Segment-Routing-LSPs. Dies gilt jedoch nicht für PCEP-gestützte LSPs; wird eine Systemprotokollmeldung für die Mismatch im ersten Hop-Auflösungstyp zum Zeitpunkt der Berechnung des Pfads generiert.

    Zum Beispiel:

    Der Commit des Tunnels lsp1 schlägt fehl, da Path-1 im IP-Adressmodus und Path-2 im Label-Modus ist.

  • Die Bindungs-SID ist für den statischen nicht farbigen LSP aktiviert, dessen Segmentlistentyp SID-Label ist.

    Zum Beispiel:

    Die Konfiguration der SID-Bindung über Label-Segmentliste wird nur für farbige statische LSPs und nicht für farbfreie statische LSPs unterstützt.

Statische Segment-Routing LSP-Bereitstellung

Die Segmentbereitstellung erfolgt auf Routerbasis. Für ein bestimmtes Segment auf einem Router wird ein eindeutiges SID-Label (Unique Service Identifier) aus einem gewünschten Label-Pool zugewiesen, der aus dem dynamischen Label-Pool für ein SID-Label mit Adjacency oder aus dem Segment Routing Global Block (SRGB) für ein Sid- oder Node-SID-Präfix stammen kann. Das Adjacency-SID-Label kann dynamisch zugewiesen werden, was das Standardverhalten ist, oder aus einem lokalen statischen Label-Pool (SRLB) zugewiesen werden. Eine Route für das SID-Label wird dann in der Tabelle mpls.0 installiert.

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

Einschränkungen statischer Segment-Routing-LSP

  • Junos OS hat derzeit eine Einschränkung, dass der nächste Hop nicht so aufgebaut werden kann, dass mehr als die Label für die maximale Segment-Listentiefe übertragen werden können. Daher ist eine Segmentliste mit mehr als den maximalen SID-Labeln (mit Ausnahme des SID-Labels des ersten Hops, das zur Auflösung der Weiterleitung am nächsten Hop verwendet wird) für farbige oder nicht-farbige Segment-Routing-LSPs nicht geeignet. Außerdem kann die tatsächliche Anzahl für einen bestimmten Segment-Routing-LSP noch niedriger als die maximale Grenze sein, wenn sich ein MPLS-Service auf dem Segment-Routing-LSP oder der Segment-Routing-LSP auf einem Link- oder Node-Schutzpfad befindet. In allen Fällen darf die Gesamtzahl der Service-Label, SID-Label und Link- oder Node-Schutzetiketten die maximale Segmentlistentiefe nicht überschreiten. Sie können die maximale Begrenzung der Segmentlisten auf [edit protocols source-packet-routing] Hierarchieebene konfigurieren. Mehrere nicht farbige Segment-Routing-LSPs mit weniger oder gleich den maximalen SID-Labeln können zusammengefügt werden, um einen längeren Segment-Routing-LSP zu erstellen. Dies wird als Segment-Routing-LSP-Stitching bezeichnet. Dies kann mit bindungs-SID-Label erreicht werden.

  • Das Segment-Routing-LSP-Stitching wird tatsächlich auf Pfadebene durchgeführt. Wenn ein nicht farbiger Segment-Routing-LSP mehrere Pfade mit mehreren Segmentlisten hat, kann jeder Pfad unabhängig voneinander mit einem anderen nicht-farbigen Segment-Routing-LSP an einem Stitching-Punkt zusammengefügt werden. Ein nicht farbiger Segment-Routing-LSP, der dem Stitching gewidmet ist, kann die Installation des Eingangsrouten deaktivieren, indem es eine Anweisung auf [edit protocols source-packet-routing source-routing-path lsp-name] Hierarchieebene konfiguriertno-ingress.

  • Pro nicht farbigen statischen Segment-Routing-LSP werden maximal 128 primäre Pfade und 1 sekundärer Pfad unterstützt. Wenn eine Konfigurationsverletzung vorliegt, schlägt die Commit-Prüfung mit einem Fehler fehl.

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

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

Dynamische Erstellung von Segment-Routing-LSPs

In Segment-Routing-Netzwerken, in denen jedes Provider-Edge-Gerät (PE) mit jedem anderen PE-Gerät verbunden ist, ist für die Einrichtung der Segment-Routing-Label-Switched Paths (LSPs) eine große Anzahl an Konfigurationen erforderlich, obwohl nur wenige SR-TE-Pfade (Segment Routing Traffic Engineered) verwendet werden dürfen. Sie können BGP-trigerred dynamische Erstellung dieser LSPs aktivieren, um den Konfigurationsaufwand in solchen Bereitstellungen zu reduzieren.

Konfiguration dynamischer Segment-Routing-LSP-Vorlage

Um die Vorlage für die dynamische Erstellung von Segment-Routing-LSPs zu konfigurieren, müssen Sie die spring-te-Anweisung in der [edit routing-options dynamic-tunnels] Hierarchie einschließen.

  • Im Folgenden ist eine Beispielkonfiguration für farbdynamische Segment-Routing-LSP-Vorlage:

  • Im Folgenden wird eine Beispielkonfiguration für nicht farbliche dynamische Segment-Routing-LSP-Vorlage dargestellt:

Auflösung dynamischer Segment-Routing-LSPs
Auflösung farbiger dynamischer Segment-Routing-LSP

Wenn den BGP-Präfixen color community zugewiesen wird, werden sie zunächst über die Catch-all-route-for-that-color-Richtlinie aufgelöst, und wiederum wird die SR-TE-Vorlage identifiziert, in der das BGP-Präfix aufgelöst werden soll. Die Ziel-SID wird dann aus dem BGP-Payload-Prefix-Next-Hop-Attribut abgeleitet. Wenn beispielsweise der nächste Hop des BGP-Nutzpräfixes eine IP-Adresse ist, die zu Gerät A gehört, wird die Node-SID von Gerät A genommen, und ein entsprechendes Label wird vorbereitet und an den unteren Rand des Stacks verschoben. Das BGP-Nutzpräfix wird in einem nur farbbasierten Modus aufgelöst, wobei sich die Node-SID von Gerät A am unteren Rand des endgültigen Labelstacks befindet und die SR-TE-Pfadbezeichnungen oben sind.

Der endgültige LSP-Vorlagenname ist eine Kombination aus Präfix, Farbe und Tunnelname. zum Beispiel <prefix>:<color>:dt-srte-<tunnel-name>. Die Farbe im LSP-Namen wird im hexadezimalen Format angezeigt, und das Format des Tunnelnamens ähnelt dem von RSVP ausgelösten Tunnel-LSP-Namen.

Um ein farbiges Zielnetzwerk erfolgreich zu lösen, sollte die Farbe eine gültige Vorlagenzuordnung haben, entweder zu einer bestimmten Farbe oder über die color-any Vorlage. Ohne gültige Zuordnung wird der Tunnel nicht erstellt, und die zur Lösung angeforderte BGP-Route bleibt ungelöst.

Auflösung unfarbiger dynamischer Segment-Routing-LSPs

Die Catch-All-Routen für nicht farbige LSPs werden zur Routingtabelle inet.3 hinzugefügt. Das nicht farbige Tunnelziel muss in einer anderen spring-te Konfiguration mit nur einem Vorlagennamen in der Zuordnungsliste konfiguriert werden. Dieser Vorlagenname wird für alle Tunnelrouten verwendet, die mit jedem der Zielnetzwerke übereinstimmen, die unter derselben spring-te Konfiguration konfiguriert sind. Diese Tunnel ähneln den RSVP-Tunneln in ihrer Funktionalität.

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

Dynamische Segment-Routing-LSP-Beispielkonfiguration

Die dynamische Segment-Routing-LSP-Vorlage enthält immer einen teilweisen Pfad. Die SID des letzten Hop-Knotens wird automatisch zum Zeitpunkt der Tunnelerstellung abgeleitet, abhängig von der Protokoll-Next-Hop-Adresse (PNH)-Knoten-SID. 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. Dynamische Segment-Routing-LSP-Vorlagen sind nicht für einen einzigen Tunnel gemein, daher kann kein vollständiger Pfad darauf ausgeführt werden. Sie können eine Segmentliste verwenden, wenn ein vollständiger Pfad verwendet werden soll.

Farbige, dynamische Segment-Routing-LSPs

Beispielkonfiguration für farbige dynamische Segment-Routing-LSPs:

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

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

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

  3. BGP prefix to tunnel mapping:

    R1(prefix) -> 10. 22.44.55-101(PNH) LSP-Tunnelname = 10. 22.44.55:65:dt-srte-tunnel1

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

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

  4. inetcolor.0 tunnel route:

    10. 22.44.55-101/64 --> <next-hop>

    10. 22.44.55-124/64 --> <next-hop>

  5. inetcolor6.0 tunnel route:

    ffff::10. 22.44.55-101/160 --> <next-hop>

    ffff::10. 22.44.55-124/160 --> <next-hop>

Nicht-farbige dynamische Segment-Routing-LSPs

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

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

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

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

  3. BGP prefix to tunnel mapping:

    R1(prefix) -> 10.33.44.55(PNH) LSP-Vorlagenname = LSP1 --- 10.33.44.55:dt-srte-tunnel2

    R1(prefix) -> ffff::10.33.44.55(PNH) LSP-Vorlagenname = LSP1 --- 10.33.44.55:dt-srte-tunnel2

  4. inet.3 tunnel route: 10.33.44.55/32 --> <nächsten Hop>

  5. inet6.3 tunnel route: ffff::10.33.44.55/128 --> <next-hop>

Ungelöste dynamische Segment-Routing-LSP

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

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

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

  2. inetcolor6.0 tunnel route: ffff::10.33.44.0 - 0/120 --> RT_NH_TUNNEL ffff::10.1.0 - 0/24 --> RT_NH_TUNNEL

  3. BGP prefix to tunnel mapping: R1(prefix) -> 10.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 spring-te eine Vorlage mit einem Farbobjekt enthält, müssen Sie alle anderen Vorlagen auch mit Farbobjekten konfigurieren. Es wird angenommen, dass alle Ziele innerhalb dieser Konfiguration gefärbt sind.

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

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

  • Die Zuordnung von Farbe zu Vorlage erfolgt auf Eins-zu-Eins-Basis. Eine Farbe kann nicht mehreren Vorlagen zuordnen.

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

  • Farbige und nicht farbige Ziele können nicht in derselben spring-te Konfiguration koexistiert werden.

  • Sie können dieselben Zielnetzwerke nicht mit oder ohne Farbe unter verschiedenen spring-te Konfigurationsanweisungen konfigurieren.

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

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

Die folgenden Services werden über farbige dynamische Segment-Routing-LSPs unterstützt:

  • Layer 3-VPN

  • BGP EVPN

  • Richtlinien-Services exportieren

Die folgenden Services werden über nicht farbige dynamische Segment-Routing-LSPs unterstützt:

  • Layer 3-VPN

  • Layer 2-VPN

  • Multipath-Konfigurationen

Verhalten mit mehreren Tunnelquellen im Segment-Routing

Wenn zwei Quellen Routen vom Segment-Routing zum selben Ziel herunterladen (z. B. statische und dynamische Quelltunnel), wird die bevorzugte Segment-Routing-Option für die Auswahl des aktiven Routeneintrags verwendet. Ein höherer Wert hat eine größere Präferenz. Falls die Präferenz gleich bleibt, wird die Tunnelquelle verwendet, um den Routeneintrag zu bestimmen.

Einschränkungen für dynamisches Segment-Routing-LSPs

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

  • IPv6-Segment-Routing-Tunnel.

  • Statische Tunnel.

  • 6PE wird nicht unterstützt.

  • Verteilte CSPF.

  • sBFD- und LDP-Tunnelling wird 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) für die Auflösung von Transporttunneln über statisch farbige und BGP Segment Routing Traffic-Engineered (SR-TE)-LSPs angeben. Dies wird als Color-IP-Protokoll Next Hop-Auflösung bezeichnet, wo Sie eine Auflösungskarte konfigurieren und auf die VPN-Services anwenden müssen. Mit dieser Funktion können Sie eine farbbasierte Datenverkehrssteuerung von Layer-2- und Layer-3-VPN-Services ermöglichen.

Junos OS unterstützt farbige SR-TE-LSPs , die mit einer einzigen Farbe verknüpft sind. Die farbbasierte Zuordnung von VPN-Services wird auf statischen farbigen LSPs und BGP SR-TE-LSPs unterstützt.

VPN-Service-Coloring

Im Allgemeinen kann einem VPN-Dienst eine Farbe auf dem Ausgangsrouter zugewiesen werden, auf dem das VPN NLRI angekündigt wird, oder auf einem Eingangsrouter, bei dem das VPN NLRI empfangen und verarbeitet wird.

Sie können den VPN-Services auf verschiedenen Ebenen eine Farbe zuweisen:

  • Pro Routing-Instanz.

  • Pro BGP-Gruppe.

  • Pro BGP-Nachbarn.

  • Pro Präfix.

Sobald Sie eine Farbe zugewiesen haben, wird die Farbe an einen VPN-Service in Form einer BGP Color Extended Community angehängt.

Sie können einem VPN-Service, den sogenannten mehrfarbigen VPN-Services, mehrere Farben zuweisen. In solchen Fällen wird die letzte Farbe als Farbe des VPN-Dienstes betrachtet, und alle anderen Farben werden ignoriert.

Mehrere Farben werden von Eingangs- und/oder Eingangsgeräten über mehrere Richtlinien in der folgenden Reihenfolge zugewiesen:

  • BGP-Exportrichtlinie auf dem Ausgangsgerät.

  • BGP-Importrichtlinie auf dem Eingangsgerät.

  • VRF-Importrichtlinie auf dem Eingangsgerät.

Die beiden Modi des VPN-Service-Coloring sind:

Ausgangsfarbzuweisung

In diesem Modus ist das Ausgangsgerät (d. h. der Werbetreibende des VPN NLRI) für die Farbgebung des VPN-Dienstes verantwortlich. Um diesen Modus zu aktivieren, können Sie eine Routing-Richtlinie definieren und sie in der Routing-Instanz vrf-export, dem Gruppenexport oder dem [edit protocols bgp] Gruppennachbar-Export des VPN-Service auf Hierarchieebene anwenden. Das VPN NLRI wird von BGP mit der angegebenen Farb-erweiterten Community beworben.

Zum Beispiel:

Oder

HINWEIS:

Wenn Sie die Routingrichtlinie als Exportrichtlinie einer BGP-Gruppe oder eines BGP-Nachbarn anwenden, müssen Sie die vpn-apply-export Anweisung auf BGP-, BGP-Gruppen- oder BGP-Nachbarschaftsebene einschließen, damit die Richtlinie auf die VPN-NLRI wirkt.

Die Routing-Richtlinien werden auf Layer-3-VPN-Präfix-NLRIs, Layer-2-VPN-NRLIs und EVPN-NLRIs angewendet. Die Color Extended Community wird von allen VPN-Routen geerbt, importiert und in den Ziel-VRFs auf einem oder mehreren Eingangsgeräten installiert.

Eingangsfarbzuweisung

In diesem Modus ist das Eingangsgerät (d. h. der Empfänger des VPN NLRI) für das Coloring des VPN-Dienstes verantwortlich. Um diesen Modus zu aktivieren, können Sie eine Routing-Richtlinie definieren und sie auf die Routing-Instanz vrf-import, den Gruppenimport oder den [edit protocols bgp] Gruppennachbarnimport des VPN-Dienstes auf Hierarchieebene anwenden. Alle VPN-Routen, die der Routing-Richtlinie entsprechen, werden mit der angegebenen farblichen erweiterten Community verbunden.

Zum Beispiel:

Oder

Festlegen des VPN-Servicezuordnungsmodus

Um flexible VPN-Dienstzuordnungsmodi anzugeben, müssen Sie mithilfe der resolution-map Anweisung eine Richtlinie definieren und die Richtlinie in der Routing-Instanz vrf-import, dem Gruppenimport oder dem [edit protocols bgp] Gruppennachbarimport eines VPN-Service auf Hierarchieebene verweisen. Alle VPN-Routen, die der Routing-Richtlinie entsprechen, sind mit der angegebenen Auflösungskarte verbunden.

Zum Beispiel:

Sie können eine Importrichtlinie auf die Routing-Instanz des VPN-Service anwenden.

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

HINWEIS:

Jeder VPN-Servicezuordnungsmodus sollte einen eindeutigen Namen haben, der in der Auflösungskarte definiert ist. In der Auflösungskarte wird nur ein einzelner Eintrag von IP-Color unterstützt, wobei die VPN-Route(n) mit einem farbigen IP-Protokoll in Form von ip-address:color.

Color-IP Protocol Next Hop-Auflösung

Der Protokoll-Next-Hop-Auflösungsprozess wurde erweitert, um die Auflösung des Colored-IP-Protokolls next Hop zu unterstützen. Für einen farbigen VPN-Service nimmt der Prozess zur Auflösung des Protokolls next Hop eine Farbe und eine Auflösungszuordnung an, erstellt ein farbiges IP-Protokoll in Form von IP-address:colorund löst das Protokoll als nächsten Hop in der Routingtabelle inet6color.0 auf.

Sie müssen eine Richtlinie konfigurieren, um die Multipath-Auflösung von farbigen Layer-2-VPN-, Layer-3-VPN- oder EVPN-Services über farbige LSPs zu unterstützen. Die Richtlinie muss dann mit der entsprechenden RIB-Tabelle als Importrichtlinie für den Resolver angewendet werden.

Zum Beispiel:

Fallback zum IP-Protokoll Next Hop-Lösung

Wenn für einen farbigen VPN-Service keine Auflösungszuordnung angewendet wird, ignoriert der VPN-Dienst seine Farbe und fällt auf die IP-Protokoll-Next-Hop-Auflösung zurück. Umgekehrt, wenn für einen nicht farbigen VPN-Service eine Auflösungskarte angewendet wird, wird die Auflösungskarte ignoriert, und der VPN-Service verwendet das IP-Protokoll next Hop-Auflösung.

Das Fallback ist ein einfacher Prozess von farbigen SR-TE-LSPs zu LDP-LSPs, indem eine RIB-Gruppe für LDP verwendet wird, um Routen in inet{6}color.0-Routing-Tabellen zu installieren. Eine längste Prefix-Übereinstimmung für einen colored-IP-Protokoll next Hop stellt sicher, dass eine LDP-Route mit einer übereinstimmenden IP-Adresse zurückgegeben werden sollte, wenn keine farbige SR-TE LSP-Route vorhanden ist.

BGP-gekennzeichnete Unicast-farbbasierte Zuordnung über SR-TE

Ab Junos OS Version 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 auflösen. BGP-LU unterstützt die Zuordnung einer BGP-Community-Farbe und die Definition eines resolution map für SR-TE. Ein farbiges Protokoll des nächsten Hops wird erstellt und in einem farbigen SR-TE-Tunnel in der inetcolor.0 Tabelle inet6color.0 aufgelöst. BGP-Verwendungen inet.3 und inet6.3 -Tabellen für nicht farbbasierte Zuordnung. Auf diese Weise können Sie BGP-LU-IPv6- und IPv4-Präfixe mit einer IPv6-Next-Hop-Adresse in Nur-IPv6-Netzwerken bekannt geben, in denen Router keine IPv4-Adressen konfiguriert haben. Mit dieser Funktion unterstützen wir derzeit BGP IPv6 LU über SR-TE mit IS-IS-Underlay.

In Abbildung 9konfiguriert der Controller 4 farbige Tunnel in einem IPv6-Core-Netzwerk, das mit SR-TE konfiguriert ist. Jeder farbige Tunnel nimmt je nach definierter Auflösungskarte einen anderen Pfad zum Zielrouter D. Der Controller konfiguriert einen farbigen SR-TE-Tunnel zu 2001:db8::3701:2d05-Schnittstelle in Router D . BGP importiert Richtlinien, um dem empfangenen Präfix 2001:db8::3700:6/128 eine Farb- und Auflösungszuordnung zuzuweisen. Basierend auf der zugewiesenen Community-Farbe löst BGP-LU den farbigen nächsten Hop für BGP IPv6 LU-Präfix gemäß der zugewiesenen Auflösungszuordnungsrichtlinie auf.

Abbildung 9: BGP IPv6 LU über farbiges IPv6 SR-TE BGP IPv6 LU über farbiges IPv6 SR-TE

BGP-LU unterstützt die folgenden Szenarien:

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

  • BGP IPv4 LU über statisch gefärbtes und nicht farbiges IPv4 SR-TE mit ISIS/OSPF IPv4 SR-Erweiterungen.

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

  • BGP IPv6 LU über statisch gefärbtes und nicht farbiges IPv6 SR-TE mit ISIS IPv6 SR-Erweiterungen.

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

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

  • IPv6 Layer 3 VPN-Services über statisch gefärbtes und nicht farbiges IPv6 SR-TE mit ISIS IPv6-SR-Erweiterungen.

Unterstützte und nicht unterstützte Funktionen für farbbasierte Zuordnung von VPN-Services

Die folgenden Funktionen und Funktionen werden von einer farbbasierten Zuordnung von VPN-Services unterstützt:

  • BGP Layer 2 VPN (Kompella Layer 2 VPN)

  • BGP EVPN

  • Auflösungskarte mit einer einzigen IP-Farboption.

  • Farbiges IPv4- und IPv6-Protokoll next Hop-Auflösung.

  • Routing Information Base (auch Routing-Tabelle genannt) gruppenbasiertes Fallback auf LDP-LSP in der Routing-Tabelle inetcolor.0.

  • Farbiger SR-TE LSP.

  • Virtuelle Plattformen.

  • 64-Bit-Junos OS.

  • Logische Systeme.

  • BGP als Unicast gekennzeichnet.

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

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

  • Layer-2-Circuit

  • FEC-129 BGP automatisch entdeckt und LDP-signalisiert Layer-2-VPN.

  • VPLS

  • MVPN

  • IPv4 und IPv6 mit Resolution-Map.

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

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

Wenn ein PCE-initiierter Segment-Routing-LSP erstellt wird, wird der LSP mit Richtlinienanweisungen überprüft (falls vorhanden), und wenn eine Übereinstimmung vorliegt, 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; zum Beispiel Kennzahl.

So konfigurieren Sie eine Vorlage:

  1. Fügen Sie die Source-Routing-Path-Template-Anweisung auf Hierarchieebene [edit protocols source-packet-routing] ein. Die zusätzlichen BFD- und LDP-Tunneling-Parameter können Sie hier konfigurieren.

  2. Fügen Sie die Source-routing-path-template-map-Anweisung auf der [edit protocols source-packet-routing] Hierarchieebene ein, um die Richtlinienanweisungen auflisten zu können, mit denen der PCE-initiierte LSP überprüft werden soll.

  3. Definieren Sie eine Richtlinie zur Liste der LSPs, auf die die Vorlage angewendet werden soll.

    Die from Anweisung kann entweder den LSP-Namen oder den regulären LSP-Ausdruck mit den Bedingungen und lsp-regex übereinstimmungen lsp enthalten. Diese Optionen schließen sich gegenseitig aus, sodass Sie zu einem bestimmten Zeitpunkt nur eine Option angeben können.

    Die then Anweisung muss die sr-te-template Option mit einer Annahmeaktion enthalten. Dadurch wird die Vorlage auf den PCE-initiierten LSP angewendet.

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

  • Die Vorlagenkonfiguration ist nicht auf statisch konfigurierte Segment-Routing-LSPs oder die Segment-Routing-LSP eines anderen Clients anwendbar.

  • PCEP-bereitgestellte Konfiguration hat Vorrang vor Vorlagenkonfiguration.

  • PCEP-LSP erbt keine Vorlagensegmentlistenkonfiguration.

Beispiel: Konfigurieren von statischem Segment-Routing Label Switched Path

Dieses Beispiel zeigt, wie Sie statisches Segment-Routing-Label Switched Paths (LSPs) in MPLS-Netzwerken konfigurieren. Diese Konfiguration trägt zu einer höheren Skalierbarkeit für MPLS-Netzwerke bei.

Anforderungen

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

  • Sieben universelle 5G-Routing-Plattformen der MX-Serie

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

Stellen Sie sicher, dass Sie die Geräteschnittstellen konfigurieren, bevor Sie beginnen.

Überblick

Junos OS wird eine Reihe expliziter Segment-Routing-Pfade auf dem Eingangsrouter eines nicht farbigen statischen Segment-Routing-Tunnels konfiguriert, indem die segment-list Anweisung auf [edit protocols source-packet-routing] Hierarchieebene konfiguriert wird. Sie können den Segment-Routing-Tunnel konfigurieren, indem Sie die source-routing-path Anweisung auf [edit protocols source-packet-routing] Hierarchieebene konfigurieren. Der Segment-Routing-Tunnel hat eine Zieladresse und einen oder mehrere primäre Pfade und optional sekundäre Pfade, die auf die Segmentliste verweisen. Jede Segmentliste besteht aus einer Abfolge von Hops. Bei nicht farbigen statischen Segment-Routing-Tunneln gibt der erste Hop der Segmentliste eine unmittelbare IP-Adresse des nächsten Hops an, und der zweite mit Nth Hop gibt die SID-Label (Segment identifiziert) an, die dem Link oder Knoten entsprechen, den der Pfad durchläuft. Die Route zum Ziel des Segment-Routing-Tunnels ist in der Tabelle inet.3 installiert.

Topologie

In diesem Beispiel konfigurieren Sie Layer-3-VPN auf den Provider-Edge-Routern PE1 und PE5. Konfigurieren Sie das MPLS-Protokoll auf allen Routern. Der Segment-Routing-Tunnel wird vom Router PE1 zum Router PE5 mit einem primären Pfad auf Router PE1 und Router PE5 konfiguriert. Router PE1 ist zum Schutz des Pfads auch mit sekundären Pfaden konfiguriert. Die Transit-Router PE2 zu PE4 sind mit Adjacency-SID-Labeln mit Label Pop und einer ausgehenden Schnittstelle konfiguriert.

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

Konfiguration

CLI-Schnellkonfiguration

Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen sie in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, kopieren Sie die Befehle, fügen Sie sie auf Hierarchieebene in die [edit] CLI ein, und geben Sie dann aus dem Konfigurationsmodus ein commit .

PE1

PE2

PE3

PE4

PE5

CE1

CE2

Konfiguration von Geräte-PE1
Schritt-für-Schritt-Verfahren

Im folgenden Beispiel müssen Sie auf verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in 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 die 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 der Peergruppe, die lokale Adresse, die Protokollfamilie für NLRIs in Updates und die IP-Adresse eines Nachbarn für die Peergruppe.

  5. Konfigurieren Sie die Protokollbereichsschnittstellen.

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

  7. Konfigurieren Sie die IPv4-Zieladresse, binden Sie das SID-Label sowie den primären und sekundären Quell-Routingpfad für Protokoll SPRING.

  8. Konfigurieren Sie Richtlinienoptionen.

  9. Konfigurieren Sie BGP-Community-Informationen.

  10. Konfigurieren Sie die Routing-Instanz VRF1 mit Instanztyp, Schnittstelle, Router-Distinguisher, VRF-Import, Export und Tabellenetikett. Konfigurieren Sie die Exportrichtlinie und die Schnittstelle des Bereichs für Protokoll-OSPF.

Ergebnisse

Bestätigen Sie Ihre Konfiguration im Konfigurationsmodus, indem Sie die show interfacesBefehle , show policy-options, , show protocolsshow routing-optionsund show routing-instances eingeben. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Konfiguration von Geräte-PE2
Schritt-für-Schritt-Verfahren

Im folgenden Beispiel müssen Sie auf verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in 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 Protokoll-MPLS.

  3. Konfigurieren Sie Schnittstellen und statischen Label-Bereich für Protokoll-MPLS.

  4. Konfigurieren Sie Schnittstellen für Protokoll-OSPF.

Ergebnisse

Bestätigen Sie ihre Konfiguration im Konfigurationsmodus auf Router PE2, indem Sie die show interfaces befehle und show protocols eingeben. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Überprüfung

Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.

Überprüfen der Routeneingabe der Routing-Tabelle inet.3 des Routers PE1
Zweck

Überprüfen Sie den Routeneintrag der Routing-Tabelle inet.3 des Routers PE1.

Aktion

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

Bedeutung

Die Ausgabe zeigt die Eingangsrouten von Segment-Routing-Tunneln an.

Überprüfen von Routing-Tabelleneinträgen der Routing-Tabelle mpls.0 des Routers PE1
Zweck

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

Aktion

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

Bedeutung

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

Überprüfung des SPRING Traffic Engineered LSP of Router PE1
Zweck

Überprüfen Sie spring-Datenverkehrs-LSPs auf den Eingangsroutern.

Aktion

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

Bedeutung

Die Ausgabe zeigt die Übersicht über spring Traffic Engineered LSPs auf dem Eingangsrouter an.

Überprüfung des SPRING Traffic Engineered LSPs auf dem Eingangsrouter des Routers PE1
Zweck

Überprüfen Sie spring-Datenverkehrs-LSPs auf dem Eingangsrouter.

Aktion

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

Bedeutung

Die Ausgabe zeigt Details zu SPRING-Traffic-entwickelten LSPs auf dem Eingangsrouter an

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

Überprüfen Sie die Routing-Tabelleneinträge der Routing-Tabelle mpls.0 des Routers PE2.

Aktion

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

Überprüfen des Status statischer MPLS-LSP-Segmente des Routers PE2
Zweck

Überprüfen Sie den Status der MPLS-LSP-Segmente des Routers PE2.

Aktion

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

Bedeutung

Die Ausgabe zeigt den Status der statischen MPLS-LSP-Segmente des Routers PE2 an.

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

Vor Junos OS Version 19.2R1S1 konnten Sie für das Traffic-Engineering von Segment-Routing-Pfaden entweder explizit statische Pfade konfigurieren oder berechnete Pfade von einem externen Controller verwenden. Mit der Distributed Constrained Shortest Path First (CSPF)-Funktion für Segment-Routing-LSP können Sie einen Segment-Routing-LSP lokal auf dem Eingangsgerät gemäß den von Ihnen konfigurierten Einschränkungen berechnen. Mit dieser Funktion werden die LSPs basierend auf den konfigurierten Einschränkungen und dem Metriktyp (Traffic-Engineering oder IGP) optimiert. Die LSPs werden so berechnet, dass sie die verfügbaren ECMP-Pfade zum Ziel nutzen, wobei die Segment-Routing-Label-Stack-Kompression aktiviert oder deaktiviert ist.

Einschränkungen der verteilten CSPF-Berechnung

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

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

  • Integration und Ausschluss administrativer Gruppen.

  • Integration von losen oder strengen Hop-IP-Adressen.

    HINWEIS:

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

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

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

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

  • IPV6-Adressen.

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

  • Schnittstellen ohne Nummer.

  • Mehrere Routing-Protokolle wie OSPF, ISIS und BGP-LS gleichzeitig aktiviert.

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

  • Ein- 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-Kompressionsalgorithmus mit CSPF.

Label Stack-Kompression aktiviert

Ein komprimierter Label-Stack stellt eine Reihe von Pfaden von einer Quelle zu einem Ziel dar. Sie besteht im Allgemeinen aus Node-SIDs und Adjacency-SIDs. Wenn die Komprimierung des Labelstacks aktiviert ist, wird das Ergebnis der Berechnung eine Reihe von Pfaden, die den ECMP zum Ziel maximieren, mit einer minimalen Anzahl von SIDs im Stack, während sie den Einschränkungen entsprechen.

Label Stack-Kompression deaktiviert

Die CsPF-Multipath-Berechnung mit deaktivierter Label-Stack-Kompression findet bis zu N Segmentlisten zum Ziel, wobei:

  • Die Kosten für alle Segmentlisten sind gleich und die gleichen wie die kürzeste Traffic-Engineering-Metrik, um das Ziel zu erreichen.

  • Jede Segmentliste besteht aus Adjacency-SIDs.

  • Der Wert von N ist die maximale Anzahl von Segmentlisten, die für den Kandidatenpfad nach Konfiguration zulässig sind.

  • Keine zwei Segmentlisten sind identisch.

  • Jede Segmentliste erfüllt alle konfigurierten Einschränkungen.

Verteilte CSPF-Berechnungsdatenbank

Die für die SR-TE-Berechnung verwendete Datenbank enthält alle Verbindungen, Knoten, Präfixe und deren Merkmale, unabhängig davon, ob Traffic-Engineering in diesen Werbeknoten aktiviert ist. Mit anderen Worten, es ist die Vereinigung der Traffic-Engineering-Datenbank (TED) und der IGP-Link-Zustandsdatenbank aller Domänen, von denen der Computerknoten gelernt hat. Daher müssen Sie die Anweisung auf [edit protocols isis traffic-engineering] Hierarchieebene einschließenigp-topology, damit CSPF funktioniert.

Konfigurieren verteilter CSPF-Berechnungsbeschränkungen

Sie können ein Rechenprofil verwenden, um die Berechnungsbeschränkungen logisch zu gruppieren. Diese Rechenprofile werden durch die Segment-Routing-Pfade für die Berechnung der primären und sekundären Segment-Routing-LSPs referenziert.

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

Die Konfiguration für die unterstützten Recheneinschrä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 SR-TE-Schnittstellen (Segment Routing Traffic-Engineering) an.

    Um die Berechnungsbeschränkungen zu konfigurieren, können Sie drei Kategorien für eine Reihe von administrativen Gruppen angeben. Die Konfiguration der Berechnungsbeschränkungen kann allen Routing-Pfaden für Kandidatensegmente gemeinsam sein oder unter einzelnen Kandidatenpfaden.

    • include-any– Gibt an, dass alle Verbindungen mit mindestens einer der konfigurierten administrativen Gruppen in der Liste für den pfad akzeptabel sind, der durchquert werden soll.

    • include-all– Gibt an, dass jede Verbindung mit allen konfigurierten administrativen Gruppen in der Liste für den zu durchlaufenden Pfad akzeptabel ist.

    • exclude– Gibt an, dass verbindungen, die nicht über eine der konfigurierten administrativen Gruppen in der Liste verfügen, für den Pfad, der durchquert werden soll, akzeptabel sind.

  • Explicit path

    Sie können eine Reihe von Router-IDs im Datenverarbeitungsprofil als Einschränkung für die Berechnung der SR-TE-Kandidatenpfade angeben. Jeder Hop muss eine IPv4-Adresse sein und kann vom Typ streng oder lose sein. Wenn der Hoptyp nicht konfiguriert ist, wird strict verwendet. Sie müssen die compute Option unter der Segmentliste-Anweisung einschließen, wenn Sie die Explizite Pfadeinschränkung angeben.

  • Maximum number of segment lists (ECMP paths)

    Sie können einen Kandidatenpfad mit einer Reihe von dynamischen Segment-Listen zuordnen. Bei den Pfaden handelt es sich um ECMP-Pfade, bei denen jede Segmentliste in ein Next-Hop-Gateway mit aktiver Gewichtung übersetzt wird. Diese Pfade sind das Ergebnis von Pfadberechnungen mit oder ohne Kompression.

    Sie können dieses Attribut mit der maximum-computed-segment-lists maximum-computed-segment-lists Option unter der Konfigurationsaussage für rechenprofile 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 Parameter für die maximale Segmentlistentiefe stellt sicher, dass unter den ECMP-Pfaden, die alle anderen Einschränkungen erfüllen, wie z. B. administrative Gruppen, nur Pfade verwendet werden, deren Segmentlisten kleiner oder gleich der maximalen Segmentlistentiefe sind. Wenn Sie diesen Parameter als Einschränkung unter dem Rechenprofil konfigurieren, überschreibt er die maximum-segment-list-depth Konfiguration auf [edit protocols source-packet-routing] Der Hierarchieebene, sofern vorhanden.

    Sie können dieses Attribut mit der maximum-segment-list-depth maximum-segment-list-depth Option unter der Konfigurationsaussage für rechenprofile konfigurieren.

  • Protected or unprotected adjacency SIDs

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

  • Metric type

    Sie können den Typ der Metrik für den Link angeben, der für die Berechnung verwendet werden soll. Standardmäßig verwenden SR-TE-LSPs Traffic-Engineering-Metriken der Links für die Berechnung. Die Traffic-Engineering-Metrik für Links wird durch Traffic-Engineering-Erweiterungen von IGP-Protokollen angekündigt. Sie können jedoch auch die IGP-Metrik für die Berechnung verwenden, indem Sie die Metriktypkonfiguration im Rechenprofil verwenden.

    Sie können dieses Attribut mit der metric-type (igp | te) Option unter der Konfigurationsaussage für rechenprofile konfigurieren.

Verteilte CSPF-Berechnung

Die SR-TE-Kandidatenpfade werden lokal berechnet, sodass sie die konfigurierten Einschränkungen erfüllen. Wenn die LabelStack-Kompression deaktiviert ist, ergibt sich bei der CSPF-Berechnung für mehrere Pfade eine Reihe von SID-Stacks mit Adjacency. Wenn die Label-Stack-Kompression aktiviert ist, ergibt sich ein Satz komprimierter Label-Stacks (bestehend aus angrenzenden SIDs und Node-SIDs).

Wenn sekundäre Pfade berechnet werden, werden die Von den primären Pfaden genommenen Verbindungen, Knoten und DIE BACKBONEGs zur Berechnung nicht vermieden. Weitere Informationen zu primären und sekundären Pfaden finden Sie unter Konfigurieren von primären und sekundären LSPs.

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

Interaktion zwischen verteilter CSPF-Berechnung und SR-TE-Funktionen

Gewichtung im Zusammenhang mit Pfaden einer SR-TE-Richtlinie

Sie können Gewichtungen für berechnete und statische SR-TE-Pfade konfigurieren, die zu den nächsten Hops der Route beitragen. Ein einzelner Pfad, der die Berechnung aktiviert hat, kann jedoch zu mehreren Segmentlisten führen. Diese berechneten Segmentlisten werden unter sich als ECMP behandelt. Sie können diesen Segmenten hierarchische ECMP-Gewichtungen zuweisen, unter Berücksichtigung der Gewichtungen, die jedem der konfigurierten Vorwahlen zugewiesen sind.

BFD Liveliness Detection

Sie können die BFD-Liveliness-Erkennung 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, infolgedessen die für die Segmentlisten konfigurierten BFD-Parameter auf alle berechneten Segmentlisten angewendet werden. Wenn alle aktiven primären Pfade nach unten gehen, wird der vorprogrammierte sekundäre Pfad (falls angegeben) aktiv.

Inherit-Label-Nexthops

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

Automatische Übersetzungsfunktion

Sie können die Funktion zur automatischen Übersetzung in den Segmentlisten und die primären oder sekundären Pfade mit der automatischen Übersetzungsfunktion konfigurieren, die auf diese Segmentlisten verweist. Auf der anderen Seite kann die primäre oder sekundäre, auf der die Rechenfunktion aktiviert ist, keine Segmentliste referenziert werden. Aus diesem Grund können Sie die Rechenfunktion und die automatische Übersetzungsfunktion für einen bestimmten primären oder sekundären Pfad nicht aktivieren. Sie können jedoch einen LSP mit einem primären Pfad mit Rechentyp und einem anderen mit automatischem Übersetzungstyp konfigurieren lassen.

Verteilte CSPF-Berechnungs-Beispielkonfigurationen

Beispiel 1

In Beispiel 1

  • Der nicht berechnete primäre Pfad verweist auf eine konfigurierte Segmentliste. In diesem Beispiel wird auf die konfigurierte Segmentliste static_sl1 verwiesen, und sie dient auch als Name für diesen primären Pfad.

  • Ein berechneter Primärname sollte einen Namen konfiguriert haben, und dieser Name sollte keine konfigurierte Segmentliste referenziert. In diesem Beispiel compute_segment1 ist keine konfigurierte Segmentliste.

  • Das compute_profile_red Rechenprofil wird mit dem Namen compute_segment1auf den primären Pfad angewendet.

  • Das compute_profile_red Rechenprofil enthält eine Segmentliste des Typs compute, die verwendet wird, um die explizite Pfadeinschränkung für die Berechnung anzugeben.

Die Gewichtungen für den berechneten Pfad next-Hops und statische Next-Hops sind 2 bzw. 3. Vorausgesetzt, die nächsten Hops für berechnete Pfade sind comp_nh1, comp_nh2und , und comp_nh3der nächste Hop für statischen Pfad ist static_nh, werden die Gewichtungen wie folgt angewendet:

Next-Hop

Gewicht

comp_nh1

2

comp_nh2

2

comp_nh3

2

static_nh

9

Beispiel 2

In Beispiel 2 können sowohl die primären als auch die sekundären Pfade vom Rechentyp sein und ihre eigenen Rechenprofile haben.

Beispiel 3

Wenn in Beispiel 3 unter einem primären oder sekundären Pfad die Berechnung erwähnt wird, führt dies zur lokalen Berechnung eines Pfads zum Ziel, ohne Einschränkungen oder andere Parameter für die Berechnung.

Beispiel: Konfigurieren von CoS-basierter Weiterleitung und richtlinienbasiertem Routing für SR-TE LSPs

SUMMARY CoS-basierte Weiterleitung (CBF) und richtlinienbasiertes Routing (PBR, auch bekannt als filterbasierte Weiterleitung) können für nicht farbige Segment Routing-Traffic-Engineered (SR-TE)-LSPs aktiviert werden, um selektiven Datenverkehr über einen expliziten SR-TE-Pfad zu steuern. Dies bietet Ihnen den Vorteil der Datenverkehrswartung auf Grundlage von Class-of-Service oder einer Richtlinie.

CoS-basierte Weiterleitung und richtlinienbasiertes Routing für SR-TE-LSPs – Übersicht

Vorteile von CoS-based Forwarding (CBF) und richtlinienbasiertem Routing (PBR) für SR-TE LSPs

Mit CBF und PBR können Sie:

  • Nutzen Sie Kombinationen aus SR-TE-Pfaden (Segment Routing-Traffic Engineering), um den Serviceverkehr im Core zu steuern.

  • Wählen Sie die unterstützenden Services aus, die über die ausgewählten SR-TE-Pfade aufgelöst werden sollen.

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 Quell-Routing-Pfade, die den gesamten Labelstack statisch konfiguriert haben.

  • PCEP— Dynamische Bereitstellung von Quell-Routing-Pfaden, die auf einem Controller erstellt und in einem ERO entweder über PCEP-Segment-Routing-Erweiterungen oder in einer BGP-Segment-Routing-Richtlinie über BGP-Segment-Routing-Erweiterungen heruntergeladen werden.

  • Dynamic LSPs— Dynamisch erstellte Tunnel, die durch das dynamische Tunnelmodul ausgelöst werden und eine Last-Hop-ERO-Auflösung haben.

  • Auto-translated paths— Statisch konfigurierte Quell-Routing-Pfade, die automatisch übersetzt werden.

Überlegungen zur Konfiguration von CBF und PBR für SR-TE-LSPs

Merken:

  • CBF und PBR sind nur bei nicht farbigen SR-TE-LSPs aktiviert, die statisch oder dynamisch konfiguriert sind.

  • CbF- und PBR-Konfigurationen für SR-TE-LSPs können auf einem Gerät koexistieren. die Reihenfolge der Konfiguration bestimmt den Typ, in dem die Routen weitergeleitet werden.

  • Wenn es sich bei dem ersten Hop des SR-TE-LSP um eine Bezeichnung für PBR handelt, müssen Sie die resolution preserve-nexthop-hiearchy Anweisung auf [edit routing-options] Hierarchieebene einschließen.

  • Die klassenbasierte Weiterleitung von Routen für CBF ist nur in der Weiterleitungstabelle und nicht auf den Routen sichtbar.

  • Die richtlinienbasierte Weiterleitung von Routen für PBR erfolgt auf den Routen und wird in der show route Befehlsausgabe gesehen.

Konfigurieren sie CoS-basierte Weiterleitung und richtlinienbasiertes Routing für SR-TE LSPs

SUMMARY CoS-basierte Weiterleitung (CBF) und richtlinienbasiertes Routing (PBR, auch bekannt als filterbasierte Weiterleitungs-FBF) können verwendet werden, um den selektiven Datenverkehr mithilfe eines expliziten Segment Routing-Traffic-Engineered Path (SR-TE) Label-Swtiched Path (LSP) zu steuern. Nur nicht farbige Segment-Routing-LSPs, bei denen der nächste Hop als Erstes Hop-Label oder IP-Adresse konfiguriert ist, unterstützen CBF und PBR.

Bevor Sie beginnen

  • Sie müssen Junos OS Version 20.1 und höher ausführen, um CBF und PBR für nicht farbige SR-TE-LSPs zu aktivieren.

  • Konfigurieren Sie die Geräteschnittstellen und stellen Sie sicher, dass die Geräte mit dem Netzwerk verbunden sind.

  • Definieren Sie Segmentlisten und konfigurieren Sie SR-TE-LSPs und die zugehörigen Parameter.

Gehen Sie folgendermaßen vor, um einen SR-TE-LSP zu konfigurieren:

  1. Definieren Sie die Segmentliste mit Label-Parametern.

    Zum Beispiel:

  2. Konfigurieren Sie den Quell-Routing-Pfad für die SR-TE-LSPs und geben Sie den Voreinstellungswert und das primäre Segment für den Pfad an.

    Zum Beispiel:

Sie können nun CBF und PBR für die konfigurierten SR-TE-LSPs konfigurieren.

Um CBF zu konfigurieren, gehen Sie wie folgt vor:

  1. Definieren Sie DSCP-Klassifizierer (Differenzierte Services Code Point) zur Verarbeitung eingehender IPv4-Pakete, Weiterleitungsklassen und Optionswerte.

    Zum Beispiel:

  2. Definieren Sie Forwarding Classes (FCs) für die Gruppierung von Paketen für die Übertragung und weisen Sie Pakete den Ausgabewarteschlangen zu.

    Zum Beispiel:

  3. Weisen Sie den Geräteschnittstellen die konfigurierten Klassifizierer zu.

    Zum Beispiel:

  4. Definieren Sie CoS-basierte Weiterleitungsrichtlinienoptionen mit LSP next-Hop als SR-TE LSP.

    Zum Beispiel:

  5. Verwerfen Sie Datenverkehr, der keine Weiterleitungsklasse in der Next-Hop-Karte erfüllt.

    Zum Beispiel:

  6. Konfigurieren Sie eine Richtlinienaussage, die angibt, dass Routen, die dem Routenfilter entsprechen, der CoS-Next-Hop-Zuordnung unterliegen, die durch Map-Name angegeben wird.

    Zum Beispiel:

  7. Wenden Sie die Richtlinie auf Routen an, die aus der Routingtabelle in die Weiterleitungstabelle exportiert werden. Dies ermöglicht CBF für SR-TE-LSPs.

    Zum Beispiel:

  8. Commit der Konfiguration.

Verify CBF Configuration

Sie können die CBF-Konfiguration mit dem show route forwarding-table destination ip-address vpn vpn-name extensive Befehl überprüfen.

Bei CBF ist die klassenbasierte Weiterleitung von Routen nur in der Weiterleitungstabelle sichtbar, im Gegensatz zu PBR, wo die gefilterten Routen in der show route Befehlsausgabe angezeigt werden.

Um PBR zu konfigurieren, gehen Sie wie folgt vor:

  1. Konfigurieren Sie eine Richtlinienanweisung, die angibt, dass Routen, die dem Protokoll und dem Routenfilter entsprechen, dem LSP next-Hop unterliegen oder als Lastausgleich als Equal-Cost-Multipath (ECMP) in der Weiterleitungstabelle ausgeführt werden.

    Zum Beispiel:

  2. Konfigurieren Sie das Gerät so, dass es eine benutzerdefinierte Routenauflösung auf dem Protokoll des nächsten Hops von Routen ausführt.

    HINWEIS:

    Die resolution preserve-nexthop-hierarchy Anweisung ist für PBR obligatorisch, wenn der erste Hop des SR-TE-LSP ein Label ist.

  3. Wenden Sie die Richtlinie auf Routen an, die aus der Routingtabelle in die Weiterleitungstabelle exportiert werden. Dies ermöglicht PBR für SR-TE-LSPs.

    Zum Beispiel:

  4. Commit der Konfiguration.

Verify PBR Configuration

Sie können die PBR-Konfiguration mit dem show route destination-prefix Befehl überprüfen.

Die Ausgabe zeigt alle Next-Hops für das Zielpräfix 4.0.0.1 an. Die expanded-nh extensive Optionen zeigen die gefilterten Next-Hops unter dem Krt_inh Ausgabefeld an.

Für PBR führt die show route Befehlsausgabe die richtlinienbasierte Filterung von Routen durch.

Aktivieren mehrerer Pfade für SR-TE-LSPs in PCEP

Sie können mehrere Pfade (primär oder sekundär) für PCEP SR-TE-LSPs (statisch konfiguriert, delegiert und PCE-initiiert) konfigurieren, wie in draft-ietf-pce-multipath-06 definiert. Nur eine sekundäre Pfadkonfiguration wird unterstützt und nur für statisch konfigurierte SR-TE-LSPs. Die in Draft-ietf-pce-multipath-06 definierten PCEP-Erweiterungen ermöglichen es PCEP, mehrere Pfade (Multipath) für die LSPs zwischen PCEP-Endpunkten zu verbreiten.

Vorteile mehrerer Pfade für PCEP SR-TE LSPs

  • LSPs können mehrere EROs zu einem Ziel haben

  • Bietet Load Balancing-Funktionen durch Konfiguration der Gewichtung für einzelne EROs

  • Passt sich mit dem Entwurf für die SR-TE-Architektur zur Definition von Kandidatenpfaden ab

Die folgenden PCEP-Funktionen für mehrere Pfade werden unterstützt:

  • Wenn PCEP für mehrere Pfade aktiviert ist (Standard), können Sie mehrere primäre (oder einen sekundären) Pfad in einem PCC-konfigurierten und kontrollierten Kandidatenpfad konfigurieren.

  • Wenn PCEP für mehrere Pfade deaktiviert ist, können Sie nur einen primären Pfad in einem Kandidatenpfad konfigurieren. Die Konfiguration des sekundären Pfads ist nicht zulässig.

Wenn Sie PCEP-Multipaths aktivieren, compute-profile können sie jetzt mit einer maximalen Anzahl von Segmentlisten (maximum-computed-segment-lists) von mehr als 1 konfiguriert werden.

HINWEIS:

Wenn PCEP für mehrere Pfade aktiviert ist, sendet PCCD keine Einschränkungen für PCC-gesteuerte Kandidatenpfade.

Wenn die PCEP-Multipath-Funktion aktiviert ist, ist die sekundäre Pfadkonfiguration für einen nicht delegierten PCC-Kandidatenpfad zulässig. Das für den sekundären Pfad spezifische EXPLICIT-ROUTE-Objekt (EROs) wird an den PCE gesendet, wobei das Backup-Flag für den ERO festgelegt ist. Die primären Pfade enthalten den MULTIPATH-BACKUP-TLV in der PCRpt-Nachricht nicht. Sekundärer Pfad umfasst MULTIPATH-BACKUP-TLV mit Backup-Flag gesetzt.

Die folgenden PCEP-Multipath-Funktionen werden unterstützt:

  • Multipath Weight TLV (MULTIPATH-WEIGHT-TLV) im Path-Attribut (PATH-ATTRIB) Objekt

  • MULTIPATH-BACKUP TLV in Path Attribut (PATH-ATTRIB) Nur für PCC-gesteuerte SR-TE-LSPs

  • MULTIPATH-CAP-TLV im PCEP-LSP-Objekt

  • Beschränkt mehrere primäre und sekundäre Pfade im Sr-Kandidatenpfad, wenn DER PCEP-Multipath deaktiviert ist

  • Mehrere primäre und sekundäre Pfade im SR-Kandidatenpfad, wenn PCEP-Multipath für PCC-gesteuerte LSPs aktiviert ist

  • Maximale Anzahl an berechneten Segmentlisten (max-computed-segment-lists) mehr als 1 im SR-TE-Rechenprofil für delegierte und PCE-initiierte LSPs

  • Mehrere EROs für PCE-initiierte Kandidatenpfade in SR-TE und PCCD

  • SRv6-LSPs

  • SR MPLS (IPv4)

  • Dynamische SR MPLS (IPv4)-Tunnel

  • Multi-Controller-Unterstützung

  • Mehrere ERO-Pfade für PCE-initiierte, PCC-konfigurierte und kontrollierte sowie delegierte farbige und unfarbige Kandidatenpfade

  • Abwärtskompatibel mit früheren Versionen von Paragon Pathfinder. Um die Abwärtskompatibilität zu gewährleisten, müssen Sie die Konfigurationsaussage auf Hierarchieebene [edit protocols pcep] konfigurierendisable-multipath-capability.

  • Fehlercode-Unterstützung für Fehler bei der Validierung von PCE-initiierten Kandidatenpfaden

    • Die Gesamtanzahl der Pfade für Unterkandidaten pro Kandidatenpfad ist auf 127 begrenzt. Wenn die Anzahl der ERO-Pfade 127 kreuzt, wird für PCE initiierte LSPs von SR-TE ERROR an PCCD ausgegeben (und PCCD sendet PCEP-Fehlermeldung an PCE) und die entsprechenden ERO-Pfade werden abgelehnt.

Folgende PCEP-Fehlermeldungen werden unterstützt:

Tabelle 5: PCEP-Fehlermeldungen
Fehlertyp Fehlerwert Bedeutung Verwendung
19 20 Backup-Pfad wird nicht unterstützt Dies geschieht, wenn MULTIPATH-BACKUP-TLV vom PCC empfangen wird.
24 1 Inakzeptable Instanziierungsparameter Dies geschieht, wenn PCE versucht, mehr als 127 Unterkandidatenpfade pro Kandidatenpfad hinzuzufügen.

Einschränkungen

Es gelten die folgenden PCEP-Einschränkungen:

  • Die folgenden im Draft-ietf-pce-multipath-06 erwähnten TLVs werden nicht unterstützt:

    • Multipath-Backup-TLV

    • Multipath-Gegenrichtungspfad TLV

    • Zusammengesetzter Kandidatenpfad

  • Wenn die Multipath-Funktion in PCEP deaktiviert ist, ist die Konfiguration mehrerer Pfade für Subkandidaten nicht zulässig. Auf Junos-Geräten ohne Multipath-Funktion (Junos OS-Versionen früher als 22.4R1) ist jedoch die Konfiguration mehrerer Pfade für Sub-Kandidaten zulässig. Wenn PCEP-Multisegmente aktiviert ist (standardmäßig), sind für PCC-gesteuerte LSPs zum Zweck der Berichterstattung mehrere primäre Pfade zulässig. Für delegierte Kandidatenpfade wird jedoch nur ein primärer Pfad unterstützt, wenn PCEP-Multisegmente aktiviert ist.

  • Admin-Gruppen und andere Einschränkungen werden nicht an PCE für PCC-konfigurierte und kontrollierte SR-MPLS- und SRv6-Kandidatenpfade (mit einzelnen oder mehreren primären Konfigurationen) benachrichtigt. Es gibt keine Auswirkungen auf delegierte und PCE-initiierte Kandidatenpfade.

  • Wenn die PCEP-Multipath-Funktion aktiviert ist, ist die sekundäre Pfadkonfiguration für nicht delegierte Kandidatenpfade zulässig. Wenn die PCEP-Multipath-Funktion deaktiviert ist, ist die sekundäre Pfadkonfiguration nicht zulässig.

  • Kandidatenpfade können keine Mischung aus PCE-initiierten und delegierten LSPs haben.

  • Mehrere Sub-Candidate-Pfade für einen PCE-initiierten farbigen Kandidatenpfad werden nicht unterstützt.

  • Delegieren von Funktionen mit mehreren Unterkandidatenpfaden in einem Kandidatenpfad wird nicht unterstützt.

Konfiguration

Fügen Sie die propagate-max-segmentlist Konfigurationsaussage aufedit protocols pcep [] Hierarchieebene ein, um PCCD zu ermöglichen, mehrpfadfähige TLV im LSP-Objekt zu senden, um die maximal berechnete Segmentliste für einen bestimmten Kandidatenpfad zu benachrichtigen. Standardmäßig wird die TLV nicht im LSP-Objekt gesendet.

Um die PCEP-Sitzung mit mehreren Funktionen für alle PCEs zu deaktivieren, fügen Sie die disable-multipath-capability Konfigurationsaussage auf der Hierarchieebene [edit protocols pcep] ein.

Sie können die folgenden Protokoll-Traceoptionen für die Diagnose aktivieren:

  • user@host# set protocols pcep traceoptions ...

  • user@host# set protocols pcep pce pce1 traceoptions ...

  • user@host# set protocols source-packet-routing traceoptions

Sie können die folgenden Show-Befehle verwenden, um den Status von LSPs in PCC anzuzeigen:

  • user@host> show path-computation-client lsp— Zeigt den Status der Label-Switched Paths (LSPs) an, die dem Path Computation Client (PCC) bekannt sind.

  • user@host> show path-computation-client lsp extensive— Zeigen Sie das umfangreiche Ausgabeniveau zu jedem bekannten LSP an – Punkt-zu-Punkt- und Point-to-Multipoint-LSPs.

  • user@host> show path-computation active-pce– Zeigt den Status von Multipath in den Sitzungen an.

  • user@host> show spring-traffic-engineering lsp detail—Anzeige der Eingangsdetails des SPRING Traffic Engineering.

Ermöglichung der Sicherheit auf Transportebene für PCEP-Sitzungen

Transport Layer Security (TLS) unterstützt Peer-Authentifizierung, Nachrichtenverschlüsselung und Integrität. Sie können TLS im Path Computation Client (PCC) aktivieren, um eine TCP-Verbindung mit dem Path Computation Element (PCE) wie in RFC 8253 definiert herzustellen. Dadurch wird eine sichere PCEP-Sitzung (PCEPS) zum Transport von PCEP-Nachrichten erstellt.

In diesem Dokument wird beschrieben, wie Sie TLS für PCEP-Sitzungen aktivieren, um Interaktionen mit PCE zu sichern, einschließlich der Einleitung der TLS-Prozeduren, des TLS-Handshake-Mechanismus und der TLS-Methoden für die Peer-Authentifizierung. Sicherer Transport für PCEP über TLS wird auch als PCEPS bezeichnet.

Vorteile der Aktivierung von TLS für PCEP-Sitzungen

  • Schützt PCEP-Sitzungen vor Angriffen wie Spoofing (PCC- oder PCE-Identitätswechsel), Snooping (Nachrichtenabfangen), Fälschung und Denial of Service.

  • Nutzt die Vorteile der TLS-Sicherheit.

Aktivieren von TLS in Path Computation Client (PCC)

Um TLS in PCC zu aktivieren und eine PCEPS-Sitzung einzurichten, legen Sie die tls-strict CLI-Anweisung auf Hierarchieebene [edit protocols pcep] fest.

Nach der Aktivierung der tls-strengen Konfigurationsaussage passieren die folgenden Ereignisse:

  1. PCEP-Sitzungsklappen. Jede vorhandene TCP-Verbindung wird beendet und eine erneute Verbindung erfolgt mithilfe von TLS.

  2. PCC stellt eine TCP-Verbindung mit dem PCE her.

  3. TLS-Prozeduren werden durch die StartTLS Nachricht von PCE an PCC und von PCC zu PCE initiiert. Die StartTLS Nachricht wird von PCC gesendet und der StartTLSWait Timer wird gestartet. Sie können den StartTLSWait Timer konfigurieren, indem Sie die start-tls-wait-timer seconds CLI-Anweisung auf der Hierarchieebene [edit protocols pcep pce pce-id] konfigurieren.

    HINWEIS:

    Der empfohlene Wert für den StartTLSWait Timer beträgt 60 Sekunden und darf nicht niedriger als der OpenWait Timer sein. Der Standard-Timer-Wert OpenWait ist auf 60 Sekunden festgelegt.

    • Wenn die Open-Nachricht von PCC empfangen StartTLS wird, PCErr wird eine Nachricht mit Error-Type auf 1 (PcEP-Sitzungseinrichtung fehlgeschlagen) und Fehlerwert auf 1 (Empfang einer ungültigen Open-Nachricht oder einer nicht-offenen Nachricht) festgelegt, und die TCP-Sitzung wird geschlossen.

    • Wenn StartTLS eine Nachricht nicht von PCE empfangen wird, sendet PCC nach Ablauf des StartTLSWait Timers eine PCErr Nachricht mit dem Wert Error-Type auf 25 (PCEP-FehlerStartTLS) und den Fehlerwert auf 5 (keine Nachricht (nochStartTLS PCErr/Open) vor Ablauf StartTLSWait des Timers), und die TCP-Sitzung wird geschlossen.

  4. Aushandlung und Aufbau einer TLS-Verbindung erfolgt.

  5. Der Austausch von PCEP-Nachrichten wird gemäß RFC5440 gestartet.

HINWEIS:

Wenn Sie die tls-strict CLI-Anweisung unter der Hierarchieebene [edit protocols pcep] nicht aktivieren, dann wird beim Einrichten einer PCEP-Sitzung, wenn die StartTLS Nachricht von PCC empfangen wird, anstelle der Open Nachricht, PCErr fehlermeldungstyp ist auf 1 (PCEP-Sitzungseinrichtung fehlgeschlagen) und Fehlerwert auf 1 (Empfang einer ungültigen Open-Nachricht oder einer nicht-offenen Nachricht) festgelegt, wird die TCP-Sitzung geschlossen.

HINWEIS:

Um eine erfolgreiche PCEPS-Sitzung herzustellen, muss TLS sowohl auf PCC als auch auf PCE aktiviert sein.

Aktualisieren von Zertifikaten mithilfe der Public Key Infrastructure (PKI)

Die PKI benachrichtigt PCC nicht über den Ablauf des Zertifikats. Sie müssen das Zertifikat manuell mit dem folgenden CLI-Befehl aktualisieren. Bei dieser Methode müssen Sie das Ablaufdatum des Zertifikats im Auge behalten.

Einrichten einer TLS-Verbindung

In den folgenden Schritten wird beschrieben, wie eine TLS-Verbindung (unter Verwendung von TLS v1.2) hergestellt wird:

  1. Generieren Sie Zertifikate für die Knoten (Junos OS-Geräte/pce-server). Sie können die Zertifikate mit einer der folgenden Methoden generieren:

    • Method 1— Generieren Sie Schlüsselpaar und CSR auf dem Gerät und senden Sie dieses CSR an die CA, um das Zertifikat zu erhalten. Sobald das Zertifikat ausgestellt ist, wird es in das Kästchen kopiert und installiert.

    • Method 2— Generieren Sie das Schlüsselpaar und das Zertifikat sofort. Sowohl das Zertifikat als auch der private Schlüssel werden auf dem Gerät kopiert und zusammen installiert.

  2. Laden Sie die Zertifizierungsstelle (Certification Authority, CA) auf den PCC, damit das PCE-Serverzertifikat anhand der geladenen Zertifizierungsstelle validiert werden kann.

    HINWEIS:

    CAs können in einer flachen Hierarchie als unabhängige Zertifizierungsstelle geladen werden. Wenn eine Zertifizierungsstelle eine Unter-CA einer anderen CA ist, wird die Kette intern von PKI aufgebaut.

    HINWEIS:

    Das Serverzertifikat sollte von einer Zertifizierungsstelle signiert werden. Selbstsignierte Zertifikate sind nicht erlaubt.

  3. Aktivieren Sie TLS auf PCC.

  4. PCEP-Sitzung wird über TLS mit TLS-Handshake-Mechanismus eingerichtet.

  5. PCE-Server überwacht Port 4189 auf eingehende PCC-Verbindungsanfragen über TLS.

  6. PCC initiiert die Verbindungsanfrage zum Ziel-Port 4189.

  7. Nach Abschluss eines Drei-Wege-Handshakes beginnt der TLS-Handshake mit der Verwendung der Zertifikate und die One-Way-Authentifizierung ist durchgeführt (PCC authentifiziert das Serverzertifikat). Sowohl der Server als auch der Client warten, StartTLSWait bis die StartTLS Nachricht empfangen wird. Sie können den StartTLSWait Timer konfigurieren, indem Sie die start-tls-wait-timer seconds CLI-Anweisung auf der Hierarchieebene [edit protocols pcep pce pce-id] konfigurieren.

    HINWEIS:

    Der empfohlene Wert für den StartTLSWait Timer beträgt 60 Sekunden und darf nicht niedriger als der OpenWait Timer sein. Der Standard-Timer-Wert OpenWait ist auf 60 Sekunden festgelegt.

  8. Nach der erfolgreichen TLS-Handshake-Sitzung initiiert PCC und PCE die Einrichtung der PCEP-Sitzung über TLS, während der die Sitzungsparameter ausgehandelt werden.

    • Wenn die Zertifikatsvalidierung fehlschlägt, beendet PCC die TCP-Verbindung.

  9. PCEP-Nachricht wird über TLS-Verbindung als Anwendungsdaten gesendet.

  10. Die Verschlüsselung und Entschlüsselung erfolgt sowohl auf PCC als auch auf PCE nach einem erfolgreichen TLS-Handshake.

  11. Wenn die PCEP-Sitzung geschlossen wird, wird die TLS-Sitzung entfernt.

HINWEIS:

Wenn das Zertifikat während einer laufenden PCEP-über-TLS-Sitzung abgelaufen, widerrufen oder neu geladen wird, ist die laufende Sitzung nicht betroffen.

Grundlegendes zum TLS-Handshake-Mechanismus

Der Handshake ist eine Serie von Nachrichten, die zwischen einem Server und einem Client ausgetauscht werden. Die genauen Schritte im Handshake variieren je nach Schlüsselaustauschalgorithmus, Cipher Suite usw. Im Folgenden werden die grundlegenden Schritte zum TLS-Handshake-Mechanismus beschrieben:

  1. Client Hello— Der Client initiiert den Handshake, indem er diese Nachricht sendet. Diese Nachricht enthält TLS-Version, eine Liste der unterstützten Kryptografiealgorithmen oder Cipher Suite und andere Client-Details.

  2. Server Hello— Der Server antwortet auf "Client Hello", indem er eine Sever-Hallo-Nachricht sendet. Diese Nachricht enthält Serverzertifikat, ausgewählten Kryptografiealgorithmus, Sitzungs-ID und den öffentlichen Schlüssel des Servers.

  3. Authentication— Der Client im Hintergrund überprüft das Serverzertifikat mit einer konfigurierten Zertifizierungsstelle, die das Zertifikat ausgestellt hatte. Bei erfolgreicher Überprüfung bestätigt der Client, dass der Server echt ist und interagiert weiter.

  4. Optional Client Certificate— Wenn der Server in der Server Hello-Nachricht ein Zertifikat vom Client angefordert hat, sendet der Client das Client-Zertifikat (nur im Fall von gegenseitigem TLS).

  5. Client Key Exchange— Der Client sendet einen geheimen Schlüssel, der mit dem öffentlichen Schlüssel des Servers verschlüsselt ist (in der Nachricht "Server Hallo" erfasst).

  6. Decrypt secret key— Der Server entschlüsselt den geheimen Schlüssel mithilfe des privaten Schlüssels.

  7. Client Finished— Der Client sendet eine Finish-Nachricht, die mit dem gemeinsam genutzten geheimen Schlüssel verschlüsselt ist, und signalisiert den Handshake "Complete".

  8. Server Finished— Der Server antwortet mit einer Endnachricht, die mit dem gemeinsam genutzten geheimen Schlüssel verschlüsselt ist, und signalisiert den Handshake "Complete".

  9. Exchange Messages— Die Nachrichten nach dem Handshake-Abschluss werden symmetrisch verschlüsselt.

Diagnose und Validierung von TLS für PCEP-Sitzungen

Verwenden Sie für Diagnosen die folgenden CLI-Anweisungen für Traceoptions:

Aktivieren Sie PKI-Protokolle mit der folgenden Konfiguration und erfassen Sie dieselbe Datei von /var/log/<filename>

Überprüfen Sie das geladene CA-Zertifikat mit dem folgenden Befehl:

Beispielausgabe

Im Folgenden sehen Sie eine Beispielausgabe des show path-computation-client statistics Befehls:

Diese Beispielausgabe bietet die folgenden Informationen:

  • TLS ist bei PCC aktiviert.

  • PCE ist TLS-fähig.

  • TLS-Sitzung eingerichtet. Dies zeigt auch an, dass das PCE-Serverzertifikat gültig ist.

  • Der PCEPS-Sitzungsstatus ist einsatzbereit.

Berichtspfadoptimierung und berechnete Metriken in PCEP

Das Metrikobjekt in PCEP wird für mehrere Zwecke verwendet. Das Metrikobjekt gibt den Metriktyp an, der für die Pfadoptimierung verwendet wird. Das Metrikobjekt gibt auch eine Bindung an die Pfadkosten an, die nicht überschritten werden darf, damit der Pfad als akzeptabel angesehen wird. Das Metrikobjekt gibt auch die berechnete Metrik an.

Wir unterstützen Kennzahlobjekte für die Pfadoptimierung (Interior Gateway Protocol, Traffic Engineering und Pfadverzögerung) und Berichterstellung von berechneten Metriken für RSVP- und SR-TE-LSPs.

HINWEIS:

Metrikobjekt zur Pfadoptimierung und Berichterstattung von berechneten Metriken ist für SRv6-TE-LSPs nicht anwendbar.

Vorteile von Berichtspfadoptimierung und berechneten Metriken in PCEP

  • Die Berichterstattung über in PCC konfigurierte Pfadoptimierungsmetriken hilft PCE, sich der Einschränkungen bewusst zu sein, die für die Pfadberechnung verwendet werden.

  • Berichterstellung von berechneten Metriken an den PCE. Auf diese Weise kann PCE analysieren, ob der LSP eine weitere Optimierung erfordert.

Verständnis der Optimierungsmetriken

Im folgenden Abschnitt werden die beabsichtigten und tatsächlichen Optimierungsmetriken für RSVP- und SR-TE (SR MPLS)-LSPs in PCEP beschrieben.

Lokal erstellte RSVP-LSP

Um die lokal erstellten RSVP-LSPs mit Metriken zu optimieren, konfigurieren Sie die Optimierungsmetriken (IGP, TE und Pfadverzögerung), sodass die konfigurierte Metrik über PCEP gemeldet wird. Die berechnete Metrik wird als tatsächliche Metrik in PCEP durch die PCRpt-Nachricht gesendet.

Delegierter RSVP-LSP

Um die Optimierungsmetriken für delegierte RSVP-LSPs zu melden, konfigurieren Sie die Optimierungsmetriken (IGP, TE und Pfadverzögerung).

Intended Metric:

  • Wenn die Optimierungskennzahl zum Zeitpunkt der Delegierung des LSP konfiguriert ist, werden die Informationen über die PCRpt-Nachricht an PCE gesendet.

  • Wenn die Optimierungskennzahl nach der Delegierung von LSP konfiguriert wird, wird die Änderung auf dem LSP angewendet/an den PCE übermittelt, wenn der LSP-Steuerungsstatus lokal gesteuert wird.

  • Wenn die PCUpd-Nachricht empfangen wird und die Optimierungskennzahl in der Nachricht vorhanden ist, wird die Metrik in den nachfolgenden PCRpt-Meldungen als beabsichtigte Metrik verwendet, bis der LSP-Kontrollstatus extern gesteuert wird.

  • Wenn die PCUpd-Nachricht empfangen wird und die Optimierungskennzahl in der Nachricht nicht vorhanden ist, enthalten nachfolgende PCRpt-Meldungen keine beabsichtigte Metrik.

  • Wenn sich der Status der LSP-Steuerung in lokal gesteuert ändert, wird die über Junos CLI konfigurierte Optimierungskennzahl die beabsichtigte Metrik in der PCRpt-Meldung.

Actual Metric:

  • Während der Delegierung des LSP enthält die PCRpt-Nachricht keine tatsächliche Metrik.

  • Wenn eine PCUpd-Nachricht empfangen wird und eine berechnete Metrik in der Nachricht vorhanden ist, wird die Metrik in den nachfolgenden PCRpt-Meldungen als tatsächliche Metrik verwendet, bis der LSP-Kontrollstatus extern gesteuert wird.

  • Wenn eine PCUpd-Nachricht empfangen wird, wenn keine berechnete Metrik in der Nachricht vorhanden ist, enthalten die nachfolgenden PCRpt-Meldungen keine tatsächliche Metrik.

  • Wenn sich der Status der LSP-Steuerung in lokal gesteuert ändert, wird die von PCC berechnete Metrik in der PCRpt-Nachricht als tatsächliche Metrik gesendet.

PCE-initiierter RSVP-LSP

Um die Optimierungsmetriken für PCE-initiierte RSVP-LSPs zu melden, konfigurieren Sie die Optimierungsmetriken (IGP, TE und Pfadverzögerung) in einer Vorlage. Die Vorlage wird dann auf den PCE-initatierten LSP angewendet, wenn der LSP-Steuerungsstatus lokal gesteuert wird.

Intended Metric:

  • Wenn ein PCE-initiierter LSP einer Vorlage mit Optimierungsmetrik zugeordnet wird, wird die Konfiguration auf den LSP angewendet und an den PCE gesendet, wenn sich der LSP-Steuerungsstatus auf lokal gesteuert ändert.

  • Wenn die PCInit/PCUpd-Nachricht empfangen wird und die Optimierungskennzahl in der Nachricht vorhanden ist, wird die Metrik in den nachfolgenden PCRpt-Meldungen wie vorgesehen verwendet, bis der LSP-Kontrollstatus extern gesteuert wird.

  • Wenn die PCInit/PCUpd-Nachricht empfangen wird und keine Optimierungskennzahl in der Nachricht vorhanden ist, enthalten die nachfolgenden PCRpt-Meldungen keine beabsichtigte Metrik.

  • Wenn der LSP-Steuerungsstatus lokal gesteuert wird, wird die in der Vorlage vorhandene Optimierungsmetrik als beabsichtigte Metrik in der PCRpt-Nachricht verwendet.

Actual Metric:

  • Wenn eine PCInit/PCUpd-Nachricht empfangen wird und die berechnete Metrik in der Nachricht vorhanden ist, wird die Metrik in den nachfolgenden PCRpt-Meldungen als tatsächliche Metrik verwendet, bis der LSP-Kontrollstatus extern gesteuert wird.

  • Wenn die pcInit/PCUpd-Nachricht empfangen wird, enthalten die nachfolgenden PCRpt-Meldungen keine tatsächliche Metrik, wenn die berechnete Metrik in der Nachricht nicht vorhanden ist.

  • Wenn sich der Status der LSP-Steuerung in lokal gesteuert ändert, wird die von PCC berechnete Metrik in der PCRpt-Nachricht als tatsächliche Metrik gesendet.

Delegierter SR-TE-LSP

Um die Optimierungsmetriken für delegierte SR-TE (SR MPLS)-LSPs zu melden, konfigurieren Sie die Optimierungsmetriken (IGP, TE und Pfadverzögerung).

Intended Metric:

  • Wenn die Optimierungskennzahl zum Zeitpunkt der Delegierung von LSP konfiguriert ist, werden die Informationen über die PCRpt-Nachricht an den PCE gesendet.

  • Wenn die Optimierungskennzahl nach der Delegierung von LSP konfiguriert wird, wird die Änderung auf dem LSP angewendet/an den PCE übermittelt, wenn der LSP-Steuerungsstatus lokal gesteuert wird.

  • Wenn die PCUpd-Nachricht empfangen wird und die Optimierungskennzahl in der Nachricht vorhanden ist, wird die Metrik in den nachfolgenden PCRpt-Meldungen als beabsichtigte Metrik verwendet, bis der LSP-Kontrollstatus extern gesteuert wird.

  • Wenn die PCUpd-Nachricht empfangen wird und die Optimierungskennzahl in der Nachricht nicht vorhanden ist, enthalten nachfolgende PCRpt-Meldungen keine beabsichtigte Metrik.

  • Wenn sich der Status der LSP-Steuerung in lokal gesteuert ändert, wird die über Junos CLI konfigurierte Optimierungskennzahl die beabsichtigte Metrik in der PCRpt-Meldung.

Actual Metric:

  • Wenn LSP nach der Erstellung delegiert wird, werden zum Zeitpunkt der LSP-Delegierung, wenn LSP 1 ERO hat, berechnete Werte von IGP, TE und Verzögerungsmetriken als tatsächliche Metriken in der PCRpt-Nachricht gesendet.

  • Wenn LSP nach der Erstellung delegiert wird, zum Zeitpunkt der LSP-Delegierung, wenn LSP mehrere EROs hat, wird die berechnete/tatsächliche Metrik nicht in der PCRpt-Nachricht gesendet, da die tatsächliche Metrik pro LSP (nicht pro ERO) in PCEP gesendet werden muss.

  • Wenn eine PCUpd-Nachricht empfangen wird und eine berechnete Metrik in der Nachricht vorhanden ist, wird die Metrik in den nachfolgenden PCRpt-Meldungen als tatsächliche Metrik verwendet, bis der LSP-Kontrollstatus extern gesteuert wird.

  • Wenn eine PCUpd-Nachricht empfangen wird, wenn keine berechnete Metrik in der Nachricht vorhanden ist, enthalten die nachfolgenden PCRpt-Meldungen keine tatsächliche Metrik.

  • Wenn sich der Status der LSP-Steuerung in lokal gesteuert ändert, werden IGP-, TE- und Verzögerungsmetriken, die in PCC berechnet werden, als tatsächliche Metriken in der PCRpt-Nachricht gesendet.

PCE-initiierter SR-TE LSP

Beabsichtigte Metriken oder tatsächliche Metriken, die von PCE in PCInit/PCUpd-Nachrichten gesendet werden, werden über PCRpt-Nachricht an PCE zurückgemeldet, bis der LSP extern kontrolliert wird.

Intended Metric:

  • Wenn die PCInit/PCUpd-Nachricht empfangen wird und die Optimierungskennzahl in der Nachricht vorhanden ist, wird die Metrik in den nachfolgenden PCRpt-Meldungen wie vorgesehen verwendet, bis der LSP-Kontrollstatus extern gesteuert wird.

  • Wenn die PCInit/PCUpd-Nachricht empfangen wird und keine Optimierungskennzahl in der Nachricht vorhanden ist, enthalten die nachfolgenden PCRpt-Meldungen keine beabsichtigte Metrik.

  • Wenn der LSP-Steuerungsstatus lokal gesteuert wird, wird die beabsichtigte Metrik nicht gesendet.

Actual Metric:

  • Wenn die PCInit/PCUpd-Nachricht empfangen wird und eine berechnete Metrik in der Nachricht vorhanden ist, wird die Metrik in den nachfolgenden PCRpt-Meldungen als tatsächliche Metrik verwendet, bis der LSP-Kontrollstatus extern gesteuert wird.

  • Wenn die PCInit/PCUpd-Nachricht empfangen wird, enthalten die nachfolgenden PCRpt-Meldungen keine tatsächliche Metrik, wenn in der Nachricht keine berechnete Metrik vorhanden ist.

  • Wenn sich der LSP-Steuerungsstatus in lokal gesteuert ändert, enthalten nachfolgende PCRpt-Nachrichten keine tatsächliche Metrik.

Senden der Optimierungskennzahl in PCRpt-Nachricht

Die Optimierungskennzahl wird über intended-attributes-list die in-PCRpt-Nachricht an den PCE gesendet. Der Metrikwert ist auf 0 und B, C-Flags auf 0 festgelegt. Der Metriktyp gibt die zu optimierenden Metrik an.

Senden einer rechnergestützten Metrik in PCRpt-Nachricht

Die berechnete Metrik wird durch actual-attributes-list die in-PCRpt-Nachricht an den PCE gesendet. Der Metrikwert ist der berechnete Metrikwert und der Metriktyp gibt den berechneten Metriktyp an. B-Flag ist auf 0 und C-Flag auf 1 gesetzt.

Abwärtskompatibilität für Routing-Metrik

Da die Routenmetrik mithilfe von Anbieter-TLV unterstützt wird, verarbeitet PCC keine Routenmetrik, die von Juniper PCE gesendet wird, die Northstar und ältere Versionen von paragon Pathfinder unterstützt.

Konfigurieren von Optimierungsmetriken für LSPs

Sie können Optimierungsmetriken (IGP, TE und Pfadverzögerung) für RSVP-LSPs und SR-TE LSP konfigurieren.

Um die IGP-, TE- und Pfadverzögerungsoptimierungsmetriken für RSVP-LSPs zu konfigurieren, fügen Sie die metric-type <igp|te|delay|delay minimum> CLI-Anweisung auf der Hierarchieebene [edit protocols mpls label-switched-path <lsp-name>] ein.

Um die IGP-, TE- und Pfadverzögerungsoptimierungsmetriken für SR-TE-LSPs zu konfigurieren, fügen Sie die metric-type <igp|te|delay|delay minimum> CLI-Anweisung auf der Hierarchieebene [edit protocols source-packet-routing compute-profile <compute-profile-name>] ein.

Beispielausgabe

Sie können die show path-computation-client lsp Cli-Befehle verwenden show path-computation-client lsp extensive , um den Status von Label-Switched Paths (LSPs) anzuzeigen, die dem Path Computation Client (PCC) bekannt sind.

Im Folgenden wird eine Beispielausgabe von show path-computation-client lsp extensive:

Die Ausgabe zeigt, dass der LSP mit der Metrik Typ IGP optimiert ist. Der berechnete Wert der IGP-Metrik ist 50. Die in der Routing-Tabelle installierte Route-Metrik ist 50.

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
Ab Junos OS Version 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 auflösen.
19.4R1
Sie können einen einzelnen oder einen Bereich 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 PCE-initiierte Segment-Routing-LSPs konfigurieren, um zwei zusätzliche Parameter für diese LSPs weiterzugeben: Bidirectional Forwarding Detection (BFD) und LDP-Tunneling.
19.1R1
Ab Junos OS Version 19.1R1 wird eine Commit-Check-Funktion eingeführt, um sicherzustellen, dass alle Segmentlisten, die zu den farbigen Routen beitragen, das Mindestetikett für alle Hops aufweisen.
19.1R1
Ab Junos OS Version 19.1R1 gilt diese Anforderung nicht, da der erste Hop der nicht farbigen statischen LSPs jetzt zusätzlich zu DEN IP-Adressen auch SID-Label unterstützt. Mit der Unterstützung des ersten Hop-Label werden MPLS Fast Reroute (FRR) und weighted equal-cost Multipath aktiviert, um die statischen nicht-farbigen Segment-Routing-LSPs zu lösen, ähnlich wie farbige statische LSPs.
18.2R1
Ab Junos OS Version 18.2R1 werden statisch konfigurierte nicht farbige Segment-Routing-LSPs auf dem Eingangsgerät über eine Path Computation Element Protocol (PCE)-Sitzung an das Path Computation Element Protocol (PCE) gemeldet.
17.2R1
Ab Junos OS Version 17.2 werden zusätzlich zu external cspfden PCE-gesteuerten LSPs zwei neue Pfadberechnungstypen eingeführt: local cspf und no cspf.
16.1
Ab Junos OS Version 16.1 können Sie eine PCEP-Sitzung mit TCP-MD5-Authentifizierung gemäß RFC 5440 sichern.
16.1
Junos OS Version 16.1 führt die Funktion ein, eine PCEP-Sitzung mit TCP-MD5-Authentifizierung gemäß RFC 5440 zu sichern.
14.2R4
Ab Junos OS Version 14.2R4 wird Unterstützung für automatische Bandbreite für PCE-gesteuerte LSPs bereitgestellt.