Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

MPLS Traffic Engineering-Konfiguration

MPLS und Traffic Engineering

Traffic-Engineering ermöglicht Ihnen die Steuerung des Pfads, dem Datenpakete folgen, unter Umgehung des Standard-Routingmodells, das Routing-Tabellen verwendet. Das Traffic-Engineering verschiebt die Datenströme von überlasteten Links in alternative Links, die nicht vom automatisch berechneten, zielbasierten kürzesten Pfad ausgewählt werden. Mit Traffic Engineering können Sie:

  • Machen Sie teure Langstreckenglasfaser effizienter.

  • Steuern Sie, wie Datenverkehr bei einzelnen oder mehreren Ausfällen umgeleitet wird.

  • Klassifizieren Sie wichtigen und regelmäßigen Datenverkehr auf Pfadbasis.

Der Kern des Traffic-Engineering-Designs basiert auf dem Aufbau von Label-Switched Paths (LSPs) zwischen Routern. Ein LSP ist verbindungsorientiert, z. B. eine virtuelle Verbindung in Frame-Relay oder ATM. LSPs sind nicht zuverlässig: Bei einem LSP eingehende Pakete haben keine Zustellungsgarantien, obgleich bevorzugte Behandlung möglich ist. LSPs gleichen auch unidirektionalen Tunneln, in denen die an einen Pfad eingehenden Pakete verkapselt und über den gesamten Pfad geschaltet werden, ohne dass sie von zwischengeschalteten Knoten berühren werden. LSPs ermöglichen eine ab gehende Kontrolle über die Art und Weise, wie Pakete in einem Netzwerk weitergeleitet werden. Um Zuverlässigkeit zu gewährleisten, kann ein LSP eine Reihe von primären und sekundären Pfaden verwenden.

LSPs können nur für BGP konfiguriert werden (Datenverkehr, dessen Ziel sich außerhalb eines autonomen Systems befindet [AS].). In diesem Fall wird der Datenverkehr innerhalb AS nicht von LSPs beeinträchtigt. LSPs können auch für BGP und Interior Gateway Protocol (IGP) konfiguriert werden. daher wird sowohl intra-AS als auch Inter-AS-Datenverkehr von den LSPs betroffen.

MPLS Traffic Engineering und Signalprotokolle – Überblick

Traffic-Engineering vereinfacht effiziente und zuverlässige Netzwerkabläufe und optimiert gleichzeitig Netzwerkressourcen und Datenverkehrsleistung. Traffic-Engineering bietet die Möglichkeit, den Datenverkehrsfluss von dem vom Interior Gateway Protocol (IGP) ausgewählten kürzesten Pfad zu einem potenziell weniger überlasteten physischen Pfad in einem Netzwerk zu bewegen. Zur Unterstützung des Traffic-Engineerings muss das Netzwerk nicht nur das Source-Routing, sondern auch die folgenden Aufgaben unterstützen:

  • Berechnung eines Pfads an der Quelle unter Berücksichtigung aller Beschränkungen, wie Bandbreite und administrative Anforderungen.

  • Verteilt die Informationen zur Netzwerktopologie und Verbindungsattributen im gesamten Netzwerk, sobald der Pfad berechnet wurde.

  • Reservieren Sie Netzwerkressourcen, und ändern Sie Link-Attribute.

Wenn der Transitdatenverkehr über ein IP-Netzwerk geroutet wird, MPLS häufig zur Entwicklung seiner Verkehrsverkehrsflusses verwendet wird. Obwohl der exakte Pfad durch das Transitnetzwerk für Absender oder Empfänger des Datenverkehrs weniger wichtig ist, möchten Netzwerkadministratoren den Datenverkehr oft effizienter zwischen bestimmten Quell- und Zieladressenpaaren routen. Indem Sie jedem Paket ein kurzes Label mit speziellen Routinganweisungen hinzufügen, können MPLS Pakete vom Router zum Router über das Netzwerk switchen, anstatt Pakete auf der Basis von Next-Hop-Suchups zu weiterleiten. Die resultierenden Routen werden als Label Switched Paths (LSPs) bezeichnet. LSPs steuern die Weiterleitung des Datenverkehrs durch das Netzwerk und beschleunigen die Weiterleitung des Datenverkehrs.

LSPs können manuell oder über Signalisierungsprotokolle erstellt werden. Signalprotokolle werden in einer Umgebung verwendet, MPLS um LSPs für den Datenverkehr im Transitnetzwerk zu erstellen. Junos OS unterstützt zwei Signalisierungsprotokolle: LDP und das Resource Reservation Protocol (RSVP).

MPLS-Traffic Engineering verwendet folgende Komponenten:

  • MPLS-LSPs für die Paketweiterleitung

  • IGP für die Verteilung von Informationen über die Netzwerktopologie und Verbindungsattribute

  • Constrained Shortest Path First (CSPF) für Pfadberechnung und Pfadauswahl

  • RSVP-Erweiterungen zur Festlegung des Weiterleitungsstatus entlang des Pfads und zur Reserve von Ressourcen entlang des Pfads

Junos OS unterstützt außerdem Traffic-Engineering in verschiedenen Regionen OSPF Region.

Traffic-Engineering-Funktionen

Die Aufgabe der Zuordnung von Datenverkehrsflüssen zu einer vorhandenen physischen Topologie wird Traffic-Engineering genannt. Traffic-Engineering bietet die Möglichkeit, den Datenverkehrsfluss von dem vom Interior Gateway Protocol (IGP) ausgewählten kürzesten Pfad weg auf einen potenziell weniger überlasteten physischen Pfad im gesamten Netzwerk zu verschieben.

Traffic-Engineering bietet folgende Funktionen:

  • Routen Sie Primärpfade zu bekannten Engpässen oder Engpässen im Netzwerk.

  • Präzise Kontrolle darüber, wie Datenverkehr umgeleitet wird, wenn auf dem primären Pfad ein oder mehrere Fehler ausschlagen müssen.

  • Effizientere Nutzung verfügbarer Gesamtbandbreite und Langstreckenfaser, indem sichergestellt wird, dass Untergruppen des Netzwerks nicht überlastet werden, während andere Teilgruppen des Netzwerks entlang potenziell alternativer Pfade nicht ausgelastet sind.

  • Maximieren Der betrieblichen Effizienz.

  • Verbessern Sie die datenverkehrsorientierten Leistungscharakteristiken des Netzwerks durch Minimieren von Paketverlusten, Minimieren von bestimmten Engpässen und Maximieren des Durchsatzes.

  • Verbessern der statistischen Leistungseigenschaften des Netzwerks (wie Verlustquote, Verzögerungsschwankung und Übertragungsverzögerung), die zur Unterstützung eines Multiservices-Internets erforderlich sind.

Komponenten des Traffic Engineering

Im Junos®Betriebssystem (OS) wird Traffic Engineering mit MPLS RSVP implementiert. Traffic Engineering besteht aus vier Funktionskomponenten:

Konfigurieren des Traffic Engineering für LSPs

Wenn Sie einen LSP konfigurieren, wird eine Host-Route (eine 32-Bit-Maske) im ein- und ausgehenden Router installiert. die Adresse der Hostroute ist die Zieladresse des LSP. Die Option für die Anweisung auf Hierarchieebene ist standardmäßig aktiviert (Sie können diese Option auch explizit konfigurieren), sodass nur BGP bgptraffic engineering[edit protocols mpls] LSPs in der bgp Routenberechnung verwenden können. Mit den traffic-engineering anderen Anweisungsoptionen können Sie dieses Verhalten in der Master-Routing-Instanz ändern. Diese Funktion ist für bestimmte Routing-Instanzen nicht verfügbar. Sie können auch immer nur eine der Anweisungsoptionen ( oder traffic-engineeringbgp ) bgp-igpbgp-igp-both-ribsmpls-forwarding aktivieren.

