Auf dieser Seite
PCEP-Konfiguration
PCEP -Übersicht
Ein Path Computation Element (PCE) ist eine Entität (Komponente, Anwendung oder Netzwerkknoten), die in der Lage ist, einen Netzwerkpfad oder eine Netzwerkroute basierend auf einem Netzwerkdiagramm zu berechnen und Rechenbeschränkungen anzuwenden. Ein Path Computation Client (PCC) ist jede Clientanwendung, die eine Pfadberechnung zur Durchführung durch einen PCE anfordert. Das Path Computation Element Protocol (PCEP) ermöglicht die Kommunikation zwischen einem PCC und einem PCE oder zwischen zwei PCEs (definiert in RFC 5440).
PCEP ist ein TCP-basiertes Protokoll, das von der IETF PCE Working Group definiert wird und eine Reihe von Nachrichten und Objekten definiert, die zur Verwaltung von PCEP-Sitzungen und zum Anfordern und Senden von Pfaden für Multidomain Traffic Engineered LSPs (TE LSPs) verwendet werden. Es bietet einen Mechanismus für einen PCE zur Berechnung des Pfads für die externen LSPs eines PCC. Zu den PCEP-Interaktionen gehören LSP-Statusberichte, die vom PCC an den PCE gesendet werden, und PCE-Aktualisierungen für die externen LSPs.
Abbildung 1 veranschaulicht die Rolle von PCEP bei der clientseitigen Implementierung einer stateful PCE-Architektur in einem MPLS RSVP-TE-fähigen Netzwerk.

Eine TCP-basierte PCEP-Sitzung verbindet ein PCC mit einem externen PCE. Das PCC initiiert die PCEP-Sitzung und bleibt für die Dauer der PCEP-Sitzung mit dem PCE verbunden. Während der PCEP-Sitzung fordert der PCC LSP-Parameter vom zustandsbehafteten PCE an. Wenn ein oder mehrere LSP-Parameter vom PCE empfangen werden, sendet der PCC das TE-LSP erneut an. Wenn die PCEP-Sitzung beendet wird, wird die zugrunde liegende TCP-Verbindung sofort geschlossen, und der PCC versucht, die PCEP-Sitzung erneut einzurichten.
Daher umfassen die PCEP-Funktionen:
LSP-Tunnelstatussynchronisierung zwischen einem PCC und einem stateful PCE: Wenn eine aktive Zustands-PCE-Verbindung erkannt wird, versucht ein PCC, alle LSPs in einer Prozedur namens LSP-Zustandssynchronisierung an diesen PCE zu delegieren. PCEP ermöglicht die Synchronisierung des PCC LSP-Zustands mit dem PCE.
Delegierung der Kontrolle über LSP-Tunnel an einen zustandsbehafteten PCE: Ein aktiver Zustandsbehafteter PCE steuert ein oder mehrere LSP-Attribute für Rechenpfade, wie Bandbreite, Pfad (ERO) und Priorität (Setup und Halten). PCEP ermöglicht eine solche Delegierung von LSPs für die Pfadberechnung.
Stateful-PCE-Steuerung des Timings und der Reihenfolge von Pfadberechnungen innerhalb und über PCEP-Sitzungen hinweg: Ein aktiver Zustandsbehafteter PCE ändert ein oder mehrere LSP-Attribute, wie Bandbreite, Pfad (ERO) und Priorität (Setup und Halten). PCEP kommuniziert diese neuen LSP-Attribute vom PCE an das PCC, danach signalisiert der PCC den LSP im angegebenen Pfad erneut.
Unterstützung des Path Computation Element Protocol für RSVP-TE – Übersicht
- Grundlegendes zu MPLS RSVP-TE
- Aktuelle EINSCHRÄNKUNGEN VON MPLS RSVP-TE
- Verwendung einer externen Path-Computing-Entität
- Komponenten des External Path Computing
- Interaktion zwischen einem PCE und einem PCC mit PCEP
- LSP-Verhalten mit externem Computing
- Konfigurationsanweisungen, die für externes Computing unterstützt werden
- PCE-gesteuerter LSP-Schutz
- PCE-gesteuerter LSP-ERO
- PCE-gesteuerte Point-to-Multipoint-RSVP-TE-LSPs
- PCE-initiierte Point-to-Point-LSPs
- PCE-initiierter Bypass-LSP
- PCE-initiierte Point-to-Multipoint-LSPs
- SRv6 LSP in PCEP
- Vorteile von SRv6-LSPs in PCEP
- Automatischer Bandbreiten- und PCE-gesteuerter LSP
- TCP-MD5-Authentifizierung für PCEP-Sitzungen
- Auswirkungen der clientseitigen PCE-Implementierung auf die Netzwerkleistung
Grundlegendes zu MPLS RSVP-TE
Traffic Engineering (TE) befasst sich mit der Leistungsoptimierung von betrieblichen Netzwerken und bezieht hauptsächlich die Datenverkehrsströme auf eine vorhandene physische Topologie ab. Traffic Engineering bietet die Möglichkeit, den Datenverkehr von dem kürzesten Pfad, der vom Interior Gateway Protocol (IGP) ausgewählt wurde, auf einen potenziell weniger überfüllten physischen Pfad durch ein Netzwerk zu verschieben.
Für das Traffic-Engineering in großen, dichten Netzwerken können MPLS-Funktionen implementiert werden, da sie möglicherweise die meisten der in einem Overlay-Modell verfügbaren Funktionen auf integrierte Weise und zu niedrigeren Kosten als die derzeit konkurrierenden Alternativen bereitstellen. Der Hauptgrund für die Implementierung von MPLS Traffic Engineering ist die Steuerung der Pfade, auf denen der Datenverkehr durch ein Netzwerk fließt. Der Hauptvorteil der Implementierung von MPLS Traffic Engineering besteht darin, dass es eine Kombination aus den Traffic-Engineering-Funktionen von ATM und der Class-of-Service -Differenzierung (CoS) von IP bietet.
In einem MPLS-Netzwerk werden Datenebeneninformationen über Label Switching weitergeleitet. Ein Paket, das auf einem Provider-Edge -Router (PE) vom Kunden-Edge -Router (CE) ankommt, werden mit Denketiketten versehen und dann an den Ausgangs-PE-Router weitergeleitet. Die Label werden am Ausgangsrouter entfernt und dann als IP-Paket an das entsprechende Ziel weitergeleitet. Die Label-Switching-Router (LSRs) in der MPLS-Domäne verwenden Label-Verteilungsprotokolle, um die Bedeutung von Labeln zu kommunizieren, die zur Weiterleitung des Datenverkehrs zwischen und über die LSRs verwendet werden. RSVP-TE ist ein solches Protokoll zur Label-Verteilung, das es einem LSR-Peer ermöglicht, mehr über die Labelzuordnungen anderer Peers zu erfahren.
Wenn sowohl MPLS als auch RSVP auf einem Router aktiviert sind, wird MPLS zu einem Client von RSVP. Der Hauptzweck der Junos OS RSVP-Software besteht darin, dynamische Signalübertragung innerhalb von Label-Switched Paths (LSPs) zu unterstützen. RSVP reserviert Ressourcen, z. B. für IP-Unicast- und Multicast-Datenströme, und fordert Quality-of-Service -Parameter (QoS) für Anwendungen an. Das Protokoll wird im MPLS Traffic Engineering erweitert, damit RSVP LSPs einrichten kann, die für das Traffic-Engineering in MPLS-Netzwerken verwendet werden können.
Wenn MPLS und RSVP kombiniert werden, werden Label mit RSVP-Datenströmen verknüpft. Sobald ein LSP eingerichtet ist, wird der Datenverkehr durch den Pfad durch das Label definiert, das auf den Eingangsknoten des LSP angewendet wird. Die Zuordnung des Etiketts zum Datenverkehr erfolgt nach unterschiedlichen Kriterien. Die Paketmenge, denen von einem bestimmten Knoten derselbe Labelwert zugewiesen wird, gehören derselben FEC (Forwarding Äquivalenzklasse) und definieren effektiv den RSVP-Datenfluss. Wenn der Datenverkehr auf diese Weise auf einem LSP abgebildet wird, wird der LSP als LSP-Tunnel bezeichnet.
LSP-Tunnel sind eine Möglichkeit, unidirektionale Label-Switched-Pfade einzurichten. RSVP-TE baut auf dem RSVP-Core-Protokoll auf, indem neue Objekte definiert und vorhandene Objekte geändert werden, die in den PATH- und RESV-Objekten für die LSP-Einrichtung verwendet werden. Die neuen Objekte – LABEL-REQUEST Object (LRO), RECORD-ROUTE Object (RRO), LABEL Object und EXPLICIT-ROUTE Object (ERO) – sind in Bezug auf das RSVP-Protokoll optional, mit Ausnahme der LRO- und LABEL-Objekte, die beide für den Aufbau von LSP-Tunneln obligatorisch sind.
Im Allgemeinen richtet RSVP-TE einen Label-Switched-Pfad ein, der die Framebereitstellung vom Eingangs- zum Ausgangsrouter gewährleistet. Mit den neuen Traffic-Engineering-Funktionen werden jedoch die folgenden Funktionen in einer MPLS-Domäne unterstützt:
-
Möglichkeit, einen Label-Switched-Pfad mit einer vollständigen oder teilweisen expliziten Route einzurichten (RFC 3209).
-
Auf Einschränkungen basierende LSP-Einrichtung über Verbindungen, die Anforderungen wie Bandbreite und Verbindungseigenschaften erfüllen.
-
Endpunktsteuerung, die mit dem Einrichten und Verwalten von LSP-Tunneln an den Eingangs- und Ausgangsroutern verbunden ist.
-
Link-Management, das Linkressourcen verwaltet, um ressourcenorientiertes Routing von Traffic-Engineering-LSPs zu tun und MPLS-Label zu programmieren.
-
MPLS Fast Reroute (FRR), das die schutzbedürftigen LSPs verwaltet und diesen LSPs Backup-Tunnelinformationen zuweist.
Aktuelle EINSCHRÄNKUNGEN VON MPLS RSVP-TE
Obwohl die RSVP-Erweiterungen für das Traffic-Engineering eine bessere Netzwerkauslastung ermöglichen und die Anforderungen von Datenverkehrsklassen erfüllen, hat die heutige MPLS RSVP-TE-Protokollsuite mehrere Probleme, die mit ihrer verteilten Natur verbunden sind. Dies verursacht eine Reihe von Problemen während des Streits um die Bisektionskapazität, insbesondere innerhalb einer LSP-Prioritätsklasse, bei der eine Teilmenge von LSPs gemeinsame Setup- und Prioritätswerte hat. Zu den Einschränkungen von RSVP-TE gehören:
-
Mangelnde Visibilität der einzelnen Bandbreitenanforderungen pro LSP und pro Gerät: Die Eingangsrouter in einem MPLS-RSVP-TE-Netzwerk stellen LSPs ein, ohne einen globalen Überblick über den Bandbreitenbedarf im Netzwerk zu haben. Informationen zur Netzwerkressourcenauslastung sind nur als insgesamt reservierte Kapazität nach Datenverkehrsklasse auf Schnittstellenbasis verfügbar. Der individuelle LSP-Status ist lokal auf jedem Label Edge Router (LER) nur für seine eigenen LSPs verfügbar. Infolgedessen treten eine Reihe von Problemen im Zusammenhang mit der Nachfragestruktur auf, insbesondere innerhalb einer gemeinsamen Einrichtung und haben Priorität.
-
Asynchrone und unabhängige Art der RSVP-Signalübertragung: In RSVP-TE werden die Einschränkungen für die Pfadeinrichtung durch einen Administrator gesteuert. Daher wird die für einen LSP-Tunnel reservierte Bandbreite vom Administrator festgelegt und bedeutet nicht automatisch eine Begrenzung des über den Tunnel gesendeten Datenverkehrs. Daher ist die auf einem Traffic-Engineering-Link verfügbare Bandbreite die für den Link konfigurierte Bandbreite, ohne die Summe aller Reservierungen, die für den Link vorgenommen wurden. Daher führen die nicht signalisierten Anforderungen an einen LSP-Tunnel zu einer Serviceverschlechterung des LSP, der eine übermäßige Bandbreite benötigt, sowie der anderen LSPs, die die Bandbreitenanforderungen der Traffic-Engineering-Verbindung erfüllen.
-
LSPs basierend auf dynamischen oder expliziten Pfadoptionen in der reihenfolge der Voreinstellung eingerichtet: Die Eingangsrouter in einem MPLS-RSVP-TE-Netzwerk richten LSPs für Anforderungen basierend auf der Reihenfolge der Ankunft ein. Da die eingehenden Router keinen globalen Überblick über den Bandbreitenbedarf im Netzwerk haben, kann die Verwendung der voreingesetzten Reihenfolge zur Einrichtung von LSPs dazu führen, dass der Datenverkehr unterbrochen wird oder LSPs überhaupt nicht eingerichtet werden, wenn es einen übermäßigen Bandbreitenbedarf gibt.
Abbildung 2 Beispielsweise wird mit MPLS RSVP-TE konfiguriert, in dem A und G die Label Edge Router (LERs) sind. Diese Eingangsrouter richten unabhängig nach der Reihenfolge der Anforderungen LSPs ein und haben keine Kenntnis oder Kontrolle über die LSPs des jeweils anderen. Die Router B, C und D sind Zwischen- oder Transitrouter, die eine Verbindung zu den Ausgangsroutern E und F herstellen.

Die Eingangsrouter richten LSPs in der Reihenfolge ein, in der die Anforderungen ankommen. Wenn Router G zwei Anforderungen mit je 5 Kapazität für G-F erhält, dann signalisiert G zwei LSPs – LSP1 und LSP2 – über G-B-D-F. Wenn Router A die dritte Anforderung der Kapazität 10 für A-E empfängt, signalisiert er auch einen LSP, LSP3, über A-B-C-E. Wenn jedoch die Nachfrage an den A-E-LSP von 10 auf 15 steigt, kann Router A LSP3 nicht mit demselben Pfad (A-B-C-E) signalisieren, da der B-C-Link eine geringere Kapazität hat.
Router A sollte die erhöhte Nachfrage an LSP3 über den A-B-D-C-E-Pfad signalisieren. Da LSP1 und LSP2 den B-D-Link basierend auf der Reihenfolge der eingehenden Anforderungen verwendet haben, wird LSP3 nicht signalisiert.
Obwohl für alle LSPs ausreichend Maximale-Flow-Bandbreite verfügbar ist, unterliegt LSP3 möglicherweise längeren Serviceverschlechterungen. Dies liegt an der mangelnden globalen Nachfragetransparenz von Router A und der fehlenden systemischen Koordination bei der Bedarfsplatzierung durch die Eingangsrouter A und G.
Verwendung einer externen Path-Computing-Entität
Als Lösung für die aktuellen Einschränkungen der MPLS-RSVP-TE-Pfadberechnung ist eine externe Pfad-Computing-Entität mit einer globalen Ansicht der nachfrage pro LSP pro Gerät im Netzwerk erforderlich, unabhängig von der verfügbaren Kapazität.
Derzeit wird in einem MPLS RSVP-TE-Netzwerk nur online- und echtzeitbasierte Routing-Pfadberechnungen bereitgestellt. Jeder Router führt unabhängig von den anderen Routern im Netzwerk einschränkungensbasierte Routing-Berechnungen durch. Diese Berechnungen basieren auf derzeit verfügbaren Topologieinformationen – Informationen, die in der Regel aktuell sind, aber nicht vollständig korrekt sind. LSP-Platzierungen werden lokal optimiert, basierend auf dem aktuellen Netzwerkstatus. Die MPLS RSVP-TE-Tunnel werden über die CLI eingerichtet. Ein Betreiber konfiguriert den TE-LSP, der dann vom Eingangsrouter signalisiert wird.
Zusätzlich zu den vorhandenen Traffic-Engineering-Funktionen wird die MPLS RSVP-TE-Funktionalität um eine externe Pfad-Computing-Entität erweitert, die als Path Computation Element (PCE) bezeichnet wird. Der PCE berechnet den Pfad für die TE-LSPs der Eingangsrouter, die für die externe Steuerung konfiguriert wurden. Der Eingangsrouter, der eine Verbindung zu einem PCE herstellt, heißt Path Computation Client (PCC). Das PCC wird mit dem Path Computation Client Protocol (PCEP) konfiguriert, um die externe Pfadverarbeitung durch einen PCE zu ermöglichen.
Weitere Informationen finden Sie unter Komponenten des External Path Computing.
Um das externe Path Computing für die TE-LSPs eines PCC zu ermöglichen, fügen Sie die lsp-external-controller pccd
Anweisung auf der Hierarchie- und [edit mpls lsp lsp-name]
Hierarchieebene [edit mpls]
ein.
Komponenten des External Path Computing
Ein externes Pfad-Computing-System besteht aus folgenden Komponenten:
Pfadberechnungselement
Ein Path Computation Element (PCE) kann eine beliebige Entität (Komponente, Anwendung oder Netzwerkknoten) sein, die in der Lage ist, einen Netzwerkpfad oder eine Netzwerkroute basierend auf einem Netzwerkdiagramm zu berechnen und Rechenbeschränkungen anzuwenden. Ein PCE kann jedoch nur den Pfad für die TE-LSPs eines PCC berechnen, die für die externe Steuerung konfiguriert wurden.
Ein PCE kann entweder zustandsbehaftet oder zustandslos sein.
-
Stateful PCE: Ein zustandsbehafteter PCE behält eine strikte Synchronisierung zwischen dem PCE und dem Netzwerkstatus (in Bezug auf Topologie- und Ressourceninformationen) zusammen mit den im Netzwerk verwendeten berechneten Pfaden und reservierten Ressourcen bei. Mit anderen Worten, ein stateful PCE nutzt Informationen aus der Traffic-Engineering-Datenbank sowie Informationen über vorhandene Pfade (z. B. TE-LSPs) im Netzwerk, wenn neue Anforderungen vom PCC verarbeitet werden.
Ein zustandsbehafteter PCE hat zwei Arten:
-
Passiver Zustandsbehafteter PCE: Behält die Synchronisierung mit dem PCC bei und lernt die PCC-LSP-Zustände, um Pfadberechnungen besser zu optimieren, hat aber keine Kontrolle darüber.
-
Aktives Stateful-PCE: Ändert aktiv die PCC-LSPs und lernt außerdem mehr über die PCC-LSP-Zustände.
HINWEIS:In einer redundanten Konfiguration mit Haupt- und Backup-aktiven Stateful-PCEs kann das Backup Active Stateful-PCE die Attribute der delegierten LSPs erst ändern, wenn es zum Zeitpunkt eines Failovers zum Haupt-PCE wird. Bei einem Switchover gibt es keine Vorbehauptung von PCEs. Der Haupt-PCE wird durch ein Backup-PCE unterstützt, und wenn der Haupt-PCE ausfällt, übernimmt das Backup-PCE die Rolle des Haupt-PCE und bleibt der Haupt-PCE auch nach dem PCE, das zuvor der Haupt-PCE war wieder betriebsbereit.
Ein stateful PCE bietet die folgenden Funktionen:
-
Bietet Offline-LSP-Pfadberechnung.
-
Löst eine LSP-Re-Route aus, wenn das Netzwerk neu optimiert werden muss.
-
Ändert die LSP-Bandbreite, wenn der Bandbreitenbedarf einer Anwendung steigt.
-
Ändert andere LSP-Attribute auf dem Router, wie z. B. ERO, Einrichtungspriorität und Hold-Priorität.
Ein PCE hat einen globalen Überblick über den Bandbreitenbedarf im Netzwerk und unterhält eine datenverkehrsbasierte Datenbank, in der Pfadberechnungen durchgeführt werden können. Es führt Statistiken von allen Routern in der MPLS-Domäne mithilfe von SNMP und NETCONF durch. Dies bietet einen Mechanismus für die Offline-Steuerung der TE-LSPs des PCC. Obwohl ein Offline-LSP-Pfadberechnungssystem in einen Netzwerkcontroller eingebettet werden kann, fungiert der PCE wie ein vollwertiger Netzwerkcontroller, der zusätzlich zu den Rechenpfaden die Kontrolle über die TE-LSPs des PCC bietet.
Obwohl ein Stateful-PCE eine optimale Pfadberechnung und einen erhöhten Erfolg der Pfadberechnung ermöglicht, erfordert es zuverlässige Zustandssynchronisierungsmechanismen mit potenziell erheblichem Overhead auf der Steuerungsebene und der Wartung einer großen Menge an Daten in Bezug auf den Status, wie im Fall eines vollständigen Meshs von TE-LSPs.
-
-
Zustandslose PCE: Ein zustandsloser PCE erinnert sich nicht an einen berechneten Pfad, und jede Reihe von Anforderungen wird unabhängig voneinander verarbeitet (RFC 5440).
Pfadberechnungs-Client
Ein Path Computation Client (PCC) ist jede Clientanwendung, die eine Pfadberechnung zur Durchführung durch einen PCE anfordert.
Ein PCC kann auf einmal mit maximal 10 PCEs verbunden werden. Die PCC-zu-PCE-Verbindung kann eine konfigurierte statische Route oder eine TCP-Verbindung sein, die die Erreichbarkeit herstellt. Der PCC weist jedem angeschlossenen PCE eine Prioritätsnummer zu. Es sendet eine Nachricht an alle angeschlossenen PCEs mit Informationen über seine aktuellen LSPs in einem Prozess namens LSP-Zustandssynchronisierung. Für die TE-LSPs mit aktivierter externer Kontrolle delegiert der PCC diese LSPs an den Haupt-PCE. Das PCC wählt als Haupt-PCE einen PCE mit der niedrigsten Prioritätsnummer oder den PCE, mit dem es zuerst verbunden ist, wenn keine Prioritätsnummer vorhanden ist.
Der PCC signalisiert einen LSP basierend auf dem berechneten Pfad, den er von einem PCE empfängt. Wenn die PCEP-Sitzung mit dem Haupt-PCE beendet wird, wählt das PCC einen neuen Haupt-PCE, und alle delegierten LSPs an den zuvor Haupt-PCE werden an das neu verfügbare Haupt-PCE delegiert.
Path Computation Element Protocol
Das Path Computation Element Protocol (PCEP) wird für die Kommunikation zwischen PCC und PCE (sowie zwischen zwei PCEs) verwendet (RFC 5440). PCEP ist ein TCP-basiertes Protokoll, das von der IETF PCE Working Group definiert wird und eine Reihe von Nachrichten und Objekten definiert, die zur Verwaltung von PCEP-Sitzungen und zum Anfordern und Senden von Pfaden für Domänenübergreifende TE-LSPs verwendet werden. Zu den PCEP-Interaktionen gehören PCC-Nachrichten sowie Benachrichtigungen über bestimmte Zustände im Zusammenhang mit der Verwendung eines PCE im Kontext von MPLS RSVP-TE. Wenn PCEP für die PCE-to-PCE-Kommunikation verwendet wird, übernimmt der anfordernde PCE die Rolle eines PCC.
Daher umfassen die PCEP-Funktionen:
-
LSP-Tunnelstatussynchronisierung zwischen PCC und einem Stateful-PCE.
-
Delegierung der Kontrolle über LSP-Tunnel an einen Zustandsbehafteten PCE.
Interaktion zwischen einem PCE und einem PCC mit PCEP
Abbildung 3 veranschaulicht die Beziehung zwischen PCE, PCC und der Rolle von PCEP im Kontext von MPLS RSVP-TE.

Die Kommunikation zwischen PCE und PCC wird durch das TCP-basierte PCEP ermöglicht. Das PCC initiiert die PCEP-Sitzung und bleibt für die Dauer der PCEP-Sitzung mit einem PCE verbunden.
Ab Junos OS Version 16.1 können Sie eine PCEP-Sitzung mit TCP-MD5-Authentifizierung gemäß RFC 5440 sichern. Um den MD5-Sicherheitsmechanismus für eine PCEP-Sitzung zu aktivieren, wird empfohlen, den MD5-Authentifizierungsschlüssel auf [edit protocols pcep pce pce-id]
Hierarchieebene für eine PCEP-Sitzung zu definieren und zu binden. Sie können jedoch auch einen vordefinierten Schlüsselbund aus der [edit security authentication-key-chains key-chain]
Hierarchieebene verwenden, um eine PCEP-Sitzung zu sichern. In diesem Fall sollten Sie den vordefinierten Schlüsselbund an die PCEP-Sitzung auf [edit protocols pcep pce pce-id]
Hierarchieebene binden.
PCE und PCC verwenden denselben Schlüssel, um die Echtheit jedes Segments, das über die TCP-Verbindung der PCEP-Sitzung gesendet wird, zu überprüfen, um die PCEP-Kommunikation zwischen den Geräten zu sichern, die Angriffe ausgesetzt sein und Dienste im Netzwerk unterbrechen können.
Weitere Informationen zum Sichern von PCEP-Sitzungen mit MD5-Authentifizierung finden Sie unter TCP-MD5-Authentifizierung für PCEP-Sitzungen.
Sobald die PCEP-Sitzung eingerichtet ist, führt der PCC folgende Aufgaben aus:
-
LSP-Zustandssynchronisierung: Der PCC sendet Informationen über alle LSPs (lokal und extern) an alle angeschlossenen PCEs. Für externe LSPs sendet der PCC Informationen über jede Konfigurationsänderung, RRO-Änderung, Zustandsänderung usw. an den PCE.
Für PCE-initiierte LSPs ist auf dem PCC keine LSP-Konfiguration vorhanden. Der PCE, der den LSP initiiert, sendet die LSP-Parameter an den PCC, der angezeigt hat, dass er PCE-initiierte LSPs unterstützt.
HINWEIS:Unterstützung für PCE-initiierte LSPs wird in Junos OS Version 13.3 und höher bereitgestellt.
-
LSP-Delegierung: Nach der Synchronisierung der LSP-Statusinformationen delegiert das PCC die externen LSPs an einen PCE, den wichtigsten aktiven Status-PCE. Nur der Haupt-PCE kann Parameter für den externen LSP festlegen. Zu den Parametern, die der HAUPT-PCE ändert, gehören Bandbreite, Pfad (ERO) und Priorität (Setup und Halten). Die in der lokalen Konfiguration angegebenen Parameter werden durch die Parameter überschrieben, die vom Haupt-PCE festgelegt werden.
HINWEIS:Wenn die PCEP-Sitzung mit dem Haupt-PCE beendet wird, wählt das PCC einen neuen Haupt-PCE, und alle delegierten LSPs an den zuvor Haupt-PCE werden an das neu verfügbare Haupt-PCE delegiert.
Im Fall von PCE-initiierten LSPs erstellt der PCC den LSP unter Verwendung der parameter, die vom PCE erhalten wurden. Der PCC weist dem PCE-initiierten LSP eine eindeutige LSP-ID zu und delegiert den LSP automatisch an den PCE. Ein PCC kann die Delegierung der PCE-initiierten LSPs für eine aktive PCEP-Sitzung nicht widerrufen.
Wenn eine PCEP-Sitzung beendet wird, startet der PCC zwei Timer, ohne die PCE-initiierten LSPs sofort zu löschen –
delegation cleanup timeout
undlsp cleanup timer
– um Eine Unterbrechung der Services zu vermeiden. Während dieser Zeit kann ein aktiver zustandsbehafteter PCE die Kontrolle über die von dem ausgefallenen PCE bereitgestellten LSPs übernehmen, indem eine Create-Anforderung für den LSP gesendet wird.Die Kontrolle über PCE-initiierte LSPs wird nach Ablauf von
delegation cleanup timeout
. Wenn dasdelegation cleanup timeout
Ablaufdatum abläuft und kein anderer PCE die Kontrolle über den LSP von dem ausgefallenen PCE übernommen hat, übernimmt das PCC die lokale Kontrolle über den nicht delegierte PCE-initiierten LSP. Wenn später der ursprüngliche oder ein neuer aktiver Stateful-PCE die Kontrolle über die lokal kontrollierten PCE-initiierten LSPs erlangen möchte, delegiert das PCC diese LSPs an den PCE und derlsp cleanup timer
Timer wird angehalten.Ein PCE kann die Delegierung des PCE-initiierten LSP an den PCC zurückschicken, um die LSP-Übertragung zwischen PCEs zu ermöglichen. Dies löst für den
lsp cleanup timer
PCE-initiierten LSP aus. Der PCC wartet, bis der Timer für die LSP-Bereinigung abläuft, bevor die nicht delegierte PCE-initiierten LSPs aus dem ausgefallenen PCE entfernt werden.Wenn das
lsp cleanup timer
Ablaufen abläuft und kein anderer PCE die Kontrolle über die LSPs von dem ausgefallenen PCE übernommen hat, löscht das PCC alle LSPs, die von dem ausgefallenen PCE bereitgestellt wurden.HINWEIS:In Übereinstimmung mit Draft-ietf-pce-stateful-pce-09 erfolgt das Widerrufen von PCE-initiierten LSP-Delegationen durch einen PCC in einer Make-before-Break-Weise, bevor die LSPs zu einem alternativen PCE neu delegiert werden. Ab Junos OS Version 18.1R1 muss die
lsp-cleanup-timer
Version größer oder gleich demdelegation-cleanup-timeout
des PCC sein, um die LSP-Delegierungen zu widerrufen. Wenn nicht, kann das Timeout-Intervall für die Neulegation für den PCC auf unendlich festgelegt werden, wobei die LSP-Delegierungen an diesen PCE intakt bleiben, bis eine bestimmte Aktion vom PCC zur Änderung der vom PCE festgelegten Parameter durchgeführt wird. -
LSP-Signalübertragung: Wenn der PCC einen oder mehrere LSP-Parameter vom hauptaktiven Zustandsstatus-PCE empfängt, sendet der PCC den TE-LSP basierend auf dem von PCE bereitgestellten Pfad neu. Wenn der PCC den LSP nicht einrichten kann, benachrichtigt es den PCE über den Setup-Fehler und wartet, bis der Haupt-PCE neue Parameter für diesen LSP bereitstellt, und signalisiert ihn dann erneut.
Wenn der PCE einen Pfad angibt, der unvollständig ist oder lose Hops hat, bei denen nur die Pfadendpunkte angegeben sind, führt der PCC kein auf Einschränkungen basierendes Routing durch, um den vollständigen Satz von Hops zu ermitteln. Stattdessen stellt der PCC RSVP den PCE-bereitgestellten Pfad für die Signalübertragung bereit, und der Pfad wird mithilfe von IGP Hop-by-Hop-Routing eingerichtet.
Unter Berücksichtigung der in Abbildung 2verwendeten Topologie veranschaulicht Abbildung 4 die partielle clientseitige PCE-Implementierung im MPLS RSVP-TE-fähigen Netzwerk. Die Eingangsrouter A und G sind die PCCs, die so konfiguriert sind, dass sie über eine TCP-Verbindung eine Verbindung mit dem externen Stateful-PCE herstellen.
Der PCE hat einen globalen Überblick über den Bandbreitenbedarf im Netzwerk und führt externe Pfadberechnungen durch, nachdem er die Traffic-Engineering-Datenbank durchgeblickt hat. Der aktive Stateful-PCE ändert dann ein oder mehrere LSP-Attribute und sendet ein Update an den PCC. Der PCC verwendet die Parameter, die es vom PCE empfängt, um den LSP erneut zu signalisieren.

Auf diese Weise bietet der Stateful-PCE einen kooperativen Betrieb verteilter Funktionen, die zur Bewältigung spezifischer Herausforderungen einer kürzesten interdomainbeschränkten Pfadberechnung verwendet werden. Es eliminiert Überlastungsszenarien, in denen Datenverkehrsströme ineffizient auf verfügbaren Ressourcen abgebildet werden, was zu einer Überauslastung einiger Teilmengen von Netzwerkressourcen führt, während andere Ressourcen unterbelastet bleiben.
LSP-Verhalten mit externem Computing
LSP-Typen
In einer clientseitigen PCE-Implementierung gibt es drei Arten von TE-LSPs:
-
CLI-gesteuerte LSPs: Die LSPs, für die die
lsp-external-controller pccd
Anweisung nicht konfiguriert ist, werden als CLI-gesteuerte LSPs bezeichnet. Obwohl diese LSPs unter lokaler Kontrolle stehen, aktualisiert der PCC die angeschlossenen PCEs mit Informationen über die CLI-gesteuerten LSPs während des anfänglichen LSP-Synchronisierungsprozesses. Nach der ersten LSP-Synchronisierung informiert der PCC den PCE auch über neue und gelöschte LSPs. -
PCE-gesteuerte LSPs: Die LSPs, für die die
lsp-external-controller pccd
Anweisung konfiguriert ist, heißt PCE-gesteuerte LSPs. Der PCC delegiert die PCC-initiierten LSPs zur externen Pfadberechnung an den Haupt-PCE.Das PCC informiert den PCE über die konfigurierten Parameter eines PCE-gesteuerten LSP, wie Bandbreite, ERO und Prioritäten. Es informiert die PCE auch über die tatsächlichen Werte, die für diese Parameter verwendet wurden, um den LSP einschließlich der RRO einzurichten, sofern verfügbar.
Das PCC sendet solche LSP-Statusberichte nur an das PCE, wenn eine Neukonfiguration stattgefunden hat oder wenn eine Änderung des ERO, der RRO oder des Status der PCE-gesteuerten LSPs unter externer Kontrolle erfolgt.
Es gibt zwei Arten von Parametern, die aus der CLI-Konfiguration eines LSP für einen PCE stammen:
-
Parameter, die nicht von einem PCE überschrieben werden und sofort angewendet werden.
-
Parameter, die von einem PCE überschrieben werden. Diese Parameter umfassen Bandbreite, Pfad und Priorität (Setup- und Haltewerte). Wenn die Steuermodus-Switches von extern zu lokal wechseln, werden die CLI-konfigurierten Werte für diese Parameter bei der nächsten Gelegenheit angewendet, um das LSP erneut zu signalisieren. Die Werte werden nicht sofort angewendet.
-
-
Extern bereitgestellte LSPs (oder PCE-initiierte LSPs): Die LSPs, auf denen die
lsp-provisioning
Anweisung konfiguriert ist, werden als PCE-initiierte LSPs bezeichnet. Ein PCE-initiierter LSP wird dynamisch von einem externen PCE erstellt. daher ist auf dem PCC keine LSP-Konfiguration vorhanden. Der PCC erstellt den PCE-initiierten LSP unter Verwendung der vom PCE bereitgestellten Parameter und delegiert den LSP automatisch an den PCE.HINWEIS:Unterstützung für PCE-initiierte LSPs wird in Junos OS Version 13.3 und höher bereitgestellt.
Die CLI-gesteuerten LSPs, PCE-gesteuerten LSPs und PCE-initiierte LSPs können auf einem PCC koexistieren.
Die CLI-gesteuerten LSPs und PCE-gesteuerten LSPs können auf einem PCC koexistieren.
LSP-Steuerungsmodus
In einer clientseitigen PCE-Implementierung gibt es zwei Arten von Steuerungsmodi für einen PCC-gesteuerten LSP:
-
Extern: Standardmäßig unterliegen alle PCE-gesteuerten LSPs einer externen Kontrolle. Wenn ein LSP unter externer Kontrolle steht, verwendet der PCC die von PCE bereitgestellten Parameter, um den LSP einzurichten.
-
Lokal: Ein PCE-gesteuerter LSP kann unter lokaler Kontrolle stehen. Wenn die LSP-Switches von der externen Steuerung zur lokalen Steuerung wechseln, erfolgt die Pfadberechnung mithilfe der CLI-konfigurierten Parameter und des einschränkungensbasierten Routing. Ein solcher Switchover erfolgt nur, wenn es einen Trigger gibt, um den LSP erneut zu signalisieren. Bis dahin nutzt das PCC die von PCE bereitgestellten Parameter, um den PCE-gesteuerten LSP zu signalisieren, obwohl der LSP unter lokaler Kontrolle bleibt.
Ein PCE-gesteuerter LSP wechselt von seinem externen Standardsteuerungsmodus zur lokalen Steuerung, wenn z. B. keine Verbindung zu einem PCE besteht oder wenn ein PCE die Delegierung von LSPs zurück an den PCC zurückgibt.
Weitere Informationen zu CLI-gesteuerten LSPs und PCE-gesteuerten LSPs finden Sie unter LSP-Typen.
Konfigurationsanweisungen, die für externes Computing unterstützt werden
Tabelle 1 listet die MPLS- und vorhandenen LSP-Konfigurationsanweisungen auf, die für einen PCE-gesteuerten LSP gelten.
Unterstützung für PCE-gesteuerte LSP |
Anwendbare LSP-Konfigurationsanweisungen |
Zutreffende MPLS-Konfigurationsanweisungen |
---|---|---|
Diese Konfigurationsanweisungen können zusammen mit der PCE-Konfiguration konfiguriert werden. Sie werden jedoch nur wirksam, wenn die lokale Konfiguration verwendet wird. Während der PCE-Steuerung bleiben diese Konfigurationsanweisungen inaktiv. |
|
|
Diese Konfigurationsanweisungen können zusammen mit der PCE-Konfiguration konfiguriert werden, werden aber durch die PCE-gesteuerten LSP-Attribute überschrieben. Wenn jedoch die lokale Konfiguration verwendet wird, werden die konfigurierten Werte für diese Konfigurationsanweisungen angewendet. HINWEIS:
Änderungen an der lokalen Konfiguration über die CLI, während der LSP unter der Kontrolle eines Zustandsbehafteten PCE steht, haben keine Auswirkungen auf den LSP. Diese Änderungen treten nur in Kraft, wenn die lokale Konfiguration angewendet wird. |
|
|
Diese Konfigurationsanweisungen können nicht zusammen mit der PCE-Konfiguration konfiguriert werden. |
|
|
Die restlichen LSP-Konfigurationsanweisungen sind genauso anwendbar wie für vorhandene LSPs. Bei der Konfiguration einer der oben genannten Konfigurationsanweisungen für einen PCE-gesteuerten LSP wird eine MPLS-Protokollmeldung generiert, die anzeigt, wann die konfigurierten Parameter in Kraft treten.
PCE-gesteuerter LSP-Schutz
Die Schutzpfade, einschließlich Fast Reroute und Bypass-LSPs, werden lokal vom PCC unter Verwendung von einschränkungensbasiertem Routing berechnet. Ein zustandsbehafteter PCE gibt nur den primären Pfad (ERO) an. Ein PCE kann auch einen nicht-Standby-sekundären Pfad auslösen, auch wenn die lokale Konfiguration keinen nicht-Standby-sekundären Pfad zum LSP-Schutz hat.
PCE-gesteuerter LSP-ERO
Für PCE-kontrollierte LSPs (PCC-delegierte LSPs und PCE-initated LSPs) muss nur ein vollständiges Explicit Route Object (ERO)-Objekt vom PCE an das PCC gesendet werden; andernfalls lehnt der PCC die PcUpdate- oder PCCreate-Nachricht für diese PCEP-Sitzung ab.
Ab Junos OS Version 17.2 werden zusätzlich zu external cspf
den PCE-gesteuerten LSPs zwei neue Pfadberechnungstypen eingeführt: local cspf
und no cspf
.
-
local cspf
—Ein PCC verwendet denlocal cspf
Berechnungstyp nur, wenn der PCE einen Juniper Vendor TLV sendet (Unternehmensnummer: 0x0a4c) des Typs 5. -
no cspf
— Weder PCE noch PCC führt eine Berechnung des eingeschränkten Pfads durch. Die Endgeräte und Einschränkungen werden dem RSVP-Modul für die Einrichtung des LSP mit dem IGP-Pfad angegeben.Ein PCC verwendet
no cspf
in den folgenden Fällen den Berechnungstyp:-
Wenn der PCE TLV sendet
local cspf
, und wenn die Junos OS-Konfiguration oder entsprechende Vorlage für diesen LSP im PCC-delegierten LSP enthalten istno-cspf
. -
Wenn der PCE TLV sendet
local cspf
, und wenn die Junos OS-Konfigurationsvorlage für diesen LSP in den PCE-initiierten LSP enthalten istno-cspf
. -
Wenn der PCE keine TLV mit einem leeren ERO oder einer losen ERO (mit losem Bit im ERO-Objekt) sendet
local cspf
.
-
Mit diesen neuen Berechnungstypen kann ein PCC ein ERO-Objekt entweder als loses ERO oder als leeres ERO akzeptieren. Eine externe Pfad-Computing-Entität, die nicht in der Lage ist, einen Pfad zu berechnen, kann Parameter wie Bandbreite und Farbe basierend auf den Analysen ändern. In solchen Fällen wird ein leeres ERO-Objekt oder ein loses ERO verwendet, deren Pfad vom PCC bestimmt wird.
PCE-gesteuerte Point-to-Multipoint-RSVP-TE-LSPs
Nachdem eine PCEP-Sitzung zwischen einem PCE und einem PCC eingerichtet wurde, meldet der PCC alle LSPs im System an die PCE für die LSP-Zustandssynchronisierung. Dazu gehören PCC-gesteuerte, PCE-delegierte und PCE-initiierte Point-to-Point-LSPs. Ab Junos OS Version 15.1F6 und 16.1R1 wird diese Funktion auch auf Point-to-Multipoint-LSPs erweitert. Bei einem PCE ähnelt der Point-to-Multipoint-LSP dem des RSVP-Point-to-Multipoint-LSP, bei dem der Point-to-Multipoint-LSP als Eine Sammlung von Punkt-zu-Punkt-LSPs behandelt wird, die unter einem Punkt-zu-Multipoint-Bezeichner gruppiert sind.
Standardmäßig wird die PCE-Steuerung von Point-to-Multipoint-LSPs auf einem PCC nicht unterstützt. Um diese Funktion hinzuzufügen, fügen Sie die p2mp-lsp-report-capability
Anweisung auf der [edit protocols pcep pce pce-name]
Hierarchie- oder [edit protocols pcep pce-group group-id]
Hierarchieebene ein. Nachdem die Point-to-Multipoint-Berichtfunktion auf einem PCC konfiguriert ist, kündigt das PCC diese Funktion dem PCE an. Wenn PCE dieselbe Point-to-Multipoint-Berichtsfunktion im Gegenzug ankündigen, meldet der PCC die vollständige Point-to-Multipoint-LSP-Struktur an den PCE für die LSP-Zustandssynchronisierung.
Ein PCC mit der Point-to-Multipoint-TE-LSP-Funktion unterstützt die Berichterstellung von Point-to-Multipoint-TE-LSPs für zustandsbehaftete PCEs, Point-to-Multipoint-Update und LSP-Datenbank, die Point-to-Multipoint-LSP-Namen unterstützt. Die folgenden Funktionen und Funktionen werden für Junos OS Version 15.1F6 und 16.1 jedoch nicht unterstützt:
-
Statische Point-to-Multipoint-LSPs
-
PCE-delegierte und PCE-initiierte Point-to-Multipoint-LSPs
-
Automatische Bandbreite
-
TE++
-
PCE-Anforderungs- und Antwortnachricht
-
Erstellung von Point-to-Multipoint-LSPs mithilfe von Vorlagen
-
Konfigurieren des Vorwärtseintrags auf den PCE-initiierten Point-to-Multipoint-LSPs
-
Konfigurieren der Weiterleitungseingabe auf dem Router, der auf einen bereitgestellten LSP hinweist.
PCE-initiierte Point-to-Point-LSPs
Ab Junos OS Version 16.1 wird die PCEP-Funktionalität erweitert, um einem Stateful-PCE die Initiierung und Bereitstellung von Traffic-Engineering-LSPs über ein PCC zu ermöglichen. Zuvor wurden die LSPs auf dem PCC konfiguriert und der PCC die Kontrolle über die externen LSPs an einen PCE delegiert. Das Eigentum des LSP-Staates wurde vom PCC gehalten. Mit der Einführung der PCE-initiierten LSPs kann ein PCE einen Point-to-Point-LSP des Datenverkehrs dynamisch initiieren und bereitstellen, ohne dass ein lokal konfigurierter LSP auf dem PCC erforderlich ist. Beim Erhalt einer PCE-Nachricht erstellt das PCC den PCE-initiierten LSP und delegiert den LSP automatisch an den PCE.
Standardmäßig lehnt ein PCC die Anforderung zur Bereitstellung pcE-initiierter Punkt-zu-Punkt-LSPs von einem PCE ab. Um die Unterstützung von PCE-initierten LSPs auf dem PCC zu ermöglichen, fügen Sie die lsp-Provisioning-Anweisung auf der [edit protocols pcep pce pce-id]
Hierarchie- oder [edit protocols pcep pce-group group-id]
Hierarchieebene ein.
Ein PCC gibt an, dass er PCE-initiierte Point-to-Point-LSPs unterstützt und gleichzeitig die Path Computation Element Protocol (PCEP)-Sitzung mit dem PCE aufbaut. Ein PCE wählt einen PCC mit dieser Funktion aus, um einen LSP zu initiieren. Der PCE stellt dem PCC die PCE-initiierten LSP-Parameter zur Verfügung. Nach dem Erhalt der PCE-initiierten Point-to-Point-LSP-Parameter richtet das PCC den LSP ein, weist eine LSP-ID zu und delegiert den LSP automatisch an den PCE.
Wenn der PCE, der den LSP initiiert, die PCE-initiierten Punkt-zu-Punkt-LSP-Parameter nicht bereitstellt, verwendet der PCC die Standardparameter. Eine optionale LSP-Vorlage kann auch konfiguriert werden, um Werte für den PCE-initiierten Punkt-zu-Punkt-LSP anzugeben, wenn die LSP-Parameter nicht vom PCE bereitgestellt werden. Um eine LSP-Vorlage für PCE-initiierte Punkt-zu-Punkt-LSPs auf dem PCC zu konfigurieren, fügen Sie die Label-switched-path-template-Anweisung auf Hierarchieebene [edit protocols mpls lsp-external-controller lsp-external-controller]
ein.
Wenn eine PCEP-Sitzung beendet wird, startet der PCC zwei Timer, ohne die PCE-initiiertenLSPs sofort zu löschen –delegation cleanup timeout
und lsp cleanup timer
–, um Eine Unterbrechung der Services zu vermeiden. Während dieser Zeit kann ein aktiver zustandsbehafteter PCE die Kontrolle über die von dem ausgefallenen PCE bereitgestellten LSPs erlangen.
Ein PCE kann die Delegierung des PCE-initiierten Point-to-Point-LSP an den PCC zurückschicken, um die LSP-Übertragung zwischen PCEs zu ermöglichen. Die Kontrolle über PCE-initiierte LSPs wird nach Ablauf des Timeouts der Delegationsbereinigung auf das PCC zurückgesetzt. Wenn das Timeout für die Delegierungsbereinigung abläuft und kein anderer PCE die Kontrolle über den LSP von dem ausgefallenen PCE übernommen hat, übernimmt das PCC die lokale Kontrolle über den nicht delegierte PCE-initiierten LSP. Wenn später das ursprüngliche oder ein neuer aktiver Stateful-PCE die Kontrolle über die lokal kontrollierten PCE-initiierten Point-to-Point-LSPs erlangen möchte, delegiert das PCC diese LSPs an das PCE und der LSP-Bereinigungs-Timer wird angehalten.
Das PCC wartet, bis der Timer für die LSP-Bereinigung abläuft, bevor die nicht delegierte PCE-initiierten Punkt-zu-Punkt-LSPs aus dem ausgefallenen PCE gelöscht werden. Wenn der LSP-Bereinigungs-Timer abläuft und kein anderer PCE die Kontrolle über die LSPs aus dem ausgefallenen PCE übernommen hat, löscht das PCC alle LSPs, die vom ausgefallenen PCE bereitgestellt wurden.
Ab Junos OS Version 21.1R1 unterstützen wir Nonstop Active Routing (NSR) für PCE-initiierte RSVP-basierte Point-to-Point- und Point-to-Multipoint-LSPs. Nur die primäre Routing-Engine unterhält die PCEP-Sitzung mit dem Controller. Es synchronisiert alle RSVP-LSPs, die von PCEs initiiert wurden, einschließlich Multicast-Flow-Spezifikationen für alle PCE-initiierten P2MP-LSPs, mit der Backup-Routing-Engine. Während eines Switchovers stürzt die PCEP-Sitzung ab und stellt erneut fest, wenn die Backup-Routing-Engine zur primären Routing-Engine wird. Dies reduziert den Datenverkehrsverlust für den Datenverkehr, der über PCE-initiierte RSVP-LSPs während Routing-Engine-Switchovers übertragen wird. Diese Funktion wird aktiviert, wenn NSR konfiguriert ist.
PCE-initiierter Bypass-LSP
- Grundlegendes zu PCE-initiierten Bypass-LSPs
- Vorteile von PCE-initiierter Bypass-LSP
- Verhalten von PCE-initiierten Bypass-LSPs während eines Ausfalls der PCEP-Sitzung
Grundlegendes zu PCE-initiierten Bypass-LSPs
Zum Zeitpunkt eines Verbindungs- oder Knotenausfalls kann es zu Datenverkehrsausfällen kommen, weil die Backup-Schutzpfade im Netzwerk nicht über ausreichend Bandbreite verfügen, um den Datenverkehr zu bewältigen. In solchen Netzwerken kann zwar ein PCE verwendet werden, um alle Pfade zu berechnen, um die Netzwerkleistung zu optimieren, müssen die lokalen Schutzpfade auch über den PCE gesteuert werden.
Junos OS Version 19.2R1 und höher bieten teilweise Unterstützung für den Internet-Entwurf draft-cbrt-pce-stateful-local-protection-01 (läuft ab Dezember 2018), PCEP-Erweiterungen für RSVP-TE Local-Protection mit PCE-Stateful, wobei die PCEP-Funktionen erweitert werden, um es einem stateful PCE zu ermöglichen, LSPs für eine geschützte Schnittstelle zu initiieren, bereitzustellen und zu verwalten. Mehrere Bypass-LSPs mit Bandbreitenreservierung können vom PCE initiiert werden, um eine Verbindung oder einen Knoten zu schützen. Es wird erwartet, dass die Bandbreite auf dem Bypass-LSP kleiner ist als die Gesamtbandbreite der primären LSPs, die sie schützen könnte.
Der bestehende Bypass-Auswahlmechanismus, der manuelle Bypass-LSPs (falls vorhanden) gegenüber dynamischen Bypass-LSPs bevorzugt, wird erweitert, um (falls vorhanden) von PCE bereitgestellte Bypass-LSPs gegenüber dynamischen Bypass-LSPs zu bevorzugen. Die über PCE bereitgestellten Bypass-LSPs haben eine höhere Präferenz gegenüber dynamischen Bypass-LSPs, werden aber weniger bevorzugt als manuelle Bypass-LSPs.
Die Für die Ausführung von Betriebsumgehungs-LSPs verwendeten Vorgänge, wie clear rsvp session
z. B. , können auch auf den PCE-initiierten Bypass-LSPs ausgeführt werden. Sie können Befehle verwenden, z show path-computation-client status extensive
. B. zur show path-computation-client lsp
Anzeige von PCE-initiierten Umgehungs-LSP-Statistiken.
Mit Unterstützung von PCE-initiierten Bypass-LSP können Sie:
-
Erstellen Sie einen RSVP-Bypass-LSP über PCEP von einem externen Controller, wobei der Bypass-LSP:
-
kann zum Schutz von Verbindungen oder Knoten sein.
-
muss eine Nicht-Null-Bandbreite haben.
-
muss eine festgelegte strenge ERO haben.
-
-
Aktualisieren Sie die Bandbreite und den ERO für einen vorhandenen PCE-erstellten Bypass-LSP.
-
Überschreiben Sie die Bypass-LSP-Bandbreite für die Zugangskontrolle der primären LSPs. Dies muss ein Parameter pro Umgehung sein und sollte die Aktualisierung des Abonnements pro Bypass-LSP ermöglichen.
Vorteile von PCE-initiierter Bypass-LSP
Die PCE-initiierten Bypass-LSPs bieten die folgenden Vorteile:
-
Bessere Kontrolle über den Datenverkehr nach einem Ausfall und deterministischere Pfadberechnung von Schutzpfaden.
-
Erfüllen Sie komplexe Einschränkungen und Anforderungen an die Vielfalt, wie z. B. die Aufrechterhaltung unterschiedlicher Pfade für LSPs sowie deren lokale Schutzpfade.
-
Stellen Sie sicher, dass die Verbindungen bei Ausfällen nicht überlastet sind.
Verhalten von PCE-initiierten Bypass-LSPs während eines Ausfalls der PCEP-Sitzung
Wenn eine PCEP-Sitzung ausfällt, werden die von PCE initiierten Bypass-LSPs bis zum Ablauf des Status-Timeout-Timers verwaist. Die PCE-initiierten Bypass-LSPs werden nach Ablauf des Status-Timeout-Timer bereinigt. Um die Kontrolle über einen PCE-initiierten Bypass-LSP zu erhalten (nachdem die PCEP-Sitzung ausfällt), sendet ein PCE (entweder der primäre PCE oder eine andere sekundäre PCE) vor Ablauf des Status-Timeouts eine PCInitiate-Nachricht.
PCE-initiierte Point-to-Multipoint-LSPs
Mit der Einführung von Point-to-Multipoint-PCE-initiierten LSPs kann ein PCE einen Point-to-Multipoint-LSP dynamisch initiieren und bereitstellen, ohne dass eine lokale LSP-Konfiguration auf dem PCC erforderlich ist. Auf diese Weise kann der PCE den Zeitpunkt und die Reihenfolge der Punkt-zu-Multipoint-Pfadberechnungen innerhalb und über Path Computation Element Protocol (PCEP)-Sitzungen steuern und so ein dynamisches Netzwerk schaffen, das zentral gesteuert und bereitgestellt wird.
Weitere Informationen finden Sie unter Grundlegendes zum Path Computation Element Protocol für MPLS RSVP-TE mit Unterstützung für PCE-initiierte Point-to-Multipoint-LSPs.
SRv6 LSP in PCEP
Segment-Routing kann sowohl auf MPLS- als auch auf IPv6-Weiterleitungsebene angewendet werden. Das Path Computation Element (PCE) berechnet SR-Pfade für MPLS- und IPv6-Weiterleitungsebene. Segment-Routing für PCEP unterstützt SR-LSPs wie PCE-initiierte, lokal erstellte und delegierte SR-LSPs in der IPv6-Weiterleitungsebene.
Vorteile von SRv6-LSPs in PCEP
- Ermöglicht die Erstellung von PCE-initiierten SRv6-LSPs.
- Delegieren der auf dem Router erstellten SRv6-LSPs an den Controller.
- Melden Sie die lokal auf dem Router erstellten LSPs dem Controller.
- Die SRv6-Netzwerkprogrammierung bietet die Flexibilität, Segment-Routing ohne MPLS zu nutzen.
PCEP unterstützt das Erstellen, Updieren und Löschen von PCE initiierten farbigen und unfarbigen SRv6-LSPs. Wenn ein PCE initiierter SRv6-LSP zusammen mit einem statischen SRv6-LSP für dieselbe IP oder farbbasierte IP vorhanden ist, wird die statische SRv6 TE LSP-mitwirkende Route gegenüber der PCE-initiierten SRv6 TE LSP-Mitwirkenden Route bevorzugt.
Um eine PCEP-Sitzung so zu konfigurieren, dass sie SRv6-fähig ist, müssen Sie die srv6-capability
Konfigurationsaussage unter [Edit protocols pce pce-id] oder auf [edit protocols pcep pce-group pce-id
] Hierarchieebene aktivieren. Wenn die srv6-capability
Konfigurationsaussage aktiviert ist, müssen Sie die Srv6-Konfigurationsaussage auch auf der Hierarchieebene [edit protocols source-packet-routing
] aktivieren, andernfalls wird während des Commits der Fehler angezeigt.
Um SRv6 für SR-TE zu konfigurieren, müssen Sie die Konfigurationsaussage srv6 auf der Hierarchieebene [Edit protocols Source-Packet-Routing] hinzufügen.
[Weitere Informationen finden Sie unter Understanding SR-TE Policy for SRv6 Tunnel .
Um die maximale Segmentlistentiefe für SRv6-LSP zu konfigurieren, müssen Sie die maximum-srv6-segment-list-depth
Konfigurationsaussage auf Hierarchieebene [edit protocols pcep
] aktivieren.
Automatischer Bandbreiten- und PCE-gesteuerter LSP
Ab Junos OS Version 14.2R4 wird Unterstützung für automatische Bandbreite für PCE-gesteuerte LSPs bereitgestellt. In früheren Versionen galt die Option für automatische Bandbreite nicht für PCE-gesteuerte LSPs, obwohl LSPs unter der Kontrolle von Auto-Bandwdith und einschränkungensbasiertem Routing mit PCE-gesteuerten LSPs koexistieren konnten. Die Statistikerfassung für die automatische Bandbreite wurde nur wirksam, wenn der Steuerungsmodus eines PCE-gesteuerten LSP von extern auf lokal geändert wurde. Dies geschah in Fällen, wie z. B. keine Verbindung zu einem PCE oder wenn ein PCE die Delegation von LSPs zurück an den PCC zurückschickt.
TCP-MD5-Authentifizierung für PCEP-Sitzungen
Ein Stateful PCE-Server automatisiert die Erstellung von Traffic-Engineering-Pfaden im gesamten Netzwerk, erhöht die Netzwerkauslastung und ermöglicht ein maßgeschneidertes programmierbares Netzwerkerlebnis mit der Verwendung von PCEP-Kommunikation mit einem PCC. Ein PCC sendet LSP-Berichte an einen PCE-Server, und der PCE aktualisiert oder stellt LSPs zurück an den PCC. Die über eine PCEP-Sitzung gesendeten Daten sind für einen PCE-Server entscheidend, um externe Pfadberechnungen durchzuführen. Infolgedessen kann ein Angriff auf die PCEP-Kommunikation Netzwerkservices unterbrechen. Wenn geänderte PCEP-Nachrichten an einen PCC gesendet werden, können unangemessene LSPs eingerichtet werden. Wenn geänderte PCEP-Meldungen an einen PCE gesendet werden, wird vom PCE eine falsche Ansicht des Netzwerks gelernt.
In Anbetracht der Bedeutung der PCEP-Kommunikation zwischen einem PCE und PCC für die effektive Ausführung der PCE-Funktionen bietet Junos OS Version 16.1 die Funktion, eine PCEP-Sitzung mit TCP-MD5-Authentifizierung gemäß RFC 5440 zu sichern. Diese Funktion schützt die Kommunikation zwischen einem PCE und PCC über eine PCEP-Sitzung, die einem Angriff ausgesetzt sein und Netzwerkservices unterbrechen kann.
Um den MD5-Sicherheitsmechanismus für eine PCEP-Sitzung zu aktivieren, wird empfohlen, den MD5-Authentifizierungsschlüssel auf [edit protocols pcep pce pce-id]
Hierarchieebene für eine PCEP-Sitzung zu definieren und zu binden. Sie können jedoch auch einen vordefinierten Schlüsselbund aus der [edit security authentication-key-chains key-chain]
Hierarchieebene verwenden, um eine PCEP-Sitzung zu sichern. In diesem Fall sollten Sie den vordefinierten Schlüsselbund an die PCEP-Sitzung auf [edit protocols pcep pce pce-id]
Hierarchieebene binden.
Die folgende Konfiguration wird auf dem PCC ausgeführt, um eine sichere PCEP-Sitzung mit einem PCE einzurichten:
-
Verwendung des MD5-Authentifizierungsschlüssels:
[edit protocols pcep pce pce-id] user@PCC# set authentication-key key
-
Verwendung vordefinierter Authentifizierungs-Keychains:
[edit protocols pcep pce pce-id] user@PCC# set authentication-key-chain key-chain user@PCC# set authentication-algorithm md5
Damit sichere PCEP-Sitzungen erfolgreich eingerichtet werden können, muss die MD5-Authentifizierung mit dem vorab freigegebenen Authentifizierungsschlüssel sowohl auf dem PCE-Server als auch auf dem PCC konfiguriert werden. PCE und PCC verwenden denselben Schlüssel, um die Echtheit jedes Segments zu überprüfen, das über die TCP-Verbindung der PCEP-Sitzung gesendet wird.
-
Junos OS Version 16.1 unterstützt nur DIE TCP-MD5-Authentifizierung für PCEP-Sitzungen, ohne die Unterstützung für TLS und TCP-AO zu erweitern, z. B. Schutz vor Abhören, Manipulation und Nachrichtenfälschung.
-
Die erste Anwendung eines Sicherheitsmechanismus auf eine PCEP-Sitzung bewirkt, dass die Sitzung zurückgesetzt wird.
-
Wenn MD5 auf einer Seite der PCEP-Sitzung falsch konfiguriert oder nicht konfiguriert ist, wird die Sitzung nicht eingerichtet. Stellen Sie sicher, dass die Konfigurationen auf PCC und PCE übereinstimmen.
-
Diese Funktion bietet keine Unterstützung für einen Sitzungsauthentifizierungsmechanismus.
-
Verwenden
show path-computation-client status
Sie die Befehlsausgaben,show protocols pcep
um den von der PCEP-Sitzung verwendeten Authentifizierungsschlüssel anzuzeigen. -
Verwenden Sie den
show system statistics tcp | match auth
Befehl, um die Anzahl der Pakete anzuzeigen, die aufgrund von Authentifizierungsfehlern von TCP unterbrochen werden. -
Der Betrieb des Schlüsselbundes kann mithilfe der
show security keychain detail
Befehlsausgabe überprüft werden.
Auswirkungen der clientseitigen PCE-Implementierung auf die Netzwerkleistung
Die Pflege einer zustandsbehafteten Datenbank kann nicht trivial sein. In einer einzigen zentralisierten PCE-Umgebung muss ein Zustandsbehafteter PCE lediglich alle TE-LSPs, die vom PCE berechnet wurden, die tatsächlich eingerichteten TE-LSPs (falls dies bekannt sein kann) und an die Zeit, als die TE-LSPs abgerissen wurden, erinnern. Diese Anforderungen verursachen jedoch einen erheblichen Overhead für das Kontrollprotokoll in Bezug auf Zustand, Netzwerknutzung und -verarbeitung sowie die Optimierung von Verbindungen weltweit im gesamten Netzwerk. Daher umfassen die Bedenken einer stateful PCE-Implementierung:
-
Jeder zuverlässige Synchronisierungsmechanismus führt zu einem erheblichen Overhead auf der Steuerungsebene. PCEs können den Status synchronisieren, indem sie miteinander kommunizieren, aber wenn TE-LSPs mithilfe einer verteilten Berechnung zwischen mehreren PCEs eingerichtet werden, werden die Probleme bei der Synchronisierung und Vermeidung von Race-Bedingungen größer und komplexer.
-
Die Out-of-Band Traffic Engineering-Datenbanksynchronisierung kann komplex sein, wenn mehrere PCEs in einem verteilten PCE-Berechnungsmodell eingerichtet sind, und kann anfällig für Rennensbedingungen, Skalierbarkeitsbedenken usw. sein.
-
Pfadberechnungen unter Einbeziehung des Gesamtzustands des Netzwerks sind sehr komplex, selbst wenn der PCE detaillierte Informationen zu allen Pfaden, Prioritäten und Ebenen enthält.
Trotz der oben genannten Bedenken ist die teilweise clientseitige Implementierung des Stateful PCE in großen Traffic-Engineering-Systemen äußerst effektiv. Sie bietet eine schnelle Konvergenz und erhebliche Vorteile in Bezug auf die optimale Ressourcennutzung, indem sie die Anforderungen an globale Visibilität eines TE-LSP-Zustands und eine geordnete Steuerung der Pfadreservierungen über alle Geräte innerhalb des zu kontrollierenden Systems bietet.
Beispiel: Konfigurieren des Path Computation Element Protocol für MPLS RSVP-TE
Dieses Beispiel zeigt, wie sie das externe Path Computing durch ein Path Computation Element (PCE) für datenverkehrsbasierte Label-Switched Paths (TE LSPs) auf einem Path Computation Client (PCC) aktivieren. Außerdem wird gezeigt, wie Sie das Path Computation Element Protocol (PCEP) auf dem PCC konfigurieren, um die Kommunikation zwischen PCE und PCC zu ermöglichen.
Anforderungen
In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:
Drei Router, die eine Kombination aus Routern der ACX-Serie, Multiservice-Edge-Routern der M-Serie, universellen 5G-Routing-Plattformen der MX-Serie, Core-Routern der T-Serie oder Transport-Routern der PTX-Serie sein können, von denen einer als PCC konfiguriert ist.
Eine TCP-Verbindung zu einem externen Stateful PCE vom PCC.
Junos OS Version 12.3 oder höher, die auf dem PCC zusammen mit dem Add-on-Paket JSDN ausgeführt wird.
Das JSDN-Add-on-Paket muss zusammen mit dem Core-Junos OS-Installationspaket installiert werden.
Bevor Sie beginnen:
Konfigurieren Sie die Geräteschnittstellen.
Konfigurieren Sie MPLS und RSVP-TE.
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.
Die teilweise clientseitige Implementierung der stateful PCE-Architektur basiert auf Version 2 des Internet Draft-ietf-pce-stateful-pce. Ab Junos OS Version 16.1 wird diese Implementierung aktualisiert, um Version 7 zu unterstützen, wie in Internet Draft-ietf-pce-stateful-pce-07 definiert. Versionen vor 16.1 unterstützen die ältere Version des PCE-Entwurfs, was zu Interoperabilitätsproblemen zwischen einem PCC mit einer vorherigen Version und einem zustandsbehafteten PCE-Server führt, der internet draft-ietf-pce-stateful-pce-07 einhält.
Um die externe Pfadverarbeitung durch einen PCE zu ermöglichen, fügen Sie die lsp-external-controller
Anweisung auf PCC auf der [edit mpls]
Hierarchieebene ein [edit mpls lsp lsp-name]
.
lsp-external-controller pccd;
Ein mit der lsp-external-controller
Anweisung konfigurierter LSP wird als PCE-gesteuerter LSP bezeichnet und unterliegt standardmäßig der externen Kontrolle eines PCE. Ein aktiver Stateful-PCE kann die von der CLI festgelegten Parameter wie Bandbreite, Pfad (ERO) und Priorität für solche PCE-gesteuerten LSPs des PCC außer Kraft setzen.
Um die Kommunikation zwischen PCE und PCC zu ermöglichen, konfigurieren Sie PCEP auf der PCC-Hierarchieebene [edit protocols]
.
pcep { ... }
Beachten Sie bei der Konfiguration von PCEP auf einem PCC die folgenden Überlegungen:
Das JSDN-Add-on-Paket muss zusammen mit dem Core-Junos OS-Installationspaket installiert werden.
Junos OS Version 12.3 unterstützt nur stateful PCEs.
Ein PCC kann sich mit maximal 10 Stateful-PCEs verbinden. Zu einem bestimmten Zeitpunkt kann es nur einen Haupt-PCE (den PCE mit dem niedrigsten Prioritätswert oder den PCE, der sich bei Fehlen einer PCE-Priorität zuerst mit dem PCC verbindet) geben, an die der PCC LSPs für die Pfadberechnung delegiert.
Für Junos OS Version 12.3 initiiert pcC immer die PCEP-Sitzungen. PCEP-Sitzungen, die von Remote-PCEs initiiert werden, werden vom PCC nicht akzeptiert.
Vorhandene LSP-Funktionen wie LSP-Schutz und Make-before-Break sind für PCE-gesteuerte LSPs geeignet.
Die automatische Bandbreitenoption ist für PCE-gesteuerte LSPs deaktiviert, obwohl LSPs unter der Kontrolle von Auto-Bandwdith und einschränkungensbasiertem Routing mit PCE-gesteuerten LSPs koexistieren können.
PCE-gesteuerte LSPs können durch andere CLI-Konfigurationen wie lsp-nexthop zu Routen, Weiterleitungsadjacencies, CCC-Verbindungen und logische Tunnel verwiesen werden.
PCE-gesteuerte LSPs unterstützen GRES nicht.
PCE-gesteuerte LSPs unter logischen Systemen werden nicht unterstützt.
PCE-gesteuerte LSPs können keine Point-to-Multipoint-LSPs sein.
Bidirektionale LSPs werden nicht unterstützt.
PCE-gesteuerte LSPs können ohne einen primären Pfad keine sekundären Pfade haben.
PCE-gesteuerte LSPs sind auf externe Pfadberechnungen angewiesen, was sich auf die gesamte Einrichtungszeit, Umleitungen und Make-before-Break-Funktionen auswirkt.
Einrichtungszeit und Konvergenzzeit (Reroute, MBB) für bestehende LSPs sind die gleichen wie in früheren Versionen, wenn es keine PCE-gesteuerten LSPs gibt. Ein kleiner Einfluss ist jedoch in Anwesenheit von PCE-gesteuerten LSPs zu sehen.
Es wird erwartet, dass die ERO-Berechnungszeit deutlich höher sein wird als lokal-CSPF.
Topologie

In diesem Beispiel ist PCC der Eingangsrouter, der eine Verbindung zum externen aktiven Zustands-PCE herstellt.
Die externen LSPs des Routers PCC werden wie folgt berechnet:
Router PCC empfängt die LSP-Tunnelkonfiguration, die über die CLI eingerichtet wurde. Wenn die empfangene Konfiguration mit externem Path Computing aktiviert wird, wird Router PCC bewusst, dass einige der LSP-Attribute – Bandbreite, Pfad und Priorität – unter der Kontrolle des zustandsbehafteten PCE stehen und delegiert den LSP an den PCE.
In diesem Beispiel wird der externe LSP aufgerufen
PCC-to-R2
und von Router PCC zu Router R2 eingerichtet. Der CLI-konfigurierte ERO fürPCC-to-R2
ist PCC-R0-R1-R2. Die Bandbreite fürPCC-to-R2
beträgt 10 m, und sowohl die Prioritäts- als auch die Haltepriorität sind 4.Router PCC versucht, die PCE-gesteuerten LSP-Attribute abzurufen. Um dies zu tun, sendet Router PCC eine PCRpt-Nachricht an den Stateful-PCE, in der angegeben wird, dass der LSP konfiguriert wurde. Die PCRpt-Nachricht kommuniziert den Status des LSP und enthält die lokalen Konfigurationsparameter des LSP.
Der zustandsbehaftete PCE ändert eines oder mehrere der delegierten LSP-Attribute und sendet die neuen LSP-Parameter über die PCUpd-Nachricht an Router PCC.
Nach dem Erhalt der neuen LSP-Parameter richtet Router PCC einen neuen LSP ein und signalisiert ihn über den VON PCE bereitgestellten Pfad.
In diesem Beispiel ist der PCE-bereitgestellte ERO für
PCC-to-R2
PCC-R3-R2. Die Bandbreite fürPCC-to-R2
beträgt 8 m, und sowohl der Setup- als auch der Hold-Prioritätswert sind 3.Router PCC sendet einen PCRpt mit der neuen RRO an den Stateful PCE.
Konfiguration
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen sie in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, und kopieren Sie dann die Befehle und fügen sie auf Hierarchieebene in die [edit]
CLI ein.
PCC
set interfaces ge-1/0/1 unit 0 family inet address 20.31.4.1/24 set interfaces ge-1/0/1 unit 0 family iso set interfaces ge-1/0/1 unit 0 family mpls set interfaces ge-1/1/1 unit 0 family inet address 20.31.1.1/24 set interfaces ge-1/1/1 unit 0 family iso set interfaces ge-1/1/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.179.95/32 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls lsp-external-controller pccd set protocols mpls label-switched-path PCC-to-R2 to 10.255.179.98 set protocols mpls label-switched-path PCC-to-R2 bandwidth 10m set protocols mpls label-switched-path PCC-to-R2 priority 4 4 set protocols mpls label-switched-path PCC-to-R2 primary to-R2-path set protocols mpls label-switched-path PCC-to-R2 lsp-external-controller pccd set protocols mpls path to-R2-path 20.31.1.2 strict set protocols mpls path to-R2-path 20.31.2.2 strict set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols isis level 1 disable set protocols isis interface all set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0 set protocols pcep pce pce1 destination-ipv4-address 10.209.57.166 set protocols pcep pce pce1 destination-port 4189 set protocols pcep pce pce1 pce-type active set protocols pcep pce pce1 pce-type stateful
R0
set interfaces ge-1/0/6 unit 0 family inet address 20.31.1.2/24 set interfaces ge-1/0/6 unit 0 family iso set interfaces ge-1/0/6 unit 0 family mpls set interfaces ge-1/0/7 unit 0 family inet address 20.31.2.1/24 set interfaces ge-1/0/7 unit 0 family iso set interfaces ge-1/0/7 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.179.96/32 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols isis level 1 disable set protocols isis interface all set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0
R1
set system ports console log-out-on-disconnect set interfaces ge-2/0/3 unit 0 family inet address 20.31.2.2/24 set interfaces ge-2/0/3 unit 0 family iso set interfaces ge-2/0/3 unit 0 family mpls set interfaces ge-2/0/4 unit 0 family inet address 20.31.8.1/24 set interfaces ge-2/0/4 unit 0 family iso set interfaces ge-2/0/4 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.179.97/32 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols isis level 1 disable set protocols isis interface all set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0
R2
set interfaces ge-1/0/2 unit 0 family inet address 20.31.8.2/24 set interfaces ge-1/0/2 unit 0 family iso set interfaces ge-1/0/2 unit 0 family mpls set interfaces ge-1/0/3 unit 0 family inet address 20.31.5.2/24 set interfaces ge-1/0/3 unit 0 family iso set interfaces ge-1/0/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.179.98/32 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols isis level 1 disable set protocols isis interface all set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0
R3
set interfaces ge-2/0/1 unit 0 family inet address 20.31.4.2/24 set interfaces ge-2/0/1 unit 0 family iso set interfaces ge-2/0/1 unit 0 family mpls set interfaces ge-2/0/3 unit 0 family inet address 20.31.5.1/24 set interfaces ge-2/0/3 unit 0 family iso set interfaces ge-2/0/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.179.99/32 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols isis level 1 disable set protocols isis interface all set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0
Verfahren
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie auf verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus.
So konfigurieren Sie Router PCC:
Wiederholen Sie diese Prozedur für jeden Eingangsrouter von Juniper Networks in der MPLS-Domäne, nachdem Sie die entsprechenden Schnittstellennamen, Adressen und sonstigen Parameter für jeden Router geändert haben.
Konfigurieren Sie die Schnittstellen.
Um MPLS zu aktivieren, fügen Sie die Protokollfamilie in die Schnittstelle ein, damit die Schnittstelle eingehenden MPLS-Datenverkehr nicht verwirft.
[edit interfaces]
user@PCC# set ge-1/0/1 unit 0 family inet address 20.31.4.1/24 user@PCC# set ge-1/0/1 unit 0 family iso user@PCC# set ge-1/0/1 unit 0 family mpls user@PCC# set ge-1/1/1 unit 0 family inet address 20.31.1.1/24 user@PCC# set ge-1/1/1 unit 0 family iso user@PCC# set ge-1/1/1 unit 0 family mpls user@PCC# set lo0 unit 0 family inet address 10.255.179.95/32Aktivieren Sie RSVP auf allen Schnittstellen von Router PCC, mit Ausnahme der Verwaltungsschnittstelle.
[edit protocols]
user@PCC# set rsvp interface all user@PCC# set rsvp interface fxp0.0 disableKonfigurieren Sie den Label-Switched Path (LSP) vom Router PCC zum Router R2 und ermöglichen Sie die externe Steuerung von LSPs durch den PCE.
[edit protocols] user@PCC# set mpls lsp-external-controller pccd user@PCC# set mpls label-switched-path PCC-to-R2 to 10.255.179.98/32 user@PCC# set mpls label-switched-path PCC-to-R2 bandwidth 10m user@PCC# set protocols mpls label-switched-path PCC-to-R2 priority 4 4 user@PCC# set protocols mpls label-switched-path PCC-to-R2 primary to-R2-path user@PCC# set protocols mpls label-switched-path PCC-to-R2 lsp-external-controller pccd
Konfigurieren Sie den LSP von Router PCC zu Router R2, der über eine lokale Kontrolle verfügt und von den PCE-bereitgestellten LSP-Parametern außer Kraft gesetzt wird.
[edit protocols] user@PCC# set mpls path to-R2-path 20.31.1.2/30 strict user@PCC# set mpls path to-R2-path 20.31.2.2/30 strict
Aktivieren Sie MPLS auf allen Schnittstellen von Router PCC mit Ausnahme der Verwaltungsschnittstelle.
[edit protocols] user@PCC# set mpls interface all user@PCC# set mpls interface fxp0.0 disable
Konfigurieren Sie IS-IS auf allen Schnittstellen des Router-PCC mit Ausnahme der Verwaltungsschnittstelle.
[edit protocols] user@PCC# set isis level 1 disable user@PCC# set isis interface all user@PCC# set isis interface fxp0.0 disable user@PCC# set isis interface lo0.0
Definieren Sie den PCE, mit dem Router PCC verbunden ist, und konfigurieren Sie die IP-Adresse des PCE.
[edit protocols] user@PCC# set pcep pce pce1 destination-ipv4-address 10.209.57.166
Konfigurieren Sie den Zielport für Router-PCC, der mithilfe des TCP-basierten PCEP mit einem PCE verbindet.
[edit protocols] user@PCC# set pcep pce pce1 destination-port 4189
Konfigurieren Sie den PCE-Typ.
[edit protocols] user@PCC# set pcep pce pce1 pce-type active user@PCC# set pcep pce pce1 pce-type stateful
Ergebnisse
Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie die show interfaces
befehle eingeben show protocols
. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@PCC# show interfaces
ge-1/0/1 {
unit 0 {
family inet {
address 20.31.4.1/24;
}
family iso;
family mpls;
}
}
ge-1/1/1 {
unit 0 {
family inet {
address 20.31.1.1/24;
}
family iso;
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.179.95/32;
}
}
}
user@PCC# show protocols
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
lsp-external-controller pccd;
label-switched-path PCC-to-R2 {
to 10.255.179.98;
bandwidth 10m;
priority 4 4;
primary to-R2-path;
lsp-external-controller pccd;
}
path to-R2-path {
20.31.1.2 strict;
20.31.2.2 strict;
}
interface all;
interface fxp0.0 {
disable;
}
}
isis {
level 1 disable;
interface all;
interface fxp0.0 {
disable;
}
interface lo0.0;
}
pcep {
pce pce1 {
destination-ipv4-address 10.209.57.166;
destination-port 4189;
pce-type active stateful;
}
}
Wenn Sie mit der Konfiguration des Geräts fertig sind, geben Sie im Konfigurationsmodus ein commit
.
Überprüfung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
- Überprüfung des PCEP-Sitzungsstatus
- Überprüfung des PCE-gesteuerten LSP-Status, wenn die LSP-Steuerung extern ist
- Überprüfung des PCE-gesteuerten LSP-Status, wenn die LSP-Steuerung lokal ist
Überprüfung des PCEP-Sitzungsstatus
Zweck
Überprüfen Sie den PCEP-Sitzungsstatus zwischen pcE und Router PCC, wenn der PCE-Status ist.
Aktion
Führen Sie den Befehl im show path-computation-client active-pce
Betriebsmodus aus.
user@PCC>
show path-computation-client active-pce
PCE pce1
General
IP address : 10.209.57.166
Priority : 0
PCE status : PCE_STATE_UP
Session type : PCE_TYPE_STATEFULACTIVE
PCE-mastership : main
Counters
PCReqs Total: 0 last 5min: 0 last hour: 0
PCReps Total: 0 last 5min: 0 last hour: 0
PCRpts Total: 5 last 5min: 5 last hour: 5
PCUpdates Total: 1 last 5min: 1 last hour: 1
Timers
Local Keepalive timer: 30 [s] Dead timer: 120 [s]
Remote Keepalive timer: 30 [s] Dead timer: 120 [s]
Errors
PCErr-recv
PCErr-sent
PCE-PCC-NTFS
PCC-PCE-NTFS
Bedeutung
Die Ausgabe zeigt Informationen über den aktuellen aktiven Status-PCE an, mit dem Router PCC verbunden ist. Das PCE status
Ausgabefeld gibt den aktuellen Status der PCEP-Sitzung zwischen PCE und Router PCC an.
Für pce1
ist der Status der PCEP-Sitzung PCE_STATE_UP
, was angibt, dass die PCEP-Sitzung zwischen den PCEP-Peers eingerichtet wurde.
Die Statistik zeigt PCRpts
die Anzahl der Nachrichten an, die vom Router PCC an den PCE gesendet werden, um den aktuellen Status der LSPs zu melden. Die PCUpdates
Statistik zeigt die Anzahl der Nachrichten an, die Router PCC vom PCE empfangen. Die PCUpdates
Meldungen enthalten die PCE-geänderten Parameter für die PCE-gesteuerten LSPs.
Überprüfung des PCE-gesteuerten LSP-Status, wenn die LSP-Steuerung extern ist
Zweck
Überprüfen Sie den Status des PCE-gesteuerten LSP von Router PCC zu Router R2, wenn der LSP unter externer Kontrolle steht.
Aktion
Führen Sie den Befehl im show mpls lsp name PCC-to-R2 extensive
Betriebsmodus aus.
user@PCC>
show mpls lsp name PCC-to-R2 extensive
Ingress LSP: 1 sessions
10.255.179.98
From: 10.255.183.59, State: Up, ActiveRoute: 0, LSPname: PCC-to-R2
ActivePath: to-R2-path (primary)
LSPtype: Externally controlled, Penultimate hop popping
LSP Control Status: Externally controlled
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary to-R2-path State: Up
Priorities: 3 3
Bandwidth: 8Mbps
SmartOptimizeTimer: 180
No computed ERO.
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
20.31.4.2 20.31.5.2
21 Mar 11 05:00:56.736 EXTCTRL LSP: Sent Path computation request and LSP status
20 Mar 11 05:00:56.736 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
19 Mar 11 05:00:56.735 Selected as active path
18 Mar 11 05:00:56.734 EXTCTRL LSP: Sent Path computation request and LSP status
17 Mar 11 05:00:56.734 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
16 Mar 11 05:00:56.734 Record Route: 20.31.4.2 20.31.5.2
15 Mar 11 05:00:56.734 Up
14 Mar 11 05:00:56.713 EXTCTRL LSP: Sent Path computation request and LSP status
13 Mar 11 05:00:56.713 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
12 Mar 11 05:00:56.712 Originate Call
11 Mar 11 05:00:56.712 EXTCTRL_LSP: Received setup parameters : 20.31.4.2 20.31.5.2
10 Mar 11 05:00:49.283 EXTCTRL LSP: Sent Path computation request and LSP status
9 Mar 11 05:00:49.283 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
8 Mar 11 05:00:20.581 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
7 Mar 11 05:00:20.581 EXTCTRL LSP: Sent Path computation request and LSP status
6 Mar 11 05:00:20.581 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
5 Mar 11 05:00:20.580 EXTCTRL_LSP: Control status became external
4 Mar 11 05:00:03.716 EXTCTRL_LSP: Control status became local
3 Mar 11 05:00:03.714 EXTCTRL LSP: Sent Path computation request and LSP status
2 Mar 11 05:00:03.714 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
1 Mar 11 05:00:00.279 EXTCTRL LSP: Awaiting external controller connection
Created: Mon Mar 11 05:00:00 2013
Total 1 displayed, Up 1, Down 0
Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Bedeutung
In der Ausgabe zeigen die Felder und LSP Control Status
die LSPtype
Ausgabefelder, dass der LSP extern gesteuert wird. Die Ausgabe zeigt auch ein Protokoll der PCEP-Nachrichten, die zwischen Router PCC und PCE gesendet werden.
Die PCEP-Sitzung zwischen PCE und Router PCC ist verfügbar, und Router PCC empfängt die folgenden PCE-gesteuerten LSP-Parameter:
ERO (Pfad) – 20.31.4.2 und 20.31.5.2
Bandwidth—8Mbps
Prioritäten – 3 3 (Werte für Einrichtung und Halten)
Überprüfung des PCE-gesteuerten LSP-Status, wenn die LSP-Steuerung lokal ist
Zweck
Überprüfen Sie den Status des PCE-gesteuerten LSP von Router PCC zu Router R2, wenn die LSP-Steuerung lokal wird.
Aktion
Führen Sie den Befehl im show mpls lsp name PCC-to-R2 extensive
Betriebsmodus aus.
user@PCC>
show mpls lsp name PCC-to-R2 extensive
Ingress LSP: 1 sessions
10.255.179.98
From: 10.255.183.59, State: Up, ActiveRoute: 0, LSPname: PCC-to-R2
ActivePath: to-R2-path (primary)
LSPtype: Externally controlled, Penultimate hop popping
LSP Control Status: Locally controlled
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary to-R2-path State: Up
Priorities: 4 4 (ActualPriorities 3 3)
Bandwidth: 10Mbps (ActualBandwidth: 8Mbps)
SmartOptimizeTimer: 180
No computed ERO.
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
20.31.4.2 20.31.5.2
22 Mar 11 05:02:09.618 EXTCTRL_LSP: Control status became local
21 Mar 11 05:00:56.736 EXTCTRL LSP: Sent Path computation request and LSP status
20 Mar 11 05:00:56.736 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
19 Mar 11 05:00:56.735 Selected as active path
18 Mar 11 05:00:56.734 EXTCTRL LSP: Sent Path computation request and LSP status
17 Mar 11 05:00:56.734 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
16 Mar 11 05:00:56.734 Record Route: 20.31.4.2 20.31.5.2
15 Mar 11 05:00:56.734 Up
14 Mar 11 05:00:56.713 EXTCTRL LSP: Sent Path computation request and LSP status
13 Mar 11 05:00:56.713 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
12 Mar 11 05:00:56.712 Originate Call
11 Mar 11 05:00:56.712 EXTCTRL_LSP: Received setup parameters : 20.31.4.2 20.31.5.2
10 Mar 11 05:00:49.283 EXTCTRL LSP: Sent Path computation request and LSP status
9 Mar 11 05:00:49.283 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
8 Mar 11 05:00:20.581 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
7 Mar 11 05:00:20.581 EXTCTRL LSP: Sent Path computation request and LSP status
6 Mar 11 05:00:20.581 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
5 Mar 11 05:00:20.580 EXTCTRL_LSP: Control status became external
4 Mar 11 05:00:03.716 EXTCTRL_LSP: Control status became local
3 Mar 11 05:00:03.714 EXTCTRL LSP: Sent Path computation request and LSP status
2 Mar 11 05:00:03.714 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
1 Mar 11 05:00:00.279 EXTCTRL LSP: Awaiting external controller connection
Created: Mon Mar 11 05:00:00 2013
Total 1 displayed, Up 1, Down 0
Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Bedeutung
In der Ausgabe zeigt das LSP Control Status
Ausgabefeld, dass der LSP unter lokaler Kontrolle steht. Obwohl der PCE-gesteuerte LSP unter lokaler Kontrolle steht, verwendet Router PCC weiterhin die von PCE bereitgestellten Parameter, bis die nächste Gelegenheit, den LSP neu zu signalisieren.
Die Ausgabe zeigt nun die LSP-Parameter an, die mit der CLI konfiguriert wurden, zusammen mit den PCE-bereitgestellten Parametern, die verwendet werden, um den LSP als die tatsächlich verwendeten Werte festzulegen.
Bandbreite – 10 Mbit/s (tatsächlicheBandbreite: 8 Mbit/s)
Prioritäten – 4 4 (Tatsächliche Prioritäten 3 3)
Auf dem Trigger, um den LSP erneut zu signalisieren, verwendet Router PCC die lokalen Konfigurationsparameter, um den PCE-gesteuerten LSP einzurichten.
user@PCC>
show mpls lsp name PCC-to-R2 extensive externally-controlled
Ingress LSP: 1 sessions
10.255.179.98
From: 10.255.183.59, State: Up, ActiveRoute: 0, LSPname: PCC-to-R2
ActivePath: to-R2-path (primary)
LSPtype: Externally controlled, Penultimate hop popping
LSP Control Status: Locally controlled
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary to-R2-path State: Up
Priorities: 4 4
Bandwidth: 10Mbps
SmartOptimizeTimer: 180
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30)
20.31.1.2 S 20.31.2.2 S 20.31.8.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
20.31.1.2 20.31.2.2 20.31.8.2
28 Mar 11 05:02:51.787 Record Route: 20.31.1.2 20.31.2.2 20.31.8.2
27 Mar 11 05:02:51.787 Up
26 Mar 11 05:02:51.697 EXTCTRL_LSP: Applying local parameters with this signalling attempt
25 Mar 11 05:02:51.697 Originate Call
24 Mar 11 05:02:51.696 Clear Call
23 Mar 11 05:02:51.696 CSPF: computation result accepted 20.31.1.2 20.31.2.2 20.31.8.2
22 Mar 11 05:02:09.618 EXTCTRL_LSP: Control status became local
21 Mar 11 05:00:56.736 EXTCTRL LSP: Sent Path computation request and LSP status
20 Mar 11 05:00:56.736 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
19 Mar 11 05:00:56.735 Selected as active path
18 Mar 11 05:00:56.734 EXTCTRL LSP: Sent Path computation request and LSP status
17 Mar 11 05:00:56.734 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
16 Mar 11 05:00:56.734 Record Route: 20.31.4.2 20.31.5.2
15 Mar 11 05:00:56.734 Up
14 Mar 11 05:00:56.713 EXTCTRL LSP: Sent Path computation request and LSP status
13 Mar 11 05:00:56.713 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
12 Mar 11 05:00:56.712 Originate Call
11 Mar 11 05:00:56.712 EXTCTRL_LSP: Received setup parameters : 20.31.4.2 20.31.5.2
10 Mar 11 05:00:49.283 EXTCTRL LSP: Sent Path computation request and LSP status
9 Mar 11 05:00:49.283 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
8 Mar 11 05:00:20.581 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
7 Mar 11 05:00:20.581 EXTCTRL LSP: Sent Path computation request and LSP status
6 Mar 11 05:00:20.581 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
5 Mar 11 05:00:20.580 EXTCTRL_LSP: Control status became external
4 Mar 11 05:00:03.716 EXTCTRL_LSP: Control status became local
3 Mar 11 05:00:03.714 EXTCTRL LSP: Sent Path computation request and LSP status
2 Mar 11 05:00:03.714 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
1 Mar 11 05:00:00.279 EXTCTRL LSP: Awaiting external controller connection
Created: Mon Mar 11 05:00:00 2013
Total 1 displayed, Up 1, Down 0
Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Dies Computed ERO
ist 20.31.1.2, 20.31.2.2 und 20.31.8.2. Der PCE-gesteuerte LSP wird mithilfe der lokalen Konfigurationsparameter eingerichtet.
Beispiel: Konfigurieren des Path Computation Element Protocol für MPLS RSVP-TE mit Unterstützung von PCE-initiierten Point-to-Point-LSPs
Dieses Beispiel zeigt, wie Sie den Path Computation Client (PCC) mit der Fähigkeit konfigurieren, von Path Computation Element (PCE) initiierte, datenverkehrsgesteuerte Punkt-zu-Punkt-Label-Switched Paths (LSPs) zu unterstützen.
Anforderungen
In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:
Drei Router, die eine Kombination aus Routern der ACX-, M-, MX- oder T-Serie sein können.
Eine TCP-Verbindung zu zwei externen Stateful-PCEs vom Eingangsrouter (PCC).
Junos OS Version 16.1 oder höher, die auf dem PCC ausgeführt wird.
Bevor Sie beginnen:
Konfigurieren Sie die Geräteschnittstellen.
Konfigurieren Sie MPLS und RSVP-TE (RSVP-Traffic Engineering).
Konfigurieren Sie OSPF oder ein anderes IGP-Protokoll.
Überblick
Ab Junos OS Version 16.1 wird die PCEP-Funktionalität erweitert, um einem Stateful-PCE die Initiierung und Bereitstellung von Traffic-Engineering-LSPs über ein PCC zu ermöglichen. Zuvor wurden die LSPs auf dem PCC konfiguriert und der PCC die Kontrolle über die externen LSPs an einen PCE delegiert. Das Eigentum des LSP-Staates wurde vom PCC gehalten. Mit der Einführung der PCE-initiierten LSPs kann ein PCE einen Point-to-Point-LSP des Datenverkehrs dynamisch initiieren und bereitstellen, ohne dass ein lokal konfigurierter LSP auf dem PCC erforderlich ist. Beim Erhalt einer PCE-Nachricht erstellt das PCC den PCE-initiierten LSP und delegiert den LSP automatisch an den PCE.
Beachten Sie bei der Konfiguration der Unterstützung von PCE-initiierten Punkt-zu-Punkt-LSPs für ein PCC die folgenden Überlegungen:
Junos OS Version 13.3 unterstützt nur Stateful-PCEs.
Für Junos OS Version 13.3 initiiert der PCC immer die PCEP-Sitzungen. PCEP-Sitzungen, die von Remote-PCEs initiiert werden, werden vom PCC nicht akzeptiert.
Vorhandene LSP-Funktionen, wie LSP-Schutz und Make-before-Break, sind für PCE-initiierte LSPs geeignet.
PCE-initiierte LSPs unterstützen keine Graceful Routing Engine Switchover (GRES).
PCE-initiierte LSPs unter logischen Systemen werden nicht unterstützt.
PCE-initiierte LSPs können keine Point-to-Multipoint-LSPs sein.
Bidirektionale LSPs werden nicht unterstützt.
RSVP-TE für nicht nummerierte Links wird nicht unterstützt. PCE-initiierte LSPs unterstützen nur nummerierte Links.
Der PCE, der einen Segment-Routing-LSP initiiert, kann die Bindungs-Segment-ID (SID)-Label verwenden, die mit nicht farbigen Segment-Routing-LSPs verknüpft sind, um die PCE-initiierten Segment-Routing-LSP-Pfade bereitzustellen.
Ab Junos OS Version 18.2R1 werden statisch konfigurierte nicht farbige Segment-Routing-LSPs auf dem Eingangsgerät über eine PCEP-Sitzung an einen PCE gemeldet. Diesen nicht farbigen Segment-Routing-LSPs sind möglicherweise verbindliche SID-Label zugeordnet. Mit dieser Funktion kann der PCE dieses verbindliche SID-Label im Labelstack verwenden, um PCE-initiierte Segment-Routing-LSP-Pfade bereitzustellen.
Topologie

In diesem Beispiel ist PCC der Eingangsrouter, der eine Verbindung zu zwei externen zustandsbehafteten PCEs herstellt: PCE1 und PCE2.
Wenn eine neue Nachfrage besteht, initiiert der aktive Stateful-PCE dynamisch einen LSP, um die Anforderung zu erfüllen. Da PCC mit der Fähigkeit konfiguriert ist, den PCE-initiierten LSP zu unterstützen, wird die Pfadberechnung auf PCC wie folgt durchgeführt:
Ein PCE sendet eine PCCreate-Nachricht an den PCC, um einen LSP zu initiieren und bereitzustellen. Der PCC richtet den PCE-initiierten LSP unter Verwendung der vom PCE empfangenen Parameter ein und delegiert den PCE-initiierten LSP automatisch an den PCE, der ihn initiiert hat.
In diesem Beispiel ist PCE1 der aktive Stateful-PCE, der den PCE-initiierten LSP auf PCC initiiert und bereitgestellt. Nach erhalt der PCE-initiierten LSP-Parameter richtet PCC den LSP ein und delegiert automatisch den PCE-initiierten LSP an PCE1.
Wenn die PCEP-Sitzung zwischen PCC und PCE1 beendet wird, startet PCC zwei Timer für den PCE1-initiierten LSP: Timeout für Delgation Cleanup und den LSP-Bereinigungs-Timer. Während dieser Zeit kann PCE1 oder PCE2 die Kontrolle über den PCE-initiierten LSP übernehmen.
Wenn PCE2 vor Ablauf des LSP-Bereinigungs-Timers die Kontrolle über den PCE-initiierten LSP erhält, delegiert PCC den PCE-initiierten LSP an PCE2, und der LSP-Bereinigungs-Timeout und die Zeitüberschreitung für die Delegierungsbereinigung werden angehalten.
Wenn das Timeout für die Delegierungsbereinigung abgelaufen ist und weder PCE1 noch PCE2 die Kontrolle über den PCE-initiierten LSP übernommen haben, übernimmt PCC die lokale Kontrolle über den nicht delegierte PCE-initiierten LSP bis zum Ablauf des LSP-Bereinigungs-Timers.
Nach Ablauf des LSP-Bereinigungs-Timers löscht PCC den PCE-initiierten LSP, der von PCE1 bereitgestellt wird.
Konfiguration
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen sie in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, und kopieren Sie dann die Befehle und fügen sie auf Hierarchieebene in die [edit]
CLI ein.
PCC
set interfaces ge-0/1/1 unit 0 family inet address 10.0.102.9/24 set interfaces ge-0/1/1 unit 0 family iso set interfaces ge-0/1/1 unit 0 family mpls set interfaces ge-0/1/3 unit 0 family inet address 10.0.112.14/24 set interfaces ge-0/1/3 unit 0 family iso set interfaces ge-0/1/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.12.1/32 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls lsp-external-controller ppcd set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols pcep pce-group PCEGROUP pce-type active set protocols pcep pce-group PCEGROUP pce-type stateful set protocols pcep pce-group PCEGROUP lsp-provisioning set protocols pcep pce-group PCEGROUP lsp-cleanup-timer 30 set protocols pcep pce PCE1 destination-ipv4-address 192.168.69.58 set protocols pcep pce PCE1 destination-port 4189 set protocols pcep pce PCE1 pce-group PCEGROUP set protocols pcep pce PCE2 destination-ipv4-address 192.168.70.65 set protocols pcep pce PCE2 destination-port 4189 set protocols pcep pce PCE2 pce-group PCEGROUP
R1
set interfaces ge-3/1/1 unit 0 family inet address 10.0.102.10/24 set interfaces ge-3/1/1 unit 0 family iso set interfaces ge-3/1/1 unit 0 family mpls set interfaces ge-3/1/2 unit 0 family inet address 10.0.101.9/24 set interfaces ge-3/1/2 unit 0 family iso set interfaces ge-3/1/2 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.10.1/32 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable
R2
set interfaces ge-0/1/1 unit 0 family inet address 10.0.101.10/24 set interfaces ge-0/1/1 unit 0 family iso set interfaces ge-0/1/1 unit 0 family mpls set interfaces ge-0/1/3 unit 0 family inet address 10.0.112.13/24 set interfaces ge-0/1/3 unit 0 family iso set interfaces ge-0/1/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.11.1/32 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable
Verfahren
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie auf verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus.
So konfigurieren Sie den PCC-Router:
Wiederholen Sie diese Prozedur für jeden Eingangsrouter von Juniper Networks in der MPLS-Domäne, nachdem Sie die entsprechenden Schnittstellennamen, Adressen und sonstigen Parameter für jeden Router geändert haben.
Konfigurieren Sie die Schnittstellen.
Um MPLS zu aktivieren, fügen Sie die Protokollfamilie in die Schnittstelle ein, damit die Schnittstelle eingehenden MPLS-Datenverkehr nicht verwirft.
[edit interfaces]
user@PCC# set ge-0/1/1 unit 0 family inet address 10.0.102.9/24 user@PCC# set ge-0/1/1 unit 0 family iso user@PCC# set ge-0/1/1 unit 0 family mpls user@PCC# set ge-0/1/3 unit 0 family inet address 10.0.112.14/24 user@PCC# set ge-0/1/3 unit 0 family iso user@PCC# set ge-0/1/3 unit 0 family mpls user@PCC# set lo0 unit 0 family inet address 192.168.12.1/32Aktivieren Sie RSVP auf allen Schnittstellen des PCC mit Ausnahme der Verwaltungsschnittstelle.
[edit protocols]
user@PCC# set rsvp interface all user@PCC# set rsvp interface fxp0.0 disableErmöglichen Sie die externe Kontrolle von LSPs durch die PCEs.
[edit protocols] user@PCC# set mpls lsp-external-controller pccd
Aktivieren Sie MPLS auf allen Schnittstellen des PCC mit Ausnahme der Verwaltungsschnittstelle.
[edit protocols] user@PCC# set mpls interface all user@PCC# set mpls interface fxp0.0 disable
Konfigurieren Sie OSPF auf allen Schnittstellen des PCC mit Ausnahme der Verwaltungsschnittstelle.
[edit protocols] user@PCC# set ospf traffic-engineering user@PCC# set ospf area 0.0.0.0 interface all user@PCC# set ospf area 0.0.0.0 interface fxp0.0 disable user@PCC# set ospf interface lo0.0
Definieren Sie die PCE-Gruppe und aktivieren Sie die Unterstützung von PCE-initiierten LSPs für die PCE-Gruppe.
[edit protocols] user@PCC# set protocols pcep pce-group PCEGROUP pce-type active user@PCC# set protocols pcep pce-group PCEGROUP pce-type stateful user@PCC# set protocols pcep pce-group PCEGROUP lsp-provisioning user@PCC# set protocols pcep pce-group PCEGROUP lsp-cleanup-timer 30
Definieren Sie die PCEs, die mit dem PCC verbunden sind.
[edit protocols] user@PCC# set pcep pce PCE1 destination-ipv4-address 192.168.69.58 user@PCC# set pcep pce PCE1 destination-port 4189 user@PCC# set pcep pce PCE1 pce-group PCEGROUP user@PCC# set pcep pce PCE2 destination-ipv4-address 192.168.70.65 user@PCC# set pcep pce PCE2 destination-port 4189 user@PCC# set pcep pce PCE2 pce-group PCEGROUP
Ergebnisse
Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie die show interfaces
befehle eingeben show protocols
. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@PCC# show interfaces
ge-0/1/1 {
unit 0 {
family inet {
address 10.0.102.9/24;
}
family iso;
family mpls;
}
}
ge-0/1/3 {
unit 0 {
family inet {
address 10.0.112.14/24;
}
family iso;
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 192.168.12.1/32;
}
}
}
user@PCC# show protocols
rsvp {
interface all;
}
interface fxp0.0 {
disable;
}
}
mpls {
lsp-external-controller pccd;
interface all;
interface fxp0.0 {
disable;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface all;
interface fxp0.0 {
disable;
}
}
}
pce-group PCEGROUP {
pce-type active stateful;
lsp-provisioning;
lsp-cleanup-timer 30;
}
pce PCE1 {
destination-ipv4-address 192.168.69.58;
destination-port 4189;
pce-group PCEGROUP;
}
pce PCE2 {
destination-ipv4-address 192.168.70.65;
destination-port 4189;
pce-group PCEGROUP;
}
Wenn Sie mit der Konfiguration des Geräts fertig sind, geben Sie im Konfigurationsmodus ein commit
.
Überprüfung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
- Überprüfung des PCC-Status
- Überprüfung des PCE1-Status
- Überprüfung des PCE-initiierten LSP-Status bei externer Bereitstellung des LSP
Überprüfung des PCC-Status
Zweck
Überprüfen Sie den PCEP-Sitzungsstatus und die LSP-Zusammenfassung zwischen dem PCC und den angeschlossenen PCEs.
Aktion
Führen Sie den Befehl im show path-computation-client status
Betriebsmodus aus.
user@PCC# show path-computation-client status Session Type Provisioning Status PCE1 Stateful Active On Up PCE2 Stateful Active On Up LSP Summary Total number of LSPs : 1 Static LSPs : 0 Externally controlled LSPs : 0 Externally provisioned LSPs : 1/16000 (current/limit) Orphaned LSPs : 0 PCE1 (main) Delegated : 1 Externally provisioned : 1 PCE2 Delegated : 0 Externally provisioned : 0
Bedeutung
Die Ausgabe zeigt den Status der PCEP-Sitzung zwischen den aktiven Stateful-PCEs und dem PCC an. Außerdem werden Informationen über die verschiedenen Arten von LSPs auf dem PCC und die Anzahl der LSPs angezeigt, die von den angeschlossenen PCEs bereitgestellt und an sie delegiert werden.
PCE1 ist der wichtigste aktive PCE und verfügt über einen PCE-initiierten LSP, der automatisch vom PCC delegiert wurde.
Überprüfung des PCE1-Status
Zweck
Überprüfen Sie den Status des hauptaktiven Status-PCE.
Aktion
Führen Sie den Befehl im show path-computation-client active-pce detail
Betriebsmodus aus.
user@PCC# show path-computation-client active-pce PCE PCE1 -------------------------------------------- General IP address : 192.168.69.58 Priority : 0 PCE status : PCE_STATE_UP Session type : PCE_TYPE_STATEFULACTIVE LSP provisioning allowed : On LSP cleanup timer : 30 [s] PCE-mastership : main Max unknown messages : 5 Keepalives received : 0 Keepalives sent : 0 Dead timer : 0 [s] Elapsed as main current : 1 [s] Elapsed as main total : 446380 [s] Unknown msgs/min rate : 0 Session failures : 2198 Corrupted messages : 0 Delegation timeout set : 30 Delegation timeout in : 0 [s] Delegation failures : 0 Connection down : 167092 [s] Counters PCReqs Total: 0 last 5min: 0 last hour: 0 PCReps Total: 0 last 5min: 0 last hour: 0 PCRpts Total: 5 last 5min: 5 last hour: 5 PCUpdates Total: 0 last 5min: 0 last hour: 0 PCCreates Total: 1 last 5min: 1 last hour: 1 Timers Local Keepalive timer: 30 [s] Dead timer: 120 [s] LSP cleanup timer: 30 [s] Remote Keepalive timer: 0 [s] Dead timer: 0 [s] LSP cleanup timer: - [s] Errors PCErr-recv PCErr-sent PCE-PCC-NTFS PCC-PCE-NTFS
Bedeutung
Die Ausgabe zeigt Informationen über den aktuellen aktiven Zustands-PCE an, mit dem das PCC verbunden ist. Das PCE status
Ausgabefeld gibt den aktuellen Status der PCEP-Sitzung zwischen einem PCE und PCC an.
Für PCE1 ist PCE_STATE_UP
der Status der PCEP-Sitzung , was angibt, dass die PCEP-Sitzung mit dem PCC eingerichtet wurde.
Überprüfung des PCE-initiierten LSP-Status bei externer Bereitstellung des LSP
Zweck
Überprüfen Sie den Status des PCE-initiierten LSP.
Aktion
Führen Sie den Befehl im show mpls lsp externally-provisioned detail
Betriebsmodus aus.
user@PCC# show mpls lsp externally-provisioned detail Ingress LSP: 1 sessions 10.0.101.10 From: 10.0.102.9, State: Up, ActiveRoute: 0, LSPname: lsp15 ActivePath: path1 (primary) Link protection desired LSPtype: Externally Provisioned, Penultimate hop popping LSP Control Status: Externally controlled LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 *Primary path1 State: Up Priorities: 7 0 Bandwidth: 8Mbps Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3) 10.0.102.10 S 10.0.101.9 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 10.0.102.10 S 10.0.101.9 S
Bedeutung
In der Ausgabe zeigt das LSPtype
Ausgabefeld, dass der LSP extern bereitgestellt wird.
Die PCEP-Sitzung zwischen PCC und PCE1 ist verfügbar, und das PCC empfängt die folgenden PCE-initiierten LSP-Parameter:
ERO (Pfad) – 10.0.102.10 und 10.0.101.9
Bandbreite – 8 Mbit/s
Priorität – 7 0 (Setup- und Haltewerte)
Konfigurieren des Path Computation Element Protocol für MPLS RSVP-TE mit Unterstützung von PCE-initiierten Point-to-Point-LSPs
Sie können einen Path Computation Client (PCC) konfigurieren, der dynamisch erstellte Label Switched Paths (LSPs) von einer zentralisierten externen Path Computing-Entität unterstützt. Ein Stateful Path Computaiton Element (PCE) kann verwendet werden, um externe Pfadberechnungen durchzuführen und bei steigender Nachfrage dynamische LSPs zu generieren.
Ein PCC erstellt den PCE-initiierten Point-to-Point-LSP unter Verwendung der von PCE bereitgestellten LSP-Parameter oder Parameter aus einer vorkonfigurierten LSP-Vorlage, wenn der PCE den LSP nicht bereitstellt, und delegiert automatisch den PCE-initiierten Punkt-zu-Punkt-LSP an den jeweiligen PCE. Daher ist für PCE-initiierte LSPs kein lokal konfigurierter LSP auf dem PCC erforderlich.
Ein CLI-gesteuerter LSP, PCE-gesteuerter LSP und PCE-initiierter LSP können auf einem PCC koexistieren.
Bevor Sie beginnen:
Konfigurieren Sie die Geräteschnittstellen.
Konfigurieren Sie MPLS und RSVP-TE.
Konfigurieren Sie OSPF oder ein anderes IGP-Protokoll.
Führen Sie die folgenden Aufgaben aus, um PCE-initiierte Punkt-zu-Punkt-LSPs zu konfigurieren:
Beispielausgabe
[edit] user@PCC# edit protocols pcep [edit protocols pcep] user@PCC# set message-rate-limit 50 [edit protocols pcep] user@PCC# set max-provisioned-lsps 16000 [edit protocols pcep] user@PCC# edit pce PCE [edit protocols pcep pce PCE] user@PCC# set delegation-cleanup-timeout 20 [edit protocols pcep pce PCE] user@PCC# set destination-ipv4-address 192.168.69.58 [edit protocols pcep pce PCE] user@PCC# set destination-port 4189 [edit protocols pcep pce PCE] user@PCC# set lsp-cleanup-timer 50 [edit protocols pcep pce PCE] user@PCC# set lsp-provisioning [edit protocols pcep pce PCE] user@PCC# set max-unknown-messages 5 [edit protocols pcep pce PCE] user@PCC# set max-unknown-requests 5 [edit protocols pcep pce PCE] user@PCC# set request-timer 50 [edit protocols pcep pce PCE] user@PCC# up [edit protocols pcep] user@PCC# show message-rate-limit 50; max-provisioned-lsps 16000; pce PCE { destination-ipv4-address 192.168.69.58; destination-port 4189; lsp-provisioning; lsp-cleanup-timer 50; request-timer 50; max-unknown-requests 5; max-unknown-messages 5; delegation-cleanup-timeout 20; } [edit protocols pcep] user@PCC# commit commit complete
Beispiel: Konfigurieren des Path Computation Element Protocol für MPLS RSVP-TE mit Unterstützung für PCE-gesteuerte Point-to-Multipoint-LSPs
In diesem Beispiel wird gezeigt, wie Sie den Path Computation Client (PCC) mit der Möglichkeit konfigurieren, Point-to-Multipoint-Datenverkehr entwickelte Label-Switched Paths (TE LSPs) zu einem Path Computation Element (PCE) zu melden.
Anforderungen
In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:
Drei Router, die eine Kombination aus Routern der ACX-, M-, MX- oder T-Serie sein können.
Eine virtuelle Maschine mit Virtual Route Reflector (VRR)-Funktion konfiguriert.
Eine TCP-Verbindung zu einem externen Stateful PCE aus dem VRR.
Junos OS Version 16.1 oder höher, die auf dem PCC ausgeführt wird.
Bevor Sie beginnen:
Konfigurieren Sie die Geräteschnittstellen.
Konfigurieren Sie MPLS und RSVP-TE.
Konfigurieren Sie OSPF oder ein anderes IGP-Protokoll.
Überblick
Nachdem eine PCEP-Sitzung zwischen einem PCE und einem PCC eingerichtet wurde, meldet der PCC alle LSPs im System an die PCE für die LSP-Zustandssynchronisierung. Dazu gehören PCC-gesteuerte, PCE-delegierte und PCE-initiierte Point-to-Point-LSPs. Ab Junos OS Version 15.1F6 und 16.1R1 wird diese Funktion auch auf Point-to-Multipoint-LSPs erweitert.
Standardmäßig wird die PCE-Steuerung von Point-to-Multipoint-LSPs auf einem PCC nicht unterstützt. Um diese Funktion hinzuzufügen, fügen Sie die p2mp-lsp-report-capability
Anweisung auf der [edit protocols pcep pce pce-name]
Hierarchie- oder [edit protocols pcep pce-group group-id]
Hierarchieebene ein.
Topologie

In diesem Beispiel ist PCC der Eingangsrouter, Router R1 der Transitrouter und Router R2 der Ausgangsrouter. PCC ist mit einem Virtual Route Reflector (VRR) verbunden, der mit einem PCE verbunden ist. Es gibt viele Point-to-Multipoint-Schnittstellen zwischen PCC, Router R1 und Router R2.
Die Berichterstattung von Point-to-Multipoint-LSPs erfolgt wie folgt:
Wenn Router PCC mit Point-to-Point- und Point-to-Multipoint-LSPs ohne Unterstützung für Point-to-Multipoint-Berichtfunktion konfiguriert ist, werden nur die Punkt-zu-Punkt-LSPs an den angeschlossenen PCE gemeldet. Standardmäßig unterstützt ein PCC keine Point-to-Multipoint-LSP-Berichtfunktion.
Wenn Router PCC mit Point-to-Multipoint-LSP-Berichtfunktion konfiguriert ist, gibt PCC diese Funktion zuerst über eine Berichtsnachricht an PCE an.
Standardmäßig bietet ein PCE Unterstützung für Point-to-Multipoint-LSP-Funktionen. Nach Erhalt der Ankündigung des PCC für Point-to-Multipoint-LSP-Funktion, der PCE im Gegenzug seine Funktion gegenüber dem PCC.
Wenn PCE die Point-to-Multipoint-Funktion ansinnen hat, meldet PCC alle Zweigstellen von Point-to-Multipoint-LSPs an den PCE mithilfe der Update-Meldung.
Sobald alle LSPs an den PCE gemeldet sind, wird der LSP-Zustand zwischen PCE und PCC synchronisiert.
Konfiguration
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen sie in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, und kopieren Sie dann die Befehle und fügen sie auf Hierarchieebene in die [edit]
CLI ein.
PCC
set interfaces ge-0/0/0 unit 0 family inet address 1.2.4.1/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 1.2.3.1/30 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 1.2.2.1/30 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 family inet address 1.2.5.1/30 set interfaces ge-0/0/3 unit 0 family mpls set interfaces ge-0/0/4 unit 0 family inet address 1.4.0.1/30 set interfaces ge-0/0/4 unit 0 family mpls set interfaces ge-0/0/5 unit 0 family inet address 1.2.1.1/30 set interfaces ge-0/0/5 unit 0 family mpls set interfaces ge-0/0/6 unit 0 family inet address 1.2.0.1/30 set interfaces ge-0/0/6 unit 0 family mpls set routing-options autonomous-system 100 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls lsp-external-controller pccd pce-controlled-lsp pcc_delegated_no_cspf_* label-switched-path-template lsp_template_no_cspf set protocols mpls lsp-external-controller pccd pce-controlled-lsp pce_initiated_no_ero_no_cspf_* label-switched-path-template lsp_template_no_cspf set protocols mpls lsp-external-controller pccd pce-controlled-lsp pce_initiated_loose_ero_no_cspf_* label-switched-path-template lsp_template_no_cspf set protocols mpls traffic-engineering database import policy TE set protocols mpls admin-groups violet 1 set protocols mpls admin-groups indigo 2 set protocols mpls admin-groups blue 3 set protocols mpls admin-groups green 4 set protocols mpls admin-groups yellow 5 set protocols mpls admin-groups orange 6 set protocols mpls label-switched-path lsp_template_no_cspf template set protocols mpls label-switched-path lsp_template_no_cspf no-cspf set protocols mpls label-switched-path lsp1-pcc to 128.102.177.16 set protocols mpls label-switched-path lsp2-pcc to 128.102.177.16 set protocols mpls label-switched-path lsp2-pcc lsp-external-controller pccd set protocols mpls path loose-path 1.2.3.2 loose set protocols mpls path strict-path 1.2.3.2 strict set protocols mpls path strict-path 2.3.3.2 strict set protocols mpls path path-B set protocols mpls path path-C set protocols mpls interface all set protocols mpls interface ge-0/0/6.0 admin-group violet set protocols mpls interface ge-0/0/5.0 admin-group indigo set protocols mpls interface ge-0/0/2.0 admin-group blue set protocols mpls interface ge-0/0/1.0 admin-group green set protocols mpls interface ge-0/0/0.0 admin-group yellow set protocols mpls interface ge-0/0/3.0 admin-group orange set protocols mpls interface fxp0.0 disable set protocols bgp group northstar type internal set protocols bgp group northstar local-address 128.102.180.228 set protocols bgp group northstar family traffic-engineering unicast set protocols bgp group northstar export TE set protocols bgp group northstar neighbor 128.102.180.215 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/6.0 set protocols ospf area 0.0.0.0 interface ge-0/0/5.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 set protocols ospf area 0.0.0.0 interface ge-0/0/4.0 interface-type p2p set protocols pcep pce pce1 local-address 10.102.180.228 set protocols pcep pce pce1 destination-ipv4-address 10.102.180.246 set protocols pcep pce pce1 destination-port 4189 set protocols pcep pce pce1 pce-type active set protocols pcep pce pce1 pce-type stateful set protocols pcep pce pce1 lsp-provisioning set protocols pcep pce pce1 lsp-cleanup-timer 0 set protocols pcep pce pce1 delegation-cleanup-timeout 60 set protocols pcep pce pce1 p2mp-lsp-report-capability set policy-options policy-statement TE term 1 from family traffic-engineering set policy-options policy-statement TE term 1 then accept
R1
set interfaces ge-0/0/0 unit 0 family inet address 2.3.4.1/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 1.2.0.2/30 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 1.2.4.2/30 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 family inet address 1.2.2.2/30 set interfaces ge-0/0/3 unit 0 family mpls set interfaces ge-0/0/4 unit 0 family inet address 2.3.1.1/30 set interfaces ge-0/0/4 unit 0 family mpls set interfaces ge-0/0/5 unit 0 family inet address 1.2.3.2/30 set interfaces ge-0/0/5 unit 0 family mpls set interfaces ge-0/0/6 unit 0 family inet address 1.2.5.2/30 set interfaces ge-0/0/6 unit 0 family mpls set interfaces ge-0/0/7 unit 0 family inet address 1.2.1.2/30 set interfaces ge-0/0/7 unit 0 family mpls set interfaces ge-0/0/8 unit 0 family inet address 2.3.5.1/30 set interfaces ge-0/0/8 unit 0 family mpls set interfaces ge-0/0/9 unit 0 family inet address 2.3.2.1/30 set interfaces ge-0/0/9 unit 0 family mpls set interfaces ge-0/1/0 unit 0 family inet address 2.3.3.1/30 set interfaces ge-0/1/0 unit 0 family mpls set interfaces ge-0/1/1 unit 0 family inet address 2.3.0.1/30 set interfaces ge-0/1/1 unit 0 family mpls set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls admin-groups violet 1 set protocols mpls admin-groups indigo 2 set protocols mpls admin-groups blue 3 set protocols mpls admin-groups green 4 set protocols mpls admin-groups yellow 5 set protocols mpls admin-groups orange 6 set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols mpls interface ge-0/0/1.0 admin-group violet set protocols mpls interface ge-0/0/7.0 admin-group indigo set protocols mpls interface ge-0/0/3.0 admin-group blue set protocols mpls interface ge-0/0/5.0 admin-group green set protocols mpls interface ge-0/0/2.0 admin-group yellow set protocols mpls interface ge-0/0/6.0 admin-group orange set protocols mpls interface ge-0/1/1.0 admin-group violet set protocols mpls interface ge-0/0/4.0 admin-group indigo set protocols mpls interface ge-0/0/9.0 admin-group blue set protocols mpls interface ge-0/1/0.0 admin-group green set protocols mpls interface ge-0/0/0.0 admin-group yellow set protocols mpls interface ge-0/0/8.0 admin-group orange set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/7.0 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 set protocols ospf area 0.0.0.0 interface ge-0/0/5.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols ospf area 0.0.0.0 interface ge-0/0/6.0 set protocols ospf area 0.0.0.0 interface ge-0/1/1.0
R2
set interfaces ge-0/0/0 unit 0 family inet address 2.3.0.2/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 2.3.1.2/30 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 2.3.5.2/30 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 family inet address 2.3.4.2/30 set interfaces ge-0/0/3 unit 0 family mpls set interfaces ge-0/0/4 unit 0 family inet address 2.3.2.2/30 set interfaces ge-0/0/4 unit 0 family mpls set interfaces ge-0/0/5 unit 0 family inet address 2.3.3.2/30 set interfaces ge-0/0/5 unit 0 family mpls set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls admin-groups violet 1 set protocols mpls admin-groups indigo 2 set protocols mpls admin-groups blue 3 set protocols mpls admin-groups green 4 set protocols mpls admin-groups yellow 5 set protocols mpls admin-groups orange 6 set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols mpls interface ge-0/0/0.0 admin-group violet set protocols mpls interface ge-0/0/1.0 admin-group indigo set protocols mpls interface ge-0/0/4.0 admin-group blue set protocols mpls interface ge-0/0/5.0 admin-group green set protocols mpls interface ge-0/0/3.0 admin-group yellow set protocols mpls interface ge-0/0/2.0 admin-group orange set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/4.0 set protocols ospf area 0.0.0.0 interface ge-0/0/5.0 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive
R3
set interfaces em0 unit 0 family inet address 10.102.180.215/19 set interfaces em1 unit 0 family inet address 4.5.0.1/30 set interfaces em2 unit 0 family inet address 1.4.0.2/30 set interfaces em2 unit 0 family mpls set routing-options router-id 128.102.180.215 set routing-options autonomous-system 100 set protocols topology-export set protocols rsvp interface all set protocols mpls lsp-external-controller pccd set protocols mpls traffic-engineering database import igp-topology set protocols mpls traffic-engineering database import policy TE set protocols mpls interface all set protocols bgp group northstar type internal set protocols bgp group northstar local-address 128.102.180.215 set protocols bgp group northstar family traffic-engineering unicast set protocols bgp group northstar neighbor 128.102.180.228 set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface em2.0 interface-type p2p set policy-options policy-statement TE from family traffic-engineering set policy-options policy-statement TE then accept
Verfahren
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie auf verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus.
So konfigurieren Sie den PCC-Router:
Konfigurieren Sie die Schnittstellen von Router PCC. Um MPLS zu aktivieren, fügen Sie die Protokollfamilie in die Schnittstelle ein, damit die Schnittstelle eingehenden MPLS-Datenverkehr nicht verwirft.
[edit interfaces] user@PCC# set ge-0/0/0 unit 0 family inet address 1.2.4.1/30 user@PCC# set ge-0/0/0 unit 0 family mpls user@PCC# set ge-0/0/1 unit 0 family inet address 1.2.3.1/30 user@PCC# set ge-0/0/1 unit 0 family mpls user@PCC# set ge-0/0/2 unit 0 family inet address 1.2.2.1/30 user@PCC# set ge-0/0/2 unit 0 family mpls user@PCC# set ge-0/0/3 unit 0 family inet address 1.2.5.1/30 user@PCC# set ge-0/0/3 unit 0 family mpls user@PCC# set ge-0/0/4 unit 0 family inet address 1.4.0.1/30 user@PCC# set ge-0/0/4 unit 0 family mpls user@PCC# set ge-0/0/5 unit 0 family inet address 1.2.1.1/30 user@PCC# set ge-0/0/5 unit 0 family mpls user@PCC# set ge-0/0/6 unit 0 family inet address 1.2.0.1/30 user@PCC# set ge-0/0/6 unit 0 family mpls
Konfigurieren Sie die autonome Systemnummer für Router PCC.
[edit routing-options] user@PCC# set autonomous-system 100
Aktivieren Sie RSVP auf allen Schnittstellen von Router PCC, mit Ausnahme der Verwaltungsschnittstelle.
[edit protocols] user@PCC# set rsvp interface all user@PCC# set rsvp interface fxp0.0 disable
Aktivieren Sie MPLS auf allen Schnittstellen von Router PCC mit Ausnahme der Verwaltungsschnittstelle.
[edit protocols] user@PCC# set mpls interface all user@PCC# set mpls interface fxp0.0 disable
Konfigurieren Sie einen dynamischen LSP und deaktivieren Sie die automatische Pfadberechnung für den LSP.
[edit protocols] user@PCC# set mpls label-switched-path lsp_template_no_cspf template user@PCC# set mpls label-switched-path lsp_template_no_cspf no-cspf
Konfigurieren Sie Point-to-Multipoint-LSPs und definieren Sie externe Pfad-Computing-Entität für den LSP.
[edit protocols] user@PCC# set mpls label-switched-path lsp1-pcc to 128.102.177.16 user@PCC# set mpls label-switched-path lsp2-pcc to 128.102.177.16 user@PCC# set mpls label-switched-path lsp2-pcc lsp-external-controller pccd
Aktivieren Sie das externe Path Computing für die MPLS-LSPs und weisen Sie eine Vorlage für extern bereitgestellte LSPs zu.
[edit protocols] user@PCC# set mpls lsp-external-controller pccd pce-controlled-lsp pcc_delegated_no_cspf_* label-switched-path-template lsp_template_no_cspf user@PCC# set mpls lsp-external-controller pccd pce-controlled-lsp pce_initiated_no_ero_no_cspf_* label-switched-path-template lsp_template_no_cspf user@PCC# set mpls lsp-external-controller pccd pce-controlled-lsp pce_initiated_loose_ero_no_cspf_* label-switched-path-template lsp_template_no_cspf
Konfigurieren Sie die LSPs, die über lokale Kontrolle verfügen und von den PCE-bereitgestellten LSP-Parametern außer Kraft gesetzt werden.
[edit protocols] user@PCC# set mpls path loose-path 1.2.3.2 loose user@PCC# set mpls path strict-path 1.2.3.2 strict user@PCC# set mpls path strict-path 2.3.3.2 strict user@PCC# set mpls path path-B user@PCC# set mpls path path-C
Konfigurieren Sie MPLS-Gruppenrichtlinien für die LSP-Berechnung mit eingeschränktem Pfad.
[edit protocols] user@PCC# set mpls admin-groups violet 1 user@PCC# set mpls admin-groups indigo 2 user@PCC# set mpls admin-groups blue 3 user@PCC# set mpls admin-groups green 4 user@PCC# set mpls admin-groups yellow 5 user@PCC# set mpls admin-groups orange 6
Weisen Sie die konfigurierten administrativen Gruppenrichtlinien Router-PCC-Schnittstellen zu.
[edit protocols] user@PCC# set mpls interface ge-0/0/6.0 admin-group violet user@PCC# set mpls interface ge-0/0/5.0 admin-group indigo user@PCC# set mpls interface ge-0/0/2.0 admin-group blue user@PCC# set mpls interface ge-0/0/1.0 admin-group green user@PCC# set mpls interface ge-0/0/0.0 admin-group yellow user@PCC# set mpls interface ge-0/0/3.0 admin-group orange
Konfigurieren Sie eine Importrichtlinie für die Traffic Engineering-Datenbank (TED).
[edit protocols] user@PCC# set mpls traffic-engineering database import policy TE
Konfigurieren Sie eine interne BGP-Gruppe.
[edit protocols] user@PCC# set bgp group northstar type internal user@PCC# set bgp group northstar local-address 128.102.180.228 user@PCC# set bgp group northstar neighbor 128.102.180.215
Konfigurieren Sie traffic engineering für BGP und weisen Sie die Exportrichtlinie zu.
[edit protocols] user@PCC# set bgp group northstar family traffic-engineering unicast user@PCC# set bgp group northstar export TE
Konfigurieren Sie OSPF-Bereich 0 auf allen Point-to-Multipoint-Schnittstellen des Router PCC.
[edit protocols] user@PCC# set ospf area 0.0.0.0 interface lo0.0 user@PCC# set ospf area 0.0.0.0 interface ge-0/0/6.0 user@PCC# set ospf area 0.0.0.0 interface ge-0/0/5.0 user@PCC# set ospf area 0.0.0.0 interface ge-0/0/2.0 user@PCC# set ospf area 0.0.0.0 interface ge-0/0/1.0 user@PCC# set ospf area 0.0.0.0 interface ge-0/0/0.0 user@PCC# set ospf area 0.0.0.0 interface ge-0/0/3.0
Konfigurieren Sie OSPF-Bereich 0 auf der Point-to-Point-Schnittstelle des Router PCC.
[edit protocols] user@PCC# set ospf area 0.0.0.0 interface ge-0/0/4.0 interface-type p2p
Ermöglichen Sie Traffic-Engineering für OSPF.
[edit protocols] user@PCC# set ospf traffic-engineering
Definieren Sie den PCE, mit dem Router PCC verbunden ist, und konfigurieren Sie die PCE-Parameter.
[edit protocols] user@PCC# set pcep pce pce1 local-address 10.102.180.228 user@PCC# set pcep pce pce1 destination-ipv4-address 10.102.180.246 user@PCC# set pcep pce pce1 destination-port 4189 user@PCC# set pcep pce pce1 pce-type active user@PCC# set pcep pce pce1 pce-type stateful user@PCC# set pcep pce pce1 lsp-provisioning user@PCC# set pcep pce pce1 lsp-cleanup-timer 0 user@PCC# set pcep pce pce1 delegation-cleanup-timeout 60
Konfigurieren Sie Router-PCC, um Point-to-Multipoint-LSP-Funktionen für externes Pfad-Computing zu aktivieren.
[edit protocols] set pcep pce pce1 p2mp-lsp-report-capability
Konfigurieren Sie die Traffic-Engineering-Richtlinie.
[edit policy-options] user@PCC# set policy-statement TE term 1 from family traffic-engineering user@PCC# set policy-statement TE term 1 then accept
Ergebnisse
Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie die show interfaces
befehle eingeben show protocols
. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@PCC# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 1.2.4.1/30;
}
family mpls;
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 1.2.3.1/30;
}
family mpls;
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 1.2.2.1/30;
}
family mpls;
}
}
ge-0/0/3 {
unit 0 {
family inet {
address 1.2.5.1/30;
}
family mpls;
}
}
ge-0/0/4 {
unit 0 {
family inet {
address 1.4.0.1/30;
}
family mpls;
}
}
ge-0/0/5 {
unit 0 {
family inet {
address 1.2.1.1/30;
}
family mpls;
}
}
ge-0/0/6 {
unit 0 {
family inet {
address 1.2.0.1/30;
}
family mpls;
}
}
user@PCC# show protocols
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
lsp-external-controller pccd {
pce-controlled-lsp pcc_delegated_no_cspf_* {
label-switched-path-template {
lsp_template_no_cspf;
}
}
pce-controlled-lsp pce_initiated_no_ero_no_cspf_* {
label-switched-path-template {
lsp_template_no_cspf;
}
}
pce-controlled-lsp pce_initiated_loose_ero_no_cspf_* {
label-switched-path-template {
lsp_template_no_cspf;
}
}
}
traffic-engineering {
database {
import {
policy TE;
}
}
}
admin-groups {
violet 1;
indigo 2;
blue 3;
green 4;
yellow 5;
orange 6;
}
label-switched-path lsp_template_no_cspf {
template;
no-cspf;
}
label-switched-path lsp1-pcc {
to 128.102.177.16;
}
label-switched-path lsp2-pcc {
to 128.102.177.16;
lsp-external-controller pccd;
}
path loose-path {
1.2.3.2 loose;
}
path strict-path {
1.2.3.2 strict;
2.3.3.2 strict;
}
path path-B;
path path-C;
interface all;
interface ge-0/0/6.0 {
admin-group violet;
}
interface ge-0/0/5.0 {
admin-group indigo;
}
interface ge-0/0/2.0 {
admin-group blue;
}
interface ge-0/0/1.0 {
admin-group green;
}
interface ge-0/0/0.0 {
admin-group yellow;
}
interface ge-0/0/3.0 {
admin-group orange;
}
interface fxp0.0 {
disable;
}
}
bgp {
group northstar {
type internal;
local-address 128.102.180.228;
family traffic-engineering {
unicast;
}
export TE;
neighbor 128.102.180.215;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface lo0.0;
interface ge-0/0/6.0;
interface ge-0/0/5.0;
interface ge-0/0/2.0;
interface ge-0/0/1.0;
interface ge-0/0/0.0;
interface ge-0/0/3.0;
interface ge-0/0/4.0 {
interface-type p2p;
}
}
}
pcep {
pce pce1 {
local-address 10.102.180.228;
destination-ipv4-address 10.102.180.246;
destination-port 4189;
pce-type active stateful;
lsp-provisioning;
lsp-cleanup-timer 0;
delegation-cleanup-timeout 60;
p2mp-lsp-report-capability;
}
}
Überprüfung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
Überprüfung der LSP-Konfiguration auf dem PCC
Zweck
Überprüfen Sie den LSP-Typ und den Laufenden Zustand des Point-to-Multipoint-LSP.
Aktion
Führen Sie den Befehl im show mpls lsp extensive
Betriebsmodus aus.
user@PCC> show mpls lsp extensive Ingress LSP: 2 sessions 128.102.177.16 From: 128.102.180.228, State: Up, ActiveRoute: 0, LSPname: lsp1-pcc ActivePath: (primary) LSPtype: Static Configured, Penultimate hop popping LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 *Primary State: Up Priorities: 7 0 SmartOptimizeTimer: 180 Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 2) 1.2.1.2 S 2.3.0.2 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 1.2.1.2 2.3.0.2 6 Jul 12 14:44:10.620 Selected as active path 5 Jul 12 14:44:10.617 Record Route: 1.2.1.2 2.3.0.2 4 Jul 12 14:44:10.615 Up 3 Jul 12 14:44:10.175 Originate Call 2 Jul 12 14:44:10.174 CSPF: computation result accepted 1.2.1.2 2.3.0.2 1 Jul 12 14:43:41.442 CSPF failed: no route toward 128.102.177.16[2 times] Created: Tue Jul 12 14:42:43 2016 128.102.177.16 From: 128.102.180.228, State: Up, ActiveRoute: 0, LSPname: lsp2-pcc ActivePath: (primary) LSPtype: Externally controlled - static configured, Penultimate hop popping LSP Control Status: Externally controlled LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 *Primary State: Up Priorities: 7 0 External Path CSPF Status: external SmartOptimizeTimer: 180 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 1.2.4.2 2.3.0.2 50 Jul 12 14:50:14.699 EXTCTRL LSP: Sent Path computation request and LSP status 49 Jul 12 14:50:14.698 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 48 Jul 12 14:49:27.859 EXTCTRL LSP: Sent Path computation request and LSP status 47 Jul 12 14:49:27.859 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 46 Jul 12 14:49:27.858 EXTCTRL LSP: Sent Path computation request and LSP status 45 Jul 12 14:49:27.858 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 44 Jul 12 14:49:27.858 EXTCTRL_LSP: Control status became external 43 Jul 12 14:49:03.746 EXTCTRL_LSP: Control status became local 42 Jul 12 14:46:52.367 EXTCTRL LSP: Sent Path computation request and LSP status 41 Jul 12 14:46:52.367 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 40 Jul 12 14:46:52.367 EXTCTRL LSP: Sent Path computation request and LSP status 39 Jul 12 14:46:52.366 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 38 Jul 12 14:46:52.366 EXTCTRL_LSP: Control status became external 37 Jul 12 14:46:41.584 Selected as active path 36 Jul 12 14:46:41.565 Record Route: 1.2.4.2 2.3.0.2 35 Jul 12 14:46:41.565 Up 34 Jul 12 14:46:41.374 EXTCTRL_LSP: Applying local parameters with this signalling attempt 33 Jul 12 14:46:41.374 Originate Call 32 Jul 12 14:46:41.374 CSPF: computation result accepted 1.2.4.2 2.3.0.2 31 Jul 12 14:46:28.254 EXTCTRL_LSP: Control status became local 30 Jul 12 14:46:12.494 EXTCTRL LSP: Sent Path computation request and LSP status 29 Jul 12 14:46:12.494 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 28 Jul 12 14:45:43.164 EXTCTRL LSP: Sent Path computation request and LSP status 27 Jul 12 14:45:43.164 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 26 Jul 12 14:45:13.424 EXTCTRL LSP: Sent Path computation request and LSP status 25 Jul 12 14:45:13.423 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 24 Jul 12 14:44:44.774 EXTCTRL LSP: Sent Path computation request and LSP status 23 Jul 12 14:44:44.773 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 22 Jul 12 14:44:15.053 EXTCTRL LSP: Sent Path computation request and LSP status 21 Jul 12 14:44:15.053 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 20 Jul 12 14:43:45.705 EXTCTRL LSP: Sent Path computation request and LSP status 19 Jul 12 14:43:45.705 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 18 Jul 12 14:43:45.705 EXTCTRL LSP: Sent Path computation request and LSP status 17 Jul 12 14:43:45.705 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 16 Jul 12 14:43:45.705 EXTCTRL_LSP: Control status became external 15 Jul 12 14:43:42.398 CSPF failed: no route toward 128.102.177.16 14 Jul 12 14:43:13.009 EXTCTRL_LSP: Control status became local 13 Jul 12 14:43:13.009 EXTCTRL LSP: Sent Path computation request and LSP status 12 Jul 12 14:43:13.008 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 11 Jul 12 14:42:43.343 EXTCTRL LSP: Sent Path computation request and LSP status 10 Jul 12 14:42:43.343 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 9 Jul 12 14:42:43.343 EXTCTRL LSP: Sent Path computation request and LSP status 8 Jul 12 14:42:43.343 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 7 Jul 12 14:42:43.342 EXTCTRL LSP: Sent Path computation request and LSP status 6 Jul 12 14:42:43.342 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 5 Jul 12 14:42:43.341 EXTCTRL_LSP: Control status became external 4 Jul 12 14:42:43.337 EXTCTRL_LSP: Control status became local 3 Jul 12 14:42:43.323 EXTCTRL LSP: Sent Path computation request and LSP status 2 Jul 12 14:42:43.323 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 1 Jul 12 14:42:43.258 EXTCTRL LSP: Awaiting external controller connection Created: Tue Jul 12 14:42:43 2016 Total 2 displayed, Up 2, Down 0 Egress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0
Bedeutung
Der Ausgang zeigt den lsp2-pcc LSP als PCE-gesteuerten LSP an.
Überprüfung der PCE-Konfiguration auf dem PCC
Zweck
Überprüfen Sie die Konfiguration der PCE-Parameter und den PCE-Zustand.
Aktion
Führen Sie den Befehl im show path-computation-client active-pce
Betriebsmodus aus.
user@PCC> show path-computation-client active-pce PCE pce1 -------------------------------------------- General PCE IP address : 10.102.180.246 Local IP address : 10.102.180.228 Priority : 0 PCE status : PCE_STATE_UP Session type : PCE_TYPE_STATEFULACTIVE LSP provisioning allowed : On P2MP LSP report allowed : On P2MP LSP update allowed : Off P2MP LSP init allowed : Off PCE-mastership : main Counters PCReqs Total: 0 last 5min: 0 last hour: 0 PCReps Total: 0 last 5min: 0 last hour: 0 PCRpts Total: 12 last 5min: 0 last hour: 12 PCUpdates Total: 1 last 5min: 0 last hour: 1 PCCreates Total: 0 last 5min: 0 last hour: 0 Timers Local Keepalive timer: 30 [s] Dead timer: 120 [s] LSP cleanup timer: 0 [s] Remote Keepalive timer: 30 [s] Dead timer: 120 [s] LSP cleanup timer: 0 [s] Errors PCErr-recv PCErr-sent Type: 1 Value: 2 Count: 1 PCE-PCC-NTFS PCC-PCE-NTFS
Bedeutung
Die Ausgabe zeigt den aktiven PCE an, mit dem Router PCC verbunden ist, und die pce1 PCE-Parameter und den Status.
Grundlegendes zum Path Computation Element Protocol für MPLS RSVP-TE mit Unterstützung für PCE-initiierte Point-to-Multipoint-LSPs
Mit der Einführung von Point-to-Multipoint-PCE-initiierten LSPs kann ein PCE einen Point-to-Multipoint-LSP dynamisch initiieren und bereitstellen, ohne dass eine lokale LSP-Konfiguration auf dem PCC erforderlich ist. Auf diese Weise kann der PCE den Zeitpunkt und die Reihenfolge der Punkt-zu-Multipoint-Pfadberechnungen innerhalb und über Path Computation Element Protocol (PCEP)-Sitzungen steuern und so ein dynamisches Netzwerk schaffen, das zentral gesteuert und bereitgestellt wird.
- Vorteile von PCE-initiierten Point-to-Multipoint-LSPs
- Signalisierung von PCE-initiierten Point-to-Multipoint-LSPs
- Verhalten von PCE-initiierten Point-to-Multipoint-LSPs nach pcEP-Sitzungsfehlern
- Konfigurieren von PCE-initiierten Point-to-Multipoint-LSP-Funktionen
- Unterstützte und nicht unterstützte Funktionen für PCE-initiierte Point-to-Multipoint-LSPs
- Zuordnung von PCE-initiierten Point-to-Multipoint-LSPs zu MVPN
Vorteile von PCE-initiierten Point-to-Multipoint-LSPs
Erfüllt die Anforderungen der Point-to-Multipoint-Traffic-Engineering-LSP-Platzierung als Reaktion auf Anwendungsanforderungen durch dynamische Erstellung und Abschaltung von Point-to-Multipoint-LSPs, wodurch ein dynamisches Netzwerk entsteht, das zentral gesteuert und bereitgestellt wird.
Signalisierung von PCE-initiierten Point-to-Multipoint-LSPs
Die Signalisierung von PCE-initiierten Point-to-Multipoint-LSPs ist wie folgt:
-
When a new branch is added (Grafting)– Nur der neue Zweigstellen-Sub-LSP wird signalisiert und führt nicht zu einer erneuten Signalübertragung des gesamten Punkt-zu-Multipoint-Baumes.
Wenn vor der Bereitstellung des neuen Sub-LSP Änderungen in der Topologie aufgetreten sind, berechnet der Path Computation Server (PCS) die gesamte Point-to-Multipoint-Struktur neu und aktualisiert den Point-to-Multipoint-LSP mithilfe einer PC-Updatemeldung.
-
When a branch is deleted (Pruning)— Der gelöschte Zweigstellen-Sub-LSP wird heruntergerissen und führt nicht zu einer Erneutübertragung des gesamten Punkt-zu-Mehrpunkt-Baumes.
-
When a branch sub-LSP parameter is changed— Änderungen in Sub-LSP-Parametern, wie Explicit Route Object (ERO), Bandbreite oder Priorität, können entweder aufgrund der Optimierung oder auf Benutzeranfrage erfolgen. Wenn es eine Anfrage für eine Sub-LSP gibt, wird die gesamte Point-to-Multipoint-Struktur neu signalisiert, und der Switchover zur neuen Instanz erfolgt, sobald die neuen Instanzen aller Zweigstellen aktiviert sind.
-
When a branch sub-LSP path fails– Ein Fehler wird dem PCS für den ausgefallenen Zweigstellen-Sub-LSP gemeldet. Nach dem Erhalt des neuen ERO von den PCS wird die gesamte Point-to-Multipoint-Struktur zusammen mit dem ausgefallenen Zweigstellen-Sub-LSP erneut signalisiert, und der Switchover zur neuen Instanz erfolgt in einer Make-before-Break -Art (MBB).
Verhalten von PCE-initiierten Point-to-Multipoint-LSPs nach pcEP-Sitzungsfehlern
Wenn eine PCEP-Sitzung ausfällt, werden die von PCE initiierten Point-to-Multipoint-LSPs bis zum Ablauf des state timeout
Timers verwaist. Nach Ablauf des state timeout
Timers werden die PCE-initiierten LSPs bereinigt.
Um die Kontrolle über einen PCE-initiierten Point-to-Multipoint-LSP nach einem PCEP-Sitzungsfehler zu erhalten, sendet der primäre oder sekundäre PCE eine PCInitiate
Nachricht, bevor der state timeout
Timer abläuft.
Konfigurieren von PCE-initiierten Point-to-Multipoint-LSP-Funktionen
Standardmäßig wird die Erstellung und Bereitstellung von Point-to-Multipoint-LSPs durch einen PCE auf einem PCC nicht unterstützt. Um diese Funktion zu aktivieren, fügen Sie die p2mp-lsp-init-capability
Anweisungen und p2mp-lsp-update-capability
Anweisungen auf der [edit protocols pcep pce pce-name]
[edit protocols pcep pce-group group-id]
Oder Hierarchieebene ein.
Die p2mp-lsp-init-capability
Anweisung bietet die Möglichkeit, Point-to-Multipoint-RSVP-TE-LSPs von einem PCE bereitzustellen. Die p2mp-lsp-update-capability
Anweisung bietet die Möglichkeit, Point-to-Multipoint-RSVP-TE LSP-Parameter durch einen PCE zu aktualisieren.
Unterstützte und nicht unterstützte Funktionen für PCE-initiierte Point-to-Multipoint-LSPs
Die folgenden Funktionen werden von PCE-initiierten Point-to-Multipoint-LSPs unterstützt:
-
Teilweise Konformität mit dem Internet Draft-ietf-pce-stateful-pce-p2mp (läuft im Oktober 2018 ab), Path Computation Element (PCE) Protocol Extensions für Stateful PCE-Verwendung für Point-to-Multipoint Traffic Engineering Label Switched Paths.
- Ab Junos OS Version 21.1R1 unterstützen wir Nonstop Active Routing (NSR) für PCE-initiierte RSVP-basierte Point-to-Multipoint-LSPs. Nur die primäre Routing-Engine unterhält die PCEP-Sitzung mit dem Controller. Es synchronisiert alle RSVP-LSPs, die von PCEs initiiert wurden, einschließlich Multicast-Flow-Spezifikationen für alle PCE-initiierten P2MP-LSPs, mit der Backup-Routing-Engine. Während eines Switchovers stürzt die PCEP-Sitzung ab und stellt erneut fest, wenn die Backup-Routing-Engine zur primären Routing-Engine wird. Dies reduziert den Datenverkehrsverlust für den Datenverkehr, der über PCE-initiierte RSVP-LSPs während Routing-Engine-Switchovers übertragen wird. Diese Funktion wird aktiviert, wenn NSR konfiguriert ist.
Die folgenden Funktionen werden von PCE-initiierten Point-to-Multipoint-LSPs nicht unterstützt:
-
Delegierung von Point-to-Multipoint-LSP.
-
LSP-Kontrolldelegation.
-
Interior Gateway Protocol (IGP)-Erweiterung für die PCE-Erkennung innerhalb einer IGP-Routing-Domain.
-
Anfrage-/Antwort-Messaging.
-
Direkte Verlagerung von Zweigstellen-Sub-LSP von einem Punkt-zu-Multipoint-Tree zum anderen.
Das gleiche kann erreicht werden, indem ein Zweigstellen-Sub-LSP aus der ersten Punkt-zu-Multipoint-Struktur entfernt und erneut zu einer anderen hinzugefügt wird, nachdem die Meldung angibt, dass
PCReport
LSP vom Gerät entfernt wird. -
IPv6 wird nicht unterstützt.
-
SERO-basierte Signalübertragung wird nicht unterstützt.
-
Empty-ERO-Funktion wird nicht unterstützt.
-
Der Linkschutz wird nicht unterstützt.
Zuordnung von PCE-initiierten Point-to-Multipoint-LSPs zu MVPN
Sie können einen einzelnen oder einen Bereich von MVPN-Multicast-Flows (S,G) einem dynamisch erstellten PCE-initiierten Point-to-Multipoint-Label-Switched Path (LSP) zuordnen. Sie können nur selektive Arten von Datenströmen angeben, für die diese Funktion funktionieren soll. Die Themen umfassen:
-
Route Distinguisher (RD), der der MVPN-Routing-Instanz zugeordnet ist.
-
(S,G), die die Quelle eines Multicast-Pakets und einer Ziel-Multicast-Gruppenadresse ist. Dies wird verwendet, um eingehenden Datenverkehr zu filtern, um ihn dem Tunnel zuzuordnen.
-
Point-to-Multipoint-LSP, der verwendet wird, um Datenverkehr zu senden, der der oben genannten Datenstromspezifikation entspricht.
Weitere Informationen finden Sie im Internet Draft-ietf-pce-pcep-flowspec-05 (läuft ab 16. Februar 2020) PCEP Extension for Flow Specification.
In der aktuellen Implementierung dieser Funktion werden die folgenden Abschnitte des Entwurfs nicht implementiert:
-
Abschnitt 3.1.2 — Werbung für PCE-Kapazität in der IGP
-
Abschnitt 3.2 – PCReq- und PCRep-Meldung
-
Abschnitt 7 – Die meisten Datenstromspezifikationen, außer Route DistinguDie aktuelle Implementierung dieser Funktion wird nicht unterstützt, und IPv4-Multicast-Datenstromspezifikationen werden nicht unterstützt.
So ermöglichen Sie die Zuordnung von PCE-initiierten Point-to-Multipoint-LSPs zu MVPN:
-
Fügen Sie die
pce_traffic_steering
Anweisung auf der[edit protocols pcep pce pce-id]
Hierarchieebene ein, um die Unterstützung der Datenstromspezifikationsfunktion (auch Traffic Steering genannt) durch den PCC anzugeben. -
Fügen Sie die
external-controller
Anweisung auf Hierarchieebene[edit routing-instances routing-instance-name provider-tunnel]
ein.Das Vorhandensein in
external-controller
der Provider-Tunnel-Konfiguration für MVPN zeigt an, dass der Point-to-Multipoint-LSP und (S,G) für diese MVPN-Instanz vom externen Controller bereitgestellt werden können. Auf diese Weise kann der externe Controller dynamisch (S,G) und Point-to-Multipoint-LSP für MVPN konfigurieren.
Berücksichtigen Sie folgendes für die Zuordnung von PCE-initiierten Point-to-Multipoint-LSPs zu MVPN:
-
Wenn Sie die
external-controller pccd
Anweisung für eine bestimmte MVPN-Instanz nicht aktivieren, wird der PCCD-Prozess nicht dynamisch konfiguriert (S,G). -
Wenn Sie die Konfiguration über die
external-controller pccd
CLI deaktivieren, werden die dynamisch erlernten Multicast-Datenflüsse (S,G) für diese bestimmte MVPN-Instanz gelöscht und an den externen Controller gemeldet. -
Wenn (S,G) bereits über die CLI konfiguriert ist, kann das PCC nicht dynamisch (S,G) konfiguriert werden, da die lokale Konfiguration eine höhere Priorität hat.
-
Wenn ein bestimmtes (S,G) vom externen Controller dynamisch gelernt wird und Sie dann dasselbe (S,G) für dieselbe MVPN-Instanz konfigurieren, wird das dynamisch gelernte (S,G) gelöscht und dem externen Controller über den PCC gemeldet.
-
Wenn der Routingprotokollprozess neu gestartet wird, konfiguriert der PCCD-Prozess alle (S,G) erneut.
-
Wenn der PCCD-Prozess neu gestartet wird, meldet MVPN alle konfigurierten PCCD (S,G) an den externen Controller.
-
Wenn der Benutzer eine bestimmte MVPN-Instanz aktiviert
external-controller pccd
, fordert MVPN den PCCD-Prozess an, (S,G) zu konfigurieren, falls vorhanden. -
Wenn größere Konfigurationsänderungen an einer bestimmten MPVN-Instanz vorgenommen werden, fordert MVPN den PCCD-Prozess an, alle (S,G) für diese bestimmte MVPN-Instanz neu zu konfigurieren.
-
Alle Datenstromspezifikationen, die mit einem PCE-initiierten Point-to-Multipoint-LSP verknüpft sind, müssen den gleichen RD haben. Während der PC-Initiierung, wenn nicht alle Datenstromspezifikationen über dasselbe RD verfügen, wird die Pc-Initiierungsnachricht mit einem Fehler gelöscht.
-
Sie können einen Point-to-Multipoint-LSP nur mit selektiven Datenstromspezifikationen verknüpfen, andernfalls wird die Pc-Initiierungsnachricht mit einem Fehler gelöscht.
-
Wenn während der PC-Aktualisierung nicht alle Datenstromspezifikationen aufgrund einer neuen Datenstromspezifikation oder aufgrund einer aktualisierung der Datenstromspezifikationen nicht in allen Datenstromspezifikationen identisch sind, löst der PCC die Update-Meldung aus.
-
Wenn während der PC-Aktualisierung nicht alle Datenstromspezifikationen die selektive Bedingung erfüllen, entweder aufgrund des Hinzufügens einer neuen Datenstromspezifikation oder aufgrund einer Aktualisierung der Datenstromspezifikationen, setzt der PCC die Update-Meldung ab.
-
Das Verhalten für die Zuordnung von PCE-initiierten Point-to-Multipoint-LSP mit MVPN-Routing-Instanz und zuordnung von statischen (lokal konfigurierten) Point-to-Multipoint-LSP mit MVPN-Instanz ist auf Benutzerebene gleich.
-
Eine Datenstromspezifikations-ID kann nur einem Point-to-Multipoint-LSP zugeordnet werden. Um dieselbe RD und (S,G) mehreren Point-to-Multipoint-LSPs zu zuordnen, können Sie mehrere Datenstromspezifikationen mit verschiedenen IDs und derselben RD & (S,G) hinzufügen.
-
Für PCEP-mapped dynamic (S,G) ist der Schwellenwert immer der Standardwert von 0.
-
Es gibt keine Begrenzung für die Anzahl der Datenstromspezifikationen, die einem einzelnen PCE-initiierten Point-to-Multipoint-LSP zugeordnet sind.
-
Die aktuelle Implementierung dieser Funktion unterstützt nicht:
-
Berichterstellung von Weiterleitungsstatus, die dem Point-to-Multipoint-LSP zugeordnet sind.
-
Dynamische Konfiguration eines inklusiven Provider-Tunnels
-
Zuordnung für MVPN-Replikationstunnel
-
Programmierbarer Routing-Protokollprozess (prpd)
-
Berichterstellung von Point-to-Multipoint-LSP mit CLI-Konfiguration, der auf MVPN-Multicast-Datenströme (S,G) abgebildet ist.
-
Siehe auch
Aktivieren von Segment-Routing für das Path Computation Element Protocol
SUMMARY Sie können Segment-Routing oder Source Packet Routing in Networking (SPRING) Traffic-Engineering (SR-TE) mit dem Path Computation Element Protocol (PCEP) zur Traffic Steering aktivieren. Mit dieser Unterstützung werden die Vorteile des Segment-Routing auf die Label-Switched Paths (LSPs) erweitert, die extern durch ein Path Computation Element (PCE) gesteuert werden.
- Segment-Routing für die Path Computation Element Protocol – Übersicht
- Beispiel: Konfigurieren des Segment-Routing für das Path Computation Element Protocol
Segment-Routing für die Path Computation Element Protocol – Übersicht
- Vorteile von Segment-Routing für PCEP
- Segment-Routing für Traffic Engineering
- Junos OS Implementierung von Segment-Routing für PCEP
- Segment-Routing für PCEP-Einschränkungen und nicht unterstützte Funktionen
Vorteile von Segment-Routing für PCEP
Die Einrichtung von LSPs über einen externen Controller bietet einen globalen Überblick über den Bandbreitenbedarf pro LSP und Pro Gerät im Netzwerk und ermöglicht eine einschränkungsbasierte Pfadberechnung in Online- und Echtzeit.
Die Vorteile des Segment-Routings werden auf die LSPs ausgeweitet, die von einem externen Controller, auch Path Computation Element (PCE genannt), initiiert werden, um die Vorteile des externen Path Computing in einem MPLS-Netzwerk zu erweitern.
Ein Path Computation Client (PCC, ein eingehender Router der MX-Serie) mit Delegierungsfunktion kann die Kontrolle über die delegierten Segment-Routing-LSPs vom PCE zurückerlegen, wenn die PCEP-Sitzung ausfällt. andernfalls würden die LSPs aus dem PCC gelöscht. So können Sie den Schutz von LSP-Daten gewährleisten, indem Sie eine Situation verhindern, in der Pakete unbemerkt verworfen oder gelöscht werden (auch bekannt als Null-Route-Bedingung).
Segment-Routing für Traffic Engineering
Segment-Routing kann über eine IPv4- oder IPv6-Datenebene betrieben werden und unterstützt Multipath zu gleichen Kosten (ECMP). Mit den integrierten IGP-Erweiterungen lässt sich das Segment-Routing in die umfangreichen Multiservice-Funktionen von MPLS integrieren, einschließlich Layer 3 VPN, Virtual Private Wire Service (VPWS), Virtual Private LAN Service (VPLS) und Ethernet VPN (EVPN).
Zu den übergeordneten Komponenten der SR-Te-Lösung (Segment Routing-Traffic Engineering) gehören:
Verwendung einer IGP für Werbe-Link-Merkmale. Diese Funktionalität ist ähnlich wie RSVP-TE.
Verwendung von Constrained Shortest Path First (CSPF) auf dem Eingangsgerät oder PCE.
Verwendung einer IGP für Werbeetiketten für Links.
In SR-TE-Funktionen:
Das Eingangsgerät erstellt einen LSP, indem es die Label der Verbindungen stapelt, die es passieren möchte.
Die IGP-Ankündigung per Link wird mit Label-Stacking kombiniert, um Source-Routing-LSPs auf dem Eingangsgerät zu erstellen, sodass die Transitgeräte die End-to-End-LSPs nicht kennen.
LSPs werden zwischen Edge-Knoten erstellt, ohne auf die Transitgeräte pro LSP Speicheranforderungen zu stellen. (Die Erstellung solcher LSPs ist aktiviert, da es in SR-TE keine Signalübertragung pro LSP gibt.)
Die Label pro Nachbarn werden gestapelt, was zur Verwaltung einer großen Anzahl von Labeln führt, was zu einer Skalierung der Steuerungsebene führt.
Junos OS Implementierung von Segment-Routing für PCEP
Junos OS implementiert Segment-Routing für PCEP für zwei Arten von LSPs: PCE-initiierte LSPs und PCE-delegierte LSPs.
PCE-initiierte Segment-Routing-LSPs
Die VON PCE initiierten Segment-Routing-LSPs sind die LSPs, die der PCE für die Adjacency- und Node-Segmente erstellt.
Der PCE führt die folgenden Funktionen aus:
Berechnet den Pfad des Segment-Routing-LSP.
Stellt den LSP auf dem Path Computation Client (PCC) unter Verwendung von PCEP-Segment-Routing-Erweiterungen bereit.
Analysiert die PCEP-Segment-Routing-Erweiterungen.
Erstellt eine Tunnelroute auf dem PCC, die ihren eigenen Präferenzwert hat und in der Routingtabelle inet.3 zur Verfügung gestellt wird, um IP-Datenverkehr und -Services wie jede andere Tunnelroute aufzulösen.
Das PCC führt folgende Funktionen aus:
Wählt die ausgehende Schnittstelle basierend auf dem ersten Network Access Identifier (NAI) im Source Explicit Route Object (S-ERO) aus.
Junos OS unterstützt S-EROs, die den ersten Hop als strikten Hop enthalten; Junos OS unterstützt die Auswahl der ausgehenden Schnittstelle auf dem PCC basierend auf einem Lose-Hop Node Segment ID (SID). Die restlichen Hops können jedoch lose sein. Für die S-EROs, die über den ersten Hop hinausgehen, wird keine spezifische Verarbeitung durchgeführt, außer das Label einfach für die Erstellung des nächsten Hops zu verwenden.
Lehnt den S-ERO ab, wenn:
Der S-ERO hat keine Label darin.
Der S-ERO enthält mehr als sechs Hops.
Der PCC erstellt eine Multipath-Route zu gleichen Kosten (ECMP), wenn mehrere LSPs zum gleichen Ziel mit derselben Metrik kommen.
Wartet darauf, dass der PCE alle Ereignisse verarbeitet, die nach der Bereitstellung zu einer Änderung des Segment-Routing-LSP führen, z. B. wenn das Label geändert oder zurückgezogen wird oder wenn eine der schnittstellen, die vom LSP durchlaufen werden, ausfällt.
Wenn die PCEP-Sitzung ausfällt, wird der vom PCE initiierte Segment-Routing-LSP:
Bleibt 300 Sekunden betriebsbereit.
Wird nach 300 Sekunden aus dem PCC gelöscht.
Weitere Informationen finden Sie unter Internet draft-ietf-pce-lsp-setup-type-03.txt (läuft ab 25. Dezember 2015), Übermittlung des Pfadeinrichtungstyps in PCEP-Nachrichten; und draft-ietf-pce-segment-routing-06.txt (ab 10. Februar 2016), PCEP-Erweiterungen für Segment-Routing.
PCE-delegierte Segment-Routing-LSPs
Die PCE-delegierten Segment-Routing-LSPs sind die LSPs, die vom PCC lokal konfiguriert und dann an einen PCE-Controller delegiert werden.
Junos OS Version 20.1R1 unterstützt:
PCE-Delegierungsfunktion nur für nichtfarbige Segment-Routing-LSPs mit IPv4-Zielen.
Delegierung und Berichterstellung nur des ersten Segments einer Segmentliste an einen externen Controller. Mehrere Segmente werden für die PCE-Delegierung nicht unterstützt.
Der PCC kann einen Segment-Routing-LSP auf folgende Weise an einen externen Controller (den PCE) delegieren:
Initial delegation— Die lokalen LSPs müssen noch auf dem PCC konfiguriert werden, und die Delegierung des LSP erfolgt zu dem Zeitpunkt, zu dem der LSP konfiguriert wird.
Delegation of existing LSP— Die lokalen LSPs werden auf dem PCC konfiguriert, und die Delegierung des LSP erfolgt, nachdem der Quell-Routing-Pfad konfiguriert wurde. Das heißt, die Delegierungsfunktion ist auf bestehenden Segment-Routing-LSPs aktiviert.
Nach dem Delegieren eines Segment-Routing-LSP steuert der PCE die delegierten LSPs und kann die LSP-Attribute für die Pfadberechnung ändern. Die LSP-Steuerung wird auf das PCC zurückgesetzt, wenn die PCEP-Sitzung zwischen dem PCC und dem PCE ausfällt. Die PCE-delegierten LSPs haben einen Vorteil gegenüber PCE-initiierten LSPs, wenn die PCEP-Sitzung ausfällt. Im Fall von PCE-initiierten LSPs werden die LSPs aus dem PCC gelöscht, wenn die PCEP-Sitzung ausfällt. Im Fall von PCE-delegierten LSPs übernimmt das PCC jedoch, wenn die PCEP-Sitzung ausfällt, die Kontrolle über die delegierten LSPs aus dem PCE zurück. Infolgedessen verhindern wir mit PCE-delegierten LSPs eine Situation, in der Pakete unbemerkt verworfen werden (auch als Null-Route-Bedingung bezeichnet), wenn die Sitzung ausfällt.
Die folgenden Arten von Segment-Routing-LSPs unterstützen die PCE-Delegierungsfunktion:
Static LSPs— Statisch konfigurierte Quell-Routing-Pfade, die den gesamten Labelstack statisch konfiguriert haben.
Auto-translated LSPs— Statisch konfigurierte Quell-Routing-Pfade, die automatisch übersetzt werden.
Computed LSPs— Statisch konfigurierte Quell-Routing-Pfade, die mit distributed Constrained Shortest Path First (CSPF) berechnet werden.
Dynamic LSPs— Dynamisch erstellte Tunnel, die durch das dynamische Tunnelmodul ausgelöst werden und eine Last-Hop-ERO-Auflösung haben.
Abhängig von der Quelle des Segment-Routing-LSP können Sie die Delegierungsfunktion auf dem PCC konfigurieren. Um die Delegierung von Segment-Routing-LSPs zu ermöglichen, fügen Sie die lsp-external-controller pccd
Anweisung auf der entsprechenden Ebene unter der Hierarchie ein [edit protocols source-packet-routing]
.
Tabelle 2 zeigt eine Zuordnung der LSP-Quelle zur entsprechenden Konfigurationshierarchieebene, auf der die Delegierungsfunktion aktiviert ist.
Sie müssen die lsp-external-controller pccd
Anweisung auf der [edit protocols source-packet-routing]
Hierarchie- und [edit protocols mpls]
Hierarchieebene einschließen, bevor Sie die Delegierungsfunktion auf dem PCC konfigurieren.
Quelle für Segment-Routing-LSP |
Konfigurationshierarchie |
---|---|
|
Liste der primären Segmente bei |
Computed LSPs (distributed CSPF) |
Liste des primären Segments des Source-Routing-Pfads unter:
|
Dynamische LSPs |
Primary Segment List der Source-Routing-Pfadvorlage unter:
|
Sie können den Steuerungsstatus der SR-TE-LSPs aus der Befehlsausgabe "Show Spring-Traffic-Engineering" anzeigen.
Tabelle 3 zeigt die PCEP-Interaktion an, wenn die lsp-external-controller
Anweisung für einen Quell-Routing-Pfad konfiguriert ist.
Konfigurationshierarchie für lsp-externer Controller |
Quell-Routing-Pfad Delegierungsstatus |
PCEP-Interaktion zwischen PCC und PCE |
---|---|---|
Liste des primären Segments des Quell-Routing-Pfads |
Erste Delegierung |
Das gleiche Verhalten wird beobachtet, wenn der Routing-Protokollprozess (rpd) neu gestartet wird oder ein Switchover der Routing-Engine stattfindet. |
Liste des primären Segments des Quell-Routing-Pfads |
Delegierung vorhandener Pfade |
|
Primäres Segment des Source-Routing-Pfads |
Die Delegierung ist nicht konfiguriert oder wurde gelöscht. |
Die Segmentliste aus dem PCE (sofern vorhanden) wird nicht mehr verwendet, und das Berechnungsergebnis aus der lokalen Konfiguration wird verwendet. Wenn das lokale Ergebnis für die Segmentliste verfügbar ist, wird die entsprechende Segmentliste verwendet, um die Route nach dem Make-before-Break-Prinzip zu programmieren. |
Segmentliste des Quell-Routing-Pfads |
Die Delegierung ist aktiviert, nachdem LSP konfiguriert wurde. |
Die Delegierungsfunktionen werden für die primäre Segmentliste unter dem Quell-Routing-Pfad ausgelöst. |
Segmentliste des Quell-Routing-Pfads |
Die Delegierung ist nicht konfiguriert oder wurde gelöscht. |
Die Delegierungsfunktionen werden aus der primären Segmentliste unter dem Quell-Routing-Pfad entfernt. |
Primäre Segmentliste der Quell-Routing-Pfadvorlage |
Die Delegierung ist aktiviert, nachdem LSP konfiguriert wurde. |
|
Primäre Segmentliste der Quell-Routing-Pfadvorlage |
Die Delegierung ist nicht konfiguriert oder wurde gelöscht. |
Die Delegierungsfunktionen werden von allen Quell-Routing-Pfaden und primären Pfaden entfernt, die der Vorlagenkonfiguration entsprechen. |
Segment-Routing für PCEP-Einschränkungen und nicht unterstützte Funktionen
Die Unterstützung von Segment-Routing für PCEP trägt nicht zur Leistungsbelastung des Systems bei. Es hat jedoch die folgenden Einschränkungen:
Ein SR-TE LSP ist auf dem PCC nicht lokal geschützt. Wenn der LSP mehr als sechs Hops hat, wird auf dem LSP außer der Übertragung von einfachem IP-Datenverkehr kein Service auf dem LSP bereitgestellt.
Graceful Routing Engine Switchover (GRES) und Unified In-Service Software Upgrade (Unified ISSU) werden nicht unterstützt.
Nonstop Active Routing (NSR) wird nicht unterstützt.
IPv6 wird nicht unterstützt.
PCE-delegierte LSPs unterstützen Folgendes nicht:
Farbige SR-TE-LSPs
IPv6-LSPs
Sekundäre Segmentliste des Source-Routing-Pfads. Es kann nur ein Pfad der Segmentliste delegiert werden.
Multisegment-Standard. Nur das erste Segment der Segmentliste wird delegiert und an den Controller gemeldet.
Beispiel: Konfigurieren des Segment-Routing für das Path Computation Element Protocol
Dieses Beispiel zeigt, wie Sie Segment-Routing oder SPRING Traffic-Engineering (SOURCE Packet Routing in Networking) (SR-TE) für das Path Computation Element Protocol (PCEP) konfigurieren. In der Konfiguration nutzen wir die Vorteile des Segment-Routing mit den Vorteilen des externen Path Computing für ein effizientes Traffic-Engineering.
Anforderungen
In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:
Vier universelle 5G-Routing-Plattformen der MX-Serie, bei denen der eingehende Router der Path Computation Client (PCC) ist.
Eine TCP-Verbindung vom PCC zu einem externen Stateful Path Computation Element (PCE).
Junos OS Version 17.2 oder höher, die auf dem PCC zur Implementierung von PCE-initiierten LSPs ausgeführt wird.
Für PCE-Delegierungsfunktionen müssen Sie Junos OS Version 20.1R1 oder höher ausführen.
Bevor Sie beginnen:
Konfigurieren Sie die Geräteschnittstellen.
Konfigurieren Sie MPLS.
Konfigurieren Sie IS-IS.
Überblick
Die Junos OS-Implementierung des Segment-Routing für PCEP umfasst PCE-initiierte und PCE-delegierte SR-TE-LSPs.
Die Implementierung von PCE-initiierten LSPs wird in Junos OS Version 17.2R1 eingeführt, wo die Traffic-Engineering-Funktionen des Segment-Routing in PCEP-Sitzungen für LSPs unterstützt werden, die von einem PCE initiiert werden. Der PCE erstellt die LSPs für die Adjacency- und Node-Segmente. Tunnelrouten werden in der Routing-Tabelle inet.3 des PCC erstellt, die den PCE-initiierten SR-TE-LSPs entspricht.
Die Implementierung von PCE-delegierten LSPs wird in Junos OS Version 20.1R1 eingeführt, wo die lokal konfigurierten nicht farbigen IPv4-Segment-Routing-LSPs auf dem PCC an einen PCE-Controller delegiert werden können. Der PCE steuert dann den LSP und kann LSP-Attribute für die Pfadberechnung ändern.
Die PCE-delegierten LSPs haben einen Vorteil gegenüber PCE-initiierten LSPs, wenn die PCEP-Sitzung ausfällt. Im Fall von PCE-initiierten LSPs werden die LSPs aus dem PCC gelöscht, wenn die PCEP-Sitzung ausfällt. Im Fall von PCE-delegierten LSPs übernimmt das PCC jedoch, wenn die PCEP-Sitzung ausfällt, die Kontrolle über die delegierten LSPs aus dem PCE zurück. Infolgedessen verhindern wir mit PCE-delegierten LSPs eine Situation, in der Pakete unbemerkt verworfen werden (auch als Null-Route-Bedingung bezeichnet), wenn die PCEP-Sitzung ausfällt.
So aktivieren Sie Das Segment-Routing für PCEP:
Für PCE-initiierte Segment-Routing-LSPs:
Ermöglichen Sie das externe Path Computing für MPLS, indem Sie die
lsp-external-controller
Anweisung auf Hierarchieebene[edit protocols mpls]
angeben.Diese Konfiguration ist auch für PCEP mit RSVP-TE-Erweiterungen erforderlich. Sie können PCEP mit RSVP-TE nicht deaktivieren, wenn das Segment-Routing für PCEP aktiviert ist.
Ermöglichen Sie das externe Path Computing für SR-TE, indem Sie die
lsp-external-controller pccd
Anweisung auf Hierarchieebene[edit protocols spring-traffic-engineering]
einberechnen.Aktivieren Sie das Segment-Routing für PCE, indem Sie die
spring-capability
Anweisung auf Hierarchieebene[edit protocols pcep pce pce-name]
einbesteigen.Konfigurieren Sie optional die maximale SID-Tiefe für den PCE, indem Sie die
max-sid-depth number
Anweisung auf Hierarchieebene[edit protocols pcep pce pce-name]
angeben.Die maximale SID-Tiefe ist die Anzahl der SIDs, die von einem Knoten oder einem Link auf einem Knoten unterstützt werden. Wenn nicht konfiguriert, wird ein standardmäßiger maximaler SID-Wert von 5 angewendet.
Konfigurieren Sie optional den Voreinstellungswert für Segment-Routing, indem Sie den
preference preference-value
Wert auf[edit protocol spring-te]
Hierarchieebene einbesteigen.Der Voreinstellungswert gibt die Reihenfolge an, in der ein Pfad als aktives Pfadformular unter den Kandidatenpfaden ausgewählt wird, wobei ein höherer Wert eine höhere Präferenz hat. Wenn die Konfiguration nicht konfiguriert ist, wird der Standardeinstellungswert 8 angewendet.
Konfigurieren Sie optional die Segment-Routing-Protokollierung für die Fehlerbehebung, indem Sie die
traceoptions
Anweisung auf Hierarchieebene[edit protocols spring-te]
angeben.
Führen Sie für die PCE-Delegierung von Segment-Routing-LSPs zusätzlich zu den oben genannten Schritten Folgendes aus:
Definieren Sie eine Segmentliste mit Label-Parametern. Dadurch entsteht ein Segment-Routing-LSP lokal auf dem PCC.
Aktivieren Sie die Delegierungsfunktion des lokal konfigurierten LSP auf dem PCC, indem Sie die
lsp-external-controller pccd
Anweisung in eine der folgenden Hierarchien aufnehmen, abhängig von der LSP-Quelle des Segment-Routing:Für statisch konfigurierte Quell-Routing-Pfade, die mit verteilten CSPF -
[edit protocols source-packet-routing source-routing-path lsp-name primary path-name compute profile-name]
und[edit protocols source-packet-routing source-routing-path lsp-name primary path-name]
Hierarchieebenen berechnet werden.Für statisch konfigurierte Quell-Routing-Pfade, bei denen der gesamte Labelstack statisch konfiguriert ist, und Quell-Routing-Pfade, die automatisch übersetzt werden –
[edit protocols source-packet-routing source-routing-path lsp-name primary path-name]
Hierarchieebene.Für dynamisch erstellte Tunnel, die über das Dynamic Tunnel Module ausgelöst werden und die last-Hop-ERO-Auflösung –
[edit protocols source-packet-routing source-routing-path-template template-name primary primary-segment-list-name]
und[edit protocols source-packet-routing source-routing-path-template template-name]
Hierarchieebenen haben.
Topologie
Abbildung 8 veranschaulicht eine Beispiel-Netzwerktopologie, in der eine PCEP-Sitzung zwischen dem PCE und dem PCC (eingehender Router der MX-Serie) ausgeführt wird. Die Router R1, R2 und R3 sind die anderen Router der MX-Serie im Netzwerk. In diesem Beispiel konfigurieren wir das Segment-Routing für PCEP auf dem PCC. Außerdem konfigurieren wir eine statische Route auf dem PCC zum Router R3, um die Verwendung von SR-TE-Tunnelrouten beim Routing des Datenverkehrs für die statische Route zu überprüfen.

Konfiguration
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen sie in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, kopieren Sie die Befehle, fügen Sie sie auf Hierarchieebene in die [edit]
CLI ein, und geben Sie dann aus dem Konfigurationsmodus ein commit
.
Obwohl wir in diesem Abschnitt die Konfiguration aller Geräte (PCC und die drei Router) vorstellen, dokumentiert das Schritt-für-Schritt-Verfahren nur die Konfiguration des PCC.
PCC
set interfaces ge-0/0/5 unit 0 family inet address 10.100.41.1/24 set interfaces ge-0/0/5 unit 0 family iso set interfaces ge-0/0/5 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.100.4/32 primary set interfaces lo0 unit 0 family iso address 49.0011.0110.0000.0101.00 set interfaces lo0 unit 0 family mpls set routing-options static route 100.1.1.1/32 next-hop 192.168.100.3 set routing-options router-id 192.168.100.4 set routing-options autonomous-system 64496 set protocols rsvp interface fxp0.0 disable set protocols rsvp interface all set protocols mpls lsp-external-controller pccd set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols isis source-packet-routing srgb start-label 800000 set protocols isis source-packet-routing srgb index-range 4000 set protocols isis source-packet-routing node-segment ipv4-index 101 set protocols isis source-packet-routing node-segment ipv6-index 11 set protocols isis level 1 disable set protocols isis level 2 wide-metrics-only set protocols isis interface all point-to-point set protocols isis interface all level 2 metric 10 set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0 passive set protocols source-packet-routing segment-list static_seg_list_1 hop1 label 800102 set protocols source-packet-routing segment-list static_seg_list_1 hop2 label 800103 set protocols source-packet-routing source-routing-path static_srte_lsp_1 to 192.168.100.3 set protocols source-packet-routing source-routing-path static_srte_lsp_1 primary static_seg_list_1 lsp-external-controller pccd set protocols spring-traffic-engineering lsp-external-controller pccd set protocols source-packet-routing source-routing-path static1 lsp-external-controller pccd set protocols pcep pce pce1 local-address 192.168.100.4 set protocols pcep pce pce1 destination-ipv4-address 10.102.180.232 set protocols pcep pce pce1 destination-port 4189 set protocols pcep pce pce1 pce-type active set protocols pcep pce pce1 pce-type stateful set protocols pcep pce pce1 lsp-provisioning set protocols pcep pce pce1 spring-capability
Router R1
set interfaces ge-0/0/5 unit 0 family inet address 10.100.41.2/24 set interfaces ge-0/0/5 unit 0 family iso set interfaces ge-0/0/5 unit 0 family mpls set interfaces ge-0/1/2 unit 0 family inet address 10.100.12.1/24 set interfaces ge-0/1/2 unit 0 family iso set interfaces ge-0/1/2 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.100.1/32 primary set interfaces lo0 unit 0 family iso address 49.0011.0110.0000.0102.00 set interfaces lo0 unit 0 family mpls set routing-options router-id 192.168.100.1 set routing-options autonomous-system 64496 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols isis source-packet-routing srgb start-label 800000 set protocols isis source-packet-routing srgb index-range 4000 set protocols isis source-packet-routing node-segment ipv4-index 102 set protocols isis level 1 disable set protocols isis level 2 wide-metrics-only set protocols isis interface all point-to-point set protocols isis interface all level 2 metric 10 set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0 passive
Router R2
set interfaces ge-0/1/2 unit 0 family inet address 10.100.12.2/24 set interfaces ge-0/1/2 unit 0 family iso set interfaces ge-0/1/2 unit 0 family mpls set interfaces ge-0/1/8 unit 0 family inet address 10.100.23.1/24 set interfaces ge-0/1/8 unit 0 family iso set interfaces ge-0/1/8 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.100.2/32 set interfaces lo0 unit 0 family iso address 49.0011.0110.0000.0105.00 set interfaces lo0 unit 0 family mpls set routing-options router-id 192.168.100.2 set routing-options autonomous-system 64496 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols isis source-packet-routing srgb start-label 800000 set protocols isis source-packet-routing srgb index-range 4000 set protocols isis source-packet-routing node-segment ipv4-index 105 set protocols isis level 1 disable set protocols isis level 2 wide-metrics-only set protocols isis interface all point-to-point set protocols isis interface all level 2 metric 10 set protocols isis interface all level 1 disable set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0 passive
Router R3
set interfaces ge-0/1/8 unit 0 family inet address 10.100.23.2/24 set interfaces ge-0/1/8 unit 0 family iso set interfaces ge-0/1/8 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.100.3/32 primary set interfaces lo0 unit 0 family iso address 49.0011.0110.0000.0103.00 set interfaces lo0 unit 0 family mpls set routing-options static route 100.1.1.1/32 receive set routing-options router-id 192.168.100.3 set routing-options autonomous-system 64496 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols isis source-packet-routing srgb start-label 800000 set protocols isis source-packet-routing srgb index-range 4000 set protocols isis source-packet-routing node-segment ipv4-index 103 set protocols isis level 1 disable set protocols isis level 2 wide-metrics-only set protocols isis interface all point-to-point set protocols isis interface all level 2 metric 10 set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0 passive
Verfahren
Schritt-für-Schritt-Verfahren
In diesem Beispiel konfigurieren wir nur den PCC.
Für die folgenden Schritte müssen Sie auf verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI-Benutzerhandbuch.
So konfigurieren Sie das PCC:
Konfigurieren Sie die Schnittstellen des PCC.
[edit interfaces] user@PCC# set ge-0/0/5 unit 0 family inet address 10.100.41.1/24 user@PCC# set ge-0/0/5 unit 0 family iso user@PCC# set ge-0/0/5 unit 0 family mpls user@PCC# set lo0 unit 0 family inet address 192.168.100.4/32 primary user@PCC# set lo0 unit 0 family iso address 49.0011.0110.0000.0101.00 user@PCC# set lo0 unit 0 family mpls
Konfigurieren Sie die Router-ID und weisen Sie dem PCC eine autonome Systemnummer zu.
[edit routing-options] user@PCC# set router-id 192.168.100.4 user@PCC# set autonomous-system 64496
Konfigurieren Sie eine statische Route vom PCC zum Router R3.
Die statische Route wird nur zu Verifizierungszwecken erstellt und wirkt sich nicht auf die Funktionsfunktionalität aus.
[edit routing-options] user@PCC# set static route 100.1.1.1/32 next-hop 192.168.100.3
Konfigurieren Sie RSVP auf allen Schnittstellen des PCC mit Ausnahme der Verwaltungsschnittstelle.
[edit protocols] user@PCC# set rsvp interface fxp0.0 disable user@PCC# set rsvp interface all
Konfigurieren Sie MPLS auf allen Schnittstellen des PCC mit Ausnahme der Verwaltungsschnittstelle.
[edit protocols] user@PCC# set mpls interface all user@PCC# set mpls interface fxp0.0 disable
Aktivieren Sie externe Path Computing-Funktionen für MPLS.
[edit protocols] user@PCC# set mpls lsp-external-controller pccd
Konfigurieren Sie IS-IS-Ebene 2 auf allen Schnittstellen des PCC, mit Ausnahme der Verwaltungs- und Loopback-Schnittstellen.
[edit protocols] user@PCC# set isis level 1 disable user@PCC# set isis level 2 wide-metrics-only user@PCC# set isis interface all point-to-point user@PCC# set isis interface all level 2 metric 10 user@PCC# set isis interface fxp0.0 disable user@PCC# set isis interface lo0.0 passive
Konfigurieren Sie SRGB-Attribute (Segment Routing Global Block) für Das Segment-Routing.
[edit protocols] user@PCC# set isis source-packet-routing srgb start-label 800000 user@PCC# set isis source-packet-routing srgb index-range 4000 user@PCC# set isis source-packet-routing node-segment ipv4-index 101 user@PCC# set isis source-packet-routing node-segment ipv6-index 11
Aktivieren Sie externe Path Computing-Funktionen für SR-TE.
[edit protocols] user@PCC# set spring-traffic-engineering lsp-external-controller pccd
Konfigurieren Sie die PCE-Parameter und aktivieren Sie die Bereitstellung des LSP durch den PCE und die Segment-Routing-Funktion.
[edit protocols] user@PCC# set pcep pce pce1 local-address 192.168.100.4 user@PCC# set pcep pce pce1 destination-ipv4-address 10.102.180.232 user@PCC# set pcep pce pce1 destination-port 4189 user@PCC# set pcep pce pce1 pce-type active user@PCC# set pcep pce pce1 pce-type stateful
Ermöglichen Sie die Bereitstellung von Segment-Routing-LSPs durch den PCE.
[edit protocols] user@PCC# set pcep pce pce1 lsp-provisioning
Aktivieren Sie die Segment-Routing-Funktion für den PCE.
[edit protocols] user@PCC# set pcep pce pce1 spring-capability
Definieren Sie die statischen Parameter der Segmentliste
static_seg_list_1
.[edit protocols] user@PCC# set source-packet-routing segment-list static_seg_list_1 hop1 label 800102 user@PCC# set source-packet-routing segment-list static_seg_list_1 hop2 label 800103
Konfigurieren Sie einen statischen Segment-Routing-LSP vom PCC zum Router R3 für die PCE-Delegierung.
[edit protocols] user@PCC# set source-packet-routing source-routing-path static_srte_lsp_1 to 192.168.100.3
Aktivieren Sie die Delegierungsfunktion für den
static_srte_lsp_1
Quell-Routing-Pfad.[edit protocols] user@PCC# set source-packet-routing source-routing-path static_srte_lsp_1 primary static_seg_list_1 lsp-external-controller pccd
Indem Sie die Schritte 13, 14 und 15 abschließen, ermöglichen Sie dem PCC, die Segment-Routing-LSPs an den PCE zu delegieren.
Commit der Konfiguration.
Ergebnisse
Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie die show interfaces
Befehle und show protocols
show routing-options
die Befehle eingeben. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@PCC# show interfaces ge-0/0/5 { unit 0 { family inet { address 10.100.41.1/24; } family iso; family mpls; } } lo0 { unit 0 { family inet { address 192.168.100.4/32 { primary; } } family iso { address 49.0011.0110.0000.0101.00; } family mpls; } }
user@PCC# show routing-options static { route 100.1.1.1/32 next-hop 192.168.100.3; } router-id 192.168.100.4; autonomous-system 64496;
user@PCC# show protocols rsvp { interface fxp0.0 { disable; } interface all; } mpls { lsp-external-controller pccd; interface all; interface fxp0.0 { disable; } } isis { source-packet-routing { srgb start-label 800000 index-range 4000; node-segment { ipv4-index 101; ipv6-index 11; } } level 1 disable; level 2 wide-metrics-only; interface all { point-to-point; level 2 metric 10; } interface fxp0.0 { disable; } interface lo0.0 { passive; } } spring-traffic-engineering { lsp-external-controller pccd; } source-packet-routing { segment-list static_seg_list_1 { hop1 label 800102 hop1 label 800102 } source-routing-path static_srte_lsp_1 { to 192.168.100.3; primary { static_seg_list_1 { lsp-external-controller pccd; } } } } pcep { pce pce1 { local-address 192.168.100.4; destination-ipv4-address 10.102.180.232; destination-port 4189; pce-type active stateful; lsp-provisioning; spring-capability; } }
Wenn Sie mit der Konfiguration des Geräts (des PCC) fertig sind, geben Sie im Konfigurationsmodus ein commit
.
Überprüfung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
- Überprüfen der IS-IS-Adjacency und -Label
- Traffic Engineering-Datenbank überprüfen
- SR-TE-LSPs überprüfen
- Tunnelroutenerstellung überprüfen
- Überprüfen von Weiterleitungstabelleneinträgen
- Überprüfen der Verwendung von Tunnelrouten für statische Routenweiterleitung
Überprüfen der IS-IS-Adjacency und -Label
Zweck
Überprüfen Sie die IS-IS-Nachbarschaft auf dem PCC. Notieren Sie sich den SRGB-Labelbereich, die Adjacency- und Node-Segmentwerte sowie die Ausgabefelder der SPRING-Funktion.
Aktion
Führen Sie im Betriebsmodus die show isis adjacency extensive
Befehle show isis database extensive
und show isis overview
Befehle aus.
user@PCC> show isis adjacency extensive R1 Interface: ge-0/0/5.0, Level: 2, State: Up, Expires in 25 secs Priority: 0, Up/Down transitions: 1, Last transition: 00:37:15 ago Circuit type: 2, Speaks: IP, IPv6 Topologies: Unicast Restart capable: Yes, Adjacency advertisement: Advertise IP addresses: 10.100.41.2 Level 2 IPv4 Adj-SID: 16 Transition log: When State Event Down reason Wed Apr 5 02:42:48 Up Seenself PCE Interface: gre.0, Level: 2, State: Up, Expires in 25 secs Priority: 0, Up/Down transitions: 1, Last transition: 00:27:00 ago Circuit type: 2, Speaks: IP, IPv6 Topologies: Unicast Restart capable: Yes, Adjacency advertisement: Advertise IP addresses: 11.105.199.2 Level 2 Transition log: When State Event Down reason Wed Apr 5 02:53:03 Up Seenself
user@PCC> show isis database extensive IS-IS level 1 link-state database: IS-IS level 2 link-state database: PCC.00-00 Sequence: 0x2a6, Checksum: 0x1a4f, Lifetime: 1150 secs IPV4 Index: 101 Node Segment Blocks Advertised: Start Index : 0, Size : 4000, Label-Range: [ 800000, 803999 ] IS neighbor: R1.00 Metric: 10 Two-way fragment: R1.00-00, Two-way first fragment: R1.00-00 IS neighbor: PCE.00 Metric: 16777215 IP prefix: 192.168.100.4/32 Metric: 0 Internal Up IP prefix: 11.101.102.0/30 Metric: 10 Internal Up IP prefix: 11.105.199.0/30 Metric: 16777215 Internal Up Header: LSP ID: PCC.00-00, Length: 243 bytes Allocated length: 1492 bytes, Router ID: 192.168.100.4 Remaining lifetime: 1150 secs, Level: 2, Interface: 0 Estimated free bytes: 1084, Actual free bytes: 1249 Aging timer expires in: 1150 secs Protocols: IP, IPv6 Packet: LSP ID: PCC.00-00, Length: 243 bytes, Lifetime : 1198 secs Checksum: 0x1a4f, Sequence: 0x2a6, Attributes: 0x3 L1 L2 NLPID: 0x83, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes Packet type: 20, Packet version: 1, Max area: 0 TLVs: Area address: 49.0011 (3) LSP Buffer Size: 1492 Speaks: IP Speaks: IPV6 IP router id: 192.168.100.4 IP address: 192.168.100.4 Hostname: PCC IS extended neighbor: R1.00, Metric: default 10 IP address: 10.100.41.1 Neighbor's IP address: 10.100.41.2 Local interface index: 334, Remote interface index: 333 Current reservable bandwidth: Priority 0 : 10Mbps Priority 1 : 10Mbps Priority 2 : 10Mbps Priority 3 : 10Mbps Priority 4 : 10Mbps Priority 5 : 10Mbps Priority 6 : 10Mbps Priority 7 : 10Mbps Maximum reservable bandwidth: 10Mbps Maximum bandwidth: 10Mbps Administrative groups: 0 none P2P IPV4 Adj-SID - Flags:0x30(F:0,B:0,V:1,L:1,S:0), Weight:0, Label: 16 IS extended neighbor: PCE.00, Metric: default 16777215 IP address: 11.105.199.1 Neighbor's IP address: 11.105.199.2 Local interface index: 329, Remote interface index: 329 IP extended prefix: 11.101.102.0/30 metric 10 up IP extended prefix: 11.105.199.0/30 metric 16777215 up IP extended prefix: 192.168.100.4/32 metric 0 up 8 bytes of subtlvs Node SID, Flags: 0x40(R:0,N:1,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 101 Router Capability: Router ID 192.168.100.4, Flags: 0x00 SPRING Capability - Flags: 0xc0(I:1,V:1), Range: 4000, SID-Label: 800000 SPRING Algorithm - Algo: 0 No queued transmissions R1.00-00 Sequence: 0x297, Checksum: 0x1615, Lifetime: 839 secs IPV4 Index: 102 Node Segment Blocks Advertised: Start Index : 0, Size : 4000, Label-Range: [ 800000, 803999 ] IS neighbor: PCC.00 Metric: 10 Two-way fragment: PCC.00-00, Two-way first fragment: PCC.00-00 IS neighbor: R2.00 Metric: 10 Two-way fragment: R2.00-00, Two-way first fragment: R2.00-00 IP prefix: 192.168.100.1/32 Metric: 0 Internal Up IP prefix: 11.101.102.0/30 Metric: 10 Internal Up IP prefix: 11.102.105.0/30 Metric: 10 Internal Up Header: LSP ID: R1.00-00, Length: 302 bytes Allocated length: 302 bytes, Router ID: 192.168.100.1 Remaining lifetime: 839 secs, Level: 2, Interface: 334 Estimated free bytes: 0, Actual free bytes: 0 Aging timer expires in: 839 secs Protocols: IP, IPv6 Packet: LSP ID: R1.00-00, Length: 302 bytes, Lifetime : 1196 secs Checksum: 0x1615, Sequence: 0x297, Attributes: 0x3 L1 L2 NLPID: 0x83, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes Packet type: 20, Packet version: 1, Max area: 0 TLVs: Area address: 49.0011 (3) LSP Buffer Size: 1492 Speaks: IP Speaks: IPV6 IP router id: 192.168.100.1 IP address: 192.168.100.1 Hostname: R1 IP extended prefix: 192.168.100.1/32 metric 0 up 8 bytes of subtlvs Node SID, Flags: 0x40(R:0,N:1,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 102 IP extended prefix: 11.101.102.0/30 metric 10 up IP extended prefix: 11.102.105.0/30 metric 10 up Router Capability: Router ID 192.168.100.1, Flags: 0x00 SPRING Capability - Flags: 0xc0(I:1,V:1), Range: 4000, SID-Label: 800000 SPRING Algorithm - Algo: 0 IS extended neighbor: R2.00, Metric: default 10 IP address: 10.100.12.1 Neighbor's IP address: 10.100.12.2 Local interface index: 334, Remote interface index: 333 Current reservable bandwidth: Priority 0 : 10Mbps Priority 1 : 10Mbps Priority 2 : 10Mbps Priority 3 : 10Mbps Priority 4 : 10Mbps Priority 5 : 10Mbps Priority 6 : 10Mbps Priority 7 : 10Mbps Maximum reservable bandwidth: 10Mbps Maximum bandwidth: 10Mbps Administrative groups: 0 none P2P IPV4 Adj-SID - Flags:0x30(F:0,B:0,V:1,L:1,S:0), Weight:0, Label: 17 IS extended neighbor: PCC.00, Metric: default 10 IP address: 10.100.41.2 Neighbor's IP address: 10.100.41.1 Local interface index: 333, Remote interface index: 334 Current reservable bandwidth: Priority 0 : 10Mbps Priority 1 : 10Mbps Priority 2 : 10Mbps Priority 3 : 10Mbps Priority 4 : 10Mbps Priority 5 : 10Mbps Priority 6 : 10Mbps Priority 7 : 10Mbps Maximum reservable bandwidth: 10Mbps Maximum bandwidth: 10Mbps Administrative groups: 0 none P2P IPV4 Adj-SID - Flags:0x30(F:0,B:0,V:1,L:1,S:0), Weight:0, Label: 16 No queued transmissions R3.00-00 Sequence: 0x95, Checksum: 0xd459, Lifetime: 895 secs IPV4 Index: 103 Node Segment Blocks Advertised: Start Index : 0, Size : 4000, Label-Range: [ 800000, 803999 ] IS neighbor: R2.00 Metric: 10 Two-way fragment: R2.00-00, Two-way first fragment: R2.00-00 IP prefix: 192.168.100.3/32 Metric: 0 Internal Up IP prefix: 11.102.1.0/24 Metric: 10 Internal Up IP prefix: 11.103.107.0/30 Metric: 10 Internal Up Header: LSP ID: R3.00-00, Length: 209 bytes Allocated length: 284 bytes, Router ID: 192.168.100.3 Remaining lifetime: 895 secs, Level: 2, Interface: 334 Estimated free bytes: 75, Actual free bytes: 75 Aging timer expires in: 895 secs Protocols: IP, IPv6 Packet: LSP ID: R3.00-00, Length: 209 bytes, Lifetime : 1192 secs Checksum: 0xd459, Sequence: 0x95, Attributes: 0x3 L1 L2 NLPID: 0x83, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes Packet type: 20, Packet version: 1, Max area: 0 TLVs: Area address: 49.0011 (3) LSP Buffer Size: 1492 Speaks: IP Speaks: IPV6 IP router id: 192.168.100.3 IP address: 192.168.100.3 Hostname: R3 IS extended neighbor: R2.00, Metric: default 10 IP address: 10.100.23.2 Neighbor's IP address: 10.100.23.1 Local interface index: 336, Remote interface index: 334 Current reservable bandwidth: Priority 0 : 10Mbps Priority 1 : 10Mbps Priority 2 : 10Mbps Priority 3 : 10Mbps Priority 4 : 10Mbps Priority 5 : 10Mbps Priority 6 : 10Mbps Priority 7 : 10Mbps Maximum reservable bandwidth: 10Mbps Maximum bandwidth: 10Mbps Administrative groups: 0 none P2P IPV4 Adj-SID - Flags:0x30(F:0,B:0,V:1,L:1,S:0), Weight:0, Label: 16 IP extended prefix: 192.168.100.3/32 metric 0 up 8 bytes of subtlvs Node SID, Flags: 0x40(R:0,N:1,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 103 IP extended prefix: 11.103.107.0/30 metric 10 up IP extended prefix: 11.102.1.0/24 metric 10 up Router Capability: Router ID 192.168.100.3, Flags: 0x00 SPRING Capability - Flags: 0xc0(I:1,V:1), Range: 4000, SID-Label: 800000 SPRING Algorithm - Algo: 0 No queued transmissions R2.00-00 Sequence: 0x2aa, Checksum: 0xf8f4, Lifetime: 1067 secs IPV4 Index: 105 Node Segment Blocks Advertised: Start Index : 0, Size : 4000, Label-Range: [ 800000, 803999 ] IS neighbor: R1.00 Metric: 10 Two-way fragment: R1.00-00, Two-way first fragment: R1.00-00 IS neighbor: R3.00 Metric: 10 Two-way fragment: R3.00-00, Two-way first fragment: R3.00-00 IP prefix: 192.168.100.2/32 Metric: 0 Internal Up IP prefix: 11.102.105.0/30 Metric: 10 Internal Up IP prefix: 11.103.107.0/30 Metric: 10 Internal Up Header: LSP ID: R2.00-00, Length: 302 bytes Allocated length: 302 bytes, Router ID: 192.168.100.2 Remaining lifetime: 1067 secs, Level: 2, Interface: 334 Estimated free bytes: 0, Actual free bytes: 0 Aging timer expires in: 1067 secs Protocols: IP, IPv6 Packet: LSP ID: R2.00-00, Length: 302 bytes, Lifetime : 1194 secs Checksum: 0xf8f4, Sequence: 0x2aa, Attributes: 0x3 L1 L2 NLPID: 0x83, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes Packet type: 20, Packet version: 1, Max area: 0 TLVs: Area address: 49.0011 (3) LSP Buffer Size: 1492 Speaks: IP Speaks: IPV6 IP router id: 192.168.100.2 IP address: 192.168.100.2 Hostname: R2 IP extended prefix: 192.168.100.2/32 metric 0 up 8 bytes of subtlvs Node SID, Flags: 0x40(R:0,N:1,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 105 IP extended prefix: 11.102.105.0/30 metric 10 up IP extended prefix: 11.103.107.0/30 metric 10 up Router Capability: Router ID 192.168.100.2, Flags: 0x00 SPRING Capability - Flags: 0xc0(I:1,V:1), Range: 4000, SID-Label: 800000 SPRING Algorithm - Algo: 0 IS extended neighbor: R3.00, Metric: default 10 IP address: 10.100.23.1 Neighbor's IP address: 10.100.23.2 Local interface index: 334, Remote interface index: 336 Current reservable bandwidth: Priority 0 : 10Mbps Priority 1 : 10Mbps Priority 2 : 10Mbps Priority 3 : 10Mbps Priority 4 : 10Mbps Priority 5 : 10Mbps Priority 6 : 10Mbps Priority 7 : 10Mbps Maximum reservable bandwidth: 10Mbps Maximum bandwidth: 10Mbps Administrative groups: 0 none P2P IPV4 Adj-SID - Flags:0x30(F:0,B:0,V:1,L:1,S:0), Weight:0, Label: 16 IS extended neighbor: R1.00, Metric: default 10 IP address: 10.100.12.2 Neighbor's IP address: 10.100.12.1 Local interface index: 333, Remote interface index: 334 Current reservable bandwidth: Priority 0 : 10Mbps Priority 1 : 10Mbps Priority 2 : 10Mbps Priority 3 : 10Mbps Priority 4 : 10Mbps Priority 5 : 10Mbps Priority 6 : 10Mbps Priority 7 : 10Mbps Maximum reservable bandwidth: 10Mbps Maximum bandwidth: 10Mbps Administrative groups: 0 none P2P IPV4 Adj-SID - Flags:0x30(F:0,B:0,V:1,L:1,S:0), Weight:0, Label: 17 No queued transmissions PCE.00-00 Sequence: 0x277, Checksum: 0x64a5, Lifetime: 533 secs IS neighbor: PCC.00 Metric: 16777215 IP prefix: 11.0.0.199/32 Metric: 0 Internal Up IP prefix: 11.105.199.0/30 Metric: 16777215 Internal Up Header: LSP ID: PCE.00-00, Length: 120 bytes Allocated length: 284 bytes, Router ID: 11.0.0.199 Remaining lifetime: 533 secs, Level: 2, Interface: 329 Estimated free bytes: 164, Actual free bytes: 164 Aging timer expires in: 533 secs Protocols: IP, IPv6 Packet: LSP ID: PCE.00-00, Length: 120 bytes, Lifetime : 1196 secs Checksum: 0x64a5, Sequence: 0x277, Attributes: 0x3 L1 L2 NLPID: 0x83, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes Packet type: 20, Packet version: 1, Max area: 0 TLVs: Area address: 11.0007 (3) LSP Buffer Size: 1492 Speaks: IP Speaks: IPV6 IP router id: 11.0.0.199 IP address: 11.0.0.199 Hostname: PCE Router Capability: Router ID 11.0.0.199, Flags: 0x00 IP extended prefix: 11.105.199.0/30 metric 16777215 up IP extended prefix: 11.0.0.199/32 metric 0 up IS extended neighbor: PCC.00, Metric: default 16777215 IP address: 11.105.199.2 Neighbor's IP address: 11.105.199.1 Local interface index: 329, Remote interface index: 329 No queued transmissions
user@PCC> show isis overview Instance: master Router ID: 192.168.100.4 Hostname: PCC Sysid: 0110.0000.0101 Areaid: 49.0011 Adjacency holddown: enabled Maximum Areas: 3 LSP life time: 1200 Attached bit evaluation: enabled SPF delay: 200 msec, SPF holddown: 5000 msec, SPF rapid runs: 3 IPv4 is enabled, IPv6 is enabled, SPRING based MPLS is enabled Traffic engineering: enabled Restart: Disabled Helper mode: Enabled Layer2-map: Disabled Source Packet Routing (SPRING): Enabled SRGB Config Range: SRGB Start-Label : 800000, SRGB Index-Range : 4000 SRGB Block Allocation: Success SRGB Start Index : 800000, SRGB Size : 4000, Label-Range: [ 800000, 803999 ] Node Segments: Enabled Ipv4 Index : 101, Ipv6 Index : 11 Level 1 Internal route preference: 15 External route preference: 160 Prefix export count: 0 Wide metrics are enabled, Narrow metrics are enabled Source Packet Routing is enabled Level 2 Internal route preference: 18 External route preference: 165 Prefix export count: 0 Wide metrics are enabled Source Packet Routing is enabled
Bedeutung
Die IS-IS-Verbindung zwischen PCC und PCE und die zwischen PCC und Router R1 sind in Betrieb. Die Ausgabe zeigt auch die Labelzuweisungen für die angrenzenden und Knotensegmente an.
Traffic Engineering-Datenbank überprüfen
Zweck
Überprüfen Sie die Traffic-Engineering-Datenbankeinträge auf dem PCC.
Aktion
Führen Sie den Befehl im show ted database extensive
Betriebsmodus aus.
user@PCC# show ted database extensive TED database: 5 ISIS nodes 5 INET nodes NodeID: PCC.00(192.168.100.4) Type: Rtr, Age: 403 secs, LinkIn: 1, LinkOut: 1 Protocol: IS-IS(2) 192.168.100.4 To: R1.00(192.168.100.1), Local: 10.100.41.1, Remote: 10.100.41.2 Local interface index: 334, Remote interface index: 333 Color: 0 none Metric: 10 IGP metric: 10 Static BW: 10Mbps Reservable BW: 10Mbps Available BW [priority] bps: [0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps [4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps Interface Switching Capability Descriptor(1): Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps [4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps P2P Adjacency-SID: IPV4, SID: 16, Flags: 0x30, Weight: 0 Prefixes: 192.168.100.4/32 Metric: 0, Flags: 0x00 Prefix-SID: SID: 101, Flags: 0x40, Algo: 0 SPRING-Capabilities: SRGB block [Start: 800000, Range: 4000, Flags: 0xc0] SPRING-Algorithms: Algo: 0 NodeID: R1.00(192.168.100.1) Type: Rtr, Age: 712 secs, LinkIn: 2, LinkOut: 2 Protocol: IS-IS(2) 192.168.100.1 To: PCC.00(192.168.100.4), Local: 10.100.41.2, Remote: 10.100.41.1 Local interface index: 333, Remote interface index: 334 Color: 0 none Metric: 10 IGP metric: 10 Static BW: 10Mbps Reservable BW: 10Mbps Available BW [priority] bps: [0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps [4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps Interface Switching Capability Descriptor(1): Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps [4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps P2P Adjacency-SID: IPV4, SID: 16, Flags: 0x30, Weight: 0 To: R2.00(192.168.100.2), Local: 10.100.12.1, Remote: 10.100.12.2 Local interface index: 334, Remote interface index: 333 Color: 0 none Metric: 10 IGP metric: 10 Static BW: 10Mbps Reservable BW: 10Mbps Available BW [priority] bps: [0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps [4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps Interface Switching Capability Descriptor(1): Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps [4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps P2P Adjacency-SID: IPV4, SID: 17, Flags: 0x30, Weight: 0 Prefixes: 192.168.100.1/32 Metric: 0, Flags: 0x00 Prefix-SID: SID: 102, Flags: 0x40, Algo: 0 SPRING-Capabilities: SRGB block [Start: 800000, Range: 4000, Flags: 0xc0] SPRING-Algorithms: Algo: 0 NodeID: R3.00(192.168.100.3) Type: Rtr, Age: 435 secs, LinkIn: 1, LinkOut: 1 Protocol: IS-IS(2) 192.168.100.3 To: R2.00(192.168.100.2), Local: 10.100.23.2, Remote: 10.100.23.1 Local interface index: 336, Remote interface index: 334 Color: 0 none Metric: 10 IGP metric: 10 Static BW: 10Mbps Reservable BW: 10Mbps Available BW [priority] bps: [0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps [4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps Interface Switching Capability Descriptor(1): Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps [4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps P2P Adjacency-SID: IPV4, SID: 16, Flags: 0x30, Weight: 0 Prefixes: 192.168.100.3/32 Metric: 0, Flags: 0x00 Prefix-SID: SID: 103, Flags: 0x40, Algo: 0 SPRING-Capabilities: SRGB block [Start: 800000, Range: 4000, Flags: 0xc0] SPRING-Algorithms: Algo: 0 NodeID: R2.00(192.168.100.2) Type: Rtr, Age: 456 secs, LinkIn: 2, LinkOut: 2 Protocol: IS-IS(2) 192.168.100.2 To: R1.00(192.168.100.1), Local: 10.100.12.2, Remote: 10.100.12.1 Local interface index: 333, Remote interface index: 334 Color: 0 none Metric: 10 IGP metric: 10 Static BW: 10Mbps Reservable BW: 10Mbps Available BW [priority] bps: [0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps [4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps Interface Switching Capability Descriptor(1): Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps [4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps P2P Adjacency-SID: IPV4, SID: 17, Flags: 0x30, Weight: 0 To: R3.00(192.168.100.3), Local: 10.100.23.1, Remote: 10.100.23.2 Local interface index: 334, Remote interface index: 336 Color: 0 none Metric: 10 IGP metric: 10 Static BW: 10Mbps Reservable BW: 10Mbps Available BW [priority] bps: [0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps [4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps Interface Switching Capability Descriptor(1): Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps [4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps P2P Adjacency-SID: IPV4, SID: 16, Flags: 0x30, Weight: 0 Prefixes: 192.168.100.2/32 Metric: 0, Flags: 0x00 Prefix-SID: SID: 105, Flags: 0x40, Algo: 0 SPRING-Capabilities: SRGB block [Start: 800000, Range: 4000, Flags: 0xc0] SPRING-Algorithms: Algo: 0 NodeID: PCE.00(11.0.0.199) Type: Rtr, Age: 267 secs, LinkIn: 0, LinkOut: 0 Protocol: IS-IS(2) 11.0.0.199
Bedeutung
Die Traffic-Engineering-Datenbank enthält Einträge, die von den Routern R1, R2 und R3 angekündigt werden, die der PCE für das externe Path Computing für den PCC verwendet.
SR-TE-LSPs überprüfen
Zweck
Überprüfen Sie die Erstellung von SR-TE-LSPs auf dem PCC.
Aktion
Führen Sie im Betriebsmodus die show path-computation-client lsp
Befehle show spring-traffic-engineering lsp detail
und show route protocol spring-te
Befehle aus.
user@PCC> show path-computation-client lsp Name Status PLSP-Id LSP-Type Controller Path-Setup-Type Template adj_sid_lsp (Up) 3 ext-provised pce1 spring-te node_sid_lsp (Up) 5 ext-provised pce1 spring-te
user@PCC> show spring-traffic-engineering lsp detail Name: adj_sid_lsp To: 192.168.100.3 State: Up, Outgoing interface: ge-0/0/5.0 Delegation info: Control-status: Externally controlled Routing-status: Externally routed SR-ERO hop count: 3 Hop 1 (Strict): NAI: IPv4 Adjacency ID, 10.100.41.1 -> 10.100.41.2 SID type: 20-bit label, Value: 16 Hop 2 (Strict): NAI: IPv4 Adjacency ID, 10.100.12.1 -> 10.100.12.2 SID type: 20-bit label, Value: 17 Hop 3 (Strict): NAI: IPv4 Adjacency ID, 10.100.23.1 -> 10.100.23.2 SID type: 20-bit label, Value: 16 Name: node_sid_lsp To: 192.168.100.3 State: Up, Outgoing interface: ge-0/0/5.0 Delegation info: Control-status: Externally controlled Routing-status: Externally routed SR-ERO hop count: 3 Hop 1 (Strict): NAI: IPv4 Adjacency ID, 10.100.41.1 -> 10.100.41.2 SID type: 20-bit label, Value: 16 Hop 2 (Strict): NAI: IPv4 Node ID, Node address: 192.168.100.1 SID type: 20-bit label, Value: 800105 Hop 3 (Strict): NAI: IPv4 Node ID, Node address: 192.168.100.2 SID type: 20-bit label, Value: 800103 Name: static_srte_lsp_1 Tunnel-source: Static configuration To: 192.168.100.3 State: Up Path: static_seg_list_1 Outgoing interface: NA Delegation info: Control-status: Externally controlled Routing-status: Externally routed Auto-translate status: Disabled Auto-translate result: N/A BFD status: Up BFD name: V4-srte_bfd_session-4 SR-ERO hop count: 2 Hop 1 (Strict): NAI: IPv4 Adjacency ID, 13.1.1.2 -> 36.12.16.1 SID type: None Hop 2 (Strict): NAI: IPv4 Node ID, Node address: 192.168.100.3 SID type: 20-bit label, Value: 804000 Total displayed LSPs: 3 (Up: 3, Down: 0)
user@PCC> show route protocol spring-te inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden) inet.3: 3 destinations, 4 routes (3 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.100.3/32 *[SPRING-TE/8] 00:23:32, metric 0 to 10.100.41.2 via ge-0/0/5.0, Push 16, Push 17(top) > to 10.100.41.2 via ge-0/0/5.0, Push 800103, Push 800105(top) iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) mpls.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden) inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
Bedeutung
Die Ausgaben zeigen, dass zwei SR-TE-LSPs –adj_sid_lsp
und node_sid_lsp
– vom PCE für die Adjacency- bzw. Node-Segmente erstellt wurden.
Der Segment-Routing-LSP static_srte_lsp_1
, , wird mit der Delegierungsfunktion aktiviert. Das Delegation info
Feld zeigt den Steuerungs- und Routing-Status von PCE-delegierten LSPs. Externally controlled
bedeutet, dass der PCE die Kontrolle über die LSPs hat. Externally routed
Bedeutet, dass der PCE den ERO für den Quell-Routing-Pfad bereitgestellt hat.
Tunnelroutenerstellung überprüfen
Zweck
Überprüfen Sie die Tunnelrouten, die für die SR-TE-LSPs erstellt wurden, die in der Routingtabelle inet.3 auf dem PCC enthalten sind.
Aktion
Führen Sie den Befehl im show route table inet.3 extensive
Betriebsmodus aus.
user@PCC> show route table inet.3 extensive inet.3: 3 destinations, 4 routes (3 active, 0 holddown, 0 hidden) 192.168.100.1/32 (1 entry, 1 announced) *L-ISIS Preference: 14 Level: 2 Next hop type: Router, Next hop index: 581 Address: 0xb7a23b0 Next-hop reference count: 13 Next hop: 10.100.41.2 via ge-0/0/5.0, selected Session Id: 0x172 State: Active Int Local AS: 64496 Age: 45:51 Metric: 10 Validation State: unverified ORR Generation-ID: 0 Task: IS-IS Announcement bits (2): 0-Resolve tree 1 2-Resolve tree 3 AS path: I 192.168.100.3/32 (2 entries, 1 announced) *SPRING-TE Preference: 8 Next hop type: Router, Next hop index: 0 Address: 0xb61c190 Next-hop reference count: 7 Next hop: 10.100.41.2 via ge-0/0/5.0 weight 0x1 Label operation: Push 16, Push 17(top) Label TTL action: prop-ttl, prop-ttl(top) Load balance label: Label 16: None; Label 17: None; Label element ptr: 0xb7a2a60 Label parent element ptr: 0x0 Label element references: 5 Label element child references: 0 Label element lsp id: 0 Session Id: 0x0 Next hop: 10.100.41.2 via ge-0/0/5.0 weight 0x1, selected Label operation: Push 800103, Push 800105(top) Label TTL action: prop-ttl, prop-ttl(top) Load balance label: Label 800103: None; Label 800105: None; Label element ptr: 0xb7a2c40 Label parent element ptr: 0x0 Label element references: 2 Label element child references: 0 Label element lsp id: 0 Session Id: 0x0 State: Active Int Local AS: 64496 Age: 9:44 Metric: 0 Validation State: unverified Task: SPRING-TE Announcement bits (2): 0-Resolve tree 1 2-Resolve tree 3 AS path: I L-ISIS Preference: 14 Level: 2 Next hop type: Router, Next hop index: 0 Address: 0xb7a28f0 Next-hop reference count: 1 Next hop: 10.100.41.2 via ge-0/0/5.0, selected Label operation: Push 800103 Label TTL action: prop-ttl Load balance label: Label 800103: None; Label element ptr: 0xb7a2880 Label parent element ptr: 0x0 Label element references: 1 Label element child references: 0 Label element lsp id: 0 Session Id: 0x0 State: Int Inactive reason: Route Preference Local AS: 64496 Age: 45:40 Metric: 30 Validation State: unverified ORR Generation-ID: 0 Task: IS-IS AS path: I 192.168.100.2/32 (1 entry, 1 announced) *L-ISIS Preference: 14 Level: 2 Next hop type: Router, Next hop index: 0 Address: 0xb7a29b0 Next-hop reference count: 1 Next hop: 10.100.41.2 via ge-0/0/5.0, selected Label operation: Push 800105 Label TTL action: prop-ttl Load balance label: Label 800105: None; Label element ptr: 0xb7a2940 Label parent element ptr: 0x0 Label element references: 1 Label element child references: 0 Label element lsp id: 0 Session Id: 0x0 State: Active Int Local AS: 64496 Age: 45:40 Metric: 20 Validation State: unverified ORR Generation-ID: 0 Task: IS-IS Announcement bits (2): 0-Resolve tree 1 2-Resolve tree 3 AS path: I
Bedeutung
Tunnelrouten wurden für das PCE-kontrollierte LSP-Ziel mit SR-TE als Protokoll-Label erstellt.
Überprüfen von Weiterleitungstabelleneinträgen
Zweck
Stellen Sie sicher, dass das SR-TE LSP-Ziel für Router R3 in der Weiterleitungstabelle des PCC installiert ist.
Aktion
Führen Sie den Befehl im show route forwarding-table destination ip-address extensive
Betriebsmodus aus.
user@PCC> show route forwarding-table destination 192.168.100.3 extensive Routing table: default.inet [Index 0] Internet: Enabled protocols: Bridging, Destination: 192.168.100.3/32 Route type: user Route reference: 0 Route interface-index: 0 Multicast RPF nh index: 0 P2mpidx: 0 Flags: sent to PFE, rt nh decoupled Nexthop: 10.100.41.2 Next-hop type: unicast Index: 581 Reference: 14 Next-hop interface: ge-0/0/5.0 Routing table: __pfe_private__.inet [Index 3] Internet: Enabled protocols: Bridging, Destination: default Route type: permanent Route reference: 0 Route interface-index: 0 Multicast RPF nh index: 0 P2mpidx: 0 Flags: sent to PFE Next-hop type: discard Index: 517 Reference: 2 Routing table: __juniper_services__.inet [Index 5] Internet: Enabled protocols: Bridging, Destination: default Route type: permanent Route reference: 0 Route interface-index: 0 Multicast RPF nh index: 0 P2mpidx: 0 Flags: sent to PFE Next-hop type: discard Index: 530 Reference: 2 Routing table: __master.anon__.inet [Index 6] Internet: Enabled protocols: Bridging, Dual VLAN, Destination: default Route type: permanent Route reference: 0 Route interface-index: 0 Multicast RPF nh index: 0 P2mpidx: 0 Flags: sent to PFE Next-hop type: reject Index: 545 Reference: 1
Bedeutung
Die SR-TE LSP-Ziel-IP-Adresse für Router R3 wird als Weiterleitungseintrag installiert.
Überprüfen der Verwendung von Tunnelrouten für statische Routenweiterleitung
Zweck
Stellen Sie sicher, dass die statische Route die Tunnelroute übernimmt, die für die SR-TE-LSPs erstellt wurde.
Aktion
Führen Sie die show route ip-address
Befehle im show route forwarding-table destination ip-address
Betriebsmodus aus.
user@PCC> show route 100.1.1.1 inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 100.1.1.1/32 *[Static/5] 00:33:36, metric2 0 > to 10.100.41.2 via ge-0/0/5.0, Push 16, Push 17(top) to 10.100.41.2 via ge-0/0/5.0, Push 800103, Push 800105(top)
user@PCC> show route forwarding-table destination 100.1.1.1 Routing table: default.inet Internet: Enabled protocols: Bridging, Destination Type RtRef Next hop Type Index NhRef Netif 100.1.1.1/32 user 0 indr 1048575 2 10.100.41.2 Push 16, Push 17(top) 590 2 ge-0/0/5.0 Routing table: __pfe_private__.inet Internet: Enabled protocols: Bridging, Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 dscd 517 2 Routing table: __juniper_services__.inet Internet: Enabled protocols: Bridging, Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 dscd 530 2 Routing table: __master.anon__.inet Internet: Enabled protocols: Bridging, Dual VLAN, Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 rjct 545 1
Bedeutung
Die Ausgaben zeigen, dass die statische Route zu Router R3 die für den SR-TE LSP erstellte Tunnelroute verwendet.
Statisches Segment-Routing Label Switched Path
Die Segment-Routing-Architektur ermöglicht es den Eingangsgeräten in einem Core-Netzwerk, den Datenverkehr über explizite Pfade zu steuern. Sie können diese Pfade mithilfe von Segmentlisten konfigurieren, um die Pfade zu definieren, die der eingehende Datenverkehr nehmen soll. Der eingehende Datenverkehr kann gekennzeichnet oder IP-Datenverkehr sein, was dazu führt, dass der Weiterleitungsvorgang am Eingangsgerät entweder ein Label-Swap oder eine zielbasierte Suche ist.
- Grundlegendes zu statischem Segment-Routing-LSP in MPLS-Netzwerken
- Beispiel: Konfigurieren von statischem Segment-Routing Label Switched Path
Grundlegendes zu statischem Segment-Routing-LSP in MPLS-Netzwerken
Quellpaket-Routing oder Segment-Routing ist eine Architektur auf Steuerungsebene, die es einem Eingangsrouter ermöglicht, ein Paket durch eine bestimmte Gruppe von Knoten und Verbindungen im Netzwerk zu steuern, ohne sich auf die Zwischenknoten im Netzwerk zu verlassen, um den tatsächlichen Pfad zu bestimmen.
- Einführung in Segment-Routing-LSPs
- Vorteile der Verwendung von Segment-Routing-LSPs
- Farbiger statischer Segment-Routing-LSP
- Nicht farbiger statischer Segment-Routing-LSP
- Statische Segment-Routing LSP-Bereitstellung
- Einschränkungen statischer Segment-Routing-LSP
- Dynamische Erstellung von Segment-Routing-LSPs
- Farbbasierte Zuordnung von VPN-Services
- Tunnelvorlagen für PCE-initiierte Segment-Routing-LSPs
Einführung in Segment-Routing-LSPs
Segment-Routing nutzt das Quell-Routing-Paradigma. Ein Gerät lenkt ein Paket durch eine geordnete Liste von Anweisungen, die als Segmente bezeichnet werden. Ein Segment kann jede Anweisung, topologische oder servicebasiert darstellen. Ein Segment kann eine lokale Semantik zu einem Segment-Routing-Knoten oder zu einem globalen Knoten innerhalb einer Segment-Routing-Domäne haben. Segment-Routing erzwingt einen Datenfluss durch alle topologischen Pfade und Serviceketten, während der Status pro Datenstrom nur am Eingangsgerät zur Segment-Routing-Domäne beibehalten wird. Segment-Routing kann direkt auf die MPLS-Architektur angewendet werden, ohne dass sich dies auf der Weiterleitungsebene ändert. Ein Segment wird als MPLS-Label codiert. Eine geordnete Liste von Segmenten wird als Stapel von Labeln codiert. Das zu verarbeitene Segment steht ganz oben auf dem Stack. Nach Abschluss eines Segments wird das entsprechende Label aus dem Stack geknallt.
Segment-Routing-LSPs können entweder dynamisch oder statisch sein.
Dynamic segment routing LSPs— Wenn ein Segment-Routing-LSP entweder von einem externen Controller erstellt und über Path Computation Element Protocol (PCEP)-Erweiterungen auf ein Eingangsgerät heruntergeladen wird, oder von einer BGP-Segment-Routing-Richtlinie über BGP-Segment-Routing-Erweiterungen, wird der LSP dynamisch bereitgestellt. Die Segmentliste des dynamischen Segment-Routing-LSP ist im PCEP Explicit Route Object (ERO) oder der BGP-Segment-Routing-Richtlinie des LSP enthalten. |
Static segment routing LSPs– Wenn ein Segment-Routing-LSP auf dem Eingangsgerät durch eine lokale Konfiguration erstellt wird, wird der LSP statisch bereitgestellt. Ein statischer Segment-Routing-LSP kann außerdem basierend auf der Konfiguration Zum Beispiel: [edit protocols] source-packet-routing { source-routing-path lsp_name { to destination_address; color color_value; binding-sid binding-label; primary segment_list_1_name weight weight; ... primary segment_list_n_name weight weight; secondary segment_list_n_name; sr-preference sr_preference_value; } } Hier bezieht sich jede primäre und sekundäre Anweisung auf eine Segmentliste. [edit protocols] source-packet-routing { segment-list segment_list_name { hop_1_name label sid_label; ... hop_n_name label sid_label; } } |
Vorteile der Verwendung von Segment-Routing-LSPs
-
Statisches Segment-Routing hängt nicht vom LSP-Weiterleitungsstatus auf Transit-Routern ab. Dadurch entfällt die Notwendigkeit der Bereitstellung und Aufrechterhaltung pro LSP-Weiterleitungsstatus im Core.
-
Bieten Sie MPLS-Netzwerken eine höhere Skalierbarkeit.
Farbiger statischer Segment-Routing-LSP
Ein statischer Segment-Routing-LSP, der mit der color
Anweisung konfiguriert ist, wird als farbiger LSP bezeichnet.
- Grundlegendes zu farbigen statischen Segment-Routing-LSPs
- Segmentliste der farbigen Segment-Routing-LSPs
Grundlegendes zu farbigen statischen Segment-Routing-LSPs
Ähnlich wie bei einer BGP-Segment-Routing-Richtlinie wird die Eingangsroute des farbigen LSP in den Routing-Tabellen oder inet6color.0
Routing-Tabellen mit destincation-ip-address, color
schlüssel für die inetcolor.0
Zuordnung des IP-Datenverkehrs installiert.
Ein statischer gefärbter Segment-Routing-LSP kann eine Bindungs-SID haben, für die eine Route in der mpls.0
Routing-Tabelle installiert ist. Dieses verbindliche SID-Label wird verwendet, um gekennzeichneten Datenverkehr dem Segment-Routing-LSP zuzuordnen. Die Gateways der Route werden aus den Segmentlistenkonfigurationen unter den primären und sekundären Pfaden abgeleitet.
Segmentliste der farbigen Segment-Routing-LSPs
Die farbigen statischen Segment-Routing-LSPs unterstützen bereits den Ersten Hop-Label-Modus zur Auflösung eines LSP. Der First-Hop-IP-Modus wird jedoch für farbige Segment-Routing-LSPs nicht unterstützt. Ab Junos OS Version 19.1R1 wird eine Commit-Check-Funktion eingeführt, um sicherzustellen, dass alle Segmentlisten, die zu den farbigen Routen beitragen, das Mindestetikett für alle Hops aufweisen. Wenn diese Anforderung nicht erfüllt ist, wird das Commit blockiert.
Nicht farbiger statischer Segment-Routing-LSP
Ein statischer Segment-Routing-LSP, der ohne die color
Anweisung konfiguriert wird, ist ein nicht farbiger LSP. Ähnlich wie PCEP-Segment-Routing-Tunnel wird die Eingangsroute in den inet.3
Routing-Tabellen oder inet6.3
Routing-Tabellen installiert.
Junos OS unterstützt nicht farbige statische Segment-Routing-LSPs auf Eingangsroutern. Sie können nicht farbige statische Segment-Routing-LSP bereitstellen, indem Sie einen Quell-Routing-Pfad und eine oder mehrere Segmentlisten konfigurieren. Diese Segmentlisten können von mehreren nicht farbigen Segment-Routing-LSPs verwendet werden.
- Verständnis von nicht farbigen Segment-Routing-LSPs
- Segmentliste der nicht farbigen Segment-Routing-LSPs
Verständnis von nicht farbigen Segment-Routing-LSPs
Der nicht farbige Segment-Routing-LSP hat einen eindeutigen Namen und eine Ziel-IP-Adresse. Eine Eingangsroute zum Ziel wird in der Routingtabelle inet.3 mit einer Standardeinstellung von 8 und einer Metrik von 1 installiert. Mit dieser Route können nicht farbige Services dem Segment-Routing-LSP zugeordnet werden, der sich auf das Ziel bezieht. Falls der nicht farbige Segment-Routing-LSP keine Eingangsroute erfordert, kann die Eingangsroute deaktiviert werden. Ein nicht farbiger Segment-Routing-LSP verwendet verbindliches SID-Label, um Segment-Routing-LSP-Stitching zu erreichen. Dieses Label kann verwendet werden, um den Segment-Routing-LSP als Segment zu modellieren, das weiter verwendet werden kann, um andere Segment-Routing-LSPs hierarchisch zu erstellen. Der Transit des bindenden SID-Labels hat standardmäßig eine Präferenz von 8 und eine Metrik von 1.
Ab Junos OS Version 18.2R1 werden statisch konfigurierte nicht farbige Segment-Routing-LSPs auf dem Eingangsgerät über eine Path Computation Element Protocol (PCE)-Sitzung an das Path Computation Element Protocol (PCE) gemeldet. Diesen nicht farbigen Segment-Routing-LSPs sind möglicherweise SID-Label (Binding Service Identifier) zugeordnet. Mit dieser Funktion kann der PCE dieses verbindliche SID-Label im Labelstack verwenden, um PCE-initiierte Segment-Routing-LSP-Pfade bereitzustellen.
Ein nicht farbiger Segment-Routing-LSP kann maximal 8 primäre Pfade haben. Wenn mehrere primäre Pfade für den Betrieb vorhanden sind, verteilt die Packet Forwarding Engine (PFE) den Datenverkehr über die Pfade basierend auf Load Balancing-Faktoren wie der auf dem Pfad konfigurierten Gewichtung. Dies ist equal cost Multi Path (ECMP), wenn auf keinem der Pfade eine Gewichtung konfiguriert oder ein gewichtetes ECMP konfiguriert wird, wenn mindestens einer der Pfade eine Nicht-Null-Gewichtung auf den Pfaden konfiguriert hat. In beiden Fällen, wenn einer oder einige der Pfade ausfällt, stellt die PFE den Datenverkehr über die verbleibenden Pfade neu aus, was automatisch zum Schutz des Pfads führt. Ein nicht farbiger Segment-Routing-LSP kann einen sekundären Pfad für dedizierten Pfadschutz haben. Wenn ein primärer Pfad ausfällt, stellt der PFE den Datenverkehr zu den verbleibenden funktionalen primären Pfaden neu aus. Andernfalls wechselt die PFE den Datenverkehr in den Backup-Pfad, wodurch der Pfad geschützt wird. Ein nicht farbiger Segment-Routing-LSP kann eine Metrik für [edit protocols source-packet-routing source-routing-path lsp-name]
seine Eingangs- und Bindungs-SID-Routen angeben. Mehrere nicht farbige Segment-Routing-LSPs haben dieselbe Zieladresse, die zum nächsten Hop der Eingangsroute beiträgt.
Mehrere nicht farbige Segment-Routing-LSPs haben dieselbe Zieladresse, die zum nächsten Hop der Eingangsroute beiträgt. Jeder primäre oder sekundäre Pfad jedes Segment-Routing-LSP wird als Gateway-Kandidat betrachtet, wenn der Pfad funktionell ist und der Segment-Routing-LSP die beste Wahl all dieser Segment-Routing-LSPs hat. Die maximale Anzahl von Gateways, die der nächste Hop halten kann, darf jedoch die RPD-Grenze für mehrere Pfade nicht überschreiten, die standardmäßig 128 beträgt. Zusätzliche Pfade werden beschnitten, zuerst sekundäre Pfade und dann primäre Pfade. Eine bestimmte Segmentliste kann von diesen Segment-Routing-LSPs mehrfach als primäre oder sekundäre Pfade bezeichnet werden. In diesem Fall gibt es mehrere Gateways, die jeweils eine eindeutige Segment-Routing-LSP-Tunnel-ID haben. Diese Gateways sind unterschiedlich, obwohl sie den gleichen ausgehenden Label-Stack und dieselbe Schnittstelle haben. Ein nicht farbiger Segment-Routing-LSP und ein farbiger Segment-Routing-LSP können auch die gleiche Zieladresse haben. Sie entsprechen jedoch verschiedenen Zieladressen für Eingangsrouten, da die Farbadresse des Segment-Routing-LSP sowohl mit ihrer Zieladresse als auch mit ihrer Farbe erstellt wird.
Wenn ein statischer, nicht farbiger Segment-Routing-LSP und ein von PCEP erstelltes Segment-Routing-LSP zusammen existieren und dieselbe Adressierung haben, die zur gleichen Eingangsroute beiträgt, wenn sie auch dieselbe Präferenz haben. Andernfalls wird der Segment-Routing-LSP mit der besten Präferenz für die Route installiert.
Segmentliste der nicht farbigen Segment-Routing-LSPs
Eine Segmentliste besteht aus einer Liste von Hops. Diese Hops basieren auf dem SID-Label oder einer IP-Adresse. Die Anzahl der SID-Label in der Segmentliste sollte die maximale Begrenzung der Segmentliste nicht überschreiten. Die maximale Bindung von Segmentlisten an einen LSP-Tunnel wird von 8 auf 128 erhöht, mit maximal 1000 Tunneln pro System. Pro statischem Segment-Routing-LSP werden maximal 128 primäre Pfade unterstützt. Sie können die maximale Begrenzung der Segmentliste auf [edit protocols source-packet-routing]
Hierarchieebene konfigurieren.
Vor Junos OS Version 19.1R1 musste der erste Hop der Segmentliste eine IP-Adresse einer ausgehenden Schnittstelle sein, und der zweite zu nth Hop konnte SID-Label sein, damit ein nicht farbiger statischer Segment-Routing-LSP nutzbar war. Ab Junos OS Version 19.1R1 gilt diese Anforderung nicht, da der erste Hop der nicht farbigen statischen LSPs jetzt zusätzlich zu DEN IP-Adressen auch SID-Label unterstützt. Mit der Unterstützung des ersten Hop-Label werden MPLS Fast Reroute (FRR) und weighted equal-cost Multipath aktiviert, um die statischen nicht-farbigen Segment-Routing-LSPs zu lösen, ähnlich wie farbige statische LSPs.
Damit der First-Hop-Label-Modus wirksam wird, müssen Sie die inherit-label-nexthops
Anweisung global oder einzeln für eine Segmentliste einschließen, und der erste Hop der Segmentliste muss sowohl IP-Adresse als auch Label enthalten. Wenn der erste Hop nur die IP-Adresse enthält, hat die inherit-label-nexthops
Anweisung keine Auswirkungen.
Sie können in jeder der folgenden Hierarchien konfigurieren inherit-label-nexthops
. Die inherit-label-nexthops
Anweisung wird nur wirksam, wenn der erste Hop der Segmentliste sowohl IP-Adresse als auch Label enthält.
-
Segment list level– Auf
[edit protocols source-packet-routing segment-list segment-list-name]
Hierarchieebene. -
Globally– Auf
[edit protocols source-packet-routing]
Hierarchieebene.
Wenn die inherit-label-nexthops
Anweisung global konfiguriert ist, hat sie Vorrang vor der Konfiguration auf Segmentlistenebene, und die inherit-label-nexthops
Konfiguration wird auf alle Segmentlisten angewendet. Wenn die inherit-label-nexthops
Anweisung nicht global konfiguriert ist, werden nur Segmentlisten mit beiden Labeln und IP-Adresse im ersten Hop und mit inherit-label-nexthops
Anweisung konfiguriert, mithilfe von SID-Labeln aufgelöst.
Bei dynamischen, nicht farbigen statischen LSPs, also den PCEP-gesteuerten Segment-Routing-LSPs, muss die inherit-label-nexthops
Anweisung global aktiviert werden, da die Konfiguration auf Segmentebene nicht angewendet wird.
Tabelle 4 beschreibt den Modus des Segment-Routing-LSP-Auflösung basierend auf der ersten Hop-Spezifikation.
Erste Hop-Spezifikation |
Modus der LSP-Auflösung |
---|---|
Nur IP-Adresse Zum Beispiel: segment-list path-1 { hop-1 ip-address 172.16.12.2; hop-2 label 1000012; hop-3 label 1000013; hop-4 label 1000014; } |
Die Segmentliste wird über die IP-Adresse aufgelöst. |
Nur SID Zum Beispiel: segment-list path-2 { hop-1 label 1000011; hop-2 label 1000012; hop-3 label 1000013; hop-4 label 1000014; } |
Die Segmentliste wird mithilfe von SID-Labeln aufgelöst. |
IP-Adresse und SID (ohne Zum Beispiel: segment-list path-3 { hop1 { label 801006; ip-address 172.16.1.2; } hop-2 label 1000012; hop-3 label 1000013; hop-4 label 1000014; } |
Standardmäßig wird die Segmentliste über die IP-Adresse aufgelöst. |
IP-Adresse und SID (mit der Zum Beispiel: segment-list path-3 { inherit-label-nexthops; hop1 { label 801006; ip-address 172.16.1.2; } hop-2 label 1000012; hop-3 label 1000013; hop-4 label 1000014; } |
Die Segmentliste wird mithilfe von SID-Labeln aufgelöst. |
Sie können den show route ip-address protocol spring-te active-path table inet.3
Befehl verwenden, um die nicht farbigen Datenverkehrs-LSPs für Segment-Routing anzuzeigen, die mehrere Segmentlisten in der Routingtabelle inet.3 installiert haben.
Zum Beispiel:
user@host> show route 10.7.7.7 protocol spring-te active-path table inet.3 inet.3: 42 destinations, 59 routes (41 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 10.7.7.7/32 *[SPRING-TE/8] 00:01:25, metric 1, metric2 0 > to 10.11.1.2 via et-0/0/0.1, Push 801007 to 10.21.1.2 via et-0/0/2.1, Push 801007 to 10.102.1.2 via et-0/0/0.2, Push 801007, Push 801002(top) to 10.21.1.2 via et-0/0/2.2, Push 801007, Push 801005(top) to 10.103.1.2 via et-0/0/0.3, Push 801007, Push 801003(top) to 10.203.1.2 via et-0/0/2.3, Push 801007, Push 801006(top) to 10.104.1.2 via et-0/0/0.4, Push 801007, Push 801003, Push 801002(top) to 10.204.1.2 via et-0/0/2.4, Push 801007, Push 801006, Push 801005(top)
Der erste Hop-Typ von Segmentlisten eines statischen Segment-Routing-LSP kann dazu führen, dass ein Commit fehlschlägt, wenn:
-
Verschiedene Segmentlisten eines Tunnels haben unterschiedliche Arten der ersten Hop-Auflösung. Dies gilt sowohl für gefärbte als auch für nicht farbige statische Segment-Routing-LSPs. Dies gilt jedoch nicht für PCEP-gestützte LSPs; wird eine Systemprotokollmeldung für die Mismatch im ersten Hop-Auflösungstyp zum Zeitpunkt der Berechnung des Pfads generiert.
Zum Beispiel:
segment-list path-1 { hop-1 ip-address 172.16.12.2; hop-2 label 1000012; hop-3 label 1000013; hop-4 label 1000014; } segment-list path-2 { hop-1 label 1000011; hop-2 label 1000012; hop-3 label 1000013; hop-4 label 1000014; } source-routing-path lsp1 { to 172.16.10.1; primary { path-1; path-2; } }
Der Commit des Tunnels lsp1 schlägt fehl, da Path-1 im IP-Adressmodus und Path-2 im Label-Modus ist.
-
Die Bindungs-SID ist für den statischen nicht farbigen LSP aktiviert, dessen Segmentlistentyp SID-Label ist.
Zum Beispiel:
segment-list path-3 { hop-1 label 1000011; hop-2 label 1000012; hop-3 label 1000013; hop-4 label 1000014; } source-routing-path lsp1 { to 172.16.10.1; binding-sid 333; primary { path-3; } }
Die Konfiguration der SID-Bindung über Label-Segmentliste wird nur für farbige statische LSPs und nicht für farbfreie statische LSPs unterstützt.
Statische Segment-Routing LSP-Bereitstellung
Die Segmentbereitstellung erfolgt auf Routerbasis. Für ein bestimmtes Segment auf einem Router wird ein eindeutiges SID-Label (Unique Service Identifier) aus einem gewünschten Label-Pool zugewiesen, der aus dem dynamischen Label-Pool für ein SID-Label mit Adjacency oder aus dem Segment Routing Global Block (SRGB) für ein Sid- oder Node-SID-Präfix stammen kann. Das Adjacency-SID-Label kann dynamisch zugewiesen werden, was das Standardverhalten ist, oder aus einem lokalen statischen Label-Pool (SRLB) zugewiesen werden. Eine Route für das SID-Label wird dann in der Tabelle mpls.0 installiert.
Junos OS ermöglicht statisches Segment-Routing-LSPs durch Konfiguration der segment
Anweisung auf [edit protocols mpls static-label-switched-path static-label-switched-path]
Hierarchieebene. Ein statischer Segment-LSP wird durch ein eindeutiges SID-Label identifiziert, das unter den statischen Label-Pool von Junos OS fällt. Sie können den statischen Labelpool von Junos OS konfigurieren, indem Sie die static-label-range static-label-range
Anweisung auf [edit protocols mpls label-range]
Hierarchieebene konfigurieren.
Einschränkungen statischer Segment-Routing-LSP
-
Junos OS hat derzeit eine Einschränkung, dass der nächste Hop nicht so aufgebaut werden kann, dass mehr als die Label für die maximale Segment-Listentiefe übertragen werden können. Daher ist eine Segmentliste mit mehr als den maximalen SID-Labeln (mit Ausnahme des SID-Labels des ersten Hops, das zur Auflösung der Weiterleitung am nächsten Hop verwendet wird) für farbige oder nicht-farbige Segment-Routing-LSPs nicht geeignet. Außerdem kann die tatsächliche Anzahl für einen bestimmten Segment-Routing-LSP noch niedriger als die maximale Grenze sein, wenn sich ein MPLS-Service auf dem Segment-Routing-LSP oder der Segment-Routing-LSP auf einem Link- oder Node-Schutzpfad befindet. In allen Fällen darf die Gesamtzahl der Service-Label, SID-Label und Link- oder Node-Schutzetiketten die maximale Segmentlistentiefe nicht überschreiten. Sie können die maximale Begrenzung der Segmentlisten auf
[edit protocols source-packet-routing]
Hierarchieebene konfigurieren. Mehrere nicht farbige Segment-Routing-LSPs mit weniger oder gleich den maximalen SID-Labeln können zusammengefügt werden, um einen längeren Segment-Routing-LSP zu erstellen. Dies wird als Segment-Routing-LSP-Stitching bezeichnet. Dies kann mit bindungs-SID-Label erreicht werden. -
Das Segment-Routing-LSP-Stitching wird tatsächlich auf Pfadebene durchgeführt. Wenn ein nicht farbiger Segment-Routing-LSP mehrere Pfade mit mehreren Segmentlisten hat, kann jeder Pfad unabhängig voneinander mit einem anderen nicht-farbigen Segment-Routing-LSP an einem Stitching-Punkt zusammengefügt werden. Ein nicht farbiger Segment-Routing-LSP, der dem Stitching gewidmet ist, kann die Installation des Eingangsrouten deaktivieren, indem es eine Anweisung auf
[edit protocols source-packet-routing source-routing-path lsp-name]
Hierarchieebene konfiguriertno-ingress
. -
Pro nicht farbigen statischen Segment-Routing-LSP werden maximal 128 primäre Pfade und 1 sekundärer Pfad unterstützt. Wenn eine Konfigurationsverletzung vorliegt, schlägt die Commit-Prüfung mit einem Fehler fehl.
-
Die maximale Bindung von Segmentlisten an einen LSP-Tunnel wird von 8 auf 128 erhöht, mit maximal 1000 Tunneln pro System. Pro statischem Segment-Routing-LSP werden maximal 128 primäre Pfade unterstützt. Als Einschränkung beträgt die maximale Sensorunterstützung für LSP-Pfad nur 32000.
-
Wenn eine Segmentliste mit mehr Labeln als die maximale Segmentlistentiefe konfiguriert ist, schlägt die Konfigurations-Commit-Prüfung mit einem Fehler fehl.
Dynamische Erstellung von Segment-Routing-LSPs
In Segment-Routing-Netzwerken, in denen jedes Provider-Edge-Gerät (PE) mit jedem anderen PE-Gerät verbunden ist, ist für die Einrichtung der Segment-Routing-Label-Switched Paths (LSPs) eine große Anzahl an Konfigurationen erforderlich, obwohl nur wenige SR-TE-Pfade (Segment Routing Traffic Engineered) verwendet werden dürfen. Sie können BGP-trigerred dynamische Erstellung dieser LSPs aktivieren, um den Konfigurationsaufwand in solchen Bereitstellungen zu reduzieren.
- Konfiguration dynamischer Segment-Routing-LSP-Vorlage
- Auflösung dynamischer Segment-Routing-LSPs
- Überlegungen zur Konfiguration der dynamischen Erstellung von Segment-Routing-LSPs
- Services, die über dynamische Segment-Routing-LSPs unterstützt werden
- Verhalten mit mehreren Tunnelquellen im Segment-Routing
- Einschränkungen für dynamisches Segment-Routing-LSPs
Konfiguration dynamischer Segment-Routing-LSP-Vorlage
Um die Vorlage für die dynamische Erstellung von Segment-Routing-LSPs zu konfigurieren, müssen Sie die spring-te-Anweisung in der [edit routing-options dynamic-tunnels]
Hierarchie einschließen.
-
Im Folgenden ist eine Beispielkonfiguration für farbdynamische Segment-Routing-LSP-Vorlage:
[edit routing-options] dynamic-tunnels { <dynamic-tunnel-name> { spring-te { source-routing-path-template { <template-name1> color [c1 c2]; <template-name2> color [c3]; <template-name3> color-any; } destination-networks { <dest1>; <dest2>; } } } }
-
Im Folgenden wird eine Beispielkonfiguration für nicht farbliche dynamische Segment-Routing-LSP-Vorlage dargestellt:
dynamic-tunnels { <dynamic-tunnel-name> { spring-te { source-routing-path-template { <template-name1>; } destination-networks { <dest1>; <dest2>; } } } }
Auflösung dynamischer Segment-Routing-LSPs
Auflösung farbiger dynamischer Segment-Routing-LSP
Wenn den BGP-Präfixen color community zugewiesen wird, werden sie zunächst über die Catch-all-route-for-that-color-Richtlinie aufgelöst, und wiederum wird die SR-TE-Vorlage identifiziert, in der das BGP-Präfix aufgelöst werden soll. Die Ziel-SID wird dann aus dem BGP-Payload-Prefix-Next-Hop-Attribut abgeleitet. Wenn beispielsweise der nächste Hop des BGP-Nutzpräfixes eine IP-Adresse ist, die zu Gerät A gehört, wird die Node-SID von Gerät A genommen, und ein entsprechendes Label wird vorbereitet und an den unteren Rand des Stacks verschoben. Das BGP-Nutzpräfix wird in einem nur farbbasierten Modus aufgelöst, wobei sich die Node-SID von Gerät A am unteren Rand des endgültigen Labelstacks befindet und die SR-TE-Pfadbezeichnungen oben sind.
Der endgültige LSP-Vorlagenname ist eine Kombination aus Präfix, Farbe und Tunnelname. zum Beispiel <prefix>:<color>:dt-srte-<tunnel-name>
. Die Farbe im LSP-Namen wird im hexadezimalen Format angezeigt, und das Format des Tunnelnamens ähnelt dem von RSVP ausgelösten Tunnel-LSP-Namen.
Um ein farbiges Zielnetzwerk erfolgreich zu lösen, sollte die Farbe eine gültige Vorlagenzuordnung haben, entweder zu einer bestimmten Farbe oder über die color-any
Vorlage. Ohne gültige Zuordnung wird der Tunnel nicht erstellt, und die zur Lösung angeforderte BGP-Route bleibt ungelöst.
Auflösung unfarbiger dynamischer Segment-Routing-LSPs
Die Catch-All-Routen für nicht farbige LSPs werden zur Routingtabelle inet.3 hinzugefügt. Das nicht farbige Tunnelziel muss in einer anderen spring-te
Konfiguration mit nur einem Vorlagennamen in der Zuordnungsliste konfiguriert werden. Dieser Vorlagenname wird für alle Tunnelrouten verwendet, die mit jedem der Zielnetzwerke übereinstimmen, die unter derselben spring-te
Konfiguration konfiguriert sind. Diese Tunnel ähneln den RSVP-Tunneln in ihrer Funktionalität.
Der endgültige Name der LSP-Vorlage ist eine Kombination aus Prefix und Tunnelname. zum Beispiel <prefix>:dt-srte-<tunnel-name>
.
Dynamische Segment-Routing-LSP-Beispielkonfiguration
Die dynamische Segment-Routing-LSP-Vorlage enthält immer einen teilweisen Pfad. Die SID des letzten Hop-Knotens wird automatisch zum Zeitpunkt der Tunnelerstellung abgeleitet, abhängig von der Protokoll-Next-Hop-Adresse (PNH)-Knoten-SID. Dieselbe Vorlage kann von mehreren Tunneln zu verschiedenen Zielen verwendet werden. In solchen Fällen bleibt der partielle Pfad gleich, und nur der letzte Hop ändert sich je nach PNH. Dynamische Segment-Routing-LSP-Vorlagen sind nicht für einen einzigen Tunnel gemein, daher kann kein vollständiger Pfad darauf ausgeführt werden. Sie können eine Segmentliste verwenden, wenn ein vollständiger Pfad verwendet werden soll.
Farbige, dynamische Segment-Routing-LSPs
Beispielkonfiguration für farbige dynamische Segment-Routing-LSPs:
protocols source-packet-routing { source-routing-path-template sr_lsp1 { primary sr_sl1 primary sr_sl2 weight 2 sr-preference 180; } } dynamic-tunnels tunnel1 { spring-te { source-routing-path-template { sr_lsp1 color [ 123 124 125 ]; sr_lsp2 color-any } destination-networks { 10.22.44.0/24; } } }
Für die oben genannte Beispielkonfiguration sind die Routeneinträge wie folgt:
-
inetcolor.0 tunnel route: 10. 22.44.0-0/24 --> RT_NH_TUNNEL
-
inetcolor6.0 tunnel route: ffff::10. 22.44.0-0/120 --> RT_NH_TUNNEL
-
BGP prefix to tunnel mapping:
R1(prefix) -> 10. 22.44.55-101(PNH) LSP-Tunnelname = 10. 22.44.55:65:dt-srte-tunnel1
R1(prefix) -> ffff::10. 22.44.55-101(PNH) LSP-Tunnelname = 10. 22.44.55:65:dt-srte-tunnel1
R1(prefix) -> ffff::10. 22.44.55-124(PNH) LSP-Tunnelname = 10. 22.44.55:7c:dt-srte-tunnel1
-
inetcolor.0 tunnel route:
10. 22.44.55-101/64 --> <next-hop>
10. 22.44.55-124/64 --> <next-hop>
-
inetcolor6.0 tunnel route:
ffff::10. 22.44.55-101/160 --> <next-hop>
ffff::10. 22.44.55-124/160 --> <next-hop>
Nicht-farbige dynamische Segment-Routing-LSPs
Beispielkonfiguration für nicht farbige dynamische Segment-Routing-LSPs:
protocols source-packet-routing { source-routing-path-template sr_lsp1 { primary sr_sl1 primary sr_sl2 weight 2 sr-preference 180; } } dynamic-tunnels { tunnel1 { spring-te { source-routing-path-template { sr_lsp1 color [ 101 ]; } destination-networks { 10.33.44.0/24; } } } tunnel2 { spring-te { source-routing-path-template { sr_lsp1; } destination-networks { 10.33.44.0/24; } } } }
Für die oben genannte Beispielkonfiguration sind die Routeneinträge wie folgt:
-
inet.3 tunnel route: 10.33.44.0/24 --> RT_NH_TUNNEL
-
inet6.3 tunnel route: ffff::10.33.44.0/120 --> RT_NH_TUNNEL
-
BGP prefix to tunnel mapping:
R1(prefix) -> 10.33.44.55(PNH) LSP-Vorlagenname = LSP1 --- 10.33.44.55:dt-srte-tunnel2
R1(prefix) -> ffff::10.33.44.55(PNH) LSP-Vorlagenname = LSP1 --- 10.33.44.55:dt-srte-tunnel2
-
inet.3 tunnel route: 10.33.44.55/32 --> <nächsten Hop>
-
inet6.3 tunnel route: ffff::10.33.44.55/128 --> <next-hop>
Ungelöste dynamische Segment-Routing-LSP
Beispielkonfiguration für nicht gelöste dynamische Segment-Routing-LSPs:
protocols source-packet-routing { source-routing-path-template sr_lsp1 { primary sr_sl1 primary sr_sl2 weight 2 sr-preference 180; } } dynamic-tunnels tunnel1 { spring-te { source-routing-path-template { sr_lsp1 color [120 121 122 123]; } destination-networks { 10.33.44.0/24; 10.1.1.0/24; } } }
Für die oben genannte Beispielkonfiguration sind die Routeneinträge wie folgt:
-
inetcolor.0 tunnel route: 10.33.44.0 - 0/24 --> RT_NH_TUNNEL 10.1.1.0 - 0 /24 --> RT_NH_TUNNEL
-
inetcolor6.0 tunnel route: ffff::10.33.44.0 - 0/120 --> RT_NH_TUNNEL ffff::10.1.0 - 0/24 --> RT_NH_TUNNEL
-
BGP prefix to tunnel mapping: R1(prefix) -> 10.33.44.55-124(PNH) Tunnel wird nicht erstellt. (Vorlage für die Farbe nicht gefunden).
Überlegungen zur Konfiguration der dynamischen Erstellung von Segment-Routing-LSPs
Berücksichtigen Sie bei der Konfiguration der dynamischen Erstellung von Segment-Routing-LSPs Folgendes:
-
Einer Vorlage kann ein Farbobjekt zugewiesen werden. Wenn die dynamische Tunnelkonfiguration
spring-te
eine Vorlage mit einem Farbobjekt enthält, müssen Sie alle anderen Vorlagen auch mit Farbobjekten konfigurieren. Es wird angenommen, dass alle Ziele innerhalb dieser Konfiguration gefärbt sind. -
Eine Vorlage kann eine Liste von Farben darauf definiert haben oder mit der
color-any
Option konfiguriert werden. Beide Optionen können in derselbenspring-te
Konfiguration koexistieren. In solchen Fällen haben Vorlagen, die bestimmten Farben zugewiesen sind, eine höhere Präferenz. -
In einer
spring-te
Konfiguration kann mit dercolor-any
Option nur eine Vorlage definiert werden. -
Die Zuordnung von Farbe zu Vorlage erfolgt auf Eins-zu-Eins-Basis. Eine Farbe kann nicht mehreren Vorlagen zuordnen.
-
Der Vorlagenname sollte in der
spring-te
Anweisung unter der[edit protocols]
Hierarchie konfiguriert werden und dieprimary
Option aktiviert haben. -
Farbige und nicht farbige Ziele können nicht in derselben
spring-te
Konfiguration koexistiert werden. -
Sie können dieselben Zielnetzwerke nicht mit oder ohne Farbe unter verschiedenen
spring-te
Konfigurationsanweisungen konfigurieren. -
In einer nicht farbigen
spring-te
Konfiguration kann nur eine Vorlage ohne Farbobjekt konfiguriert werden.
Services, die über dynamische Segment-Routing-LSPs unterstützt werden
Die folgenden Services werden über farbige dynamische Segment-Routing-LSPs unterstützt:
-
Layer 3-VPN
-
BGP EVPN
-
Richtlinien-Services exportieren
Die folgenden Services werden über nicht farbige dynamische Segment-Routing-LSPs unterstützt:
-
Layer 3-VPN
-
Layer 2-VPN
-
Multipath-Konfigurationen
Verhalten mit mehreren Tunnelquellen im Segment-Routing
Wenn zwei Quellen Routen vom Segment-Routing zum selben Ziel herunterladen (z. B. statische und dynamische Quelltunnel), wird die bevorzugte Segment-Routing-Option für die Auswahl des aktiven Routeneintrags verwendet. Ein höherer Wert hat eine größere Präferenz. Falls die Präferenz gleich bleibt, wird die Tunnelquelle verwendet, um den Routeneintrag zu bestimmen.
Einschränkungen für dynamisches Segment-Routing-LSPs
Die dynamischen SR-TE-LSPs unterstützen die folgenden Funktionen und Funktionen nicht:
-
IPv6-Segment-Routing-Tunnel.
-
Statische Tunnel.
-
6PE wird nicht unterstützt.
-
Verteilte CSPF.
-
sBFD- und LDP-Tunnelling wird für dynamische SR-TE-LSPs und in einer Vorlage nicht unterstützt.
-
Installieren und B-SID-Routen in einer Vorlage.
Farbbasierte Zuordnung von VPN-Services
Sie können Farbe als Protokoll-Next-Hop-Einschränkung (zusätzlich zur IPv4- oder IPv6-Adresse) für die Auflösung von Transporttunneln über statisch farbige und BGP Segment Routing Traffic-Engineered (SR-TE)-LSPs angeben. Dies wird als Color-IP-Protokoll Next Hop-Auflösung bezeichnet, wo Sie eine Auflösungskarte konfigurieren und auf die VPN-Services anwenden müssen. Mit dieser Funktion können Sie eine farbbasierte Datenverkehrssteuerung von Layer-2- und Layer-3-VPN-Services ermöglichen.
Junos OS unterstützt farbige SR-TE-LSPs , die mit einer einzigen Farbe verknüpft sind. Die farbbasierte Zuordnung von VPN-Services wird auf statischen farbigen LSPs und BGP SR-TE-LSPs unterstützt.
- VPN-Service-Coloring
- Festlegen des VPN-Servicezuordnungsmodus
- Color-IP Protocol Next Hop-Auflösung
- Fallback zum IP-Protokoll Next Hop-Lösung
- BGP-gekennzeichnete Unicast-farbbasierte Zuordnung über SR-TE
- Unterstützte und nicht unterstützte Funktionen für farbbasierte Zuordnung von VPN-Services
VPN-Service-Coloring
Im Allgemeinen kann einem VPN-Dienst eine Farbe auf dem Ausgangsrouter zugewiesen werden, auf dem das VPN NLRI angekündigt wird, oder auf einem Eingangsrouter, bei dem das VPN NLRI empfangen und verarbeitet wird.
Sie können den VPN-Services auf verschiedenen Ebenen eine Farbe zuweisen:
-
Pro Routing-Instanz.
-
Pro BGP-Gruppe.
-
Pro BGP-Nachbarn.
-
Pro Präfix.
Sobald Sie eine Farbe zugewiesen haben, wird die Farbe an einen VPN-Service in Form einer BGP Color Extended Community angehängt.
Sie können einem VPN-Service, den sogenannten mehrfarbigen VPN-Services, mehrere Farben zuweisen. In solchen Fällen wird die letzte Farbe als Farbe des VPN-Dienstes betrachtet, und alle anderen Farben werden ignoriert.
Mehrere Farben werden von Eingangs- und/oder Eingangsgeräten über mehrere Richtlinien in der folgenden Reihenfolge zugewiesen:
-
BGP-Exportrichtlinie auf dem Ausgangsgerät.
-
BGP-Importrichtlinie auf dem Eingangsgerät.
-
VRF-Importrichtlinie auf dem Eingangsgerät.
Die beiden Modi des VPN-Service-Coloring sind:
Ausgangsfarbzuweisung
In diesem Modus ist das Ausgangsgerät (d. h. der Werbetreibende des VPN NLRI) für die Farbgebung des VPN-Dienstes verantwortlich. Um diesen Modus zu aktivieren, können Sie eine Routing-Richtlinie definieren und sie in der Routing-Instanz vrf-export
, dem Gruppenexport oder dem [edit protocols bgp]
Gruppennachbar-Export des VPN-Service auf Hierarchieebene anwenden. Das VPN NLRI wird von BGP mit der angegebenen Farb-erweiterten Community beworben.
Zum Beispiel:
[edit policy-options] community red-comm { members color:0:50; }
[edit policy-options] policy-statement pol-color { term t1 { from { [any match conditions]; } then { community add red-comm; accept; } } }
[edit routing-instances] vpn-X { ... vrf-export pol-color ...; }
Oder
Wenn Sie die Routingrichtlinie als Exportrichtlinie einer BGP-Gruppe oder eines BGP-Nachbarn anwenden, müssen Sie die vpn-apply-export
Anweisung auf BGP-, BGP-Gruppen- oder BGP-Nachbarschaftsebene einschließen, damit die Richtlinie auf die VPN-NLRI wirkt.
[edit protocols bgp] group PEs { ... neighbor PE-A { export pol-color ...; vpn-apply-export; } }
Die Routing-Richtlinien werden auf Layer-3-VPN-Präfix-NLRIs, Layer-2-VPN-NRLIs und EVPN-NLRIs angewendet. Die Color Extended Community wird von allen VPN-Routen geerbt, importiert und in den Ziel-VRFs auf einem oder mehreren Eingangsgeräten installiert.
Eingangsfarbzuweisung
In diesem Modus ist das Eingangsgerät (d. h. der Empfänger des VPN NLRI) für das Coloring des VPN-Dienstes verantwortlich. Um diesen Modus zu aktivieren, können Sie eine Routing-Richtlinie definieren und sie auf die Routing-Instanz vrf-import
, den Gruppenimport oder den [edit protocols bgp]
Gruppennachbarnimport des VPN-Dienstes auf Hierarchieebene anwenden. Alle VPN-Routen, die der Routing-Richtlinie entsprechen, werden mit der angegebenen farblichen erweiterten Community verbunden.
Zum Beispiel:
[edit routing-options] community red-comm { members color:0:50; }
[edit policy-options] policy-statement pol-color { term t1 { from { [any match conditions]; } then { community add red-comm; accept; } } }
[edit routing-instances] vpn-Y { ... vrf-import pol-color ...; }
Oder
[edit protocols bgp] group PEs { ... neighbor PE-B { import pol-color ...; } }
Festlegen des VPN-Servicezuordnungsmodus
Um flexible VPN-Dienstzuordnungsmodi anzugeben, müssen Sie mithilfe der resolution-map
Anweisung eine Richtlinie definieren und die Richtlinie in der Routing-Instanz vrf-import
, dem Gruppenimport oder dem [edit protocols bgp]
Gruppennachbarimport eines VPN-Service auf Hierarchieebene verweisen. Alle VPN-Routen, die der Routing-Richtlinie entsprechen, sind mit der angegebenen Auflösungskarte verbunden.
Zum Beispiel:
[edit policy-options] resolution-map map-A { <mode-1>; <mode-2>; ... } policy-statement pol-resolution { term t1 { from { [any match conditions]; } then { resolution-map map-A; accept; } } }
Sie können eine Importrichtlinie auf die Routing-Instanz des VPN-Service anwenden.
[edit routing-instances] vpn-Y { ... vrf-import pol-resolution ...; }
Sie können die Importrichtlinie auch auf eine BGP-Gruppe oder einen BGP-Nachbarn anwenden.
[edit protocols bgp] group PEs { ... neighbor PE-B { import pol-resolution ...; } }
Jeder VPN-Servicezuordnungsmodus sollte einen eindeutigen Namen haben, der in der Auflösungskarte definiert ist. In der Auflösungskarte wird nur ein einzelner Eintrag von IP-Color unterstützt, wobei die VPN-Route(n) mit einem farbigen IP-Protokoll in Form von ip-address:color
.
Color-IP Protocol Next Hop-Auflösung
Der Protokoll-Next-Hop-Auflösungsprozess wurde erweitert, um die Auflösung des Colored-IP-Protokolls next Hop zu unterstützen. Für einen farbigen VPN-Service nimmt der Prozess zur Auflösung des Protokolls next Hop eine Farbe und eine Auflösungszuordnung an, erstellt ein farbiges IP-Protokoll in Form von IP-address:colorund löst das Protokoll als nächsten Hop in der Routingtabelle inet6color.0 auf.
Sie müssen eine Richtlinie konfigurieren, um die Multipath-Auflösung von farbigen Layer-2-VPN-, Layer-3-VPN- oder EVPN-Services über farbige LSPs zu unterstützen. Die Richtlinie muss dann mit der entsprechenden RIB-Tabelle als Importrichtlinie für den Resolver angewendet werden.
Zum Beispiel:
[edit policy-options] policy-statement mpath { then multipath-resolve; }
[edit routing-options] resolution { rib bgp.l3vpn.0 { inetcolor-import mpath; } } resolution { rib bgp.l3vpn-inet6.0 { inet6color-import mpath; } } resolution { rib bgp.l2vpn.0 { inetcolor-import mpath; } } resolution { rib mpls.0 { inetcolor-import mpath; } } resolution { rib bgp.evpn.0 { inetcolor-import mpath; } }
Fallback zum IP-Protokoll Next Hop-Lösung
Wenn für einen farbigen VPN-Service keine Auflösungszuordnung angewendet wird, ignoriert der VPN-Dienst seine Farbe und fällt auf die IP-Protokoll-Next-Hop-Auflösung zurück. Umgekehrt, wenn für einen nicht farbigen VPN-Service eine Auflösungskarte angewendet wird, wird die Auflösungskarte ignoriert, und der VPN-Service verwendet das IP-Protokoll next Hop-Auflösung.
Das Fallback ist ein einfacher Prozess von farbigen SR-TE-LSPs zu LDP-LSPs, indem eine RIB-Gruppe für LDP verwendet wird, um Routen in inet{6}color.0-Routing-Tabellen zu installieren. Eine längste Prefix-Übereinstimmung für einen colored-IP-Protokoll next Hop stellt sicher, dass eine LDP-Route mit einer übereinstimmenden IP-Adresse zurückgegeben werden sollte, wenn keine farbige SR-TE LSP-Route vorhanden ist.
BGP-gekennzeichnete Unicast-farbbasierte Zuordnung über SR-TE
Ab Junos OS Version 20.2R1 kann BGP Labeled Unicast (BGP-LU) IPv4- oder IPv6-Routen über Segment Routing–Traffic Engineering (SR-TE) für IPv4- und IPv6-Adressfamilien auflösen. BGP-LU unterstützt die Zuordnung einer BGP-Community-Farbe und die Definition eines resolution map
für SR-TE. Ein farbiges Protokoll des nächsten Hops wird erstellt und in einem farbigen SR-TE-Tunnel in der inetcolor.0
Tabelle inet6color.0
aufgelöst. BGP-Verwendungen inet.3
und inet6.3
-Tabellen für nicht farbbasierte Zuordnung. Auf diese Weise können Sie BGP-LU-IPv6- und IPv4-Präfixe mit einer IPv6-Next-Hop-Adresse in Nur-IPv6-Netzwerken bekannt geben, in denen Router keine IPv4-Adressen konfiguriert haben. Mit dieser Funktion unterstützen wir derzeit BGP IPv6 LU über SR-TE mit IS-IS-Underlay.
In Abbildung 9konfiguriert der Controller 4 farbige Tunnel in einem IPv6-Core-Netzwerk, das mit SR-TE konfiguriert ist. Jeder farbige Tunnel nimmt je nach definierter Auflösungskarte einen anderen Pfad zum Zielrouter D. Der Controller konfiguriert einen farbigen SR-TE-Tunnel zu 2001:db8::3701:2d05-Schnittstelle in Router D . BGP importiert Richtlinien, um dem empfangenen Präfix 2001:db8::3700:6/128 eine Farb- und Auflösungszuordnung zuzuweisen. Basierend auf der zugewiesenen Community-Farbe löst BGP-LU den farbigen nächsten Hop für BGP IPv6 LU-Präfix gemäß der zugewiesenen Auflösungszuordnungsrichtlinie auf.

BGP-LU unterstützt die folgenden Szenarien:
-
BGP IPv4 LU über BGP IPv4 SR-TE mit ISIS/OSPF IPv4 SR-Erweiterungen.
-
BGP IPv4 LU über statisch gefärbtes und nicht farbiges IPv4 SR-TE mit ISIS/OSPF IPv4 SR-Erweiterungen.
-
BGP IPv6 LU über BGP IPv6 SR-TE mit ISIS IPv6 SR-Erweiterungen.
-
BGP IPv6 LU über statisch gefärbtes und nicht farbiges IPv6 SR-TE mit ISIS IPv6 SR-Erweiterungen.
-
IPv6 Layer 3 VPN-Services mit lokaler IPv6-Adresse und IPv6-Nachbarnadresse.
-
IPv6 Layer 3 VPN-Services über BGP IPv6 SR-TE, mit ISIS IPv6 SR-Erweiterungen.
-
IPv6 Layer 3 VPN-Services über statisch gefärbtes und nicht farbiges IPv6 SR-TE mit ISIS IPv6-SR-Erweiterungen.
Unterstützte und nicht unterstützte Funktionen für farbbasierte Zuordnung von VPN-Services
Die folgenden Funktionen und Funktionen werden von einer farbbasierten Zuordnung von VPN-Services unterstützt:
-
BGP Layer 2 VPN (Kompella Layer 2 VPN)
-
BGP EVPN
-
Auflösungskarte mit einer einzigen IP-Farboption.
-
Farbiges IPv4- und IPv6-Protokoll next Hop-Auflösung.
-
Routing Information Base (auch Routing-Tabelle genannt) gruppenbasiertes Fallback auf LDP-LSP in der Routing-Tabelle inetcolor.0.
-
Farbiger SR-TE LSP.
-
Virtuelle Plattformen.
-
64-Bit-Junos OS.
-
Logische Systeme.
-
BGP als Unicast gekennzeichnet.
Die folgenden Funktionen und Funktionen werden von der farbbasierten Zuordnung von VPN-Services nicht unterstützt:
-
Farbige MPLS-LSPs, wie RSVP, LDP, BGP-LU, statisch.
-
Layer-2-Circuit
-
FEC-129 BGP automatisch entdeckt und LDP-signalisiert Layer-2-VPN.
-
VPLS
-
MVPN
-
IPv4 und IPv6 mit Resolution-Map.
Tunnelvorlagen für PCE-initiierte Segment-Routing-LSPs
Sie können eine Tunnelvorlage für PCE-initiierte Segment-Routing-LSPs konfigurieren, um zwei zusätzliche Parameter für diese LSPs weiterzugeben: Bidirectional Forwarding Detection (BFD) und LDP-Tunneling.
Wenn ein PCE-initiierter Segment-Routing-LSP erstellt wird, wird der LSP mit Richtlinienanweisungen überprüft (falls vorhanden), und wenn eine Übereinstimmung vorliegt, wendet die Richtlinie die konfigurierte Vorlage für diesen LSP an. Die Vorlagenkonfiguration wird nur übernommen, wenn sie nicht von der LSP-Quelle (PCEP) bereitgestellt wird; zum Beispiel Kennzahl.
So konfigurieren Sie eine Vorlage:
-
Fügen Sie die Source-Routing-Path-Template-Anweisung auf Hierarchieebene
[edit protocols source-packet-routing]
ein. Die zusätzlichen BFD- und LDP-Tunneling-Parameter können Sie hier konfigurieren. -
Fügen Sie die Source-routing-path-template-map-Anweisung auf der
[edit protocols source-packet-routing]
Hierarchieebene ein, um die Richtlinienanweisungen auflisten zu können, mit denen der PCE-initiierte LSP überprüft werden soll. -
Definieren Sie eine Richtlinie zur Liste der LSPs, auf die die Vorlage angewendet werden soll.
Die
from
Anweisung kann entweder den LSP-Namen oder den regulären LSP-Ausdruck mit den Bedingungen undlsp-regex
übereinstimmungenlsp
enthalten. Diese Optionen schließen sich gegenseitig aus, sodass Sie zu einem bestimmten Zeitpunkt nur eine Option angeben können.Die
then
Anweisung muss diesr-te-template
Option mit einer Annahmeaktion enthalten. Dadurch wird die Vorlage auf den PCE-initiierten LSP angewendet.
Berücksichtigen Sie bei der Konfiguration einer Vorlage für PCE-initiierte LSPs Folgendes:
-
Die Vorlagenkonfiguration ist nicht auf statisch konfigurierte Segment-Routing-LSPs oder die Segment-Routing-LSP eines anderen Clients anwendbar.
-
PCEP-bereitgestellte Konfiguration hat Vorrang vor Vorlagenkonfiguration.
-
PCEP-LSP erbt keine Vorlagensegmentlistenkonfiguration.
Beispiel: Konfigurieren von statischem Segment-Routing Label Switched Path
Dieses Beispiel zeigt, wie Sie statisches Segment-Routing-Label Switched Paths (LSPs) in MPLS-Netzwerken konfigurieren. Diese Konfiguration trägt zu einer höheren Skalierbarkeit für MPLS-Netzwerke bei.
Anforderungen
In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:
-
Sieben universelle 5G-Routing-Plattformen der MX-Serie
-
Junos OS Version 18.1 oder höher, die auf allen Routern ausgeführt wird
Stellen Sie sicher, dass Sie die Geräteschnittstellen konfigurieren, bevor Sie beginnen.
Überblick
Junos OS wird eine Reihe expliziter Segment-Routing-Pfade auf dem Eingangsrouter eines nicht farbigen statischen Segment-Routing-Tunnels konfiguriert, indem die segment-list
Anweisung auf [edit protocols source-packet-routing]
Hierarchieebene konfiguriert wird. Sie können den Segment-Routing-Tunnel konfigurieren, indem Sie die source-routing-path
Anweisung auf [edit protocols source-packet-routing]
Hierarchieebene konfigurieren. Der Segment-Routing-Tunnel hat eine Zieladresse und einen oder mehrere primäre Pfade und optional sekundäre Pfade, die auf die Segmentliste verweisen. Jede Segmentliste besteht aus einer Abfolge von Hops. Bei nicht farbigen statischen Segment-Routing-Tunneln gibt der erste Hop der Segmentliste eine unmittelbare IP-Adresse des nächsten Hops an, und der zweite mit Nth Hop gibt die SID-Label (Segment identifiziert) an, die dem Link oder Knoten entsprechen, den der Pfad durchläuft. Die Route zum Ziel des Segment-Routing-Tunnels ist in der Tabelle inet.3 installiert.
Topologie
In diesem Beispiel konfigurieren Sie Layer-3-VPN auf den Provider-Edge-Routern PE1 und PE5. Konfigurieren Sie das MPLS-Protokoll auf allen Routern. Der Segment-Routing-Tunnel wird vom Router PE1 zum Router PE5 mit einem primären Pfad auf Router PE1 und Router PE5 konfiguriert. Router PE1 ist zum Schutz des Pfads auch mit sekundären Pfaden konfiguriert. Die Transit-Router PE2 zu PE4 sind mit Adjacency-SID-Labeln mit Label Pop und einer ausgehenden Schnittstelle konfiguriert.

Konfiguration
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen sie in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, kopieren Sie die Befehle, fügen Sie sie auf Hierarchieebene in die [edit]
CLI ein, und geben Sie dann aus dem Konfigurationsmodus ein commit
.
PE1
set interfaces ge-0/0/0 unit 0 family inet address 10.10.12.1/24 set interfaces ge-0/0/0 unit 0 family mpls maximum-labels 5 set interfaces ge-0/0/1 unit 0 family inet address 10.10.13.1/24 set interfaces ge-0/0/1 unit 0 family mpls maximum-labels 5 set interfaces ge-0/0/5 unit 0 family inet address 10.10.17.1/24 set routing-options autonomous-system 65000 set routing-options forwarding-table export load-balance-policy set routing-options forwarding-table chained-composite-next-hop ingress l3vpn set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols bgp group pe type internal set protocols bgp group pe local-address 192.168.147.211 set protocols bgp group pe family inet-vpn unicast set protocols bgp group pe neighbor 192.168.146.181 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols source-packet-routing segment-list sl-15-primary hop-1 ip-address 10.10.13.3 set protocols source-packet-routing segment-list sl-15-primary hop-2 label 1000134 set protocols source-packet-routing segment-list sl-15-primary hop-3 label 1000145 set protocols source-packet-routing segment-list sl-15-backup hop-1 ip-address 10.10.12.2 set protocols source-packet-routing segment-list sl-15-backup hop-2 label 1000123 set protocols source-packet-routing segment-list sl-15-backup hop-3 label 1000134 set protocols source-packet-routing segment-list sl-15-backup hop-4 label 1000145 set protocols source-packet-routing source-routing-path lsp-15 to 192.168.146.181 set protocols source-packet-routing source-routing-path lsp-15 binding-sid 1000999 set protocols source-packet-routing source-routing-path lsp-15 primary sl-15-primary set protocols source-packet-routing source-routing-path lsp-15 secondary sl-15-backup set policy-options policy-statement VPN-A-export term a from protocol ospf set policy-options policy-statement VPN-A-export term a from protocol direct set policy-options policy-statement VPN-A-export term a then community add VPN-A set policy-options policy-statement VPN-A-export term a then accept set policy-options policy-statement VPN-A-export term b then reject set policy-options policy-statement VPN-A-import term a from protocol bgp set policy-options policy-statement VPN-A-import term a from community VPN-A set policy-options policy-statement VPN-A-import term a then accept set policy-options policy-statement VPN-A-import term b then reject set policy-options policy-statement bgp-to-ospf from protocol bgp set policy-options policy-statement bgp-to-ospf from route-filter 10.10.0.0/16 orlonger set policy-options policy-statement bgp-to-ospf then accept set policy-options policy-statement load-balance-policy then load-balance per-packet set policy-options community VPN-A members target:65000:1 set routing-instances VRF1 instance-type vrf set routing-instances VRF1 interface ge-0/0/5.0 set routing-instances VRF1 route-distinguisher 192.168.147.211:1 set routing-instances VRF1 vrf-import VPN-A-import set routing-instances VRF1 vrf-export VPN-A-export set routing-instances VRF1 vrf-table-label set routing-instances VRF1 protocols ospf export bgp-to-ospf set routing-instances VRF1 protocols ospf area 0.0.0.0 interface ge-0/0/5.0
PE2
set interfaces ge-0/0/0 unit 0 family inet address 10.10.12.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.10.23.2/24 set interfaces ge-0/0/1 unit 0 family mpls set protocols mpls static-label-switched-path adj-23 segment 1000123 set protocols mpls static-label-switched-path adj-23 segment next-hop 10.10.23.3 set protocols mpls static-label-switched-path adj-23 segment pop set protocols mpls static-label-switched-path adj-21 segment 1000221 set protocols mpls static-label-switched-path adj-21 segment next-hop 10.10.12.1 set protocols mpls static-label-switched-path adj-21 segment pop set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
PE3
set interfaces ge-0/0/0 unit 0 family inet address 10.10.13.3/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.10.23.3/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 10.10.34.3/24 set interfaces ge-0/0/2 unit 0 family mpls set protocols mpls static-label-switched-path adj-34 segment 1000134 set protocols mpls static-label-switched-path adj-34 segment next-hop 10.10.34.4 set protocols mpls static-label-switched-path adj-34 segment pop set protocols mpls static-label-switched-path adj-32 segment 1000232 set protocols mpls static-label-switched-path adj-32 segment next-hop 10.10.23.2 set protocols mpls static-label-switched-path adj-32 segment pop set protocols mpls interface ge-0/0/1.0 set protocols mpls interface ge-0/0/2.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
PE4
set interfaces ge-0/0/2 unit 0 family inet address 10.10.34.4/24 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 family inet address 10.10.45.4/24 set interfaces ge-0/0/3 unit 0 family mpls set protocols mpls static-label-switched-path adj-45 segment 1000145 set protocols mpls static-label-switched-path adj-45 segment next-hop 10.10.45.5 set protocols mpls static-label-switched-path adj-45 segment pop set protocols mpls static-label-switched-path adj-43 segment 1000243 set protocols mpls static-label-switched-path adj-43 segment next-hop 10.10.34.3 set protocols mpls static-label-switched-path adj-43 segment pop set protocols mpls interface ge-0/0/2.0 set protocols mpls interface ge-0/0/3.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0
PE5
set interfaces ge-0/0/3 unit 0 family inet address 10.10.45.5/24 set interfaces ge-0/0/3 unit 0 family mpls maximum-labels 5 set interfaces ge-0/0/4 unit 0 family inet address 10.10.56.5/24 set routing-options autonomous-system 65000 set protocols mpls interface ge-0/0/3.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols bgp group pe type internal set protocols bgp group pe local-address 192.168.146.181 set protocols bgp group pe family inet-vpn unicast set protocols bgp group pe neighbor 192.168.147.211 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 set protocols ospf area 0.0.0.0 interface lo0.0 set protocols bfd sbfd local-discriminator 0.0.0.32 minimum-receive-interval 1000 set protocols source-packet-routing segment-list sl-51 hop-1 ip-address 10.10.45.4 set protocols source-packet-routing segment-list sl-51 hop-2 label 1000243 set protocols source-packet-routing segment-list sl-51 hop-3 label 1000232 set protocols source-packet-routing segment-list sl-51 hop-4 label 1000221 set protocols source-packet-routing source-routing-path lsp-51 to 192.168.147.211 set protocols source-packet-routing source-routing-path lsp-51 primary sl-51 set policy-options policy-statement VPN-A-export term a from protocol ospf set policy-options policy-statement VPN-A-export term a from protocol direct set policy-options policy-statement VPN-A-export term a then community add VPN-A set policy-options policy-statement VPN-A-export term a then accept set policy-options policy-statement VPN-A-export term b then reject set policy-options policy-statement VPN-A-import term a from protocol bgp set policy-options policy-statement VPN-A-import term a from community VPN-A set policy-options policy-statement VPN-A-import term a then accept set policy-options policy-statement VPN-A-import term b then reject set policy-options policy-statement bgp-to-ospf from protocol bgp set policy-options policy-statement bgp-to-ospf from route-filter 10.10.0.0/16 orlonger set policy-options policy-statement bgp-to-ospf then accept set policy-options community VPN-A members target:65000:1 set routing-instances VRF1 instance-type vrf set routing-instances VRF1 interface ge-0/0/4.0 set routing-instances VRF1 route-distinguisher 192.168.146.181:1 set routing-instances VRF1 vrf-import VPN-A-import set routing-instances VRF1 vrf-export VPN-A-export set routing-instances VRF1 vrf-table-label set routing-instances VRF1 protocols ospf export bgp-to-ospf set routing-instances VRF1 protocols ospf area 0.0.0.0 interface ge-0/0/4.0
CE1
set interfaces ge-0/0/0 unit 0 family inet address 10.10.17.7/24 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
CE2
set interfaces ge-0/0/4 unit 0 family inet address 10.10.56.6/24 set protocols ospf area 0.0.0.0 interface ge-0/0/4.0
Konfiguration von Geräte-PE1
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie auf verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI-Benutzerhandbuch.
So konfigurieren Sie Geräte-PE1:
-
Konfigurieren Sie die Schnittstellen.
[edit interfaces] set ge-0/0/0 unit 0 family inet address 10.10.12.1/24 set ge-0/0/0 unit 0 family mpls maximum-labels 5 set ge-0/0/1 unit 0 family inet address 10.10.13.1/24 set ge-0/0/1 unit 0 family mpls maximum-labels 5 set ge-0/0/5 unit 0 family inet address 10.10.17.1/24
-
Konfigurieren Sie die autonome Systemnummer und -optionen zur Steuerung der Paketweiterleitungs-Routing-Optionen.
[edit routing-options] set autonomous-system 65000 set forwarding-table export load-balance-policy set forwarding-table chained-composite-next-hop ingress l3vpn
-
Konfigurieren Sie die Schnittstellen mit dem MPLS-Protokoll und konfigurieren Sie den MPLS-Labelbereich.
[edit protocols mpls] set interface ge-0/0/0.0 set interface ge-0/0/1.0 set label-range static-label-range 1000000 1000999
-
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.
[edit protocols bgp] set group pe type internal set group pe local-address 192.168.147.211 set group pe family inet-vpn unicast set group pe neighbor 192.168.146.181
-
Konfigurieren Sie die Protokollbereichsschnittstellen.
[edit protocols ospf] set area 0.0.0.0 interface ge-0/0/0.0 set area 0.0.0.0 interface lo0.0 set area 0.0.0.0 interface ge-0/0/1.0
-
Konfigurieren Sie die IPv4-Adresse und die Label der primären und sekundären Pfade für Source Routing-Traffic Engineering (TE)-Richtlinien des Protocol Source Packet Routing (SPRING).
[edit protocols source-packet-routing segment-list] set sl-15-primary hop-1 ip-address 10.10.13.3 set sl-15-primary hop-2 label 1000134 set sl-15-primary hop-3 label 1000145 set sl-15-backup hop-1 ip-address 10.10.12.2 set sl-15-backup hop-2 label 1000123 set sl-15-backup hop-3 label 1000134 set sl-15-backup hop-4 label 1000145
-
Konfigurieren Sie die IPv4-Zieladresse, binden Sie das SID-Label sowie den primären und sekundären Quell-Routingpfad für Protokoll SPRING.
[edit protocols source-packet-routing source-routing-path] set lsp-15 to 192.168.146.181 set lsp-15 binding-sid 1000999 set lsp-15 primary sl-15-primary set lsp-15 secondary sl-15-backup
-
Konfigurieren Sie Richtlinienoptionen.
[edit policy-options policy-statement] set VPN-A-export term a from protocol ospf set VPN-A-export term a from protocol direct set VPN-A-export term a then community add VPN-A set VPN-A-export term a then accept set VPN-A-export term b then reject set VPN-A-import term a from protocol bgp set VPN-A-import term a from community VPN-A set VPN-A-import term a then accept set VPN-A-import term b then reject set bgp-to-ospf from protocol bgp set bgp-to-ospf from route-filter 10.10.0.0/16 orlonger set bgp-to-ospf then accept set load-balance-policy then load-balance per-packet
-
Konfigurieren Sie BGP-Community-Informationen.
[edit policy-options] set community VPN-A members target:65000:1
-
Konfigurieren Sie die Routing-Instanz VRF1 mit Instanztyp, Schnittstelle, Router-Distinguisher, VRF-Import, Export und Tabellenetikett. Konfigurieren Sie die Exportrichtlinie und die Schnittstelle des Bereichs für Protokoll-OSPF.
[edit routing-instances VRF1] set instance-type vrf set interface ge-0/0/5.0 set route-distinguisher 192.168.147.211:1 set vrf-import VPN-A-import set vrf-export VPN-A-export set vrf-table-label set protocols ospf export bgp-to-ospf set protocols ospf area 0.0.0.0 interface ge-0/0/5.0
Ergebnisse
Bestätigen Sie Ihre Konfiguration im Konfigurationsmodus, indem Sie die show interfacesBefehle , show policy-options, , show protocolsshow routing-optionsund show routing-instances eingeben. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
[edit] user@PE1# show interfaces { ge-0/0/0 { unit 0 { family inet { address 10.10.12.1/24; } family mpls { maximum-labels 5; } } } ge-0/0/1 { unit 0 { family inet { address 10.10.13.1/24; } family mpls { maximum-labels 5; } } } ge-0/0/5 { unit 0 { family inet { address 10.10.17.1/24; } } } } policy-options { policy-statement VPN-A-export { term a { from protocol [ ospf direct ]; then { community add VPN-A; accept; } } term b { then reject; } } policy-statement VPN-A-import { term a { from { protocol bgp; community VPN-A; } then accept; } term b { then reject; } } policy-statement bgp-to-ospf { from { protocol bgp; route-filter 10.10.0.0/16 orlonger; } then accept; } policy-statement load-balance-policy { then { load-balance per-packet; } } community VPN-A members target:65000:1; } routing-instances { VRF1 { instance-type vrf; protocols { ospf { area 0.0.0.0 { interface ge-0/0/5.0; } export bgp-to-ospf; } } interface ge-0/0/5.0; route-distinguisher 192.168.147.211:1; vrf-import VPN-A-import; vrf-export VPN-A-export; vrf-table-label; } } routing-options { autonomous-system 65000; forwarding-table { export load-balance-policy; chained-composite-next-hop { ingress { l3vpn; } } } } protocols { bgp { group pe { type internal; local-address 192.168.147.211; family inet-vpn { unicast; } neighbor 192.168.146.181; } } mpls { label-range { static-label-range 1000000 1000999; } interface ge-0/0/0.0; interface ge-0/0/1.0; } ospf { area 0.0.0.0 { interface ge-0/0/0.0; interface lo0.0; interface ge-0/0/1.0; } } source-packet-routing { segment-list sl-15-primary { hop-1 ip-address 10.10.13.3; hop-2 label 1000134; hop-3 label 1000145; } segment-list sl-15-backup { hop-1 ip-address 10.10.12.2; hop-2 label 1000123; hop-3 label 1000134; hop-4 label 1000145; } source-routing-path lsp-15 { to 192.168.146.181; binding-sid 1000999; primary { sl-15-primary; } secondary { sl-15-backup; } } } }
Konfiguration von Geräte-PE2
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie auf verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI-Benutzerhandbuch.
-
Konfigurieren Sie die Schnittstellen.
[edit interfaces] set ge-0/0/0 unit 0 family inet address 10.10.12.2/24 set ge-0/0/0 unit 0 family mpls set ge-0/0/1 unit 0 family inet address 10.10.23.2/24 set ge-0/0/1 unit 0 family mpls
-
Konfigurieren Sie den statischen LSP für Protokoll-MPLS.
[edit protocols mpls static-label-switched-path] set adj-23 segment 1000123 set adj-23 segment next-hop 10.10.23.3 set adj-23 segment pop set adj-21 segment 1000221 set adj-21 segment next-hop 10.10.12.1 set adj-21 segment pop
-
Konfigurieren Sie Schnittstellen und statischen Label-Bereich für Protokoll-MPLS.
[edit protocols mpls] set interface ge-0/0/0.0 set interface ge-0/0/1.0 set label-range static-label-range 1000000 1000999
-
Konfigurieren Sie Schnittstellen für Protokoll-OSPF.
[edit protocols ospf area 0.0.0.0] set interface ge-0/0/0.0 set interface ge-0/0/1.0
Ergebnisse
Bestätigen Sie ihre Konfiguration im Konfigurationsmodus auf Router PE2, indem Sie die show interfaces befehle und show protocols eingeben. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
[edit] user@PE2# show interfaces { ge-0/0/0 { unit 0 { family inet { address 10.10.12.2/24; } family mpls; } } ge-0/0/1 { unit 0 { family inet { address 10.10.23.2/24; } family mpls; } } } protocols { mpls { label-range { static-label-range 1000000 1000999; } interface ge-0/0/0.0; interface ge-0/0/1.0; static-label-switched-path adj-23 { segment { 1000123; next-hop 10.10.23.3; pop; } } static-label-switched-path adj-21 { segment { 1000221; next-hop 10.10.12.1; pop; } } } ospf { area 0.0.0.0 { interface ge-0/0/0.0; interface ge-0/0/1.0; } } }
Überprüfung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
- Überprüfen der Routeneingabe der Routing-Tabelle inet.3 des Routers PE1
- Überprüfen von Routing-Tabelleneinträgen der Routing-Tabelle mpls.0 des Routers PE1
- Überprüfung des SPRING Traffic Engineered LSP of Router PE1
- Überprüfung des SPRING Traffic Engineered LSPs auf dem Eingangsrouter des Routers PE1
- Überprüfen der Routing-Tabelleneinträge der Routing-Tabelle mpls.0 des Routers PE2
- Überprüfen des Status statischer MPLS-LSP-Segmente des Routers PE2
Überprüfen der Routeneingabe der Routing-Tabelle inet.3 des Routers PE1
Zweck
Überprüfen Sie den Routeneintrag der Routing-Tabelle inet.3 des Routers PE1.
Aktion
Geben Sie im Betriebsmodus den show route table inet.3
Befehl ein.
user@PE1> show route table inet.3
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.146.181/32 *[SPRING-TE/8] 03:09:26, metric 1
> to 10.10.13.3 via ge-0/0/1.0, Push 1000145, Push 1000134(top)
to 10.10.12.2 via ge-0/0/0.0, Push 1000145, Push 1000134, Push 1000123(top)
Bedeutung
Die Ausgabe zeigt die Eingangsrouten von Segment-Routing-Tunneln an.
Überprüfen von Routing-Tabelleneinträgen der Routing-Tabelle mpls.0 des Routers PE1
Zweck
Überprüfen der Routeneinträge der Routing-Tabelle mpls.0
Aktion
Geben Sie im Betriebsmodus den show route table mpls.0
Befehl ein.
user@PE1> show route table mpls.0
mpls.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 03:25:52, metric 1
Receive
1 *[MPLS/0] 03:25:52, metric 1
Receive
2 *[MPLS/0] 03:25:52, metric 1
Receive
13 *[MPLS/0] 03:25:52, metric 1
Receive
16 *[VPN/0] 03:25:52
> via lsi.0 (VRF1), Pop
1000999 *[SPRING-TE/8] 03:04:03, metric 1
> to 10.10.13.3 via ge-0/0/1.0, Swap 1000145, Push 1000134(top)
to 10.10.12.2 via ge-0/0/0.0, Swap 1000145, Push 1000134, Push 1000123(top)
Bedeutung
Die Ausgabe zeigt die SID-Label der Segment-Routing-Tunnel an.
Überprüfung des SPRING Traffic Engineered LSP of Router PE1
Zweck
Überprüfen Sie spring-Datenverkehrs-LSPs auf den Eingangsroutern.
Aktion
Geben Sie im Betriebsmodus den show spring-traffic-engineering overview
Befehl ein.
user@PE1> show spring-traffic-engineering overview
Overview of SPRING-TE:
Route preference: 8
Number of LSPs: 1 (Up: 1, Down: 0)
External controllers:
< Not configured >
Bedeutung
Die Ausgabe zeigt die Übersicht über spring Traffic Engineered LSPs auf dem Eingangsrouter an.
Überprüfung des SPRING Traffic Engineered LSPs auf dem Eingangsrouter des Routers PE1
Zweck
Überprüfen Sie spring-Datenverkehrs-LSPs auf dem Eingangsrouter.
Aktion
Geben Sie im Betriebsmodus den show spring-traffic-engineering lsp detail
Befehl ein.
user@PE1# show spring-traffic-engineering lsp detail
Name: lsp-15
To: 192.168.146.181
State: Up
Path: sl-15-primary
Outgoing interface: ge-0/0/1.0
BFD status: N/A (Up: 0, Down: 0)
SR-ERO hop count: 3
Hop 1 (Strict):
NAI: IPv4 Adjacency ID, 0.0.0.0 -> 10.10.13.3
SID type: None
Hop 2 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000134
Hop 3 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000145
Path: sl-15-backup
Outgoing interface: ge-0/0/0.0
BFD status: N/A (Up: 0, Down: 0)
SR-ERO hop count: 4
Hop 1 (Strict):
NAI: IPv4 Adjacency ID, 0.0.0.0 -> 10.10.12.2
SID type: None
Hop 2 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000123
Hop 3 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000134
Hop 4 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000145
Total displayed LSPs: 1 (Up: 1, Down: 0)
Bedeutung
Die Ausgabe zeigt Details zu SPRING-Traffic-entwickelten LSPs auf dem Eingangsrouter an
Überprüfen der Routing-Tabelleneinträge der Routing-Tabelle mpls.0 des Routers PE2
Zweck
Überprüfen Sie die Routing-Tabelleneinträge der Routing-Tabelle mpls.0 des Routers PE2.
Aktion
Geben Sie im Betriebsmodus den show route table mpls.0
Befehl ein.
user@PE2> show route table mpls.0
mpls.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 03:22:29, metric 1
Receive
1 *[MPLS/0] 03:22:29, metric 1
Receive
2 *[MPLS/0] 03:22:29, metric 1
Receive
13 *[MPLS/0] 03:22:29, metric 1
Receive
1000123 *[MPLS/6] 03:22:29, metric 1
> to 10.10.23.3 via ge-0/0/1.0, Pop
1000123(S=0) *[MPLS/6] 03:22:29, metric 1
> to 10.10.23.3 via ge-0/0/1.0, Pop
1000221 *[MPLS/6] 03:22:29, metric 1
> to 10.10.12.1 via ge-0/0/0.0, Pop
1000221(S=0) *[MPLS/6] 03:22:29, metric 1
> to 10.10.12.1 via ge-0/0/0.0, Pop
Überprüfen des Status statischer MPLS-LSP-Segmente des Routers PE2
Zweck
Überprüfen Sie den Status der MPLS-LSP-Segmente des Routers PE2.
Aktion
Geben Sie im Betriebsmodus den show mpls static-lsp
Befehl ein.
user@PE2> show mpls static-lsp
Ingress LSPs:
Total 0, displayed 0, Up 0, Down 0
Transit LSPs:
Total 0, displayed 0, Up 0, Down 0
Bypass LSPs:
Total 0, displayed 0, Up 0, Down 0
Segment LSPs:
LSPname SID-label State
adj-21 1000221 Up
adj-23 1000123 Up
Total 2, displayed 2, Up 2, Down 0
Bedeutung
Die Ausgabe zeigt den Status der statischen MPLS-LSP-Segmente des Routers PE2 an.
Ermöglichung verteilter CSPF für Segment-Routing-LSPs
Vor Junos OS Version 19.2R1S1 konnten Sie für das Traffic-Engineering von Segment-Routing-Pfaden entweder explizit statische Pfade konfigurieren oder berechnete Pfade von einem externen Controller verwenden. Mit der Distributed Constrained Shortest Path First (CSPF)-Funktion für Segment-Routing-LSP können Sie einen Segment-Routing-LSP lokal auf dem Eingangsgerät gemäß den von Ihnen konfigurierten Einschränkungen berechnen. Mit dieser Funktion werden die LSPs basierend auf den konfigurierten Einschränkungen und dem Metriktyp (Traffic-Engineering oder IGP) optimiert. Die LSPs werden so berechnet, dass sie die verfügbaren ECMP-Pfade zum Ziel nutzen, wobei die Segment-Routing-Label-Stack-Kompression aktiviert oder deaktiviert ist.
- Einschränkungen der verteilten CSPF-Berechnung
- Verteilter CSPF-Berechnungsalgorithmus
- Verteilte CSPF-Berechnungsdatenbank
- Konfigurieren verteilter CSPF-Berechnungsbeschränkungen
- Verteilte CSPF-Berechnung
- Interaktion zwischen verteilter CSPF-Berechnung und SR-TE-Funktionen
- Verteilte CSPF-Berechnungs-Beispielkonfigurationen
Einschränkungen der verteilten CSPF-Berechnung
Segment-Routing-LSP-Pfade werden berechnet, wenn alle konfigurierten Einschränkungen erfüllt sind.
Die verteilte CSPF-Berechnungsfunktion unterstützt die folgenden Teilmenge von Einschränkungen, die im Internet-Entwurf angegeben wurden, draft-ietf-spring-segment-routing-policy-03.txt, Segment-Routing-Richtlinie für das Traffic Engineering:
-
Integration und Ausschluss administrativer Gruppen.
-
Integration von losen oder strengen Hop-IP-Adressen.
HINWEIS:Sie können nur Router-IDs in den losen oder strengen Hop-Einschränkungen angeben. Label und andere IP-Adressen können in Junos OS Version 19.2R1-S1 nicht als lose oder strenge Hop-Einschränkungen angegeben werden.
-
Maximale Anzahl von Segment-IDs (SIDs) in der Segmentliste.
-
Maximale Anzahl von Segmentlisten pro Segment-Routingpfad des Kandidaten.
Die verteilte CSPF-Berechnungsfunktion für Segment-Routing-LSPs unterstützt die folgenden Arten von Einschränkungen und Bereitstellungsszenarien nicht:
-
IPV6-Adressen.
-
Inter Domain Segment Routing Traffic Engineering (SR-TE)-LSPs.
-
Schnittstellen ohne Nummer.
-
Mehrere Routing-Protokolle wie OSPF, ISIS und BGP-LS gleichzeitig aktiviert.
-
Berechnung mit Präfixen oder Anycast-Adressen als Ziel.
-
Ein- und Ausschluss von Schnittstellen-IP-Adressen als Einschränkungen.
Verteilter CSPF-Berechnungsalgorithmus
Die verteilte CSPF-Berechnungsfunktion für Segment-Routing-LSPs verwendet den Label-Stack-Kompressionsalgorithmus mit CSPF.
Label Stack-Kompression aktiviert
Ein komprimierter Label-Stack stellt eine Reihe von Pfaden von einer Quelle zu einem Ziel dar. Sie besteht im Allgemeinen aus Node-SIDs und Adjacency-SIDs. Wenn die Komprimierung des Labelstacks aktiviert ist, wird das Ergebnis der Berechnung eine Reihe von Pfaden, die den ECMP zum Ziel maximieren, mit einer minimalen Anzahl von SIDs im Stack, während sie den Einschränkungen entsprechen.
Label Stack-Kompression deaktiviert
Die CsPF-Multipath-Berechnung mit deaktivierter Label-Stack-Kompression findet bis zu N Segmentlisten zum Ziel, wobei:
-
Die Kosten für alle Segmentlisten sind gleich und die gleichen wie die kürzeste Traffic-Engineering-Metrik, um das Ziel zu erreichen.
-
Jede Segmentliste besteht aus Adjacency-SIDs.
-
Der Wert von N ist die maximale Anzahl von Segmentlisten, die für den Kandidatenpfad nach Konfiguration zulässig sind.
-
Keine zwei Segmentlisten sind identisch.
-
Jede Segmentliste erfüllt alle konfigurierten Einschränkungen.
Verteilte CSPF-Berechnungsdatenbank
Die für die SR-TE-Berechnung verwendete Datenbank enthält alle Verbindungen, Knoten, Präfixe und deren Merkmale, unabhängig davon, ob Traffic-Engineering in diesen Werbeknoten aktiviert ist. Mit anderen Worten, es ist die Vereinigung der Traffic-Engineering-Datenbank (TED) und der IGP-Link-Zustandsdatenbank aller Domänen, von denen der Computerknoten gelernt hat. Daher müssen Sie die Anweisung auf [edit protocols isis traffic-engineering]
Hierarchieebene einschließenigp-topology
, damit CSPF funktioniert.
Konfigurieren verteilter CSPF-Berechnungsbeschränkungen
Sie können ein Rechenprofil verwenden, um die Berechnungsbeschränkungen logisch zu gruppieren. Diese Rechenprofile werden durch die Segment-Routing-Pfade für die Berechnung der primären und sekundären Segment-Routing-LSPs referenziert.
Um ein Rechenprofil zu konfigurieren, fügen Sie die Rechenprofil-Anweisung auf Hierarchieebene [edit protocols source-packet-routing]
ein.
Die Konfiguration für die unterstützten Recheneinschränkungen umfasst:
-
Administrative groups
Sie können Admin-Gruppen unter der
[edit protocols mpls]
Hierarchieebene konfigurieren. Junos OS wendet die Konfiguration der administrativen Gruppe auf die SR-TE-Schnittstellen (Segment Routing Traffic-Engineering) an.Um die Berechnungsbeschränkungen zu konfigurieren, können Sie drei Kategorien für eine Reihe von administrativen Gruppen angeben. Die Konfiguration der Berechnungsbeschränkungen kann allen Routing-Pfaden für Kandidatensegmente gemeinsam sein oder unter einzelnen Kandidatenpfaden.
-
include-any
– Gibt an, dass alle Verbindungen mit mindestens einer der konfigurierten administrativen Gruppen in der Liste für den pfad akzeptabel sind, der durchquert werden soll. -
include-all
– Gibt an, dass jede Verbindung mit allen konfigurierten administrativen Gruppen in der Liste für den zu durchlaufenden Pfad akzeptabel ist. -
exclude
– Gibt an, dass verbindungen, die nicht über eine der konfigurierten administrativen Gruppen in der Liste verfügen, für den Pfad, der durchquert werden soll, akzeptabel sind.
-
-
Explicit path
Sie können eine Reihe von Router-IDs im Datenverarbeitungsprofil als Einschränkung für die Berechnung der SR-TE-Kandidatenpfade angeben. Jeder Hop muss eine IPv4-Adresse sein und kann vom Typ streng oder lose sein. Wenn der Hoptyp nicht konfiguriert ist, wird strict verwendet. Sie müssen die
compute
Option unter der Segmentliste-Anweisung einschließen, wenn Sie die Explizite Pfadeinschränkung angeben. -
Maximum number of segment lists (ECMP paths)
Sie können einen Kandidatenpfad mit einer Reihe von dynamischen Segment-Listen zuordnen. Bei den Pfaden handelt es sich um ECMP-Pfade, bei denen jede Segmentliste in ein Next-Hop-Gateway mit aktiver Gewichtung übersetzt wird. Diese Pfade sind das Ergebnis von Pfadberechnungen mit oder ohne Kompression.
Sie können dieses Attribut mit der
maximum-computed-segment-lists maximum-computed-segment-lists
Option unter der Konfigurationsaussage für rechenprofile konfigurieren. Diese Konfiguration bestimmt die maximale Anzahl solcher Segmentlisten, die für einen bestimmten primären und sekundären LSP berechnet werden. -
Maximum segment list depth
Der Parameter für die maximale Segmentlistentiefe stellt sicher, dass unter den ECMP-Pfaden, die alle anderen Einschränkungen erfüllen, wie z. B. administrative Gruppen, nur Pfade verwendet werden, deren Segmentlisten kleiner oder gleich der maximalen Segmentlistentiefe sind. Wenn Sie diesen Parameter als Einschränkung unter dem Rechenprofil konfigurieren, überschreibt er die
maximum-segment-list-depth
Konfiguration auf[edit protocols source-packet-routing]
Der Hierarchieebene, sofern vorhanden.Sie können dieses Attribut mit der
maximum-segment-list-depth maximum-segment-list-depth
Option unter der Konfigurationsaussage für rechenprofile konfigurieren. -
Protected or unprotected adjacency SIDs
Sie können geschützte oder ungeschützte Adjacency-SID als Einschränkung unter dem Rechenprofil konfigurieren, um Verbindungen mit dem angegebenen SID-Typ zu vermeiden.
-
Metric type
Sie können den Typ der Metrik für den Link angeben, der für die Berechnung verwendet werden soll. Standardmäßig verwenden SR-TE-LSPs Traffic-Engineering-Metriken der Links für die Berechnung. Die Traffic-Engineering-Metrik für Links wird durch Traffic-Engineering-Erweiterungen von IGP-Protokollen angekündigt. Sie können jedoch auch die IGP-Metrik für die Berechnung verwenden, indem Sie die Metriktypkonfiguration im Rechenprofil verwenden.
Sie können dieses Attribut mit der
metric-type (igp | te)
Option unter der Konfigurationsaussage für rechenprofile konfigurieren.
Verteilte CSPF-Berechnung
Die SR-TE-Kandidatenpfade werden lokal berechnet, sodass sie die konfigurierten Einschränkungen erfüllen. Wenn die LabelStack-Kompression deaktiviert ist, ergibt sich bei der CSPF-Berechnung für mehrere Pfade eine Reihe von SID-Stacks mit Adjacency. Wenn die Label-Stack-Kompression aktiviert ist, ergibt sich ein Satz komprimierter Label-Stacks (bestehend aus angrenzenden SIDs und Node-SIDs).
Wenn sekundäre Pfade berechnet werden, werden die Von den primären Pfaden genommenen Verbindungen, Knoten und DIE BACKBONEGs zur Berechnung nicht vermieden. Weitere Informationen zu primären und sekundären Pfaden finden Sie unter Konfigurieren von primären und sekundären LSPs.
Für alle LSPs mit erfolglosem Berechnungsergebnis wird die Berechnung als Änderungen der Traffic-Engineering-Datenbank (TED) erneut durchgeführt.
Interaktion zwischen verteilter CSPF-Berechnung und SR-TE-Funktionen
- Gewichtung im Zusammenhang mit Pfaden einer SR-TE-Richtlinie
- BFD Liveliness Detection
- Inherit-Label-Nexthops
- Automatische Übersetzungsfunktion
Gewichtung im Zusammenhang mit Pfaden einer SR-TE-Richtlinie
Sie können Gewichtungen für berechnete und statische SR-TE-Pfade konfigurieren, die zu den nächsten Hops der Route beitragen. Ein einzelner Pfad, der die Berechnung aktiviert hat, kann jedoch zu mehreren Segmentlisten führen. Diese berechneten Segmentlisten werden unter sich als ECMP behandelt. Sie können diesen Segmenten hierarchische ECMP-Gewichtungen zuweisen, unter Berücksichtigung der Gewichtungen, die jedem der konfigurierten Vorwahlen zugewiesen sind.
BFD Liveliness Detection
Sie können die BFD-Liveliness-Erkennung für die berechneten primären oder sekundären Pfade konfigurieren. Jeder berechnete primäre oder sekundäre Pfad kann zu mehreren Segmentlisten führen, infolgedessen die für die Segmentlisten konfigurierten BFD-Parameter auf alle berechneten Segmentlisten angewendet werden. Wenn alle aktiven primären Pfade nach unten gehen, wird der vorprogrammierte sekundäre Pfad (falls angegeben) aktiv.
Inherit-Label-Nexthops
Sie sind nicht erforderlich, die Konfiguration in der inherit-label-nexthops
[edit protocols source-packet-routing segment-list segment-list-name]
Hierarchie für die berechneten primären oder sekundären Pfade explizit zu aktivieren, da es sich um ein Standardverhalten handelt.
Automatische Übersetzungsfunktion
Sie können die Funktion zur automatischen Übersetzung in den Segmentlisten und die primären oder sekundären Pfade mit der automatischen Übersetzungsfunktion konfigurieren, die auf diese Segmentlisten verweist. Auf der anderen Seite kann die primäre oder sekundäre, auf der die Rechenfunktion aktiviert ist, keine Segmentliste referenziert werden. Aus diesem Grund können Sie die Rechenfunktion und die automatische Übersetzungsfunktion für einen bestimmten primären oder sekundären Pfad nicht aktivieren. Sie können jedoch einen LSP mit einem primären Pfad mit Rechentyp und einem anderen mit automatischem Übersetzungstyp konfigurieren lassen.
Verteilte CSPF-Berechnungs-Beispielkonfigurationen
Beispiel 1
In Beispiel 1
-
Der nicht berechnete primäre Pfad verweist auf eine konfigurierte Segmentliste. In diesem Beispiel wird auf die konfigurierte Segmentliste static_sl1 verwiesen, und sie dient auch als Name für diesen primären Pfad.
-
Ein berechneter Primärname sollte einen Namen konfiguriert haben, und dieser Name sollte keine konfigurierte Segmentliste referenziert. In diesem Beispiel compute_segment1 ist keine konfigurierte Segmentliste.
-
Das compute_profile_red Rechenprofil wird mit dem Namen compute_segment1auf den primären Pfad angewendet.
-
Das compute_profile_red Rechenprofil enthält eine Segmentliste des Typs
compute
, die verwendet wird, um die explizite Pfadeinschränkung für die Berechnung anzugeben.
[edit protocols source-packet-routing] segment-list static_sl1{ hop1 label 80000 } segment-list exp_path1 { hop1 ip-address 10.1.1.1 loose hop2 ip-address 10.2.2.2 compute } compute-profile compute_profile_red { include-any red segment-list exp_path1 maximum-segment-list-depth 5 }
Die Gewichtungen für den berechneten Pfad next-Hops und statische Next-Hops sind 2 bzw. 3. Vorausgesetzt, die nächsten Hops für berechnete Pfade sind comp_nh1, comp_nh2und , und comp_nh3der nächste Hop für statischen Pfad ist static_nh, werden die Gewichtungen wie folgt angewendet:
Next-Hop |
Gewicht |
---|---|
comp_nh1 |
2 |
comp_nh2 |
2 |
comp_nh3 |
2 |
static_nh |
9 |
Beispiel 2
In Beispiel 2 können sowohl die primären als auch die sekundären Pfade vom Rechentyp sein und ihre eigenen Rechenprofile haben.
[edit protocols source-packet-routing] compute-profile compute_profile_green{ include-any green maximum-segment-list-depth 5 } compute-profile compute_profile_red{ include-any red maximum-segment-list-depth 8 }
Beispiel 3
Wenn in Beispiel 3 unter einem primären oder sekundären Pfad die Berechnung erwähnt wird, führt dies zur lokalen Berechnung eines Pfads zum Ziel, ohne Einschränkungen oder andere Parameter für die Berechnung.
[edit protocols source-packet-routing] source-routing-path srte_colored_policy1 { to 10.5.5.5 color 5 binding-sid 10001 primary { compute_segment1 { compute } } }
Beispiel: Konfigurieren von CoS-basierter Weiterleitung und richtlinienbasiertem Routing für SR-TE LSPs
SUMMARY CoS-basierte Weiterleitung (CBF) und richtlinienbasiertes Routing (PBR, auch bekannt als filterbasierte Weiterleitung) können für nicht farbige Segment Routing-Traffic-Engineered (SR-TE)-LSPs aktiviert werden, um selektiven Datenverkehr über einen expliziten SR-TE-Pfad zu steuern. Dies bietet Ihnen den Vorteil der Datenverkehrswartung auf Grundlage von Class-of-Service oder einer Richtlinie.
- CoS-basierte Weiterleitung und richtlinienbasiertes Routing für SR-TE-LSPs – Übersicht
- Konfigurieren sie CoS-basierte Weiterleitung und richtlinienbasiertes Routing für SR-TE LSPs
CoS-basierte Weiterleitung und richtlinienbasiertes Routing für SR-TE-LSPs – Übersicht
- Vorteile von CoS-based Forwarding (CBF) und richtlinienbasiertem Routing (PBR) für SR-TE LSPs
- Segment-Routing-Pfadquellen, die CBF und PBR unterstützen
- Überlegungen zur Konfiguration von CBF und PBR für SR-TE-LSPs
Vorteile von CoS-based Forwarding (CBF) und richtlinienbasiertem Routing (PBR) für SR-TE LSPs
Mit CBF und PBR können Sie:
Nutzen Sie Kombinationen aus SR-TE-Pfaden (Segment Routing-Traffic Engineering), um den Serviceverkehr im Core zu steuern.
Wählen Sie die unterstützenden Services aus, die über die ausgewählten SR-TE-Pfade aufgelöst werden sollen.
Segment-Routing-Pfadquellen, die CBF und PBR unterstützen
Die folgenden Quellen für Segment-Routing-Pfade unterstützen CoS-basierte Weiterleitung und richtlinienbasiertes Routing:
Static SR–TE paths— Statisch konfigurierte Quell-Routing-Pfade, die den gesamten Labelstack statisch konfiguriert haben.
PCEP— Dynamische Bereitstellung von Quell-Routing-Pfaden, die auf einem Controller erstellt und in einem ERO entweder über PCEP-Segment-Routing-Erweiterungen oder in einer BGP-Segment-Routing-Richtlinie über BGP-Segment-Routing-Erweiterungen heruntergeladen werden.
Dynamic LSPs— Dynamisch erstellte Tunnel, die durch das dynamische Tunnelmodul ausgelöst werden und eine Last-Hop-ERO-Auflösung haben.
Auto-translated paths— Statisch konfigurierte Quell-Routing-Pfade, die automatisch übersetzt werden.
Überlegungen zur Konfiguration von CBF und PBR für SR-TE-LSPs
Merken:
CBF und PBR sind nur bei nicht farbigen SR-TE-LSPs aktiviert, die statisch oder dynamisch konfiguriert sind.
CbF- und PBR-Konfigurationen für SR-TE-LSPs können auf einem Gerät koexistieren. die Reihenfolge der Konfiguration bestimmt den Typ, in dem die Routen weitergeleitet werden.
Wenn es sich bei dem ersten Hop des SR-TE-LSP um eine Bezeichnung für PBR handelt, müssen Sie die
resolution preserve-nexthop-hiearchy
Anweisung auf[edit routing-options]
Hierarchieebene einschließen.Die klassenbasierte Weiterleitung von Routen für CBF ist nur in der Weiterleitungstabelle und nicht auf den Routen sichtbar.
Die richtlinienbasierte Weiterleitung von Routen für PBR erfolgt auf den Routen und wird in der
show route
Befehlsausgabe gesehen.
Konfigurieren sie CoS-basierte Weiterleitung und richtlinienbasiertes Routing für SR-TE LSPs
SUMMARY CoS-basierte Weiterleitung (CBF) und richtlinienbasiertes Routing (PBR, auch bekannt als filterbasierte Weiterleitungs-FBF) können verwendet werden, um den selektiven Datenverkehr mithilfe eines expliziten Segment Routing-Traffic-Engineered Path (SR-TE) Label-Swtiched Path (LSP) zu steuern. Nur nicht farbige Segment-Routing-LSPs, bei denen der nächste Hop als Erstes Hop-Label oder IP-Adresse konfiguriert ist, unterstützen CBF und PBR.
Bevor Sie beginnen
Sie müssen Junos OS Version 20.1 und höher ausführen, um CBF und PBR für nicht farbige SR-TE-LSPs zu aktivieren.
Konfigurieren Sie die Geräteschnittstellen und stellen Sie sicher, dass die Geräte mit dem Netzwerk verbunden sind.
Definieren Sie Segmentlisten und konfigurieren Sie SR-TE-LSPs und die zugehörigen Parameter.
Gehen Sie folgendermaßen vor, um einen SR-TE-LSP zu konfigurieren:
Sie können nun CBF und PBR für die konfigurierten SR-TE-LSPs konfigurieren.
Um CBF zu konfigurieren, gehen Sie wie folgt vor:
Definieren Sie DSCP-Klassifizierer (Differenzierte Services Code Point) zur Verarbeitung eingehender IPv4-Pakete, Weiterleitungsklassen und Optionswerte.
[edit class-of-service] user@host# set classifiers dscpclassifier-name forwarding-class forwarding-class-name loss-priority level code-points [ aliases ] [ 6 bit-patterns ]
Zum Beispiel:
[edit class-of-service] user@host# set classifiers dscp mydscp forwarding-class af11 loss-priority low code-points 001010 user@host# set classifiers dscp mydscp forwarding-class af11 loss-priority medium-high code-points 001100 user@host# set classifiers dscp mydscp forwarding-class af11 loss-priority high code-points 001110 user@host# set classifiers dscp mydscp forwarding-class af21 loss-priority low code-points 010010 user@host# set classifiers dscp mydscp forwarding-class af21 loss-priority medium-high code-points 010100 user@host# set classifiers dscp mydscp forwarding-class af21 loss-priority high code-points 010110 user@host# set classifiers dscp mydscp forwarding-class af31 loss-priority low code-points 011010 user@host# set classifiers dscp mydscp forwarding-class af31 loss-priority medium-high code-points 011100 user@host# set classifiers dscp mydscp forwarding-class af31 loss-priority high code-points 011110 user@host# set classifiers dscp mydscp forwarding-class af41 loss-priority low code-points 100010 user@host# set classifiers dscp mydscp forwarding-class af41 loss-priority medium-high code-points 100100 user@host# set classifiers dscp mydscp forwarding-class af41 loss-priority high code-points 100110
Definieren Sie Forwarding Classes (FCs) für die Gruppierung von Paketen für die Übertragung und weisen Sie Pakete den Ausgabewarteschlangen zu.
[edit class-of-service] user@host# set forwarding-classes queue queue-numner class-name
Zum Beispiel:
[edit class-of-service] user@host# set forwarding-classes queue 0 af11 user@host# set forwarding-classes queue 1 af21 user@host# set forwarding-classes queue 2 af31 user@host# set forwarding-classes queue 3 af41
Weisen Sie den Geräteschnittstellen die konfigurierten Klassifizierer zu.
[edit class-of-service] user@host# set interfaces interface-name unit unit classifiers dscp classifier-name
Zum Beispiel:
[edit class-of-service] user@host# set interfaces ge-0/0/8 unit 1 classifiers dscp mydscp user@host# set interfaces ge-0/0/8 unit 2 classifiers dscp mydscp
Definieren Sie CoS-basierte Weiterleitungsrichtlinienoptionen mit LSP next-Hop als SR-TE LSP.
[edit class-of-service] user@host# set forwarding-policy next-hop-map map-name forwarding-classes class-name lsp-next-hop source-routing-path-name
Zum Beispiel:
[edit class-of-service] user@host# set forwarding-policy next-hop-map my_cbf forwarding-class af11 lsp-next-hop srtelsp1 user@host# set forwarding-policy next-hop-map my_cbf forwarding-class af21 lsp-next-hop srtelsp2 user@host# set forwarding-policy next-hop-map my_cbf forwarding-class af41 lsp-next-hop srtelsp3 user@host# set forwarding-policy next-hop-map my_cbf forwarding-class af31 lsp-next-hop srtelsp4
Verwerfen Sie Datenverkehr, der keine Weiterleitungsklasse in der Next-Hop-Karte erfüllt.
[edit class-of-service] user@host# set forwarding-policy next-hop-map map-name forwarding-class-default discard
Zum Beispiel:
[edit class-of-service] user@host# set forwarding-policy next-hop-map my_cbf forwarding-class-default discard
Konfigurieren Sie eine Richtlinienaussage, die angibt, dass Routen, die dem Routenfilter entsprechen, der CoS-Next-Hop-Zuordnung unterliegen, die durch Map-Name angegeben wird.
[edit policy-options] user@host# set policy-statement policy-name from route-filter destination-prefix match-type <actions> user@host# set policy-statement policy-name then cos-next-hop-map map-name
Zum Beispiel:
[edit policy-options] user@host# set policy-statement cbf from route-filter 4.0.0.1/16 orlonger user@host# set policy-statement cbf then cos-next-hop-map my_cbf
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.
[edit routing-options] user@host# set forwarding-table export policy-name
Zum Beispiel:
[edit routing-options] user@host# set forwarding-table export cbf
Commit der Konfiguration.
user@host# commit
Verify CBF Configuration
Sie können die CBF-Konfiguration mit dem show route forwarding-table destination ip-address vpn vpn-name extensive
Befehl überprüfen.
user@host> show route forwarding-table destination 4.0.0.1 vpn vpn1 extensive Routing table: vpn1.inet [Index 8] Internet: Destination: 4.0.0.1/32 Route type: user Route reference: 0 Multicast RPF nh index: 0 P2mpidx: 0 Flags: sent to PFE Next-hop type: indirect Next-hop type: indexed Route type: idx:0 Nexthop: 11.1.1.2 Next-hop type: Push 296, Push 801007, Push 801003, Push 801002(top) Index: 807 Reference: 1 Route interface-index: 0 Index: 1048579 Reference: 10001 Index: 837 Reference: 2 Load Balance Label: None Next-hop interface: ge-0/0/1.1 Route type: idx:1 Nexthop: 11.11.1.2 Next-hop type: Push 296, Push 801007, Push 801003, Push 801002(top) Index: 809
Bei CBF ist die klassenbasierte Weiterleitung von Routen nur in der Weiterleitungstabelle sichtbar, im Gegensatz zu PBR, wo die gefilterten Routen in der show route
Befehlsausgabe angezeigt werden.
Um PBR zu konfigurieren, gehen Sie wie folgt vor:
Konfigurieren Sie eine Richtlinienanweisung, die angibt, dass Routen, die dem Protokoll und dem Routenfilter entsprechen, dem LSP next-Hop unterliegen oder als Lastausgleich als Equal-Cost-Multipath (ECMP) in der Weiterleitungstabelle ausgeführt werden.
[edit policy-options] user@host# set policy-statement policy-name from protocol protocol-name user@host# set policy-statement policy-name from route-filter destination-prefix match-type <actions> user@host# set policy-statement policy-name then install-nexthop lsp lsp-name user@host# set policy-statement policy-name then load-balance per-packet
Zum Beispiel:
[edit policy-options] user@host# set policy-statement pbr term 1 from protocol bgp user@host# set policy-statement pbr term 1 from route-filter 4.0.0.1/32 exact user@host# set policy-statement pbr term 1 then install-nexthop lsp srtelsp1 user@host# set policy-statement pbr term 1 then load-balance per-packet user@host# set policy-statement pbr term 1 then reject
Konfigurieren Sie das Gerät so, dass es eine benutzerdefinierte Routenauflösung auf dem Protokoll des nächsten Hops von Routen ausführt.
HINWEIS:Die
resolution preserve-nexthop-hierarchy
Anweisung ist für PBR obligatorisch, wenn der erste Hop des SR-TE-LSP ein Label ist.[edit routing-options] user@host# set resolution preserve-nexthop-hierarchy
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.
[edit routing-options] user@host# set forwarding-table export policy-name
Zum Beispiel:
[edit routing-options] user@host# set forwarding-table export pbr
Commit der Konfiguration.
user@host# commit
Verify PBR Configuration
Sie können die PBR-Konfiguration mit dem show route destination-prefix
Befehl überprüfen.
user@host> show route 4.0.0.1 vpn1.inet.0: 10003 destinations, 10003 routes (10003 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 4.0.0.1/32 *[BGP/170] 00:24:12, localpref 100, from 7.7.7.7 AS path: 10 I, validation-state: unverified to 11.1.1.2 via ge-0/0/1.1, Push 50983, Push 801007, Push 801003, Push 801002(top) > to 11.11.1.2 via ge-0/0/1.2, Push 50983, Push 801007, Push 801003, Push 801002(top) to 11.12.1.2 via ge-0/0/1.3, Push 50983, Push 801007, Push 801003, Push 801002(top) to 11.13.1.2 via ge-0/0/1.4, Push 50983, Push 801007, Push 801003, Push 801002(top)
user@host> show route 4.0.0.1 expanded-nh extensive vpn1.inet.0: 10003 destinations, 10003 routes (10003 active, 0 holddown, 0 hidden) 4.0.0.1/32 (1 entry, 1 announced) Installed-nexthop: Indr (0xc7aaa54) 7.7.7.7 Push 50983 Session-ID: 0x16f Krt_inh (0xc745a84) Index:1048579 PNH: 7.7.7.7 Chain (0xc7aa798) Index:823 Push 50983 Router (0xc417034) 11.1.1.2 Push 801007, Push 801003, Push 801002(top) via ge-0/0/1.1
Die Ausgabe zeigt alle Next-Hops für das Zielpräfix 4.0.0.1 an. Die expanded-nh extensive
Optionen zeigen die gefilterten Next-Hops unter dem Krt_inh
Ausgabefeld an.
user@host> show route 4.0.0.2 vpn1.inet.0: 10003 destinations, 10003 routes (10003 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 4.0.0.2/32 *[BGP/170] 00:30:14, localpref 100, from 7.7.7.7 AS path: 10 I, validation-state: unverified to 11.1.1.2 via ge-0/0/1.1, Push 569, Push 801007, Push 801003, Push 801002(top) > to 11.11.1.2 via ge-0/0/1.2, Push 569, Push 801007, Push 801003, Push 801002(top) to 11.12.1.2 via ge-0/0/1.3, Push 569, Push 801007, Push 801003, Push 801002(top) to 11.17.1.2 via ge-0/0/1.8, Push 569, Push 801007, Push 801003, Push 801002(top)
user@host> show route 7.7.7.7 protocol spring-te inet.0: 10082 destinations, 10119 routes (10082 active, 0 holddown, 0 hidden) inet.3: 25 destinations, 77 routes (25 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 7.7.7.7/32 *[SPRING-TE/1] 00:00:32, metric 1, metric2 4 > to 11.1.1.2 via ge-0/0/1.1, Push 801007, Push 801003, Push 801002(top) to 11.11.1.2 via ge-0/0/1.2, Push 801007, Push 801003, Push 801002(top) to 11.12.1.2 via ge-0/0/1.3, Push 801007, Push 801003, Push 801002(top) to 11.17.1.2 via ge-0/0/1.8, Push 801007, Push 801003, Push 801002(top)
Für PBR führt die show route
Befehlsausgabe die richtlinienbasierte Filterung von Routen durch.
Aktivieren mehrerer Pfade für SR-TE-LSPs in PCEP
Sie können mehrere Pfade (primär oder sekundär) für PCEP SR-TE-LSPs (statisch konfiguriert, delegiert und PCE-initiiert) konfigurieren, wie in draft-ietf-pce-multipath-06 definiert. Nur eine sekundäre Pfadkonfiguration wird unterstützt und nur für statisch konfigurierte SR-TE-LSPs. Die in Draft-ietf-pce-multipath-06 definierten PCEP-Erweiterungen ermöglichen es PCEP, mehrere Pfade (Multipath) für die LSPs zwischen PCEP-Endpunkten zu verbreiten.
Vorteile mehrerer Pfade für PCEP SR-TE LSPs
-
LSPs können mehrere EROs zu einem Ziel haben
-
Bietet Load Balancing-Funktionen durch Konfiguration der Gewichtung für einzelne EROs
-
Passt sich mit dem Entwurf für die SR-TE-Architektur zur Definition von Kandidatenpfaden ab
Die folgenden PCEP-Funktionen für mehrere Pfade werden unterstützt:
-
Wenn PCEP für mehrere Pfade aktiviert ist (Standard), können Sie mehrere primäre (oder einen sekundären) Pfad in einem PCC-konfigurierten und kontrollierten Kandidatenpfad konfigurieren.
-
Wenn PCEP für mehrere Pfade deaktiviert ist, können Sie nur einen primären Pfad in einem Kandidatenpfad konfigurieren. Die Konfiguration des sekundären Pfads ist nicht zulässig.
Wenn Sie PCEP-Multipaths aktivieren, compute-profile
können sie jetzt mit einer maximalen Anzahl von Segmentlisten (maximum-computed-segment-lists
) von mehr als 1 konfiguriert werden.
Wenn PCEP für mehrere Pfade aktiviert ist, sendet PCCD keine Einschränkungen für PCC-gesteuerte Kandidatenpfade.
Wenn die PCEP-Multipath-Funktion aktiviert ist, ist die sekundäre Pfadkonfiguration für einen nicht delegierten PCC-Kandidatenpfad zulässig. Das für den sekundären Pfad spezifische EXPLICIT-ROUTE-Objekt (EROs) wird an den PCE gesendet, wobei das Backup-Flag für den ERO festgelegt ist. Die primären Pfade enthalten den MULTIPATH-BACKUP-TLV in der PCRpt-Nachricht nicht. Sekundärer Pfad umfasst MULTIPATH-BACKUP-TLV mit Backup-Flag gesetzt.
Die folgenden PCEP-Multipath-Funktionen werden unterstützt:
-
Multipath Weight TLV (MULTIPATH-WEIGHT-TLV) im Path-Attribut (PATH-ATTRIB) Objekt
-
MULTIPATH-BACKUP TLV in Path Attribut (PATH-ATTRIB) Nur für PCC-gesteuerte SR-TE-LSPs
-
MULTIPATH-CAP-TLV im PCEP-LSP-Objekt
-
Beschränkt mehrere primäre und sekundäre Pfade im Sr-Kandidatenpfad, wenn DER PCEP-Multipath deaktiviert ist
-
Mehrere primäre und sekundäre Pfade im SR-Kandidatenpfad, wenn PCEP-Multipath für PCC-gesteuerte LSPs aktiviert ist
-
Maximale Anzahl an berechneten Segmentlisten (
max-computed-segment-lists
) mehr als 1 im SR-TE-Rechenprofil für delegierte und PCE-initiierte LSPs -
Mehrere EROs für PCE-initiierte Kandidatenpfade in SR-TE und PCCD
-
SRv6-LSPs
-
SR MPLS (IPv4)
-
Dynamische SR MPLS (IPv4)-Tunnel
-
Multi-Controller-Unterstützung
-
Mehrere ERO-Pfade für PCE-initiierte, PCC-konfigurierte und kontrollierte sowie delegierte farbige und unfarbige Kandidatenpfade
-
Abwärtskompatibel mit früheren Versionen von Paragon Pathfinder. Um die Abwärtskompatibilität zu gewährleisten, müssen Sie die Konfigurationsaussage auf Hierarchieebene [
edit protocols pcep
] konfigurierendisable-multipath-capability
. -
Fehlercode-Unterstützung für Fehler bei der Validierung von PCE-initiierten Kandidatenpfaden
-
Die Gesamtanzahl der Pfade für Unterkandidaten pro Kandidatenpfad ist auf 127 begrenzt. Wenn die Anzahl der ERO-Pfade 127 kreuzt, wird für PCE initiierte LSPs von SR-TE ERROR an PCCD ausgegeben (und PCCD sendet PCEP-Fehlermeldung an PCE) und die entsprechenden ERO-Pfade werden abgelehnt.
-
Folgende PCEP-Fehlermeldungen werden unterstützt:
Fehlertyp | Fehlerwert | Bedeutung | Verwendung |
---|---|---|---|
19 | 20 | Backup-Pfad wird nicht unterstützt | Dies geschieht, wenn MULTIPATH-BACKUP-TLV vom PCC empfangen wird. |
24 | 1 | Inakzeptable Instanziierungsparameter | Dies geschieht, wenn PCE versucht, mehr als 127 Unterkandidatenpfade pro Kandidatenpfad hinzuzufügen. |
Einschränkungen
Es gelten die folgenden PCEP-Einschränkungen:
-
Die folgenden im Draft-ietf-pce-multipath-06 erwähnten TLVs werden nicht unterstützt:
-
Multipath-Backup-TLV
-
Multipath-Gegenrichtungspfad TLV
-
Zusammengesetzter Kandidatenpfad
-
-
Wenn die Multipath-Funktion in PCEP deaktiviert ist, ist die Konfiguration mehrerer Pfade für Subkandidaten nicht zulässig. Auf Junos-Geräten ohne Multipath-Funktion (Junos OS-Versionen früher als 22.4R1) ist jedoch die Konfiguration mehrerer Pfade für Sub-Kandidaten zulässig. Wenn PCEP-Multisegmente aktiviert ist (standardmäßig), sind für PCC-gesteuerte LSPs zum Zweck der Berichterstattung mehrere primäre Pfade zulässig. Für delegierte Kandidatenpfade wird jedoch nur ein primärer Pfad unterstützt, wenn PCEP-Multisegmente aktiviert ist.
-
Admin-Gruppen und andere Einschränkungen werden nicht an PCE für PCC-konfigurierte und kontrollierte SR-MPLS- und SRv6-Kandidatenpfade (mit einzelnen oder mehreren primären Konfigurationen) benachrichtigt. Es gibt keine Auswirkungen auf delegierte und PCE-initiierte Kandidatenpfade.
-
Wenn die PCEP-Multipath-Funktion aktiviert ist, ist die sekundäre Pfadkonfiguration für nicht delegierte Kandidatenpfade zulässig. Wenn die PCEP-Multipath-Funktion deaktiviert ist, ist die sekundäre Pfadkonfiguration nicht zulässig.
-
Kandidatenpfade können keine Mischung aus PCE-initiierten und delegierten LSPs haben.
-
Mehrere Sub-Candidate-Pfade für einen PCE-initiierten farbigen Kandidatenpfad werden nicht unterstützt.
-
Delegieren von Funktionen mit mehreren Unterkandidatenpfaden in einem Kandidatenpfad wird nicht unterstützt.
Konfiguration
Fügen Sie die propagate-max-segmentlist
Konfigurationsaussage aufedit protocols pcep
[] Hierarchieebene ein, um PCCD zu ermöglichen, mehrpfadfähige TLV im LSP-Objekt zu senden, um die maximal berechnete Segmentliste für einen bestimmten Kandidatenpfad zu benachrichtigen. Standardmäßig wird die TLV nicht im LSP-Objekt gesendet.
user@host# set protocols pcep propagate-max-computed-segmentlist;
Um die PCEP-Sitzung mit mehreren Funktionen für alle PCEs zu deaktivieren, fügen Sie die disable-multipath-capability
Konfigurationsaussage auf der Hierarchieebene [edit protocols pcep
] ein.
user@host# set protocols pcep disable-multipath-capability;
[edit protocols] pcep { disable-multipath-capability; propagate-max-segmentlist; }
Sie können die folgenden Protokoll-Traceoptionen für die Diagnose aktivieren:
-
user@host# set protocols pcep traceoptions
... -
user@host# set protocols pcep pce pce1 traceoptions
... -
user@host# set protocols source-packet-routing traceoptions
Sie können die folgenden Show-Befehle verwenden, um den Status von LSPs in PCC anzuzeigen:
-
user@host> show path-computation-client lsp
— Zeigt den Status der Label-Switched Paths (LSPs) an, die dem Path Computation Client (PCC) bekannt sind. -
user@host> show path-computation-client lsp extensive
— Zeigen Sie das umfangreiche Ausgabeniveau zu jedem bekannten LSP an – Punkt-zu-Punkt- und Point-to-Multipoint-LSPs. -
user@host> show path-computation active-pce
– Zeigt den Status von Multipath in den Sitzungen an. -
user@host> show spring-traffic-engineering lsp detail
—Anzeige der Eingangsdetails des SPRING Traffic Engineering.
Ermöglichung der Sicherheit auf Transportebene für PCEP-Sitzungen
Transport Layer Security (TLS) unterstützt Peer-Authentifizierung, Nachrichtenverschlüsselung und Integrität. Sie können TLS im Path Computation Client (PCC) aktivieren, um eine TCP-Verbindung mit dem Path Computation Element (PCE) wie in RFC 8253 definiert herzustellen. Dadurch wird eine sichere PCEP-Sitzung (PCEPS) zum Transport von PCEP-Nachrichten erstellt.
In diesem Dokument wird beschrieben, wie Sie TLS für PCEP-Sitzungen aktivieren, um Interaktionen mit PCE zu sichern, einschließlich der Einleitung der TLS-Prozeduren, des TLS-Handshake-Mechanismus und der TLS-Methoden für die Peer-Authentifizierung. Sicherer Transport für PCEP über TLS wird auch als PCEPS bezeichnet.
- Vorteile der Aktivierung von TLS für PCEP-Sitzungen
- Aktivieren von TLS in Path Computation Client (PCC)
- Aktualisieren von Zertifikaten mithilfe der Public Key Infrastructure (PKI)
- Einrichten einer TLS-Verbindung
- Grundlegendes zum TLS-Handshake-Mechanismus
- Diagnose und Validierung von TLS für PCEP-Sitzungen
- Beispielausgabe
Vorteile der Aktivierung von TLS für PCEP-Sitzungen
-
Schützt PCEP-Sitzungen vor Angriffen wie Spoofing (PCC- oder PCE-Identitätswechsel), Snooping (Nachrichtenabfangen), Fälschung und Denial of Service.
-
Nutzt die Vorteile der TLS-Sicherheit.
Aktivieren von TLS in Path Computation Client (PCC)
Um TLS in PCC zu aktivieren und eine PCEPS-Sitzung einzurichten, legen Sie die tls-strict
CLI-Anweisung auf Hierarchieebene [edit protocols pcep
] fest.
Nach der Aktivierung der tls-strengen Konfigurationsaussage passieren die folgenden Ereignisse:
-
PCEP-Sitzungsklappen. Jede vorhandene TCP-Verbindung wird beendet und eine erneute Verbindung erfolgt mithilfe von TLS.
-
PCC stellt eine TCP-Verbindung mit dem PCE her.
-
TLS-Prozeduren werden durch die StartTLS Nachricht von PCE an PCC und von PCC zu PCE initiiert. Die StartTLS Nachricht wird von PCC gesendet und der StartTLSWait Timer wird gestartet. Sie können den StartTLSWait Timer konfigurieren, indem Sie die
start-tls-wait-timer seconds
CLI-Anweisung auf der Hierarchieebene [edit protocols pcep pce pce-id
] konfigurieren.HINWEIS:Der empfohlene Wert für den StartTLSWait Timer beträgt 60 Sekunden und darf nicht niedriger als der OpenWait Timer sein. Der Standard-Timer-Wert OpenWait ist auf 60 Sekunden festgelegt.
-
Wenn die Open-Nachricht von PCC empfangen StartTLS wird, PCErr wird eine Nachricht mit Error-Type auf 1 (PcEP-Sitzungseinrichtung fehlgeschlagen) und Fehlerwert auf 1 (Empfang einer ungültigen Open-Nachricht oder einer nicht-offenen Nachricht) festgelegt, und die TCP-Sitzung wird geschlossen.
-
Wenn StartTLS eine Nachricht nicht von PCE empfangen wird, sendet PCC nach Ablauf des StartTLSWait Timers eine PCErr Nachricht mit dem Wert Error-Type auf 25 (PCEP-FehlerStartTLS) und den Fehlerwert auf 5 (keine Nachricht (nochStartTLS PCErr/Open) vor Ablauf StartTLSWait des Timers), und die TCP-Sitzung wird geschlossen.
-
-
Aushandlung und Aufbau einer TLS-Verbindung erfolgt.
-
Der Austausch von PCEP-Nachrichten wird gemäß RFC5440 gestartet.
Wenn Sie die tls-strict
CLI-Anweisung unter der Hierarchieebene [edit protocols pcep
] nicht aktivieren, dann wird beim Einrichten einer PCEP-Sitzung, wenn die StartTLS Nachricht von PCC empfangen wird, anstelle der Open Nachricht, PCErr fehlermeldungstyp ist auf 1 (PCEP-Sitzungseinrichtung fehlgeschlagen) und Fehlerwert auf 1 (Empfang einer ungültigen Open-Nachricht oder einer nicht-offenen Nachricht) festgelegt, wird die TCP-Sitzung geschlossen.
Um eine erfolgreiche PCEPS-Sitzung herzustellen, muss TLS sowohl auf PCC als auch auf PCE aktiviert sein.
Aktualisieren von Zertifikaten mithilfe der Public Key Infrastructure (PKI)
Die PKI benachrichtigt PCC nicht über den Ablauf des Zertifikats. Sie müssen das Zertifikat manuell mit dem folgenden CLI-Befehl aktualisieren. Bei dieser Methode müssen Sie das Ablaufdatum des Zertifikats im Auge behalten.
user@host> request security pki local-certificates re-enroll certificate id
Einrichten einer TLS-Verbindung
In den folgenden Schritten wird beschrieben, wie eine TLS-Verbindung (unter Verwendung von TLS v1.2) hergestellt wird:
-
Generieren Sie Zertifikate für die Knoten (Junos OS-Geräte/pce-server). Sie können die Zertifikate mit einer der folgenden Methoden generieren:
-
Method 1— Generieren Sie Schlüsselpaar und CSR auf dem Gerät und senden Sie dieses CSR an die CA, um das Zertifikat zu erhalten. Sobald das Zertifikat ausgestellt ist, wird es in das Kästchen kopiert und installiert.
-
Method 2— Generieren Sie das Schlüsselpaar und das Zertifikat sofort. Sowohl das Zertifikat als auch der private Schlüssel werden auf dem Gerät kopiert und zusammen installiert.
-
-
Laden Sie die Zertifizierungsstelle (Certification Authority, CA) auf den PCC, damit das PCE-Serverzertifikat anhand der geladenen Zertifizierungsstelle validiert werden kann.
user@host# set security pki ca-profile pccd-tls ca-identity pccd-tls user@host# commit
user@host> request security pki ca-certificate load ca-profile pccd-tls filename /var/tmp/ca.crt
HINWEIS:CAs können in einer flachen Hierarchie als unabhängige Zertifizierungsstelle geladen werden. Wenn eine Zertifizierungsstelle eine Unter-CA einer anderen CA ist, wird die Kette intern von PKI aufgebaut.
HINWEIS:Das Serverzertifikat sollte von einer Zertifizierungsstelle signiert werden. Selbstsignierte Zertifikate sind nicht erlaubt.
-
Aktivieren Sie TLS auf PCC.
-
PCEP-Sitzung wird über TLS mit TLS-Handshake-Mechanismus eingerichtet.
-
PCE-Server überwacht Port 4189 auf eingehende PCC-Verbindungsanfragen über TLS.
-
PCC initiiert die Verbindungsanfrage zum Ziel-Port 4189.
-
Nach Abschluss eines Drei-Wege-Handshakes beginnt der TLS-Handshake mit der Verwendung der Zertifikate und die One-Way-Authentifizierung ist durchgeführt (PCC authentifiziert das Serverzertifikat). Sowohl der Server als auch der Client warten, StartTLSWait bis die StartTLS Nachricht empfangen wird. Sie können den StartTLSWait Timer konfigurieren, indem Sie die
start-tls-wait-timer seconds
CLI-Anweisung auf der Hierarchieebene [edit protocols pcep pce pce-id
] konfigurieren.HINWEIS:Der empfohlene Wert für den StartTLSWait Timer beträgt 60 Sekunden und darf nicht niedriger als der OpenWait Timer sein. Der Standard-Timer-Wert OpenWait ist auf 60 Sekunden festgelegt.
-
Nach der erfolgreichen TLS-Handshake-Sitzung initiiert PCC und PCE die Einrichtung der PCEP-Sitzung über TLS, während der die Sitzungsparameter ausgehandelt werden.
-
Wenn die Zertifikatsvalidierung fehlschlägt, beendet PCC die TCP-Verbindung.
-
-
PCEP-Nachricht wird über TLS-Verbindung als Anwendungsdaten gesendet.
-
Die Verschlüsselung und Entschlüsselung erfolgt sowohl auf PCC als auch auf PCE nach einem erfolgreichen TLS-Handshake.
-
Wenn die PCEP-Sitzung geschlossen wird, wird die TLS-Sitzung entfernt.
Wenn das Zertifikat während einer laufenden PCEP-über-TLS-Sitzung abgelaufen, widerrufen oder neu geladen wird, ist die laufende Sitzung nicht betroffen.
Grundlegendes zum TLS-Handshake-Mechanismus
Der Handshake ist eine Serie von Nachrichten, die zwischen einem Server und einem Client ausgetauscht werden. Die genauen Schritte im Handshake variieren je nach Schlüsselaustauschalgorithmus, Cipher Suite usw. Im Folgenden werden die grundlegenden Schritte zum TLS-Handshake-Mechanismus beschrieben:
-
Client Hello— Der Client initiiert den Handshake, indem er diese Nachricht sendet. Diese Nachricht enthält TLS-Version, eine Liste der unterstützten Kryptografiealgorithmen oder Cipher Suite und andere Client-Details.
-
Server Hello— Der Server antwortet auf "Client Hello", indem er eine Sever-Hallo-Nachricht sendet. Diese Nachricht enthält Serverzertifikat, ausgewählten Kryptografiealgorithmus, Sitzungs-ID und den öffentlichen Schlüssel des Servers.
-
Authentication— Der Client im Hintergrund überprüft das Serverzertifikat mit einer konfigurierten Zertifizierungsstelle, die das Zertifikat ausgestellt hatte. Bei erfolgreicher Überprüfung bestätigt der Client, dass der Server echt ist und interagiert weiter.
-
Optional Client Certificate— Wenn der Server in der Server Hello-Nachricht ein Zertifikat vom Client angefordert hat, sendet der Client das Client-Zertifikat (nur im Fall von gegenseitigem TLS).
-
Client Key Exchange— Der Client sendet einen geheimen Schlüssel, der mit dem öffentlichen Schlüssel des Servers verschlüsselt ist (in der Nachricht "Server Hallo" erfasst).
-
Decrypt secret key— Der Server entschlüsselt den geheimen Schlüssel mithilfe des privaten Schlüssels.
-
Client Finished— Der Client sendet eine Finish-Nachricht, die mit dem gemeinsam genutzten geheimen Schlüssel verschlüsselt ist, und signalisiert den Handshake "Complete".
-
Server Finished— Der Server antwortet mit einer Endnachricht, die mit dem gemeinsam genutzten geheimen Schlüssel verschlüsselt ist, und signalisiert den Handshake "Complete".
-
Exchange Messages— Die Nachrichten nach dem Handshake-Abschluss werden symmetrisch verschlüsselt.
Diagnose und Validierung von TLS für PCEP-Sitzungen
Verwenden Sie für Diagnosen die folgenden CLI-Anweisungen für Traceoptions:
user@host# set protocols pcep traceoptions … user@host# set protocols pcep pce pce-id traceoptions … user@host# set protocols source-packet-routing traceoptions
Aktivieren Sie PKI-Protokolle mit der folgenden Konfiguration und erfassen Sie dieselbe Datei von /var/log/<filename>
user@host# set security pki traceoptions file <filename> user@host# set security pki traceoptions flag all sss
Überprüfen Sie das geladene CA-Zertifikat mit dem folgenden Befehl:
user@host> show security pki ca-certificate detail
Beispielausgabe
Im Folgenden sehen Sie eine Beispielausgabe des show path-computation-client statistics
Befehls:
user@host> show path-computation-client statistics Warning: License key missing; requires 'PCEP' license PCE ns1 -------------------------------------------- General PCE IP address : 192.168.18.1 Local IP address : 190.168.18.101 Priority : 0 PCE status : PCE_STATE_UP Session type : PCE_TYPE_STATEFULACTIVE LSP provisioning allowed : On P2MP LSP report allowed : On P2MP LSP update allowed : On P2MP LSP init allowed : On Session SRv6 Capable : No PCE-mastership : main PCE Traffic Steering : Off PCC TLS Enabled : Yes PCE TLS Enabled : Yes Session TLS Enabled : Yes Counters PCReqs Total: 0 last 5min: 0 last hour: 0 PCReps Total: 0 last 5min: 0 last hour: 0 PCRpts Total: 0 last 5min: 0 last hour: 0 PCUpdates Total: 0 last 5min: 0 last hour: 0 PCCreates Total: 0 last 5min: 0 last hour: 0 Timers Local Keepalive timer: 0 [s] Dead timer: 0 [s] LSP cleanup timer: - [s] Remote Keepalive timer: 0 [s] Dead timer: 0 [s] LSP cleanup timer: - [s] Errors PCErr-recv PCErr-sent PCE-PCC-NTFS PCC-PCE-NTFS Pcupdate empty ero action counters Send-err : 0 Tear down path : 0 Routing decision : 0 Routing decision failed: 0
Diese Beispielausgabe bietet die folgenden Informationen:
-
TLS ist bei PCC aktiviert.
-
PCE ist TLS-fähig.
-
TLS-Sitzung eingerichtet. Dies zeigt auch an, dass das PCE-Serverzertifikat gültig ist.
-
Der PCEPS-Sitzungsstatus ist einsatzbereit.
Berichtspfadoptimierung und berechnete Metriken in PCEP
Das Metrikobjekt in PCEP wird für mehrere Zwecke verwendet. Das Metrikobjekt gibt den Metriktyp an, der für die Pfadoptimierung verwendet wird. Das Metrikobjekt gibt auch eine Bindung an die Pfadkosten an, die nicht überschritten werden darf, damit der Pfad als akzeptabel angesehen wird. Das Metrikobjekt gibt auch die berechnete Metrik an.
Wir unterstützen Kennzahlobjekte für die Pfadoptimierung (Interior Gateway Protocol, Traffic Engineering und Pfadverzögerung) und Berichterstellung von berechneten Metriken für RSVP- und SR-TE-LSPs.
Metrikobjekt zur Pfadoptimierung und Berichterstattung von berechneten Metriken ist für SRv6-TE-LSPs nicht anwendbar.
- Vorteile von Berichtspfadoptimierung und berechneten Metriken in PCEP
- Verständnis der Optimierungsmetriken
- Konfigurieren von Optimierungsmetriken für LSPs
- Beispielausgabe
Vorteile von Berichtspfadoptimierung und berechneten Metriken in PCEP
-
Die Berichterstattung über in PCC konfigurierte Pfadoptimierungsmetriken hilft PCE, sich der Einschränkungen bewusst zu sein, die für die Pfadberechnung verwendet werden.
-
Berichterstellung von berechneten Metriken an den PCE. Auf diese Weise kann PCE analysieren, ob der LSP eine weitere Optimierung erfordert.
Verständnis der Optimierungsmetriken
Im folgenden Abschnitt werden die beabsichtigten und tatsächlichen Optimierungsmetriken für RSVP- und SR-TE (SR MPLS)-LSPs in PCEP beschrieben.
- Lokal erstellte RSVP-LSP
- Delegierter RSVP-LSP
- PCE-initiierter RSVP-LSP
- Delegierter SR-TE-LSP
- PCE-initiierter SR-TE LSP
- Senden der Optimierungskennzahl in PCRpt-Nachricht
- Senden einer rechnergestützten Metrik in PCRpt-Nachricht
- Abwärtskompatibilität für Routing-Metrik
Lokal erstellte RSVP-LSP
Um die lokal erstellten RSVP-LSPs mit Metriken zu optimieren, konfigurieren Sie die Optimierungsmetriken (IGP, TE und Pfadverzögerung), sodass die konfigurierte Metrik über PCEP gemeldet wird. Die berechnete Metrik wird als tatsächliche Metrik in PCEP durch die PCRpt-Nachricht gesendet.
Delegierter RSVP-LSP
Um die Optimierungsmetriken für delegierte RSVP-LSPs zu melden, konfigurieren Sie die Optimierungsmetriken (IGP, TE und Pfadverzögerung).
Intended Metric:
-
Wenn die Optimierungskennzahl zum Zeitpunkt der Delegierung des LSP konfiguriert ist, werden die Informationen über die PCRpt-Nachricht an PCE gesendet.
-
Wenn die Optimierungskennzahl nach der Delegierung von LSP konfiguriert wird, wird die Änderung auf dem LSP angewendet/an den PCE übermittelt, wenn der LSP-Steuerungsstatus lokal gesteuert wird.
-
Wenn die PCUpd-Nachricht empfangen wird und die Optimierungskennzahl in der Nachricht vorhanden ist, wird die Metrik in den nachfolgenden PCRpt-Meldungen als beabsichtigte Metrik verwendet, bis der LSP-Kontrollstatus extern gesteuert wird.
-
Wenn die PCUpd-Nachricht empfangen wird und die Optimierungskennzahl in der Nachricht nicht vorhanden ist, enthalten nachfolgende PCRpt-Meldungen keine beabsichtigte Metrik.
-
Wenn sich der Status der LSP-Steuerung in lokal gesteuert ändert, wird die über Junos CLI konfigurierte Optimierungskennzahl die beabsichtigte Metrik in der PCRpt-Meldung.
Actual Metric:
-
Während der Delegierung des LSP enthält die PCRpt-Nachricht keine tatsächliche Metrik.
-
Wenn eine PCUpd-Nachricht empfangen wird und eine berechnete Metrik in der Nachricht vorhanden ist, wird die Metrik in den nachfolgenden PCRpt-Meldungen als tatsächliche Metrik verwendet, bis der LSP-Kontrollstatus extern gesteuert wird.
-
Wenn eine PCUpd-Nachricht empfangen wird, wenn keine berechnete Metrik in der Nachricht vorhanden ist, enthalten die nachfolgenden PCRpt-Meldungen keine tatsächliche Metrik.
-
Wenn sich der Status der LSP-Steuerung in lokal gesteuert ändert, wird die von PCC berechnete Metrik in der PCRpt-Nachricht als tatsächliche Metrik gesendet.
PCE-initiierter RSVP-LSP
Um die Optimierungsmetriken für PCE-initiierte RSVP-LSPs zu melden, konfigurieren Sie die Optimierungsmetriken (IGP, TE und Pfadverzögerung) in einer Vorlage. Die Vorlage wird dann auf den PCE-initatierten LSP angewendet, wenn der LSP-Steuerungsstatus lokal gesteuert wird.
Intended Metric:
-
Wenn ein PCE-initiierter LSP einer Vorlage mit Optimierungsmetrik zugeordnet wird, wird die Konfiguration auf den LSP angewendet und an den PCE gesendet, wenn sich der LSP-Steuerungsstatus auf lokal gesteuert ändert.
-
Wenn die PCInit/PCUpd-Nachricht empfangen wird und die Optimierungskennzahl in der Nachricht vorhanden ist, wird die Metrik in den nachfolgenden PCRpt-Meldungen wie vorgesehen verwendet, bis der LSP-Kontrollstatus extern gesteuert wird.
-
Wenn die PCInit/PCUpd-Nachricht empfangen wird und keine Optimierungskennzahl in der Nachricht vorhanden ist, enthalten die nachfolgenden PCRpt-Meldungen keine beabsichtigte Metrik.
-
Wenn der LSP-Steuerungsstatus lokal gesteuert wird, wird die in der Vorlage vorhandene Optimierungsmetrik als beabsichtigte Metrik in der PCRpt-Nachricht verwendet.
Actual Metric:
-
Wenn eine PCInit/PCUpd-Nachricht empfangen wird und die berechnete Metrik in der Nachricht vorhanden ist, wird die Metrik in den nachfolgenden PCRpt-Meldungen als tatsächliche Metrik verwendet, bis der LSP-Kontrollstatus extern gesteuert wird.
-
Wenn die pcInit/PCUpd-Nachricht empfangen wird, enthalten die nachfolgenden PCRpt-Meldungen keine tatsächliche Metrik, wenn die berechnete Metrik in der Nachricht nicht vorhanden ist.
-
Wenn sich der Status der LSP-Steuerung in lokal gesteuert ändert, wird die von PCC berechnete Metrik in der PCRpt-Nachricht als tatsächliche Metrik gesendet.
Delegierter SR-TE-LSP
Um die Optimierungsmetriken für delegierte SR-TE (SR MPLS)-LSPs zu melden, konfigurieren Sie die Optimierungsmetriken (IGP, TE und Pfadverzögerung).
Intended Metric:
-
Wenn die Optimierungskennzahl zum Zeitpunkt der Delegierung von LSP konfiguriert ist, werden die Informationen über die PCRpt-Nachricht an den PCE gesendet.
-
Wenn die Optimierungskennzahl nach der Delegierung von LSP konfiguriert wird, wird die Änderung auf dem LSP angewendet/an den PCE übermittelt, wenn der LSP-Steuerungsstatus lokal gesteuert wird.
-
Wenn die PCUpd-Nachricht empfangen wird und die Optimierungskennzahl in der Nachricht vorhanden ist, wird die Metrik in den nachfolgenden PCRpt-Meldungen als beabsichtigte Metrik verwendet, bis der LSP-Kontrollstatus extern gesteuert wird.
-
Wenn die PCUpd-Nachricht empfangen wird und die Optimierungskennzahl in der Nachricht nicht vorhanden ist, enthalten nachfolgende PCRpt-Meldungen keine beabsichtigte Metrik.
-
Wenn sich der Status der LSP-Steuerung in lokal gesteuert ändert, wird die über Junos CLI konfigurierte Optimierungskennzahl die beabsichtigte Metrik in der PCRpt-Meldung.
Actual Metric:
-
Wenn LSP nach der Erstellung delegiert wird, werden zum Zeitpunkt der LSP-Delegierung, wenn LSP 1 ERO hat, berechnete Werte von IGP, TE und Verzögerungsmetriken als tatsächliche Metriken in der PCRpt-Nachricht gesendet.
-
Wenn LSP nach der Erstellung delegiert wird, zum Zeitpunkt der LSP-Delegierung, wenn LSP mehrere EROs hat, wird die berechnete/tatsächliche Metrik nicht in der PCRpt-Nachricht gesendet, da die tatsächliche Metrik pro LSP (nicht pro ERO) in PCEP gesendet werden muss.
-
Wenn eine PCUpd-Nachricht empfangen wird und eine berechnete Metrik in der Nachricht vorhanden ist, wird die Metrik in den nachfolgenden PCRpt-Meldungen als tatsächliche Metrik verwendet, bis der LSP-Kontrollstatus extern gesteuert wird.
-
Wenn eine PCUpd-Nachricht empfangen wird, wenn keine berechnete Metrik in der Nachricht vorhanden ist, enthalten die nachfolgenden PCRpt-Meldungen keine tatsächliche Metrik.
-
Wenn sich der Status der LSP-Steuerung in lokal gesteuert ändert, werden IGP-, TE- und Verzögerungsmetriken, die in PCC berechnet werden, als tatsächliche Metriken in der PCRpt-Nachricht gesendet.
PCE-initiierter SR-TE LSP
Beabsichtigte Metriken oder tatsächliche Metriken, die von PCE in PCInit/PCUpd-Nachrichten gesendet werden, werden über PCRpt-Nachricht an PCE zurückgemeldet, bis der LSP extern kontrolliert wird.
Intended Metric:
-
Wenn die PCInit/PCUpd-Nachricht empfangen wird und die Optimierungskennzahl in der Nachricht vorhanden ist, wird die Metrik in den nachfolgenden PCRpt-Meldungen wie vorgesehen verwendet, bis der LSP-Kontrollstatus extern gesteuert wird.
-
Wenn die PCInit/PCUpd-Nachricht empfangen wird und keine Optimierungskennzahl in der Nachricht vorhanden ist, enthalten die nachfolgenden PCRpt-Meldungen keine beabsichtigte Metrik.
-
Wenn der LSP-Steuerungsstatus lokal gesteuert wird, wird die beabsichtigte Metrik nicht gesendet.
Actual Metric:
-
Wenn die PCInit/PCUpd-Nachricht empfangen wird und eine berechnete Metrik in der Nachricht vorhanden ist, wird die Metrik in den nachfolgenden PCRpt-Meldungen als tatsächliche Metrik verwendet, bis der LSP-Kontrollstatus extern gesteuert wird.
-
Wenn die PCInit/PCUpd-Nachricht empfangen wird, enthalten die nachfolgenden PCRpt-Meldungen keine tatsächliche Metrik, wenn in der Nachricht keine berechnete Metrik vorhanden ist.
-
Wenn sich der LSP-Steuerungsstatus in lokal gesteuert ändert, enthalten nachfolgende PCRpt-Nachrichten keine tatsächliche Metrik.
Senden der Optimierungskennzahl in PCRpt-Nachricht
Die Optimierungskennzahl wird über intended-attributes-list
die in-PCRpt-Nachricht an den PCE gesendet. Der Metrikwert ist auf 0 und B, C-Flags auf 0 festgelegt. Der Metriktyp gibt die zu optimierenden Metrik an.
Senden einer rechnergestützten Metrik in PCRpt-Nachricht
Die berechnete Metrik wird durch actual-attributes-list
die in-PCRpt-Nachricht an den PCE gesendet. Der Metrikwert ist der berechnete Metrikwert und der Metriktyp gibt den berechneten Metriktyp an. B-Flag ist auf 0 und C-Flag auf 1 gesetzt.
Abwärtskompatibilität für Routing-Metrik
Da die Routenmetrik mithilfe von Anbieter-TLV unterstützt wird, verarbeitet PCC keine Routenmetrik, die von Juniper PCE gesendet wird, die Northstar und ältere Versionen von paragon Pathfinder unterstützt.
Konfigurieren von Optimierungsmetriken für LSPs
Sie können Optimierungsmetriken (IGP, TE und Pfadverzögerung) für RSVP-LSPs und SR-TE LSP konfigurieren.
Um die IGP-, TE- und Pfadverzögerungsoptimierungsmetriken für RSVP-LSPs zu konfigurieren, fügen Sie die metric-type <igp|te|delay|delay minimum>
CLI-Anweisung auf der Hierarchieebene [edit protocols mpls label-switched-path <lsp-name>
] ein.
Um die IGP-, TE- und Pfadverzögerungsoptimierungsmetriken für SR-TE-LSPs zu konfigurieren, fügen Sie die metric-type <igp|te|delay|delay minimum>
CLI-Anweisung auf der Hierarchieebene [edit protocols source-packet-routing compute-profile <compute-profile-name>
] ein.
Beispielausgabe
Sie können die show path-computation-client lsp
Cli-Befehle verwenden show path-computation-client lsp extensive
, um den Status von Label-Switched Paths (LSPs) anzuzeigen, die dem Path Computation Client (PCC) bekannt sind.
Im Folgenden wird eine Beispielausgabe von show path-computation-client lsp extensive
:
user@host> show path-computation-client lsp extensive name sr_lsp
LSP Name : sr_lsp
PathName : -
From : 192.168.1.101
To : 192.168.1.106
Path Setup Type : spring-te
State : Up
Active Path : Yes
Link Protection : none
LSP Type : ext-provised
P2mp tree : NULL
Path cspf status : external_cspf
Controller : ns1
Template : NULL
PLSP-ID : 31
LSP-ID : 0
RSVP Error : 0x0
Requested AutoBw : 0bps
Record Route : (Label=299792)
From PCE ERO (received) : (Label=299792)
From RPD ERO (reported) : (Label=299792)
Configured ERO on PCC : Not Supported
Bandwidth:
Intended : 98.76Kbps
Actual : 0bps
Intended Metric:
Metric type Bound Optimization
IGP 0 TRUE
Actual Metric:
Metric type Computed value
IGP 50
Route Metric : 50
Mapped Flowspec (FS-Ids) : -
LSP Attributes:
Exclude-Any: 0, Include-Any: 0, Include-All: 0
Setup Priority: 0, Hold-Priority: 0
Local Protection Bit: FALSE
Last Rpt/Pcreqest received from RPD at : 22:15:32.000
Last Update sent to PCE at : 16:00:00.000
Last PcUpdate/PcCreate received from PCE at : 22:15:32.000
Last error sent to PCE at : 16:00:00.000
Last 5 reasons to send Report/Pcrequest : , , , ,
Die Ausgabe zeigt, dass der LSP mit der Metrik Typ IGP optimiert ist. Der berechnete Wert der IGP-Metrik ist 50. Die in der Routing-Tabelle installierte Route-Metrik ist 50.
external cspf
den PCE-gesteuerten LSPs zwei neue Pfadberechnungstypen eingeführt: local cspf
und no cspf
.