Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
Auf dieser Seite
 

LSP-Konfiguration für Segment-Routing

Aktivieren von verteiltem CSPF für Segment-Routing-LSPs

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

Verteilte CSPF-Berechnungseinschränkungen

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

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

  • Ein- und Ausschluss administrativer Gruppen.

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

    HINWEIS:

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

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

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

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

  • IPV6-Adressen.

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

  • Nicht nummerierte Schnittstellen.

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

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

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

Verteilter CSPF-Berechnungsalgorithmus

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

Aktivierte Etikettenstapelkomprimierung

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

Label-Stack-Komprimierung deaktiviert

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

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

  • Jede Segmentliste enthält benachbarte SIDs.

  • Der Wert von 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 Beschränkungen.

Verteilte CSPF-Berechnungsdatenbank

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

Konfigurieren verteilter CSPF-Berechnungseinschränkungen

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

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

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

  • Administrative groups

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

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

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

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

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

  • Explicit path

    Sie können eine Reihe von Router-IDs im Computeprofil als Einschränkung für die Berechnung der SR-TE-Kandidatenpfade angeben. Jeder Hop muss eine IPv4-Adresse sein und kann vom Typ strict oder loose sein. Wenn der Typ eines Hops nicht konfiguriert ist, wird strict verwendet. Sie müssen die compute Option unter der segment-list-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 dynamischer Segmentlisten verknüpfen. Bei den Pfaden handelt es sich um ECMP-Pfade, bei denen jede Segmentliste in ein Next-Hop-Gateway mit aktiver Gewichtung übersetzt wird. Diese Pfade sind das Ergebnis der Pfadberechnung mit oder ohne Komprimierung.

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

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

  • Protected or unprotected adjacency SIDs

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

  • Metric type

    Sie können den Typ der Metrik auf dem Link angeben, der für die Berechnung verwendet werden soll. Standardmäßig verwenden SR-TE-Sprachdienstleister für die Berechnung Traffic-Engineering-Metriken der Verbindungen. Die Traffic-Engineering-Metrik für Links wird durch Traffic-Engineering-Erweiterungen von IGP-Protokollen angekündigt. Sie können jedoch auch die IGP-Metrik für die Berechnung verwenden, indem Sie die Konfiguration vom Typ "metric" im Computeprofil verwenden.

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

Verteilte CSPF-Berechnung

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

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

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

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

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

Sie können Gewichtungen für berechnete und statische SR-TE-Pfade konfigurieren, die zu den nächsten Hops der Route beitragen. Ein einzelner Pfad, für den die Berechnung aktiviert ist, kann jedoch zu mehreren Segmentlisten führen. Diese berechneten Segmentlisten werden untereinander als ECMP behandelt. Sie können diesen Segmenten hierarchische ECMP-Gewichtungen zuweisen, wobei die Gewichtungen berücksichtigt werden, die den einzelnen konfigurierten primären Segmenten zugewiesen sind.

BFD-Lebendigkeitserkennung

Sie können die BFD-Lebendigkeitserkennung für die berechneten primären oder sekundären Pfade konfigurieren. Jeder berechnete primäre oder sekundäre Pfad kann zu mehreren Segmentlisten führen, daher werden die BFD-Parameter, die für die Segmentlisten konfiguriert sind, auf alle berechneten Segmentlisten angewendet. Wenn alle aktiven Primärpfade ausfallen, wird der vorprogrammierte Sekundärpfad (falls vorhanden) aktiv.

inherit-label-nexthops

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

Automatische Übersetzungsfunktion

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

Beispielkonfigurationen für verteilte CSPF-Berechnungen

Beispiel 1

In Beispiel 1

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

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

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

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

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

Nächster Hop

Gewicht

comp_nh1

2

comp_nh2

2

comp_nh3

2

static_nh

9

Beispiel 2

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

Beispiel 3

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

Statisches Segment-Routing-Label Switched-Pfad

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

Grundlegendes zum statischen Segment-Routing LSP in MPLS-Netzwerken

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

Einführung in Segment-Routing-LSPs

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

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

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

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

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

Zum Beispiel:

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

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

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

Vorteile der Verwendung von Segment-Routing-LSPs

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

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

Farbiges statisches Segment-Routing LSP

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

Grundlegendes zu farbigen LSPs für das Routing statischer Segmente

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

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

Segmentliste der LSPs für farbiges Segment-Routing

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

Nicht farbiges statisches Segment-Routing LSP

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

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

Grundlegendes zum Routing von LSPs für nicht farbige Segmente

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

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

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

HINWEIS:

Für den Fall, dass ein statischer, nicht eingefärbter Segment-Routing-LSP und ein von PCEP erstellter Segment-Routing-LSP nebeneinander existieren und dieselbe zu adressieren haben, die zur gleichen Eingangsroute beiträgt, wenn sie auch die gleiche Präferenz haben. Andernfalls wird das Segment-Routing-LSP mit der besten Präferenz für die Route installiert.

Segmentliste der nicht-farbigen Segment-Routing-LSPs

Eine Segmentliste besteht aus einer Liste von Hops. Diese Hops basieren auf der SID-Bezeichnung oder einer IP-Adresse. Die Anzahl der SID-Bezeichnungen in der Segmentliste sollte den maximalen Grenzwert für Segmentlisten nicht überschreiten. Die maximale Segmentlistenbindung an einen LSP-Tunnel wurde von 8 auf 128 erhöht, mit maximal 1000 Tunneln pro System. Pro LSP für statisches Segmentrouting werden maximal 128 primäre Pfade unterstützt. Sie können das maximale Limit für Segmentlisten auf Hierarchieebene [edit protocols source-packet-routing] konfigurieren.

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

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

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

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

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

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, die sowohl Bezeichnungen als auch IP-Adresse im ersten Hop enthalten und mit der Anweisung konfiguriert sind inherit-label-nexthops , mithilfe von SID-Bezeichnungen aufgelöst.

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

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

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

