Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

BGP-Routenreflektoren

Verstehen von BGP-Routenreflektoren

In diesem Thema wird die Verwendung von Routenreflektoren zur Simplifizierung der Konfiguration und Unterstützung bei der Skalierung erörtert. Eine weitere Möglichkeit, die Arbeitslast auf einem Routenreflektor zu reduzieren, der sich nicht im Datenverkehrsweiterleitungspfad befindet, besteht darin, die no-install Anweisung auf der [edit protocols bgp family family-name] Hierarchieebene zu verwenden. Ab Junos OS Version 15.1 beseitigt die Anweisung die no-install Interaktion zwischen dem Routing-Protokoll-Daemon (rpd) und anderen Komponenten im Junos-System wie dem Kernel oder dem verteilten Firewall-Daemon (dfwd). Diese Interaktion wird dadurch verhindert, dass Routen in den zugehörigen RPD-Routing-Informationsdatenbanken (RIBs), auch bekannt als Routing-Tabellen, für diese Komponenten veröffentlicht werden.

Anmerkung:

In Versionen vor Junos OS Version 15.1 können Sie die Arbeitslast auf einem Routenreflektor reduzieren, der sich nicht im Datenverkehrsweiterleitungspfad befindet, indem Sie eine Weiterleitungstabellen-Exportrichtlinie verwenden, die aus BGP gelernte Routen zurückweist.

Aufgrund der internen BGP(IBGP)-Full-Mesh-Anforderung verwenden die meisten Netzwerke Routenreflektoren, um die Konfiguration zu vereinfachen. Die Formel zur Berechnung der Anzahl der für ein full mesh erforderlichen Sitzungen lautet v * (v - 1)/2, wobei v die Anzahl der BGP-fähigen Geräte ist. Das Full-Mesh-Modell ist nicht gut skalierbar. Mithilfe eines Routenreflektors gruppieren Sie Router in Cluster, die durch numerische Kennungen identifiziert werden, die für das autonome System (AS) eindeutig sind. Innerhalb des Clusters müssen Sie eine BGP-Sitzung von einem einzelnen Router (dem Routenreflektor) zu jedem internen Peer konfigurieren. Mit dieser Konfiguration wird die IBGP Full-Mesh-Anforderung erfüllt.

Um Routenreflektion in einem AS zu verwenden, bezeichnen Sie einen oder mehrere Router als Routenreflektor – in der Regel einen pro Präsenzpunkt (POP). Routenreflektoren haben die besondere BGP-Fähigkeit, von einem internen Peer gelernte Routen auf andere interne Peers umzuverwenden. Anstatt also zu erfordern, dass alle internen Peers vollständig miteinander vernetzt sind, erfordert die Routenreflektion nur, dass der Routenreflektor vollständig mit allen internen Peers vernetzt ist. Der Routenreflektor und alle internen Peers bilden einen Cluster, wie in Abbildung 1dargestellt.

Anmerkung:

Für einige Geräte von Juniper Networks muss auf jedem Gerät, das einen Routenreflektor verwendet, eine Erweiterte BGP-Funktionslizenz installiert sein. Lizenzdetails finden Sie im Leitfaden Softwareinstallation und -upgrade.

Abbildung 1: Einfache Routenreflektortopologie (ein Cluster)Einfache Routenreflektortopologie (ein Cluster)

Abbildung 1 zeigt den Router RR, der als Routenreflektor für Cluster 127 konfiguriert ist. Die anderen Router sind interne Peers innerhalb des Clusters. BGP-Routen werden von einem der internen Peers an Router RR angeboten. RR liest diese Routen dann auf alle anderen Peers innerhalb des Clusters um.

Sie können mehrere Cluster konfigurieren und verknüpfen, indem Sie ein vollständiges Mesh aus Routenreflektoren konfigurieren (siehe Abbildung 2).

Abbildung 2: Grundlegende Routenreflektion (mehrere Cluster)Grundlegende Routenreflektion (mehrere Cluster)

Abbildung 2 zeigt die Routenreflektoren RR 1, RR 2, RR 3 und RR 4 als vollständig meshierte interne Peers. Wenn ein Router eine Route zu RR 1 angibt, liest RR 1 die Route auf die anderen Routenreflektoren um, die wiederum die Route auf die verbleibenden Router innerhalb des AS umstellen. Die Routenreflektion ermöglicht die Verbreitung der Route im gesamten AS ohne die Skalierungsprobleme, die durch die Full-Mesh-Anforderung entstehen.

Anmerkung:

Ein Routenreflektor, der mehrere Cluster unterstützt, akzeptiert keine Route mit derselben Cluster-ID von einem Nicht-Client-Router. Daher müssen Sie eine andere Cluster-ID für eine redundante RR konfigurieren, um die Route zu anderen Clustern widerzuspiegeln.

