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 Route basierend auf einem Netzwerkdiagramm zu berechnen und Recheneinschränkungen anzuwenden. Ein Path Computation Client (PCC) ist eine beliebige Client-Anwendung, die eine Pfadberechnung 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 wurde 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 Engineering LSPs (TE LSPs) verwendet werden. Es stellt einen Mechanismus bereit, mit dem ein PCE eine Pfadberechnung für die externen LSPs eines PCC durchführen kann. Die PCEP-Interaktionen umfassen LSP-Statusberichte, die vom PCC an das PCE gesendet werden, sowie 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 einen PCC mit einem externen PCE. Der 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. Beim Empfang eines oder mehrerer LSP-Parameter vom PCE signalisiert der PCC den TE LSP erneut. Wenn die PCEP-Sitzung beendet wird, wird die zugrunde liegende TCP-Verbindung sofort geschlossen, und der PCC versucht, die PCEP-Sitzung wiederherzustellen.

Zu den PCEP-Funktionen gehören also:

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

  • Delegierung der Steuerung über LSP-Tunnel an ein zustandsbehaftetes PCE—Ein aktives zustandsbehaftetes PCE steuert ein oder mehrere LSP-Attribute für die Berechnung von Pfaden, z. B. Bandbreite, Pfad (ERO) und Priorität (Einrichtung und Halten). PCEP ermöglicht eine solche Delegation von Sprachdienstleistern für die Pfadberechnung.

  • Zustandsbehaftete PCE-Steuerung des Timings und der Abfolge von Pfadberechnungen innerhalb und zwischen PCEP-Sitzungen: Ein aktives zustandsbehaftetes PCE ändert ein oder mehrere LSP-Attribute, z. B. Bandbreite, Pfad (ERO) und Priorität (Einrichtung und Halten). PCEP übermittelt diese neuen LSP-Attribute vom PCE an den PCC, woraufhin der PCC den LSP im angegebenen Pfad erneut signalisiert.

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 Betriebsnetzen, wobei der Datenverkehr hauptsächlich auf eine vorhandene physische Topologie abgebildet wird. Traffic Engineering bietet die Möglichkeit, den Datenverkehrsfluss vom kürzesten vom Interior Gateway Protocol (IGP) gewählten Pfad auf einen potenziell weniger überlasteten physischen Pfad in einem Netzwerk zu verlagern.

Für das Traffic Engineering in großen, dichten Netzwerken können MPLS-Funktionen implementiert werden, da sie potenziell den größten Teil der in einem Overlay-Modell verfügbaren Funktionalität auf integrierte Weise und zu geringeren Kosten als die derzeit konkurrierenden Alternativen bereitstellen. Der Hauptgrund für die Implementierung von MPLS Traffic Engineering ist die Steuerung von Pfaden, entlang derer der Datenverkehr durch ein Netzwerk fließt. Der Hauptvorteil der Implementierung von MPLS Traffic Engineering besteht darin, dass sie eine Kombination aus den Traffic-Engineering-Funktionen von ATM und der Class-of-Service (CoS)-Differenzierung von IP bietet.

In einem MPLS-Netzwerk werden Informationen auf der Datenebene mithilfe von Label Switching weitergeleitet. Auf ein Paket, das vom Kunden-Edge-Router (CE) auf einem Provider-Edge-Router (PE) eingeht, werden Bezeichnungen angewendet, die dann an den ausgehenden PE-Router weitergeleitet werden. Die Labels 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 Labels zu kommunizieren, die zum Weiterleiten des Datenverkehrs zwischen und durch die LSRs verwendet werden. RSVP-TE ist ein solches Label-Verteilungsprotokoll, das es einem LSR-Peer ermöglicht, mehr über die Label-Zuordnungen 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 Signale innerhalb von Label-Switched-Pfaden (LSPs) zu unterstützen. RSVP reserviert Ressourcen, z. B. für IP-Unicast- und Multicast-Datenströme, und fordert QoS-Parameter (Quality of Service) für Anwendungen an. Das Protokoll wurde in MPLS Traffic Engineering erweitert, damit RSVP LSPs einrichten kann, die für Traffic Engineering in MPLS-Netzwerken verwendet werden können.

Wenn MPLS und RSVP kombiniert werden, werden Bezeichnungen mit RSVP-Flows verknüpft. Sobald ein LSP eingerichtet ist, wird der Datenverkehr durch den Pfad durch die Bezeichnung definiert, die auf den Eingangsknoten des LSP angewendet wird. Die Zuordnung des Labels zum Datenverkehr erfolgt anhand verschiedener Kriterien. Die Gruppe von Paketen, denen von einem bestimmten Knoten derselbe Label-Wert zugewiesen wird, gehört derselben Weiterleitungsäquivalenzklasse (FEC) an und definiert effektiv den RSVP-Fluss. Wenn Datenverkehr auf diese Weise einem LSP zugeordnet wird, wird der LSP als LSP-Tunnel bezeichnet.

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

Im Allgemeinen richtet RSVP-TE einen Label-Switched-Pfad ein, der die Frame-Bereitstellung vom Eingangs- zum Ausgangsrouter sicherstellt. 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 teilweise expliziten Route einzurichten (RFC 3209).

  • Constraint-basierte LSP-Einrichtung über Verbindungen, die Anforderungen erfüllen, wie z. B. Bandbreite und Verbindungseigenschaften.

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

  • Link-Management, das Link-Ressourcen verwaltet, um ressourcenorientiertes Routing von Traffic-Engineering-LSPs durchzuführen und MPLS-Labels zu programmieren.

  • MPLS Fast Reroute (FRR), das die LSPs verwaltet, die geschützt werden müssen, und diesen LSPs Backup-Tunnelinformationen zuweist.

Aktuelle MPLS RSVP-TE-Einschränkungen

Obwohl die RSVP-Erweiterungen für das Traffic Engineering eine bessere Netzwerkauslastung ermöglichen und die Anforderungen der Datenverkehrsklassen erfüllen, weist die heutige MPLS RSVP-TE-Protokollsuite mehrere Probleme auf, die mit ihrer verteilten Natur zusammenhängen. Dies führt zu einer Reihe von Problemen beim Konflikt um die Zweiteilungskapazität, insbesondere innerhalb einer LSP-Prioritätsklasse, in der eine Teilmenge von LSPs gemeinsame Einstellungen und Prioritätswerte aufweist. Zu den Einschränkungen von RSVP-TE gehören:

  • Mangelnde Transparenz der individuellen Bandbreitenanforderungen pro LSP und pro Gerät: Die Eingangsrouter in einem MPLS RSVP-TE-Netzwerk richten LSPs ein, ohne einen globalen Überblick über den Bandbreitenbedarf im Netzwerk zu haben. Informationen zur Auslastung von Netzwerkressourcen sind nur als reservierte Gesamtkapazität nach Datenverkehrsklasse pro Schnittstelle 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 dem Nachfragemuster auf, insbesondere innerhalb eines gemeinsamen Setups und einer gemeinsamen Haltepriorität.

  • Asynchrone und unabhängige RSVP-Signalisierung: In RSVP-TE werden die Einschränkungen für die Pfadeinrichtung von einem 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 einer Traffic-Engineering-Verbindung verfügbare Bandbreite die für die Verbindung konfigurierte Bandbreite, ohne die Summe aller Reservierungen, die für die Verbindung vorgenommen wurden. Daher führen die nicht signalisierten Anforderungen an einen LSP-Tunnel zu einer Verschlechterung des Dienstes des LSP, der überschüssige Bandbreite benötigt, sowie der anderen LSPs, die die Bandbreitenanforderungen der Traffic-Engineering-Verbindung erfüllen.

  • LSPs, die auf der Grundlage dynamischer oder expliziter Pfadoptionen in der Reihenfolge ihrer Präferenz eingerichtet werden: Die Eingangsrouter in einem MPLS RSVP-TE-Netzwerk richten LSPs für Anforderungen basierend auf der Reihenfolge des Eingangs ein. Da die Eingangsrouter keine globale Ansicht des Bandbreitenbedarfs im Netzwerk haben, kann die Verwendung der Präferenzreihenfolge zum Einrichten von LSPs dazu führen, dass Datenverkehr verworfen wird oder LSPs überhaupt nicht eingerichtet werden, wenn ein übermäßiger Bandbreitenbedarf besteht.

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

Abbildung 2: Beispiel MPLS Traffic EngineeringBeispiel MPLS Traffic Engineering

Die Eingangsrouter richten LSPs basierend auf der Reihenfolge ein, in der die Anforderungen eingehen. Wenn Router G zwei Anforderungen von je Kapazität 5 für G-F empfängt, signalisiert G zwei LSPs – LSP1 und LSP2 – über G-B-D-F. Auf die gleiche Weise signalisiert Router A, wenn er die dritte Anforderung von Kapazität 10 für A-E erhält, einen LSP, LSP3, über A-B-C-E. Wenn die Anforderung des A-E LSP jedoch von 10 auf 15 steigt, kann Router A LSP3 nicht über denselben Pfad (A-B-C-E) signalisieren, da die B-C-Verbindung eine geringere Kapazität aufweist.

Router A hätte die erhöhte Nachfrage nach LSP3 über den Pfad A-B-D-C-E signalisieren sollen. Da LSP1 und LSP2 die B-D-Verbindung basierend auf der Reihenfolge der eingegangenen Anforderungen verwendet haben, wird LSP3 nicht signalisiert.

Obwohl also für alle Sprachdienstleister eine ausreichende Bandbreite für den maximalen Datenfluss zur Verfügung steht, ist LSP3 einer potenziell verlängerten Dienstverschlechterung ausgesetzt. Dies ist auf die mangelnde globale Nachfragetransparenz von Router A und die mangelnde systemische Koordination bei der Bedarfsplatzierung durch die Eingangsrouter A und G zurückzuführen.

Verwendung einer externen Path Computing-Entität

Als Lösung für die derzeitigen Einschränkungen bei der MPLS RSVP-TE-Pfadberechnung ist eine externe Pfadberechnungseinheit mit einer globalen Ansicht des Bedarfs pro LSP und pro Gerät im Netzwerk unabhängig von der verfügbaren Kapazität erforderlich.

Derzeit wird in einem MPLS RSVP-TE-Netzwerk nur eine auf Online- und Echtzeiteinschränkungen basierende Routing-Pfadberechnung bereitgestellt. Jeder Router führt einschränkungsbasierte Routingberechnungen unabhängig von den anderen Routern im Netzwerk durch. Diese Berechnungen basieren auf aktuell verfügbaren Topologieinformationen, d. h. Informationen, die in der Regel aktuell, aber nicht vollständig genau sind. LSP-Platzierungen werden basierend auf dem aktuellen Netzwerkstatus lokal optimiert. Die MPLS RSVP-TE-Tunnel werden über die CLI eingerichtet. Ein Bediener 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 Pfadberechnungseinheit erweitert, die als Path Computation Element (PCE) bezeichnet wird. Der PCE berechnet den Pfad für die TE-LSPs von Eingangsroutern, die für die externe Steuerung konfiguriert wurden. Der Eingangsrouter, der eine Verbindung zu einem PCE herstellt, wird als Path Computation Client (PCC) bezeichnet. Der PCC ist mit dem Path Computation Client Protocol (PCEP) konfiguriert, um die externe Pfadberechnung durch einen PCE zu erleichtern.

Weitere Informationen finden Sie unter .Komponenten des External Path Computing

Um die externe Pfadberechnung für die TE-LSPs eines PCC zu aktivieren, schließen Sie die Anweisung auf der Hierarchieebene und ein.lsp-external-controller pccd[edit mpls][edit mpls lsp lsp-name]

Komponenten des External Path Computing

Die Komponenten, aus denen sich ein externes Pfadcomputersystem zusammensetzt, sind:

Element "Pfadberechnung"