Anmerkung:

Das Aktivieren oder Deaktivieren einer der Anweisungsoptionen bewirkt, dass alle MPLS entfernt und dann in die traffic-engineering Routingtabellen ein- oder deaktiviert werden.

Sie können OSPF und Traffic-Engineering so konfigurieren, dass die LSP-Metrik in zusammenfassenden Link-State-Ankündigungen (LSAs) ausgeschrieben wird, wie in diesem Abschnitt Die LSP-Metrik in zusammengefassten LSAs anzeigen beschrieben.

In den folgenden Abschnitten wird die Konfiguration von Traffic Engineering für LSPs beschrieben:

Verwenden von LSPs für BGP- IGP Datenverkehrsweiterleitung

Sie können BGP und die IGPs LSPs für die Weiterleitung von Datenverkehr verwenden, der für Egress-Router bestimmt ist, indem Sie die Option bgp-igp für die Aussage traffic-engineering auswählen. Diese bgp-igp Option bewirkt, dass alle Inet.3-Routen in die Inet.0-Routingtabelle verschoben werden.

Geben Sie auf dem Ingress-Router bgp-igp die Option für die Erklärung traffic-engineering an:

Sie können diese Aussage in den folgenden Hierarchieebenen enthalten:

  • [edit protocols mpls]

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

    Anmerkung:

    Die bgp-igp Option für die Aussage kann nicht für VPN konfiguriert traffic-engineering werden. VPNs erfordern, dass routen in der inet.3-Routingtabelle aufgeführt sind.

Verwendung von LSPs für die Weiterleitung in virtuellen privaten Netzwerken

VPNs setzen voraus, dass Routen in der inet.3-Routingtabelle verbleiben, um ordnungsgemäß zu funktionieren. Konfigurieren Sie für VPNs die Option der Anweisung, um zu verursachen, BGP, und die IGPs LSPs für die Weiterleitung von Datenverkehr, der für bgp-igp-both-ribstraffic-engineering Egress-Router bestimmt ist. Diese Option installiert die bgp-igp-both-ribs ingress-Routen sowohl in der Inet.0-Routingtabelle (für IPv4-Unicast-Routen) als auch in der Inet.3-Routingtabelle (für MPLS Pfadinformationen).

Auf dem Ingress-Router geben Sie die traffic-engineering bgp-igp-both-ribs Erklärung an:

Sie können diese Aussage in den folgenden Hierarchieebenen enthalten:

  • [edit protocols mpls]

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

Wenn Sie die Anweisung bgp-igp-both-ribs verwenden, werden die Routen aus der inet.3-Tabelle in die inet.0-Tabelle kopiert. Die kopierten Routen sind LDP-Signal- oder RSVP-signalisiert und haben wahrscheinlich eine geringere Präferenz als andere Routen in inet.0. Routen mit geringerer Präferenz werden in der Wahrscheinlichkeit eher als aktive Routen gewählt. Dies kann ein Problem darstellen, da Routing-Richtlinien nur auf aktiven Routen agieren. Verwenden Sie stattdessen die Option, um dieses Problem mpls-forwarding zu vermeiden.

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

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

Wenn Sie die Option für die Anweisung konfigurieren, werden LSPs für die Weiterleitung mpls-forwardingtraffic-engineering verwendet, aber nicht in die Routenauswahl ausgeschlossen. Diese Routen werden sowohl den Inet.0- als auch inet.3-Routingtabellen hinzugefügt. LSPs in der Inet.0-Routingtabelle erhalten eine niedrige Präferenz, wenn die aktive Route ausgewählt wird. Die LSPs in der inet.3-Routingtabelle werden jedoch normalerweise bevorzugt und werden daher für die Weiterleitung der nächsten Hops verwendet.

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

Um LSPs für die Weiterleitung zu verwenden, diese aber von der Routenauswahl auszuschließen, geben Sie mpls-forwarding die Option für die Anweisung traffic-engineering ein:

Sie können diese Aussage in den folgenden Hierarchieebenen enthalten:

  • [edit protocols mpls]

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

Wenn Sie die Option mpls-forwarding konfigurieren, IGP Shortcut-Routen nur in die Routing-Tabelle inet.0 kopiert werden.

Im Gegensatz zur Option können Sie die bgp-igp-both-ribs LDP-signalisierten und RSVP-signalisierten Routen für die Weiterleitung verwenden und die BGP- und IGP-Routen für Routingzwecke aktiv halten, sodass die Routing-Richtlinien entsprechend agieren mpls-forwarding können.

Ein Router wird beispielsweise BGP ausgeführt und verfügt über eine BGP-Route mit der 10.10.10.1/32-Route, die er an einen anderen Speaker von BGP senden muss. Wenn Sie die Option verwenden und Ihr Router auch über einen Label bgp-igp-both-ribs Switched Path (LSP) bis 10.10.10.1 verfügt, wird die MPLS-Route für 10.10.10.10.1 inet.0-Routingtabelle aktiv. Dadurch wird verhindert, dass Ihr Router die 10.10.10.1-Route an den anderen Router BGP kann. Wenn Sie dagegen die Option anstatt der Option verwenden, wird die BGP-Route 10.10.10.1/32 an den anderen BGP-Sprecher ausgeschrieben, und der LSP wird weiterhin zur Überführung des Datenverkehrs an das mpls-forwardingbgp-igp-both-ribs 10.10.10.10.1-Ziel verwendet.

Die LSP-Metrik in zusammengefassten LSAs anzeigen

Sie können die MPLS und OSPF LSP als Link konfigurieren. Mit dieser Konfiguration können andere Router im Netzwerk diesen LSP verwenden. Um dieses Ziel zu erreichen, müssen Sie eine Konfiguration MPLS und OSPF Traffic Engineering konfigurieren, um die LSP-Metrik in zusammenfassenden LSAs zu werben.

Geben MPLS an: traffic-engineering bgp-igplabel-switched-path

Sie können diese Anweisungen in den folgenden Hierarchieebenen enthalten:

  • [edit protocols mpls]

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

Geben OSPF an: lsp-metric-into-summary

Sie können diese Aussage in den folgenden Hierarchieebenen enthalten:

  • [edit protocols ospf traffic-engineering shortcuts]

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

Weitere Informationen zur Traffic-OSPF-Engineering finden Sie in der Junos OS Routing Protocols Library für Routinggeräte.

Interarea Traffic Engineering ermöglichen

Der Junos OS kann einen zusammenhängende, trafficorientierten LSP in mehreren OSPF Bereichen signalisieren. Die LSP-Signalübertragung muss entweder mit Nesting oder zusammenhängender Signalübertragung erfolgen, wie in RFC 4206 beschrieben, Label-Switched Paths (LSP) Hierarchy mit Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE). Die zusammenhängende Signalunterstützung ist jedoch auf einfache Signalübertragung beschränkt. Eine Reoptimierung wird mit zusammenhängender Signalübertragung nicht unterstützt.