Wenn Cluster jedoch groß werden, wird es schwierig, ein Full-Mesh mit einem Routenreflektor zu skalieren, ebenso wie ein Full-Mesh zwischen Routenreflektoren. Um dieses Problem auszugleichen, können Sie Cluster von Routern zu Clustern von Clustern gruppieren, um hierarchische Routenreflektion zu ermöglichen (siehe Abbildung 3).

Abbildung 3: Hierarchische Routenreflektion (Cluster von Clustern)Hierarchische Routenreflektion (Cluster von Clustern)

Abbildung 3 zeigt RR 2, RR 3 und RR 4 als Routenreflektoren für Cluster 127, 19 und 45. Anstatt diese Routenreflektoren vollständig zu vermaschen, hat der Netzwerkadministrator sie als Teil eines anderen Clusters (Cluster 6) konfiguriert, für den RR 1 der Routenreflektor ist. Wenn ein Router eine Route zu RR 2 anwirbt, liest RR 2 die Route zu allen Routern innerhalb seines eigenen Clusters um, und revertiert dann die Route auf RR 1. RR 1 liest die Route zu den Routern in seinem Cluster, und diese Router übertragen die Route durch ihre Cluster.

Beispiel: Konfigurieren eines Routenreflektors

In diesem Beispiel wird die Konfiguration eines Routenreflektors dargestellt.

Anforderungen

Vor der Konfiguration dieses Beispiels ist keine spezielle Konfiguration über die Geräte initialisierung hinaus erforderlich.

Überblick

Im Allgemeinen müssen interne BGP-fähige Geräte (IBGP) vollständig meshfähig sein, da IBGP keine Updates für andere IBGP-fähige Geräte zurückgibt. Das Full-Mesh ist ein logisches Mesh, das durch die Konfiguration mehrerer neighbor Anweisungen auf jedem IBGP-fähigen Gerät erreicht wird. Das Full-Mesh ist nicht unbedingt ein physisches Full-Mesh. Die Verwaltung eines Full-Meshs (logisch oder physisch) ist in großen Bereitstellungen nicht gut skalierbar.

Abbildung 4 zeigt ein IBGP-Netzwerk mit Gerät A, das als Routenreflektor fungiert. Geräte B und Gerät C sind Clients des Routenreflektors. Gerät D und Gerät E befinden sich außerhalb des Clusters, also nichtclients des Routenreflektors.

Auf Gerät A (dem Routenreflektor) müssen Sie Peer-Beziehungen zu allen IBGP-fähigen Geräten aufbauen, indem Sie die Anweisung für die neighbor Clients (Gerät B und Gerät C) und die Nichtclients (Gerät D und Gerät E) einordnen. Sie müssen auch die cluster Anweisung und eine Cluster-Kennung enthalten. Die Cluster-Kennung kann ein beliebiger 32-Bit-Wert sein. In diesem Beispiel wird die IP-Adresse der Loopback-Schnittstelle des Routenreflektors verwendet.

Auf Gerät B und Gerät C, den Routenreflektorclients, benötigen Sie nur eine neighbor Anweisung, die eine Peer-Beziehung mit dem Routenreflektor, Gerät A, bildet.

Auf Gerät D und Gerät E, den Nichtclients, benötigen Sie für jedes Nichtclientgerät (D-to-E und E-to-D) eine neighbor Anweisung. Sie benötigen auch eine neighbor Anweisung für den Routenreflektor (D-to-A und E-to-A). Geräte D und Gerät E benötigen neighbor keine Anweisungen für die Clientgeräte (Gerät B und Gerät C).

Tipp:

Geräte D und Gerät E gelten als Nichtclients, da sie peer-Beziehungen explizit miteinander konfiguriert haben. Um sie zu RRroute-Reflector-Clients zu machen, entfernen Sie die neighbor 192.168.5.5 Anweisung aus der Konfiguration auf Gerät D, und entfernen Sie die neighbor 192.168.0.1 Anweisung aus der Konfiguration auf Gerät E.

Abbildung 4: IBGP-Netzwerk mit einem RoutenreflektorIBGP-Netzwerk mit einem Routenreflektor

Konfiguration

Verfahren

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 die Netzwerkkonfiguration erforderlich sind, und kopieren Sie dann die Befehle und fügen Sie sie auf Hierarchieebene in die [edit] CLI ein.

Gerät A

Gerät B

Gerät C

Gerät D

Gerät E

Schritt-für-Schritt-Verfahren

Konfigurieren des Routenreflektors

Schritt-für-Schritt-Verfahren

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

