MPLS Traffic Engineering Konfiguration

Verwenden von LSPs sowohl für BGP- als auch für IGP-Datenverkehrsweiterleitung

Sie können BGP und die IGPs so konfigurieren, dass sie LSPs für die Weiterleitung von Datenverkehr verwenden, der für Ausgangsrouter bestimmt ist, indem Sie die Option für die Anweisung hinzufügen.bgp-igptraffic-engineering Die Option bewirkt, dass alle inet.3-Routen in die inet.0-Routing-Tabelle verschoben werden.bgp-igp

Fügen Sie auf dem Eingangsrouter die Option für die folgende Anweisung ein:bgp-igptraffic-engineering

Sie können diese Anweisung auf den folgenden Hierarchieebenen einbinden:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

  HINWEIS:

  Die Option für die Anweisung kann nicht für VPN konfiguriert werden).bgp-igptraffic-engineering VPNs erfordern, dass sich die Routen in der inet.3-Routing-Tabelle befinden.

Verwenden von Sprachdienstleistern für die Weiterleitung in Virtual Private Networks

VPNs erfordern, dass Routen in der inet.3-Routing-Tabelle verbleiben, um ordnungsgemäß zu funktionieren. Konfigurieren Sie für VPNs die Option der Anweisung so, dass BGP und IGPs LSPs für die Weiterleitung von Datenverkehr verwenden, der für Ausgangsrouter bestimmt ist.bgp-igp-both-ribstraffic-engineering Mit dieser Option werden die Eingangsrouten sowohl in der Routing-Tabelle inet.0 (für IPv4-Unicast-Routen) als auch in der Routing-Tabelle inet.3 (für MPLS-Pfadinformationen) installiert.bgp-igp-both-ribs

Fügen Sie auf dem Eingangsrouter die folgende Anweisung ein:traffic-engineering bgp-igp-both-ribs

Sie können diese Anweisung auf den folgenden Hierarchieebenen einbinden:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

Wenn Sie die Anweisung verwenden, werden die Routen aus der Tabelle inet.3 in die Tabelle inet.0 kopiert.bgp-igp-both-ribs Die kopierten Routen sind LDP-signalisiert oder RSVP-signalisiert und haben wahrscheinlich eine schlechtere Präferenz als andere Routen in inet.0. Routen mit einer minderwertigen Präferenz werden mit größerer Wahrscheinlichkeit als aktive Routen ausgewählt. Dies kann ein Problem darstellen, da Routing-Richtlinien nur auf aktive Routen angewendet werden. Um dieses Problem zu vermeiden, verwenden Sie stattdessen die Option.mpls-forwarding

Verwenden von RSVP- und LDP-Routen für die Weiterleitung, aber nicht für die Routenauswahl

Wenn Sie die Optionen oder für die Anweisung konfigurieren, können LSPs mit hoher Priorität IGP-Routen in der Routing-Tabelle inet.0 ersetzen.bgp-igpbgp-igp-both-ribstraffic-engineering IGP-Routen werden möglicherweise nicht mehr neu verteilt, da sie nicht mehr die aktiven Routen sind.

Wenn Sie die Option für die Anweisung konfigurieren, werden LSPs für die Weiterleitung verwendet, aber von der Routenauswahl ausgeschlossen.mpls-forwardingtraffic-engineering Diese Routen werden sowohl den Routing-Tabellen inet.0 als auch inet.3 hinzugefügt. LSPs in der inet.0-Routing-Tabelle werden bei der Auswahl der aktiven Route schlechter bevorzugt. LSPs in der inet.3-Routing-Tabelle erhalten jedoch eine normale Präferenz und werden daher für die Auswahl der Weiterleitung nächster Hops verwendet.

Wenn Sie die Option aktivieren, werden Routen, deren Status ist, für die Weiterleitung bevorzugt, auch wenn ihre Präferenz schlechter ist als die der aktuell aktiven Route.mpls-forwardingForwardingOnly Um den Status einer Route zu untersuchen, führen Sie einen Befehl aus.show route detail

Um LSPs für die Weiterleitung zu verwenden, sie aber von der Routenauswahl auszuschließen, schließen Sie die Option für die Anweisung ein:mpls-forwardingtraffic-engineering

Sie können diese Anweisung auf den folgenden Hierarchieebenen einbinden:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

Wenn Sie die Option konfigurieren, werden IGP-Verknüpfungsrouten nur in die inet.0-Routing-Tabelle kopiert.mpls-forwarding

Im Gegensatz zur Option können Sie mit dieser Option die LDP-signalisierten und RSVP-signalisierten Routen für die Weiterleitung verwenden und die BGP- und IGP-Routen für Routing-Zwecke aktiv halten, damit Routing-Richtlinien darauf reagieren können.bgp-igp-both-ribsmpls-forwarding

Angenommen, auf einem Router wird BGP ausgeführt und er hat die BGP-Route 10.10.10.1/32, die er an einen anderen BGP-Speaker senden muss. Wenn Sie die Option verwenden und Ihr Router auch über einen Label-Switched-Path (LSP) zu 10.10.10.1 verfügt, wird die MPLS-Route für 10.10.10.1 in der Routing-Tabelle inet.0 aktiv.bgp-igp-both-ribs Dadurch wird verhindert, dass Ihr Router die Route 10.10.10.1 an den anderen BGP-Router ankündigt. Wenn Sie hingegen die Option anstelle der Option verwenden, wird die BGP-Route 10.10.10.1/32 dem anderen BGP-Sprecher angekündigt, und der LSP wird weiterhin verwendet, um Datenverkehr an das Ziel 10.10.10.1 weiterzuleiten.mpls-forwardingbgp-igp-both-ribs

Werbung für die LSP-Metrik in zusammengefassten LSAs

Sie können MPLS und OSPF so konfigurieren, dass ein LSP als Link behandelt wird. Diese Konfiguration ermöglicht es anderen Routern im Netzwerk, diesen LSP zu verwenden. Um dieses Ziel zu erreichen, müssen Sie MPLS und OSPF Traffic Engineering so konfigurieren, dass die LSP-Metrik in zusammengefassten LSAs angekündigt wird.

Fügen Sie für MPLS die und-Anweisungen ein:traffic-engineering bgp-igplabel-switched-path

Sie können diese Anweisungen auf den folgenden Hierarchieebenen einbinden:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

Fügen Sie für OSPF die folgende Anweisung ein:lsp-metric-into-summary

Sie können diese Anweisung auf den folgenden Hierarchieebenen einbinden:

• [edit protocols ospf traffic-engineering shortcuts]

• [edit logical-systems logical-system-name protocols ospf traffic-engineering shortcuts]

Weitere Informationen zum OSPF Traffic Engineering finden Sie in der Junos OS Routing Protocols Library for Routing Devices.https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/config-guide-routing/index.html

Anforderungen an das Inter-AS Traffic Engineering

Die ordnungsgemäße Einrichtung und das Funktionieren von verkehrstechnischen Sprachdienstleistern zwischen AS hängen von den folgenden Netzwerkanforderungen ab, die alle erfüllt sein müssen:

• Alle AS werden von einem einzigen Service Provider kontrolliert.

• OSPF wird als Routing-Protokoll in jedem AS verwendet, und EBGP wird als Routing-Protokoll zwischen den AS verwendet.

• ASBR-Informationen sind in jedem AS verfügbar.

• EBGP-Routing-Informationen werden von OSPF verteilt, und in jedem AS ist ein vollständiges IBGP-Netz vorhanden.

• Transit-LSPs werden nicht auf den Inter-AS-Verbindungen konfiguriert, sondern zwischen Ein- und Ausstiegspunkt-ASBRs auf jedem AS.

• Die EBGP-Verbindung zwischen ASBRs in verschiedenen ASs ist eine direkte Verbindung und muss als passive Traffic-Engineering-Verbindung unter OSPF konfiguriert werden. Die Remote-Link-Adresse selbst, nicht das Loopback oder eine andere Link-Adresse, wird als Remote-Knoten-ID für diese passive Verbindung verwendet. Weitere Informationen zur Konfiguration des passiven OSPF-Traffic-Engineering-Modus finden Sie unter Konfigurieren des passiven OSPF-TE-Modus.

Darüber hinaus muss die Adresse, die für den Remote-Knoten der passiven OSPF-Traffic-Engineering-Verbindung verwendet wird, mit der Adresse übereinstimmen, die für die EBGP-Verbindung verwendet wird. Weitere Informationen zu OSPF und BGP im Allgemeinen finden Sie in der Junos OS Routing Protocols Library for Routing Devices.https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/config-guide-routing/index.html

Einschränkungen des Inter-AS Traffic Engineering