Im Folgenden werden einige der Inter-Area Traffic Engineering-Funktionen beschrieben:

  • Das Interarea Traffic Engineering kann aktiviert werden, wenn die Loose-Hop Area Border-Router (ABRs) auf dem Ingress-Router mit CSPF für die Explicit Route Object (ERO)-Berechnung innerhalb eines OSPF werden. Die ERO-Erweiterung wird auf den ABRs abgeschlossen.

  • Interarea Traffic Engineering kann aktiviert werden, wenn CSPF aktiviert ist, aber ohne ABRs, die in der LSP-Konfiguration auf dem Ingress-Router angegeben sind (ABRs können automatisch angegeben werden).

  • Das Traffic-Engineering mit differenzierten Services (DiffServ) wird unterstützt, solange die Zuordnungen des Klassentyps für mehrere Bereiche einheitlich sind.

Um inter-ares Traffic-Engineering zu ermöglichen, müssen Sie die Anweisung in die Konfiguration expand-loose-hop jedes LSP-Transit-Routers beinhalten:

Sie können diese Aussage in den folgenden Hierarchieebenen enthalten:

  • [edit protocols mpls]

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

Ermöglichen des inter-AS Traffic Engineering für LSPs

Im Allgemeinen ist Traffic-Engineering für LSPs möglich, die die folgenden Bedingungen erfüllen:

  • Beide Enden des LSP befinden sich im selben Bereich OSPF oder auf der gleichen IS-IS Ebene.

  • Die beiden Enden des LSP befinden sich OSPF Bereichen innerhalb desselben autonomen Systems (AS). LSPs, die in unterschiedlichen Ebenen IS-IS werden nicht unterstützt.

  • Die beiden Enden eines Explicit Path LSP befinden sich in verschiedenen OSPF-ASs, und die autonomen System-Border-Router (ASBRs) sind statisch als die auf dem Explicit-Path-LSP unterstützten Loose Hops konfiguriert. Weitere Informationen finden Sie unter Konfigurieren von Explicit-Path-LSPs.

Ohne statisch definierte ASBRs auf LSPs ist Traffic-Engineering nicht zwischen einer Routingdomäne oder einer AS und einer anderen möglich. Wenn die ASs jedoch von einem einzelnen Service Provider kontrolliert werden, ist es in manchen Fällen möglich, dass traffic-engineered-LSPs die ASs umspannen und die OSPF-ASBRs, die sie verknüpfen, dynamisch entdecken (IS-IS wird von dieser Funktion nicht unterstützt).

Inter-AS Traffic Engineered-LSPs sind möglich, solange bestimmte Netzwerkanforderungen erfüllt werden, keine der begrenzungsbeschränkten Bedingungen gelten und OSPF passiver Modus mit EBGP konfiguriert wird. Details werden in den folgenden Abschnitten angegeben:

Inter-AS Traffic Engineering-Anforderungen

Die ordnungsgemäße Einrichtung und Arbeitsweise von trafficorientierten AS-LSPs hängt von den folgenden Netzwerkanforderungen ab, die alle erfüllt werden müssen:

  • Alle ASs werden von einem einzelnen Service Provider kontrolliert.

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

  • ASBR-Informationen sind in jeder AS.

  • EBGP-Routing-Informationen werden von OSPF verteilt, und innerhalb jeder AS IBGP-Full-Mesh AS.

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

  • Die EBGP-Verbindung zwischen ASBRs in verschiedenen ASs ist eine Direktverbindung und muss als passiver Traffic-Engineering-Link unter "OSPF. Die Remote-Verbindungsadresse selbst und nicht die Loopback- oder eine andere Link-Adresse wird als Remote-Node-Kennung für diesen passiven Link verwendet. Weitere Informationen zur Konfiguration des passiven OSPF Traffic Engineering finden Sie Konfiguration OSPF Passiver TE-Modus unter.

Außerdem muss die für den Remoteknoten des passiven Traffic Engineering-Links (OSPF Traffic Engineering-Link) verwendete Adresse mit der für die EBGP-Verbindung verwendeten Adresse identisch sein. Weitere Informationen über die OSPF und BGP finden Sie in der Junos OS Routing protocols Library für Routinggeräte.

Inter-AS Traffic Engineering-Beschränkungen

Es werden ausschließlich hierarchische oder geschachtelte LSP-Signalübertragungen für datenverkehrsbasierte AS LSPs unterstützt. Es werden nur Punkt-zu-Punkt-LSPs unterstützt (es gibt keine Point-to-Multipoint-Unterstützung).

Außerdem gelten die folgenden Beschränkungen. Selbst wenn die oben genannten Anforderungen erfüllt sind, macht jede dieser Bedingungen AS Netzwerkverkehr unmöglich.

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

  • Policer oder Topologien, die verhindern, BGP innerhalb der Netzwerktopologie bekannt zu sein, AS werden 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, können aber nicht ausgeschrieben werden).

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

  • Bidirektionale LSPs werden nicht unterstützt (LSPs sind aus Sicht des Traffic-Engineering unidirektional).

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

Darüber hinaus werden mehrere Funktionen, die bei allen LSPs routinemäßig sind, von Inter-AS Traffic Engineering nicht unterstützt:

  • Verbindungsfarbe der Admin-Gruppe werden nicht unterstützt.

  • Sekundäre Standby wird nicht unterstützt.

  • Eine Erneute Optimierung wird nicht unterstützt.

  • Crankback bei Transitroutern wird nicht unterstützt.

  • Die unterschiedliche Pfadberechnung wird nicht unterstützt.

  • Graceful-Restart wird nicht unterstützt.

Diese Listen mit Beschränkungen oder nicht mehr unterstützten Funktionen mit datenverkehrsorientierten LSPs AS sind nicht erschöpfend.

Konfiguration OSPF Passiver TE-Modus

Normalerweise werden Protokolle für das interior Routing wie OSPF nicht auf Verbindungen zwischen ASs ausgeführt. Damit das Traffic-Engineering zwischen AS Netzwerk jedoch ordnungsgemäß funktioniert, müssen innerhalb der Netzwerkschnittstelle Informationen über die inter-AS-Verbindung, insbesondere die Adresse an der Remoteschnittstelle, AS. Diese Informationen sind normalerweise weder in EBGP-Erreichbarkeitsmeldungen noch in Routing-OSPF enthalten.

Um diese Verbindungsadresseninformationen innerhalb des AS zu überfluten und für die Berechnung des Traffic Engineering zur Verfügung zu stellen, müssen Sie OSPF passiven Modus für Traffic-Engineering auf jeder interkonfigurierungsbasierten AS konfigurieren. Sie müssen außerdem die Remoteadresse für die OSPF angeben, um sie zu verteilen und in die Traffic-Engineering-Datenbank ein-/ oder anderen Zugriff auf diese Datenbank zu erhalten.

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

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

Paketweiterleitungskomponente

Die Packet Forwarding-Komponente der Junos Traffic Engineering-Architektur ist MPLS, die dafür verantwortlich ist, einen Fluss von IP-Paketen über einen vordefinierten Pfad durch ein Netzwerk zu führen. Dieser Pfad wird als Label Switched Path (LSP) bezeichnet. LSPs sind simplex, d. h. der Datenverkehr fließt vom Head-End-Router (Ingress) in eine Richtung zu einem Tail-End-Router (Egress). Duplexdatenverkehr erfordert zwei LSPs: einen LSP für den Datenverkehr in jede Richtung. Ein LSP wird durch die Verbindung eines oder mehrere Label-Switched-Hops erstellt, sodass ein Paket von einem Router an einen anderen in der MPLS-Domäne weitergeleitet werden kann.