So konfigurieren Sie IBGP im Netzwerk mit Gerät A von Juniper Networks als Routenreflektor:

  1. Konfigurieren Sie die Schnittstellen.

  2. Konfigurieren Sie BGP, einschließlich der Cluster-Kennungs- und Nachbarbeziehungen mit allen IBGP-fähigen Geräten im autonomen System (AS).

    Wenden Sie auch die Richtlinie an, die OSPF-Routen in BGP umverteilt.

  3. Konfigurieren Sie statisches Routing oder ein Interior Gateway Protocol (IGP).

    In diesem Beispiel wird OSPF verwendet.

  4. Konfigurieren Sie die Richtlinie, die OSPF-Routen in BGP umverteilt.

  5. Konfigurieren Sie die Router-ID und die autonome Systemnummer (AS).

Ergebnisse

Bestätigen Sie Im Konfigurationsmodus Ihre Konfiguration durch Eingabe der show interfacesBefehle , , show protocolsshow policy-optionsundshow routing-options. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Wenn Sie die Konfiguration des Geräts durchgeführt haben, geben Sie aus dem Konfigurationsmodus ein commit .

Anmerkung:

Wiederholen Sie diese Schritte für jeden nichtclient-BGP-Peer innerhalb des Clusters, den Sie konfigurieren, wenn die anderen nichtclient-Geräte von Juniper Networks stammen. Andernfalls erhalten Sie anweisungen in der Dokumentation des Geräts.

Konfigurieren von Client-Peers

Schritt-für-Schritt-Verfahren

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

So konfigurieren Sie Client-Peers:

  1. Konfigurieren Sie die Schnittstellen.

  2. Konfigurieren Sie die BGP-Nachbarbeziehung mit dem Routenreflektor.

    Wenden Sie auch die Richtlinie an, die OSPF-Routen in BGP umverteilt.

  3. OSPF konfigurieren.

  4. Konfigurieren Sie die Richtlinie, die OSPF-Routen in BGP umverteilt.

  5. Konfigurieren Sie die Router-ID und die AS-Nummer.

Ergebnisse

Bestätigen Sie Im Konfigurationsmodus Ihre Konfiguration durch Eingabe der show interfacesBefehle , , show protocolsshow policy-optionsundshow routing-options. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Wenn Sie die Konfiguration des Geräts durchgeführt haben, geben Sie aus dem Konfigurationsmodus ein commit .

Anmerkung:

Wiederholen Sie diese Schritte für jeden Client-BGP-Peer innerhalb des Clusters, den Sie konfigurieren, wenn die anderen Clientgeräte von Juniper Networks stammen. Andernfalls erhalten Sie anweisungen in der Dokumentation des Geräts.

Konfigurieren von Nichtclient-Peers

Schritt-für-Schritt-Verfahren

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

So konfigurieren Sie Nichtclient-Peers:

  1. Konfigurieren Sie die Schnittstellen.

  2. Konfigurieren Sie die BGP-Nachbarbeziehungen mit dem RRroute-Reflector und mit den anderen Nichtclient-Peers.

    Wenden Sie auch die Richtlinie an, die OSPF-Routen in BGP umverteilt.

  3. OSPF konfigurieren.

  4. Konfigurieren Sie die Richtlinie, die OSPF-Routen in BGP umverteilt.

  5. Konfigurieren Sie die Router-ID und die AS-Nummer.

Ergebnisse

Bestätigen Sie Im Konfigurationsmodus Ihre Konfiguration durch Eingabe der show interfacesBefehle , , show protocolsshow policy-optionsundshow routing-options. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Wenn Sie die Konfiguration des Geräts durchgeführt haben, geben Sie aus dem Konfigurationsmodus ein commit .

Anmerkung:

Wiederholen Sie diese Schritte für jeden nichtclient-BGP-Peer innerhalb des Clusters, den Sie konfigurieren, wenn die anderen nichtclient-Geräte von Juniper Networks stammen. Andernfalls erhalten Sie anweisungen in der Dokumentation des Geräts.

Überprüfung

Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.

Überprüfen von BGP-Nachbarn

Zweck

Überprüfen Sie, ob BGP auf konfigurierten Schnittstellen ausgeführt wird und dass die BGP-Sitzung für jede Nachbaradresse eingerichtet wird.

Aktion

Geben Sie im Betriebsmodus den show bgp neighbor Befehl ein.

Überprüfen von BGP-Gruppen

Zweck

Vergewissern Sie sich, dass die BGP-Gruppen richtig konfiguriert sind.

Aktion

Geben Sie im Betriebsmodus den show bgp group Befehl ein.

Überprüfen der BGP-Zusammenfassungsinformationen

Zweck

Vergewissern Sie sich, dass die BGP-Konfiguration korrekt ist.

Aktion

Geben Sie im Betriebsmodus den show bgp summary Befehl ein.

Überprüfen der Routing-Tabelleninformationen

Zweck

Vergewissern Sie sich, dass die Routingtabelle die IBGP-Routen enthält.

Aktion

Geben Sie im Betriebsmodus den show route Befehl ein.

Verständnis eines Routenreflektors, der zu zwei verschiedenen Clustern gehört