Nur hierarchische oder verschachtelte LSP-Signale werden für LSPs unterstützt, die für den Datenverkehr zwischen AS entwickelt wurden. Es werden nur Punkt-zu-Punkt-Sprachdienstleister unterstützt (es gibt keine Punkt-zu-Mehrpunkt-Unterstützung).

Darüber hinaus gelten die folgenden Einschränkungen. Jede dieser Bedingungen ist ausreichend, um LSPs im Inter-AS-Verkehr unmöglich zu machen, selbst wenn die oben genannten Anforderungen erfüllt sind.

• Die Verwendung von Multihop-BGP wird nicht unterstützt.

• Die Verwendung von Policern oder Topologien, die verhindern, dass BGP-Routen innerhalb des AS bekannt sind, wird nicht unterstützt.

• Mehrere ASBRs in einem LAN zwischen EBGP-Peers werden nicht unterstützt. Es wird nur ein ASBR in einem LAN zwischen EBGP-Peers unterstützt (andere ASBRs können im LAN vorhanden sein, aber nicht angekündigt werden).

• Routenreflektoren oder Richtlinien, die ASBR-Informationen ausblenden oder verhindern, dass ASBR-Informationen innerhalb der ASs verteilt werden, werden nicht unterstützt.

• Bidirektionale Sprachdienstleister werden nicht unterstützt (Sprachdienstleister sind aus Sicht der Verkehrstechnik unidirektional).

• Topologien mit Inter-AS- und Intra-AS-Pfaden zum selben Ziel werden nicht unterstützt.

Darüber hinaus werden einige Funktionen, die bei allen Sprachdienstleistern Routine sind, vom Inter-AS-Traffic-Engineering nicht unterstützt:

• Die Linkfarben von Admin-Gruppen werden nicht unterstützt.

• Der sekundäre Standby-Modus wird nicht unterstützt.

• Eine erneute Optimierung wird nicht unterstützt.

• Crankback auf Transit-Routern wird nicht unterstützt.

• Die Berechnung diverser Pfade wird nicht unterstützt.

• Ein ordnungsgemäßer Neustart wird nicht unterstützt.

Diese Listen von Einschränkungen oder nicht unterstützten Funktionen bei LSPs mit Inter-AS-Datenverkehrstechnik sind nicht vollständig.

Konfigurieren des passiven OSPF-TE-Modus

Normalerweise werden interne Routing-Protokolle wie OSPF nicht auf Verbindungen zwischen AS ausgeführt. Damit das Inter-AS-Traffic Engineering ordnungsgemäß funktioniert, müssen jedoch Informationen über die Inter-AS-Verbindung, insbesondere die Adresse auf der Remote-Schnittstelle, innerhalb des AS zur Verfügung gestellt werden. Diese Informationen sind normalerweise weder in EBGP-Erreichbarkeitsmeldungen noch in OSPF-Routing-Ankündigungen enthalten.

Um diese Link-Adressinformationen innerhalb des AS zu überfluten und für Traffic-Engineering-Berechnungen zur Verfügung zu stellen, müssen Sie den passiven OSPF-Modus für das Traffic-Engineering auf jeder AS-übergreifenden Schnittstelle konfigurieren. Außerdem müssen Sie die Remoteadresse angeben, an die OSPF verteilt und in die Traffic Engineering-Datenbank aufgenommen werden soll.

Um den passiven OSPF-Modus für das Traffic Engineering auf einer Inter-AS-Schnittstelle zu konfigurieren, fügen Sie die Anweisung für den Link auf Hierarchieebene ein:passive[edit protocols ospf area area-id interface interface-name]

OSPF muss auf dem Router ordnungsgemäß konfiguriert sein. Im folgenden Beispiel wird die Inter-AS-Verbindung so konfiguriert, dass Traffic Engineering-Informationen mit OSPF innerhalb des AS verteilt werden.so-1/1/0 Die Remote-IP-Adresse lautet .192.168.207.2

Paketweiterleitung basierend auf Label-Swapping

Der Paketweiterleitungsprozess an jedem Router basiert auf dem Konzept des Label-Swapping. Dieses Konzept ähnelt dem, was an jedem ATM-Switch (Asynchronous Transfer Mode) in einem permanenten virtuellen Schaltkreis (PVC) auftritt. Jedes MPLS-Paket enthält einen 4-Byte-Kapselungsheader, der ein 20-Bit-Label-Feld mit fester Länge enthält. Wenn ein Paket mit einem Label bei einem Router eintrifft, untersucht der Router das Label und kopiert es als Index in seine MPLS-Weiterleitungstabelle. Jeder Eintrag in der Weiterleitungstabelle enthält ein Schnittstellen-Eingangslabel-Paar, das einem Satz von Weiterleitungsinformationen zugeordnet ist, die auf alle Pakete angewendet werden, die auf der jeweiligen Schnittstelle mit demselben eingehenden Label ankommen.

Wie ein Paket einen MPLS-Backbone durchläuft

In diesem Abschnitt wird beschrieben, wie ein IP-Paket verarbeitet wird, wenn es ein MPLS-Backbone-Netzwerk durchläuft.

An der Eingangskante des MPLS-Backbones wird der IP-Header vom Eingangsrouter untersucht. Basierend auf dieser Analyse wird das Paket klassifiziert, einem Label zugewiesen, in einem MPLS-Header gekapselt und an den nächsten Hop im LSP weitergeleitet. MPLS bietet ein hohes Maß an Flexibilität bei der Art und Weise, wie ein IP-Paket einem Sprachdienstleister zugewiesen werden kann. In der Junos Traffic Engineering-Implementierung werden beispielsweise alle Pakete, die am Eingangsrouter eingehen und die MPLS-Domäne am selben Ausgangsrouter verlassen sollen, über denselben LSP weitergeleitet.

Sobald das Paket beginnt, den LSP zu durchlaufen, verwendet jeder Router das Label, um die Weiterleitungsentscheidung zu treffen. Die MPLS-Weiterleitungsentscheidung wird unabhängig vom ursprünglichen IP-Header getroffen: Die eingehende Schnittstelle und das Label werden als Nachschlageschlüssel in der MPLS-Weiterleitungstabelle verwendet. Die alte Bezeichnung wird durch eine neue Bezeichnung ersetzt, und das Paket wird an den nächsten Hop entlang des LSP weitergeleitet. Dieser Vorgang wird an jedem Router im LSP wiederholt, bis das Paket den Ausgangsrouter erreicht.

Wenn das Paket am Ausgangsrouter eintrifft, wird die Bezeichnung entfernt und das Paket verlässt die MPLS-Domäne. Das Paket wird dann basierend auf der Ziel-IP-Adresse, die im ursprünglichen IP-Header des Pakets enthalten ist, gemäß dem traditionellen, kürzesten Pfad, der vom IP-Routing-Protokoll berechnet wird, weitergeleitet.

Komponente "Informationsverteilung"

Traffic Engineering erfordert detaillierte Kenntnisse über die Netzwerktopologie sowie dynamische Informationen über die Netzwerkbelastung. Zur Implementierung der Informationsverteilungskomponente werden einfache Erweiterungen der IGPs definiert. Link-Attribute sind Teil der Link-State-Ankündigung jedes Routers. IS-IS-Erweiterungen umfassen die Definition neuer Type Length Values (TLVs), während OSPF-Erweiterungen mit undurchsichtigen Link-State-Ankündigungen (LSAs) implementiert werden. Der Standard-Flooding-Algorithmus, der von den Link-State-IGPs verwendet wird, stellt sicher, dass Link-Attribute an alle Router in der Routing-Domäne verteilt werden. Zu den Traffic-Engineering-Erweiterungen, die der IGP-Link-State-Ankündigung hinzugefügt werden, gehören die maximale Linkbandbreite, die maximale reservierte Linkbandbreite, die aktuelle Bandbreitenreservierung und die Linkfärbung.

Jeder Router verwaltet Netzwerkverbindungsattribute und Topologieinformationen in einer speziellen Traffic-Engineering-Datenbank. Die Traffic-Engineering-Datenbank wird ausschließlich für die Berechnung expliziter Pfade für die Platzierung von LSPs in der physischen Topologie verwendet. Es wird eine separate Datenbank gepflegt, so dass die anschließende verkehrstechnische Berechnung unabhängig vom IGP und der Link-State-Datenbank des IGP ist. Währenddessen setzt die IGP ihren Betrieb unverändert fort und führt die traditionelle Berechnung des kürzesten Weges auf der Grundlage von Informationen durch, die in der Verbindungsstatusdatenbank des Routers enthalten sind.

Komponente "Pfadauswahl"