First Hop – Spezifikation

Modus der LSP-Auflösung

Nur IP-Adresse

Zum Beispiel:

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

Die Segmentliste wird anhand der IP-Adresse aufgelöst.

Nur SID

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

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

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

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

Zum Beispiel:

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

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

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

Zum Beispiel:

HINWEIS:

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

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

    Zum Beispiel:

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

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

    Zum Beispiel:

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

Statisches Segment-Routing LSP-Bereitstellung

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

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

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

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

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

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

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

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

Dynamische Erstellung von Segment-Routing-LSPs

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

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

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

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

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

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

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

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

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

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

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

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

Dynamisches Segment-Routing LSP-Beispielkonfiguration

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

Farbige dynamische Segment-Routing-LSPs

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

Wenn der BGP-Dienst PNH 10.22.44.0/24 mit der Farbgemeinschaft 123/124/125 ist, wird die SR-TE-Vorlage sr_lsp1 verwendet, um einen Tunnel zu erstellen. Jede andere Farbe für dasselbe PNH-Präfix verwendet aufgrund der Konfiguration sr_lsp2 Vorlage color-any .

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

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

  2. inet6color.0 tunnel route  ffff::10.22.44.0-0/120 --> RT_NH_TUNNEL

  3. BGP prefix to tunnel mapping 

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

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

    R1(Präfix) -> ffff::10.22.44.55-124(PNH) LSP-Tunnelname = 10.22.44.55:7c:dt-srte-tunnel1

  4. inetcolor.0 tunnel route 

    10.22.44.55-101/64 --> <nächster-hop>

    10.22.44.55-124/64 --> <nächster-hop>

  5. inet6color.0 tunnel route:

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

    ffff::10.22.44.55-124/160 --> <next-hop>

Der farbige 101-Tunnel (10.22.44.55:65:dt-srte-tunnel1) wird aufgrund der color-any Konfiguration erstellt.

Die IPv6-Routen in inet6color.0 sind konfigurationsbedingt mpls ipv6-tunneling . IPv6-Routen mit Farbgemeinschaft können über die Tabelle inet6color.0 aufgelöst werden, indem in der Routing-Tabelle inetcolor.0 gespeicherte SR-TE-Routen in IPv4-zugeordnete IPv6-Adressen konvertiert und dann in die Routing-Tabelle inet6color.0 kopiert werden.

Nicht farbige LSPs für dynamisches Segment-Routing

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

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

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

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

  3. BGP prefix to tunnel mapping 

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

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

  4. inet.3 tunnel route  10.33.44.55/32 --> <nächster-hop>

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

Der ungefärbte Tunnel (10.33.44.55:dt-srte-tunnel2) wird mit dynamic-tunnel tunnel2 erstellt, da keine Farbe konfiguriert ist. Die IPv6-Routen in inet6.3 sind konfigurationsbedingt mpls ipv6-tunneling . IPv6-Routen können über ein MPLS-Netzwerk aufgelöst werden, indem in der inet.3-Routing-Tabelle gespeicherte SR-TE-Routen in IPv4-zugeordnete IPv6-Adressen konvertiert und dann in die inet6.3-Routing-Tabelle kopiert werden.

Ungelöster dynamischer Segment-Routing-LSP

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

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

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

  2. inet6color.0 tunnel route  ffff::10.33.44.0 - 0/120 --> RT_NH_TUNNEL ffff::10.1.1.0 - 0 /24 --> RT_NH_TUNNEL

  3. BGP prefix to tunnel mapping  R1(Präfix) -> 10.33.44.55-124(PNH) Der Tunnel wird nicht erstellt. (Vorlage für die Farbe nicht gefunden).

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

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

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

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

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

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

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

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

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

  • In der 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

  • Exportieren von Richtliniendiensten

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

  • Layer 3-VPN

  • Layer 2-VPN

  • Multipath-Konfigurationen

Verhalten mit mehreren Tunnelquellen im Segment-Routing

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

Einschränkungen von dynamischen Segment-Routing-LSPs

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

  • IPv6-Segment-Routing-Tunnel.

  • Statische Tunnel.

  • 6PE wird nicht unterstützt.

  • Verteiltes CSPF.

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

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

Farbbasiertes Mapping von VPN-Diensten

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

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

VPN-Dienst-Coloring

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

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

  • Pro Routing-Instanz.

  • Pro BGP-Gruppe.

  • Pro BGP-Nachbar.

  • Pro Präfix.

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

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

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

  • BGP-Exportrichtlinie auf dem Ausgangsgerät.

  • BGP-Importrichtlinie auf dem Eingangsgerät.

  • VRF-Importrichtlinie auf dem Eingangsgerät.

Die beiden Modi der VPN-Dienstfärbung sind:

Farbzuweisung für Ausgang

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

Zum Beispiel:

Oder

HINWEIS:

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

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

Zuweisung von Eingangsfarben

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

Zum Beispiel:

Oder

Festlegen des VPN-Dienstzuordnungsmodus

Um flexible Zuordnungsmodi für VPN-Dienste 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 Gruppennachbarimport eines VPN-Diensts auf der [edit protocols bgp] Hierarchieebene referenzieren. Alle VPN-Routen, die der Routing-Richtlinie entsprechen, werden mit der angegebenen Auflösungskarte verknüpft.

Zum Beispiel:

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

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

HINWEIS:

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

Color-IP-Protokoll Next Hop Auflösung

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

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

Zum Beispiel:

Fallback auf IP-Protokoll Next Hop Resolution

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

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

Farbbasiertes BGP-Labeled-Unicast-Mapping über SR-TE