Der Zweck der Routenreflektion ist die Schleifenverhinderung, wenn die internen BGP-Routinggeräte (IBGP) nicht vollständig meshiert sind. Um dies zu erreichen, brechen RRs eines der Regeln des normalen BGP-Betriebs: Sie können die von einem internen BGP-Peer gelernten Routen auf andere interne BGP-Peers umstellen.

Normalerweise ist ein einzelnes RR Ein Mitglied von nur einem Cluster. Denken Sie beispielsweise daran, dass in einem hierarchischen RR-Design eine RR der Client einer Ebene-1-RR sein kann, aber keine Clients voneinander.

Wenn jedoch zwei RRs Clients voneinander sind und die Routen von einem Cluster zum anderen reflektiert werden, ist nur eine der Cluster-IDs in der Clusterliste enthalten. Dies liegt daran, dass eine Cluster-ID in der Clusterliste für die Schleifenverhinderung in diesem Fall geeignet ist.

Tabelle 1 fasst die Regeln zusammen, die Routenreflektoren beim Ausfüllen der Clusterliste einer reflektierten Route mit Cluster-IDs verwenden.

Tabelle 1: Regeln für Routenreflektoren

Routenreflektionsszenario

Konfiguration

Wenn eine Route von einem der Clients zu einem Nicht-Client-Router reflektiert wird

Client -> RR -> Nicht-Client

Die RR füllt die dem Client zugeordnete Cluster-ID in der Clusterliste der reflektierten Route aus.

Wenn eine Route von einem Nicht-Client-Router zu einem Client-Router reflektiert wird

Nicht-Client-> RR->-Client

Die RR füllt die dem Client zugeordnete Cluster-ID in der Clusterliste der reflektierten Route aus.

Wenn eine Route von einem Client-Router zu einem anderen Client-Router in einem anderen Cluster reflektiert wird

client1 -> RR -> client2 (verschiedene Cluster)

Die RR füllt die dem Client1 zugeordnete Cluster-ID in der Clusterliste aus, bevor die Cluster-ID an client2 angezeigt wird. Die dem Client 2 zugeordnete Cluster-ID wird nicht hinzugefügt.

Wenn eine Route von einem Client-Router zu einem Nicht-Client-Router in einem anderen autonomen System reflektiert wird.

Wenn Sie beispielsweise eine Tier 2-RR- und 2 BGP-Gruppen konfiguriert haben, eine für die RR-Clients und die andere für Ebene 1-RR, und Sie spiegeln eine Route von einem autonomen System zu einem anderen autonomen System wider.

Client -> RR -> Nicht-Client (unterschiedliche AS)

Die RR füllt die Clusterliste nicht mit der Cluster-ID, bevor die Route zum Nicht-Client-Gerät reflektiert wird, da die Cluster-ID spezifisch für ein autonomes System ist.

Beispiel: Konfigurieren eines Routenreflektors, der zu zwei verschiedenen Clustern gehört

In diesem Beispiel wird gezeigt, wie ein Routenreflektor (RRs) konfiguriert wird, der zu zwei verschiedenen Clustern gehört. Dies ist kein gängiges Szenario, kann aber in einigen Situationen nützlich sein.

Anforderungen

Konfigurieren Sie die Geräteschnittstellen und ein internes Gateway-Protokoll (IGP). Ein Beispiel für eine RR-Einrichtung, die die Schnittstelle und IGP-Konfiguration umfasst, finden Sie unter Beispiel: Konfigurieren eines Routenreflektors.

Überblick

In diesem Beispiel ist Gerät RR1 ein Routenreflektor für Gerät R2 und Gerät RR2. Der Routenreflektor RR1 hat zwei verschiedene Cluster-IDs zugewiesen, eine ist 5,5,5,5 für RR1-R2 und 6.6.6.6 für RR1-RR2.

Gerät RR2 ist ein Routenreflektor für Gerät R4.

Siehe Abbildung Abbildung 5.

Abbildung 5: Routenreflektor in zwei verschiedenen ClusternRoutenreflektor in zwei verschiedenen Clustern

Dieses Beispiel zeigt die BGP-Konfiguration auf Gerät RR1 und Gerät RR2.

Konfiguration

Verfahren

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 die Netzwerkkonfiguration erforderlich sind, und kopieren Sie dann die Befehle und fügen Sie sie auf Hierarchieebene in die [edit] CLI ein.

Gerät RR1

Gerät RR2

Konfigurieren von Geräte-RR1

Schritt-für-Schritt-Verfahren

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

So konfigurieren Sie Geräte-RR1:

  1. Konfigurieren Sie die Peering-Beziehung mit Gerät R2.

  2. Konfigurieren Sie die Peering-Beziehung mit Gerät R0.

  3. Konfigurieren Sie die Peering-Beziehung mit Gerät RR2.

Ergebnisse

Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie den show protocols Befehl eingeben. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Wenn Sie die Konfiguration des Geräts durchgeführt haben, geben Sie aus dem Konfigurationsmodus ein commit .