Nachdem Netzwerkverbindungsattribute und Topologieinformationen vom IGP überflutet und in der Traffic-Engineering-Datenbank abgelegt wurden, verwendet jeder Eingangsrouter die Traffic-Engineering-Datenbank, um die Pfade für seinen eigenen Satz von LSPs in der Routing-Domäne zu berechnen. Der Pfad für jeden LSP kann entweder durch eine strikte oder eine lose explizite Route dargestellt werden. Eine explizite Route ist eine vorkonfigurierte Sequenz von Routern, die Teil des physischen Pfads des LSP sein sollten. Wenn der Eingangsrouter alle Router im LSP angibt, wird der LSP durch eine strikte explizite Route identifiziert. Wenn der Eingangsrouter nur einige der Router im LSP angibt, wird der LSP als lose explizite Route beschrieben. Die Unterstützung für strikte und lockere explizite Routen ermöglicht es, dem Pfadauswahlprozess nach Möglichkeit einen großen Spielraum zu geben, aber bei Bedarf einzuschränken.

Der Eingangsrouter bestimmt den physischen Pfad für jeden LSP, indem er einen CSPF-Algorithmus (Constrained Shortest Path First) auf die Informationen in der Traffic-Engineering-Datenbank anwendet. CSPF ist ein Algorithmus mit dem kürzesten Pfad, der geändert wurde, um bestimmte Einschränkungen bei der Berechnung des kürzesten Pfads über das Netzwerk zu berücksichtigen. Die Eingabe in den CSPF-Algorithmus umfasst:

• Topologie-Verbindungsstatusinformationen, die von der IGP gelernt und in der Traffic-Engineering-Datenbank verwaltet werden

• Attribute, die mit dem Status von Netzwerkressourcen verknüpft sind (z. B. Gesamtbandbreite, reservierte Verbindungsbandbreite, verfügbare Verbindungsbandbreite und Verbindungsfarbe), die von IGP-Erweiterungen übertragen und in der Traffic-Engineering-Datenbank gespeichert werden

• Administrative Attribute, die erforderlich sind, um den Datenverkehr zu unterstützen, der den vorgeschlagenen LSP durchläuft (z. B. Bandbreitenanforderungen, maximale Hopanzahl und administrative Richtlinienanforderungen), die aus der Benutzerkonfiguration abgerufen werden

Wenn CSPF jeden potenziellen Knoten und Link für einen neuen LSP berücksichtigt, akzeptiert oder lehnt es eine bestimmte Pfadkomponente ab, basierend auf der Ressourcenverfügbarkeit oder darauf, ob die Auswahl der Komponente gegen Benutzerrichtlinieneinschränkungen verstößt. Das Ergebnis der CSPF-Berechnung ist eine explizite Route, die aus einer Sequenz von Routeradressen besteht, die den kürzesten Pfad durch das Netzwerk bereitstellt, der die Einschränkungen erfüllt. Diese explizite Route wird dann an die Signalisierungskomponente übergeben, die den Weiterleitungsstatus in den Routern entlang des LSP festlegt.

Signalisierungskomponente

Es ist nicht bekannt, dass ein LSP praktikabel ist, bis er tatsächlich von der Signalisierungskomponente etabliert wird. Die Signalisierungskomponente, die für das Einrichten des LSP-Status und das Verteilen von Labels zuständig ist, basiert auf einer Reihe von Erweiterungen für RSVP:

• Das Explicit Route-Objekt ermöglicht es einer RSVP-Pfadnachricht, eine explizite Sequenz von Routern zu durchlaufen, die unabhängig vom herkömmlichen IP-Routing mit dem kürzesten Pfad ist. Die explizite Route kann entweder strikt oder lose sein.

• Das Label Request-Objekt lässt zu, dass die RSVP-Pfadnachricht anfordert, dass zwischengeschaltete Router eine Bezeichnungsbindung für den LSP bereitstellen, den sie einrichten.

• Das Label-Objekt ermöglicht es RSVP, die Verteilung von Labels zu unterstützen, ohne die vorhandenen Mechanismen zu ändern. Da die RSVP-Resv-Nachricht dem umgekehrten Pfad der RSVP-Pfadnachricht folgt, unterstützt das Label-Objekt die Verteilung von Bezeichnungen von nachgeschalteten Knoten auf vorgelagerte Knoten.

Die Rolle eines Interior Gateway Protocol

Ein Interior Gateway Protocol (IGP) ist ein Protokolltyp, der für den Austausch von Routing-Informationen zwischen Geräten innerhalb eines autonomen Systems (AS) verwendet wird. Basierend auf der Methode zur Berechnung des besten Weges zu einem Ziel werden die IGPs in zwei Kategorien unterteilt:

• Link-State-Protokolle: Kündigen Informationen über die Netzwerktopologie (direkt verbundene Verbindungen und den Status dieser Verbindungen) an alle Router an, die Multicast-Adressen und ausgelöste Routing-Updates verwenden, bis alle Router, auf denen das Link-State-Protokoll ausgeführt wird, identische Informationen über das Netzwerk haben. Der beste Pfad zu einem Ziel wird auf der Grundlage von Einschränkungen wie maximaler Verzögerung, minimaler verfügbarer Bandbreite und Ressourcenklassenaffinität berechnet.

  OSPF und IS-IS sind Beispiele für Link-State-Protokolle.

• Distance Vector Protocols: Kündigen Sie direkt verbundene Nachbarn über eine Broadcast-Adresse vollständige Routing-Tabelleninformationen an. Der beste Pfad wird basierend auf der Anzahl der Hops zum Zielnetzwerk berechnet.

  RIP ist ein Beispiel für ein Distanzvektorprotokoll.

Wie der Name schon sagt, besteht die Rolle eines IGP darin, Routing-Konnektivität innerhalb oder innerhalb einer bestimmten Routing-Domäne bereitzustellen. Eine Routing-Domäne ist eine Gruppe von Routern unter gemeinsamer administrativer Kontrolle, die ein gemeinsames Routing-Protokoll verwenden. Ein AS kann aus mehreren Routing-Domänen bestehen, wobei IGP-Funktionen Netzwerkpräfixe (Routen) von benachbarten Routern ankündigen und lernen, um eine Routing-Tabelle zu erstellen, die letztendlich Einträge für alle Quellen enthält, die die Erreichbarkeit für ein bestimmtes Präfix ankündigen. IGP führt einen Routenauswahlalgorithmus aus, um den besten Pfad zwischen dem lokalen Router und jedem Ziel auszuwählen, und bietet vollständige Konnektivität zwischen den Routern, die eine Routing-Domäne bilden.

Zusätzlich zur Ankündigung der Erreichbarkeit innerhalb des Netzwerks werden IGPs häufig verwendet, um Routing-Informationen anzukündigen, die sich außerhalb der Routing-Domäne dieser IGP befinden, und zwar durch einen Prozess, der als Routenumverteilung bezeichnet wird. Bei der Routenneuverteilung werden Routing-Informationen zwischen verschiedenen Routing-Protokollen ausgetauscht, um mehrere Routing-Domänen miteinander zu verbinden, wenn eine Konnektivität innerhalb des AS gewünscht wird.

Einschränkungen eines Interior Gateway Protocol

Während jede einzelne IGP ihre eigenen Vor- und Nachteile hat, sind die größten Einschränkungen von IGP im Allgemeinen die Leistung und Skalierbarkeit.

IGPs sind so konzipiert, dass sie die Erfassung und Verteilung von Netzwerktopologieinformationen für verkehrstechnische Zwecke übernehmen. Obwohl sich dieses Modell bewährt hat, haben IGPs inhärente Skalierungsbeschränkungen, wenn es um die Verteilung großer Datenbanken geht. IGPs können Nachbarn automatisch erkennen, mit denen sie Informationen über die Topologie von Intra-Area-Netzwerken erfassen. Die Link-State-Datenbank oder eine Traffic-Engineering-Datenbank hat jedoch den Geltungsbereich eines einzelnen Bereichs oder AS, wodurch Anwendungen, wie z. B. End-to-End-Traffic-Engineering, den Vorteil externer Sichtbarkeit einschränken, um bessere Entscheidungen treffen zu können.

Bei labelvermittelten Netzwerken wie MPLS und Generalized MPLS (GMPLS) arbeiten die meisten vorhandenen Traffic-Engineering-Lösungen in einer einzigen Routing-Domäne. Diese Lösungen funktionieren nicht, wenn eine Route vom Eingangsknoten zum Ausgangsknoten den Routingbereich oder AS des Eingangsknotens verlässt. In solchen Fällen wird das Problem der Pfadberechnung kompliziert, da die vollständigen Routing-Informationen nicht im gesamten Netzwerk verfügbar sind. Dies liegt daran, dass Service Provider in der Regel aus Gründen von Skalierbarkeitseinschränkungen und Vertraulichkeitsbedenken keine Routing-Informationen über den Routing-Bereich oder AS hinaus preisgeben.