Wenn ein eingehender Router ein IP-Paket empfängt, fügt er dem Paket einen MPLS-Header hinzu und weitergeleitet es an den nächsten Router im LSP. Das gekennzeichnete Paket wird von jedem Router entlang des LSP weitergeleitet, bis es das Ende des LSP, den Egress-Router, erreicht. An diesem Punkt wird MPLS Header entfernt und das Paket wird anhand von Layer 3-Informationen wie der IP-Zieladresse weitergeleitet. Der Wert dieses Schemas ist, dass der physische Pfad des LSP nicht auf das begrenzt ist, was der IGP als kürzester Pfad zur Ziel-IP-Adresse wählen würde.

Paketweiterleitung basierend auf Label-Swapping

Der Paketweiterleitungsprozess an jedem Router basiert auf dem Konzept des Label-Swapping. Dieses Konzept ist ähnlich wie bei jedem Asynchronen Übertragungsmodus-Switch (ATM) in einem permanenten virtuellen Circuit (PVC). Jedes MPLS Paket enthält einen 4-Byte-Einkapselungs-Header, der ein 20-Bit-Labelfeld fester Länge enthält. Wenn ein Paket mit einem Label an einem Router ankommt, untersucht der Router das Label und kopiert es als Index in die MPLS Weiterleitungstabelle. Jeder Eintrag in der Weiterleitungstabelle enthält ein Labelpaar, das zur Schnittstelle eingehender Label einer Gruppe von Weiterleitungsinformationen zugeordnet ist, die auf alle an der jeweiligen Schnittstelle ein und demselben Label eintreffenden Pakete angewendet werden.

So durchläuft ein Paket einen MPLS Backbone

In diesem Abschnitt wird beschrieben, wie ein IP-Paket verarbeitet wird, während es über ein MPLS Backbone-Netzwerk übertragen wird.

Am Eingangsrand des MPLS Backbone wird der IP-Header vom Eingangsrouter untersucht. Basierend auf dieser Analyse wird das Paket klassifiziert, ein Label zugewiesen, in einen MPLS-Header eingekapselt und an den nächsten Hop im LSP weitergeleitet. MPLS bietet eine hohe Flexibilität bei der Zuweisung eines IP-Pakets zu einem LSP. Bei der Implementierung des Junos Traffic Engineering werden beispielsweise alle am Eingehenden-Router eintreffenden Pakete, die zur Ausfahrt der MPLS-Domäne am selben Ausgangsrouter bestimmt sind, über denselben LSP weitergeleitet.

Sobald das Paket den LSP durchlaufen hat, verwendet jeder Router das Label, um die Weiterleitungsentscheidung zu treffen. Die MPLS Weiterleitung erfolgt unabhängig vom ursprünglichen IP-Header: werden die eingehende Schnittstelle und das Label als Suchschlüssel in der MPLS der Weiterleitungstabelle verwendet. Das alte Label wird durch ein neues Label 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 Egress Router erreicht.

Wenn das Paket am Egress Router ankommt, wird das Label entfernt und das Paket aus der MPLS Domain. Die Weiterleitung des Pakets erfolgt dann basierend auf der IP-Zieladresse, die im ursprünglichen IP-Header des Pakets enthalten ist. Dabei handelt es sich um den vom IP-Routing-Protokoll berechneten traditionellen kürzesten Pfad.

Informationsverteilungskomponente

Traffic-Engineering erfordert detaillierte Kenntnisse über die Netzwerktopologie sowie dynamische Informationen über die Netzwerklast. Zur Implementierung der Informationsverteilungskomponente werden einfache Erweiterungen an den IGPs definiert. Linkattribute sind in die Linkstatusanzeige jedes Routers aufgenommen. IS-IS dieser Erweiterungen enthält die Definition neuer TLVs (Type Length Values), während OSPF mit opaquen Link-State-Advertisements (LSAs) implementiert werden. Der von den Link-State IGPs verwendete Standard-Flooding-Algorithmus stellt sicher, dass Link-Attribute an alle Router in der Routingdomäne verteilt werden. Einige der Traffic-Engineering-Erweiterungen, die dem Link IGP hinzugefügt werden sollen, umfassen die maximale Verbindungsbandbreite, die maximal reservierte Linkbandbreite, die Reservierung der aktuellen Bandbreite und das Coloring von Verbindungen.

Jeder Router verwaltet Die Attribute und Topologieinformationen der Netzwerkverbindung in einer speziellen Traffic Engineering-Datenbank. Die Traffic-Engineering-Datenbank wird ausschließlich für die Berechnung expliziter Pfade zur Platzierung von LSPs in der physischen Topologie verwendet. Es wird eine separate Datenbank gepflegt, um die nachfolgende Traffic Engineering-Berechnung unabhängig von der IGP und der IGP-Verbindungsstatusdatenbank des IGP zu erstellen. Währenddessen führt IGP seinen Betrieb ohne Änderungen weiter und führt die herkömmliche Berechnung des kürzesten Pfads basierend auf den Informationen in der Link-Status-Datenbank des Routers durch.

Pfadauswahlkomponente

Nachdem Attribute und Topologieinformationen der Netzwerkverbindung durch den IGP geflutet und in die Traffic-Engineering-Datenbank platziert wurden, nutzt jeder Ingress-Router die Traffic Engineering-Datenbank, um die Pfade für seine eigenen LSPs in der gesamten Routingdomäne zu berechnen. Der Pfad für jeden LSP kann entweder durch eine strikte oder lose explicit Route dargestellt werden. Ein Explicit Route ist eine vorkonfigurierte Folge von Routern, die Teil des physischen Pfads des LSP sein sollten. Wenn der Ingress-Router alle Router im LSP angibt, wird der LSP als strict Explicit Route bezeichnet. Wenn der Ingress-Router nur einige der Router im LSP angibt, wird der LSP als lose explicit Route beschrieben. Die Unterstützung für strikte und lose explicit Routen ermöglicht es, wann immer dies möglich ist, breite Spielraum für die Auswahl des Pfads zu geben, bei Bedarf jedoch einschränkungen zu sein.

Der Ingress-Router ermittelt den physischen Pfad für jeden LSP durch Anwendung eines CSPF-Algorithmus (Constrained Shortest Path First) auf die Informationen in der Traffic Engineering-Datenbank. CSPF ist ein Algorithmus, der für den kürzesten Pfad zuerst entwickelt wurde, um bestimmte Einschränkungen zu berücksichtigen, wenn der kürzeste Pfad im Netzwerk berechnet wird. Die Eingabe in den CSPF-Algorithmus umfasst:

  • Informationen zum Verbindungsstatus der Topologie, die aus dem Netzwerk IGP und in der Traffic Engineering-Datenbank verwaltet werden

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

  • Administrative Attribute, die zur Unterstützung des Datenverkehrs über den vorgeschlagenen LSP erforderlich sind (wie Bandbreitenanforderungen, maximale Hopanzahl und administrative Richtlinienanforderungen), die aus der Benutzerkonfiguration gewonnen werden

Da CSPF jeden Kandidatenknoten und jeden Link für einen neuen LSP in Betracht nimmt, akzeptiert oder lehnt es eine bestimmte Pfadkomponente basierend auf der Ressourcenverfügbarkeit ab oder ob die Auswahl der Komponente gegen Benutzerrichtlinieneinschränkungen verstößt. Bei der Berechnung der CSPF-Berechnung geht es um eine explizite Route, die aus einer Folge von Routeradressen besteht, die den kürzesten Pfad durch das Netzwerk bieten, der die Beschränkungen erfüllt. Diese Explicit Route wird dann an die Signalkomponente übergeben, die den Weiterleitungsstatus in den Routern entlang des LSP stellt.

Signalkomponente