Ein Pfadberechnungselement (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 den Pfad jedoch nur 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 Stateful PCE sorgt für eine strikte Synchronisierung zwischen dem PCE und dem Netzwerkstatus (in Bezug auf Topologie und Ressourceninformationen) sowie dem Satz der berechneten Pfade und reservierten Ressourcen, die im Netzwerk verwendet werden. Mit anderen Worten: Ein zustandsbehaftetes PCE nutzt bei der Verarbeitung neuer Anforderungen aus dem PCC sowohl Informationen aus der Traffic-Engineering-Datenbank als auch Informationen über vorhandene Pfade (z. B. TE-LSPs) im Netzwerk.

    Es gibt zwei Arten von zustandsbehafteten PCE:

    • Passives zustandsbehaftetes PCE: Hält die Synchronisierung mit dem PCC aufrecht und lernt die PCC-LSP-Zustände, um die Pfadberechnungen besser zu optimieren, hat aber keine Kontrolle über diese.

    • Active Stateful PCE: Ändert aktiv die PCC-LSPs und informiert sich über die PCC-LSP-Zustände.

      HINWEIS:

      In einer redundanten Konfiguration mit aktiven Haupt- und Backup-PCEs kann das aktive Stateful-PCE für die Sicherung die Attribute der delegierten LSPs erst ändern, wenn es zum Zeitpunkt eines Failovers zum Haupt-PCE wird. Im Falle eines Umstiegs gibt es keine Vorwegnahme von PCEs. Das Haupt-PCE wird durch ein Backup-PCE unterstützt, und wenn das Haupt-PCE ausfällt, übernimmt das Backup-PCE die Rolle des Haupt-PCE und bleibt das Haupt-PCE, auch wenn das PCE, das zuvor das Haupt-PCE war, wieder betriebsbereit ist.

    Ein Stateful PCE stellt folgende Funktionen zur Verfügung:

    • Bietet Offline-LSP-Pfadberechnung.

    • Löst LSP-Rerouting 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, z. B. ERO, Einrichtungspriorität und Haltepriorität.

    Ein PCE hat einen globalen Überblick über den Bandbreitenbedarf im Netzwerk und unterhält eine Datenbank mit Datenverkehrstechnik, um Pfadberechnungen durchzuführen. Es führt die Statistikerfassung von allen Routern in der MPLS-Domäne mithilfe von SNMP und NETCONF durch. Dadurch wird ein Mechanismus für die Offline-Steuerung der TE-LSPs des PCC bereitgestellt. Obwohl ein Offline-LSP-Pfadberechnungssystem in einen Netzwerkcontroller eingebettet werden kann, verhält sich der PCE wie ein vollwertiger Netzwerk-Controller, der neben den Rechenpfaden auch die Kontrolle über die TE-LSPs des PCC ermöglicht.

    Obwohl eine zustandsbehaftete PCE eine optimale Pfadberechnung und einen höheren Erfolg bei der Pfadberechnung ermöglicht, erfordert sie zuverlässige Zustandssynchronisierungsmechanismen mit potenziell erheblichem Overhead auf der Steuerungsebene und der Pflege einer großen Datenmenge in Form von Zuständen, wie im Fall eines vollständigen Netzes von TE-LSPs.

  • Zustandsloses PCE: Ein zustandsloses PCE merkt sich keinen berechneten Pfad, und jeder Satz von Anforderungen wird unabhängig voneinander verarbeitet (RFC 5440).

Client für die Pfadberechnung

Ein Path Computation Client (PCC) ist eine beliebige Client-Anwendung, die eine Pfadberechnung durch einen PCE anfordert.

Ein PCC kann mit maximal 10 PCEs gleichzeitig verbunden werden. Bei der PCC-zu-PCE-Verbindung kann es sich um eine konfigurierte statische Route oder eine TCP-Verbindung handeln, die die Erreichbarkeit herstellt. Die 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, der als LSP-Statussynchronisierung bezeichnet wird. Für die TE-LSPs, für die die externe Steuerung aktiviert ist, delegiert der PCC diese LSPs an den Haupt-PCE. Der PCC wählt als Haupt-PCE einen PCE mit der niedrigsten Prioritätsnummer oder den PCE, mit dem er sich zuerst verbindet, wenn keine Prioritätsnummer vorhanden ist.

Der PCC signalisiert einen LSP auf der Grundlage des berechneten Pfads, den er von einem PCE empfängt, erneut. Wenn die PCEP-Sitzung mit dem Haupt-PCE beendet wird, wählt der PCC einen neuen Haupt-PCE aus, und alle delegierten LSPs an den vorherigen Haupt-PCE werden an den neu verfügbaren 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 wurde und eine Reihe von Nachrichten und Objekten definiert, die zur Verwaltung von PCEP-Sitzungen und zum Anfordern und Senden von Pfaden für Multidomain-TE-LSPs verwendet werden. Zu den PCEP-Interaktionen gehören PCC-Nachrichten sowie Benachrichtigungen über spezifische Zustände im Zusammenhang mit der Verwendung eines PCE im Kontext von MPLS RSVP-TE. Wenn PCEP für die PCE-zu-PCE-Kommunikation verwendet wird, übernimmt der anfordernde PCE die Rolle eines PCC.

Zu den PCEP-Funktionen gehören also:

  • LSP-Tunnelzustandssynchronisierung zwischen PCC und einem zustandsbehafteten PCE.

  • Delegierung der Steuerung über LSP-Tunnel an ein zustandsbehaftetes 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-TEPCC und RSVP-TE

Die PCE-zu-PCC-Kommunikation wird durch das TCP-basierte PCEP ermöglicht. Der 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 der TCP-MD5-Authentifizierung gemäß RFC 5440 sichern. Um den MD5-Sicherheitsmechanismus für eine PCEP-Sitzung zu aktivieren, wird empfohlen, den MD5-Authentifizierungsschlüssel auf Hierarchieebene für eine PCEP-Sitzung zu definieren und zu binden.[edit protocols pcep pce pce-id] Sie können aber auch einen vordefinierten Schlüsselbund aus der Hierarchieebene verwenden, um eine PCEP-Sitzung abzusichern.[edit security authentication-key-chains key-chain] In diesem Fall sollten Sie den vordefinierten Schlüsselbund auf Hierarchieebene in die PCEP-Sitzung binden.[edit protocols pcep pce pce-id]

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

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

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

  1. LSP-Statussynchronisierung: Der PCC sendet Informationen über alle LSPs (lokal und extern) an alle verbundenen PCEs. Bei externen Sprachdienstleistern sendet der PCC Informationen über jede Konfigurationsänderung, RRO-Änderung, Zustandsänderung usw. an den PCE.

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

    HINWEIS:

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

  2. LSP-Delegierung: Nachdem die LSP-Statusinformationen synchronisiert wurden, delegiert der PCC die externen LSPs an ein PCE, das aktive aktive zustandsbehaftete PCE. Nur das Haupt-PCE kann Parameter für den externen LSP einstellen. Zu den Parametern, die der Haupt-PCE ändert, gehören Bandbreite, Pfad (ERO) und Priorität (Einrichtung und Halten). Die in der lokalen Konfiguration angegebenen Parameter werden durch die Parameter überschrieben, die von der Haupt-PCE festgelegt werden.

    HINWEIS:

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

    Bei PCE-initiierten LSPs erstellt der PCC den LSP mit den Parametern, die er vom PCE erhält. 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 für die 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 – und –, um eine Unterbrechung der Dienste zu vermeiden.delegation cleanup timeoutlsp cleanup timer Während dieser Zeit kann ein aktiver zustandsbehafteter PCE die Kontrolle über die LSPs übernehmen, die vom ausgefallenen PCE bereitgestellt wurden, indem er eine Erstellungsanforderung für den LSP sendet.

    Die Kontrolle über PCE-initiierte LSPs wird nach Ablauf der .delegation cleanup timeout Wenn der PCE abläuft und kein anderer PCE die Kontrolle über den LSP vom fehlgeschlagenen PCE übernommen hat, übernimmt der PCC die lokale Kontrolle über den nicht delegierten, von PCE initiierten LSP.delegation cleanup timeout Wenn später der ursprüngliche oder ein neuer aktiver zustandsbehafteter PCE die Kontrolle über die lokal gesteuerten PCE-initiierten LSPs übernehmen möchte, delegiert der PCC diese LSPs an den PCE, und der Timer wird gestoppt.lsp cleanup timer

    Ein PCE kann die Delegierung des PCE-initiierten LSP an den PCC zurückgeben, um die LSP-Übertragung zwischen PCEs zu ermöglichen. Dies löst die für den PCE-initiierten LSP aus.lsp cleanup timer Der PCC wartet, bis der LSP-Bereinigungstimer abgelaufen ist, bevor er die nicht delegierten, von PCE initiierten LSPs aus dem fehlgeschlagenen PCE entfernt.

    Wenn der PCE abläuft und kein anderer PCE die Kontrolle über die LSPs aus dem fehlgeschlagenen PCE erlangt hat, löscht der PCC alle LSPs, die vom fehlgeschlagenen PCE bereitgestellt wurden.lsp cleanup timer

    HINWEIS:

    In Übereinstimmung mit draft-ietf-pce-stateful-pce-09 erfolgt das Widerrufen von PCE-initiierten LSP-Delegierungen durch einen PCC nach dem Make-before-Break-Verfahren, bevor die LSPs an einen alternativen PCE delegiert werden. Ab Junos OS Version 18.1R1 muss der Wert größer oder gleich dem Wert sein, damit der PCC die LSP-Delegierungen widerrufen kann.lsp-cleanup-timerdelegation-cleanup-timeout Ist dies nicht der Fall, kann das Zeitüberschreitungsintervall für die erneute Delegierung für den PCC auf unendlich festgelegt werden, wobei die LSP-Delegierungen an diesen PCE intakt bleiben, bis der PCC bestimmte Maßnahmen ergreift, um die vom PCE festgelegten Parameter zu ändern.

  3. LSP-Signalisierung: Beim Empfang eines oder mehrerer LSP-Parameter vom aktiven Stateful-Haupt-PCE signalisiert der PCC den TE-LSP basierend auf dem von PCE bereitgestellten Pfad erneut. Wenn der PCC den LSP nicht einrichten kann, benachrichtigt er 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 aufweist, bei denen nur die Pfadendpunkte angegeben sind, führt der PCC kein lokales, einschränkungsbasiertes Routing durch, um den vollständigen Satz von Hops zu ermitteln. Stattdessen stellt der PCC RSVP den von PCE bereitgestellten Pfad für die Signalisierung zur Verfügung, und der Pfad wird mithilfe des IGP-Hop-by-Hop-Routings eingerichtet.

Unter Berücksichtigung der in verwendeten Topologie wird die partielle clientseitige PCE-Implementierung im MPLS RSVP-TE-fähigen Netzwerk veranschaulicht.Abbildung 2Abbildung 4 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.

Das PCE hat einen globalen Überblick über den Bandbreitenbedarf im Netzwerk und führt externe Pfadberechnungen durch, nachdem es die Traffic-Engineering-Datenbank nachgeschlagen hat. Der aktive zustandsbehaftete PCE ändert dann ein oder mehrere LSP-Attribute und sendet eine Aktualisierung an den PCC. Der PCC verwendet die Parameter, die er vom PCE empfängt, um den LSP erneut zu signalisieren.

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

Auf diese Weise bietet das Stateful PCE einen kooperativen Betrieb verteilter Funktionalität, der verwendet wird, um spezifische Herausforderungen einer kürzesten Interdomain-Constrained-Path-Berechnung zu bewältigen. Es eliminiert Überlastungsszenarien, in denen Datenverkehrsströme ineffizient auf verfügbare Ressourcen abgebildet werden, was zu einer Überauslastung einiger Teilmengen von Netzwerkressourcen führt, während andere Ressourcen nicht ausgelastet sind.

LSP-Verhalten mit externem Computing

LSP-Typen

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

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

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

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

    Der PCC sendet solche LSP-Statusberichte nur dann an das PCE, wenn eine Rekonfiguration stattgefunden hat oder wenn sich der ERO, RRO oder Status der PCE-gesteuerten LSPs unter externer Kontrolle ändert.

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

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

    • Parameter, die von einem PCE überschrieben werden. Zu diesen Parametern gehören Bandbreite, Pfad und Priorität (Setup- und Hold-Werte). Wenn der Steuerungsmodus von extern zu lokal wechselt, werden die CLI-konfigurierten Werte für diese Parameter bei der nächsten Gelegenheit angewendet, um den LSP erneut zu signalisieren. Die Werte werden nicht sofort angewendet.

  • Extern bereitgestellte LSPs (oder PCE-initiierte LSPs): Die LSPs, für die die Anweisung konfiguriert ist, werden als PCE-initiierte LSPs bezeichnet.lsp-provisioning 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 mit den vom PCE bereitgestellten Parametern 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öheren Versionen bereitgestellt.

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

Die CLI-gesteuerten LSPs und die 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 stehen alle PCE-gesteuerten Sprachdienstleister unter externer Steuerung. Wenn ein Sprachdienstleister von außen gesteuert wird, verwendet der Sprachdienstleister die von PCE bereitgestellten Parameter, um den Sprachdienstleister einzurichten.

  • Lokal: Ein PCE-gesteuerter LSP kann unter lokale Kontrolle kommen. Wenn der LSP von der externen Steuerung zur lokalen Steuerung wechselt, erfolgt die Pfadberechnung mithilfe der CLI-konfigurierten Parameter und des einschränkungsbasierten Routings. Eine solche Umschaltung erfolgt nur, wenn es einen Auslöser gibt, um den LSP neu zu signalisieren. Bis dahin verwendet der 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 standardmäßigen externen Steuerungsmodus zur lokalen Steuerung, wenn z. B. keine Verbindung zu einem PCE besteht oder wenn ein PCE die Delegierung von LSPs an den PCC zurückgibt.

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

Unterstützte Konfigurationsanweisungen für externes Computing

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

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

Unterstützung für PCE-gesteuerte LSP

Anwendbare LSP-Konfigurationsanweisungen

Anwendbare 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

  • am wenigsten gefüllt

  • Meist-Füllung

  • Zufällige

  • admin-gruppe

  • admin-gruppen

  • admin-gruppe-erweitert

  • hop-limit

  • Kein CSPF

  • Smart-Optimize-Timer

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

HINWEIS:

Änderungen an der lokalen Konfiguration mithilfe der CLI, während der LSP unter der Kontrolle eines zustandsbehafteten PCE steht, haben keine Auswirkungen auf den LSP. Diese Änderungen treten erst 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-nächster-hop

Die übrigen LSP-Konfigurationsanweisungen gelten auf die gleiche Weise 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 angibt, wann die konfigurierten Parameter wirksam werden.

PCE-gesteuerter LSP-Schutz

Die Schutzpfade, einschließlich Fast Reroute und Bypass LSPs, werden lokal vom PCC mithilfe von Constraint-basiertem Routing berechnet. Ein zustandsbehafteter PCE gibt nur den primären Pfad (ERO) an. Ein PCE kann auch einen sekundären Nicht-Standby-Pfad auslösen, selbst wenn die lokale Konfiguration nicht über einen sekundären Nicht-Standby-Pfad für den LSP-Schutz verfügt.

PCE-gesteuerter LSP ERO

Für PCE-gesteuerte LSPs (PCC-delegated 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 zwei neue Pfadberechnungstypen für die PCE-gesteuerten LSPs eingeführt:external cspf und .local cspfno cspf

  • —Ein PCC verwendet den Berechnungstyp nur, wenn der PCE eine TLV des Juniper Vendor (Unternehmensnummer:local cspflocal cspf 0x0a4c) vom Typ 5.

  • no cspf—Weder die PCE noch die PCC führen eine Berechnung des beschränkten Pfads durch. Die Endpunkte und Einschränkungen werden dem RSVP-Modul zum Einrichten des LSP mit dem IGP-Pfad übergeben.

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

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

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

    • Wenn der PCE TLV nicht mit einem leeren ERO oder losem ERO sendet (mit losem Bit, das im ERO-Objekt festgelegt ist).local cspf

Mit diesen neuen Berechnungstypen kann ein PCC ein ERO-Objekt entweder als loses ERO oder als leeres ERO akzeptieren. Eine externe Pfadberechnungseinheit, 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 loses ERO verwendet und der einzuschlagende Weg wird vom PCC festgelegt.

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 den PCE zur LSP-Statussynchronisierung. Dazu gehören PCC-gesteuerte, PCE-delegierte und PCE-initiierte Punkt-zu-Punkt-LSPs. Ab Junos OS Version 15.1F6 und 16.1R1 wird diese Funktion auch auf die Berichterstellung von Point-to-Multipoint-LSPs ausgeweitet. Bei einem PCE ähnelt der Punkt-zu-Mehrpunkt-LSP dem von RSVP-Punkt-zu-Multipunkt-LSP, wobei der Punkt-zu-Mehrpunkt-LSP als Sammlung von Punkt-zu-Punkt-LSPs behandelt wird, die unter einem Punkt-zu-Mehrpunkt-Bezeichner gruppiert sind.

Standardmäßig wird die PCE-Steuerung von Punkt-zu-Mehrpunkt-LSPs auf einem PCC nicht unterstützt. Um diese Funktion hinzuzufügen, schließen Sie die Anweisung auf der Hierarchieebene oder ein.p2mp-lsp-report-capability[edit protocols pcep pce pce-name][edit protocols pcep pce-group group-id] Nachdem die Punkt-zu-Mehrpunkt-Berichtsfunktion auf einem PCC konfiguriert wurde, kündigt der PCC diese Funktion dem PCE an. Wenn der PCE im Gegenzug dieselbe Punkt-zu-Mehrpunkt-Berichtsfunktion ankündigt, meldet der PCC den vollständigen Punkt-zu-Mehrpunkt-LSP-Baum an den PCE zur LSP-Statussynchronisierung.

Ein PCC mit der Point-to-Multipoint-TE-LSP-Funktion unterstützt die Berichterstellung von Point-to-Multipoint-TE-LSPs für zustandsbehaftete PCEs, Punkt-zu-Multipoint-Updates und LSP-Datenbanken, die Point-to-Multipoint-LSP-Namen als Schlüssel unterstützen. Die folgenden Features und Funktionen werden jedoch für Junos OS Version 15.1F6 und 16.1 nicht unterstützt:

  • Statische Punkt-zu-Mehrpunkt-Sprachdienstleister

  • PCE-delegierte und PCE-initiierte Punkt-zu-Multipoint-LSPs

  • Automatische Bandbreite

  • TE++

  • PCE-Anfrage und Antwortnachricht

  • Erstellung von Punkt-zu-Mehrpunkt-Sprachdienstleistern mithilfe von Vorlagen

  • Konfigurieren der Vorwärtseingabe auf den PCE-initiierten Punkt-zu-Mehrpunkt-LSPs

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

PCE-initiierte Punkt-zu-Punkt-LSPs

Ab Junos OS Version 16.1 wird die PCEP-Funktionalität erweitert, damit ein Stateful PCE Traffic Engineering-LSPs über einen PCC initiieren und bereitstellen kann. Zuvor wurden die Sprachdienstleister auf dem PCC konfiguriert, und der PCC delegierte die Kontrolle über die externen Sprachdienstleister an einen PCE. Das Eigentum des LSP-Staates wurde von der PCC beibehalten. Mit der Einführung der PCE-initiierten LSPs kann ein PCE einen Punkt-zu-Punkt-LSP für das Traffic Engineering dynamisch initiieren und bereitstellen, ohne dass ein lokal konfigurierter LSP auf dem PCC erforderlich ist. Beim Empfang einer PCCreate-Nachricht von einem PCE erstellt der PCC den PCE-initiierten LSP und delegiert den LSP automatisch an den PCE.

Standardmäßig lehnt ein PCC die Anforderung zur Bereitstellung von PCE-initiierten Punkt-zu-Punkt-LSPs von einem PCE ab. Um die Unterstützung von PCE-initiierten LSPs auf dem PCC zu aktivieren, schließen Sie die lsp-provisioning-Anweisung auf den Hierarchieebenen or ein.https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/lsp-provisioning-edit-protocols-pcep-pce.html[edit protocols pcep pce pce-id][edit protocols pcep pce-group group-id]

Ein PCC gibt an, dass er PCE-initiierte Punkt-zu-Punkt-LSPs unterstützen kann, während die PCEP-Sitzung (Path Computation Element Protocol) mit dem PCE eingerichtet wird. Ein PCE wählt einen PCC mit dieser Fähigkeit aus, um einen LSP zu initiieren. Der PCE versorgt den PCC mit den PCE-initiierten LSP-Parametern. Nach dem Empfang der PCE-initiierten Punkt-zu-Punkt-LSP-Parameter richtet der 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 der PCC zu konfigurieren, schließen Sie die label-switched-path-template-Anweisung auf Hierarchieebene ein.label-switched-path-template[edit protocols mpls lsp-external-controller lsp-external-controller]

Wenn eine PCEP-Sitzung beendet wird, startet der PCC zwei Timer, ohne die PCE-initiierten LSPs sofort zu löschen – und –, um eine Unterbrechung der Dienste zu vermeiden.delegation cleanup timeoutlsp cleanup timer Während dieser Zeit kann ein aktiver zustandsbehafteter PCE die Kontrolle über die LSPs übernehmen, die vom ausgefallenen PCE bereitgestellt wurden.

Ein PCE kann die Delegierung des PCE-initiierten Punkt-zu-Punkt-LSP an den PCC zurückgeben, um die LSP-Übertragung zwischen PCEs zu ermöglichen. Die Kontrolle über PCE-initiierte LSPs wird nach Ablauf des Timeouts für die Delegierungsbereinigung auf die PCC zurückgesetzt. Wenn das Timeout für die Delegierungsbereinigung abläuft und kein anderer PCE die Kontrolle über den LSP des fehlgeschlagenen PCE erlangt hat, übernimmt der PCC die lokale Kontrolle über den nicht delegierten, von PCE initiierten LSP. Wenn später der ursprüngliche oder ein neuer aktiver zustandsbehafteter PCE die Kontrolle über die lokal gesteuerten PCE-initiierten Punkt-zu-Punkt-LSPs übernehmen möchte, delegiert der PCC diese LSPs an den PCE, und der LSP-Bereinigungstimer wird gestoppt.

Der PCC wartet, bis der LSP-Bereinigungstimer abgelaufen ist, bevor er die nicht delegierten, von PCE initiierten Punkt-zu-Punkt-LSPs aus dem fehlgeschlagenen PCE löscht. Wenn der LSP-Bereinigungstimer abläuft und kein anderer PCE die Kontrolle über die LSPs aus dem ausgefallenen PCE erlangt hat, löscht der PCC alle LSPs, die vom fehlgeschlagenen PCE bereitgestellt wurden.

Ab Junos OS Version 21.1R1 unterstützen wir Nonstop Active Routing (NSR) für PCE-initiierte RSVP-basierte Punkt-zu-Punkt- und Punkt-zu-Multipunkt-LSPs. Nur die primäre Routing-Engine verwaltet die PCEP-Sitzung mit dem Controller. Es synchronisiert alle RSVP-LSPs, die von PCEs initiiert wurden, einschließlich Multicast-Flussspezifikationen für alle PCE-initiierten P2MP-LSPs, mit der Backup-Routing-Engine. Während eines Switchovers wird die PCEP-Sitzung unterbrochen und wieder hergestellt, wenn die Backup-Routing-Engine zur primären Routing-Engine wird. Dadurch wird der Datenverkehrsverlust für den Datenverkehr reduziert, der über PCE-initiierte RSVP-LSPs während des Routing-Engine-Switchovers übertragen wird. Diese Funktion wird aktiviert, wenn NSR konfiguriert ist.

PCE-initiierte Bypass-LSP

Grundlegendes zu PCE-initiierten Bypass-LSPs

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

Junos OS Version 19.2R1 und spätere Versionen bieten teilweise Unterstützung für den Internet-Entwurf draft-cbrt-pce-stateful-local-protection-01 (läuft im Dezember 2018 ab), PCEP Extensions for RSVP-TE Local-Protection with PCE-Stateful, bei dem die PCEP-Funktionalität erweitert wird, um einem zustandsbehafteten PCE das Initiieren, Bereitstellen und Verwalten von Umgehungs-LSPs für eine geschützte Schnittstelle zu ermöglichen. 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 Umgehungs-LSP kleiner ist als die Gesamtbandbreite der primären LSPs, die möglicherweise geschützt werden.

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

Die Reihe von Operationen, die zum Ausführen von Betriebsumgehungs-LSPs verwendet werden, z. B . , kann auch für die PCE-initiierten Umgehungs-LSPs ausgeführt werden.clear rsvp session Sie können Befehle wie und verwenden, um PCE-initiierte Umgehungs-LSP-Statistiken anzuzeigen.show path-computation-client status extensiveshow path-computation-client lsp

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

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

    • kann für den Link- oder Knotenschutz dienen.

    • muss eine Bandbreite ungleich Null haben.

    • muss eine spezifizierte strikte ERO haben.

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

  • Überbelegung der Umgehungs-LSP-Bandbreite für die Zugangssteuerung der primären LSPs. Dabei muss es sich um einen Parameter pro Umgehung handeln, der die Aktualisierung des Abonnements pro Umgehungs-LSP ermöglichen sollte.

Vorteile der PCE-initiierten 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 Diversitätsanforderungen, wie z. B. die Bereitstellung diverser Pfade für Sprachdienstleister sowie ihrer lokalen Schutzpfade.

  • Stellen Sie sicher, dass Links bei Fehlerereignissen nicht überlastet werden.

Verhalten von PCE-initiierten Bypass-LSPs bei PCEP-Sitzungsfehlern

Zum Zeitpunkt eines PCEP-Sitzungsfehlers werden die PCE-initiierten Umgehungs-LSPs bis zum Ablauf des Zeitüberschreitungstimers für den Status verwaist. Die PCE-initiierten Bypass-LSPs werden nach Ablauf des Status-Timeout-Timers bereinigt. Um die Steuerung eines PCE-initiierten Bypass-LSP zu erhalten (nachdem eine PCEP-Sitzung fehlgeschlagen ist), sendet ein PCE (entweder das primäre PCE oder ein sekundäres PCE) vor Ablauf des Zeitüberschreitungstimers für den Status eine PCInitiate-Nachricht.

PCE-initiierte Punkt-zu-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 das Timing und die Reihenfolge der Punkt-zu-Mehrpunkt-Pfadberechnungen innerhalb und zwischen PCEP-Sitzungen (Path Computation Element Protocol) 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 Punkt-zu-Multipunkt-LSPs.Grundlegendes zum Path Computation Element Protocol für MPLS RSVP-TE mit Unterstützung für PCE-initiierte Punkt-zu-Mehrpunkt-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 sowohl für MPLS- als auch für IPv6-Weiterleitungsebene. Segment-Routing für PCEP unterstützt SR-LSPs wie PCE-initiierte, lokal erstellte und delegierte SR-LSPs in IPv6-Weiterleitungsebene.

Vorteile von SRv6-LSPs in PCEP

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

PCEP unterstützt das Erstellen, Aktualisieren und Löschen von PCE-initiierten farbigen und ungefärbten SRv6-LSPs. Wenn PCE-initiierte SRv6-LSP zusammen mit einer statischen SRv6-LSP für dieselbe IP- oder farbbasierte IP-Adresse existiert, wird die statische SRv6-TE-LSP-Beitragsroute der PCE-initiierten SRv6-TE-LSP-Beitragsroute vorgezogen.

Um eine PCEP-Sitzung so zu konfigurieren, dass sie SRv6-fähig ist, müssen Sie die Konfigurationsanweisung auf den Hierarchieebenen [edit protocols pcep pce pce-id] oder [] aktivieren.srv6-capabilityedit protocols pcep pce-group pce-id Wenn die Konfigurationsanweisung aktiviert ist, müssen Sie auch die Konfigurationsanweisung srv6 auf der Hierarchieebene [] aktivieren, da sonst während des Commits ein Fehler angezeigt wird.srv6-capabilityedit protocols source-packet-routing

Um SRv6 für SR-TE zu konfigurieren, müssen Sie die Konfigurationsanweisung srv6 auf der Hierarchieebene [edit protocols source-packet-routing] hinzufügen.

[Weitere Informationen finden Sie unter Grundlegendes zur SR-TE-Richtlinie für den SRv6-Tunnel .https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/topic-map/bgp-egress-traffic-engineering.html#id_unb_hnk_1rb

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

Automatische Bandbreite und PCE-gesteuerter LSP

Ab Junos OS Version 14.2R4 wird die automatische Bandbreite für PCE-gesteuerte LSPs unterstützt. In früheren Versionen galt die Option für die automatische Bandbreite nicht für PCE-gesteuerte LSPs, obwohl LSPs unter der Kontrolle von Auto-Bandwdith und Constraint-basiertem 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 zu lokal wechselte. Dies geschah z. B. in Fällen, in denen keine Verbindung zu einem PCE bestand oder wenn ein PCE die Delegation von Sprachdienstleistern an den PCC zurückgab.

TCP-MD5-Authentifizierung für PCEP-Sitzungen

Ein zustandsbehafteter PCE-Server automatisiert die Erstellung von Traffic-Engineering-Pfaden über das Netzwerk, erhöht die Netzwerkauslastung und ermöglicht eine benutzerdefinierte programmierbare Netzwerkerfahrung durch die Verwendung der PCEP-Kommunikation mit einem PCC. Ein PCC sendet LSP-Berichte an einen PCE-Server, und der PCE aktualisiert oder stellt LSPs an den PCC zurück. Die Daten, die über eine PCEP-Sitzung gesendet werden, sind für einen PCE-Server von entscheidender Bedeutung, um externe Pfadberechnungen durchzuführen. Infolgedessen kann ein Angriff auf die PCEP-Kommunikation die Netzwerkdienste unterbrechen. Wenn geänderte PCEP-Nachrichten an einen PCC gesendet werden, können ungeeignete LSPs eingerichtet werden. Wenn geänderte PCEP-Nachrichten an einen PCE gesendet werden, lernt der PCE eine falsche Ansicht des Netzwerks.

In Anbetracht der Bedeutung der PCEP-Kommunikation zwischen einem PCE und einem PCC für die effektive Ausführung der PCE-Funktionalitäten führt Junos OS Version 16.1 die Funktion zum Sichern einer PCEP-Sitzung mithilfe der TCP-MD5-Authentifizierung gemäß RFC 5440 ein. Diese Funktion schützt die Kommunikation zwischen einem PCE und einem PCC über eine PCEP-Sitzung, die einem Angriff ausgesetzt sein und Netzwerkdienste unterbrechen kann.

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

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

  • Verwenden des MD5-Authentifizierungsschlüssels:

  • Verwenden eines vordefinierten Authentifizierungsschlüsselbunds:

Damit sichere PCEP-Sitzungen erfolgreich eingerichtet werden können, sollte 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 Authentizität 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 erstmalige Anwendung des Sicherheitsmechanismus auf eine PCEP-Sitzung führt dazu, dass die Sitzung zurückgesetzt wird.

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

  • Diese Funktion bietet keine Unterstützung für Sitzungsauthentifizierungsmechanismen.

  • Um den von der PCEP-Sitzung verwendeten Authentifizierungsschlüsselbund anzuzeigen, verwenden Sie die Befehlsausgaben und .show path-computation-client statusshow protocols pcep

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

  • Die Funktion des Schlüsselbunds kann mithilfe der Befehlsausgabe überprüft werden.show security keychain detail

Auswirkungen der clientseitigen PCE-Implementierung auf die Netzwerkleistung

Die Wartung einer zustandsbehafteten Datenbank kann nicht trivial sein. In einer einzelnen zentralisierten PCE-Umgebung muss sich ein zustandsbehaftetes PCE lediglich alle TE-LSPs merken, die der PCE berechnet hat, die tatsächlich eingerichteten TE-LSPs (sofern dies bekannt ist) und wann die TE-LSPs abgerissen wurden. Diese Anforderungen verursachen jedoch einen erheblichen Overhead der Kontrollprotokolle in Bezug auf Status, Netzwerknutzung und -verarbeitung sowie die globale Optimierung der Verbindungen im gesamten Netzwerk. Zu den Bedenken einer zustandsbehafteten PCE-Implementierung gehören daher:

  • Jeder zuverlässige Synchronisationsmechanismus führt zu einem erheblichen Overhead der Steuerungsebene. PCEs können den Zustand synchronisieren, indem sie miteinander kommunizieren, aber wenn TE-LSPs mit verteilten Berechnungen eingerichtet werden, die zwischen mehreren PCEs durchgeführt werden, werden die Probleme der Synchronisierung und der Vermeidung von Race Conditions größer und komplexer.

  • Die Out-of-Band-Synchronisierung von Traffic-Engineering-Datenbanken kann komplex sein, da mehrere PCEs in einem verteilten PCE-Berechnungsmodell eingerichtet sind, und kann anfällig für Racebedingungen, Skalierbarkeitsprobleme usw. sein.

  • Pfadberechnungen, die den Gesamtstatus des Netzwerks einbeziehen, sind sehr komplex, selbst wenn das PCE detaillierte Informationen zu allen Pfaden, Prioritäten und Layern hat.

Trotz der oben genannten Bedenken ist die teilweise clientseitige Implementierung des Stateful PCE in großen verkehrstechnischen Systemen äußerst effektiv. Es bietet eine schnelle Konvergenz und erhebliche Vorteile im Hinblick auf eine optimale Ressourcennutzung, indem es die Voraussetzungen für die globale Sichtbarkeit eines TE LSP-Status und für eine geordnete Steuerung von Pfadreservierungen für alle Geräte innerhalb des zu steuernden Systems erfüllt.

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

In diesem Beispiel wird gezeigt, wie die externe Pfadberechnung durch ein Path Computation Element (PCE) für Traffic Engineering Label-Switched Paths (TE LSPs) auf einem Path Computation Client (PCC) aktiviert wird. Außerdem wird gezeigt, wie das Path Computation Element Protocol (PCEP) auf dem PCC konfiguriert wird, um die PCE-zu-PCC-Kommunikation zu ermöglichen.

Anforderungen

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

  • Drei Router, bei denen es sich um 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 Transportroutern der PTX-Serie handeln kann, von denen einer als PCC konfiguriert ist.

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

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

HINWEIS:

Das JSDN-Add-on-Paket muss zusammen mit dem Junos OS-Kerninstallationspaket 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 partielle clientseitige Implementierung der Stateful PCE-Architektur basiert auf Version 2 des Internet-Entwurfs draft-ietf-pce-stateful-pce. Ab Junos OS Version 16.1 wird diese Implementierung auf die Unterstützung von Version 7 aktualisiert, wie im Internetentwurf 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, auf dem eine frühere Version ausgeführt wird, und einem zustandsbehafteten PCE-Server, der dem Internet-Entwurf draft-ietf-pce-stateful-pce-07 entspricht, führt.

Um die Berechnung externer Pfade durch eine PCE zu ermöglichen, fügen Sie die Anweisung auf der PCC auf der Hierarchieebene und ein.lsp-external-controller[edit mpls][edit mpls lsp lsp-name]

Ein mit der Anweisung konfigurierter LSP wird als PCE-gesteuerter LSP bezeichnet und steht standardmäßig unter der externen Steuerung eines PCE.lsp-external-controller Ein aktives Stateful PCE kann die in 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 PCE-zu-PCC-Kommunikation zu ermöglichen, konfigurieren Sie PCEP auf dem PCC auf 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 Junos OS-Kerninstallationspaket installiert werden.

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

  • Ein PCC kann eine Verbindung zu maximal 10 zustandsbehafteten PCEs herstellen. Zu einem bestimmten Zeitpunkt kann es nur einen Haupt-PCE geben (den PCE mit dem niedrigsten Prioritätswert oder den PCE, der zuerst eine Verbindung zum PCC herstellt, wenn keine PCE-Priorität vorhanden ist), an den der PCC LSPs für die Pfadberechnung delegiert.

  • Bei Junos OS Version 12.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 z. B. LSP-Schutz und Make-before-Break, funktionieren für PCE-gesteuerte LSPs.

  • Die Option für die automatische Bandbreite ist für PCE-gesteuerte LSPs deaktiviert, obwohl LSPs unter der Kontrolle von Auto-Bandwdith und Constraint-basiertem Routing mit PCE-gesteuerten LSPs koexistieren können.

  • Auf PCE-gesteuerte LSPs kann von anderen CLI-Konfigurationen verwiesen werden, z. B. lsp-nexthop zu Routen, Weiterleitungs-Adjacencies, CCC-Verbindungen und logische Tunnel.

  • PCE-gesteuerte Sprachdienstleister unterstützen GRES nicht.

  • PCE-gesteuerte Sprachdienstleister unter logischen Systemen werden nicht unterstützt.

  • PCE-gesteuerte LSPs können keine Punkt-zu-Mehrpunkt-LSPs sein.

  • Bidirektionale Sprachdienstleister werden nicht unterstützt.

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

  • PCE-gesteuerte Sprachdienstleister sind von externen Pfadberechnungen abhängig, die sich auf die Gesamteinrichtungszeit, Umleitungen und Make-before-Break-Funktionen auswirken.

  • Die Einrichtungszeit und Konvergenzzeit (Reroute, MBB) für vorhandene LSPs ist die gleiche wie in früheren Versionen, sofern keine PCE-gesteuerten LSPs vorhanden sind. Ein geringer Einfluss ist jedoch in Gegenwart von PCE-kontrollierten LSPs zu beobachten.

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

Topologie

Abbildung 5: PCEP für MPLS RSVP-TE konfigurierenPCEP für MPLS RSVP-TE konfigurieren

In diesem Beispiel ist PCC der Eingangsrouter, der eine Verbindung mit dem externen, aktiven, zustandsbehafteten PCE herstellt.

Die externen Sprachdienstleister des Routers PCC werden wie folgt berechnet:

  1. Router PCC empfängt die LSP-Tunnelkonfiguration, die über die CLI eingerichtet wurde. Unter der Annahme, dass die empfangene Konfiguration mit externem Pfad-Computing aktiviert ist, erkennt Router PCC, 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 und von Router PCC auf Router R2 eingerichtet.PCC-to-R2 Die CLI-konfigurierte ERO für ist PCC-R0-R1-R2.PCC-to-R2 Die Bandbreite beträgt 10 m, und sowohl die Setup- als auch die Hold-Priorität betragen 4.PCC-to-R2

  2. Router PCC versucht, die PCE-gesteuerten LSP-Attribute abzurufen. Dazu sendet der Router PCC eine PCRpt-Nachricht an den Stateful PCE, die besagt, 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 den Router PCC.

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

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

  5. Router PCC sendet einen PCRpt mit dem neuen RRO an das Stateful PCE.

Konfiguration

CLI-Schnellkonfiguration

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

PCC

R0

R1

R2

R3

Verfahren

Schritt-für-Schritt-Anleitung

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

So konfigurieren Sie Router PCC:

HINWEIS:

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

  1. Konfigurieren Sie die Schnittstellen.

    Um MPLS zu aktivieren, schließen Sie die Protokollfamilie in die Schnittstelle ein, damit die Schnittstelle eingehenden MPLS-Datenverkehr nicht verwirft.

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

  3. Konfigurieren Sie den Label-Switched-Pfad (LSP) von Router PCC zu Router R2 und aktivieren Sie die externe Steuerung von LSPs durch den PCE.

  4. Konfigurieren Sie den LSP von Router PCC auf Router R2, der über eine lokale Steuerung verfügt und von den von PCE bereitgestellten LSP-Parametern überschrieben wird.

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

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

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

  8. Konfigurieren Sie den Zielport für den Router PCC, der über TCP-basiertes PCEP eine Verbindung zu einem PCE herstellt.

  9. Konfigurieren Sie den PCE-Typ.

Ergebnisse

Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie die Befehle und eingeben.show interfacesshow protocols Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Wenn Sie mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf .commit

Überprüfung

Vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.

Überprüfen des PCEP-Sitzungsstatus

Zweck

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

Was

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

Bedeutung

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

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

Die Statistik von gibt die Anzahl der Nachrichten an, die vom Router PCC an den PCE gesendet werden, um den aktuellen Status der LSPs zu melden.PCRpts Die Statistik gibt die Anzahl der Nachrichten an, die der Router PCC vom PCE empfangen hat.PCUpdates Die Meldungen enthalten die PCE-modifizierten Parameter für die PCE-gesteuerten LSPs.PCUpdates

Überprüfen des PCE-gesteuerten LSP-Status bei externer LSP-Steuerung

Zweck

Überprüfen Sie den Status des PCE-gesteuerten LSP von Router PCC zu Router R2, wenn der LSP unter externer Steuerung steht.

Was

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

Bedeutung

In der Ausgabe zeigen die Felder und output an, dass der LSP extern gesteuert wird.LSPtypeLSP Control Status Die Ausgabe zeigt auch ein Protokoll der PCEP-Meldungen, die zwischen Router PCC und PCE gesendet werden.

Die PCEP-Sitzung zwischen dem PCE und dem Router-PCC ist aktiv, und der Router-PCC empfängt die folgenden PCE-gesteuerten LSP-Parameter:

  • ERO (Pfad): 20.31.4.2 und 20.31.5.2

  • Bandbreite: 8 Mbit/s

  • Prioritäten—3 3 (Setup- und Hold-Werte)

Überprüfen 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 das LSP-Steuerelement lokal wird.

Was

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

Bedeutung

In der Ausgabe zeigt das Ausgabefeld an, dass der LSP unter lokaler Kontrolle steht.LSP Control Status Obwohl der PCE-gesteuerte LSP unter lokaler Kontrolle steht, verwendet der Router-PCC weiterhin die von PCE bereitgestellten Parameter, bis die LSP bei der nächsten Gelegenheit erneut signalisiert wird.

Die Ausgabe zeigt nun die LSP-Parameter an, die mithilfe der CLI konfiguriert wurden, zusammen mit den von PCE bereitgestellten Parametern, die zum Festlegen des LSP als tatsächlich verwendete Werte verwendet wurden.

  • Bandbreite: 10 Mbit/s (TatsächlichBandbreite: 8 Mbit/s)

  • Prioritäten—4 4 (Ist-Prioritäten 3 3)

Auf dem Auslöser zum erneuten Signalisieren des LSP verwendet Router PCC die lokalen Konfigurationsparameter, um den PCE-gesteuerten LSP einzurichten.

Das ist 20.31.1.2, 20.31.2.2 und 20.31.8.2.Computed ERO Der PCE-gesteuerte LSP wird über die lokalen Konfigurationsparameter aufgebaut.

Beispiel: Konfigurieren des Path Computation Element Protocol für MPLS RSVP-TE mit Unterstützung von PCE-initiierten Punkt-zu-Punkt-LSPs

In diesem Beispiel wird gezeigt, wie der Path Computation Client (PCC) so konfiguriert wird, dass er die von PCE (Path Computation Element) initiierten Point-to-Point-Label-Switched-Pfade (LSPs) unterstützt.

Anforderungen

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

  • Drei Router, bei denen es sich um eine Kombination aus Routern der ACX-Serie, M-Serie, MX-Serie oder T-Serie handeln kann.

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

  • Junos OS Version 16.1 oder höher, das 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, damit ein Stateful PCE Traffic Engineering-LSPs über einen PCC initiieren und bereitstellen kann. Zuvor wurden die Sprachdienstleister auf dem PCC konfiguriert, und der PCC delegierte die Kontrolle über die externen Sprachdienstleister an einen PCE. Das Eigentum des LSP-Staates wurde von der PCC beibehalten. Mit der Einführung der PCE-initiierten LSPs kann ein PCE einen Punkt-zu-Punkt-LSP für das Traffic Engineering dynamisch initiieren und bereitstellen, ohne dass ein lokal konfigurierter LSP auf dem PCC erforderlich ist. Beim Empfang einer PCCreate-Nachricht von einem PCE erstellt der 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 einen PCC die folgenden Überlegungen:

  • Junos OS Version 13.3 unterstützt nur zustandsbehaftete PCEs.

  • Bei 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 z. B. LSP-Schutz und Make-before-Break, funktionieren für PCE-initiierte LSPs.

  • PCE-initiierte Sprachdienstleister unterstützen keine ordnungsgemäße Routing-Engine-Umschaltung (Graceful Routing Engine Switchover, GRES).

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

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

  • Bidirektionale Sprachdienstleister 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 Bindungssegment-ID-Bezeichnungen (SID) verwenden, die nicht farbigen Segment-Routing-LSPs zugeordnet sind, um die PCE-initiierten Segmentrouting-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 können verbindliche SID-Beschriftungen zugeordnet sein. Mit dieser Funktion kann der PCE diese Bindungs-SID-Bezeichnung im Label-Stack verwenden, um PCE-initiierte LSP-Pfade für das Segment-Routing bereitzustellen.

Topologie

Abbildung 6: Beispiel für einen PCE-initierten Punkt-zu-Punkt-LSP für MPLS RSVP-TEBeispiel für einen PCE-initierten Punkt-zu-Punkt-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 ein neuer Bedarf besteht, initiiert das aktive zustandsbehaftete PCE dynamisch einen LSP, um die Anforderung zu erfüllen. Da PCC so konfiguriert ist, dass es den PCE-initiierten LSP unterstützt, wird die Pfadberechnung auf PCC wie folgt ausgefü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 mit den vom PCE empfangenen Parametern ein und delegiert den PCE-initiierten LSP automatisch an den PCE, der ihn initiiert hat.

    In diesem Beispiel ist PCE1 das aktive zustandsbehaftete PCE, das den PCE-initiierten LSP auf PCC initiiert und bereitstellt. Nach Erhalt der PCE-initiierten LSP-Parameter richtet PCC den LSP ein und delegiert den PCE-initiierten LSP automatisch an PCE1.

  2. Wenn die PCEP-Sitzung zwischen PCC und PCE1 beendet wird, startet PCC zwei Timer für den PCE1-initiierten LSP: Zeitüberschreitung bei der Bereinigung der Konfiguration und der LSP-Bereinigungstimer. Während dieser Zeit kann PCE1 oder PCE2 die Kontrolle über den PCE-initiierten LSP übernehmen.

  3. Wenn PCE2 vor Ablauf des LSP-Bereinigungstimers die Kontrolle über den PCE-initiierten LSP übernimmt, delegiert PCC den PCE-initiierten LSP an PCE2, und der LSP-Bereinigungstimer und das Delegierungsbereinigungstimeout werden beendet.

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

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

Konfiguration

CLI-Schnellkonfiguration

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

PCC

R1

R2

Verfahren

Schritt-für-Schritt-Anleitung

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

So konfigurieren Sie den PCC-Router:

HINWEIS:

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

  1. Konfigurieren Sie die Schnittstellen.

    Um MPLS zu aktivieren, schließen 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 Steuerung von Sprachdienstleistern 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 Management-Schnittstelle.

  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 eine Verbindung zum PCC herstellen.

Ergebnisse

Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie die Befehle und eingeben.show interfacesshow protocols Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Wenn Sie mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf .commit

Überprüfung

Vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.

Überprüfen des PCC-Status

Zweck

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

Was

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

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 Sprachdienstleistern im PCC sowie die Anzahl der Sprachdienstleister angezeigt, die von den angeschlossenen PCEs bereitgestellt und an sie delegiert wurden.

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

Überprüfen des PCE1-Status

Zweck

Überprüfen Sie den Status des aktiven aktiven zustandsbehafteten Haupt-PCE.

Was

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

Bedeutung

Der Ausgang zeigt Informationen über das aktuell aktive Stateful PCE an, mit dem der PCC verbunden ist. Das Ausgabefeld zeigt den aktuellen Status der PCEP-Sitzung zwischen einem PCE und einem PCC an.PCE status

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

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

Zweck

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

Was

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

Bedeutung

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

Die PCEP-Sitzung zwischen PCC und PCE1 ist aktiv, und der 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 Hold-Werte)

Konfigurieren des Path Computation Element Protocol für MPLS RSVP-TE mit Unterstützung von PCE-initiierten Punkt-zu-Punkt-LSPs

Sie können einen Path Computation Client (PCC) mit der Fähigkeit konfigurieren, dynamisch erstellte Label Switched Paths (LSPs) von einer zentralisierten externen Pfadberechnungseinheit zu unterstützen. Ein Stateful Path Computaiton Element (PCE) kann verwendet werden, um externe Pfadberechnungen durchzuführen und dynamische LSPs zu generieren, wenn die Nachfrage steigt.

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

Ein CLI-gesteuerter LSP, ein PCE-gesteuerter LSP und ein 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 PCC für die Unterstützung von PCE-initiierten Punkt-zu-Punkt-LSPs zu konfigurieren:

  1. Wechseln Sie im Konfigurationsmodus auf folgende Hierarchieebene:
  2. Geben Sie die Anzahl der Nachrichten pro Minute an, die der PCC maximal empfangen kann.
  3. Geben Sie die Anzahl der extern bereitgestellten Label Switched Paths (LSPs) für alle verbundenen PCEs an, die der PCC maximal akzeptieren kann.
  4. Geben Sie die eindeutige benutzerdefinierte ID für das verbundene PCE an, um die PCE-Parameter zu konfigurieren.
  5. Geben Sie die Zeitspanne (in Sekunden) an, die der PCC warten muss, bevor er die Steuerung der LSPs an den Routingprotokollprozess zurückgibt, 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 die Zeitspanne (in Sekunden) an, die der PCC warten muss, bevor er nach dem Beenden einer PCEP-Sitzung nicht delegierte, von PCE initiierte LSPs aus dem fehlgeschlagenen PCE löscht.
  9. Konfigurieren Sie den 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 keine Begrenzung).

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

    Der Wert kann zwischen 0 und 16384 liegen, und der Standardwert ist 5. Bei einem Wert von 0 wird diese Anweisung deaktiviert.

  12. Konfigurieren Sie den PCE-Typ.
  13. Geben Sie die Zeitspanne (in Sekunden) an, die der PCC auf eine Antwort warten muss, bevor eine Anforderung erneut gesendet wird.

    Der Wert kann zwischen 0 und 65535 Sekunden liegen.

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

Beispielausgabe

Beispiel: Konfigurieren des Path Computation Element Protocol für MPLS RSVP-TE mit Unterstützung für PCE-gesteuerte Punkt-zu-Mehrpunkt-LSPs

In diesem Beispiel wird gezeigt, wie der Path Computation Client (PCC) so konfiguriert wird, dass er Point-to-Multipoint-Traffic-Engineered Label-Switched Paths (TE LSPs) an ein Path Computation Element (PCE) meldet.

Anforderungen

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

  • Drei Router, bei denen es sich um eine Kombination aus Routern der ACX-Serie, M-Serie, MX-Serie oder T-Serie handeln kann.

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

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

  • Junos OS Version 16.1 oder höher, das 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 den PCE zur LSP-Statussynchronisierung. Dazu gehören PCC-gesteuerte, PCE-delegierte und PCE-initiierte Punkt-zu-Punkt-LSPs. Ab Junos OS Version 15.1F6 und 16.1R1 wird diese Funktion auch auf die Berichterstellung von Point-to-Multipoint-LSPs ausgeweitet.

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

Topologie

Abbildung 7: Beispiel für PCE-gesteuerte Punkt-zu-Mehrpunkt-LSPsBeispiel für PCE-gesteuerte Punkt-zu-Mehrpunkt-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 wiederum mit einem PCE verbunden ist. Es gibt viele Punkt-zu-Mehrpunkt-Schnittstellen zwischen PCC, Router R1 und Router R2.

Die Berichterstellung von Punkt-zu-Mehrpunkt-LSPs erfolgt wie folgt:

  1. Wenn Router PCC mit Punkt-zu-Punkt- und Punkt-zu-Mehrpunkt-LSPs ohne Unterstützung für die Punkt-zu-Mehrpunkt-Berichtsfunktion konfiguriert ist, werden nur die Punkt-zu-Punkt-LSPs an das angeschlossene PCE gemeldet. Standardmäßig unterstützt ein PCC keine Punkt-zu-Mehrpunkt-LSP-Berichtsfunktion.

  2. Wenn Router PCC mit einer Punkt-zu-Mehrpunkt-LSP-Berichtsfunktion konfiguriert ist, kündigt PCC diese Funktion PCE zunächst über eine Berichtsnachricht an.

  3. Standardmäßig bietet ein PCE Unterstützung für die Punkt-zu-Mehrpunkt-LSP-Funktion. Nach Erhalt der Werbung des PCC für die Punkt-zu-Mehrpunkt-LSP-Fähigkeit kündigt der PCE im Gegenzug seine Fähigkeit dem PCC an.

  4. Nach Erhalt der PCE-Ankündigung der Punkt-zu-Mehrpunkt-Funktion meldet die PCC alle Zweige von Punkt-zu-Mehrpunkt-LSPs mithilfe der Aktualisierungsmeldung an die PCE.

  5. Sobald alle Sprachdienstleister an den PCE gemeldet wurden, wird der LSP-Status zwischen dem PCE und dem PCC synchronisiert.

Konfiguration

CLI-Schnellkonfiguration

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

PCC

R1

R2

R3

Verfahren

Schritt-für-Schritt-Anleitung

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

So konfigurieren Sie den PCC-Router:

  1. Konfigurieren Sie die Schnittstellen des Routers PCC. Um MPLS zu aktivieren, schließen 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 des Router PCC, mit Ausnahme der Verwaltungsschnittstelle.

  4. Aktivieren Sie MPLS auf allen Schnittstellen des 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 Punkt-zu-Mehrpunkt-LSPs, und definieren Sie eine externe Pfadberechnungsentität für den LSP.

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

  8. Konfigurieren Sie die LSPs, die über eine lokale Steuerung verfügen und von den von PCE bereitgestellten LSP-Parametern überschrieben werden.

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

  10. Weisen Sie die konfigurierten administrativen Gruppenrichtlinien den PCC-Schnittstellen des Routers zu.

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

  12. Konfigurieren Sie eine interne BGP-Gruppe.

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

  14. Konfigurieren Sie den OSPF-Bereich 0 auf allen Punkt-zu-Mehrpunkt-Schnittstellen des Routers PCC.

  15. Konfigurieren Sie den OSPF-Bereich 0 auf der Punkt-zu-Punkt-Schnittstelle des Routers PCC.

  16. Aktivieren Sie Traffic Engineering für OSPF.

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

  18. Konfigurieren Sie Router PCC so, dass die Punkt-zu-Mehrpunkt-LSP-Funktion für die Berechnung externer Pfade aktiviert wird.

  19. Konfigurieren Sie die Traffic Engineering-Richtlinie.

Ergebnisse

Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie die Befehle und eingeben.show interfacesshow protocols Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Überprüfung

Vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.

Überprüfen der LSP-Konfiguration auf dem PCC

Zweck

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

Was

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

Bedeutung

In der Ausgabe wird der LSP lsp2-pcc als PCE-gesteuerter LSP angezeigt.

Überprüfen der PCE-Konfiguration auf dem PCC

Zweck

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

Was

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

Bedeutung

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

Grundlegendes zum Path Computation Element Protocol für MPLS RSVP-TE mit Unterstützung für PCE-initiierte Punkt-zu-Mehrpunkt-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 das Timing und die Reihenfolge der Punkt-zu-Mehrpunkt-Pfadberechnungen innerhalb und zwischen PCEP-Sitzungen (Path Computation Element Protocol) steuern und so ein dynamisches Netzwerk schaffen, das zentral gesteuert und bereitgestellt wird.

Vorteile von PCE-initiierten Punkt-zu-Multipunkt-Sprachdienstleistern

Erfüllt die Anforderungen der Punkt-zu-Mehrpunkt-Traffic-Engineering-LSP-Platzierung als Reaktion auf Anwendungsanforderungen durch dynamische Erstellung und Abbau von Punkt-zu-Mehrpunkt-LSPs, wodurch ein dynamisches Netzwerk entsteht, das zentral gesteuert und bereitgestellt wird.

Signalisierung von PCE-initiierten Punkt-zu-Mehrpunkt-LSPs

Die Signalisierung von PCE-initiierten Punkt-zu-Mehrpunkt-LSPs ist wie folgt:

  • When a new branch is added (Grafting)—Nur der neue Branch-Sub-LSP wird signalisiert und führt nicht zu einer erneuten Signalisierung des gesamten Punkt-zu-Mehrpunkt-Baums.

    Wenn vor der Bereitstellung des neuen untergeordneten LSP Änderungen an der Topologie aufgetreten sind, berechnet der Path Computation Server (PCS) die gesamte Punkt-zu-Mehrpunkt-Struktur neu und aktualisiert den Punkt-zu-Mehrpunkt-LSP mithilfe einer PC-Aktualisierungsmeldung.

  • When a branch is deleted (Pruning)—Der gelöschte untergeordnete LSP der Verzweigung wird abgerissen und führt nicht zu einer erneuten Signalisierung der gesamten Punkt-zu-Mehrpunkt-Struktur.

  • When a branch sub-LSP parameter is changed—Änderungen an Sub-LSP-Parametern, wie z. B. Explicit Route Object (ERO), Bandbreite oder Priorität, können entweder aufgrund der Optimierung oder auf Benutzerwunsch erfolgen. Wenn es eine Re-Signaling-Anforderung für einen Sub-LSP gibt, wird die gesamte Punkt-zu-Multipoint-Struktur erneut signalisiert, und dann erfolgt der Switchover zur neuen Instanz, sobald die neuen Instanzen aller Branches aktiv sind.

  • When a branch sub-LSP path fails– Dem PCS wird ein Fehler für den ausgefallenen Branch-Sub-LSP gemeldet. Beim Empfang des neuen ERO vom PCS wird der gesamte Punkt-zu-Mehrpunkt-Baum zusammen mit dem ausgefallenen Branch-Sub-LSP erneut signalisiert, und der Wechsel zur neuen Instanz erfolgt nach dem Prinzip "Make-before-Break" (MBB).

Verhalten von PCE-initiierten Punkt-zu-Multipoint-LSPs nach einem PCEP-Sitzungsfehler

Wenn eine PCEP-Sitzung fehlschlägt, sind die PCE-initiierten Punkt-zu-Multipunkt-LSPs bis zum Ablauf des Timers verwaist.state timeout Nach Ablauf des Timers werden die PCE-initiierten LSPs bereinigt.state timeout

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

Konfigurieren der PCE-initiierten Punkt-zu-Multipoint-LSP-Funktion

Standardmäßig wird die Erstellung und Bereitstellung von Punkt-zu-Mehrpunkt-LSPs durch einen PCE auf einem PCC nicht unterstützt. Um diese Funktion zu aktivieren, schließen Sie die and-Anweisungen auf den Hierarchieebenen or ein.p2mp-lsp-init-capabilityp2mp-lsp-update-capability[edit protocols pcep pce pce-name][edit protocols pcep pce-group group-id]

Die Anweisung bietet die Möglichkeit, Punkt-zu-Mehrpunkt-RSVP-TE-LSPs durch einen PCE bereitzustellen.p2mp-lsp-init-capability Die Anweisung bietet die Möglichkeit, Punkt-zu-Mehrpunkt-RSVP-TE LSP-Parameter durch eine PCE zu aktualisieren.p2mp-lsp-update-capability

Unterstützte und nicht unterstützte Funktionen für PCE-initiierte Punkt-zu-Multipunkt-LSPs

Die folgenden Funktionen werden von PCE-initiierten Punkt-zu-Mehrpunkt-LSPs unterstützt:

  • Teilweise Übereinstimmung mit dem Internet-Entwurf draft-ietf-pce-stateful-pce-p2mp (läuft im Oktober 2018 ab), Path Computation Element (PCE) Protocol Extensions for Stateful PCE usage for 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 Punkt-zu-Multipoint-LSPs. Nur die primäre Routing-Engine verwaltet die PCEP-Sitzung mit dem Controller. Es synchronisiert alle RSVP-LSPs, die von PCEs initiiert wurden, einschließlich Multicast-Flussspezifikationen für alle PCE-initiierten P2MP-LSPs, mit der Backup-Routing-Engine. Während eines Switchovers wird die PCEP-Sitzung unterbrochen und wieder hergestellt, wenn die Backup-Routing-Engine zur primären Routing-Engine wird. Dadurch wird der Datenverkehrsverlust für den Datenverkehr reduziert, der über PCE-initiierte RSVP-LSPs während des Routing-Engine-Switchovers übertragen wird. Diese Funktion wird aktiviert, wenn NSR konfiguriert ist.

Die folgenden Funktionen werden von PCE-initiierten Punkt-zu-Multipunkt-LSPs nicht unterstützt:

  • Delegierung von lokal gesteuerten Punkt-zu-Mehrpunkt-LSPs.

  • Delegierung der LSP-Steuerung.

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

  • Request/Response-Nachrichten.

  • Direktes Verschieben von Branch-Sub-LSP von einem Punkt-zu-Mehrpunkt-Baum in einen anderen.

    Dasselbe kann erreicht werden, indem ein untergeordneter Verzweigungs-LSP aus der ersten Punkt-zu-Mehrpunkt-Struktur gelöscht und einer anderen erneut hinzugefügt wird, nachdem die Meldung das Entfernen des LSP vom Gerät angezeigt hat.PCReport

  • IPv6 wird nicht unterstützt.

  • SERO-basierte Signalisierung wird nicht unterstützt.

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

  • Der Linkschutz wird nicht unterstützt.

Zuordnen von PCE-initiierten Punkt-zu-Multipoint-LSPs zu MVPN

Sie können einen einzelnen oder einen Bereich von MVPN-Multicast-Flows (S,G) einem dynamisch erstellten, PCE-initiierten Punkt-zu-Multipoint-Label-Switched-Pfad (LSP) zuordnen. Sie können nur ausgewählte Typen von Schemata angeben, damit diese Funktion funktioniert. Die Themen umfassen:

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

  • (S,G), d. h. die Quelle eines Multicast-Pakets und die Adresse der Ziel-Multicast-Gruppe. Dies wird verwendet, um eingehenden Datenverkehr zu filtern und ihn dem Tunnel zuzuordnen.

  • Punkt-zu-Mehrpunkt-LSP, der zum Senden von Datenverkehr verwendet wird, der der oben genannten Datenstromspezifikation entspricht.

Weitere Informationen finden Sie unter Internet draft draft-ietf-pce-pcep-flowspec-05 (gültig bis 16. Februar 2020) PCEP Extension for Flow Specification.

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

  • Abschnitt 3.1.2 – Werbung für PCE-Fähigkeiten in IGP

  • Abschnitt 3.2 – PCReq- und PCRep-Nachricht

  • Abschnitt 7 – Die meisten Datenstromspezifikationen, mit Ausnahme der RoutenunterscheidungDie aktuelle Implementierung dieser Funktion unterstützt keine IPv4-Multicast-Datenflussspezifikationen werden nicht unterstützt.

So aktivieren Sie die Zuordnung von PCE-initiierten Punkt-zu-Mehrpunkt-LSPs zu MVPN:

  • Fügen Sie die Anweisung auf Hierarchieebene ein, um die Unterstützung für die Datenflussspezifikationsfunktion (auch als Datenverkehrssteuerung bezeichnet) durch den PCC anzugeben.pce_traffic_steering[edit protocols pcep pce pce-id]

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

    Das Vorhandensein von in der Provider-Tunnel-Konfiguration für MVPN gibt an, dass der Punkt-zu-Multipoint-LSP und (S,G) für diese MVPN-Instanz vom externen Controller bereitgestellt werden können.external-controller Dadurch kann der externe Controller dynamisch (S,G) und Punkt-zu-Mehrpunkt-LSP für MVPN konfigurieren.

Bei der Zuordnung von PCE-initiierten Punkt-zu-Multipunkt-LSPs zu MVPN ist Folgendes zu berücksichtigen:

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

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

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

  • Wenn ein bestimmtes (S,G) dynamisch vom externen Controller gelernt wird und Sie dann dasselbe (S,G) für dieselbe MVPN-Instanz konfigurieren, wird das dynamisch erlernte (S,G) gelöscht und über den PCC an den externen Controller gemeldet.

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

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

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

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

  • Alle Flow-Spezifikationen, die einem PCE-initiierten Punkt-zu-Multipoint-LSP zugeordnet sind, müssen dieselbe RD aufweisen. Wenn während der PC-Initiierung nicht alle Flow-Spezifikationen die gleiche RD haben, wird die PC-Initiierungsnachricht mit einem Fehler gelöscht.

  • Sie können einen Punkt-zu-Mehrpunkt-LSP nur mit selektiven Datenflussspezifikationen verknüpfen, andernfalls wird die PC-Initiierungsnachricht mit einem Fehler verworfen.

  • Wenn während der PC-Aktualisierung nicht alle Flow-Spezifikationen den gleichen RD haben, entweder aufgrund einer neuen Flow-Spezifikation oder aufgrund einer vorhandenen Flow-Spezifikations-Aktualisierung, dann löscht der PCC die Update-Meldung.

  • Wenn während der PC-Aktualisierung alle Flow-Spezifikationen die selektive Bedingung nicht erfüllen, entweder aufgrund einer neuen Flow-Spezifikation oder aufgrund einer Aktualisierung vorhandener Flow-Spezifikationen, verwirft der PCC die Update-Meldung.

  • Das Verhalten für die Zuordnung von PCE-initiierten Punkt-zu-Multipoint-LSPs zu MVPN-Routing-Instanzen und die Zuordnung von statischen (lokal konfigurierten) Punkt-zu-Multipoint-LSPs zu MVPN-Instanzen ist auf Benutzerebene identisch.

  • Eine Datenflussspezifikations-ID kann nur einem Punkt-zu-Mehrpunkt-LSP zugeordnet werden. Um dieselben RD und (S,G) mehreren Punkt-zu-Mehrpunkt-LSPs zuzuordnen, können Sie mehrere Flow-Spezifikationen mit unterschiedlichen IDs und derselben RD & (S,G) hinzufügen.

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

  • Es gibt keine Begrenzung für die Anzahl der Datenflussspezifikationen, die einem einzelnen PCE-initiierten Punkt-zu-Mehrpunkt-LSP zugeordnet werden.

  • Die aktuelle Implementierung dieser Funktion unterstützt Folgendes nicht:

    • Melden von Weiterleitungszuständen, die dem Punkt-zu-Mehrpunkt-LSP zugeordnet sind.

    • Inklusive dynamischer Konfiguration des Provider-Tunnels

    • Zuordnung für MVPN-Eingangsreplikationstunnel

    • Programmierbarer Routing-Protokoll-Prozess (PRPD)

    • Berichterstellung für CLI-konfigurierte Punkt-zu-Multipunkt-LSPs, die MVPN-Multicast-Flows (S,G) zugeordnet sind.

Aktivieren des Segment-Routings 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) für die Datenverkehrssteuerung aktivieren. Mit dieser Unterstützung werden die Vorteile des Segment-Routings auf die Label-Switched-Pfade (LSPs) ausgeweitet, die extern von einem Path Computation Element (PCE) gesteuert werden.