Bedarf an übergreifender Link-State-Verteilung

Eine der Einschränkungen von IGP besteht darin, dass es nicht in der Lage ist, die Link-State-Verteilung außerhalb eines einzelnen Bereichs oder AS zu überspannen. Für das Spannen der von einem IGP erfassten Verbindungsstatusinformationen über mehrere Bereiche oder ASs hinweg gelten jedoch die folgenden Anforderungen:

• LSP-Pfadberechnung: Diese Informationen werden verwendet, um den Pfad für MPLS-LSPs über mehrere Routing-Domänen hinweg zu berechnen, z. B. einen gebietsübergreifenden TE-LSP.

• Externe Pfadberechnungsentitäten: Externe Pfadberechnungseinheiten wie Application Layer Traffic Optimization (ALTO) und Path Computation Elements (PCE) führen Pfadberechnungen basierend auf der Netzwerktopologie und dem aktuellen Status der Verbindungen innerhalb des Netzwerks, einschließlich Traffic Engineering-Informationen, durch. Diese Informationen werden in der Regel von IGPs innerhalb des Netzwerks verteilt.

  Da die externen Pfadberechnungseinheiten diese Informationen jedoch nicht aus den IGPs extrahieren können, führen sie eine Netzwerküberwachung durch, um die Netzwerkdienste zu optimieren.

BGP als Lösung nutzen

• Überblick
• Implementierung

Implementierung

In Junos OS installieren die IGPs Topologieinformationen in einer Datenbank, die als Traffic Engineering-Datenbank bezeichnet wird. Die Traffic-Engineering-Datenbank enthält die aggregierten Topologieinformationen. Um IGP-Topologieinformationen in der Traffic Engineering-Datenbank zu installieren, verwenden Sie die Konfigurationsanweisung auf der Hierarchieebene und .set igp-topology[edit protocols isis traffic-engineering][edit protocols ospf traffic-engineering] Der Mechanismus zum Verteilen von Link-State-Informationen mithilfe von BGP umfasst das Ankündigen der Traffic-Engineering-Datenbank in BGP-TE (Import) und das Installieren von Einträgen aus BGP-TE in der Traffic-Engineering-Datenbank (Export).

Ab Junos OS Version 20.4R1 können Sie IS-IS Traffic Engineering so konfigurieren, dass neben IPv4-Adressen auch IPv6-Informationen in der Traffic Engineering Database (TED) gespeichert werden. BGP-LS verteilt diese Informationen als Routen aus der Traffic Engineering-Datenbank an die LSDIST.0-Routing-Tabelle mithilfe der Importrichtlinien für Traffic Engineering-Datenbanken. Diese Routen werden BGP-TE-Peers als NLRI (Network Layer Reachability Information) mit IPv6-Router-ID-Typ, -Länge und -Wert (TLV) angekündigt. Durch Hinzufügen von IPv6-Informationen können Sie davon profitieren, dass Sie die vollständige Netzwerktopologie in die Traffic-Engineering-Datenbank erhalten.

Abbildung 1: Junos OS-Implementierung der BGP-Link-State-Verteilung

BGP-LS, NLRI und Konföderations-ID

Ab Junos OS Version 23.1R1 ermöglicht Junos OS BGP Link State (BGP-LS) Network Layer Reachability Information (NLRI), die Konföderations-ID in TLV 512 zu tragen, wenn BGP-Konföderation aktiviert ist. Das NLRI trägt die Konföderations-ID zusammen mit der Mitgliedsnummer des autonomen Systems (AS-Nummer) in TLV 517, wie in RFC 9086 definiert. Das Junos OS Traffic Engineering-Datenbankmodul nimmt die erforderlichen Änderungen vor, um die Verbund-ID und die AS-Nummer des Mitglieds in TLV 512 bzw. TLV 517 zu codieren, während die BGP-LS-NLRI (die in die Routing-Tabelle lsdist.0 eingefügt wird) erstellt wird. In Versionen vor Junos OS Version 23.1R1 trägt BGP-LS NLRI nur die Mitglieds-AS-Nummer in TLV 512, und die Verbund-ID ist in der lsdist.0-Routingtabelle nicht codiert.

Traffic Engineering-Datenbankimport

Um die Traffic-Engineering-Datenbank in BGP-TE anzukündigen, werden die Link- und Node-Einträge in der Traffic-Engineering-Datenbank in Form von Routen konvertiert. Diese konvertierten Routen werden dann von der Traffic-Engineering-Datenbank im Auftrag der entsprechenden IGP in eine für den Benutzer sichtbare Routing-Tabelle namens installiert , und zwar unter Bedingungen, die den Routenrichtlinien unterliegen.lsdist.0 Das Verfahren zum Durchsickern von Einträgen aus der Traffic-Engineering-Datenbank wird als Traffic-Engineering-Datenbankimport bezeichnet, wie in dargestellt.lsdist.0Abbildung 1

Es gibt Richtlinien, die den Importprozess von Traffic Engineering-Datenbanken regeln. Standardmäßig werden keine Einträge aus der Traffic Engineering-Datenbank in die Tabelle verloren.lsdist.0

Ab Junos OS Version 17.4R1 installiert die Traffic Engineering-Datenbank zusätzlich zu den RSVP-TE-Topologieinformationen (Interior Gateway Protocol) in der LSDIST.0-Routingtabelle, wie in dargestellt.Abbildung 1 Vor Junos OS Version 17.4R1 exportierte die Traffic-Engineering-Datenbank nur RSVP-TE-Topologieinformationen. Jetzt können Sie sowohl IGP- als auch Traffic Engineering-Topologieinformationen überwachen. Der BGP-LS liest IGP-Einträge von lsdist.0 und kündigt diese Einträge den BGP-Peers an. Um IGP-Topologieinformationen aus lsdist.0 in BGP-LS zu importieren, verwenden Sie die Konfigurationsanweisung auf Hierarchieebene .set bgp-ls[edit protocols mpls traffic-engineering database import igp-topology]

Export von Traffic Engineering-Datenbanken

BGP kann so konfiguriert werden, dass Routen aus der Tabelle exportiert oder angekündigt werden, abhängig von der Richtlinie.lsdist.0 Dies ist bei jeder Art von Routenursprung in BGP üblich. Um BGP-TE in der Traffic-Engineering-Datenbank anzukündigen, muss BGP mit der BGP-TE-Adressfamilie und einer Exportrichtlinie konfiguriert werden, die Routen für die Neuverteilung an BGP auswählt.

BGP gibt diese Routen dann wie jedes andere NLRI weiter. BGP-Peers, für die die BGP-TE-Familie konfiguriert und ausgehandelt wurde, erhalten BGP-TE-NLRIs. BGP speichert die empfangenen BGP-TE-NLRIs in Form von Routen in der Tabelle, in der auch lokal erstellte BGP-TE-Routen gespeichert sind.lsdist.0 Die von BGP installierten Routen werden dann wie jede andere Route auf andere Peers verteilt.lsdist.0 Daher gilt das Standardverfahren zur Routenauswahl für BGP-TE-NLRIs, die von mehreren Sprechern empfangen werden.

Um domänenübergreifende TE zu erreichen, werden die eingehenden Routen über eine Richtlinie in die Traffic-Engineering-Datenbank eingetragen.lsdist.0 Dieser Vorgang wird als Traffic Engineering-Datenbankexport bezeichnet, wie in dargestellt.Abbildung 1

Es gibt Richtlinien, die den Exportprozess der Traffic Engineering-Datenbank regeln. Standardmäßig werden keine Einträge aus der Tabelle in die Traffic-Engineering-Datenbank weitergegeben.lsdist.0

Ab Junos OS Version 22.4R1 können Sie die Traffic Engineering (TE)-Richtlinien, die aus dem Segment-Routing-Protokoll stammen, als Routen an die Traffic Engineering Database (TED) und in den BGP-Verbindungsstatus verteilen. BGP Link-State sammelt die Informationen zu den TE-Richtlinien, sodass die externen Controller Aktionen wie Pfadberechnung, Neuoptimierung und Netzwerkvisualisierung innerhalb und zwischen Domänen ausführen können.

Konfigurieren Sie so, dass die Segment-Routing-Richtlinien (SR) in TED gespeichert werden können.set protocols source-packet-routing traffic-engineering database

HINWEIS:

Bei SDN-Anwendungen wie PCE und ALTO können die von BGP-TE angekündigten Informationen nicht in die Traffic-Engineering-Datenbank eines Routers gelangen. In solchen Fällen wird ein externer Server, der über BGP-TE eine Peering-Verbindung mit den Routern herstellt, verwendet, um Topologieinformationen in das Himmels-/Orchestrierungssystem zu übertragen, das das Netzwerk umspannt. Diese externen Server können als BGP-TE-Consumer betrachtet werden, wenn sie BGP-TE-Routen empfangen, diese aber nicht ankündigen.