Ab Junos OS Version 20.2R1 kann BGP Labeled Unicast (BGP-LU) IPv4- oder IPv6-Routen über Segment-Routing-Traffic Engineering (SR-TE) sowohl für IPv4- als auch für IPv6-Adressfamilien auflösen. BGP-LU unterstützt die Zuordnung einer BGP-Community-Farbe und die Definition einer resolution map für SR-TE. Es wird ein nächster Hop für ein farbiges Protokoll erstellt, das in einem farbigen SR-TE-Tunnel in der inetcolor.0 Tabelle "oder inet6color.0 " aufgelöst wird. BGP-Verwendungen inet.3 und inet6.3 -Tabellen für nicht-farbbasiertes Mapping. Auf diese Weise können Sie BGP-LU-IPv6- und IPv4-Präfixe mit einer IPv6-Next-Hop-Adresse in reinen IPv6-Netzwerken ankündigen, in denen Router keine IPv4-Adressen konfiguriert haben. Mit dieser Funktion unterstützen wir derzeit BGP IPv6 LU über SR-TE mit IS-IS-Underlay.

In Abbildung 1konfiguriert 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 zur 2001:db8::3701:2d05-Schnittstelle in Router D. BGP importiert Richtlinien, um dem empfangenen Präfix 2001:db8::3700:6/128 eine Farb- und Auflösungszuordnung zuzuweisen. Basierend auf der zugewiesenen Community-Farbe löst BGP-LU den farbigen nächsten Hop für das BGP-IPv6-LU-Präfix gemäß der zugewiesenen Auflösungszuordnungsrichtlinie auf.

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

BGP-LU unterstützt die folgenden Szenarien:

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

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

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

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

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

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

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

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

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

  • BGP Layer 2 VPN (Kompella Layer 2 VPN)

  • BGP-EVPN

  • Auflösungskarte mit einer einzigen IP-Farboption.

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

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

  • Farbiges SR-TE LSP.

  • Virtuelle Plattformen.

  • 64-Bit-Junos-Betriebssystem.

  • Logische Systeme.

  • BGP mit Unicast-Bezeichnung.

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

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

  • Layer-2-Schaltung

  • Automatisch erkanntes FEC-129 BGP und LDP-signalisiertes Layer-2-VPN.

  • VPLS

  • MVPN

  • IPv4 und IPv6 mit Resolution-Map.

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

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

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

So konfigurieren Sie eine Vorlage:

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

  2. Fügen Sie die source-routing-path-template-map-Anweisung auf Hierarchieebene [edit protocols source-packet-routing] ein, um die Richtlinienanweisungen aufzulisten, anhand derer der PCE-initiierte LSP überprüft werden soll.

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

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

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

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

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

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

  • PCEP LSP übernimmt nicht die Konfiguration der Vorlagensegmentliste.

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

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

Anforderungen

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

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

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

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

Überblick

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

Topologie

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

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

Konfiguration

CLI-Schnellkonfiguration

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

PE1

PE2

PE3

PE4

PE5

CE1

CE2

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

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

So konfigurieren Sie Gerät PE1:

  1. Konfigurieren Sie die Schnittstellen.

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

  3. Konfigurieren Sie die Schnittstellen mit dem MPLS-Protokoll und den MPLS-Labelbereich.

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

  5. Konfigurieren Sie die Protokollbereichsschnittstellen.

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

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

  8. Konfigurieren Sie Richtlinienoptionen.

  9. Konfigurieren Sie BGP-Community-Informationen.

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

Ergebnisse

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

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

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

  1. Konfigurieren Sie die Schnittstellen.

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

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

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

Ergebnisse

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

Verifizierung

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

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

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

Action!

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

Bedeutung

Die Ausgabe zeigt die Eingangsrouten von Segmentrouting-Tunneln an.

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

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

Action!

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

Bedeutung

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

Verifizieren des SPRING Traffic Engineered LSP des Routers PE1
Zweck

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

Action!

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

Bedeutung

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

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

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

Action!

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

Bedeutung

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

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

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

Action!

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

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

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

Action!

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

Bedeutung

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

Routing-Engine-basiertes S-BFD für Segment-Routing-Traffic-Engineering mit First-Hop-Label-Auflösung

Sie können nahtlose Bidirectional Forwarding Detection (S-BFD) über nicht farbige und farbige Label-Switched Paths (LSPs) mit First-Hop-Label-Auflösung ausführen und S-BFD als schnellen Mechanismus zur Erkennung von Pfadfehlern verwenden.

Grundlegendes zu RE-basiertem S-BFD für Segment-Routing-Traffic-Engineering mit First-Hop-Label-Auflösung

Statische S-BFD-Segment-Routing-Tunnel für First-Hop-Labels

Die Segment-Routing-Architektur ermöglicht es Eingangsknoten in einem Core-Netzwerk, den Datenverkehr über explizite Pfade durch das Netzwerk zu leiten. Der nächste Hop für Segment-Routing Traffic Engineering (TE) ist eine oder mehrere Listen von Segmentbezeichnern (SIDs). Diese Segmentlisten stellen Pfade im Netzwerk dar, die eingehender Datenverkehr nehmen soll. Der eingehende Datenverkehr kann als IP-Datenverkehr gekennzeichnet sein, und der Weiterleitungsvorgang am Eingangsknoten kann ein Label-Swap oder ein zielbasierter Lookup sein, um den Datenverkehr auf diese Segment-Routing-TE-Pfade im Weiterleitungspfad zu leiten.

Sie können nahtloses BFD (S-BFD) über nicht-farbige und farbige statische Segment-Routing-LSPs mit First-Hop-Label-Auflösung ausführen und S-BFD als schnellen Mechanismus zur Erkennung von Pfadfehlern und zum Auslösen globaler Konvergenz verwenden. S-BFD erfordert weniger Zustandsänderungen als BFD, wodurch die Meldung von Pfadfehlern beschleunigt wird.