Es ist nicht bekannt, dass ein LSP erst dann funktionieren kann, wenn es durch die Signalkomponente tatsächlich eingerichtet wird. Die Signalkomponente, die für das Einrichten des LSP-Status und die Verteilung von Labels verantwortlich ist, basiert auf einer Reihe von RSVP-Erweiterungen:

  • Mit dem Explicit Route-Objekt kann eine RSVP-Pfadnachricht eine explicit Folge von Routern durchlaufen, die unabhängig vom herkömmlichen IP-Routing mit dem kürzesten Pfad sind. Dabei kann es sich um strikte oder lose Routen gehen.

  • Das Label Request-Objekt ermöglicht der RSVP-Pfadnachricht die Anforderung, dass Zwischenrouter eine Labelbindung für den von ihr erstellten LSP bereitstellen.

  • Mit dem Label-Objekt kann RSVP die Verteilung von Labels unterstützen, ohne die vorhandenen Mechanismen zu ändern. Da die RSVP Resv-Nachricht dem Reverse Path der RSVP-Pfadnachricht folgt, unterstützt das Label-Objekt die Verteilung von Labeln von downstream-Knoten an Upstream-Knoten.

Offline-Pfadplanung und -analyse

Trotz des reduzierten Verwaltungsaufwands, der durch die Online-Pfadberechnung entsteht, ist ein Offline-Planungs- und Analyse-Tool weiterhin erforderlich, um das Traffic Engineering weltweit zu optimieren. Bei der Online-Berechnung werden Ressourcenbeschränkungen berücksichtigt und nach und nach ein LSP berechnet. Die Herausforderung bei diesem Ansatz liegt darin, dass er nicht deterministisch ist. Die Reihenfolge, in der die LSPs berechnet werden, spielt eine entscheidende Rolle bei der Ermittlung des physischen Pfads jedes LSP im Netzwerk. LSPs, die zu einem frühen Zeitpunkt des Prozesses berechnet werden, stehen ihnen mehr Ressourcen zur Verfügung als LSPs, die später im Prozess berechnet werden, da zuvor berechnete LSPs Netzwerkressourcen verbrauchen. Wenn die Reihenfolge, in der die LSPs berechnet werden, geändert wird, kann sich auch die Gruppe der physischen Pfade für die LSPs ändern.

Ein Offline-Planungs- und Analysetool untersucht gleichzeitig die Ressourceneinschränkungen jeder Verbindung und die Anforderungen jedes LSP. Obwohl der Offline-Ansatz mehrere Stunden dauern kann, führt er globale Berechnungen durch, vergleicht die Ergebnisse jeder Berechnung und wählt dann die beste Lösung für das Netzwerk als Ganzes. Bei der Offline-Berechnung geht es um eine Gruppe von LSPs, mit denen die Nutzung der Netzwerkressourcen optimiert wird. Nach Abschluss der Offline-Berechnung können die LSPs in beliebiger Reihenfolge eingerichtet werden, da alle gemäß den Regeln der global optimierten Lösung installiert werden.

Flexible LSP-Berechnung und -Konfiguration

Traffic-Engineering beinhaltet die Zuordnung des Datenverkehrsflusses in einer physischen Topologie. Sie können die Pfade online mithilfe von einschränkungsbasiertem Routing bestimmen. Unabhängig davon, wie der physische Pfad berechnet wird, wird der Weiterleitungsstatus im Netzwerk über RSVP im Netzwerk installiert.

Der Junos OS unterstützt die folgenden Möglichkeiten für das Routen und Konfigurieren eines LSP:

  • Sie können den vollständigen Pfad für den LSP Offline-Service berechnen und jeden Router im LSP individuell mit dem erforderlichen statischen Weiterleitungsstatus konfigurieren. Das ist vergleichbar mit der Konfiguration ihrer IP-over-ATM-Cores durch Internetdienstanbieter.

  • Sie können den vollständigen Pfad für den LSP offline berechnen und den Ingress-Router statisch mit dem vollständigen Pfad konfigurieren. Der Ingress-Router verwendet dann RSVP als dynamisches Signalisierungsprotokoll, um einen Weiterleitungsstatus in jedem Router entlang des LSP zu installieren.

  • Sie können bei der dynamischen Online-LSP-Berechnung auf Einschränkungen basierendes Routing verwenden. Sie konfigurieren die Beschränkungen für jeden LSP, dann bestimmt das Netzwerk selbst den Pfad, der diese Beschränkungen am besten erfüllt. Insbesondere berechnet der Ingress-Router den gesamten LSP anhand der Einschränkungen und initiiert dann die Signalübertragung im gesamten Netzwerk.

  • Sie können einen teilweisen Pfad für einen LSP offline berechnen und den Ingress-Router statisch mit einer Untergruppe der Router im Pfad konfigurieren. können Sie dann die Online-Berechnung zulassen, um den vollständigen Pfad zu bestimmen.

    Stellen Sie sich beispielsweise eine Topologie mit zwei Ost-West-Pfaden in den USA vor: eine im Norden durch Chicago und eine im Süden über Dallas. Wenn Sie einen LSP zwischen einem Router in New York und einem in San Francisco einrichten möchten, können Sie den teilweisen Pfad für den LSP konfigurieren und einen losen Gerouteten Hop eines Routers in Dallas umfassen. Das Ergebnis ist ein auf dem Südpfad entlang des LSP geroutet. Der Ingress-Router nutzt CSPF zur Berechnung des gesamten Pfads und RSVP zur Installation des Weiterleitungsstatus entlang des LSP.

  • Sie können den Ingress-Router ohne jegliche Einschränkungen konfigurieren. In diesem Fall wird IGP mit dem kürzesten Pfad-Routing verwendet, um den Pfad des LSP zu bestimmen. Diese Konfiguration bietet hinsichtlich Traffic-Engineering keinen Mehrwert. Dies ist jedoch einfach und kann in Situationen nützlich sein, in denen Services wie virtuelle private Netzwerke (VPNs) benötigt werden.

In all diesen Fällen können Sie eine beliebige Anzahl von LSPs als Backups für den primären LSP angeben und so mehrere Konfigurationsoptionen kombinieren. Sie könnten beispielsweise den primären Pfad explizit offline rechnern, den sekundären Pfad als constraint-basiert festlegen und den tertiären Pfad nicht mehr beschränkungen. Wenn eine Verbindung, auf der der primäre LSP geroutet ist, ausfällt, bemerkt der Ingress-Router den Ausfall durch Fehlerbenachrichtigungen, die von einem Downstream-Router oder bis zum Ablaufdatum von RSVP-Softstatusinformationen empfangen werden. Dann überleitt der Router den Datenverkehr dynamisch an einen Hot-Standby-LSP oder ruft RSVP auf, um einen Weiterleitungsstatus für einen neuen Backup-LSP zu erstellen.

BGP Classful-Transportebenen im Überblick

Die Vorteile von BGP Classful-Transportebenen

  • Network-Slicing: Die Service- und Transportschichten sind voneinander entkoppelt und legen die Grundlage für Network-Slicing und Virtualisierung mit dem End-to-End-Slicing über mehrere Domänen hinweg und reduzieren so den Investitionsaufwand erheblich.

  • Interoperabilität zwischenDomänen: Erweitert die Bereitstellung der Transportklasse über mehrere Co-Operating-Domains hinweg, sodass die verschiedenen Protokolle für Übertragungssignalisierung in jeder Domain zusammenarbeiten. Abgleich beliebiger Unterschiede zwischen den erweiterten Community-Namespaces, die in jeder Domäne verwendet werden können.
  • Lösung mit Fallback:Ermöglicht die Auflösung über Tunnel (RSVP, IS-IS flexibler Algorithmus) mit flexiblen Fallback-Optionen zu Best-Effort-Tunneln oder einem anderen Farb-Tunnel.

  • 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 einen IS-IS flexiblen Algorithmus, bewahren den ROI und reduzieren die Betriebskosten.

