Link-State-Verteilung mit BGP
Link-State-Verteilung mit BGP – Übersicht
- Die Rolle eines Interior Gateway Protocol
- Einschränkungen eines Interior Gateway Protocol
- Bedarf an übergreifender Link-State-Verteilung
- BGP als Lösung nutzen
- Unterstützte und nicht unterstützte Funktionen
- BGP-Link-State-Erweiterungen für das Quellpaket-Routing in Netzwerken (SPRING)
- Verifizieren des durch BGP erlernten NLRI-Knotens mit OSPF als IGP
- Verifizieren des Präfixes NLRI, das durch BGP mit OSPF als IGP gelernt wurde
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
Um die Anforderungen an eine übergreifende Link-State-Verteilung über mehrere Domänen hinweg zu erfüllen, ist ein Exterior Gateway Protocol (EGP) erforderlich, um Link-State- und Traffic-Engineering-Informationen aus einem IGP-Bereich zu sammeln, sie für externe Komponenten freizugeben und sie für die Berechnung von Pfaden für domänenübergreifende MPLS-LSPs zu verwenden.
BGP ist ein standardisiertes EGP, das für den Austausch von Routing- und Erreichbarkeitsinformationen zwischen autonomen Systemen (ASs) entwickelt wurde. BGP ist ein bewährtes Protokoll mit besseren Skalierungseigenschaften, da es Millionen von Einträgen (z. B. VPN-Präfixe) auf skalierbare Weise verteilen kann. BGP ist das einzige Routing-Protokoll, das heute verwendet wird und für die Übertragung aller Routen im Internet geeignet ist. Dies liegt vor allem daran, dass BGP auf TCP aufsetzt und die TCP-Flusssteuerung nutzen kann. Im Gegensatz dazu verfügen die internen Gateway-Protokolle (IGPs) nicht über eine Flusskontrolle. Wenn IGPs zu viele Routeninformationen haben, beginnen sie abzuwandern. Wenn BGP über einen benachbarten Sprecher verfügt, der Informationen zu schnell sendet, kann BGP den Nachbarn drosseln, indem TCP-Bestätigungen verzögert werden.
Ein weiterer Vorteil von BGP besteht darin, dass es TLV-Tupel (Typ, Länge, Wert) und NLRI (Network Layer Reachability Information) verwendet, die eine scheinbar endlose Erweiterbarkeit bieten, ohne dass das zugrunde liegende Protokoll geändert werden muss.
Die domänenübergreifende Verteilung von Link-State-Informationen wird mithilfe von Richtlinien geregelt, die die Interessen des Dienstanbieters schützen. Dies erfordert eine Steuerung der Topologieverteilung mithilfe von Richtlinien. BGP mit seinem implementierten Richtlinien-Framework eignet sich gut für die domänenübergreifende Routenverteilung. In Junos OS ist BGP vollständig richtliniengesteuert. Der Betreiber muss Nachbarn explizit für das Peering konfigurieren und Routen in BGP explizit akzeptieren. Darüber hinaus wird die Routing-Richtlinie verwendet, um Routing-Informationen zu filtern und zu ändern. Routing-Richtlinien bieten somit eine vollständige administrative Kontrolle über die Routing-Tabellen.
Obwohl innerhalb eines AS sowohl IGP-TE als auch BGP-TE den gleichen Satz von Informationen bereitstellen, verfügt BGP-TE über bessere Skalierungseigenschaften, die vom Standard-BGP-Protokoll übernommen werden. Dies macht BGP-TE zu einer besser skalierbaren Wahl für die Erfassung von Multi-Area-/Multi-AS-Topologieinformationen.
Durch die Verwendung von BGP als Lösung werden die von der IGP erfassten Informationen für die Verteilung in BGP verwendet. Die ISPs können diese Informationen selektiv über normales BGP-Peering mit anderen ISPs, Service Providern und Content Distribution Networks (CDNs) offenlegen. Dies ermöglicht die Aggregation der IGP-erfassten Informationen über mehrere Bereiche und ASs hinweg, so dass eine externe Pfadberechnungseinheit auf die Informationen zugreifen kann, indem sie passiv auf einen Routenreflektor lauscht.
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.
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
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
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
Source Packet Routing in Networking (SPRING)
SPRING ist eine Control-Plane-Architektur, die es einem Eingangsrouter ermöglicht, ein Paket durch eine bestimmte Gruppe von Knoten und Verbindungen im Netzwerk zu steuern, ohne sich darauf zu verlassen, dass die Zwischenknoten im Netzwerk entscheiden, welchen Weg es tatsächlich nehmen muss. SPRING setzt IGPs wie IS-IS und OSPF für Werbenetzwerksegmente ein. Netzwerksegmente können jede beliebige Anweisung darstellen, topologisch oder dienstbasiert. Innerhalb von IGP-Topologien werden IGP-Segmente von den Link-State-Routing-Protokollen angekündigt. Es gibt zwei Arten von IGP-Segmenten:
| Adjacency segment |
Ein One-Hop-Pfad über eine bestimmte Nachbarschaft zwischen zwei Knoten in der IGP |
| Prefix segment |
Ein Multi-Hop, gleiche Kosten, Multipath-bewusster kürzester Pfad zu einem Präfix, entsprechend dem Status der IGP-Topologie |
Wenn SPRING in einem BGP-Netzwerk aktiviert ist, lernt die BGP-Link-State-Adressfamilie die SPRING-Informationen aus den IGP-Link-State-Routing-Protokollen und kündigt Segmente in Form von Segmentbezeichnern (SIDs) an. Die BGP-Link-State-Adressfamilie wurde erweitert, um SIDs und andere SPRING-bezogene Informationen an BGP-Peers zu übertragen. Der Routenreflektor kann ein Paket durch eine gewünschte Gruppe von Knoten und Verbindungen steuern, indem dem Paket eine geeignete Kombination von Tunneln vorangestellt wird. Mit dieser Funktion kann die BGP-Link-State-Adressfamilie die SPRING-Informationen auch an BGP-Peers weitergeben.
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.
-
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.0Diese Richtlinie kündigt einen Eintrag an, der aus der Traffic-Engineering-Datenbank gelernt wurde.
Unterstützte BGP-Link-State-Attribute und TLVs sowie nicht unterstützte Funktionen für BGP-Link-State mit SPRING
Der BGP-Verbindungsstatus mit SPRING unterstützt die folgenden Attribute sowie Typ-, Längen- und Wertewerte (TLVs), die im Netzwerk entstehen, empfangen und weitergegeben werden:
Node attributes
-
Segment-Routing-Funktionen
-
Segment-Routing-Algorithmus
Link attributes
-
Benachbarte SID
-
LAN Adjacent-SID
Prefix descriptors
-
Informationen zur IP-Erreichbarkeit
Prefix attributes
-
Präfix-SID
Die folgende Liste unterstützt TLVs, die nicht stammen, sondern nur empfangen und im Netzwerk weitergegeben werden:
Prefix descriptors
-
Multitopologie-ID
-
OSPF-Routentyp
Prefix attributes
-
Bereich
-
Bindungs-SID
Junos OS unterstützt die folgenden Funktionen mit BGP-Verbindungsstatus mit SPRING-Erweiterungen nicht:
-
IPv6-Präfix-Ursprung
-
Multitopologie-Bezeichner
-
Export der Traffic-Engineering-Datenbank für SPRING-Parameter
-
Neue TLVs mit tcpdump (vorhandene TLVs werden ebenfalls nicht unterstützt).
-
SPRING über IPv6
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:
Zweck
Überprüfen Sie die Einträge in der Routing-Tabelle lsdist.0.
Was
Führen Sie den Befehl im Betriebsmodus aus.show route table lsdist.0
user@host> show route table lsdist.0 te-node-ip 10.7.7.7 extensive
lsdist.0: 216 destinations, 216 routes (216 active, 0 holddown, 0 hidden)
NODE { AS:65100 Area:0.0.0.1 IPv4:10.7.7.7 OSPF:0 }/1536 (1 entry, 1 announced)
TSI:
LINK-STATE attribute handle 0x61d5da0
*BGP Preference: 170/-101
Next hop type: Indirect, Next hop index: 0
Address: 0x61b07cc
Next-hop reference count: 216
Source: 10.2.2.2
Protocol next hop: 10.2.2.2
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
State:<Active Int Ext>
Local AS: 65100 Peer AS: 65100
Age: 30:22 Metric2: 2
Validation State: unverified
Task: BGP_65100.10.2.2.2
Announcement bits (1): 0-TED Export
AS path: I
Accepted
Area border router: No
External router: No
Attached: No
Overload: No
SPRING-Capabilities:
- SRGB block [Start: 900000, Range: 90000, Flags: 0x00]
SPRING-Algorithms:
- Algo: 0
Localpref: 100
Router ID: 10.2.2.2
Indirect next hops: 1
Protocol next hop: 10.2.2.2 Metric: 2
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 10.11.1.2 via et-0/0/0.1 weight 0x1
Session Id: 0x143
10.2.2.2/32 Originating RIB: inet.0
Metric: 2 Node path count: 1
Forwarding nexthops: 1
Nexthop: 10.11.1.2 via et-0/0/0.1
Session Id: 143Bedeutung
Die Routen werden in der Routing-Tabelle lsdist.0 angezeigt.
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:
Zweck
Überprüfen Sie die Einträge in der Routing-Tabelle lsdist.0.
Was
Führen Sie den Befehl im Betriebsmodus aus.show route table lsdist.0
user@host> show route table lsdist.0 te-ipv4-prefix-node-ip 10.7.7.7 extensive
lsdist.0: 216 destinations, 216 routes (216 active, 0 holddown, 0 hidden)
PREFIX { Node { AS:65100 Area:0.0.0.1 IPv4:10.7.7.7 } { IPv4:10.7.7.7/32 } OSPF:0 }/1536 (1 entry, 0 announced)
*BGP Preference: 170/-101
Next hop type: Indirect, Next hop index: 0
Address: 0x61b07cc
Next-hop reference count: 216
Source: 10.2.2.2
Protocol next hop: 10.2.2.2
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
State: <Active Int Ext>
Local AS: 65100 Peer AS: 65100
Age: 30:51 Metric2: 2
Validation State: unverified
Task: BGP_65100.10.2.2.2
AS path: I
Accepted
Prefix Flags: 0x00, Prefix SID: 1007, Flags: 0x50, Algo: 0
Localpref: 65100
Router ID: 10.2.2.2
Indirect next hops: 1
Protocol next hop: 10.2.2.2 Metric: 2
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 10.11.1.2 via et-0/0/0.1 weight 0x1
Session Id: 0x143
10.2.2.2/32 Originating RIB: inet.0
Metric: 2 Node path count: 1
Forwarding nexthops: 1
Nexthop: 10.11.1.2 via et-0/0/0.1
Session Id: 143Bedeutung
Die Routen werden in der Routing-Tabelle lsdist.0 angezeigt.
Beispiel: Konfigurieren der Verbindungsstatusverteilung mithilfe von BGP
In diesem Beispiel wird gezeigt, wie BGP so konfiguriert wird, dass Verbindungsstatusinformationen über mehrere Domänen hinweg übertragen werden, die zum Berechnen von Pfaden für MPLS-LSPs verwendet werden, die sich über mehrere Domänen erstrecken, wie z. B. Inter-Area TE LSP, und um eine skalierbare und richtliniengesteuerte Möglichkeit für externe Pfadberechnungseinheiten wie ALTO und PCE zum Abrufen der Netzwerktopologie bereitzustellen.
Anforderungen
In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:
-
Vier Router, bei denen es sich um eine Kombination aus Routern der M-Serie, MX-Serie oder T-Serie handeln kann
-
Junos OS Version 14.2 oder höher, das auf allen Routern ausgeführt wird
Bevor Sie beginnen:
-
Konfigurieren Sie die Geräteschnittstellen.
-
Konfigurieren Sie die autonomen Systemnummern und Router-IDs für die Geräte.
-
Konfigurieren Sie die folgenden Protokolle:
-
RSVP
-
MPLS
-
BGP
-
IS-IS
-
OSPF
-
Überblick
Ab Junos OS Version 14.2 wird ein neuer Mechanismus zur Verteilung von Topologieinformationen über mehrere Bereiche und autonome Systeme (ASs) eingeführt, indem das BGP-Protokoll erweitert wird, um Link-State-Informationen zu übertragen, die ursprünglich mit IGP erfasst wurden. Die IGP-Protokolle haben Skalierungsbeschränkungen, wenn es um die Verteilung großer Datenbanken geht. BGP ist nicht nur ein skalierbareres Vehikel für die Übertragung von Multi-Area- und Multi-AS-Topologieinformationen, sondern bietet auch die Richtlinienkontrollen, die für die Verteilung von Multi-AS-Topologien nützlich sein können. Die BGP-Link-State-Topologieinformationen werden zum Berechnen von Pfaden für MPLS-LSPs (Label-Switched Paths) verwendet, die sich über mehrere Domänen erstrecken, z. B. gebietsübergreifende TE-LSP, und bieten eine skalierbare und richtliniengesteuerte Möglichkeit für externe Pfadberechnungseinheiten wie ALTO und PCE, die Netzwerktopologie zu erfassen.
Ab Junos OS Version 17.1R1 wird die Link-State-Verteilung mithilfe von BGP auf QFX10000 Switches unterstützt.
Topologie
In Abbildung 3gehören die Router R0 und R1 und die Router R2 und R3 zu unterschiedlichen autonomen Systemen. Auf den Routern R0 und R1 wird OSPF ausgeführt, auf den Routern R2 und R3 IS-IS.
Konfiguration
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für Ihre Netzwerkkonfiguration erforderlich sind, kopieren Sie die Befehle und fügen Sie sie in die CLI auf Hierarchieebene ein, und geben Sie sie dann aus dem Konfigurationsmodus ein .[edit]commit
R0
set interfaces ge-0/0/0 unit 0 family inet address 10.8.31.101/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.105.137/32 set routing-options router-id 10.255.105.137 set routing-options autonomous-system 65533 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering database export policy accept-all set protocols mpls cross-credibility-cspf set protocols mpls label-switched-path to-R3-inter-as to 10.255.105.135 set protocols mpls label-switched-path to-R3-inter-as bandwidth 40m set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.255.105.137 set protocols bgp group ibgp family traffic-engineering unicast set protocols bgp group ibgp neighbor 10.255.105.141 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set policy-options policy-statement accept-all from family traffic-engineering set policy-options policy-statement accept-all then accept
R1
set interfaces ge-0/0/0 unit 0 family inet address 10.8.31.103/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.8.42.102/24 set interfaces ge-0/0/1 unit 0 family iso set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.105.141/32 set interfaces lo0 unit 0 family iso address 47.0005.0102.5501.8181 set routing-options router-id 10.255.105.141 set routing-options autonomous-system 65533 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.255.105.141 set protocols bgp group ibgp family traffic-engineering unicast set protocols bgp group ibgp export nlri2bgp set protocols bgp group ibgp neighbor 10.255.105.137 set protocols bgp group ebgp type external set protocols bgp group ebgp family traffic-engineering unicast set protocols bgp group ebgp neighbor 10.8.42.104 local-address 10.8.42.102 set protocols bgp group ebgp neighbor 10.8.42.104 peer-as 65534 set protocols isis interface ge-0/0/1.0 passive remote-node-iso 0102.5502.4211 set protocols isis interface ge-0/0/1.0 passive remote-node-id 10.8.42.104 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 10.8.42.104 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 10.255.105.139 set policy-options policy-statement accept-all from family traffic-engineering set policy-options policy-statement accept-all then accept set policy-options policy-statement nlri2bgp term 1 from family traffic-engineering set policy-options policy-statement nlri2bgp term 1 then accept
R2
set interfaces ge-0/0/0 unit 0 family inet address 10.8.64.104/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.8.42.104/24 set interfaces ge-0/0/1 unit 0 family iso set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.105.139/32 set interfaces lo0 unit 0 family iso address 47.0005.0102.5502.4211.00 set routing-options router-id 10.255.105.139 set routing-options autonomous-system 65534 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering database import policy ted2nlri set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.255.105.139 set protocols bgp group ibgp family traffic-engineering unicast set protocols bgp group ibgp export nlri2bgp set protocols bgp group ibgp neighbor 10.255.105.135 set protocols bgp group ebgp type external set protocols bgp group ebgp family traffic-engineering unicast set protocols bgp group ebgp export nlri2bgp set protocols bgp group ebgp peer-as 65533 set protocols bgp group ebgp neighbor 10.8.42.102 set protocols isis level 1 disable set protocols isis interface ge-0/0/0.0 set protocols isis interface ge-0/0/1.0 passive remote-node-iso 0102.5501.8181 set protocols isis interface ge-0/0/1.0 passive remote-node-id 10.8.42.102 set protocols isis interface lo0.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 10.8.42.102 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 10.255.105.141 set policy-options policy-statement accept-all from family traffic-engineering set policy-options policy-statement accept-all then accept set policy-options policy-statement nlri2bgp term 1 from family traffic-engineering set policy-options policy-statement nlri2bgp term 1 then accept set policy-options policy-statement ted2nlri term 1 from protocol isis set policy-options policy-statement ted2nlri term 1 from protocol ospf set policy-options policy-statement ted2nlri term 1 then accept set policy-options policy-statement ted2nlri term 2 then reject
R3
set interfaces ge-0/0/0 unit 0 family inet address 10.8.64.106/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.105.135/32 set interfaces lo0 unit 0 family iso address 47.0005.0102.5502.4250 set routing-options router-id 10.255.105.135 set routing-options autonomous-system 65534 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering database export policy accept-all set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.255.105.135 set protocols bgp group ibgp family traffic-engineering unicast set protocols bgp group ibgp neighbor 10.255.105.139 set protocols isis interface ge-0/0/0.0 level 1 disable set protocols isis interface lo0.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set policy-options policy-statement accept-all from family traffic-engineering set policy-options policy-statement accept-all then accept
Verfahren
Schritt-für-Schritt-Anleitung
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Weitere Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus.Verwenden des CLI-Editors im Konfigurationsmodus
So konfigurieren Sie Router R1:
-
Konfigurieren Sie die Schnittstellen des Routers R1.
[edit interfaces] user@R1# set ge-0/0/0 unit 0 family inet address 10.8.31.103/24 user@R1# set ge-0/0/0 unit 0 family iso user@R1# set ge-0/0/0 unit 0 family mpls user@R1# set ge-0/0/1 unit 0 family inet address 10.8.42.102/24 user@R1# set ge-0/0/1 unit 0 family iso user@R1# set ge-0/0/1 unit 0 family mpls user@R1# set lo0 unit 0 family inet address 10.255.105.141/32 user@R1# set lo0 unit 0 family iso address 47.0005.0102.5501.8181
-
Konfigurieren Sie die Router-ID und das autonome System des Routers R1.
[edit routing-options]user@R1# set router-id 10.255.105.141 user@R1# set autonomous-system 65533 -
Aktivieren Sie RSVP auf allen Schnittstellen des Routers R1 (mit Ausnahme der Verwaltungsschnittstelle).
[edit protocols]user@R1# set rsvp interface all user@R1# set rsvp interface fxp0.0 disable -
Aktivieren Sie MPLS auf allen Schnittstellen des Routers R1 (mit Ausnahme der Verwaltungsschnittstelle).
[edit protocols]user@R1# set mpls interface all user@R1# set mpls interface fxp0.0 disable -
Konfigurieren Sie die BGP-Gruppe für Router R1 für die Peering-Verbindung mit Router R0, und weisen Sie die lokale Adresse und die Nachbaradresse zu.
[edit protocols]user@R1# set bgp group ibgp type internal user@R1# set bgp group ibgp local-address 10.255.105.141 user@R1# set bgp group ibgp neighbor 10.255.105.137 -
Fügen Sie die BGP-TE-Signalisierungs-NLRI (Network Layer Reachability Information) zur ibgp-BGP-Gruppe hinzu.
[edit protocols]user@R1# set bgp group ibgp family traffic-engineering unicast -
Aktivieren Sie den Export der Richtlinie nlri2bgp auf Router R1.
[edit protocols]user@R1# set bgp group ibgp export nlri2bgp -
Konfigurieren Sie die BGP-Gruppe für Router R1 für das Peering mit Router R2, und weisen Sie der BGP-Gruppe ebgp die lokale Adresse und das autonome Nachbarsystem zu.
[edit protocols]user@R1# set bgp group ebgp type external user@R1# set bgp group ebgp neighbor 10.8.42.104 local-address 10.8.42.102 user@R1# set bgp group ebgp neighbor 10.8.42.104 peer-as 65534 -
Fügen Sie die BGP-TE-Signalisierungs-NLRI in die ebgp-BGP-Gruppe ein.
[edit protocols]user@R1# set bgp group ebgp family traffic-engineering unicast -
Passives Traffic-Engineering auf der Inter-AS-Verbindung ermöglichen.
[edit protocols]user@R1# set isis interface ge-0/0/1.0 passive remote-node-iso 0102.5502.4211 user@R1# set isis interface ge-0/0/1.0 passive remote-node-id 10.8.42.104 -
Aktivieren Sie OSPF auf der Schnittstelle, die Router R1 mit Router R0 verbindet, und auf der Loopback-Schnittstelle von Router R1, und aktivieren Sie Traffic-Engineering-Funktionen.
[edit protocols]user@R1# set ospf traffic-engineering user@R1# set ospf area 0.0.0.0 interface lo0.0 user@R1# set ospf area 0.0.0.0 interface ge-0/0/0.0 -
Passives Traffic-Engineering auf der Inter-AS-Verbindung ermöglichen.
[edit protocols]user@R1# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 10.8.42.104 user@R1# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 10.255.105.139 -
Konfigurieren Sie Richtlinien so, dass Datenverkehr von BGP-TE NLRI akzeptiert wird.
[edit policy-options]user@R1# set policy-statement accept-all from family traffic-engineering user@R1# set policy-statement accept-all then accept user@R1# set policy-statement nlri2bgp term 1 from family traffic-engineering user@R1# set policy-statement nlri2bgp term 1 then accept
Ergebnisse
Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie die Befehle , , und eingeben.show interfacesshow routing-optionsshow protocolsshow policy-options Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@R1# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 10.8.31.103/24;
}
family iso;
family mpls;
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 10.8.42.102/24;
}
family iso;
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.105.141/32;
family iso {
address 47.0005.0102.5501.8181:00;
}
}
}
user@R1# show routing-options router-id 10.255.105.141; autonomous-system 65533;
user@R1# show protocols
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
interface all;
interface fxp0.0 {
disable;
}
}
bgp {
group ibgp {
type internal;
local-address 10.255.105.141;
family traffic-engineering {
unicast;
}
export nlri2bgp;
neighbor 10.255.105.137;
}
group ebgp {
type external;
family traffic-engineering {
unicast;
}
neighbor 10.8.42.104 {
local-address 10.8.42.102;
peer-as 65534;
}
}
}
isis {
interface ge-0/0/1.0 {
passive {
remote-node-iso 0102.5502.4211;
remote-node-id 10.8.42.104;
}
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface lo0.0;
interface ge-0/0/0.0;
interface ge-0/0/1.0 {
passive {
traffic-engineering {
remote-node-id 10.8.42.104;
remote-node-router-id 10.255.105.139;
}
}
}
}
}
user@R1# show policy-options
policy-statement accept-all {
from family traffic-engineering;
then accept;
}
policy-statement nlri2bgp {
term 1 {
from family traffic-engineering;
then {
accept;
}
}
}
Verfahren
Schritt-für-Schritt-Anleitung
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Weitere Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus.Verwenden des CLI-Editors im Konfigurationsmodus
So konfigurieren Sie Router R2:
-
Konfigurieren Sie die Schnittstellen des Routers R2.
[edit interfaces] user@R2# set ge-0/0/0 unit 0 family inet address 10.8.64.104/24 user@R2# set ge-0/0/0 unit 0 family iso user@R2# set ge-0/0/0 unit 0 family mpls user@R2# set ge-0/0/1 unit 0 family inet address 10.8.42.104/24 user@R2# set ge-0/0/1 unit 0 family iso user@R2# set ge-0/0/1 unit 0 family mpls user@R2# set lo0 unit 0 family inet address 10.255.105.139/32 user@R2# set lo0 unit 0 family iso address 47.0005.0102.5502.4211.00
-
Konfigurieren Sie die Router-ID und das autonome System des Routers R2.
[edit routing-options]user@R2# set router-id 10.255.105.139 user@R2# set autonomous-system 65534 -
Aktivieren Sie RSVP auf allen Schnittstellen des Routers R2 (mit Ausnahme der Verwaltungsschnittstelle).
[edit routing-options]user@R2# set rsvp interface all user@R2# set rsvp interface fxp0.0 disable -
Aktivieren Sie MPLS auf allen Schnittstellen des Routers R2 (mit Ausnahme der Verwaltungsschnittstelle).
[edit routing-options]user@R2# set mpls interface all user@R2# set mpls interface fxp0.0 disable -
Aktivieren Sie den Import von Traffic Engineering-Datenbankparametern mithilfe der ted2nlri-Richtlinie.
[edit protocols]user@R2# set mpls traffic-engineering database import policy ted2nlri -
Konfigurieren Sie die BGP-Gruppe für Router R2 für das Peering mit Router R3, und weisen Sie die lokale Adresse und die Nachbaradresse zu.
[edit protocols]user@R2# set bgp group ibgp type internal user@R2# set bgp group ibgp local-address 10.255.105.139 user@R2# set bgp group ibgp neighbor 10.255.105.135 -
Fügen Sie die BGP-TE-Signalisierungs-NLRI (Network Layer Reachability Information) zur ibgp-BGP-Gruppe hinzu.
[edit protocols]user@R2# set bgp group ibgp family traffic-engineering unicast -
Aktivieren Sie den Export der Richtlinie nlri2bgp auf Router R2.
[edit protocols]user@R2# set bgp group ibgp export nlri2bgp -
Konfigurieren Sie die BGP-Gruppe für Router R2 für das Peering mit Router R1.
[edit protocols]user@R2# set bgp group ebgp type external -
Fügen Sie die BGP-TE-Signalisierungs-NLRI in die ebgp-BGP-Gruppe ein.
[edit protocols]user@R2# set bgp group ebgp family traffic-engineering unicast -
Weisen Sie die lokale Adresse und das benachbarte autonome System der BGP-Gruppe ebgp zu.
[edit protocols]user@R2# set bgp group ebgp peer-as 65533 user@R2# set bgp group ebgp neighbor 10.8.42.102 -
Aktivieren Sie den Export der Richtlinie nlri2bgp auf Router R2.
[edit protocols]user@R2# set bgp group ebgp export nlri2bgp -
Aktivieren Sie IS-IS auf der Schnittstelle, die Router R2 mit Router R3 verbindet, und der Loopback-Schnittstelle von Router R2.
[edit protocols]user@R2# set isis level 1 disable user@R2# set isis interface ge-0/0/0.0 user@R2# set isis interface lo0.0 -
Aktivieren Sie nur IS-IS-Ankündigung auf der Schnittstelle, die Router R2 mit Router R1 verbindet.
[edit protocols]user@R2# set isis interface ge-0/0/1.0 passive remote-node-iso 0102.5501.8181 user@R2# set isis interface ge-0/0/1.0 passive remote-node-id 10.8.42.102 -
Konfigurieren Sie die Traffic-Engineering-Funktion auf Router R2.
[edit protocols]user@R2# set ospf traffic-engineering -
Aktivieren Sie nur OSPF-Ankündigungen auf der Schnittstelle, die Router R2 mit Router R1 verbindet.
[edit protocols]user@R2# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 10.8.42.102 user@R2# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 10.255.105.141 -
Konfigurieren Sie Richtlinien so, dass Datenverkehr vom BGP-TE NLRI akzeptiert wird.
[edit policy-options]user@R2# set policy-statement accept-all from family traffic-engineering user@R2# set policy-statement accept-all then accept user@R2# set policy-statement nlri2bgp term 1 from family traffic-engineering user@R2# set policy-statement nlri2bgp term 1 then accept user@R2# set policy-statement ted2nlri term 1 from protocol isis user@R2# set policy-statement ted2nlri term 1 from protocol ospf user@R2# set policy-statement ted2nlri term 1 then accept user@R2# set policy-statement ted2nlri term 2 then reject
Ergebnisse
Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie die Befehle , , und eingeben.show interfacesshow routing-optionsshow protocolsshow policy-options Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@R2# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 10.8.64.104/24;
}
family iso;
family mpls;
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 10.8.42.104/24;
}
family iso;
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.105.139/32;
family iso {
address 47.0005.0102.5502.4211.00;
}
family iso;
}
}
user@R2# show routing-options router-id 10.255.105.139; autonomous-system 65534;
user@R2# show protocols
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
traffic-engineering {
database {
import {
policy ted2nlri;
}
}
}
interface all;
interface fxp0.0 {
disable;
}
}
bgp {
group ibgp {
type internal;
local-address 10.255.105.139;
family traffic-engineering {
unicast;
}
export nlri2bgp;
neighbor 10.255.105.135;
}
group ebgp {
type external;
family traffic-engineering {
unicast;
}
export nlri2bgp;
peer-as 65533;
neighbor 10.8.42.102;
}
}
isis {
level 1 disable;
interface ge-0/0/0.0;
interface ge-0/0/1.0 {
passive {
remote-node-iso 0102.5501.8181;
remote-node-id 10.8.42.102;
}
}
interface lo0.0;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface ge-0/0/1.0 {
passive {
traffic-engineering {
remote-node-id 10.8.42.102;
remote-node-router-id 10.255.105.141;
}
}
}
}
}
user@R2# show policy-options
policy-statement accept-all {
from family traffic-engineering;
then accept;
}
policy-statement nlri2bgp {
term 1 {
from family traffic-engineering;
then {
accept;
}
}
}
policy-statement ted2nlri {
term 1 {
from protocol [ isis ospf ];
then accept;
}
term 2 {
then reject;
}
}
Überprüfung
Überprüfen Sie, ob die Konfiguration ordnungsgemäß funktioniert.
- Überprüfen des BGP-Zusammenfassungsstatus
- Überprüfen des MPLS-LSP-Status
- Überprüfen der LSDIST.0-Routing-Tabelleneinträge
- Verifizieren der Traffic Engineering-Datenbankeinträge
Überprüfen des BGP-Zusammenfassungsstatus
Zweck
Stellen Sie sicher, dass BGP auf den Routern R0 und R1 ausgeführt wird.
Was
Führen Sie den Befehl im Betriebsmodus aus.show bgp summary
user@R0> show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
lsdist.0
10 10 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.255.105.141 65533 20 14 0 79 5:18 Establ
lsdist.0: 10/10/10/0Führen Sie den Befehl im Betriebsmodus aus.show bgp summary
user@R1> show bgp summary
Groups: 2 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
lsdist.0
10 10 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.8.42.104 65534 24 17 0 70 6:43 Establ
lsdist.0: 10/10/10/0
10.255.105.137 65533 15 23 0 79 6:19 Establ
lsdist.0: 0/0/0/0Bedeutung
Router R0 ist mittels Peering mit Router R1 verbunden.
Überprüfen des MPLS-LSP-Status
Zweck
Überprüfen Sie den Status des MPLS-LSP auf Router R0.
Was
Führen Sie den Befehl im Betriebsmodus aus.show mpls lsp
user@R0> show mpls lsp Ingress LSP: 1 sessions To From State Rt P ActivePath LSPname 10.255.105.135 10.255.105.137 Up 0 * to-R3-inter-as Total 1 displayed, Up 1, Down 0 Egress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0
Bedeutung
Der MPLS-LSP von Router R0 zu Router R3 wird eingerichtet.
Überprüfen der LSDIST.0-Routing-Tabelleneinträge
Zweck
Überprüfen Sie die Einträge in der Routing-Tabelle lsdist.0 auf den Routern R0, R1 und R2.
Was
Führen Sie den Befehl im Betriebsmodus aus.show route table lsdist.0
user@R0> show route table lsdist.0
lsdist.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
NODE { AS:65534 ISO:0102.5502.4211.00 ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
NODE { AS:65534 ISO:0102.5502.4250.00 ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
NODE { AS:65534 ISO:0102.5502.4250.02 ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
NODE { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 OSPF:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:8.42.1.104 } Remote { AS:65534 ISO:0102.5501.8181.00 }.{ IPv4:10.8.42.102 } ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.64.104 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:02:03, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
LINK { Local { AS:65534 ISO:0102.5502.4250.00 }.{ IPv4:10.8.64.106 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4211.00 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4250.00 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
LINK { Local { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 }.{ IPv4:10. 8.42.104 } Remote { AS:65534 Area:0.0.0.0 IPv4:10.255.105.141 }.{ IPv4:10.8.42.102 } OSPF:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0Führen Sie den Befehl im Betriebsmodus aus.show route table lsdist.0
user@R1> show route table lsdist.0
lsdist.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
NODE { AS:65534 ISO:0102.5502.4211.00 ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
NODE { AS:65534 ISO:0102.5502.4250.00 ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
NODE { AS:65534 ISO:0102.5502.4250.02 ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
NODE { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 OSPF:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.42.104 } Remote { AS:65534 ISO:0102.5501.8181.00 }.{ IPv4:10.8.42.102 } ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.64.104 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:02:19, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
LINK { Local { AS:65534 ISO:0102.5502.4250.00 }.{ IPv4:10.8.64.106 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4211.00 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4250.00 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
LINK { Local { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 }.{ IPv4:10.8.42.104 } Remote { AS:65534 Area:0.0.0.0 IPv4:10.255.105.141 }.{ IPv4:10.8.42.102 } OSPF:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0Führen Sie den Befehl im Betriebsmodus aus.show route table lsdist.0
user@R2> show route table lsdist.0
lsdist.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
NODE { AS:65534 ISO:0102.5502.4211.00 ISIS-L2:0 }/1152
*[IS-IS/18] 1d 00:24:39
Fictitious
NODE { AS:65534 ISO:0102.5502.4250.00 ISIS-L2:0 }/1152
*[IS-IS/18] 00:20:45
Fictitious
NODE { AS:65534 ISO:0102.5502.4250.02 ISIS-L2:0 }/1152
*[IS-IS/18] 00:20:45
Fictitious
NODE { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 OSPF:0 }/1152
*[OSPF/10] 1d 00:24:39
Fictitious
LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.42.104 } Remote { AS:65534 ISO:0102.5501.8181.00 }.{ IPv4:10.8.42.102 } ISIS-L2:0 }/1152
*[IS-IS/18] 00:20:58
Fictitious
LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.64.104 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152
*[IS-IS/18] 00:02:34
Fictitious
LINK { Local { AS:65534 ISO:0102.5502.4250.00 }.{ IPv4:10.8.64.106 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152
*[IS-IS/18] 00:20:45
Fictitious
LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4211.00 }.{ } ISIS-L2:0 }/1152
*[IS-IS/18] 00:20:45
Fictitious
LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4250.00 }.{ } ISIS-L2:0 }/1152
*[IS-IS/18] 00:20:45
Fictitious
LINK { Local { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 }.{ IPv4:10.8.42.104 } Remote { AS:65534 Area:0.0.0.0 IPv4:10.255.105.141 }.{ IPv4:10.8.42.102 } OSPF:0 }/1152
*[OSPF/10] 00:20:57
FictitiousBedeutung
Die Routen werden in der Routing-Tabelle lsdist.0 angezeigt.
Verifizieren der Traffic Engineering-Datenbankeinträge
Zweck
Überprüfen Sie die Traffic Engineering-Datenbankeinträge auf Router R0.
Was
Führen Sie den Befehl im Betriebsmodus aus.show ted database
user@R0> show ted database
TED database: 5 ISIS nodes 5 INET nodes
ID Type Age(s) LnkIn LnkOut Protocol
0102.5501.8168.00(10.255.105.137) Rtr 1046 1 1 OSPF(0.0.0.0)
To: 10.8.31.101-1, Local: 10.8.31.101, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
ID Type Age(s) LnkIn LnkOut Protocol
0102.5501.8181.00 --- 1033 1 0
0102.5502.4211.00(10.255.105.139) Rtr 3519 2 3 Exported ISIS-L2(1)
To: 0102.5502.4250.02, Local: 10.8.64.104, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
To: 0102.5501.8181.00, Local: 10.8.42.104, Remote: 10.8.42.102
Local interface index: 0, Remote interface index: 0
ID Type Age(s) LnkIn LnkOut Protocol
Exported OSPF(2)
To: 10.255.105.141, Local: 10.8.42.104, Remote: 10.8.42.102
Local interface index: 0, Remote interface index: 0
ID Type Age(s) LnkIn LnkOut Protocol
0102.5502.4250.00(10.255.105.135) Rtr 1033 1 1 Exported ISIS-L2(1)
To: 0102.5502.4250.02, Local: 10.8.64.106, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
ID Type Age(s) LnkIn LnkOut Protocol
0102.5502.4250.02 Net 1033 2 2 Exported ISIS-L2(1)
To: 0102.5502.4211.00(10.255.105.139), Local: 0.0.0.0, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
To: 0102.5502.4250.00(10.255.105.135), Local: 0.0.0.0, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
ID Type Age(s) LnkIn LnkOut Protocol
10.8.31.101-1 Net 1046 2 2 OSPF(0.0.0.0)
To: 0102.5501.8168.00(10.255.105.137), Local: 0.0.0.0, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
To: 10.255.105.141, Local: 0.0.0.0, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
ID Type Age(s) LnkIn LnkOut Protocol
10.255.105.141 Rtr 1045 2 2 OSPF(0.0.0.0)
To: 0102.5502.4211.00(10.255.105.139), Local: 10.8.42.102, Remote: 10.8.42.104
Local interface index: 0, Remote interface index: 0
To: 10.8.31.101-1, Local: 10.8.31.103, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0Bedeutung
Die Routen werden in der Verkehrstechnik-Datenbank angezeigt.
Konfigurieren der Verbindungsstatusverteilung mithilfe von BGP
Sie können die Verteilung von Topologieinformationen über mehrere Bereiche und autonome Systeme (ASs) hinweg ermöglichen, indem Sie das BGP-Protokoll erweitern, um Link-State-Informationen zu übertragen, die ursprünglich mit IGP erfasst wurden. Die IGP-Protokolle haben Skalierungsbeschränkungen, wenn es um die Verteilung großer Datenbanken geht. BGP ist nicht nur ein skalierbareres Vehikel für die Übertragung von Multi-Area- und Multi-AS-Topologieinformationen, sondern bietet auch die Richtlinienkontrollen, die für die Verteilung von Multi-AS-Topologien nützlich sein können. Die BGP-Link-State-Topologieinformationen werden zum Berechnen von Pfaden für MPLS-LSPs verwendet, die sich über mehrere Domänen erstrecken, wie z. B. gebietsübergreifende TE LSP, und bieten eine skalierbare und richtliniengesteuerte Möglichkeit für externe Pfadberechnungseinheiten wie ALTO und PCE, die Netzwerktopologie zu erfassen.
Bevor Sie beginnen:
Konfigurieren Sie die Geräteschnittstellen.
Konfigurieren Sie die Router-ID und die autonome Systemnummer für das Gerät.
Konfigurieren Sie die folgenden Protokolle:
RSVP
MPLS
IS-IS
OSPF
So aktivieren Sie die Link-State-Verteilung mithilfe von BGP:
Link-State-Verteilung mit SRv6
BGP-Link-State-Erweiterungen für SRv6
Ab Junos OS Version 21.3R1 unterstützen wir SRv6 in BGP-LS und Traffic Engineering Database (TED). BGP-LS-Erweiterungen exportieren die SRv6-Topologieinformationen an die SDN-Controller. Controller erhalten die Topologieinformationen, indem sie Teil einer IGP-Domäne oder über BGP-LS sind. BGP LS bietet einen skalierbaren Mechanismus zum Exportieren der Topologieinformationen. Es kann auch für die Inter-Domain-Netzwerke verwendet werden. Außerdem können Sie NLRI jetzt basierend auf dem IPv6-Präfix (SRv6-Locator) und dem SRv6-SID-NLRI filtern.
Fluss von BGP-Link-State-SRv6-Daten
BGP LS ruft die Traffic Engineering (TE)-Daten aus der TE-Datenbank (TED) ab und verteilt sie an die Peer-BGP-Lautsprecher. Dazu wandelt TED seine Einträge für Links, Knoten und Präfixe (IPv4 und IPv6) in Form von Routen um. Die folgende Abbildung zeigt den Datenfluss in BGP-LS.
-
SRv6-Attribute, die über ISIS IGP ausgetauscht werden, werden nun in Junos unterstützt, wie im IETF-Standard [3] beschrieben.
-
SRv6-Attribute werden der Traffic Engineering Database (TED) hinzugefügt.
-
SRv6-Attribute, die über ISIS IGP gelernt wurden, werden in TED gespeichert, wenn Knoten und Links in Routen umgewandelt werden. Diese Routen werden dann der TED-Importrichtlinie unterworfen, und wenn die Richtlinie dies zulässt, werden sie in einer Routing-Tabelle namens lsdist.0 installiert.
-
BGP kann so konfiguriert werden, dass Routen aus der Tabelle lsdist.0 entsprechend der Richtlinie "exportiert" oder angekündigt werden. BGP gibt diese Routen dann wie jedes andere NLRI weiter. Das heißt, Peers, die die BGP-LS-Familie konfiguriert und ausgehandelt haben, erhalten BGP-LS-NLRIs. BGP speichert die empfangenen BGP-LS-NLRIs in Form von Routen in der Tabelle "lsdist.0", in der es sich um dieselbe Tabelle handelt, in der lokal erstellte BGP-LS-Routen gespeichert werden. Die neu hinzugefügten SRv6-Informationen werden als Attribute bereits vorhandener NLRIs (Node, Link und Prefix) und eines neuen SRv6-Locator-NLRI in BGP propagiert.
-
Die empfangenen BGP-LS-NLRIs, die in Form von Routen in der Tabelle "lsdist.0" installiert sind, können der TED-Exportrichtlinie unterworfen werden, und wenn die Richtlinie dies zulässt, werden SRv6-Attribute aus diesen Routen der lokalen Instanz der TE-Datenbank hinzugefügt.
IPv6-Präfixe und IPv6-Adjacency-SIDs MPLS-Unterstützung in Traffic Engineering-Datenbanken und BGP-Verbindungsstatus
Wir haben die folgenden IPv6-Verbesserungen vorgenommen.
- Unterstützung für das Hinzufügen der IPv6-Attribute und -Informationen zur Traffic Engineering Database (TED) von Intermediate System zu Intermediate System (IS-IS).
- Unterstützung für den Import von IPv6-Attributen aus der Traffic Engineering-Datenbank in die LSDIST.0-Routing-Tabelle.
- Unterstützung für den Export von IPv6-Attributen in BGP Link-State (BGP-LS).
- Unterstützung für BGP-LS IPv6 Network Layer Reachability Information (NLRIs) und den Export von Attributen aus der lsdist.0-Routing-Tabelle in die Traffic Engineering-Datenbank.
Wir unterstützen nur das IS-IS Interior Gateway Protocol (IGP).
- Vorteile von IPv6-Präfixen und IPv6-Adjacency-SID-MPLS-Unterstützung in Traffic Engineering-Datenbanken und BGP-LS
- Implementierung
- Unterstützung für das Hinzufügen von IPv6-Attributen und -Informationen zur Traffic Engineering-Datenbank von IS-IS
- Unterstützung für den Import von IPv6-Attributen aus der Traffic Engineering-Datenbank in die Routing-Tabelle lsdist.0
- Unterstützung für den Export von IPv6-Attributen nach BGP-LS
- Unterstützung für BGP-LS IPv6 NLRIs und Attribute Export aus der lsdist.0-Routing-Tabelle in die Traffic Engineering-Datenbank
- Konfigurationsbefehl
Vorteile von IPv6-Präfixen und IPv6-Adjacency-SID-MPLS-Unterstützung in Traffic Engineering-Datenbanken und BGP-LS
Wir haben die Ausgaben der vorhandenen Betriebsbefehle verbessert und die show-Befehle hinzugefügt, um die Liste der IPv6- bzw. IPv4-Präfixe in der Traffic-Engineering-Datenbank anzuzeigen.
show ted database extensive– Die Ausgabe wurde um die Attribute IPv6 Segment Routing (SR)-MPLS erweitert.show ted link detail—Die Ausgabe wurde erweitert, um die IPv6 SR-MPLS-Attribute einzuschließen, die den Links der Traffic-Engineering-Datenbank entsprechen.show route table lsdist.0 [extensive | detail]– Die Ausgabe wurde um IPv6-NLRIs und IPv6-SR-MPLS-Attribute erweitert.show route– Es wurden zusätzliche Parameter zum Filtern von Einträgen für die Anzeige in der Tabelle lsdist.0 hinzugefügt. Wir haben zusätzliche Optionen hinzugefügt, um IPv6-Präfixe einzubeziehen. Die Optionen sind und .te-ipv6-prefix-ipv6-addrte-ipv6-prefix-node-isoshow ted ipv6-prefix– Der Befehl show wurde hinzugefügt, um die Liste der IPv6-Präfixe in der Traffic-Engineering-Datenbank anzuzeigen.show ted ipv4-prefix– Der Befehl show wurde hinzugefügt, um die Liste der IPv4-Präfixe in der Traffic-Engineering-Datenbank anzuzeigen.
Implementierung
BGP-LS ruft die Traffic Engineering (TE)-Daten aus der Traffic Engineering-Datenbank ab und verteilt die Daten an seine BGP-Peers. Um dies zu erreichen, konvertiert die Traffic-Engineering-Datenbank ihre Links, Knoten und Präfixeinträge (IPv4 und IPv6) in Form von Routen. Die folgende Abbildung zeigt den Informationsfluss von BGP-LS zu BGP-LS.
Unterstützung für das Hinzufügen von IPv6-Attributen und -Informationen zur Traffic Engineering-Datenbank von IS-IS
Junos OS unterstützt SR-MPLS-Attribute für IPv6-Data Plane, die über IS-IS IGP ausgetauscht werden. Als Ergebnis dieser Erweiterung können IPv6-Attribute und -Informationen zur Traffic Engineering Database (TED) hinzugefügt werden.
Unterstützung für den Import von IPv6-Attributen aus der Traffic Engineering-Datenbank in die Routing-Tabelle lsdist.0
IPv6-Attribute, die von IS-IS IGP empfangen und in der Traffic-Engineering-Datenbank als Knoten, Links und Präfixe gespeichert werden, werden in Routen konvertiert. Diese Routen werden dann der Richtlinie zum Importieren von Traffic Engineering-Datenbanken unterworfen. Wenn die Richtlinie dies zulässt, werden die Routen in einer Routingtabelle mit dem Namen lsdist.0 installiert.
Unterstützung für den Export von IPv6-Attributen nach BGP-LS
BGP ist so konfiguriert, dass Routen aus der Tabelle lsdist.0 exportiert oder angekündigt werden, vorbehaltlich der Richtlinie. Dies ist ein Routineszenario für jede Routenerstellung in BGP. BGP gibt diese Routen dann wie jede andere NLRI an die Peers weiter, wobei BGP-LS konfiguriert und BGP-Nachbarschaft eingerichtet wurde. BGP speichert die empfangenen BGP-LS-NLRIs in Form von Routen in der Tabelle lsdist.0, die dieselbe Tabelle ist, in der lokal erstellte BGP-LS-Routen gespeichert werden. Als Ergebnis dieser Funktionalität werden neu hinzugefügte IPv6-Informationen als Attribute bereits vorhandener Link-NLRI und als neue IPv6-Präfix-NLRI an BGP weitergegeben.
Unterstützung für BGP-LS IPv6 NLRIs und Attribute Export aus der lsdist.0-Routing-Tabelle in die Traffic Engineering-Datenbank
In Junos OS unterliegen die empfangenen BGP-LS-NLRIs, die in Form von Routen in der Tabelle lsdist.0 installiert sind, der Exportrichtlinie für Traffic Engineering-Datenbanken. Wenn die Richtlinie dies zulässt, werden IPv6-Attribute und Informationen aus diesen Routen der lokalen Instanz der Traffic-Engineering-Datenbank hinzugefügt.
Konfigurationsbefehl
Der BGP-TE-Richtlinienbefehl wurde erweitert, um das Filtern von NLRIs basierend auf dem IPv6-Präfix NLRI zu ermöglichen. Siehe .ipv6-prefix
Siehe auch
Tabellarischer Änderungsverlauf
Die Unterstützung der Funktion hängt von der Plattform und der Version ab, die Sie benutzen. Verwenden Sie Feature Explorer, um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.