Bei einem Segment-Routing-Tunnel mit einem oder mehreren primären LSPs und optional einem sekundären LSP können Sie S-BFD auf jedem dieser LSPs aktivieren. Wenn eine S-BFD-Sitzung ausfällt, aktualisiert die Software die Route des Segment-Routing-Tunnels, indem die nächsten Hops der ausgefallenen LSPs gelöscht werden. Wenn die First-Hop-Bezeichnung des LSP auf mehr als einen unmittelbaren nächsten Hop zeigt, sendet der Kernel weiterhin S-BFD-Pakete, wenn mindestens ein nächster Hop verfügbar ist (die zugrunde liegende Fehlererkennung der Erreichbarkeit des nächsten Hops muss schneller sein als die Dauer des S-BFD-Erkennungstimers).

HINWEIS:

Dieses Modell wird für von der automatischen Übersetzung abgeleitete Sprachdienstleister unterstützt.
LSP-Ebene S-BFD

Für jede eindeutige Kombination aus Label-Stack + Adressfamilie wird eine S-BFD-Sitzung erstellt. Sie können identische Segmentlisten konfigurieren und S-BFD für alle aktivieren. Die Segmentlisten mit identischen Kombinationen aus Label-Stack und Adressfamilie verwenden dieselbe S-BFD-Sitzung. Die Quelladresse für die S-BFD-Sitzung wird auf die am wenigsten konfigurierte Loopback-Adresse (mit Ausnahme der Sonderadressen) unter der Hauptinstanz festgelegt.

HINWEIS:

Stellen Sie sicher, dass die ausgewählte Quelladresse routingfähig ist.

Die Adressfamilie eines LSP wird basierend auf der Adressfamilie der "An"-Adresse im Segment-Routing-TE-Tunnel abgeleitet. Der Status des LSP mit konfiguriertem S-BFD hängt auch davon ab, ob BFD aktiv ist – wenn S-BFD für einen LSP konfiguriert ist, wird die LSP-Route erst berechnet, wenn S-BFD meldet, dass der Pfad aktiv ist.

S-BFD-Parameter

Die folgenden S-BFD-Parameter werden für Segment-Routing-TE-Pfade unterstützt:

  • Ferndiskriminator

  • Minimales Intervall

  • Multiplikator

  • Keine Router-Warnoption

Bei S-BFD kann jeder Responder mehrere Diskriminatoren haben. Die Diskriminatoren können von IGP anderen Routern angekündigt werden, oder sie können statisch auf diesen Routern konfiguriert sein. Bei einem Initiator wird ein bestimmter Diskriminator als Ferndiskriminator für eine S-BFD-Sitzung durch statische Konfiguration ausgewählt, basierend auf der Entscheidung oder dem Beschluss von Ihnen oder einem zentralen Controller. Wenn mehrere LSPs mit demselben Schlüsselbeschriftungsstapel erstellt werden und S-BFD auf jedem von ihnen mit unterschiedlichen Parametern aktiviert ist, wird der aggressive Wert jedes Parameters in der freigegebenen S-BFD-Sitzung verwendet. Für den Diskriminatorparameter wird der niedrigste Wert als der aggressivste Wert betrachtet. Ähnlich verhält es sich mit der Router-Warnoption: Wenn in einer der Konfigurationen keine Routerwarnung konfiguriert ist, hat der abgeleitete S-BFD-Parameter keine Router-Warnoption.

Begrenzungen

  • Vor Junos OS Version 23.2R1 wurde nur die globale Reparatur unterstützt. Ab Junos OS Version 23.2R1 wird die lokale Reparatur für Geräte der MX-Serie unterstützt.

  • Obwohl S-BFD in Abhängigkeit von den konfigurierten Timer-Werten Fehler erkennt, hängt die Konvergenzzeit von der globalen Reparaturzeit (seconds) ab.

Automatische Ableitung des Remote Discriminators (RD) für S-BFD-Sitzung

Ab Junos OS Version 22.4R1 können Sie den automatisch abgeleiteten Remote-Diskriminator für S-BFD-Sitzungen für die SR-TE-Pfade verwenden. Bei dieser Funktion müssen Sie nicht in remote-discriminator der S-B-F-D-Konfiguration auf dem Eingangs- oder Transitgerät und einen entsprechenden lokalen Diskriminator auf seinem jeweiligen Endpunkt konfigurieren. Stattdessen akzeptiert das ausgehende PE-Gerät jetzt IP-Adressen als lokalen Diskriminator. Um die IP-Adresse als lokalen Diskriminator in BFD zuzulassen, verwenden Sie die Konfiguration set protocols bfd sbfd local-discriminator-ip .

Sie können auch eine gemeinsame S-BFD-Vorlage mit den S-BFD-Konfigurationen für mehrere vom Controller bereitgestellte SR-TE-Richtlinien verwenden. In diesen S-BFD-Sitzungen leitet Junos OS automatisch den Remote-Diskriminator vom Tunnelendpunkt für den Abgleich mit SR-TE-Richtlinien ab.

HINWEIS:

  • Die automatische Ableitung von RD wird nur für IPv4-Endpunkte unterstützt, nicht für IPv6-Endpunkte.

  • Die automatische Ableitung von RD für reine Farbtunnel wird nicht unterstützt. Wenn RD für statisch konfigurierte reine SR-TE-Tunnel nicht konfiguriert ist (durch automatische Ableitung von RD), zeigt das System einen Commit-Fehler an. Wenn RD nicht (durch automatische Ableitung von RD) für dynamische Nur-Farb-Tunnel mithilfe der SR-TE-Vorlagenkonfiguration konfiguriert ist, überspringt Junos OS die sbfd Konfiguration für diesen Tunnel.