Zuweisen von Glaubwürdigkeitswerten

Sobald die Einträge in der Traffic-Engineering-Datenbank installiert sind, werden die gelernten BGP-TE-Informationen für die CSPF-Pfadberechnung zur Verfügung gestellt. Die Traffic-Engineering-Datenbank verwendet ein Protokollpräferenzschema, das auf Glaubwürdigkeitswerten basiert. Ein Protokoll mit einem höheren Glaubwürdigkeitswert wird einem Protokoll mit einem niedrigeren Glaubwürdigkeitswert vorgezogen. BGP-TE ist in der Lage, Informationen aus mehreren Protokollen gleichzeitig anzukündigen, sodass zusätzlich zu den IGP-installierten Einträgen in der Traffic-Engineering-Datenbank BGP-TE-Einträge vorhanden sein können, die mehr als einem Protokoll entsprechen. Die Exportkomponente für Traffic-Engineering-Datenbanken erstellt für jedes Protokoll, das von BGP-TE unterstützt wird, ein Traffic-Engineering-Datenbankprotokoll und eine Glaubwürdigkeitsstufe. Diese Glaubwürdigkeitswerte können in der CLI konfiguriert werden.

Die Glaubwürdigkeitsreihenfolge für die BGP-TE-Protokolle lautet wie folgt:

• Unbekannt – 80

• OSPF—81

• ISIS Stufe 1—82

• ISIS Stufe 2—83

• Statisch—84

• Direkt—85

Cross-Credibility Path Computation

Nachdem Sie Glaubwürdigkeitswerte zugewiesen haben, wird jede Glaubwürdigkeitsstufe als einzelne Ebene behandelt. Der Constrained Shorted Path First-Algorithmus beginnt mit der höchsten zugewiesenen Glaubwürdigkeit zur niedrigsten und findet einen Pfad innerhalb dieser Glaubwürdigkeitsstufe.

Bei BGP-TE ist es unerlässlich, Pfade über verschiedene Glaubwürdigkeitsstufen hinweg zu berechnen, um Pfade zwischen AS zu berechnen. Beispielsweise werden auf einem Gerät aus Bereich 0, das den Pfad durch Bereich 1 berechnet, unterschiedliche Glaubwürdigkeitseinstellungen angezeigt, da Einträge für Bereich 0 von OSPF und Einträge für Bereich 1 von BGP-TE installiert werden.

Um die Pfadberechnung über Glaubwürdigkeitsebenen hinweg zu ermöglichen, schließen Sie die Anweisung auf den Ebenen , und Hierarchie ein.cross-credibility-cspfedit protocols mpls[edit protocols mpls label-switched-path lsp-name][edit protocols rsvp] Auf der Hierarchieebene umgehen die Ermöglichung von Auswirkungen LSPs und die Loose-Hop-Expansion während des Transports.[edit protocols rsvp]cross-credibility-cspf

Die Konfiguration ermöglicht die Pfadberechnung über Glaubwürdigkeitsstufen hinweg mithilfe des Algorithmus "Eingeschränkter kürzester Pfad zuerst", wobei die Einschränkung nicht auf einer Glaubwürdigkeitsbasis für Glaubwürdigkeit ausgeführt wird, sondern als einzelne Einschränkung, wobei die zugewiesenen Glaubwürdigkeitswerte ignoriert werden.cross-credibility-cspf

BGP-TE, NLRIs und TLVs

Wie andere BGP-Routen können BGP-TE-NLRIs auch über einen Routenreflektor verteilt werden, der BGP-TE NLRI spricht. Junos OS implementiert die Unterstützung für Route Reflection für die BGP-TE-Produktfamilie.

Im Folgenden finden Sie eine Liste der unterstützten NLRIs:

• NLRI verknüpfen

• Knoten-NLRI

• IPv4-Präfix NLRI (Empfangen und Weitergeben)

• IPv6-Präfix NLRI (Empfangen und Weitergeben)

• TE-Richtlinie NLRI

HINWEIS:

Junos OS bietet keine Unterstützung für die Routenunterscheidungsform der oben genannten NRLIs.

Im Folgenden finden Sie eine Liste der unterstützten Felder in Link- und Knoten-NLRIs:

• Protokoll-ID: NLRI hat seinen Ursprung in den folgenden Protokollwerten:

  • ISIS-L1

  • ISIS-L2

  • OSPF

  • SPRING-TE

• Identifier (Bezeichner): Dieser Wert kann konfiguriert werden. Standardmäßig ist der Bezeichnerwert auf festgelegt.0

• Deskriptor für lokale/Remote-Knoten: Dazu gehören:

  • Autonomes System

  • BGP-LS Identifier (BGP-LS-Kennung): Dieser Wert kann konfiguriert werden. Standardmäßig ist der BGP-LS-Kennungswert auf 0

  • Bereichs-ID

  • IGP-Router-ID

• Linkdeskriptoren (Nur für Link-NLRI): Dazu gehören:

  • Lokale/Remote-Identifikatoren verknüpfen

  • IPv4-Schnittstellenadresse

  • IPv4-Nachbaradresse

  • IPv6-Nachbar-/Schnittstellenadresse: Die IPv6-Nachbar- und Schnittstellenadressen stammen nicht, sondern werden nur gespeichert und weitergegeben, wenn sie empfangen werden.

  • Multi-Topologie-ID: Dieser Wert wird nicht erstellt, sondern gespeichert und weitergegeben, wenn er empfangen wird.

Im Folgenden finden Sie eine Liste der unterstützten TLVs mit LINK_STATE Attributen:

• Link-Attribute:

  • Administrative Gruppe

  • Maximale Verbindungsbandbreite

  • Maximal reservierbare Bandbreite

  • Nicht reservierte Bandbreite

  • Standardmetrik von TE

  • SRLG

  • Die folgenden TLVs, die nicht entstehen, sondern nur gespeichert und weitergegeben werden, wenn sie empfangen werden:

    • Undurchsichtige Link-Attribute

    • MPLS-Protokollmaske

    • Metrisch

    • Art des Link-Schutzes

    • Linkname-Attribut

• Knotenattribute:

  • IPv4 Router-ID

  • Node-Flag-Bits: Nur das Überladungsbit wird gesetzt.

  • Die folgenden TLVs, die nicht entstehen, sondern nur gespeichert und weitergegeben werden, wenn sie empfangen werden:

    • Multi-Topologie

    • OSPF-spezifische Knoteneigenschaften

    • Undurchsichtige Knoteneigenschaften

    • Name des Knotens

    • IS-IS-Bereichskennung

    • IPv6 Router-ID

  • Präfixattribute: Diese TLVs werden wie alle anderen unbekannten TLVs gespeichert und weitergegeben.

Unterstützte und nicht unterstützte Funktionen

Junos OS unterstützt die folgenden Funktionen bei der Link-State-Verteilung mithilfe von BGP:

• Werbung für Multiprotokoll-gesicherte Weiterleitungsfähigkeit

• Übertragung und Empfang von Node- und Link-State-BGP- und BGP-TE-NLRIs

• Aktives Nonstop-Routing für BGP-TE-NLRIs

• Richtlinien

Junos OS unterstützt die folgenden Funktionen für die Link-State-Verteilung mithilfe von BGP:not

• Aggregierte Topologien, Verbindungen oder Knoten

• Unterstützung von Routenunterscheidungsmerkmalen für BGP-TE-NLRIs

• Multi-Topologie-Identifikatoren

• Bezeichner für mehrere Instanzen (mit Ausnahme der Standard-Instanz-ID 0)

• Werbung für den Link- und Knotenbereich TLV

• Werbung für MPLS-Signalisierungsprotokolle

• Importieren von Knoten- und Linkinformationen mit überlappenden Adressen

BGP-Link-State-Erweiterungen für das Quellpaket-Routing in Netzwerken (SPRING)

Ab Junos OS Version 17.2R1 wird die BGP-Link-State-Adressfamilie erweitert, um die SPRING-Topologieinformationen (Source Packet Routing in Networking) an SDN-Controller (Software-Defined Networking) zu verteilen. BGP lernt in der Regel die Link-State-Informationen von IGP und verteilt sie an BGP-Peers. Neben BGP kann der SDN-Controller Link-State-Informationen direkt von IGP abrufen, wenn der Controller Teil einer IGP-Domäne ist. Die BGP-Link-State-Verteilung bietet jedoch einen skalierbaren Mechanismus zum Exportieren der Topologieinformationen. BGP-Link-State-Erweiterungen für SPRING werden in Interdomain-Netzwerken unterstützt.