Segment-Routing für das Pfadberechnungselement – Protokollübersicht

Vorteile des Segment-Routings für PCEP

  • Die Einrichtung von Sprachdienstleistern über einen externen Controller bietet einen globalen Überblick über den Bandbreitenbedarf pro Sprachdienstleister und pro Gerät im Netzwerk und ermöglicht eine auf Online- und Echtzeitbeschränkungen basierende Pfadberechnung.

    Die Vorteile des Segment-Routings werden auf die LSPs ausgeweitet, die von einem externen Controller, auch als Path Computation Element (PCE) bezeichnet, initiiert werden, wodurch die Vorteile der externen Pfadberechnung in einem MPLS-Netzwerk erweitert werden.

  • Ein Path Computation Client (PCC, ein Eingangsrouter der MX-Serie) mit Delegierungsfunktion kann die Kontrolle über die delegierten Segment-Routing-LSPs vom PCE zurückgewinnen, wenn die PCEP-Sitzung ausfällt. die Sprachdienstleister würden andernfalls aus dem PCC gelöscht. Auf diese Weise können Sie den LSP-Datenschutz gewährleisten, indem Sie eine Situation vermeiden, in der Pakete stillschweigend verworfen oder verworfen werden (auch als Null-Routing-Bedingung bezeichnet).