Terminologie der BGP Classful-Transportebenen

In diesem Abschnitt erhalten Sie eine Zusammenfassung häufig verwendeter Begriffe zum Verständnis der BGP-Transportebene.

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

  • Randknoten:Gerät am Verbindungspunkt verschiedener Domänen (IGP oder ASS).

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

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

  • Route Target (RT)– Art der erweiterten Community zur Bestimmung der VPN-Mitgliedschaft.

  • Route Distinguisher (RD)– Identifier zur Unterscheidung verwendet, zu welchem VPN oder Virtual Private LAN Service (VPLS) eine Route gehört. Jede Routinginstanz muss über einen eigenen Routen-Distinguisher verfügen.

  • Lösungsschema– Wird verwendet, um die Protocol Next-Hop-Adresse (PNH) in Auflösung zu lösen RIBs für Fallback.

    Basierend auf der Zuordnungs-Community werden die Routen den verschiedenen Transport-RIBs im System zuordnen.

  • Servicefamilie– BGP adressfamilie, die für die Werbung von Routen für Datenverkehr verwendet wird, im Gegensatz zu Tunnels.

  • Transportfamilie – BGP Adressfamilie, die für Werbe-Tunnel verwendet wird, die wiederum von Servicerouten zur Lösung verwendet werden.

  • Transport tunnel:Ein Tunnel, über den ein Service Datenverkehr platzieren kann, z. B. GRE, UDP, LDP, RSVP, SR-TE, BGP-LU.

  • Tunneldomäne:Eine Domäne des Netzwerks mit Serviceknoten und Randknoten unter einer einzigen administrativen Steuerung, die einen Tunnel dazwischen hat. Ein End-to-End-Tunnel, der mehrere benachbarte Tunneldomänen umspannt, kann erstellt werden, indem die Knoten mithilfe von Labels miteinander verbunden werden.

  • Transportklasse:Eine Gruppe von Transporttunneln, die dasselbe ToS.

  • Transportklasse RT :Ein neues Format von Routenziel zur Identifizierung einer bestimmten Transportklasse.

    Ein neues Format von Route Target zur Identifizierung einer bestimmten Transportklasse.
  • Transport-RIB:Am Serviceknoten und Randknoten verfügt eine Transportklasse über eine übergreifende Transport-RIB für ihre Tunnelrouten.

  • Transport RTI –Eine Routing-Instanz; Container mit Transport-RIB und zugehöriger Transportklasse Routenziel- und Routen-Distinguisher.

  • Transportebene– Gruppe von Transport-RTIs, die dieselbe Transportklasse importieren RT. Diese werden wiederum so miteinander verbunden, dass sie über Tunneldomänengrenzen hinweg miteinander verbunden sind. Dabei wird ein Mechanismus verwendet, der inter-AS option-b ähnelt, um Label an Randknoten (Nexthop-Self) zu ersetzen und eine End-to-End-Transportebene zu bilden.

  • Mapping community–Community auf einer Serviceroute, die Zuordnungen zur Lösung über eine Transportklasse auf.

Kenntnis BGP Classful-Transportebenen

Sie können BGP Classful-Transportschichten verwenden, um Transportklassen zur Klassifizierung einer Gruppe von Transporttunneln in einem Intra-AS-Netzwerk basierend auf den Traffic-Engineering-Eigenschaften zu konfigurieren, und diese Transport-Tunnels verwenden, um Servicerouten dem gewünschten SLA und dem angestrebten Fallback zu zuordnen.

BGP Classful-Transportebenen können diese Tunnel auf Netzwerke zwischen Domänen ausdehnen, die mehrere Domänen (ASs oder IGP Bereiche) umfassen, während gleichzeitig die Transportklasse erhalten wird. Dazu müssen Sie die BGP classful Trasport Transport Layer BGP-Familie zwischen den Rand- und Serviceknoten konfigurieren.

Sowohl in Inter-AS- als auch Intra-AS-Implementierungen können von den Service- und Border-Nodes zahlreiche Transporttunnel (MPLS-LSPs, IS-IS flexibler Algorithmus, SR-TE) erstellt werden. Die LSPs können über unterschiedliche Signalisierungsprotokolle in verschiedenen Domänen signalisiert und mit unterschiedlichen Eigenschaften des Traffic Engineering (Klasse oder Farbe) konfiguriert werden. Der Endpunkt des Transporttunnels fungiert auch als Endpunkt für den Service und kann in der gleichen Tunneldomäne wie der Service-Ingress-Knoten oder in einer benachbarten oder nicht benachbarten Domain vorhanden sein. Sie können mit BGP-Classful-Transportebenen Services über LSPs mit gewissen Traffic-Engineering-Charateristiken innerhalb einer einzelnen Domain oder über mehrere Domänen hinweg vorziehen.

BGP Classful-Transportebenen wiederverwendung der BGP-VPN-Technologie, so dass die Tunneling-Domänen lose gekoppelt und koordiniert bleiben.

  • Die Network Layer Reachability Information (NLRI) ist RD:TunnelEndpoint zum Path Hiding.
  • Das Routenziel gibt die Transportklasse der LSPs an und übergibt Routen an die entsprechende Transport-RIB auf dem Zielgerät.
  • Jedes Transport Tunneling-Protokoll installiert eine Ingress-Route zur transport-class.inet.3-Routingtabelle, modelliert die Tunnel-Transportklasse als VPN-Routenziel und sammelt die LSPs der gleichen Transportklasse in der transport-class.inet.3 Transport-Rib Routing-Tabelle.
  • Routen in dieser Routinginstanz werden auf der classful BGP Transportebene (Inet-Transport) AFI-SAFI angekündigt, die den Verfahren RFC-4364 ähnelt.

  • Beim Überschreiten der AS der Verbindungsgrenzen müssen Sie die Option-b-Verfahren befolgen, um die Transporttunnel in diesen benachbarten Domänen zu stitchen.

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

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

  • Sie können Servicerouten und BGP für classful Transportrouten über diese Transportklassen lösen, indem Sie die Zuordnungs-Community darauf carrryieren.

Die BGP classful Transportfamilie wird entlang der Transportschichtfamilie BGP LU ausgeführt. In einem MPLS Netzwerk mit BGP-LU stellt die Erfüllung strikter SLA-Anforderungen von 5G eine Herausforderung dar, da die Traffic-Engineering-Eigenschaften der Tunnel nicht über die Grenzen von Domänen bekannt oder beibehalten werden. BGP Classful-Transportebenen bieten einfach zu bedienende und skalierbare Mittel, um mehrere Pfade für Remote-Loopbacks in Verbindung mit transportklasseninformationen in der nahtlosen Cloud-Architektur MPLS werben. In BGP erstklassigen Tranport-Familienrouten werden verschiedene SLA-Pfade mithilfe der erweiterten Transportrouten-Ziel-Community dargestellt, die die Transportklasse -Farbe trägt. Dieses Transportroutenziel wird von den empfangenden Routern BGP verwendet, um die BGP-Transportroute der entsprechenden Transportklasse zu zuordnen. Wenn die BGP Classful-Transportroute erneut rebebt werden, tauscht MPLS Routen aus, verbindet die Intra-AS-Tunnel der gleichen Transportklasse und bildet so einen End-to-End-Tunnel, der die Transportklasse erhält.