S-BFD für SRv6 TE-Pfade

Ab Junos OS Version 24.4R1 können Sie S-BFD über SRv6 TE-Pfade ausführen, um Pfadfehler schnell zu erkennen. Jeder mit S-BFD konfigurierte Pfad innerhalb eines SRv6 TE-Tunnels kann Sondierungen an das Ziel des Pfads senden. Diese Sondierungen folgen den SIDs des TE-Pfads und melden Fehler für alle SIDs innerhalb des Pfads. Wenn Fehler erkannt werden, wird der entsprechende SRv6 TE-Tunnelpfad heruntergefahren, damit der Datenverkehr auf Backup-Pfade verteilt werden kann.

S-BFD für SRv6 wird im verteilten Modus auf Eingangsroutern und im verteilten Modus auf Ausgangsroutern unterstützt.

Um S-BFD für einen SRv6 TE-Pfad auf einem Eingangs-Router zu konfigurieren, müssen Sie einen lokalen Diskriminator mit der sbfd local-discriminator number Konfigurationsanweisung auf Hierarchieebene [edit protocols bfd] konfigurieren. Außerdem müssen Sie einen Remotediskriminator mit der sbfd remote-discriminator number Konfigurationsanweisung auf der [edit protocols source-packet-routing source-routing-path name primary name bfd-liveness-detection] Hierarchieebene konfigurieren.

Um S-BFD für SRv6 TE-Pfade auf einem Egress Router zu konfigurieren, müssen Sie die sbfd local-discriminator number local-ipv6-address address Konfigurationsanweisung auf der [edit protocols bfd] Hierarchieebene konfigurieren. Der loca-discriminator AT-Responder muss mit dem remote-discriminator auf dem SRv6 konfigurierten TE-Pfad am Eingangs-Router übereinstimmen

Für S-BFD-Responder, die nur die lokale IPv6-Hostadresse unterstützen, können Sie die Verwendung einer lokalen IPv6-Hostadresse erzwingen, indem Sie die bfd-liveness-detection sbfd destination-ipv6-local-host Konfigurationsanweisung auf der [edit protocols source-packet-routing source-routing-path lsp-path-name primary segment-list-name] Hierarchieebene verwenden.

Konfigurieren von RE-basiertem S-BFD für Segment-Routing-Traffic Engineering mit First-Hop-Label-Auflösung

Um S-BFD auf LSP-Ebene für eine Segmentliste zu aktivieren, konfigurieren Sie die bfd-liveness-detection Konfigurationsanweisung in der [edit protocols source-packet-routing source-routing-path lsp-path-name primary segment-list-name] Hierarchie und in der Hierarchie [edit protocols source-packet-routing source-routing-path lsp-path-name secondary segment-list-name] .

Die folgenden Schritte beschreiben die grundlegende Konfiguration und den anschließenden Betrieb von S-BFD mit First-Hop-Label-Auflösung:

  • Die folgenden Schritte beschreiben die Grundkonfiguration:

    1. Auf einem Eingangsrouter konfigurieren Sie eine oder mehrere Segmentlisten mit First-Hop-Labels für einen statischen Segment-Routing-Tunnel, der als primärer und sekundärer Pfad verwendet werden soll.

    2. Auf dem Eingangsrouter konfigurieren Sie den statischen Segment-Routing-Tunnel entweder mit mehreren primären Pfaden (für das Load Balancing) oder einem primären Pfad und einem sekundären Pfad (für den Pfadschutz). Jeder primäre oder sekundäre Pfad (LSP) verweist auf eine der Segmentlisten, die Sie bereits konfiguriert haben, und erstellt Routen mit den nächsten Hops, die von den First-Hop-Labels der beitragenden LSPs abgeleitet werden.

    3. Auf dem Eingangsrouter aktivieren Sie den Lastenausgleich pro Paket, sodass Routen, die über Eingangsrouten und die Bindungs-SID-Route (die alle über First-Hop-Bezeichnungen verfügen) aufgelöst werden, alle aktiven Pfade in der Paketweiterleitungs-Engine installieren. Eine S-BFD-Sitzung unter einem LSP schützt alle Routen, die diesen LSP verwenden.

    4. Auf dem Ausgangsrouter des Segment-Routing-Tunnels konfigurieren Sie den S-BFD-Responder-Modus mit einem lokalen Diskriminator D und erstellen für D auf jedem FPC eine verteilte S-BFD-Listener-Sitzung.

    5. Auf dem Eingangsrouter konfigurieren Sie S-BFD für jeden LSP, für den eine Pfadfehlererkennung angezeigt werden soll. Sie geben einen Remote-Diskriminator D an, der mit dem lokalen S-BFD-Diskriminator des Ausgangsrouters übereinstimmt. Eine S-BFD-Initiatorsitzung wird mit der LSP-Kombination Label-Stack+Adressfamilie als Schlüssel erstellt, wenn für den aktuellen LSP-Schlüssel noch keine Initiatorsitzung vorhanden ist. Die S-BFD-Parameter im Falle einer übereinstimmenden BFD-Sitzung werden unter Berücksichtigung der neuen gemeinsam genutzten LSPs neu bewertet. Wenn die S-BFD-Parameter abgeleitet werden, wird der aggressive Wert jedes Parameters ausgewählt.

    Die folgenden Schritte beschreiben den grundlegenden Betrieb :

    1. Die S-BFD-Initiatorsitzung wird in einem zentralisierten Modus auf der Routing-Engine ausgeführt. Die Software verfolgt die Zustände der S-BFD-Sitzung nach oben und unten.

    2. Wenn der S-BFD-Status in UP wechselt, wird der LSP für die relevanten Routen berücksichtigt.

    3. Wenn die Software auf dem Eingangsrouter eine S-BFD-Sitzung als DOWN erkennt, wird eine Session-Down-Benachrichtigung an den Routing-Daemon (RPD) gesendet, und RPD löscht den nächsten Hop der ausgefallenen LSPs aus der Route des Segment-Routing-Tunnels.

    4. Der gesamte Datenverkehrsverlust in der Prozedur ist an die S-BFD-Fehlererkennungszeit und die globale Reparaturzeit gebunden. Die S-BFD-Fehlererkennungszeit wird durch das S-BFD-Mindestintervall und die Multiplikatorparameter bestimmt. Die globale Reparaturzeit hängt von der TE-Prozesszeit für das Segment-Routing und dem erneuten Download der Routen zur Weiterleitung ab.

    LSP-Etikettenstapel werden wie folgt geändert:

    1. Der jeweilige LSP wird von der vorhandenen S-BFD-Sitzung getrennt. Wenn auf die vorhandene S-BFD-Sitzung mindestens ein LSP verweist, wird die alte BFD-Sitzung beibehalten, aber die S-BFD-Parameter werden neu ausgewertet, sodass die aggressiven Parameterwerte unter den vorhandenen LSP-Sitzungen ausgewählt werden. Außerdem wird der Name der S-BFD-Sitzung bei einer Änderung auf den minimalen Namen aktualisiert. Wenn der alten S-BFD-Sitzung keine LSPs mehr zugeordnet sind, wird diese S-BFD-Sitzung entfernt.

    2. Die Software versucht, eine vorhandene BFD-Sitzung zu finden, die mit dem Kombinationswert new-label-stack+address-family übereinstimmt. Wenn eine solche Übereinstimmung vorhanden ist, bezieht sich der LSP auf die vorhandene S-BFD-Sitzung. Die S-BFD-Sitzung wird ähnlich wie bei den erneuten Auswertungen in Schritt 1 auf jede Änderung der Parameter oder des Sitzungsnamens erneut ausgewertet.

    3. Wenn keine passende BFD-Sitzung im System vorhanden ist, wird eine neue BFD-Sitzung erstellt, und die S-BFD-Parameter werden von diesem LSP abgeleitet.

    HINWEIS:

    Das minimale Intervall und der Multiplikator einer S-BFD-Sitzung bestimmen die Fehlererkennungszeit für die Sitzung. Die Reparaturzeit hängt zusätzlich von der globalen Reparaturzeit ab.