Konfigurieren von Geräte-RR2

Schritt-für-Schritt-Verfahren

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

So konfigurieren Sie Geräte-RR2:

  1. Konfigurieren Sie die Peering-Beziehung mit Gerät R4.

  2. Konfigurieren Sie die Peering-Beziehung mit Gerät RR1.

Ergebnisse

Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie den show protocols Befehl eingeben. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Wenn Sie die Konfiguration des Geräts durchgeführt haben, geben Sie aus dem Konfigurationsmodus ein commit .

Überprüfung

Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.

Überprüfen der für Route 2.2.2.2 angekündigten Cluster-ID

Zweck

Überprüfen Sie, ob BGP auf konfigurierten Schnittstellen ausgeführt wird und dass die BGP-Sitzung für jede Nachbaradresse eingerichtet wird.

Aktion

Geben Sie im Betriebsmodus den show route advertising-protocol bgp neighbor-address Befehl ein.

Bedeutung

Die 2.2.2.2/32-Route stammt vom Client-Peer des Geräts RR1, Gerät R2. Wenn diese Route an den Client von RR1, Device RR2, gesendet wird, ist auf der Route die 5.5.5.5 Cluster-ID angehängt, die die Cluster-ID für RR1-R2 ist.

Überprüfen der für Route 1.1.1.1 angekündigten Cluster-ID

Zweck

Überprüfen Sie die Route-Anzeige von Gerät RR1 zu Gerät RR2.

Aktion

Geben Sie im Betriebsmodus den show route advertising-protocol bgp neighbor-address Befehl ein.

Bedeutung

Die Route 1.1.1.1/32 stammt vom Geräte-RR1-Gerät R0, dem Nicht-Client-Peer. Wenn diese Route an den Client von RR1, Gerät RR2, gesendet wird, ist auf der Route die 6.6.6.6 Cluster-ID angehängt, die Die Cluster-ID für RR1-RR2.

Gerät RR1 behält die eingehende Cluster-ID von Gerät RR2 bei der Werbung an einen anderen Client in einem anderen Cluster (Gerät R4) bei.

Verstehen der optimalen BGP-Routenreflektion

Sie können BGP Optimal Route Reflection (BGP-ORR) mit IS-IS und OSPF als Interior Gateway Protocol (IGP) auf einem Routenreflektor konfigurieren, um den besten Pfad zu den BGP-ORR-Clientgruppen zu werben. Dies geschieht mit der kürzesten IGP-Metrik aus der Perspektive eines Clients anstelle der Ansicht des Routenreflektors.

Clientgruppen, die dieselbe oder ähnliche IGP-Topologie nutzen, können als eine BGP-Peergruppe gruppiert werden. Sie können BGP-ORR in dieser BGP-Peer-Gruppe aktivieren optimal-route-reflection . Sie können auch einen der Clientknoten als primären Knoten (igp-primary) in einer BGP-Peergruppe konfigurieren, sodass die IGP-Metrik aus diesem primären Knoten verwendet wird, um den besten Pfad auszuwählen und ihn den Clients in derselben BGP-Peergruppe zu präsentieren. Optional können Sie auch einen anderen Clientknoten als Backup-Knoten (igp-backup) auswählen, der beim Ausfall des primären Knotens (igp-primary) verwendet wird oder nicht erreichbar ist.

Um BGP-ORR zu aktivieren, fügen Sie die optimal-route-reflection Anweisung auf der [edit protocols bgp group group-name] Hierarchieebene ein.

Anmerkung:

BGP-ORR funktioniert nur, wenn IGP für die BGP-Routenauflösung verwendet wird. BGP-ORR funktioniert nicht, wenn MPLSLDP/RSVP für die Routenauflösung verwendet wird.

Anmerkung:

Damit BGP-ORR funktioniert, sollte das BGP-Präfix über IGP aufgelöst werden. In normalen Layer-3-VPN- oder Layer-2-VPN-, VPLS- oder MVPN- oder EVPN-Szenarien werden die Präfixe über inet.3 aufgelöst. In inet.3 wäre die primäre Route für den Protocol-Next-Hop des Prefix entweder RSVP oder LDP (und nicht ein IGP-Protokoll wie IS-IS oder OSPF). Damit BGP-ORR funktioniert, müssen Sie den Router so konfigurieren, dass er inet.0 für die Routenauflösung von Layer 3-VPN- oder Layer-2-VPN- oder VPLS- oder MVPN- oder EVPN-Präfixen verwendet. Sie können dies über die folgenden Befehle tun:

  • Für Layer-3-VPN-Präfix:

  • Für Layer-2-VPN oder VPLS-Präfix:

  • Für EVPN-Präfix:

  • Für MVPN-Präfix:

Eine andere Methode besteht darin, die IGP-Routen in inet.3 zu lecken und sie als primäre Route in inet.3 zu machen.