• Source Packet Routing in Networking (SPRING)
• Fluss der BGP-Link-State-SPRING-Daten
• Unterstützte BGP-Link-State-Attribute und TLVs sowie nicht unterstützte Funktionen für BGP-Link-State mit SPRING

Fluss der BGP-Link-State-SPRING-Daten

Abbildung 2 Stellt den Datenfluss von BGP-Link-State-SPRING-Daten dar, die IS-IS an die Traffic-Engineering-Datenbank überträgt.

Abbildung 2: BGP-Link-State-Quellpaket-Routing in Netzwerken (SPRING)

• IGP überträgt die SPRING-Attribute an die Traffic-Engineering-Datenbank.

• SPRING-Funktionen und Algorithmusinformationen werden als Knotenattribute in die Traffic-Engineering-Datenbank übertragen.

• Benachbarte SID- und LAN-benachbarte SID-Informationen werden als Verbindungsattribute übertragen.

• Präfix-SID- oder Node-SID-Informationen werden als Präfixattribute übertragen.

• Ein neuer Satz oder eine Änderung an bestehenden Attributen löst IGP-Aktualisierungen in der Traffic-Engineering-Datenbank mit neuen Daten aus.

  VORSICHT:

  Wenn Traffic Engineering auf IGP-Ebene deaktiviert ist, wird keines der Attribute in die Traffic Engineering-Datenbank übertragen.

• Alle Parameter im BGP-NLRI für Traffic Engineering, einschließlich der Verbindungs-, Knoten- und Präfixdeskriptoren, werden aus Einträgen in der Traffic Engineering-Datenbank abgeleitet.

• Die Traffic-Engineering-Datenbank importiert Routeneinträge in die Routing-Tabelle von IGP, abhängig von der Richtlinie.lsdist.0

• Die Standardrichtlinie von BGP besteht darin, Routen zu exportieren, die nur BGP bekannt sind. Sie konfigurieren eine Exportrichtlinie für Nicht-BGP-Routen in der Routing-Tabelle.lsdis.0 Diese Richtlinie kündigt einen Eintrag an, der aus der Traffic-Engineering-Datenbank gelernt wurde.

Verifizieren des durch BGP erlernten NLRI-Knotens mit OSPF als IGP

Im Folgenden finden Sie eine Beispielausgabe zur Überprüfung des NLRI-Knotens, der über BGP mit OSPF als IGP erlernt wurde:

Verifizieren des Präfixes NLRI, das durch BGP mit OSPF als IGP gelernt wurde

Im Folgenden finden Sie eine Beispielausgabe zur Überprüfung des Präfixes NLRI, das über BGP mit OSPF als IGP gelernt wurde:

Vorteile von BGP Classful Transport Planes

• Network-Slicing: Service- und Transportschichten sind voneinander entkoppelt und legen mit dem End-to-End-Slicing über mehrere Domänen hinweg den Grundstein für Network-Slicing und Virtualisierung, wodurch die Investitionskosten erheblich reduziert werden.

• Interoperabilität zwischen Domänen: Erweitert die Bereitstellung von Transportklassen über kooperierende Domänen hinweg, sodass die verschiedenen Transportsignalisierungsprotokolle in jeder Domäne zusammenarbeiten können. Gleichen Sie alle Unterschiede zwischen erweiterten Communitynamespaces ab, die in den einzelnen Domänen verwendet werden können.

• Farbige Auflösung mit Fallback: Ermöglicht die Auflösung über farbige Tunnel (RSVP, IS-IS-flexibler Algorithmus) mit flexiblen Fallback-Optionen über Best-Effort-Tunnel oder andere Farbtunnel.

• Quality-of-Service: Passt das Netzwerk an und optimiert es, um die End-to-End-SLA-Anforderungen zu erfüllen.
• Nutzung vorhandener Bereitstellungen: Unterstützt gut implementierte Tunneling-Protokolle wie RSVP sowie neue Protokolle, wie z. B. den flexiblen IS-IS-Algorithmus, wodurch der ROI erhalten bleibt und die Betriebskosten gesenkt werden.

Terminologie der BGP-Classful-Transportebenen

Dieser Abschnitt enthält eine Zusammenfassung häufig verwendeter Begriffe zum Verständnis der BGP-Classful-Transportebene.

• Serviceknoten: Ingress Provider Edge (PE)-Geräte, die Servicerouten (Internet und Layer 3-VPN) senden und empfangen.

• Border Node – Gerät am Verbindungspunkt verschiedener Domänen (IGP-Bereiche oder ASs).

• Transportknoten: Gerät, das LU-Routen (BGP-Labeled Unicast) sendet und empfängt.

• BGP-VPN: VPNs, die mit RFC4364-Mechanismen erstellt wurden.

• Route Target (RT): Typ der erweiterten Community, die zum Definieren der VPN-Mitgliedschaft verwendet wird.

• Route Distinguisher (RD) – Kennung, die verwendet wird, um zu unterscheiden, zu welchem VPN oder Virtual Private LAN Service (VPLS) eine Route gehört. Jeder Routinginstanz muss ein eindeutiger Routenunterscheidungsmerkmal zugeordnet sein.

• Auflösungsschema: Wird verwendet, um die Protokoll-Next-Hop-Adresse (PNH) in Auflösungs-RIBs aufzulösen, die Fallback bereitstellen.

  Sie ordnen die Routen den verschiedenen Transport-RIBs im System auf der Grundlage einer Mapping-Community zu.

• Servicefamilie: BGP-Adressfamilie, die für die Ankündigung von Routen für Datenverkehr verwendet wird, im Gegensatz zu Tunneln.

• Transportfamilie : BGP-Adressfamilie, die für Ankündigungstunnel verwendet wird, die wiederum von Dienstrouten zur Auflösung verwendet werden.

• Transporttunnel: Ein Tunnel, über den ein Dienst Datenverkehr leiten kann, z. B. GRE, UDP, LDP, RSVP, SR-TE, BGP-LU.

• Tunneldomäne: Eine Domäne des Netzwerks, die Serviceknoten und Grenzknoten unter einer einzigen administrativen Kontrolle enthält, zwischen der ein Tunnel besteht. Ein End-to-End-Tunnel, der sich über mehrere benachbarte Tunneldomänen erstreckt, kann erstellt werden, indem die Knoten mithilfe von Beschriftungen zusammengefügt werden.

• Transportklasse: Eine Gruppe von Transporttunneln, die den gleichen Servicetyp anbieten.

• Transportklasse RT – Ein neues Format des Routenziels, das zur Identifizierung einer bestimmten Transportklasse verwendet wird.

  Ein neues Format von Route Target, das zur Identifizierung einer bestimmten Transportklasse verwendet wird.

• Transport-RIB: Am Service-Knoten und am Grenzknoten verfügt eine Transportklasse über ein zugeordnetes Transport-RIB, das ihre Tunnelrouten enthält.

• Transport RTI – Eine Routing-Instanz; Container der Transport-RIB und der zugehörigen Transportklasse Route Target und Route Distinguisher.

• Transportebene: Gruppe von Transport-RTIs, die dieselbe Transportklasse RT importieren. Diese werden wiederum zusammengefügt, um sich über Tunneldomänengrenzen hinweg zu erstrecken, wobei ein Mechanismus ähnlich dem Inter-AS option-b verwendet wird, um Beschriftungen an Grenzknoten (nexthop-self) auszutauschen und eine End-to-End-Transportebene zu bilden.

• Mapping community: Community auf einer Dienstroute, die für die Auflösung über eine Transportklasse zugeordnet werden soll.

Grundlegendes zu BGP Classful Transport Planes

Sie können BGP-Classful-Transportebenen verwenden, um Transportklassen für die Klassifizierung einer Gruppe von Transporttunneln in einem AS-internen Netzwerk basierend auf den Traffic-Engineering-Merkmalen zu konfigurieren und diese Transporttunnel zu verwenden, um Servicerouten mit dem gewünschten SLA und dem beabsichtigten Fallback abzubilden.

BGP-Classful-Transportebenen können diese Tunnel auf domänenübergreifende Netzwerke ausdehnen, die sich über mehrere Domänen (ASs oder IGP-Bereiche) erstrecken, während die Transportklasse erhalten bleibt. Dazu müssen Sie die BGP-BGP-Familie Classful Trasport Transport Layer zwischen den Border- und Service-Knoten konfigurieren.