Die folgende Ausgabe zeigt Konfigurationsanweisungen, die Sie für einen farbigen LSP mit primären LSPs verwenden würden:

Auf der Responder-Seite müssen Sie den richtigen Diskriminator konfigurieren:

Standardmäßig sind Routerwarnungen für S-BFD-Pakete konfiguriert. Wenn der MPLS-Header am Responder-Ende entfernt wird, wird das Paket zur Verarbeitung an den Host gesendet, ohne dass eine Zieladressensuche für das Paket durchgeführt wird. Wenn Sie die Option no-router-alert auf dem Eingangsrouter aktivieren, wird die Option router-alert aus den IP-Optionen und damit von der Ausgangsseite entfernt. Sie müssen die Zieladresse explizit in lo0 konfigurieren. Andernfalls wird das Paket verworfen und S-BFD bleibt ausgefallen.

Sie können ein neues Trace-Flag verwenden, bfdum BFD-Aktivitäten zu verfolgen:

Beispiel

Die folgende Konfiguration ist ein Beispiel für einen nicht eingefärbten statischen Segment-Routing-Tunnel mit LSP-Schutz.

Stellen Sie sicher, dass LSPs für statische Segmentrouting-Tunnel konfiguriert sind und dass der S-BFD-Sitzungsstatus sichtbar ist.

Zweck

Verwenden Sie den Befehl show spring-traffic-engineering lsp detail , um Sprachdienstleister für Tunnel mit statischem Segment-Routing mit dem Sitzungsstatus S-BFD anzuzeigen.

Action!

Da viele LSPs dieselbe BFD-Sitzung gemeinsam nutzen können, wird beim ersten LSP mit einer eindeutigen Kombination aus Label-Stack und Adressfamilie der Name der S-BFD-Sitzung address-family+lsp-name verwendet. Wenn sich später mehrere Sprachdienstleister dieselbe Sitzung teilen, kann der Name der Sitzung in address-family+least-lsp-name geändert werden, ohne dass sich dies auf den Status der S-BFD-Sitzung auswirkt. Der Name der S-BFD-Sitzung wird auch in der show bfd session extensive Ausgabe des Befehls angezeigt. Die Ausgabe für jeden LSP zeigt den S-BFD-Status sowie den S-BFD-Namen an, auf den er sich bezieht, wie im vorherigen Beispiel als BFD status: Up BFD name: V4-sl2gezeigt. Da es möglicherweise keine S-BFD-Sitzung pro LSP gibt, werden die S-BFD-Leistungsindikatoren auf LSP-Ebene nicht angezeigt.

Überprüfen Sie die Tunnelroute für das Segment-Routing mit einem primären nächsten Hop und einem sekundären nächsten Hop

Zweck

Überprüfen Sie in der Routing-Engine des Eingangsrouters die Tunnelroute für das Segment-Routing mit einem primären nächsten Hop und einem sekundären nächsten Hop.

Action!

Überprüfen der S-BFD-Sitzung des primären Pfads

Zweck

Überprüfen Sie in der Routing-Engine des Eingangsrouters die S-BFD-Sitzung des primären Pfads.

Action!

HINWEIS:

Überprüfen Sie auf der Routing-Engine des Eingangsrouters die S-BFD-Sitzung des sekundären Pfads ebenfalls auf ähnliche Weise.