Verwenden Sie die folgende CLI-Hierarchie, um BGP-ORR zu konfigurieren:

Konfigurieren von BGP Optimale Routenreflektion auf einem Routenreflektor zur Anzeige des besten Pfads

Sie können BGP Optimal Route Reflection (BGP-ORR) mit IS-IS und OSPF als Interior Gateway Protocol (IGP) auf einem Routenreflektor konfigurieren, um den besten Pfad zu den BGP-ORR-Clientgruppen zu werben. Dies geschieht mit der kürzesten IGP-Metrik aus der Perspektive eines Clients anstelle der Ansicht des Routenreflektors.

Um BGP-ORR zu aktivieren, fügen Sie die optimal-route-reflection Anweisung auf der [edit protocols bgp group group-name] Hierarchieebene ein.

Clientgruppen, die dieselbe oder ähnliche IGP-Topologie nutzen, können als eine BGP-Peergruppe gruppiert werden. Sie können BGP-ORR in dieser BGP-Peer-Gruppe aktivieren optimal-route-reflection .

So konfigurieren Sie BGP-ORR:

  1. Konfigurieren Sie optimale Routenreflektion.
  2. Konfigurieren Sie einen der Clientknoten als primären Knoten (igp-primary) in einer BGP-Peergruppe, so dass die IGP-Metrik von diesem primären Knoten verwendet wird, um den besten Pfad auszuwählen und ihn den Clients in derselben BGP-Peergruppe anzuzeigen.
  3. (Optional) Konfigurieren Sie einen anderen Clientknoten als Backup-Knoten (igp-backup), der verwendet wird, wenn der primäre Knoten ausfälltigp-primary oder nicht erreichbar ist.

Verwenden Sie die folgenden CLI-Befehle zur Überwachung und Fehlerbehebung der Konfiguration für BGP-ORR:

  • show bgp group— Anzeige der primären und Backup-Konfigurationen von BGP-ORR.

  • show isis bgp-orr— Anzeige der IS-IS BGP-ORR-Metrik (RIB).

  • show ospf bgp-orr— Anzeige der OSPF BGP-ORR-Metrik (RIB).

  • show ospf route– Anzeigen der Einträge in der OSPF-Routingtabelle

  • show route— Zeigen Sie die aktiven Einträge in den Routingtabellen an.

  • show route advertising protocol bgp peer— Überprüfen Sie, ob die Routen gemäß den BGP-ORR-Regeln angekündigt werden.

Überblick über BGP Route Server

Ein BGP-Routenserver ist das externe BGP (EBGP), das einem internen IBGP-Routenreflektor entspricht, der die Anzahl der in einem Netzwerk erforderlichen direkten EBGP-Sitzungen vereinfacht. EBGP-Routenserver sind hinsichtlich der BGP-Attributausbreitung transparent, so dass eine Route, die von einem Routenserver empfangen wird, die Gruppe von BGP-Attributen (NEXT_HOP, AS_PATH, MULTI_EXIT_DISC, AIGP und Communities) transportiert, wenn die Route von einem direkt verbundenen EBGP-Peer stammt.

Wie bei einem IBGP-Routenreflektor wird ein EBGP-Routenserver mithilfe der Routenserverfunktionalität an ein Netzwerk außerhalb des direkten Weiterleitungspfads zwischen den EBGP-Peers angeschlossen. Diese Konnektivität kann über eine direkte physische Verbindung oder über Layer-2-Netzwerke wie VPLS LAN oder EVPN oder über eine IP-Fabric von Punkt-zu-Punkt-EBGP-Verbindungen erfolgen, die die Erreichbarkeit von Loopback-Adressen von Peers bieten (typisch in Rechenzentrumsnetzwerken).

Das BGP-Protokoll wird erweitert, um Route-Server-Funktionen mit den folgenden in RFC 7947 beschriebenen Funktionen bereitzustellen:

  • Attributtransparenz für NEXT_HOP, AS_PATH, MULTI_EXIT_DISC, AIGP und Communities.

  • Richtlinienkontrolle pro Client und RiBs mit mehreren Routenservern zur Abwehr von Pfadverstecken.

BGP-Programmierbarkeit nutzt die Route-Server-Funktionalität. Die BGP JET-API bgp_route_service.proto wurde zur Unterstützung der Routenserverfunktionen wie folgt erweitert:

  • Programmieren Sie den EBGP-Routenserver.

  • Einfügen von Routen in die spezifische Routingserver-RIB, um sie selektiv an die Clientgruppen in clientspezifischen RIBs zu senden.

Die BGP JET-API bgp_route_service.proto enthält ein Objekt mit Peer-Typ, das einzelne Routen entweder als EBGP oder IBGP identifiziert (Standard).