Intra-AS Implementierung von BGP Classful-Transportebenen

Abbildung 4 zeigt eine Netzwerktopologie mit Before-and-After-Szenarien der Implementierung von BGP-Transportebenen in einer AS Domain. Geräte PE11 und PE12 verwenden RSVP LSPs als Transporttunnel, und alle Transport-Tunnel-Routen werden inet.3 RIB installiert. Durch die BGP Classful-Transort-Ebenen können RSVP-Transporttunnel farbsensensiert sein wie Segment-Routing-Tunnel.

Abbildung 4: Intra-AS-Domain: Before-and-After-Szenarien für die BGP Classful-Transportebenenimplementierung Intra-AS-Domain: Before-and-After-Szenarien für die BGP Classful-Transportebenenimplementierung Intra-AS-Domain: Before-and-After-Szenarien für die BGP Classful-Transportebenenimplementierung

Zur Klassifizierung von Transport-Tunneln BGP Transportklasse in einer AS Konfiguration:

  1. Definieren Sie die Transportklasse am Serviceknoten (ingress-PE-Geräte), zum Beispiel Gold und Bronze, und weisen Sie der definierten Transportklasse Farb-Community-Werte zu.

    Beispielkonfiguration:

  2. Verbinden Sie den Transporttunnel mit einer bestimmten Transportklasse am Ingress-Knoten der Tunnel.

    Beispielkonfiguration:

Funktionen AS BGP Classful Transport Plane (BSG):

  • BGP Classful-Transport erstellt vordefinierte Transport-RIBs pro named Transport Class (Gold und Bronze) und leitet automatisch eine Zuordnungs-Community von ihrem Farbwert (100 und 200) ab.
  • Die AS der Transportrouten werden von einem Tunneling-Protokoll in Transport-RIBs gefüllt, wenn es einer Transportklasse zugeordnet ist.

    In diesem Beispiel werden RSVP LSP-Routen, die mit Transportklasse Gold (Color 100) und Transport Class Bronze (Color 200) verknüpft sind, in den Transport-RIBs junos-rti-tc-<100>.inet.3 bzw. junos-rti-tc-<200>.inet.3installiert.

  • Service Node (ingress PEs) stimmen die erweiterte Farbgemeinschaft (color:0:100 und color:0:200) der Serviceroute mit der Zuordnungs-Community in vordefinierten RIBs ab, und lösen Sie das Protocol Next Hop (PNH) in entsprechenden Transport-RIBs (entweder junos-rti-tc-<100>.inet.3, oder junos-rti-tc-<200>.inet.3).
  • BGP-Routen binden sich an ein Auflösungsschema, indem sie die assiocaited Mapping-Community tragen.
  • Jede Transportklasse erstellt automatisch zwei vordefinierte Auflösungsschemata und leitet automatisch die Zuordnungs-Community ab.

    Ein Lösungsschema ist das Lösen von Servicerouten, die Color:0:<val> als Zuordnungs-Community verwenden.

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

  • Wenn der PNH der Serviceroute mithilfe der im vordefinierten Auflösungsschema aufgeführten ROUTING-Regeln nicht gelöst werden kann, kann er auf die Inet.3-Routingtabelle zurückfallen.
  • Sie können auch Fallback zwischen verschiedenen Transport-RIBs konfigurieren, indem Sie benutzerdefinierte Auflösungsschemata in der [edit routing-options resolution scheme] Konfigurationshierarchie verwenden.

Inter-AS Implementierung von BGP Classful-Transportebenen

In einem Netzwerk AS Netzwerk wird BGP-LU in ein transportorientiertes BGP-Netzwerk umgewandelt, nachdem mindestens zwei Transportklassen (Gold und Bronze) auf allen Serviceknoten bzw. PE-Geräten und Border Nodes (ABRs und ASBRs) konfiguriert wurden.

So konvertieren Sie die Transport-Tunnel in BGP Classful-Transport:

  1. Definieren Sie die Transportklasse an den Serviceknoten (Ingress-PE-Geräten) und den Randknoten (ABRs und ASBRs), zum Beispiel Gold und Broze.

    Beispielkonfiguration:

  2. Verbinden Sie die Transport-Tunnel mit einer bestimmten Transportklasse am Ingress-Knoten der Tunnel (ingress-PEs, ABRs und ASBRs).

    Beispielkonfiguration:

    Für RSVP-LSPs

    Für IS-IS Flxible-Algorithmus

  3. Ermöglichen der neuen Produktfamilie BGP classful Transport (Inet-Transport) und BGP-LU (Inet-Label-Unicast) im Netzwerk.

    Beispielkonfiguration:

  4. Bieten Sie Servicerouten vom Egress PE-Gerät mit entsprechend erweiterter Farb-Community an.

    Beispielkonfiguration:

Funktionen AS BGP Classful-Transportebene:

  1. BGP classful-Transportebenen erstellen vordefinierte Transport-RIBs pro Transportklasse (Gold und Bronze) und leiten automatisch die Zuordnungs-Community von ihrem Farbwert ab.
  2. Die AS Übertragungsrouten werden in Transport-RIBs durch Tunneling-Protokolle gefüllt, wenn diese mit einer Transportklasse verknüpft sind.

    Beispielsweise werden transport tunnelrouten, die mit der Transportklasse Gold und Bronze verknüpft sind, in den Transport-RIBs junos-rti-tc-<100>.inet.3 bzw.junos-rti-tc-<200>.inet.3installiert.

  3. BGP Classful-Transportebenen verwenden einen eindeutigen Route Distinguisher und Route Target, wenn die Transport-Tunnel-Routen von jeder Transport-RIB in die bgp.transport.3-Routingtabelle kopiert werden.
  4. Border Nodes geben Routen von bgp.transport.3-Routingtabelle zu Peers in anderen Domänen an, wenn der Transport über die Familie inet während der Sitzung BGP wird.
  5. Der empfangende Randknoten installiert diese bgp-ct-Routen in der bgp.transport.3-Routingtabelle und kopiert diese Routen basierend auf dem Transportroutenziel in die entsprechenden Transport-RIBs.
  6. Service Node treffert die Farbgemeinschaft in der Serviceroute gegen eine Zuordnungs-Community in den Auflösungsschemata und löst PNH in der entsprechenden Transport-RIB (entweder junos-rti-tc-<100>.inet.3oder junos-rti-tc-<200>.inet.3).
  7. Randknoten verwenden vordefinierte Auflösungsschemata für die PNH-Auflösung von Transportrouten.
  8. Beide Auflösungsschemata unterstützen vordefinierte oder benutzerdefinierte Auflösungsschemata die PNH-Auflösung von Servicerouten. Durch die vordefinierten Verwendungen inet.3 als Fallback und benutzerdefiniertes Auflösungsschema kann eine Liste von Transport-RIBs in der angegebenen Reihenfolge verwendet werden, während sie PNH auflösen.
  9. Wenn der PNH für Dienstrouten mithilfe der im benutzerdefinierten Auflösungsschema aufgeführten RIBs nicht gelöst werden kann, wird die Route verworfen.

Verbessern der Traffic Engineering-Datenbankgenauigkeit mit RSVP PathErr-Nachrichten