Rechenverzögerung Optimierte Intradomain- und Interdomain-Segment-Routing-Pfade

Verzögerungsbasierte Metriken für Traffic Engineered Paths – Übersicht

Die Nutzung dynamischer, verzögerungsbasierter Metriken wird in modernen Netzwerken zu einem wünschenswerten Attribut. Verzögerungsbasierte Metriken sind für ein Path Computation Element (PCE) zur Berechnung von Traffic-Engineering-Pfaden unerlässlich. Sie können verzögerungsbasierte Metriken verwenden, um Pakete auf den Pfaden mit der geringsten Latenz oder dem Pfad mit der geringsten Verzögerung zu steuern. Dazu müssen Sie die Verzögerung auf jeder Verbindung messen und sie mit einem geeigneten Routing-Protokoll (IGP oder BGP-LS) ankündigen, damit der Eingang die Verzögerungseigenschaften pro Verbindung in seinem TED hat.

Informationen dazu, wie Sie die Verzögerung bei jedem Link ankündigen oder Linkmessungen aktivieren, finden Sie unter Aktivieren der Linkverzögerungsmessung und Werbung in ISIS.

Die folgende Abfolge von Ereignissen tritt auf, wenn Sie die Erkennung von Änderungen im Netzwerk messen, ankündigen und berechnen und den Traffic Engineering-Pfad mit der kürzesten Latenz berechnen:

  • Erkennen Sie Veränderungen im Netzwerk, indem Sie die Latenz messen, mit synthetischen Sonden, Router-zu-Router.
  • Überfluten Sie die Ergebnisse über IGP-erweiterte TE-Metrikerweiterungen an Eingangsknoten.
  • Veröffentlichen Sie die Ergebnisse bei zentralen Controllern mit entsprechenden BGP-LS-Erweiterungen.
  • Berechnen Sie IGP-basierte Metrikpfade für die kürzeste kumulative Latenz (Flex-Algo).
  • Berechnen Sie für den Datenverkehr entwickelte explizite Pfade (Quelle zu Ziel) mit den kürzesten kumulativen Latenz- oder Verzögerungsmetriken (SR-TE).

Vorteile verzögerungsbasierter Metriken für die Pfadberechnung

  • Stellen Sie Mehrwertdienste bereit, die auf der niedrigsten Latenz im gesamten Netzwerk basieren.
  • Messen Sie die Latenz pro Pfad (Minimum, Maximum, Durchschnitt) mithilfe verzögerungsbasierter Metriken.
  • Steuern Sie verzögerungsempfindliche Services (wie VPN- oder 5G-Services) auf SR-optimierten Pfaden mit extrem niedriger Latenz.

DCSPF-basierte Berechnung mit Verzögerungsmetriken für SR-Pfadübersicht

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

Sie können verteiltes CSFP so konfigurieren, dass es auf mehreren Head-Ends ausgeführt wird und die Pfadberechnung unabhängig auf jedem Head-End durchführt. Sie können das Compute-Profil auf den Quellpfad (Quellpaket-Routingpfad) anwenden. Wenn Sie ein Computeprofil konfiguriert haben, das delay-variation-thresholdfür den Verzögerungsdurchschnitt optimiert ist, können Sie zusätzlich eine Einschränkung namens . Wenn Sie einen Wert für delay-variation-thresholdkonfigurieren, wird jede Verbindung, die den Schwellenwert überschreitet, von der Pfadberechnung ausgeschlossen.

Um Verzögerungsmetriken für die DCSPF-basierte Berechnung für den SR-Pfad zu konfigurieren, müssen Sie die delay Konfigurationsanweisung auf der Hierarchieebene [edit protocols source-packet-routing compute-profile profile-name metric-type delay] aktivieren. Sie können die Verzögerungsmetriken wie Minimum, Maximum, Durchschnitt und Schwellenwert für die Verzögerungsvariation für die Pfadberechnung konfigurieren.

  • minimum– Metrikwert für die minimale Verzögerung von TED für die kumulative Berechnung des Pfads mit der geringsten Latenz.
  • average– Durchschnittlicher Verzögerungsmetrikwert von TED für die kumulative Berechnung des Pfads mit der niedrigsten Latenz.
  • maximum– Metrikwert für die maximale Verzögerung von TED für die kumulative Berechnung des Pfads mit der niedrigsten Latenz.
  • delay-variation-threshold—Schwellenwert für die Variation der Verbindungsverzögerung (1..16777215). Jede Verbindung, die den Schwellenwert für die Verzögerungsvariation überschreitet, wird von der Pfadberechnung ausgeschlossen. Der Schwellenwert für die Verzögerungsvariation ist unabhängig davon, ob Sie die Optimierung für Minimum, Maximum oder Durchschnitt durchführen. Die delay-variation-threshold Konfigurationsanweisung wird auf diesen Hierarchieebenen angezeigt:

    • [edit protocols source-packet-routing compute-profile profile-name metric-type delay]

    • [edit protocols source-packet-routing compute-profile profile-name metric-type delay minimum]

    • [edit protocols source-packet-routing compute-profile profile-name metric-type delay maximum]

    • [edit protocols source-packet-routing compute-profile profile-name metric-type delay average]

Sie können Verzögerungsmetriken in der folgenden CLI-Hierarchie konfigurieren:

Übersicht über Verzögerungsmetriken für domänenübergreifende und domäneninterne Anwendungsfälle