Die Funktion des Routenservers ist im Allgemeinen unabhängig von der Adressfamilie, obwohl bestimmte spezifische BGP-Attributunterstützung adressfamiliesspezifisch sein kann (z. B. wird AIGP nur für Label-Unicast-Adressfamilien unterstützt). Routenserverfunktionen werden für alle EBGP-Adressfamilien unterstützt.

BGP-Attributtransparenz

EBGP-Attributtransparenz [RFC7947] für den Routenserver wird durch Eine Änderung der normalen BGP-Routenausbreitung unterstützt, so dass weder transitive noch nicht transitive Attribute beim Propagieren von Routen entfernt oder geändert werden.

Änderungen am normalen EBGP-Verhalten werden von der route-server-client CLI-Konfiguration gesteuert. Die route-server-client CLI-Konfiguration auf [edit protocols bgp group group-name] Hierarchieebene implementiert das BGP-Attributtransparenzverhalten des Routenservers.

  • Der Route-Server bietet Attributtransparenz sowohl für Single-Hop-EBGP- als auch Für-Multi-Hop-Konfigurationen. Daher umfasst die route-server-client Konfiguration implizit die Funktionalität für no-nexthop-change Single-Hop- und Multi-Hop-Sitzungen. Für Multi-Hop-BGP-Sitzungen müssen Sie das multihop Schlüsselwort konfigurieren.

  • Die route-server-client Konfiguration kann auf der Protokoll-, Gruppen- oder Nachbarebene der [edit protocol bgp] Hierarchie erfolgen.

  • Die route-server-client Konfiguration ist nur anwendbar, wenn der Gruppentyp extern ist. Wenn die route-server-client Konfiguration für interne Gruppen erfolgt, wird beim Commit-Versuch ein Konfigurationsfehler ausgegeben.

  • Die route-server-client Konfiguration hat keine Parameter.

  • Die normale BGP-Berechtigung gilt für die route-server-client Konfiguration.

Anmerkung:

Attribute werden in Bezug auf Attributtransparenz unabhängig gehandhabt. Selbst wenn next-hops nicht unverändert vom Route-Server gesendet werden können, werden andere Attribute transparent gesendet, wie für diese Attribute zutreffend.

Im Folgenden sehen Sie eine Beispielkonfiguration route-server-client :

Nächster Hop

Das Next-Hop-Attribut darf nicht durch das Durchsetzen von Next-Hop-Self oder anderweitige Modifikation des next-hop geändert werden, es sei denn, es wurde explizit über eine Richtlinie konfiguriert. Der Routenserver muss BGP Next-Hops gemäß den Drittanbieter-Next-Hop-Regeln von RFC 4271 weitergeben.