Ein wichtiges Element des RSVP-basierten Traffic Engineering ist die Traffic Engineering-Datenbank. Die Traffic-Engineering-Datenbank enthält eine vollständige Liste aller Netzwerkknoten und Links, die im Traffic-Engineering beteiligt sind, und eine Gruppe von Attributen, die jede dieser Verbindungen enthalten kann. (Weitere Informationen zur Traffic-Engineering-Datenbank finden Sie unter Constrained-Path LSP Computation.) Eines der wichtigsten Verbindungsattribute ist Bandbreite.

Die Bandbreitenverfügbarkeit von Verbindungen ändert sich schnell, wenn RSVP-LSPs eingerichtet und beendet werden. Es ist wahrscheinlich, dass sich die Traffic-Engineering-Datenbank inKonsistenzen im Vergleich zum tatsächlichen Netzwerk entwickelt. Diese Inkonsistenzen lassen sich nicht durch eine erhöhung des Updates IGP in IGP.

Die Verbindungsverfügbarkeit kann dasselbe Inkonsistenzproblem haben. Eine Verbindung, die ausfällt, kann alle vorhandenen RSVP-LSPs lappen. Die Nichtverfügbarkeit ist dem Netzwerk möglicherweise nicht ohne weiteres bekannt.

Wenn Sie die Anweisung konfigurieren, lernt ein Quellknoten (Ingress von einem RSVP LSP) von den Ausfällen seines LSP durch die Überwachung von PathErr-Nachrichten, die von Downstream-Knoten rsvp-error-hold-time übermittelt werden. Informationen aus den PathErr-Nachrichten werden in nachfolgende LSP-Berechnungen einbezogen, wodurch die Genauigkeit und Geschwindigkeit der LSP-Einrichtung verbessert wird. Einige PathErr-Nachrichten werden auch verwendet, um die Bandbreiteninformationen der Traffic Engineering-Datenbank zu aktualisieren, was die Inkonsistenz zwischen der Traffic Engineering-Datenbank und dem Netzwerk reduziert.

Sie können die Häufigkeit der IGP mithilfe der Anweisung update-threshold steuern. Siehe Konfigurieren des RSVP-Update-Grenzwerts auf einer Schnittstelle.

In diesem Abschnitt werden die folgenden Themen erörtert:

PathErr-Nachrichten

PathErr-Nachrichten melden eine Vielzahl von Problemen mit unterschiedlichen Code- und Untercodenummern. Eine vollständige Liste dieser PathErr-Nachrichten finden Sie in RFC 2205, Resource Reservation Protocol (RSVP), Version 1, Funktionale Spezifikation und RFC 3209, RSVP-TE: RSVP-Erweiterungen für LSP-Tunnel.

Beim Konfigurieren der Anweisung werden zwei Kategorien von PathErr-Nachrichten untersucht, die insbesondere rsvp-error-hold-time Verbindungsfehler darstellen:

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

    Diese PathErr-Nachricht stellt ein globales Problem dar, das alle LSPs betrifft, die diesen Link transitieren. Sie zeigen, dass die tatsächliche Bandbreite der Verbindungen geringer ist als die vom LSP geforderte, und dass es wahrscheinlich ist, dass die Bandbreiteninformationen in der Traffic Engineering-Datenbank eine Überschätzung sind.

    Wenn diese Fehlerart empfangen wird, wird die verfügbare Link-Bandbreite in der lokalen Traffic Engineering-Datenbank reduziert, die alle zukünftigen LSP-Berechnungen beeinflusst.

  • Verbindung für diesen LSP nicht verfügbar:

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

    • Fehler bei der Richtlinienkontrolle – Code 2

    • Vorinstallierte Dienste – Code 12

    • Routingproblem – kein Route zum Ziel verfügbar – Code 24, Untercode 5

    Diese Typen von PathErr-Nachrichten sind im Allgemeinen relevant für den angegebenen LSP. Ein Ausfall dieses LSP bedeutet nicht unbedingt, dass auch andere LSPs ausfallen könnten. Diese Fehler können angeben, dass probleme mit der maximalen Übertragungseinheit (MTU), Dienstpriorität (entweder manuell vom Betreiber initiiert oder von einem anderen LSP mit einer höheren Priorität), eine Verbindung mit dem nächsten Hop, ein Nachbar im nächsten Hop ausfallen oder aufgrund von Richtlinienerwägungen einen Service nicht mehr durchführen kann. Am besten routet man diesen bestimmten LSP weg vom Link.

Identifizierung der Problemverbindung

Jede PathErr-Nachricht enthält die IP-Adresse des Absenders. Diese Informationen werden nicht an den Ingress-Router verbreitet. Eine Suche in der Traffic-Engineering-Datenbank kann den Knoten identifizieren, von dem die PathErr-Nachricht stammte.

Jede PathErr-Nachricht enthält ausreichende Informationen, um die rsVP-Sitzung zu identifizieren, die die Nachricht ausgelöst hat. Wenn es sich dabei um einen Transit-Router handelt, wird die Nachricht einfach weitergeleitet. Wenn dieser Router der Ingress-Router ist (für diese RSVP-Sitzung), hat er die vollständige Liste aller Knoten und Verbindungen, die die Sitzung durchlaufen sollte. In Verbindung mit den Ursprungsknoteninformationen kann die Verbindung eindeutig identifiziert werden.

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

Konfigurieren Sie die Anweisung, um die Genauigkeit der Traffic Engineering-Datenbank zu rsvp-error-hold-time verbessern. Wenn diese Anweisung konfiguriert ist, lernt ein Quellknoten (Ingress von einem RSVP LSP) von den Ausfällen seines LSP durch die Überwachung von PathErr-Nachrichten, die von Downstream-Knoten übermittelt werden. Informationen aus den PathErr-Nachrichten werden in nachfolgende LSP-Berechnungen einbezogen, wodurch die Genauigkeit und Geschwindigkeit der LSP-Einrichtung verbessert wird. Einige PathErr-Nachrichten werden auch verwendet, um die Bandbreiteninformationen der Traffic Engineering-Datenbank zu aktualisieren, was die Inkonsistenz zwischen der Traffic Engineering-Datenbank und dem Netzwerk reduziert.

Um zu konfigurieren, MPLS wie lange die RSVP PathErr-Nachrichten gesendet und in die CSPF-Berechnung überdlegt werden sollten, fügen Sie die Aussage rsvp-error-hold-time hinzu:

Sie können diese Aussage in den folgenden Hierarchieebenen enthalten:

  • [edit protocols mpls]

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

Die Zeit kann einen Wert von 1 bis 240 Sekunden haben. Sie beträgt standardmäßig 25 Sekunden. Konfigurieren eines Wertes von 0 deaktiviert die Überwachung von PathErr-Nachrichten.

Release-Verlaufstabelle
Release
Beschreibung
20.4R1
Beginnend Junos OS Veröffentlichungs-20.4R1 können Sie IS-IS Traffic Engineering so konfigurieren, dass neben IPv4-Adressen IPv6-Informationen in der Traffic Engineering Database (TED) gespeichert werden.
17.4R1
Beginnend mit Junos OS Release 17.4R1 installiert die Traffic Engineering-Datenbank Informationen zur Interior Gateway Protocol (IGP)-Topologie sowie RSVP-TE-Topologieinformationen in der lsdist.0-Routingtabelle.
17.2R1
Beginnend ab Junos OS Release 17.2R1 wird die Verbindungsstatus-Adressfamilie von BGP erweitert, um das Source Packet Routing in Networking (SPRING)-Topologieinformationen an Software-Defined Networking-Controller (das SDN) zu verteilen.
17.1R1
Beginnend mit Junos OS Release 17.1R1 wird die Verteilung des Verbindungsstatus mithilfe von BGP auf QFX10000 unterstützt.