Für den domäneninternen Fall (der Pfad befindet sich innerhalb einer einzelnen Domäne) wird die Verbindungsverzögerung bei der Pfadberechnung berücksichtigt. Verzögerungsmetriken für die Berechnung des Segment-Routing-Pfads werden sowohl für komprimierte als auch für unkomprimierte SIDs unterstützt. Wenn Sie über unkomprimierte SIDs verfügen, werden Nachbarschaftssegmente für Segmentlisten verwendet, um mehrere Segmentlisten zu erstellen, wenn die gleichen Kosten anfallen. Sie können unkomprimierte SIDs mit der no-label-stack-compression Konfigurationsanweisung auf der Hierarchieebene [edit protocols source-packet-routing compute-profile profile-name] konfigurieren. Dadurch wird ein vollständig erweiterter Pfad mithilfe von Adjacency-SIDs bereitgestellt. Weitere Informationen finden Sie unter compute-profile .

Im Folgenden finden Sie eine Beispielkonfiguration für Verzögerungsmetriken:

HINWEIS:

Für die Berechnung des optischen Pfades wird empfohlen, mindestens die Verzögerungsmetriken zu verwenden. Minimum ist die Standardkonfiguration.

Für den Interdomain-Anwendungsfall (Multi-Domain), bei dem es mehrere autonome Systeme gibt, können Sie Express-Segmente verwenden, um Link-Verzögerungen für die Pfadberechnung zu konfigurieren. Expresssegmente sind Verbindungen, die Grenzknoten oder ASBRs verbinden. Weitere Informationen zu Expresssegmenten finden Sie unter Expresssegment-LSP-Konfiguration . Sie können die Verzögerung konfigurieren oder die Verzögerung des zugrunde liegenden LSP im Expresssegment übernehmen. Sie können die Konfiguration delay auf der Hierarchieebene [edit protocols express-segments segment-template template-name metric] vornehmen und die Werte für minimale, maximale und durchschnittliche Verzögerungen festlegen.

Sie können Verzögerungsmetriken in einem Expresssegment in der folgenden CLI-Hierarchie konfigurieren:

Für die domänenübergreifende Pfadberechnung können Sie BGP-EPE-Verbindungen Verzögerungsmetriken zuweisen. Sie können einen Wert für delay-metric auf der Hierarchieebene [edit protocols bgp group group-name neighbor ip address egress-te-adj-segment segment-name egress-te-link attribute] wie unten gezeigt konfigurieren:

Anwendungsszenario für Verzögerungsmetriken in optischen Netzwerken

Die folgenden Topologien stellen ein Beispiel für einen optischen Anwendungsfall dar. Lösungen für optischen Schutz und Wiederherstellung führen dazu, dass sich die zugrunde liegenden physikalischen Eigenschaften, vor allem die Pfadlänge, aufgrund von Verbindungsfehlern und anschließender DWDM-Netzwerkoptimierung ändern.

In der Abbildungerfolgt die Verbindung zwischen A und C über die optischen Knoten O1 und O3 und hat eine Latenz von 10 Mikrosekunden. In der Abbildungsehen Sie einen Verbindungsausfall zwischen den optischen Knoten O1 und O3 und dass die eigentliche optische Verbindung durch den optischen Knoten O2 umgeleitet wird. Dadurch erhöht sich die Latenz von 15 Mikrosekunden. Die Metrik für die Verbindung, die A und B verbindet, ändert sich dynamisch zwischen time=0 und time=1.

Wenn eine Änderung der Verzögerung pro Verbindung durch den Eingang erkannt wird, löst der Eingang eine Neuberechnung des verzögerungsoptimierten Pfads aus, und der Headend-Router leitet den Pfad über den nächsten verfügbaren Pfad mit der geringsten verfügbaren Latenz um. Die Änderung der Verbindungsverzögerung kann dazu führen, dass der Eingang eine andere Gruppe von Verbindungen mit dem geringsten Latenzpfad wählt. In Abbildung B sehen Sie, dass sich die Verbindung zwischen Pfad A und C geändert hat und der Headend-Router den Pfad A-B-C umleitet und auswählt, wie in der Topologie gezeigt.

Verwandte Themen

Tabellarischer Änderungsverlauf

Die Unterstützung der Funktion hängt von der Plattform und der Version ab, die Sie benutzen. Verwenden Sie Feature Explorer, um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.

Release
Beschreibung
20.2R1
Ab Junos OS Version 20.2R1 kann BGP Labeled Unicast (BGP-LU) IPv4- oder IPv6-Routen über Segment-Routing-Traffic Engineering (SR-TE) sowohl für IPv4- als auch für IPv6-Adressfamilien auflösen.
19.4R1
Sie können eine Tunnelvorlage für PCE-initiierte Segment-Routing-LSPs konfigurieren, um zwei zusätzliche Parameter für diese LSPs zu übergeben: Bidirectional Forwarding Detection (BFD) und LDP-Tunneling.
19.1R1
Ab Junos OS Version 19.1R1 wird eine Commit-Prüffunktion eingeführt, mit der sichergestellt wird, dass in allen Segmentlisten, die zu den farbigen Routen beitragen, die minimale Bezeichnung für alle Hops vorhanden ist.
19.1R1
Ab Junos OS Version 19.1R1 gilt diese Anforderung nicht mehr, da der erste Hop der nicht eingefärbten statischen LSPs jetzt zusätzlich zu den IP-Adressen auch Unterstützung für SID-Bezeichnungen bietet. Mit der Unterstützung von First-Hop-Labels werden MPLS Fast Reroute (FRR) und gewichteter Equal-Cost-Multipath für die Auflösung der statischen, nicht farbigen Segment-Routing-LSPs aktiviert, ähnlich wie bei farbigen statischen LSPs.
18.2R1
Ab Junos OS Version 18.2R1 werden statisch konfigurierte, nicht farbige Segment-Routing-LSPs auf dem Eingangsgerät über eine PCEP-Sitzung (Path Computation Element Protocol) an das Path Computation Element (PCE) gemeldet.