Segment-Routing für Traffic Engineering

Segment-Routing kann über eine IPv4- oder IPv6-Datenebene betrieben werden und unterstützt Equal-Cost Multipath (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 Werbelink-Eigenschaften. Diese Funktion ähnelt der von RSVP-TE.

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

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

    In der SR-TE-Funktionalität:

    1. Das Eingangsgerät erstellt einen LSP, indem es die Beschriftungen der Links, die es durchlaufen möchte, stapelt.

    2. Die Link-IGP-Ankündigung wird mit Label-Stacking kombiniert, um Quell-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 dass Speicheranforderungen pro LSP an die Transitgeräte gestellt werden. (Die Erstellung solcher LSPs ist aktiviert, da es in SR-TE keine Signalisierung pro LSP gibt.)

    4. Beschriftungen pro Nachbar werden gestapelt, was zur Verwaltung einer großen Anzahl von Beschriftungen 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 PCE-initiierten Segment-Routing-LSPs sind die LSPs, die der PCE für die Adjacency- und Node-Segmente erstellt

Das PCE führt folgende Funktionen aus:

  1. Berechnet den Pfad des Segmentrouting-LSP.

  2. Stellt den LSP auf dem Path Computation Client (PCC) mithilfe von PCEP-Segmentroutingerweiterungen bereit.

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

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

Das PCC erfüllt folgende Funktionen:

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

    Junos OS unterstützt S-EROs, die den ersten Hop als strikten Hop enthalten. Junos OS unterstützt nicht die Auswahl der ausgehenden Schnittstelle auf dem PCC basierend auf einer Loose-Hop-Knotensegment-ID (SID). Der verbleibende Hopfen kann jedoch lose sein. Für die S-EROs, die über den ersten Hop hinausgehen, wird keine spezifische Verarbeitung durchgeführt, außer dass das Label einfach für die Erstellung des nächsten Hops verwendet wird.

  2. Lehnt die S-ERO ab, wenn:

    • Der S-ERO hat keine Etiketten.

    • Der S-ERO transportiert mehr als sechs Hopfen.

    Der PCC erstellt eine Equal-Cost-Multipath-Route (ECMP), wenn mehrere Sprachdienstleister zum selben Ziel mit derselben Metrik vorhanden sind.

  3. Wartet darauf, dass der PCE alle Ereignisse verarbeitet, die nach der Bereitstellung zu einer Änderung des Segmentrouting-LSP führen, z. B. wenn die Bezeichnung geändert oder zurückgezogen wird oder wenn eine der vom LSP durchlaufenen Schnittstellen ausfällt.

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

  1. Bleibt 300 Sekunden lang aktiv.

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

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

PCE-delegierte Segment-Routing-LSPs

Bei den von PCE delegierten Segmentrouting-LSPs handelt es sich um LSPs, die der PCC lokal konfiguriert und dann an einen PCE-Controller delegiert.

HINWEIS:

Junos OS Version 20.1R1 unterstützt:

  • PCE-Delegierungsfunktion nur für LSPs mit nicht eingefärbtem Segment-Routing 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 Sprachdienstleister müssen noch auf dem PCC konfiguriert werden, und die Delegierung des Sprachdienstleisters erfolgt zum Zeitpunkt der Konfiguration des Sprachdienstleisters.

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

Nach dem Delegieren eines Segmentrouting-LSP steuert der PCE die delegierten LSPs und kann die LSP-Attribute für die Pfadberechnung ändern. Das LSP-Steuerelement wird auf den PCC zurückgesetzt, wenn die PCEP-Sitzung zwischen dem PCC und dem PCE unterbrochen wird. Die von PCE delegierten Sprachdienstleister haben einen Vorteil gegenüber PCE-initiierten Sprachdienstleistern, falls die PCEP-Sitzung ausfällt. Bei PCE-initiierten LSPs werden die LSPs aus dem PCC gelöscht, wenn die PCEP-Sitzung unterbrochen ist. Im Fall von PCE-delegierten Sprachdienstleistern übernimmt der PCC jedoch bei einem Ausfall der PCEP-Sitzung die Kontrolle über die delegierten Sprachdienstleister vom PCE zurück. Daher verhindern wir mit PCE-delegierten LSPs eine Situation, in der Pakete stillschweigend verworfen werden (auch als Null-Routenbedingung 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, bei denen der gesamte Beschriftungsstapel statisch konfiguriert ist.

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

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

  • Dynamic LSPs– Dynamisch erstellte Tunnel, die durch das Dynamic Tunnel Module 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 LSPs für das Segment-Routing zu ermöglichen, fügen Sie die Anweisung auf der entsprechenden Ebene unter der Hierarchie ein.lsp-external-controller pccd[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 Anweisung auf der Hierarchieebene und einschließen, bevor Sie die Delegierungsfunktion für den PCC konfigurieren.lsp-external-controller pccd[edit protocols source-packet-routing][edit protocols mpls]

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

Quelle des Segment-Routing-LSP

Konfigurationshierarchie

  • Automatisch übersetzte Sprachdienstleister

  • Statische Sprachdienstleister

Liste der Hauptsegmente unter [edit protocols source-packet-routing source-routing-path lsp-name primary path-name]

Berechnete Sprachdienstleister (verteilte CSPF)

Liste der primären Segmente des Quell-Routing-Pfads unter:

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

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

Dynamische Sprachdienstleister

Liste der primären Segmente der Quell-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 über die Ausgabe des Befehls show spring-traffic-engineering anzeigen.show spring-traffic-engineering

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

Tabelle 3: PCEP-Interaktion LSP-Delegierung

lsp-external-controller-Konfigurationshierarchie

source-routing-path Delegierungsstatus

PCEP-Interaktion zwischen PCC und PCE

Liste der primären Segmente des Quell-Routing-Pfads

Anfängliche 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 inaktiven Zustand befindet.

  3. Der lokale Sprachdienstleister programmiert eine Route erst, wenn der Controller die ERO berechnet und das Ergebnis über PCUpdate an den PCC übermittelt.

Das gleiche Verhalten tritt auf, wenn der Routingprotokollprozess (RPD) neu gestartet wird oder ein Routingmodul-Switchover erfolgt.

Liste der primären Segmente des Quell-Routing-Pfads

Delegierung eines vorhandenen Pfads

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

  2. Ein entsprechendes Primärsegment wird an die PCE delegiert.

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

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

    • Wenn Seamless BFD (S-BFD) für das primäre Segment nicht konfiguriert ist, erfolgt keine weitere Aktualisierung der Route, und der LSP-Status wird ebenfalls nicht überwacht und an das PCE gemeldet. Der LSP-Status an diesem Punkt wird als "Up" oder "Down" gemeldet, je nachdem, ob die Pfadberechnung zu diesem Zeitpunkt erfolgreich war.

    • Wenn S-BFD für das primäre Segment konfiguriert ist, wird der Zustand des primären Segments verfolgt und an das PCE gemeldet. Wenn BFD feststellt, dass das primäre Segment ausgefallen ist, wird der entsprechende primäre Pfad aus der Route entfernt. Dieselbe Route, die zuvor berechnet wurde, wird neu programmiert, wenn dieser Pfad jetzt aktiv 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 noch die vom PCE empfangene Segmentliste, und alle anderen Segmentlisten, die zuvor programmiert wurden, werden entfernt. Diese Umprogrammierung der Route geschieht nach dem Soll-im-Pause-Prinzip.

Primäres Segment des Quell-Routing-Pfads

Die Delegierung ist nicht konfiguriert oder wurde gelöscht.

Die Segmentliste aus der PCE (falls vorhanden) wird nicht mehr verwendet und das Berechnungsergebnis aus der lokalen Konfiguration 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 wird aktiviert, nachdem LSP konfiguriert wurde.

Die Delegierungsfunktion wird 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 Delegierungsfunktion wird aus der Liste der primären Segmente unter dem Quell-Routing-Pfad entfernt.

Liste der primären Segmente der Vorlage für Quell-Routing-Pfade

Die Delegierung wird aktiviert, nachdem LSP konfiguriert wurde.

  • Unter der Vorlage für den Quell-Routing-Pfad: Die Delegierungsfunktion wird für den gesamten Quell-Routing-Pfad ausgelöst.

    Vorlagenkonfigurationen können nur auf das Modul "Dynamischer Tunnel" angewendet werden.

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

Liste der primären Segmente der Vorlage für Quell-Routing-Pfade

Die Delegierung ist nicht konfiguriert oder wurde gelöscht.

Die Delegierungsfunktion wird aus allen Quellroutingpfaden 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 gelten jedoch die folgenden Einschränkungen:

  • Ein SR-TE LSP ist auf dem PCC nicht lokal geschützt. Wenn der LSP aus mehr als sechs Hops besteht, wird auf dem LSP kein anderer Dienst bereitgestellt als der Transport von einfachem IP-Datenverkehr.

  • 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.

  • Von PCE delegierte Sprachdienstleister unterstützen Folgendes nicht:

    • Farbige SR-TE LSPs

    • IPv6-Sprachdienstleister

    • Liste der sekundären Segmente des Quell-Routing-Pfads. Es kann nur ein Pfad der Segmentliste delegiert werden.

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

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

In diesem Beispiel wird gezeigt, wie Segment-Routing oder Source Packet Routing in Networking (SPRING) Traffic-Engineering (SR-TE) für das Path Computation Element Protocol (PCEP) konfiguriert wird. In der Konfiguration nutzen wir die Vorteile des Segment-Routings 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 Eingangsrouter der MX-Serie 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, das auf dem PCC für die Implementierung von PCE-initiierten LSPs ausgeführt wird.

    Für die PCE-Delegierungsfunktion müssen Sie Junos OS Version 20.1R1 oder eine höhere Version ausführen.

Bevor Sie beginnen:

  • Konfigurieren Sie die Geräteschnittstellen.

  • Konfigurieren Sie MPLS.

  • Konfigurieren Sie IS-IS.

Überblick

Die Junos OS-Implementierung des Segment-Routings 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-Routings in PCEP-Sitzungen für LSPs unterstützt werden, die von einem PCE initiiert wurden. Der PCE erstellt die LSPs für die Adjacency- und Node-Segmente. In der inet.3-Routing-Tabelle des PCC werden Tunnelrouten erstellt, die den PCE-initiierten SR-TE-LSPs entsprechen.

  • Die Implementierung von PCE-delegierten LSPs wird in Junos OS Version 20.1R1 eingeführt, in der die lokal konfigurierten IPv4-LSPs für das nicht farbige Segment-Routing 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 von PCE delegierten Sprachdienstleister haben zum Zeitpunkt des Ausfalls der PCEP-Sitzung einen Vorteil gegenüber PCE-initiierten Sprachdienstleistern. Bei PCE-initiierten LSPs werden die LSPs aus dem PCC gelöscht, wenn die PCEP-Sitzung unterbrochen ist. Im Fall von PCE-delegierten Sprachdienstleistern übernimmt der PCC jedoch bei einem Ausfall der PCEP-Sitzung die Kontrolle über die delegierten Sprachdienstleister vom PCE zurück. Daher verhindern wir mit PCE-delegierten LSPs eine Situation, in der Pakete stillschweigend verworfen werden (auch als Null-Routenbedingung bezeichnet), wenn die PCEP-Sitzung ausfällt.

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

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

  1. Aktivieren Sie die externe Pfadberechnung für MPLS, indem Sie die Anweisung auf Hierarchieebene einschließen.lsp-external-controller[edit protocols mpls]

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

  2. Aktivieren Sie die externe Pfadberechnung für SR-TE, indem Sie die Anweisung auf Hierarchieebene einschließen.lsp-external-controller pccd[edit protocols spring-traffic-engineering]

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

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

    Die maximale SID-Tiefe ist die Anzahl der SIDs, die von einem Knoten oder einer Verbindung auf einem Knoten unterstützt werden. Wenn diese Option nicht konfiguriert ist, wird ein maximaler SID-Standardwert von 5 angewendet.

  5. Konfigurieren Sie optional den Voreinstellungswert für das Segment-Routing, indem Sie das auf der Hierarchieebene einschließen.preference preference-value[edit protocol spring-te]

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

  6. Konfigurieren Sie optional die Protokollierung des Segment-Routings zur Fehlerbehebung, indem Sie die Anweisung auf Hierarchieebene einschließen.traceoptions[edit protocols spring-te]

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

  1. Definieren Sie eine Segmentliste mit Beschriftungsparametern. Dadurch wird ein Segment-Routing-LSP lokal auf dem PCC erstellt.

  2. Aktivieren Sie die Delegierungsfunktion des lokal konfigurierten LSP auf dem PCC, indem Sie die Anweisung in eine der folgenden Hierarchien einschließen, abhängig von der LSP-Quelle für das Segmentrouting:lsp-external-controller pccd

    • Für statisch konfigurierte Quellroutingpfade, die mit verteilten CSPF - und Hierarchieebenen berechnet werden.[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]

    • Für statisch konfigurierte Quellroutingpfade, bei denen der gesamte Beschriftungsstapel statisch konfiguriert ist, und Quellroutingpfade, die automatisch übersetzt werden, Hierarchieebene.[edit protocols source-packet-routing source-routing-path lsp-name primary path-name]

    • Für dynamisch erstellte Tunnel, die über das Dynamic Tunnel Module ausgelöst werden und Last-Hop-ERO-Auflösungs- und Hierarchieebenen haben.[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]

Topologie

Abbildung 8 veranschaulicht eine Beispiel-Netzwerktopologie, bei der eine PCEP-Sitzung zwischen dem PCE und dem PCC (dem Eingangsrouter 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 zu 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 sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für Ihre Netzwerkkonfiguration erforderlich sind, kopieren Sie die Befehle und fügen Sie sie in die CLI auf Hierarchieebene ein, und geben Sie sie dann aus dem Konfigurationsmodus ein .[edit]commit

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

PCC

Router R1

Router R2

Router R3

Verfahren
Schritt-für-Schritt-Anleitung

In diesem Beispiel konfigurieren wir nur den PCC.

Die folgenden Schritte erfordern, dass Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Weitere Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI-Benutzerhandbuch.Verwenden des CLI-Editors im Konfigurationsmodushttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html

So konfigurieren Sie den 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 Überprüfungszwecken erstellt und wirkt sich nicht auf die Feature-Funktionalitä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 Pfadberechnungsfunktionen für MPLS.

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

  8. Konfigurieren Sie Segment-Routing-Attribute für globale Blöcke (SRGB) für das Segment-Routing.

  9. Aktivieren Sie die externe Pfadberechnungsfunktion für SR-TE.

  10. Konfigurieren Sie die PCE-Parameter, und aktivieren Sie die Bereitstellung des LSP durch die PCE und die Segmentrouting-Funktion.

  11. Aktivieren Sie die Bereitstellung von Segment-Routing-LSPs durch die PCE.

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

  13. Definieren Sie die statischen Segmentlistenparameter .static_seg_list_1

  14. Konfigurieren Sie einen LSP für das statische Segmentrouting vom PCC zum Router R3 für die PCE-Delegierung.

  15. Aktivieren Sie die Delegierungsfunktion für den Quellroutingpfad.static_srte_lsp_1

    Wenn Sie die Schritte 13, 14 und 15 ausführen, aktivieren Sie den PCC, um die Segment-Routing-LSPs an das PCE zu delegieren.

  16. Bestätigen Sie die Konfiguration.

Ergebnisse

Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie die Befehle , und eingeben.show interfacesshow routing-optionsshow protocols Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Wenn Sie mit der Konfiguration des Geräts (PCC) fertig sind, wechseln Sie in den Konfigurationsmodus.commit

Überprüfung

Vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.

IS-IS-Nachbarschaft und -Labels überprüfen
Zweck

Überprüfen Sie die IS-IS-Nachbarschaft auf dem PCC. Beachten Sie den SRGB-Beschriftungsbereich, die Nachbarschafts- und Knotensegmentwerte sowie die Ausgabefelder der SPRING-Funktion.

Was

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

Bedeutung

Die IS-IS-Nachbarschaft zwischen PCC und PCE und die zwischen PCC und Router R1 sind verfügbar und betriebsbereit. In der Ausgabe werden auch die Beschriftungszuweisungen für die angrenzenden Segmente und Knotensegmente angezeigt.

Verifizieren der Traffic Engineering-Datenbank
Zweck

Überprüfen Sie die Einträge in der Traffic-Engineering-Datenbank auf dem PCC.

Was

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

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 die externe Pfadberechnung für den PCC verwendet.

Verifizieren von SR-TE-LSPs
Zweck

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

Was

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

Bedeutung

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

Das Segment-Routing-LSP , ist mit der Delegierungsfunktion aktiviert.static_srte_lsp_1 Das Feld zeigt den Steuerungs- und Routing-Status von PCE-delegierten LSPs an. bedeutet, dass der PCE die Kontrolle über die LSPs hat. bedeutet, dass der PCE den ERO für den Quell-Routing-Pfad bereitgestellt hat. Delegation infoExternally controlledExternally routed

Überprüfen der Tunnelroutenerstellung
Zweck

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

Was

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

Bedeutung

Für das PCE-gesteuerte LSP-Ziel wurden Tunnelrouten mit SR-TE als Protokollbezeichnung erstellt.

Weiterleitungstabelleneinträge überprüfen
Zweck

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

Was

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

Bedeutung

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

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

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

Was

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

Bedeutung

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

Statisches Segment-Routing-Label Switched-Pfad

Die Segment-Routing-Architektur ermöglicht es den Eingangsgeräten in einem Core-Netzwerk, den Datenverkehr über explizite Pfade zu leiten. Sie können diese Pfade mithilfe von Segmentlisten konfigurieren, um die Pfade zu definieren, die der eingehende Datenverkehr nehmen soll. Bei dem eingehenden Datenverkehr kann es sich um einen gekennzeichneten oder IP-Datenverkehr handeln, was dazu führt, dass der Weiterleitungsvorgang am Eingangsgerät entweder ein Label-Swap oder eine zielbasierte Suche ist.

Grundlegendes zum statischen Segment-Routing LSP in MPLS-Netzwerken

Source Packet Routing oder Segment Routing ist eine Architektur der 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 verlassen zu müssen, um den tatsächlichen Pfad zu bestimmen, den es nehmen soll.

Einführung in Segment-Routing-LSPs

Segment-Routing nutzt das Source-Routing-Paradigma. Ein Gerät steuert ein Paket durch eine geordnete Liste von Anweisungen, die als Segmente bezeichnet werden. Ein Segment kann eine beliebige Anweisung darstellen, topologisch oder dienstbasiert. 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 Fluss durch einen beliebigen topologischen Pfad und jede Servicekette, während der Pro-Flow-Status nur am Eingangsgerät zur Segment-Routing-Domäne beibehalten wird. Segment-Routing kann direkt auf die MPLS-Architektur angewendet werden, ohne dass Änderungen auf der Weiterleitungsebene vorgenommen werden. Ein Segment wird als MPLS-Label codiert. Eine geordnete Liste von Segmenten wird als Stapel von Beschriftungen codiert. Das zu verarbeitende Segment befindet sich ganz oben auf dem Stapel. Nach Abschluss eines Segments wird die zugehörige Beschriftung aus dem Stapel entfernt.

Segment-Routing-LSPs können entweder dynamischer oder statischer Natur sein.

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

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

Ein statischer Segment-Routing-LSP kann basierend auf der Konfiguration der Anweisung auf Hierarchieebene weiter in farbige und nicht farbige LSPs klassifiziert werden.color[edit protocols source-packet-routing source-routing-path lsp-name]

Hier einige Zahlen zum Generationswechsel:

[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

  • Das Routing statischer Segmente hängt nicht vom Weiterleitungsstatus pro LSP auf Transitroutern ab. Dadurch entfällt die Notwendigkeit der Bereitstellung und Wartung des Weiterleitungsstatus pro LSP im Core.

  • Höhere Skalierbarkeit für MPLS-Netzwerke.

Farbiges statisches Segment-Routing LSP

Ein LSP für statisches Segmentrouting, der mit der Anweisung konfiguriert ist, wird als farbiger LSP bezeichnet.color

Grundlegendes zu farbigen LSPs für das Routing statischer Segmente

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

Ein statischer LSP für das farbige Segment-Routing kann über eine Bindungs-SID verfügen, für die eine Route in der Routing-Tabelle installiert ist.mpls.0 Diese Bindungs-SID-Bezeichnung wird verwendet, um bezeichneten Datenverkehr dem Segmentrouting-LSP zuzuordnen. Die Gateways der Route werden aus den Segmentlistenkonfigurationen unter den primären und sekundären Pfaden abgeleitet.

Segmentliste der LSPs für farbiges Segment-Routing

Die farbigen LSPs für das Routing statischer Segmente bieten bereits Unterstützung für den First-Hop-Label-Modus zum Auflösen eines LSP. Der IP-Modus des ersten Hops wird jedoch nicht für LSPs mit farbigem Segment-Routing unterstützt. Ab Junos OS Version 19.1R1 wird eine Commit-Prüffunktion eingeführt, mit der sichergestellt wird, dass in allen Segmentlisten, die zu den farbigen Routen beitragen, die minimale Bezeichnung für alle Hops vorhanden ist. Wenn diese Anforderung nicht erfüllt ist, wird der Commit blockiert.

Nicht farbiges statisches Segment-Routing LSP

Ein LSP für statisches Segmentrouting, der ohne die Anweisung konfiguriert ist, ist ein nicht eingefärbter LSP.color Ähnlich wie bei PCEP-Segment-Routing-Tunneln wird die Eingangsroute in den OR-Routing-Tabellen installiert.inet.3inet6.3

Junos OS unterstützt nicht eingefärbte LSPs für das Routing statischer Segmente auf Eingangsroutern. Sie können LSPs für das statische Segment-Routing ohne Farbe bereitstellen, indem Sie einen Quell-Routingpfad und eine oder mehrere Segmentlisten konfigurieren. Diese Segmentlisten können von mehreren LSPs für das Segment-Routing ohne Farbe verwendet werden.

Grundlegendes zum Routing von LSPs für nicht farbige Segmente

Der nicht eingefärbte Segment-Routing-LSP hat einen eindeutigen Namen und eine Ziel-IP-Adresse. Eine Eingangsroute zum Ziel wird in der inet.3-Routing-Tabelle mit der Standardeinstellung 8 und der Metrik 1 installiert. Diese Route ermöglicht die Zuordnung von nicht eingefärbten Services zum Segment-Routing-LSP, der sich auf das Ziel bezieht. Falls der LSP für das nicht farbige Segment-Routing keine Eingangsroute erfordert, kann die Eingangsroute deaktiviert werden. Ein LSP für das Segment-Routing ohne Farbe verwendet die Bindungs-SID-Beschriftung, um das LSP-Stitching für das Segment-Routing zu erreichen. Diese Bezeichnung, die verwendet werden kann, um den Segment-Routing-LSP als ein Segment zu modellieren, das weiter verwendet werden kann, um andere Segment-Routing-LSPs hierarchisch zu erstellen. Der Transit der bindenden SID-Bezeichnung hat standardmäßig die Präferenz 8 und die Metrik 1.

Ab Junos OS Version 18.2R1 werden statisch konfigurierte, nicht farbige Segment-Routing-LSPs auf dem Eingangsgerät über eine PCEP-Sitzung (Path Computation Element Protocol) an das Path Computation Element (PCE) gemeldet. Diesen nicht-farbigen Segment-Routing-LSPs können SID-Bezeichnungen (Binding Service Identifier) zugeordnet sein. Mit dieser Funktion kann der PCE diese Bindungs-SID-Bezeichnung im Label-Stack verwenden, um PCE-initiierte LSP-Pfade für das Segment-Routing bereitzustellen.

Ein LSP mit nicht farbigem Segment-Routing kann maximal 8 primäre Pfade haben. Wenn mehrere operative primäre Pfade vorhanden sind, verteilt die Packet Forwarding Engine (PFE) den Datenverkehr basierend auf den Lastausgleichsfaktoren wie der auf dem Pfad konfigurierten Gewichtung über die Pfade. Hierbei handelt es sich um Equal Cost Multi Path (ECMP), wenn für keinen der Pfade eine Gewichtung konfiguriert ist, oder um gewichtetes ECMP, wenn für mindestens einen der Pfade eine Gewichtung ungleich Null auf den Pfaden konfiguriert ist. In beiden Fällen, wenn einer oder einige der Pfade ausfallen, gleicht die PFE den Datenverkehr auf die verbleibenden Pfade aus, was automatisch zum Erreichen des Pfadschutzes führt. Ein LSP ohne farbiges Segment-Routing kann über einen sekundären Pfad für dedizierten Pfadschutz verfügen. Bei einem Ausfall eines primären Pfads verteilt die PFE den Datenverkehr wieder auf die verbleibenden funktionalen primären Pfade. Andernfalls schaltet die PFE den Datenverkehr auf den Backup-Pfad um und erreicht so einen Pfadschutz. Ein LSP ohne farbiges Segment-Routing kann eine Metrik at für seine Eingangs- und Bindungs-SID-Routen angeben.[edit protocols source-packet-routing source-routing-path lsp-name] 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 Segmentrouting-LSP wird als Gateway-Kandidat betrachtet, wenn der Pfad funktional ist und der Segmentrouting-LSP die beste Präferenz aller dieser Segmentrouting-LSPs aufweist. Die maximale Anzahl von Gateways, die der nächste Hop aufnehmen kann, darf jedoch den RPD-Grenzwert für mehrere Pfade nicht überschreiten, der standardmäßig bei 128 liegt. Zusätzliche Pfade werden beschnitten, zuerst sekundäre Pfade und dann primäre Pfade. Eine bestimmte Segmentliste kann von diesen Segmentrouting-LSPs mehrmals als primäre oder sekundäre Pfade bezeichnet werden. In diesem Fall gibt es mehrere Gateways, von denen jedes über eine eindeutige LSP-Tunnel-ID für das Segmentrouting verfügt. Diese Gateways unterscheiden sich, obwohl sie über einen identischen ausgehenden Label-Stack und dieselbe Schnittstelle verfügen. Ein LSP für nicht-farbiges Segment-Routing und ein LSP für farbiges Segment-Routing können ebenfalls dieselbe Zieladresse haben. Sie entsprechen jedoch unterschiedlichen Zieladressen für Eingangsrouten, da die Zieladresse des LSP für das farbige Segment-Routing sowohl mit der Zieladresse als auch mit der Farbe erstellt wird.

HINWEIS:

Für den Fall, dass ein statischer, nicht eingefärbter Segment-Routing-LSP und ein von PCEP erstellter Segment-Routing-LSP nebeneinander existieren und dieselbe zu adressieren haben, die zur gleichen Eingangsroute beiträgt, wenn sie auch die gleiche Präferenz haben. Andernfalls wird das 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 der SID-Bezeichnung oder einer IP-Adresse. Die Anzahl der SID-Bezeichnungen in der Segmentliste sollte den maximalen Grenzwert für Segmentlisten nicht überschreiten. Die maximale Segmentlistenbindung an einen LSP-Tunnel wurde von 8 auf 128 erhöht, mit maximal 1000 Tunneln pro System. Pro LSP für statisches Segmentrouting werden maximal 128 primäre Pfade unterstützt. Sie können das maximale Limit für Segmentlisten auf Hierarchieebene konfigurieren.[edit protocols source-packet-routing]

Vor Junos OS Version 19.1R1 musste der erste Hop der Segmentliste eine IP-Adresse einer ausgehenden Schnittstelle sein, und der zweite Hop konnte eine SID-Bezeichnung sein, damit ein LSP für statisches Segment-Routing ohne Farbe verwendet werden konnte.n Ab Junos OS Version 19.1R1 gilt diese Anforderung nicht mehr, da der erste Hop der nicht eingefärbten statischen LSPs jetzt zusätzlich zu den IP-Adressen auch Unterstützung für SID-Bezeichnungen bietet. Mit der Unterstützung von First-Hop-Labels werden MPLS Fast Reroute (FRR) und gewichteter Equal-Cost-Multipath für die Auflösung der statischen, nicht farbigen Segment-Routing-LSPs aktiviert, ähnlich wie bei farbigen statischen LSPs.

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

Sie können die Konfiguration in einer der folgenden Hierarchien vornehmen .inherit-label-nexthops Die Anweisung wird nur wirksam, wenn der erste Hop der Segmentliste sowohl die IP-Adresse als auch die Bezeichnung enthält.inherit-label-nexthops

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

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

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

Für dynamische, nicht farbige statische LSPs, d. h. die PCEP-gesteuerten Segment-Routing-LSPs, muss die Anweisung global aktiviert werden, da die Konfiguration auf Segmentebene nicht angewendet wird.inherit-label-nexthops

Tabelle 4 beschreibt den Modus der LSP-Auflösung für das Segmentrouting basierend auf der Spezifikation des ersten Hops.

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

First Hop – Spezifikation

Modus der LSP-Auflösung

Nur IP-Adresse

Hier einige Zahlen zum Generationswechsel:

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 anhand der IP-Adresse aufgelöst.

Nur SID

Hier einige Zahlen zum Generationswechsel:

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-Beschriftungen aufgelöst.

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

Hier einige Zahlen zum Generationswechsel:

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 anhand der IP-Adresse aufgelöst.

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

Hier einige Zahlen zum Generationswechsel:

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-Beschriftungen aufgelöst.

Sie können den Befehl verwenden, um die nicht eingefärbten Segment-Routing-LSPs anzuzeigen, bei denen mehrere Segmentlisten in der inet.3-Routing-Tabelle installiert sind.show route ip-address protocol spring-te active-path table inet.3

Hier einige Zahlen zum Generationswechsel:

HINWEIS:

Der erste Hoptyp von Segmentlisten eines statischen Segmentrouting-LSP kann dazu führen, dass ein Commit fehlschlägt, wenn:

  • Unterschiedliche Segmentlisten eines Tunnels haben unterschiedliche Auflösungstypen für den ersten Hop. Dies gilt sowohl für farbige als auch für nicht-farbige LSPs für das statische Segment-Routing. Dies gilt jedoch nicht für PCEP-gesteuerte Sprachdienstleister; Für die Nichtübereinstimmung des Auflösungstyps des ersten Hops zum Zeitpunkt der Berechnung des Pfads wird eine Systemprotokollmeldung generiert.

    Hier einige Zahlen zum Generationswechsel:

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

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

    Hier einige Zahlen zum Generationswechsel:

    Die Konfiguration der Bindungs-SID über die Beschriftungssegmentliste wird nur für farbige statische LSPs und nicht für nicht farbige statische LSPs unterstützt.

Statisches Segment-Routing LSP-Bereitstellung

Die Segmentbereitstellung erfolgt pro Router. Für ein bestimmtes Segment auf einem Router wird ein eindeutiges SID-Label (Service Identifier) aus einem gewünschten Label-Pool zugewiesen, der aus dem dynamischen Label-Pool für ein Adjacency-SID-Label oder aus dem Segment Routing Global Block (SRGB) für eine Präfix-SID oder Knoten-SID stammen kann. Die Adjacency-SID-Bezeichnung kann dynamisch zugewiesen werden, was das Standardverhalten ist, oder aus einem lokalen statischen Label-Pool (SRLB) zugewiesen werden. Anschließend wird eine Route für das SID-Label in der Tabelle mpls.0 installiert.

Junos OS ermöglicht LSPs für das Routing statischer Segmente, indem die Anweisung auf Hierarchieebene konfiguriert wird.segment[edit protocols mpls static-label-switched-path static-label-switched-path] Ein statischer Segment-LSP wird durch eine eindeutige SID-Bezeichnung identifiziert, die unter den statischen Junos OS-Label-Pool fällt. Sie können den statischen Bezeichnungspool von Junos OS konfigurieren, indem Sie die Anweisung auf Hierarchieebene konfigurieren.static-label-range static-label-range[edit protocols mpls label-range]

LSP-Einschränkungen für statisches Segment-Routing

  • Junos OS hat derzeit die Einschränkung, dass der nächste Hop nicht so erstellt werden kann, dass er mehr als die maximale Segmentlistentiefe überträgt. Daher kann eine Segmentliste mit mehr als den maximalen SID-Labels (mit Ausnahme des SID-Labels des ersten Hops, das zum Auflösen der Weiterleitung des nächsten Hops verwendet wird) nicht für LSPs mit farbigem oder nicht farbigem Segment-Routing verwendet werden. Außerdem kann die tatsächlich zulässige Anzahl für einen bestimmten Segment-Routing-LSP sogar unter dem maximalen Grenzwert liegen, wenn sich ein MPLS-Dienst auf dem Segment-Routing-LSP oder der Segmentrouting-LSP auf einem Link- oder Knotenschutzpfad befindet. In jedem Fall darf die Gesamtzahl der Dienstbezeichnungen, SID-Bezeichnungen und Verbindungs- oder Knotenschutzbezeichnungen die maximale Segmentlistentiefe nicht überschreiten. Sie können die maximale Segmentlistengrenze auf Hierarchieebene konfigurieren.[edit protocols source-packet-routing] Mehrere nicht farbige Segment-Routing-LSPs mit weniger oder gleich den maximalen SID-Beschriftungen können zusammengefügt werden, um ein längeres Segment-Routing-LSP zu erstellen. Dies wird als Segment-Routing, LSP-Stitching bezeichnet. Dies kann mithilfe des binding-SID-Labels erreicht werden.

  • Das LSP-Stitching für das Segment-Routing wird tatsächlich auf Pfadebene durchgeführt. Wenn ein LSP für das Segment-Routing ohne Farbe mehrere Pfade hat, d. h. mehrere Segmentlisten, kann jeder Pfad unabhängig von einem anderen LSP für das Routing von nicht farbigen Segmenten an einem Stitching-Punkt verknüpft werden. Ein LSP ohne farbiges Segment-Routing, der für das Stitching vorgesehen ist, kann die Installation der Eingangsroute deaktivieren, indem eine Anweisung auf Hierarchieebene konfiguriert wird.no-ingress[edit protocols source-packet-routing source-routing-path lsp-name]

  • Pro LSP für das statische Segment-Routing werden maximal 128 primäre Pfade und 1 sekundärer Pfad unterstützt. Wenn es einen Verstoß in der Konfiguration gibt, schlägt die Commit-Prüfung mit einem Fehler fehl.

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

  • Wenn eine Segmentliste mit mehr Beschriftungen als der maximalen Segmentlistentiefe konfiguriert ist, schlägt die Überprüfung des Konfigurationscommits mit einem Fehler fehl.

Dynamische Erstellung von Segment-Routing-LSPs

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

Konfigurieren der LSP-Vorlage für dynamisches Segment-Routing

Um die Vorlage für die Aktivierung der dynamischen Erstellung von Segment-Routing-LSPs zu konfigurieren, müssen Sie die spring-te-Anweisung in die Hierarchie aufnehmen.spring-te (Dynamic Tunnels)[edit routing-options dynamic-tunnels]

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

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

Auflösen dynamischer Segment-Routing-LSPs
Auflösen von farbigem dynamischem Segment-Routing LSP

Wenn den BGP-Präfixen eine Farbgemeinschaft zugewiesen wird, werden sie zunächst über die Richtlinie "Catch-all-route-for-that-particular-color" aufgelöst, und im Gegenzug wird die SR-TE-Vorlage identifiziert, in der das BGP-Präfix aufgelöst werden soll. Die Ziel-SID wird dann aus dem Next-Hop-Attribut des BGP-Nutzlastpräfixes abgeleitet. Wenn der nächste Hop des BGP-Nutzlastpräfixes beispielsweise eine IP-Adresse ist, die zu Gerät A gehört, wird die Node-SID von Gerät A verwendet, ein entsprechendes Label erstellt und an das Ende des Stacks verschoben. Das BGP-Nutzlastpräfix wird in einem Nur-Farben-Modus aufgelöst, in dem sich die Node-SID von Gerät A am unteren Rand des endgültigen Label-Stacks und die SR-TE-Pfad-Labels oben befinden.

Der endgültige Name der LSP-Vorlage ist eine Kombination aus Präfix, Farbe und Tunnelname. Beispiel: .<prefix>:<color>:dt-srte-<tunnel-name> Die Farbe im LSP-Namen wird im Hexadezimalformat angezeigt, und das Format des Tunnelnamens ähnelt dem von RSVP-getriggerten Tunnel-LSP-Namen.

Um ein farbiges Zielnetzwerk erfolgreich aufzulösen, muss die Farbe über eine gültige Vorlagenzuordnung verfügen, entweder zu einer bestimmten Farbe oder über die Vorlage.color-any Ohne eine gültige Zuordnung wird der Tunnel nicht erstellt, und die BGP-Route, die eine Auflösung anfordert, bleibt unaufgelöst.

Auflösen von ungefärbten dynamischen Segment-Routing-LSPs

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

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

Dynamisches Segment-Routing LSP-Beispielkonfiguration

Die LSP-Vorlage für dynamisches Segment-Routing enthält immer einen Teilpfad. Die SID des letzten Hop-Knotens wird zum Zeitpunkt der Tunnelerstellung automatisch in Abhängigkeit von der PNH-Knoten-SID (Next Hop Address) des Protokolls abgeleitet. Dieselbe Vorlage kann von mehreren Tunneln zu verschiedenen Zielen verwendet werden. In solchen Fällen bleibt der partielle Pfad unverändert, und nur der letzte Hop ändert sich, abhängig vom PNH. LSP-Vorlagen für dynamisches Segment-Routing sind für einen einzelnen Tunnel nicht üblich, daher kann kein vollständiger Pfad darauf übertragen werden. Sie können eine Segmentliste verwenden, wenn ein vollständiger Pfad verwendet werden soll.

Farbige dynamische Segment-Routing-LSPs

Beispielkonfiguration für LSPs für farbiges dynamisches Segment-Routing:

Für die oben erwähnte Beispielkonfiguration lauten die Routeneinträge wie folgt:

  1. inetcolor.0 tunnel route  10.22.44.0-0/24 --> RT_NH_TUNNEL

  2. BGP prefix to tunnel mapping 

    R1(Präfix) -> 10.22.44.55-101(PNH) LSP-Tunnelname = 10.22.44.55:65:dt-srte-tunnel1

  3. inetcolor.0 tunnel route 

    10.22.44.55-101/64 --> &lt;nächster-hop>

    10.22.44.55-124/64 --> &lt;nächster-hop>

Nicht farbige LSPs für dynamisches Segment-Routing

Beispielkonfiguration für LSPs für das dynamische Segment-Routing ohne Farbe:

Für die oben erwähnte Beispielkonfiguration lauten die Routeneinträge wie folgt:

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

  2. BGP prefix to tunnel mapping 

    R1(Präfix) -> 10.33.44.55(PNH) LSP-Vorlagenname = LSP1 --- 10.33.44.55:dt-srte-tunnel2

  3. inet.3 tunnel route  10.33.44.55/32 --> &lt;nächster-hop>

Ungelöster dynamischer Segment-Routing-LSP

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

Für die oben erwähnte Beispielkonfiguration lauten 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. BGP prefix to tunnel mapping  R1(Präfix) -> 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:

  • Eine Vorlage kann mit einem Farbobjekt versehen werden. Wenn die dynamische Tunnelkonfiguration eine Vorlage mit einem Farbobjekt enthält, müssen Sie auch alle anderen Vorlagen mit Farbobjekten konfigurieren.spring-te Es wird davon ausgegangen, dass alle Ziele innerhalb dieser Konfiguration farbig dargestellt sind.

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

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

  • Die Zuordnung von Farbe zu Vorlage erfolgt eins-zu-eins. Eine Farbe kann nicht mehreren Vorlagen zugeordnet werden.

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

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

  • Es ist nicht möglich, dieselben Zielnetzwerke mit oder ohne Farbe unter verschiedenen Konfigurationsanweisungen zu konfigurieren.spring-te

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

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

  • Exportieren von Richtliniendiensten

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 aus dem Segment-Routing an dasselbe Ziel herunterladen (z. B. statische und dynamische Quelltunnel), wird die Voreinstellung für das Segment-Routing 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 von dynamischen Segment-Routing-LSPs

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

  • IPv6-Segment-Routing-Tunnel.

  • Statische Tunnel.

  • 6PE wird nicht unterstützt.

  • Verteiltes CSPF.

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

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

Farbbasiertes Mapping von VPN-Diensten

Sie können Farbe als Protokolleinschränkung für den nächsten Hop (zusätzlich zur IPv4- oder IPv6-Adresse) für die Auflösung von Transporttunneln über statische, farbige und BGP-Segment-Routing-SR-TE-LSPs (Traffic Engineering) angeben. Dies wird als Next-Hop-Auflösung des Color-IP-Protokolls bezeichnet, bei dem Sie eine Auflösungszuordnung konfigurieren und auf die VPN-Dienste anwenden müssen. Mit dieser Funktion können Sie die farbbasierte Datenverkehrssteuerung von Layer-2- und Layer-3-VPN-Diensten aktivieren.

Junos OS unterstützt farbige SR-TE-LSPs, die einer einzigen Farbe zugeordnet sind. Die Funktion "Farbbasierte Zuordnung von VPN-Diensten" wird für statisch gefärbte LSPs und BGP SR-TE LSPs unterstützt.

VPN-Dienst-Coloring

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

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

  • Pro Routing-Instanz.

  • Pro BGP-Gruppe.

  • Pro BGP-Nachbar.

  • Pro Präfix.

Sobald Sie eine Farbe zugewiesen haben, wird die Farbe in Form einer erweiterten BGP-Farbcommunity an einen VPN-Dienst angehängt.

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

Mehrere Farben werden von Ausgangs- 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 der VPN-Dienstfärbung sind:

Farbzuweisung für Ausgang

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

Hier einige Zahlen zum Generationswechsel:

Oder

HINWEIS:

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

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

Zuweisung von Eingangsfarben

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

Hier einige Zahlen zum Generationswechsel:

Oder

Festlegen des VPN-Dienstzuordnungsmodus

Um flexible Zuordnungsmodi für VPN-Dienste anzugeben, müssen Sie mithilfe der Anweisung eine Richtlinie definieren und die Richtlinie in der Routing-Instanz, dem Gruppenimport oder dem Gruppennachbarimport eines VPN-Diensts auf der Hierarchieebene referenzieren.resolution-mapvrf-import[edit protocols bgp] Alle VPN-Routen, die der Routing-Richtlinie entsprechen, werden mit der angegebenen Auflösungskarte verknüpft.

Hier einige Zahlen zum Generationswechsel:

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

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

HINWEIS:

Jeder VPN-Dienstzuordnungsmodus sollte einen eindeutigen Namen haben, der in der Auflösungszuordnung definiert ist. In der Auflösungskarte wird nur ein einziger Eintrag von IP-color unterstützt, wobei die VPN-Route(n) mit einem colored-IP-Protokoll Next Hop in Form von aufgelöst werden.ip-address:color

Color-IP-Protokoll Next Hop Auflösung

Der Protokoll-Next-Hop-Auflösungsprozess wurde verbessert, um die Next-Hop-Auflösung des Colored-IP-Protokolls zu unterstützen. Bei einem farbigen VPN-Dienst nimmt der Protokollauflösungsprozess für den nächsten Hop eine Farbe und eine Auflösungszuordnung, erstellt einen nächsten Hop für das Protokoll mit farbigem IP in Form von und löst den nächsten Hop des Protokolls in der Routing-Tabelle inet6color.0 auf.IP-address:color

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

Hier einige Zahlen zum Generationswechsel:

Fallback auf IP-Protokoll Next Hop Resolution

Wenn auf einen farbigen VPN-Dienst keine Auflösungszuordnung angewendet wurde, ignoriert der VPN-Dienst seine Farbe und greift auf die IP-Protokollauflösung für den nächsten Hop zurück. Umgekehrt gilt: Wenn auf einen nicht farbigen VPN-Dienst eine Auflösungszuordnung angewendet wurde, wird die Auflösungszuordnung ignoriert, und der VPN-Dienst verwendet die IP-Protokollauflösung für den nächsten Hop.

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 Präfixübereinstimmung für einen Next-Hop mit farbigem IP-Protokoll stellt sicher, dass eine LDP-Route mit einer übereinstimmenden IP-Adresse zurückgegeben wird, wenn keine farbige SR-TE LSP-Route vorhanden ist.

Farbbasiertes BGP-Labeled-Unicast-Mapping ü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) sowohl für IPv4- als auch für IPv6-Adressfamilien auflösen. BGP-LU unterstützt die Zuordnung einer BGP-Community-Farbe und die Definition einer für SR-TE.resolution map Es wird ein nächster Hop für ein farbiges Protokoll erstellt, das in einem farbigen SR-TE-Tunnel in der Tabelle "oder" aufgelöst wird.inetcolor.0inet6color.0 BGP-Verwendungen und -Tabellen für nicht-farbbasiertes Mapping.inet.3inet6.3 Auf diese Weise können Sie BGP-LU-IPv6- und IPv4-Präfixe mit einer IPv6-Next-Hop-Adresse in reinen IPv6-Netzwerken ankündigen, 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 konfiguriert der Controller 4 farbige Tunnel in einem IPv6-Core-Netzwerk, das mit SR-TE konfiguriert ist.Abbildung 9 Jeder farbige Tunnel nimmt je nach definierter Auflösungskarte einen anderen Pfad zum Zielrouter D. Der Controller konfiguriert einen farbigen SR-TE-Tunnel zur 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 das BGP-IPv6-LU-Präfix gemäß der zugewiesenen Auflösungszuordnungsrichtlinie auf.

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

BGP-LU unterstützt die folgenden Szenarien:

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

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

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

  • BGP IPv6 LU über statisches farbiges und nicht farbiges IPv6 SR-TE, mit ISIS IPv6 SR-Erweiterungen.

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

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

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

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

Die folgenden Merkmale und Funktionen werden von der farbbasierten Zuordnung von VPN-Diensten unterstützt:

  • BGP Layer 2 VPN (Kompella Layer 2 VPN)

  • BGP-EVPN

  • Auflösungskarte mit einer einzigen IP-Farboption.

  • Farbige IPv4- und IPv6-Protokollauflösung für den nächsten Hop.

  • Routing-Informationsdatenbank (auch als Routing-Tabelle bezeichnet) gruppenbasiertes Fallback auf LDP-LSP in der Routing-Tabelle inetcolor.0.

  • Farbiges SR-TE LSP.

  • Virtuelle Plattformen.

  • 64-Bit-Junos-Betriebssystem.

  • Logische Systeme.

  • BGP mit Unicast-Bezeichnung.

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

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

  • Layer-2-Schaltung

  • Automatisch erkanntes FEC-129 BGP und LDP-signalisiertes 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 zu übergeben: Bidirectional Forwarding Detection (BFD) und LDP-Tunneling.

Wenn ein PCE-initiierter Segment-Routing-LSP erstellt wird, wird der LSP anhand von Richtlinienanweisungen (falls vorhanden) überprüft, und wenn eine Übereinstimmung vorliegt, wendet die Richtlinie die konfigurierte Vorlage für diesen LSP an. Die Vorlagenkonfiguration wird nur dann übernommen, wenn sie nicht von der LSP-Quelle (PCEP) bereitgestellt wird. Beispiel: Metrik.

So konfigurieren Sie eine Vorlage:

  1. Fügen Sie die source-routing-path-template-Anweisung auf Hierarchieebene ein.source-routing-path-template[edit protocols source-packet-routing] Hier können Sie die zusätzlichen BFD- und LDP-Tunneling-Parameter konfigurieren.

  2. Fügen Sie die source-routing-path-template-map-Anweisung auf Hierarchieebene ein, um die Richtlinienanweisungen aufzulisten, anhand derer der PCE-initiierte LSP überprüft werden soll.https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/source-routing-path-template-map-edit-protocols-source-packet-routing.html[edit protocols source-packet-routing]

  3. Definieren Sie eine Richtlinie, um die Sprachdienstleister aufzulisten, auf die die Vorlage angewendet werden soll.

    Die Anweisung kann entweder den LSP-Namen oder einen regulären LSP-Ausdruck enthalten, wobei die Übereinstimmungsbedingungen und verwendet werden.fromlsplsp-regex Diese Optionen schließen sich gegenseitig aus, sodass Sie zu einem bestimmten Zeitpunkt nur eine Option angeben können.

    Die Anweisung muss die Option mit einer accept-Aktion enthalten.thensr-te-template Dadurch wird die Vorlage auf den PCE-initiierten LSP angewendet.

Beachten Sie Folgendes, wenn Sie eine Vorlage für PCE-initiierte Sprachdienstleister konfigurieren:

  • Die Vorlagenkonfiguration gilt nicht für statisch konfigurierte Segment-Routing-LSPs oder Segment-Routing-LSPs eines anderen Clients.

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

  • PCEP LSP übernimmt nicht die Konfiguration der Vorlagensegmentliste.

Beispiel: Konfigurieren des statischen Segment-Routing-Label-Switching-Pfads

In diesem Beispiel wird gezeigt, wie LSPs (Label Switched Paths) für statisches Segment-Routing in MPLS-Netzwerken konfiguriert werden. Diese Konfiguration trägt dazu bei, MPLS-Netzwerken eine höhere Skalierbarkeit zu verleihen.

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, das auf allen Routern ausgeführt wird

Bevor Sie beginnen, stellen Sie sicher, dass Sie die Geräteschnittstellen konfiguriert haben.

Überblick

Junos OS: Eine Reihe von expliziten Segment-Routing-Pfaden wird auf dem Eingangsrouter eines nicht eingefärbten statischen Segment-Routing-Tunnels konfiguriert, indem die Anweisung auf Hierarchieebene konfiguriert wird.segment-list[edit protocols source-packet-routing] Sie können den Segmentroutingtunnel konfigurieren, indem Sie die Anweisung auf Hierarchieebene konfigurieren.source-routing-path[edit protocols source-packet-routing] Der Segment-Routing-Tunnel verfügt über eine Zieladresse und einen oder mehrere primäre Pfade und optional sekundäre Pfade, die auf die Segmentliste verweisen. Jede Segmentliste besteht aus einer Sequenz von Hops. Bei nicht eingefärbten statischen Segment-Routing-Tunneln gibt der erste Hop der Segmentliste eine unmittelbare IP-Adresse für den nächsten Hop an, und der zweite bis N-te Hop gibt die Segmentidentifikations-Labels (SID) an, die der Verbindung oder Knoten entsprechen, den der Pfad durchquert. Die Route zum Ziel des Segment-Routing-Tunnels ist in der Tabelle inet.3 installiert.

Topologie

Konfigurieren Sie in diesem Beispiel Layer-3-VPN auf den Provider-Edge-Routern PE1 und PE5. Konfigurieren Sie das MPLS-Protokoll auf allen Routern. Der Segment-Routing-Tunnel wird von Router PE1 zu Router PE5 konfiguriert, wobei ein primärer Pfad auf Router PE1 und Router PE5 konfiguriert ist. Router PE1 ist auch mit einem sekundären Pfad für den Pfadschutz konfiguriert. Die Transit-Router PE2 bis PE4 sind mit benachbarten SID-Labels mit Label-Pop und einer ausgehenden Schnittstelle konfiguriert.

Abbildung 10: Statisches Segment-Routing-Label Switched-PfadStatisches Segment-Routing-Label Switched-Pfad

Konfiguration

CLI-Schnellkonfiguration

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

PE1

PE2

PE3

PE4

PE5

CE1

CE2

Konfigurieren des Geräts PE1
Schritt-für-Schritt-Anleitung

Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Weitere Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI-Benutzerhandbuch.Verwenden des CLI-Editors im Konfigurationsmodushttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html

So konfigurieren Sie Gerät PE1:

  1. Konfigurieren Sie die Schnittstellen.

  2. Konfigurieren Sie die autonome Systemnummer und -optionen, um die Routing-Optionen für die Paketweiterleitung zu steuern.

  3. Konfigurieren Sie die Schnittstellen mit dem MPLS-Protokoll und 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 Bezeichnungen der primären und sekundären Pfade für Source Routing-Traffic Engineering (TE)-Richtlinien des Protokollquellenpaket-Routings (SPRING).

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

  8. Konfigurieren Sie Richtlinienoptionen.

  9. Konfigurieren Sie BGP-Community-Informationen.

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

Ergebnisse

Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie die Befehle , , , und eingeben.show interfacesshow policy-optionsshow protocolsshow routing-optionsshow routing-instances Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Konfigurieren von Gerät PE2
Schritt-für-Schritt-Anleitung

Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Weitere Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI-Benutzerhandbuch.Verwenden des CLI-Editors im Konfigurationsmodushttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html

  1. Konfigurieren Sie die Schnittstellen.

  2. Konfigurieren Sie den statischen LSP für das MPLS-Protokoll.

  3. Konfigurieren Sie Schnittstellen und den statischen Bezeichnungsbereich für das MPLS-Protokoll.

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

Ergebnisse

Bestätigen Sie im Konfigurationsmodus auf dem Router PE2 Ihre Konfiguration, indem Sie die Befehle und eingeben.show interfacesshow protocols Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Überprüfung

Vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.

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

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

Was

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

Bedeutung

Die Ausgabe zeigt die Eingangsrouten von Segmentrouting-Tunneln an.

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

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

Was

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

Bedeutung

In der Ausgabe werden die SID-Bezeichnungen der Segmentrouting-Tunnel angezeigt.

Verifizieren des SPRING Traffic Engineered LSP des Routers PE1
Zweck

Überprüfen Sie die für den Datenverkehr entwickelten SPRING-LSPs auf den Eingangsroutern.

Was

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

Bedeutung

Die Ausgabe zeigt die Übersicht der SPRING Traffic Engineering-LSPs auf dem Eingangsrouter an.

Verifizieren von SPRING Traffic Engineered LSPs auf dem Eingangsrouter des Routers PE1
Zweck

Überprüfen Sie die SPRING Traffic Engineering-LSPs auf dem Eingangsrouter.

Was

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

Bedeutung

Die Ausgabe zeigt Details zu SPRING Traffic Engineered 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.

Was

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

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

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

Was

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

Bedeutung

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

Aktivieren von verteiltem 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 verteilten LSP-Funktion "Constrained Shortest Path First" (CSPF) für das Segment-Routing können Sie einen LSP für das Segment-Routing lokal auf dem Eingangsgerät gemäß den von Ihnen konfigurierten Einschränkungen berechnen. Mit dieser Funktion werden die Sprachdienstleister basierend auf den konfigurierten Einschränkungen und dem Metriktyp (Traffic Engineering oder IGP) optimiert. Die Sprachdienstleister werden so berechnet, dass sie die verfügbaren ECMP-Pfade zum Ziel nutzen, wobei die Komprimierung des Segment-Routing-Label-Stacks aktiviert oder deaktiviert ist.

Verteilte CSPF-Berechnungseinschränkungen

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

Die verteilte CSPF-Berechnungsfunktion unterstützt die folgende Teilmenge von Einschränkungen, die im Internet-Entwurf, draft-ietf-spring-segment-routing-policy-03.txt, Segment Routing Policy for Traffic Engineering, angegeben sind:

  • Ein- und Ausschluss administrativer Gruppen.

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

    HINWEIS:

    Sie können nur Router-IDs in den lockeren oder strikten Hop-Einschränkungen angeben. Bezeichnungen und andere IP-Adressen können in Junos OS Version 19.2R1-S1 nicht als lockere oder strikte Hop-Einschränkungen angegeben werden.

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

  • Maximale Anzahl von Segmentlisten pro Kandidatensegment-Routing-Pfad.

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

  • IPV6-Adressen.

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

  • Nicht nummerierte Schnittstellen.

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

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

  • Ein- und Ausschließen von Schnittstellen-IP-Adressen als Einschränkungen.

Verteilter CSPF-Berechnungsalgorithmus

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

Aktivierte Etikettenstapelkomprimierung

Ein komprimierter Etikettenstapel stellt eine Reihe von Pfaden von einer Quelle zu einem Ziel dar. Sie besteht in der Regel aus Knoten-SIDs und benachbarten SIDs. Wenn die Label-Stack-Komprimierung aktiviert ist, ist das Ergebnis der Berechnung eine Reihe von Pfaden, die ECMP bis zum Ziel maximieren, mit einer minimalen Anzahl von SIDs im Stack, während gleichzeitig Einschränkungen eingehalten werden.

Label-Stack-Komprimierung deaktiviert

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

  • Die Kosten für alle Segmentlisten entsprechen und entsprechen denen der kürzesten Traffic-Engineering-Metrik, um das Ziel zu erreichen.

  • Jede Segmentliste enthält benachbarte SIDs.

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

  • Keine zwei Segmentlisten sind identisch.

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

Verteilte CSPF-Berechnungsdatenbank

Die Datenbank, die für die SR-TE-Berechnung verwendet wird, enthält alle Links, Knoten, Präfixe und deren Merkmale, unabhängig davon, ob in diesen Werbeknoten Traffic-Engineering aktiviert ist. Mit anderen Worten, es ist die Vereinigung der Traffic-Engineering-Datenbank (TED) und der IGP-Link-State-Datenbank aller Domänen, aus denen der Rechenknoten gelernt hat. Damit CSPF funktioniert, müssen Sie die Anweisung daher auf Hierarchieebene einschließen.igp-topology[edit protocols isis traffic-engineering]

Konfigurieren verteilter CSPF-Berechnungseinschränkungen

Sie können ein Computeprofil verwenden, um die Berechnungseinschränkungen logisch zu gruppieren. Auf diese Computeprofile wird von den Segmentroutingpfaden für die Berechnung der primären und sekundären Segmentrouting-LSPs verwiesen.

Um ein Computeprofil zu konfigurieren, schließen Sie die compute-profile-Anweisung auf Hierarchieebene ein.compute-profile[edit protocols source-packet-routing]

Die Konfiguration für die unterstützten Berechnungseinschränkungen umfasst:

  • Administrative groups

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

    Um die Berechnungseinschränkungen zu konfigurieren, können Sie drei Kategorien für eine Gruppe von administrativen Gruppen angeben. Die Konfiguration der Berechnungseinschränkung kann für alle Routingpfade für Kandidatensegmente oder unter einzelnen Kandidatenpfaden gelten.

    • include-any– Gibt an, dass jede Verknüpfung mit mindestens einer der konfigurierten administrativen Gruppen in der Liste für den zu durchlaufenden Pfad akzeptabel ist.

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

    • exclude– Gibt an, dass jeder Link, der keine der konfigurierten administrativen Gruppen in der Liste enthält, für den zu durchlaufenden Pfad akzeptabel ist.

  • Explicit path

    Sie können eine Reihe von Router-IDs im Computeprofil als Einschränkung für die Berechnung der SR-TE-Kandidatenpfade angeben. Jeder Hop muss eine IPv4-Adresse sein und kann vom Typ strict oder loose sein. Wenn der Typ eines Hops nicht konfiguriert ist, wird strict verwendet. Sie müssen die Option unter der segment-list-Anweisung einschließen, wenn Sie die explizite Pfadeinschränkung angeben.computesegment-list

  • Maximum number of segment lists (ECMP paths)

    Sie können einen Kandidatenpfad mit einer Reihe dynamischer Segmentlisten verknüpfen. 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 der Pfadberechnung mit oder ohne Komprimierung.

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

    Sie können dieses Attribut mit der Option unter der Konfigurationsanweisung compute-profile konfigurieren.maximum-segment-list-depth maximum-segment-list-depthcompute-profile

  • Protected or unprotected adjacency SIDs

    Sie können geschützte oder ungeschützte Nachbarschafts-SID als Einschränkung unter dem Computeprofil konfigurieren, um Verknüpfungen mit dem angegebenen SID-Typ zu vermeiden.compute-profile

  • Metric type

    Sie können den Typ der Metrik auf dem Link angeben, der für die Berechnung verwendet werden soll. Standardmäßig verwenden SR-TE-Sprachdienstleister für die Berechnung Traffic-Engineering-Metriken der Verbindungen. 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 Konfiguration vom Typ "metric" im Computeprofil verwenden.

    Sie können dieses Attribut mit der Option unter der Konfigurationsanweisung compute-profile konfigurieren.metric-type (igp | te)compute-profile

Verteilte CSPF-Berechnung

Die SR-TE-Kandidatenpfade werden lokal so berechnet, dass sie die konfigurierten Einschränkungen erfüllen. Wenn die Label-Stack-Komprimierung deaktiviert ist, ist das Ergebnis der Multi-Path-CSPF-Berechnung ein Satz von Adjacency-SID-Stacks. Wenn die Label-Stack-Komprimierung aktiviert ist, ist das Ergebnis ein Satz komprimierter Label-Stacks (bestehend aus benachbarten SIDs und Knoten-SIDs).

Wenn sekundäre Pfade berechnet werden, werden die Verbindungen, Knoten und SRLGs, die von den primären Pfaden verwendet werden, für die Berechnung nicht vermieden. Weitere Informationen zu primären und sekundären Pfaden finden Sie unter Konfigurieren von primären und sekundären LSPs.Konfigurieren von primären und sekundären Sprachdienstleistern

Für alle Sprachdienstleister mit erfolglosem Berechnungsergebnis wird die Berechnung als TED-Änderungen (Traffic Engineering Database) wiederholt.

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

Gewichtungen, die mit Pfaden einer SR-TE-Richtlinie verknüpft sind

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, für den die Berechnung aktiviert ist, kann jedoch zu mehreren Segmentlisten führen. Diese berechneten Segmentlisten werden untereinander als ECMP behandelt. Sie können diesen Segmenten hierarchische ECMP-Gewichtungen zuweisen, wobei die Gewichtungen berücksichtigt werden, die den einzelnen konfigurierten primären Segmenten zugewiesen sind.

BFD-Lebendigkeitserkennung

Sie können die BFD-Lebendigkeitserkennung 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, daher werden die BFD-Parameter, die für die Segmentlisten konfiguriert sind, auf alle berechneten Segmentlisten angewendet. Wenn alle aktiven Primärpfade ausfallen, wird der vorprogrammierte Sekundärpfad (falls vorhanden) aktiv.

inherit-label-nexthops

Sie müssen die Konfiguration in der Hierarchie für die berechneten primären oder sekundären Pfade nicht explizit aktivieren, da dies ein Standardverhalten ist.inherit-label-nexthops[edit protocols source-packet-routing segment-list segment-list-name]

Automatische Übersetzungsfunktion

Sie können die automatische Übersetzungsfunktion für die Segmentlisten konfigurieren, und die primären oder sekundären Pfade mit der automatischen Übersetzungsfunktion verweisen auf diese Segmentlisten. Andererseits kann die primäre oder sekundäre Funktion, auf der die Berechnungsfunktion aktiviert ist, nicht auf eine Segmentliste verweisen. Daher können Sie nicht sowohl die Compute-Funktion als auch die automatische Übersetzungsfunktion für einen bestimmten primären oder sekundären Pfad aktivieren. Sie können jedoch einen LSP mit einem primären Pfad mit dem Typ "Compute" und einen anderen mit dem Typ "Automatische Übersetzung" konfigurieren.

Beispielkonfigurationen für verteilte CSPF-Berechnungen

Beispiel 1

In Beispiel 1

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

  • Für eine berechnete primäre Segmentliste sollte ein Name konfiguriert sein, und dieser Name sollte nicht auf eine konfigurierte Segmentliste verweisen. In diesem Beispiel handelt es sich nicht um eine konfigurierte Segmentliste.compute_segment1

  • Das Compute-Profil wird auf den primären Pfad mit dem Namen angewendet.compute_profile_redcompute_segment1

  • Das compute-profile enthält eine Segmentliste vom Typ , die verwendet wird, um die explizite Pfadeinschränkung für die Berechnung anzugeben.compute_profile_redcompute

Die Gewichtungen für berechnete Pfad-Next-Hops und statische Next-Hops sind 2 bzw. 3. Unter der Annahme, dass die nächsten Hops für berechnete Pfade , , und sind und der nächste Hop für den statischen Pfad ist, werden die Gewichtungen wie folgt angewendet:comp_nh1comp_nh2comp_nh3static_nh

Nächster Hop

Gewicht

comp_nh1

2

comp_nh2

2

comp_nh3

2

static_nh

9

Beispiel 2

In Beispiel 2 können sowohl der primäre als auch der sekundäre Pfad vom Typ "compute" sein und über eigene Computeprofile verfügen.

Beispiel 3

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

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

SUMMARY CoS-basiertes Weiterleiten (CBF) und richtlinienbasiertes Routing (PBR, auch als filterbasierte Weiterleitung bezeichnet) können für LSPs ohne farbiges Segment-Routing-Traffic Engineering (SR-TE) aktiviert werden, um selektiven Datenverkehr über einen expliziten SR-TE-Pfad zu leiten und Ihnen den Vorteil zu bieten, dass der Datenverkehr auf der Grundlage einer Serviceklasse oder einer Richtlinie bedient wird.

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

Vorteile von CoS-basierter Weiterleitung (CBF) und richtlinienbasiertem Routing (PBR) für SR-TE-Sprachdienstleister

Mit CBF und PBR können Sie:

  • Verwenden Sie Kombinationen von Segment-Routing-Traffic Engineering (SR-TE)-Pfaden, um den Servicedatenverkehr im Core zu steuern.

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

Segment-Routing-Pfadquellen, die CBF und PBR unterstützen

Die folgenden Segment-Routing-Pfadquellen unterstützen CoS-basierte Weiterleitung und richtlinienbasiertes Routing:

  • Static SR–TE paths: Statisch konfigurierte Quell-Routing-Pfade, bei denen der gesamte Beschriftungsstapel statisch konfiguriert ist.

  • PCEP– Dynamische Bereitstellung von Source-Routing-Pfaden, die auf einem Controller erstellt und auf einen Eingangsrouter in einem ERO heruntergeladen wurden, entweder über PCEP-Segment-Routing-Erweiterungen oder in einer BGP-Segment-Routing-Richtlinie über BGP-Segment-Routing-Erweiterungen.

  • Dynamic LSPs– Dynamisch erstellte Tunnel, die durch das Dynamic Tunnel Module 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-Sprachdienstleister

Merken:

  • CBF und PBR sind nur für nicht farbige SR-TE-LSPs aktiviert, die entweder statisch oder dynamisch konfiguriert sind.

  • Sowohl CBF- als auch PBR-Konfigurationen für SR-TE-LSPs können auf einem Gerät nebeneinander existieren. Die Reihenfolge der Konfiguration entscheidet über die Art der Weiterleitung der Routen.

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

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

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

Konfigurieren von CoS-basierter Weiterleitung und richtlinienbasiertem Routing für SR-TE-Sprachdienstleister

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

Vorbereitungen

  • 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 wie folgt vor, um einen SR-TE LSP zu konfigurieren:

  1. Definieren Sie die Segmentliste mit Beschriftungsparametern.

    Hier einige Zahlen zum Generationswechsel:

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

    Hier einige Zahlen zum Generationswechsel:

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

Gehen Sie wie folgt vor, um CBF zu konfigurieren

  1. Definieren Sie DSCP-Klassifizierer (Differentiated Services Code Point), um eingehende IPv4-Pakete, Weiterleitungsklassen und Optionswerte zu verarbeiten.

    Hier einige Zahlen zum Generationswechsel:

  2. Definieren Sie Weiterleitungsklassen (FCs) zum Gruppieren von Paketen für die Übertragung und Zuweisen von Paketen zu Ausgabewarteschlangen.

    Hier einige Zahlen zum Generationswechsel:

  3. Ordnen Sie die konfigurierten Klassifikatoren den Geräteschnittstellen zu.

    Hier einige Zahlen zum Generationswechsel:

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

    Hier einige Zahlen zum Generationswechsel:

  5. Verwerfen Sie Datenverkehr, der keiner Weiterleitungsklasse in der Zuordnung des nächsten Hops entspricht.

    Hier einige Zahlen zum Generationswechsel:

  6. Konfigurieren Sie eine Richtlinienanweisung, die angibt, dass Routen, die dem Routenfilter entsprechen, der CoS-Zuordnung für den nächsten Hop unterliegen, die durch map-name angegeben wird.

    Hier einige Zahlen zum Generationswechsel:

  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.

    Hier einige Zahlen zum Generationswechsel:

  8. Bestätigen Sie die Konfiguration.

Verify CBF Configuration

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

Bei CBF ist die klassenbasierte Weiterleitung von Routen nur in der Weiterleitungstabelle sichtbar, im Gegensatz zu PBR, bei dem die gefilterten Routen in der Befehlsausgabe sichtbar sind.show route

Gehen Sie wie folgt vor, um PBR zu konfigurieren

  1. Konfigurieren Sie eine Richtlinienanweisung, die angibt, dass Routen, die dem Protokoll und dem Routenfilter entsprechen, dem nächsten LSP-Hop unterliegen oder als ECMP (Equal-Cost Multipath) in der Weiterleitungstabelle einen Lastenausgleich erhalten.

    Hier einige Zahlen zum Generationswechsel:

  2. Konfigurieren Sie das Gerät so, dass es eine benutzerdefinierte Routenauflösung für die nächsten Hops von Routen durchführt.

    HINWEIS:

    Die Anweisung ist zwingend erforderlich, damit PBR funktioniert, wenn der erste Hop des SR-TE LSP ein Label ist.resolution preserve-nexthop-hierarchy

  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.

    Hier einige Zahlen zum Generationswechsel:

  4. Bestätigen Sie die Konfiguration.

Verify PBR Configuration

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

In der Ausgabe werden alle Next-Hops für das Zielpräfix 4.0.0.1 angezeigt. In den Optionen werden die gefilterten Next-Hops unter dem Ausgabefeld angezeigt.expanded-nh extensiveKrt_inh

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

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. Es wird nur eine sekundäre Pfadkonfiguration unterstützt, und zwar 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 propagieren.

Vorteile mehrerer Pfade für PCEP SR-TE LSPs

  • Sprachdienstleister können mehrere Sätze von EROs für ein Ziel haben

  • Bietet Load-Balancing-Funktionen durch Konfiguration von Gewichtungen für einzelne EROs

  • Entspricht dem SR-TE-Architekturentwurf zur Definition von Kandidatenpfaden

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 gesteuerten Kandidatenpfad konfigurieren.

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

Wenn Sie PCEP-Multipaths aktivieren, kann jetzt die maximale Anzahl von Segmentlisten () größer als 1 konfiguriert werden.compute-profilemaximum-computed-segment-lists

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 Konfiguration des sekundären Pfads 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. Primäre Pfade enthalten die MULTIPATH-BACKUP-TLV nicht in der PCRpt-Nachricht. Der sekundäre Pfad enthält MULTIPATH-BACKUP-TLV mit gesetztem Backup-Flag.

Die folgenden PCEP-Multipath-Funktionalitäten werden unterstützt:

  • Mehrwegegewichtung TLV (MULTIPATH-WEIGHT-TLV) im Pfadattributobjekt (PATH-ATTRIB)

  • MULTIPATH-BACKUP TLV im Pfadattributobjekt (PATH-ATTRIB) nur für PCC-gesteuerte SR-TE LSPs

  • MULTIPATH-CAP TLV im PCEP LSP-Objekt

  • Schränkt mehrere primäre und sekundäre Pfade im SR-Kandidatenpfad ein, wenn PCEP-Multipath deaktiviert ist

  • Mehrere primäre und sekundäre Pfade im SR-Kandidatenpfad, wenn PCEP-Multipath für PCC-gesteuerte LSPs aktiviert ist

  • Maximal berechnete Segmentlisten () größer als 1 im SR-TE-Computeprofil für delegierte und PCE-initiierte LSPsmax-computed-segment-lists

  • Mehrere EROs für den PCE-initiierten Kandidatenpfad in SR-TE und in PCCD

  • SRv6-Sprachdienstleister

  • SR MPLS (IPv4)

  • Dynamische Tunnel SR MPLS (IPv4)

  • Multi-Controller-Unterstützung

  • Mehrere ERO-Pfade für PCE-initiierte, PCC-konfigurierte und gesteuerte sowie delegierte farbige und ungefärbte Kandidatenpfade

  • Abwärtskompatibel mit früheren Versionen von Paragon Pathfinder. Aus Gründen der Abwärtskompatibilität müssen Sie die Konfigurationsanweisung auf der Hierarchieebene [] konfigurieren.disable-multipath-capabilityedit protocols pcep

  • Fehlercode-Unterstützung für Fehler bei der Validierung von PCE-initiierten Kandidatenpfaden

    • Die Gesamtzahl der Unterkandidatenpfade pro Kandidatenpfad ist auf 127 begrenzt. Wenn bei PCE-initiierten LSPs die Anzahl der ERO-Pfade 127 überschreitet, löst SR-TE ERROR an PCCD aus (und PCCD sendet eine PCEP-Fehlermeldung an PCE), und die entsprechenden ERO-Pfade werden zurückgewiesen.

Die folgenden PCEP-Fehlermeldungen werden unterstützt:

Tabelle 5: PCEP-Fehlermeldungen
Fehlertyp Fehlerwert Bedeutung Verwendung
19 20 Backup-Pfad wird nicht unterstützt Dies tritt auf, wenn MULTIPATH-BACKUP TLV vom PCC empfangen wird.
24 1 Inakzeptable Instanziierungsparameter Dies tritt auf, wenn PCE versucht, mehr als 127 Unterkandidatenpfade pro Kandidatenpfad hinzuzufügen.

Einschränkungen

Es gelten die folgenden PCEP-Einschränkungen:

  • Die folgenden TLVs, die im draft-ietf-pce-multipath-06 erwähnt werden, werden nicht unterstützt:

    • Multipath-Backup-TLV

    • Multipath-Pfad in entgegengesetzter Richtung TLV

    • Zusammengesetzter Kandidatenpfad

  • Wenn die Multipath-Funktion in PCEP deaktiviert ist, ist die Konfiguration mehrerer Unterkandidatenpfade nicht zulässig. Auf Junos-Geräten ohne Multipath-Funktion (Junos OS-Versionen vor 22.4R1) ist jedoch die Konfiguration mehrerer Unterkandidatenpfade zulässig. Wenn PCEP Multi-Segment (standardmäßig) aktiviert ist, sind mehrere primäre Pfade für PCC-gesteuerte LSPs zum Zwecke der Berichterstellung zulässig. Es wird jedoch nur ein primärer Pfad für den delegierten Kandidatenpfad unterstützt, wenn PCEP Multi-Segment aktiviert ist.

  • Admin-Gruppen und andere Einschränkungen werden PCE nicht für PCC-konfigurierte und kontrollierte SR-MPLS- und SRv6-Kandidatenpfade (mit einer 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 Konfiguration des sekundären Pfads nicht zulässig.

  • Kandidatenpfade können keine Mischung aus PCE-initiierten und delegierten LSPs enthalten.

  • Mehrere Unterkandidatenpfade für einen PCE-initiierten farbigen Kandidatenpfad werden nicht unterstützt.

  • Das Delegieren von Features mit mehreren Unterkandidatenpfaden in einem Kandidatenpfad wird nicht unterstützt.

Konfiguration

Damit PCCD Multipath-Funktions-TLV im LSP-Objekt senden kann, um die Liste der maximal berechneten Segmente für einen bestimmten Kandidatenpfad zu benachrichtigen, schließen Sie die Konfigurationsanweisung auf der Hierarchieebene [] ein.propagate-max-segmentlistedit protocols pcep 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 Konfigurationsanweisung auf der Hierarchieebene [] ein.disable-multipath-capabilityedit protocols pcep

Sie können die folgenden Protokoll-Trace-Optionen 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 von Label-Switched-Pfaden (LSPs) an, die dem Path Computation Client (PCC) bekannt sind.

  • user@host> show path-computation-client lsp extensive: Zeigt umfangreiche Ausgabepegel zu jedem bekannten LSP an – Punkt-zu-Punkt- und Punkt-zu-Mehrpunkt-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: Zeigt Eingangsdetails des SPRING-Traffic-Engineerings an.

Aktivieren der Transportschichtsicherheit für PCEP-Sitzungen

Transport Layer Security (TLS) bietet Unterstützung für Peerauthentifizierung, 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) herzustellen, wie in RFC 8253 definiert. Dadurch wird eine sichere PCEP-Sitzung (PCEPS) für den Transport von PCEP-Nachrichten erstellt.

In diesem Dokument wird beschrieben, wie TLS für PCEP-Sitzungen aktiviert wird, um Interaktionen mit PCE zu sichern, einschließlich der Initiierung der TLS-Verfahren, des TLS-Handshake-Mechanismus und der TLS-Methoden für die Peerauthentifizierung. Der sichere 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 (Abfangen von Nachrichten), Fälschung und Denial-of-Service.

  • Nutzt TLS-Sicherheitsvorteile.

Aktivieren von TLS im Path Computation Client (PCC)

Um TLS in PCC zu aktivieren und eine PCEPS-Sitzung einzurichten, legen Sie die CLI-Anweisung auf der Hierarchieebene [] fest.tls-strictedit protocols pcep

Nach der Aktivierung der Konfigurationsanweisung tls-strict treten die folgenden Ereignisse auf:

  1. PCEP-Session-Klappen. Jede vorhandene TCP-Verbindung wird beendet und die Verbindung wird mithilfe von TLS wiederhergestellt.

  2. PCC stellt eine TCP-Verbindung mit dem PCE her.

  3. TLS-Vorgänge werden durch die Nachricht von PCE zu PCC und von PCC zu PCE initiiert.StartTLS Die Nachricht wird von PCC gesendet und der Timer gestartet.StartTLSStartTLSWait Sie können den Timer konfigurieren, indem Sie die CLI-Anweisung auf der Hierarchieebene [] konfigurieren.StartTLSWaitstart-tls-wait-timer secondsedit protocols pcep pce pce-id

    HINWEIS:

    Der empfohlene Wert für den Timer beträgt 60 Sekunden und darf nicht kleiner als der Timer sein.StartTLSWaitOpenWait Der Standardwert für den Timer ist auf 60 Sekunden festgelegt.OpenWait

    • Wenn PCC die Nachricht "Offen" anstelle der Nachricht empfängt, wird die Nachricht mit dem Fehlertyp auf 1 (Fehler beim Aufbau der PCEP-Sitzung) und dem Fehlerwert auf 1 (Empfang einer ungültigen offenen Nachricht oder einer nicht offenen Nachricht) festgelegt, und die TCP-Sitzung wird geschlossen.StartTLSPCErr

    • Wenn keine Nachricht von PCE empfangen wird, sendet PCC nach Ablauf des Timers eine Nachricht, bei der der Fehlertyp auf 25 (PCEP-Fehler) und der Fehlerwert auf 5 (keine Nachricht (noch) vor Ablauf des Zeitgebers festgelegt ist), und die TCP-Sitzung wird geschlossen.StartTLSStartTLSWaitPCErrStartTLSStartTLS PCErr/OpenStartTLSWait

  4. Die Aushandlung und der Aufbau der TLS-Verbindung erfolgt.

  5. Der Austausch von PCEP-Nachrichten wird gemäß RFC5440 gestartet.

HINWEIS:

Wenn Sie die CLI-Anweisung unter der Hierarchieebene [] nicht aktivieren, wird die TCP-Sitzung geschlossen, wenn beim Einrichten einer PCEP-Sitzung die Nachricht von PCC anstelle von Nachricht empfangen wird, wobei der Fehlertyp auf 1 (Fehler beim Aufbau der PCEP-Sitzung) und der Fehlerwert auf 1 (Empfang einer ungültigen Open-Nachricht oder einer nicht offenen Nachricht) festgelegt ist.tls-strictedit protocols pcepStartTLSOpenPCErr

HINWEIS:

Um eine erfolgreiche PCEPS-Sitzung einzurichten, 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 nachverfolgen.

TLS-Verbindung herstellen

Die folgenden Schritte beschreiben, wie eine TLS-Verbindung (mit 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 ein Schlüsselpaar und CSR auf dem Gerät, und senden Sie diese CSR an die Zertifizierungsstelle, um das Zertifikat zu erhalten. Sobald das Zertifikat ausgestellt wurde, wird es auf die Box kopiert und installiert.

    • Method 2– Generieren Sie das Schlüsselpaar und das Zertifikat sofort nach dem Auspacken. Sowohl das Zertifikat als auch der private Schlüssel werden auf das Gerät kopiert und zusammen installiert.

  2. Laden Sie die Zertifizierungsstelle (Certification Authority, CA) auf die PCC, damit das PCE-Serverzertifikat anhand der geladenen CA validiert werden kann.

    HINWEIS:

    Zertifizierungsstellen können in flacher Hierarchie als unabhängige Zertifizierungsstelle geladen werden. Wenn es sich bei einer Zertifizierungsstelle um eine untergeordnete Zertifizierungsstelle einer anderen Zertifizierungsstelle handelt, wird die Kette intern von PKI erstellt.

    HINWEIS:

    Das Serverzertifikat sollte von einer Zertifizierungsstelle signiert sein. Selbstsignierte Zertifikate sind nicht zulässig.

  3. Aktivieren Sie TLS auf PCC.

  4. Die PCEP-Sitzung wird über TLS mit TLS-Handshake-Mechanismus eingerichtet.

  5. Der PCE-Server überwacht Port 4189 auf eingehende PCC-Verbindungsanforderungen über TLS.

  6. PCC initiiert die Verbindungsanforderung an den Zielport 4189.

  7. Nach Abschluss eines Drei-Wege-Handshakes beginnt der TLS-Handshake mit der Verwendung der Zertifikate, und die unidirektionale Authentifizierung wird durchgeführt (PCC authentifiziert das Serverzertifikat). Sowohl der Server als auch der Client warten auf die Zeit, bis die Nachricht empfangen wird.StartTLSWaitStartTLS Sie können den Timer konfigurieren, indem Sie die CLI-Anweisung auf der Hierarchieebene [] konfigurieren.StartTLSWait start-tls-wait-timer secondsedit protocols pcep pce pce-id

    HINWEIS:

    Der empfohlene Wert für den Timer beträgt 60 Sekunden und darf nicht kleiner als der Timer sein.StartTLSWaitOpenWait Der Standardwert für den Timer ist auf 60 Sekunden festgelegt.OpenWait

  8. Nach der erfolgreichen TLS-Handshake-Sitzung initiieren PCC und PCE den Aufbau einer PCEP-Sitzung über TLS, bei der die Sitzungsparameter ausgehandelt werden.

    • Wenn die Zertifikatsüberprüfung fehlschlägt, beendet PCC die TCP-Verbindung.

  9. Die PCEP-Nachricht wird über eine TLS-Verbindung als Anwendungsdaten gesendet.

  10. Die Ver- 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-over-TLS-Sitzung abgelaufen, gesperrt oder neu geladen wird, ist die laufende Sitzung nicht betroffen.

Grundlegendes zum TLS-Handshake-Mechanismus

Der Handshake ist eine Reihe von Nachrichten, die zwischen einem Server und einem Client ausgetauscht werden. Die genauen Schritte des Handshakes variieren je nach Schlüsselaustauschalgorithmus, Verschlüsselungssammlung usw. Im Folgenden sind die grundlegenden Schritte des TLS-Handshake-Mechanismus aufgeführt:

  1. Client Hello– Der Client initiiert den Handshake, indem er diese Nachricht sendet. Diese Nachricht enthält die TLS-Version, eine Liste der unterstützten kryptografischen Algorithmen oder Cipher Suite und andere Clientdetails.

  2. Server Hello– Der Server antwortet auf Client Hello, indem er die Sever Hello-Nachricht sendet. Diese Nachricht enthält das Serverzertifikat, den ausgewählten kryptografischen Algorithmus, die Sitzungs-ID und den öffentlichen Schlüssel des Servers.

  3. Authentication– Der Client überprüft im Hintergrund das Zertifikat des Servers mit der konfigurierten Zertifizierungsstelle, die das Zertifikat ausgestellt hat. Nach erfolgreicher Überprüfung bestätigt der Client, dass der Server echt ist, und fährt mit der Interaktion fort.

  4. Optional Client Certificate– Wenn der Server ein Zertifikat vom Client in der Server-Hallo-Nachricht angefordert hat, sendet der Client das Client-Zertifikat (nur bei gegenseitigem TLS).

  5. Client Key Exchange– Der Client sendet einen geheimen Schlüssel, der mit dem öffentlichen Schlüssel des Servers verschlüsselt ist (der in der Nachricht "Server Hello" abgerufen wurde).

  6. Decrypt secret key– Der Server entschlüsselt den geheimen Schlüssel mit dem privaten Schlüssel.

  7. Client Finished– Der Client sendet eine Finish-Nachricht, die mit dem gemeinsamen geheimen Schlüssel verschlüsselt ist und signalisiert, dass der Handshake abgeschlossen ist.

  8. Server Finished– Der Server antwortet mit einer Ende-Nachricht, die mit dem gemeinsamen geheimen Schlüssel verschlüsselt ist und signalisiert, dass der Handshake abgeschlossen ist.

  9. Exchange Messages—Die Nachrichten nach Abschluss des Handshakes werden symmetrisch verschlüsselt.

Diagnostizieren und Validieren von TLS für PCEP-Sitzungen

Verwenden Sie für die Diagnose die folgenden traceoptions CLI-Anweisungen:

Aktivieren Sie PKI-Protokolle mit der folgenden Konfiguration, und erfassen Sie dieselbe Datei aus /var/log/<filename>

Überprüfen Sie das geladene CA-Zertifikat mit dem folgenden Befehl:

Beispielausgabe

Im Folgenden finden Sie ein Beispiel für eine Ausgabe des Befehls:show path-computation-client statistics

Diese Beispielausgabe enthält die folgenden Informationen:

  • TLS ist bei PCC aktiviert.

  • PCE ist TLS-fähig.

  • Die TLS-Sitzung wird eingerichtet. Dies zeigt auch an, dass das PCE-Serverzertifikat gültig ist.

  • Der Status der PCEPS-Sitzung ist "Aktiv und wird ausgeführt".

Berichtspfadoptimierung und berechnete Metriken in PCEP

Das metrische Objekt in PCEP wird für verschiedene Zwecke verwendet. Das Metrikobjekt gibt den Metriktyp an, der für die Pfadoptimierung verwendet wird. Das Metrikobjekt gibt auch eine Grenze für 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 Metrikobjekte für die Pfadoptimierung (Interior Gateway Protocol, Traffic Engineering und Pfadverzögerung) und die Berichterstellung der berechneten Metrik für RSVP- und SR-TE-LSPs.

HINWEIS:

Das Metrikobjekt für die Pfadoptimierung und die Berichterstellung der berechneten Metrik gilt nicht für SRv6-TE-LSPs.

Vorteile der Berichtspfadoptimierung und der berechneten Metriken in PCEP

  • Die Berichterstellung von in PCC konfigurierten Pfadoptimierungsmetriken hilft PCE, die Einschränkungen zu kennen, die für die Pfadberechnung verwendet werden.

  • Reporting der berechneten Metriken an die PCE. Dies hilft PCE zu analysieren, ob der LSP weiter optimiert werden muss.

Grundlegendes zu 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) so, dass die konfigurierte Metrik über PCEP gemeldet wird. Die berechnete Metrik wird als tatsächliche Metrik in PCEP über die PCRpt-Nachricht gesendet.

Delegierte 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 Optimierungsmetrik zum Zeitpunkt der Delegierung von LSP konfiguriert ist, werden die Informationen per PCRpt-Nachricht an PCE gesendet.

  • Wenn die Optimierungsmetrik nach der Delegierung von LSP konfiguriert wird, wird die Änderung auf den LSP angewendet bzw. an den PCE kommuniziert, wenn der LSP-Steuerungsstatus lokal gesteuert wird.

  • Wenn eine PCUpd-Nachricht empfangen wird und die Optimierungsmetrik in der Nachricht vorhanden ist, wird die Metrik wie vorgesehene Metrik in nachfolgenden PCRpt-Nachrichten verwendet, bis der LSP-Steuerungsstatus extern gesteuert wird.

  • Wenn beim Empfang einer PCUpd-Nachricht keine Optimierungsmetrik in der Nachricht vorhanden ist, enthalten nachfolgende PCRpt-Nachrichten keine beabsichtigte Metrik.

  • Wenn sich der LSP-Steuerungsstatus in "Lokal gesteuert" ändert, ist die über die Junos CLI konfigurierte Optimierungsmetrik die beabsichtigte Metrik in der PCRpt-Nachricht.

Actual Metric:

  • Beim Delegieren des LSP enthält die PCRpt-Nachricht keine tatsächliche Metrik.

  • Wenn eine PCUpd-Nachricht empfangen wird und die berechnete Metrik in der Nachricht vorhanden ist, wird die Metrik als tatsächliche Metrik in nachfolgenden PCRpt-Nachrichten verwendet, bis der LSP-Steuerungsstatus extern gesteuert wird.

  • Wenn beim Empfang einer PCUpd-Nachricht keine berechnete Metrik in der Nachricht vorhanden ist, enthalten nachfolgende PCRpt-Nachrichten keine tatsächliche Metrik.

  • Wenn sich der LSP-Steuerungsstatus in "Lokal gesteuert" ändert, wird die von PCC berechnete Metrik als tatsächliche Metrik in der PCRpt-Nachricht gesendet.

PCE-initiierte 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-initiierten 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 in lokal gesteuert ändert.

  • Wenn eine PCInit/PCUpd-Nachricht empfangen wird und die Optimierungsmetrik in der Nachricht vorhanden ist, wird die Metrik als vorgesehene Metrik in nachfolgenden PCRpt-Nachrichten verwendet, bis der LSP-Steuerungsstatus extern gesteuert wird.

  • Wenn eine PCInit/PCUpd-Nachricht empfangen wird und die Optimierungsmetrik in der Nachricht nicht vorhanden ist, enthalten nachfolgende PCRpt-Nachrichten 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 als tatsächliche Metrik in nachfolgenden PCRpt-Nachrichten verwendet, bis der LSP-Steuerungsstatus extern gesteuert wird.

  • Wenn eine PCInit/PCUpd-Nachricht empfangen wird und die berechnete Metrik nicht in der Nachricht vorhanden ist, enthalten nachfolgende PCRpt-Nachrichten keine tatsächliche Metrik.

  • Wenn sich der LSP-Steuerungsstatus in "Lokal gesteuert" ändert, wird die von PCC berechnete Metrik als tatsächliche Metrik in der PCRpt-Nachricht 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 Optimierungsmetrik zum Zeitpunkt der Delegierung von LSP konfiguriert ist, werden die Informationen über die PCRpt-Nachricht an den PCE gesendet.

  • Wenn die Optimierungsmetrik nach der Delegierung von LSP konfiguriert wird, wird die Änderung auf den LSP angewendet bzw. an den PCE kommuniziert, wenn der LSP-Steuerungsstatus lokal gesteuert wird.

  • Wenn eine PCUpd-Nachricht empfangen wird und die Optimierungsmetrik in der Nachricht vorhanden ist, wird die Metrik wie vorgesehene Metrik in nachfolgenden PCRpt-Nachrichten verwendet, bis der LSP-Steuerungsstatus extern gesteuert wird.

  • Wenn beim Empfang einer PCUpd-Nachricht keine Optimierungsmetrik in der Nachricht vorhanden ist, enthalten nachfolgende PCRpt-Nachrichten keine beabsichtigte Metrik.

  • Wenn sich der LSP-Steuerungsstatus in "Lokal gesteuert" ändert, ist die über die Junos CLI konfigurierte Optimierungsmetrik die beabsichtigte Metrik in der PCRpt-Nachricht.

Actual Metric:

  • Wenn LSP nach der Erstellung delegiert wird, werden zum Zeitpunkt der LSP-Delegierung, wenn LSP über 1 ERO verfügt, berechnete Werte von IGP-, TE- und Verzögerungsmetriken als tatsächliche Metriken in der PCRpt-Nachricht gesendet.

  • Wenn LSP nach der Erstellung delegiert wird, wird zum Zeitpunkt der LSP-Delegierung, wenn LSP über mehrere EROs verfügt, die berechnete Metrik/Ist-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 die berechnete Metrik in der Nachricht vorhanden ist, wird die Metrik als tatsächliche Metrik in nachfolgenden PCRpt-Nachrichten verwendet, bis der LSP-Steuerungsstatus extern gesteuert wird.

  • Wenn beim Empfang einer PCUpd-Nachricht keine berechnete Metrik in der Nachricht vorhanden ist, enthalten nachfolgende PCRpt-Nachrichten keine tatsächliche Metrik.

  • Wenn sich der LSP-Steuerungsstatus in lokal gesteuert ändert, werden in PCC berechnete IGP-, TE- und Verzögerungsmetriken 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 eine PCRpt-Nachricht an PCE zurückgemeldet, bis der LSP extern gesteuert wird.

Intended Metric:

  • Wenn eine PCInit/PCUpd-Nachricht empfangen wird und die Optimierungsmetrik in der Nachricht vorhanden ist, wird die Metrik als vorgesehene Metrik in nachfolgenden PCRpt-Nachrichten verwendet, bis der LSP-Steuerungsstatus extern gesteuert wird.

  • Wenn eine PCInit/PCUpd-Nachricht empfangen wird und die Optimierungsmetrik in der Nachricht nicht vorhanden ist, enthalten nachfolgende PCRpt-Nachrichten keine beabsichtigte Metrik.

  • Wenn der LSP-Steuerungsstatus lokal gesteuert wird, wird die gewünschte Metrik nicht gesendet.

Actual Metric:

  • Wenn eine PCInit/PCUpd-Nachricht empfangen wird und die berechnete Metrik in der Nachricht vorhanden ist, wird die Metrik als tatsächliche Metrik in nachfolgenden PCRpt-Nachrichten verwendet, bis der LSP-Steuerungsstatus extern gesteuert wird.

  • Wenn eine PCInit/PCUpd-Nachricht empfangen wird und die berechnete Metrik in der Nachricht nicht vorhanden ist, enthalten nachfolgende PCRpt-Nachrichten keine tatsächliche Metrik.

  • Wenn sich der LSP-Kontrollstatus in "Lokal gesteuert" ändert, enthalten nachfolgende PCRpt-Nachrichten keine tatsächliche Metrik.

Senden einer Optimierungsmetrik in einer PCRpt-Nachricht

Die Optimierungsmetrik wird über die in der PCRpt-Nachricht an den PCE gesendet.intended-attributes-list Der Metrikwert ist auf 0 und die Flags B und C auf 0 festgelegt. Der Metriktyp gibt die zu optimierende Metrik an.

Senden einer berechneten Metrik in einer PCRpt-Nachricht

Die berechnete Metrik wird über die in der PCRpt-Nachricht an den PCE gesendet.actual-attributes-list Der Metrikwert ist der berechnete Metrikwert, und der Metriktyp gibt den berechneten Metriktyp an. Das B-Flag wird auf 0 gesetzt, das C-Flag auf 1.

Abwärtsinkompatibilität für Routenmetrik

Da die Routenmetrik mit der TLV des Anbieters unterstützt wird, verarbeitet PCC keine Routenmetrik, die von Juniper PCE in einem metrischen Objekt gesendet wird, das Northstar und ältere Versionen von Paragon Pathfinder unterstützt.

Konfigurieren von Optimierungsmetriken für Sprachdienstleister

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 CLI-Anweisung auf der Hierarchieebene [] ein.metric-type <igp|te|delay|delay minimum>edit protocols mpls label-switched-path <lsp-name>

Um die IGP-, TE- und Pfadverzögerungsoptimierungsmetriken für SR-TE-LSPs zu konfigurieren, fügen Sie die CLI-Anweisung auf der Hierarchieebene [] ein.metric-type <igp|te|delay|delay minimum>edit protocols source-packet-routing compute-profile <compute-profile-name>

Beispielausgabe

Sie können die Befehle und CLI verwenden, um den Status von Label-Switched-Pfaden (LSPs) anzuzeigen, die dem Path Computation Client (PCC) bekannt sind.show path-computation-client lspshow path-computation-client lsp extensive

Im Folgenden finden Sie eine Beispielausgabe von :show path-computation-client lsp extensive

Die Ausgabe zeigt, dass der LSP mit dem Metriktyp IGP optimiert ist. Der berechnete Wert der IGP-Metrik ist 50. Die in der Routing-Tabelle installierte Route-Metrik ist 50.

Tabellarischer Änderungsverlauf

Die Unterstützung der Funktion hängt von der Plattform und der Version ab, die Sie benutzen. Verwenden Sie Feature Explorer, um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.

Release
Beschreibung
21.R1
Ab Junos OS Version 21.1R1 unterstützt Junos OS Nonstop Active Routing (NSR) für PCE-initiierte RSVP-basierte Punkt-zu-Punkt- und Punkt-zu-Multipunkt-LSPs.
21.R1
Ab Junos OS Version 21.1R1 unterstützt Junos OS Nonstop Active Routing (NSR) für PCE-initiierte RSVP-basierte Punkt-zu-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) sowohl für IPv4- als auch für 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 Punkt-zu-Multipoint-Label-Switched-Pfad (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 zu übergeben: Bidirectional Forwarding Detection (BFD) und LDP-Tunneling.
19.1R1
Ab Junos OS Version 19.1R1 wird eine Commit-Prüffunktion eingeführt, mit der sichergestellt wird, dass in allen Segmentlisten, die zu den farbigen Routen beitragen, die minimale Bezeichnung für alle Hops vorhanden ist.
19.1R1
Ab Junos OS Version 19.1R1 gilt diese Anforderung nicht mehr, da der erste Hop der nicht eingefärbten statischen LSPs jetzt zusätzlich zu den IP-Adressen auch Unterstützung für SID-Bezeichnungen bietet. Mit der Unterstützung von First-Hop-Labels werden MPLS Fast Reroute (FRR) und gewichteter Equal-Cost-Multipath für die Auflösung der statischen, nicht farbigen Segment-Routing-LSPs aktiviert, ähnlich wie bei farbigen statischen LSPs.
18.2R1
Ab Junos OS Version 18.2R1 werden statisch konfigurierte, nicht farbige Segment-Routing-LSPs auf dem Eingangsgerät über eine PCEP-Sitzung (Path Computation Element Protocol) an das Path Computation Element (PCE) gemeldet.
17.2R1
Ab Junos OS Version 17.2 werden zusätzlich zwei neue Pfadberechnungstypen für die PCE-gesteuerten LSPs eingeführt:external cspf und .local cspfno cspf
16.1
Ab Junos OS Version 16.1 können Sie eine PCEP-Sitzung mit der TCP-MD5-Authentifizierung gemäß RFC 5440 sichern.
16.1
Mit Junos OS Version 16.1 wird die Funktion zum Sichern einer PCEP-Sitzung mithilfe der TCP-MD5-Authentifizierung gemäß RFC 5440 eingeführt.
14.2R4
Ab Junos OS Version 14.2R4 wird die automatische Bandbreite für PCE-gesteuerte LSPs unterstützt.