Sowohl in Inter-AS- als auch in Intra-AS-Implementierungen können viele Transporttunnel (MPLS LSPs, IS-IS flexibler Algorithmus, SR-TE) aus den Service- und Border-Knoten erstellt werden. Die LSPs können mit unterschiedlichen Signalisierungsprotokollen in verschiedenen Domänen signalisiert und mit unterschiedlichen Traffic-Engineering-Merkmalen (Klasse oder Farbe) konfiguriert werden. Der Transporttunnelendpunkt fungiert auch als Dienstendpunkt und kann sich in derselben Tunneldomäne wie der Eingangsknoten des Diensts oder in einer benachbarten oder nicht benachbarten Domäne befinden. Sie können BGP-Classful-Transportebenen verwenden, um Services über LSPs mit bestimmten Traffic-Engineering-Merkmalen entweder innerhalb einer einzelnen Domäne oder über mehrere Domänen hinweg zu ersetzen.

BGP-Transportebenen der Klasse verwenden die BGP-VPN-Technologie wieder, wodurch die Tunneling-Domänen lose gekoppelt und koordiniert bleiben.

• Die NLRI (Network Layer Reachability Information) sind RD:TunnelEndpoint , die zum Ausblenden von Pfaden verwendet werden.
• Das Routenziel gibt die Transportklasse der LSPs an und leitet Routen an das entsprechende Transport-RIB auf dem Zielgerät weiter.
• Jedes Transporttunneling-Protokoll installiert eine Eingangsroute in die Routing-Tabelle transport-class.inet.3, modelliert die Tunnel-Transportklasse als VPN-Routenziel und sammelt die LSPs derselben Transportklasse in der Transport-rib-Routing-Tabelle transport-class.inet.3.

• Routen in dieser Routinginstanz werden in der BGP-Classful-Transportebene (inet transport) AFI-SAFI nach ähnlichen Verfahren wie RFC-4364 angekündigt.

• Wenn Sie die Grenze zwischen AS-Verbindungen überschreiten, müssen Sie die Option-b-Verfahren befolgen, um die Transporttunnel in diesen benachbarten Domänen zu verknüpfen.

  Ebenso müssen Sie beim Überqueren von AS-Regionen die Option-b-Verfahren befolgen, um die Transporttunnel in den verschiedenen TE-Domänen zu verknüpfen.

• Sie können Auflösungsschemata definieren, um die Absicht für die Vielzahl von Transportklassen in einer Fallback-Reihenfolge anzugeben.

• Sie können Servicerouten und BGP-Classful-Transportrouten über diese Transportklassen auflösen, indem Sie die Mapping-Community auf sie übertragen.

Die BGP-Transportfamilie der Klasse läuft parallel zur BGP-LU-Transportschichtfamilie. In einem nahtlosen MPLS-Netzwerk mit BGP-LU ist es eine Herausforderung, die strengen SLA-Anforderungen von 5G zu erfüllen, da die verkehrstechnischen Eigenschaften der Tunnel nicht über Domänengrenzen hinweg bekannt sind oder erhalten bleiben. BGP-Classful-Transportebenen bieten eine betriebseinfache und skalierbare Möglichkeit, mehrere Pfade für Remote-Loopbacks zusammen mit den Transportklasseninformationen in der nahtlosen MPLS-Architektur anzukündigen. In BGP-Routen der Classful-Tranport-Familie werden verschiedene SLA-Pfade mithilfe der erweiterten Community Transport Route-Target dargestellt, die die Farbe der Transportklasse trägt. Dieses Transportroutenziel wird von den empfangenden BGP-Routern verwendet, um die BGP-Classful-Transportroute der entsprechenden Transportklasse zuzuordnen. Bei der erneuten Ankündigung der BGP-Classful-Transportrouten tauscht MPLS die Routen, verbindet die AS-internen Tunnel derselben Transportklasse miteinander und bildet so einen End-to-End-Tunnel, der die Transportklasse beibehält.

AS-interne Implementierung von BGP Classful Transport Planes

Abbildung 4 veranschaulicht eine Netzwerktopologie mit Vorher-Nachher-Szenarien zur Implementierung von BGP-Classful-Transportebenen in einer AS-internen Domäne. Die Geräte PE11 und PE12 verwenden RSVP-LSPs als Transporttunnel und alle Transporttunnelrouten sind in inet.3 RIB installiert. Durch die Implementierung von BGP-Classful-Transort-Ebenen können RSVP-Transporttunnel ähnlich wie Segment-Routing-Tunnel farbsensibel sein.

Abbildung 4: Intra-AS-Domäne: Vorher-Nachher-Szenarien für die Implementierung von BGP Classful Transport Planes

So klassifizieren Sie Transporttunnel in einer AS-internen Einrichtung in BGP-Transportklassen:

1. Definieren Sie die Transportklasse am Serviceknoten (Eingangs-PE-Geräte), z. B. Gold und Bronze, und weisen Sie der definierten Transportklasse Farbgemeinschaftswerte zu.

   Beispielkonfiguration:

2. Ordnen Sie den Transporttunnel einer bestimmten Transportklasse am Eingangsknoten der Tunnel zu.

   Beispielkonfiguration:

Intra-AS BGP-Funktionen der Classful-Transportebene:

• BGP Classful Transport erstellt vordefinierte Transport-RIBs pro benannter Transportklasse (Gold und Bronze) und leitet automatisch die Mapping-Community aus ihrem Farbwert (100 und 200) ab.
• AS-interne Transportrouten werden vom Tunneling-Protokoll in Transport-RIBs aufgefüllt, wenn es einer Transportklasse zugeordnet ist.

  In diesem Beispiel werden RSVP-LSP-Routen, die der Transportklasse Gold (Farbe 100) und der Transportklasse Bronze (Farbe 200) zugeordnet sind, in den Transport-RIBs junos-rti-tc-<100>.inet.3 bzw. junos-rti-tc-<200>.inet.3 installiert.

• Serviceknoten (Eingangs-PEs) gleichen die erweiterte Farbgemeinschaft (color:0:100 und color:0:200) der Serviceroute mit der Zuordnungs-Community in vordefinierten Auflösungs-RIBs ab und lösen den Protocol Next Hop (PNH) in entsprechende Transport-RIBs auf (entweder junos-rti-tc-<100>.inet.3 oder junos-rti-tc-<200>.inet.3).
• BGP-Routen werden an ein Auflösungsschema gebunden, indem sie die zugehörige Mapping-Community übertragen.
• Jede Transportklasse erstellt automatisch zwei vordefinierte Auflösungsschemata und leitet automatisch die Mapping-Community ab.

  Ein Auflösungsschema dient zum Auflösen von Servicerouten, die Color:0:<val> als Zuordnungs-Community verwenden.

  Das andere Auflösungsschema dient zum Auflösen von Transportrouten, die Transport-Target:0:<val> als Zuordnungs-Community verwenden.

• Wenn Service-Route-PNH nicht mit RIBs aufgelöst werden kann, die im vordefinierten Auflösungsschema aufgeführt sind, kann auf die inet.3-Routing-Tabelle zurückgegriffen werden.
• Sie können auch Fallback zwischen verschiedenfarbigen Transport-RIBs konfigurieren, indem Sie benutzerdefinierte Auflösungsschemata in der Konfigurationshierarchie verwenden.[edit routing-options resolution scheme]

Inter-AS-Implementierung von BGP Classful Transport Planes

In einem AS-übergreifenden Netzwerk wird BGP-LU in ein BGP-Classful-Transportnetzwerk konvertiert, nachdem mindestens zwei Transportklassen (Gold und Bronze) auf allen Service-Knoten oder PE-Geräten und Grenzknoten (ABRs und ASBRs) konfiguriert wurden.

So konvertieren Sie die Transporttunnel in BGP Classful Transport:

1. Definieren Sie die Transportklasse an den Serviceknoten (Eingangs-PE-Geräte) und den Grenzknoten (ABRs und ASBRs), z. B. Gold und Broze.

   Beispielkonfiguration:

2. Ordnen Sie die Transporttunnel einer bestimmten Transportklasse am Eingangsknoten der Tunnel zu (Eingangs-PEs, ABRs und ASBRs).

   Beispielkonfiguration:

   Für RSVP-LSPs

   Für IS-IS flxible-Algorithmus

3. Aktivieren Sie die neue Familie für den BGP-Classful-Transport (inet transport) und BGP-LU (inet labeled-unicast) im Netzwerk.

   Beispielkonfiguration:

4. Kündigen Sie Servicerouten vom ausgehenden PE-Gerät mit einer entsprechenden erweiterten Farbgemeinschaft an.

   Beispielkonfiguration:

Inter-AS BGP Classful Transport Plane-Funktionalität:

1. BGP-Classful-Transportebenen erstellen vordefinierte Transport-RIBs pro benannter Transportklasse (Gold und Bronze) und leiten automatisch die Mapping-Community aus ihrem Farbwert ab.