Das Next-Hop-Verhalten wird für die folgenden Route-Server-Szenarien angegeben:

  • Im Fall von LAN- und WAN-Interconnect werden die empfangenen Next-Hops von Drittanbietern vom Routenserver ohne Modifikation gemäß RFC 4271 angekündigt, wenn der Route-Server über ein gemeinsames LAN- und WAN-Subnetz mit Client-Peers verbunden ist.

  • Bei Multihop Interconnect im Datencenter muss EBGP Multihop konfiguriert werden, wenn der Route-Server über eine Multihop-Verbindung mit Client-Peers verbunden ist, und das Verhalten der no-nexthop-change CLI-Konfiguration wird implizit von der route-server-client Konfiguration auferlegt. Die empfangenen Next-Hops von Drittanbietern werden vom Routenserver ohne Änderung gemäß dem optionalen Verhalten von Drittanbietern, definiert in RFC 4271, angekündigt.

  • In anderen Fällen, z. B. Punkt-zu-Punkt-Single-Hop-Verbindungen zwischen dem Route-Server und Client-Peers, werden normale Next-Hop-Werbeverfahren verwendet, um Werbe-Next-Hops zu verhindern, die von BGP-Peers abgelehnt werden könnten (z. B. werden die meisten BGP-Implementierungen standardmäßig Next-Hops-Adressen zurückweisen, die nicht von der Subnetzadresse an Nicht-Multipoint-Sitzungen abgedeckt sind.

AS-Pfad

AS-Path darf nicht geändert werden, indem die lokale AS-Nummer des Route Servers vorab anhängig ist. Die Konfiguration der route-server-client CLI für einen Peer unterdrückt das Prepending der lokalen AS-Nummer in den Anzeigen. Darüber hinaus wird der show route advertising-protocol bgp peer CLI-Befehl für Peers geändert, bei denen es sich um Route-Server-Clients handelt, sodass der lokale AS nicht in den angekündigten Metriken dargestellt wird.

Andere Attribute

  • MULTI_EXIT_DISC Attribut (optional, nicht transitiv) muss nach Empfang weitergegeben werden.

  • Alle Community-Attribute, einschließlich nicht ausgeschriebener, exportfreier und nicht transitiver erweiterter Gemeinden, müssen nach Erhalt weitergegeben werden.

  • Das Accumulated IGP (AIGP)-Attribut (optional, nicht transitiv) muss als empfangen weitergegeben werden.

    Anmerkung:

    Junos OS unterstützt AIGP nur für BGP-LU-Adressfamilien (IPv4 und IPv6).

BGP Route Server Client RIB

Bei einer clientspezifischen ROUTING-RIB handelt es sich um eine eindeutige Ansicht einer BGP-Loc-RIB, die unterschiedliche Routen für das gleiche Ziel als andere Ansichten enthalten kann. Route-Serverclients können durch ihre Peer-Gruppen einer einzelnen clientspezifischen Ansicht oder einer gemeinsamen gemeinsamen RIB zugeordnet werden.

Um die Möglichkeit zu bieten, unterschiedliche Routen für verschiedene Clients für das gleiche Ziel zu werben, ist es konzeptionell notwendig, dass mehrere Instanzen der BGP-Pfadauswahl für das gleiche Ziel, aber in verschiedenen Client-/Gruppenkontexten auftreten können.

Um die hohe Anforderung einer flexiblen Richtlinienkontrolle mit Pfadauswahl pro Client/Gruppe zu implementieren, nutzt der BGP-Routenserver nicht-weiterleitungsbasierte Routinginstanzen (NFIs) für mehrere Instanzen der BGP-Pipeline, einschließlich BGP-Pfadauswahl, Loc-RIB und Richtlinie. Der Route-Server ist so konfiguriert, dass Route-Server-Clients innerhalb von BGP-Gruppen gruppiert werden, die innerhalb separater Routing-Instanzen ohne Weiterleitung konfiguriert sind. Dieser Ansatz nutzt die Tatsache, dass BGP, das in einer Routinginstanz ausgeführt wird, die Pfadauswahl übernimmt und über eine RIB verfügt, die von BGP getrennt ist, die in anderen Routinginstanzen ausgeführt wird.

Richtlinienanforderungen und -überlegungen

Um Routen zwischen Route-Server-Clients weiterzuverbreiten, werden Routen basierend auf konfigurierten Richtlinien zwischen den ROUTING-Instanzen der Routinginstanzen übertragen.

Die Konfiguration des Routenservers für die Richtlinienkontrolle umfasst die folgenden Überlegungen:

  • Route-Server-Clients sollten innerhalb derselben primären Instanz oder Routing-Instanz konfiguriert werden, um dieselbe Loc-RIB-Ansicht zu erhalten.

  • Route-Server-Clients sollten innerhalb ihrer eigenen Routing-Instanz konfiguriert werden, um völlig eindeutige Loc-RIB-Ansichten zu erhalten.

  • Route-Server-Clients sollten in verschiedenen BGP-Peer-Gruppen in derselben Routing-Instanz konfiguriert werden, um unterschiedliche Exportrichtlinien in derselben Loc-RIB-Ansicht zu haben.

  • Damit die clientspezifischen RIB-Ansichten des Routenservers standardmäßig alle Routen von anderen Tabellen empfangen, wird ein Full-Mesh von instance-import Richtlinien mit instance-anykonfiguriert. Bei der Konfiguration instance-import mit Einer Richtlinie mit instance-any:

    • instance-any kann verwendet werden in:

      • policy-statement ... term ... from

      • policy-statement ... from

      • policy-statement ... term ... to

      • policy-statement ... to

    • instance-any hat keine Parameter.

    • Die Verwendung instance-any in anderen Richtlinien hat instance-import keinen Effekt.

  • Die Konfiguration vieler verschiedener Routinginstanzen und Peergruppen wirkt sich auf Skalierbarkeit und Leistung aus.

  • Die BGP-CLI-Konfiguration forwarding-context auf [edit protocols bgp group neighbor] Hierarchieebene unterteilt die Routing-Instanz für einen BGP-Nachbarn in eine Konfigurationsinstanz und eine Weiterleitungsinstanz. Die BGP forwarding-context CLI-Konfiguration unterstützt auch eine Nichtweiterleitungsinstanz mit BGP-Peers, die so konfiguriert sind, dass route-server-client die angegebene Instanz jede Instanz ist, die eine primäre oder eine Routing-Instanz weiterleiten kann, die nicht vom Typ "No-Forwarding" ist.

Release-Verlaufstabelle
Release
Beschreibung
15.1
Ab Junos OS Version 15.1 beseitigt die Anweisung die no-install Interaktion zwischen dem Routing-Protokoll-Daemon (rpd) und anderen Komponenten im Junos-System wie dem Kernel oder dem verteilten Firewall-Daemon (dfwd).
15.1
In Versionen vor Junos OS Version 15.1 können Sie die Arbeitslast auf einem Routenreflektor reduzieren, der sich nicht im Datenverkehrsweiterleitungspfad befindet, indem Sie eine Weiterleitungstabellen-Exportrichtlinie verwenden, die aus BGP gelernte Routen zurückweist.