2. AS-interne Transportrouten werden in Transport-RIBs durch Tunneling-Protokolle aufgefüllt, wenn sie einer Transportklasse zugeordnet sind.

   Beispielsweise werden Transporttunnelrouten, die der Transportklasse Gold und Bronze zugeordnet sind, in den Transport-RIBs junos-rti-tc-<100>.inet.3 bzw. junos-rti-tc-<200>.inet.3 installiert.

3. BGP-Classful-Transportebenen verwenden eindeutige Route Distinguisher und Route Target, wenn die Transporttunnelrouten von jedem Transport-RIB in die Routing-Tabelle bgp.transport.3 kopiert werden.
4. Border-Knoten kündigen Routen von der Routing-Tabelle bgp.transport.3 an ihre Peers in anderen Domänen an, wenn der Familien-inet-Transport in der BGP-Sitzung ausgehandelt wird.
5. Der empfangende Grenzknoten installiert diese bgp-ct-Routen in der Routing-Tabelle bgp.transport.3 und kopiert diese Routen basierend auf dem Transportroutenziel in die entsprechenden Transport-RIBs.
6. Der Serviceknoten vergleicht die Farbgemeinschaft in der Serviceroute mit einer Zuordnungsgemeinschaft in den Auflösungsschemata und löst PNH im entsprechenden Transport-RIB auf (entweder junos-rti-tc-<100>.inet.3 oder junos-rti-tc-<200>. inet.3).
7. Border-Knoten verwenden vordefinierte Auflösungsschemata für die PNH-Auflösung des Transportwegs.
8. Beide Auflösungsschemata sind vordefiniert oder benutzerdefiniert und unterstützen die PNH-Auflösung für die Dienstroute. Predefined verwendet inet.3 als Fallback, und das benutzerdefinierte Auflösungsschema ermöglicht die Verwendung einer Liste von Transport-RIBs in der Reihenfolge, die beim Auflösen von PNH angegeben ist.
9. Wenn Service-Route-PNH nicht mit RIBs aufgelöst werden kann, die im benutzerdefinierten Auflösungsschema aufgeführt sind, wird die Route verworfen.

BGP Classful Transport (BGP-CT) mit zugrunde liegenden farbigen SR-TE-Tunneln – Übersicht

Vorteile von BGP-CT mit darunter liegenden farbigen SR-TE-Tunneln

• Löst Skalierungsprobleme, die in Zukunft auftreten können, wenn das Netzwerk wächst.
• Bietet Interkonnektivität für Domänen, die unterschiedliche Technologien verwenden.
• Entkoppelt Services und Transportschichten, was zu einem vollständig verteilten Netzwerk führt.
• Bietet unabhängiges Bandbreitenmanagement durch einen domäneninternen Traffic-Engineering-Controller für SR-TE.

Große Netzwerke, die ständig wachsen und sich weiterentwickeln, erfordern eine nahtlose Segment-Routing-Architektur. Ab Junos OS Version 21.2,R1 unterstützen wir BGP-CT mit zugrunde liegendem Transport als farbige SR-TE-Tunnel. BGP-CT kann Servicerouten mithilfe der Transport-RIBs auflösen und den nächsten Hop berechnen. Services, die derzeit über BGP-CT unterstützt werden, können auch die zugrunde liegenden farbigen SR-TE-Tunnel für die Routenauflösung verwenden. Die Services können nun die zugrunde liegenden farbigen SR-TE-Tunnel verwenden, wie z. B. die statischen farbigen, BGP-SR-TE-, programmierbaren rpd- und PCEP-farbigen Tunnel. BGP-CT nutzt die Erreichbarkeit des nächsten Hops, um Dienstrouten über die gewünschte Transportklasse aufzulösen.

Um die BGP-CT-Service-Routenauflösung über zugrunde liegende farbige SR-TE-Tunnel zu aktivieren, fügen Sie die Anweisung auf Hierarchieebene ein.use-transport-class[edit protocols source-packet-routing]

PathErr-Meldungen

PathErr-Nachrichten melden eine Vielzahl von Problemen mit Hilfe unterschiedlicher Code- und Subcode-Nummern. Eine vollständige Liste dieser PathErr-Meldungen finden Sie in RFC 2205, Resource Reservation Protocol (RSVP), Version 1, Functional Specification und RFC 3209, RSVP-TE: Erweiterungen für RSVP für LSP-Tunnel.

Wenn Sie die Anweisung konfigurieren, werden zwei Kategorien von PathErr-Meldungen untersucht, die speziell Verbindungsfehler darstellen:rsvp-error-hold-time

• Die Verbindungsbandbreite ist für diesen LSP gering: Angeforderte Bandbreite nicht verfügbar – Code 1, Subcode 2

  Diese Art von PathErr-Nachricht stellt ein globales Problem dar, das alle LSPs betrifft, die die Verbindung übertragen. Sie weisen darauf hin, dass die tatsächliche Verbindungsbandbreite geringer ist als die vom LSP geforderte Bandbreite, und dass es sich bei den Bandbreiteninformationen in der Traffic-Engineering-Datenbank wahrscheinlich um eine Überschätzung handelt.

  Wenn diese Art von Fehler empfangen wird, wird die verfügbare Verbindungsbandbreite in der lokalen Traffic-Engineering-Datenbank reduziert, was sich auf alle zukünftigen LSP-Berechnungen auswirkt.

• Link für diesen Sprachdienstleister nicht verfügbar:

  • Fehler bei der Zugangssteuerung – Code 1, beliebiger Subcode außer 2

  • Fehler bei der Richtliniensteuerung – Code 2

  • Service Preempted – Code 12

  • Routing-Problem – keine Route zum Ziel verfügbar – Code 24, Subcode 5

  Diese Arten von PathErr-Nachrichten sind im Allgemeinen für den angegebenen LSP relevant. Der Ausfall dieses Sprachdienstleisters bedeutet nicht zwangsläufig, dass auch andere Sprachdienstleister ausfallen könnten. Diese Fehler können auf Probleme mit der maximalen Übertragungseinheit (MTU), vorzeitige Dienstentfernung (entweder manuell vom Betreiber oder von einem anderen LSP mit höherer Priorität), einen Ausfall einer Next-Hop-Verbindung, einen Ausfall eines Next-Hop-Nachbarn oder eine Dienstablehnung aufgrund von Richtlinienüberlegungen hinweisen. Es empfiehlt sich, diesen speziellen LSP von der Verbindung weg zu routen.

Identifizieren des Problemzuhangs

Jede PathErr-Nachricht enthält die IP-Adresse des Absenders. Diese Informationen werden unverändert an den Eingangsrouter weitergegeben. Durch eine Suche in der Traffic-Engineering-Datenbank kann der Knoten identifiziert werden, von dem die PathErr-Nachricht stammt.

Jede PathErr-Nachricht enthält genügend Informationen, um die RSVP-Sitzung zu identifizieren, die die Nachricht ausgelöst hat. Wenn es sich um einen Transit-Router handelt, leitet er die Nachricht einfach weiter. Wenn es sich bei diesem Router um den Eingangsrouter (für diese RSVP-Sitzung) handelt, verfügt er über die vollständige Liste aller Knoten und Links, die die Sitzung durchlaufen soll. In Verbindung mit den ursprünglichen Knoteninformationen kann die Verbindung eindeutig identifiziert werden.

Konfigurieren des Routers zur Verbesserung der Genauigkeit der Traffic Engineering-Datenbank

Um die Genauigkeit der Traffic Engineering-Datenbank zu verbessern, konfigurieren Sie die Anweisung.rsvp-error-hold-time Wenn diese Anweisung konfiguriert ist, lernt ein Quellknoten (Eingang eines RSVP-LSP) aus den Fehlern seines LSP, indem er PathErr-Nachrichten überwacht, die von nachgeschalteten Knoten übertragen werden. Die Informationen aus den PathErr-Meldungen fließen in nachfolgende LSP-Berechnungen ein, wodurch die Genauigkeit und Geschwindigkeit der LSP-Einrichtung verbessert werden kann. Einige PathErr-Nachrichten werden auch verwendet, um Bandbreiteninformationen der Traffic-Engineering-Datenbank zu aktualisieren, wodurch Inkonsistenzen zwischen der Traffic-Engineering-Datenbank und dem Netzwerk verringert werden.

Fügen Sie die folgende Anweisung ein, um zu konfigurieren, wie lange MPLS RSVP-PathErr-Nachrichten speichern und bei der CSPF-Berechnung berücksichtigen soll:rsvp-error-hold-time

Sie können diese Anweisung auf den folgenden Hierarchieebenen einbinden:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

Die Zeit kann einen Wert zwischen 1 und 240 Sekunden haben. Der Standardwert ist 25 Sekunden. Wenn Sie den Wert 0 konfigurieren, wird die Überwachung von PathErr-Meldungen deaktiviert.