Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

BGP-Routenreflektoren

Grundlegendes zu BGP-Routenreflektoren

In diesem Thema wird die Verwendung von Routenreflektoren zur Vereinfachung der Konfiguration und zur Unterstützung der Skalierung erläutert. Eine weitere Möglichkeit, die Arbeitsauslastung eines Routenreflektors zu reduzieren, der sich nicht im Traffic-Weiterleitungspfad befindet, besteht darin, die no-install Anweisung auf Hierarchieebene [edit protocols bgp family family-name] zu verwenden. Ab Junos OS Version 15.1 eliminiert die Anweisung die no-install Interaktion zwischen dem Routing-Protokoll-Daemon (RPD) und anderen Komponenten im Junos-System, z. B. dem Kernel oder dem Distributed Firewall Daemon (dfwd). Diese Interaktion wird eliminiert, indem verhindert wird, dass Routen in den zugehörigen rpd-Routing-Informationsbasen (RIBs), die auch als Routing-Tabellen bezeichnet werden, in diesen Komponenten veröffentlicht werden.

HINWEIS:

In Versionen vor Junos OS Version 15.1 können Sie die Arbeitsauslastung eines Routenreflektors, der sich nicht im Datenverkehrsweiterleitungspfad befindet, reduzieren, indem Sie eine Exportrichtlinie für Weiterleitungstabellen verwenden, die von BGP gelernte Routen ablehnt.

Aufgrund der internen BGP-Full-Mesh-Anforderung (IBGP) verwenden die meisten Netzwerke Routenreflektoren, um die Konfiguration zu vereinfachen. Die Formel zur Berechnung der Anzahl der Sitzungen, die für ein vollständiges Netz erforderlich sind, lautet v * (v - 1)/2, wobei v die Anzahl der BGP-fähigen Geräte ist. Das Full-Mesh-Modell lässt sich nicht gut skalieren. 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 die Routenreflexion in einem AS zu verwenden, legen Sie einen oder mehrere Router als Routenreflektor fest – in der Regel einen pro Point of Presence (POP). Routenreflektoren verfügen über die spezielle BGP-Fähigkeit, Routen, die von einem internen Peer gelernt wurden, anderen internen Peers erneut anzukündigen. Anstatt dass also alle internen Peers vollständig miteinander verzahnt sein müssen, erfordert die Routenreflexion lediglich, dass der Routenreflektor vollständig mit allen internen Peers verzahnt ist. Der Routenreflektor und alle seine internen Peers bilden einen Cluster, wie in Abbildung 1gezeigt.

HINWEIS:

Für einige Geräte von Juniper Networks muss auf jedem Gerät, das einen Routenreflektor verwendet, eine Lizenz für erweiterte BGP-Funktionen installiert sein. Weitere Informationen zur Lizenz finden Sie im Softwareinstallations- und Upgrade-Handbuch.

Abbildung 1: Einfache Routenreflektor-Topologie (ein Cluster)Einfache Routenreflektor-Topologie (ein Cluster)

Abbildung 1 zeigt Router RR an, der als Routenreflektor für Cluster 127 konfiguriert ist. Die anderen Router werden als interne Peers innerhalb des Clusters bezeichnet. BGP-Routen werden dem Router RR von einem der internen Peers angekündigt. RR kündigt diese Routen dann allen anderen Peers innerhalb des Clusters erneut an.

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

Abbildung 2: Basic Route Reflection (mehrere Cluster)Basic Route Reflection (mehrere Cluster)

Abbildung 2 zeigt die Routenreflektoren RR 1, RR 2, RR 3 und RR 4 als vollständig vermaschte interne Peers an. Wenn ein Router eine Route zu RR 1 ankündigt, kündigt RR 1 die Route erneut an die anderen Routenreflektoren an, die wiederum die Route an die verbleibenden Router innerhalb des AS erneut ankündigen. Durch die Routenreflexion kann die Route im gesamten AS weitergegeben werden, ohne dass die Skalierungsprobleme auftreten, die durch die Anforderung des vollen Netzes entstehen.

HINWEIS:

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 einen redundanten Ressourceneintrag konfigurieren, um die Route zu anderen Clustern widerzuspiegeln.

Wenn Cluster jedoch größer werden, wird es schwierig, ein vollständiges Netz mit einem Routenreflektor zu skalieren, ebenso wie ein vollständiges Netz zwischen Routenreflektoren. Um dieses Problem auszugleichen, können Sie Router-Cluster zu Clustern von Clustern gruppieren, um eine hierarchische Routenreflexion 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 die Cluster 127, 19 bzw. 45. Anstatt diese Routenreflektoren vollständig zu vernetzen, 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 ankündigt, kündigt RR 2 die Route erneut an alle Router innerhalb seines eigenen Clusters an und kündigt dann die Route erneut an RR 1 an. RR 1 kündigt die Route erneut an die Router in seinem Cluster an, und diese Router geben die Route über ihre Cluster weiter.

Beispiel: Konfigurieren eines Routenreflektors

In diesem Beispiel wird gezeigt, wie ein Routenreflektor konfiguriert wird.

Anforderungen

Über die Geräteinitialisierung hinaus ist keine spezielle Konfiguration erforderlich, bevor Sie dieses Beispiel konfigurieren.

Überblick

Im Allgemeinen müssen interne BGP (IBGP)-fähige Geräte vollständig vernetzt sein, da IBGP keine Updates für andere IBGP-fähige Geräte erneut ankündigt. Das Full Mesh ist ein logisches Mesh, das durch die Konfiguration mehrerer neighbor Anweisungen auf jedem IBGP-fähigen Gerät erreicht wird. Das vollständige Netz ist nicht notwendigerweise ein physisches vollständiges Netz. Die Aufrechterhaltung eines vollständigen Netzes (logisch oder physisch) lässt sich in großen Bereitstellungen nicht gut skalieren.

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

Auf Gerät A (dem Routenreflektor) müssen Sie Peerbeziehungen mit allen IBGP-fähigen Geräten aufbauen, indem Sie die neighbor Anweisung für die Clients (Gerät B und Gerät C) und die Nicht-Clients (Gerät D und Gerät E) einschließen. Sie müssen auch die cluster Anweisung und einen Clusterbezeichner angeben. Der Clusterbezeichner 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 Routenreflektor-Clients, benötigen Sie nur eine neighbor Anweisung, die eine Peerbeziehung mit dem Routenreflektor, Gerät A, bildet.

Auf Gerät D und Gerät E, den Nicht-Clients, benötigen Sie eine neighbor Anweisung für jedes Nicht-Client-Gerät (D-zu-E und E-zu-D). Außerdem benötigen Sie eine neighbor Erklärung für den Routenreflektor (D-zu-A und E-zu-A). Gerät D und Gerät E benötigen neighbor keine Anweisungen für die Clientgeräte (Gerät B und Gerät C).

Tipp:

Gerät D und Gerät E werden als Nicht-Clients betrachtet, da sie explizit Peerbeziehungen 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 Ihre Netzwerkkonfiguration erforderlich sind, und kopieren Sie dann die Befehle und fügen Sie sie in die CLI auf Hierarchieebene [edit] ein.

Gerät A

Gerät B

Gerät C

Gerät D

Gerät E

Schritt-für-Schritt-Anleitung

Konfigurieren des Routenreflektors

Schritt-für-Schritt-Anleitung

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

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-ID und der 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 an BGP weiterverteilt.

  5. Konfigurieren Sie die Router-ID und die AS-Nummer (Autonomous System).

Ergebnisse

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

Wenn Sie mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf commit .

HINWEIS:

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

Konfigurieren von Client-Peers

Schritt-für-Schritt-Anleitung

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

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. Konfigurieren Sie OSPF.

  4. Konfigurieren Sie die Richtlinie, die OSPF-Routen an BGP weiterverteilt.

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

Ergebnisse

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

Wenn Sie mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf commit .

HINWEIS:

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

Konfigurieren von Nicht-Client-Peers

Schritt-für-Schritt-Anleitung

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

So konfigurieren Sie Nicht-Client-Peers:

  1. Konfigurieren Sie die Schnittstellen.

  2. Konfigurieren Sie die BGP-Nachbarbeziehungen mit dem RRroute-Reflektor und mit den anderen Nicht-Client-Peers.

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

  3. Konfigurieren Sie OSPF.

  4. Konfigurieren Sie die Richtlinie, die OSPF-Routen an BGP weiterverteilt.

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

Ergebnisse

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

Wenn Sie mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf commit .

HINWEIS:

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

Verifizierung

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

Verifizieren von BGP-Nachbarn

Zweck

Stellen Sie sicher, dass BGP auf konfigurierten Schnittstellen ausgeführt wird und dass die BGP-Sitzung für jede Nachbaradresse eingerichtet ist.

Action!

Geben Sie im Betriebsmodus den show bgp neighbor Befehl ein.

Verifizieren von BGP-Gruppen

Zweck

Stellen Sie sicher, dass die BGP-Gruppen ordnungsgemäß konfiguriert sind.

Action!

Geben Sie im Betriebsmodus den show bgp group Befehl ein.

Überprüfen der BGP-Zusammenfassungsinformationen

Zweck

Überprüfen Sie, ob die BGP-Konfiguration korrekt ist.

Action!

Geben Sie im Betriebsmodus den show bgp summary Befehl ein.

Überprüfen von Routing-Tabelleninformationen

Zweck

Stellen Sie sicher, dass die Routing-Tabelle die IBGP-Routen enthält.

Action!

Geben Sie im Betriebsmodus den show route Befehl ein.

Grundlegendes zu einem Routenreflektor, der zu zwei verschiedenen Clustern gehört

Der Zweck der Routenreflexion besteht darin, Schleifen zu verhindern, wenn die internen BGP-Routinggeräte (IBGP) nicht vollständig vernetzt sind. Um dies zu erreichen, verstoßen RRs gegen eine der Regeln des normalen BGP-Betriebs: Sie kündigen Routen, die von einem internen BGP-Peer gelernt wurden, anderen internen BGP-Peers erneut an.

Normalerweise ist ein einzelner Ressourcencontroller nur Mitglied eines Clusters. Stellen Sie sich z. B. vor, dass in einem hierarchischen RR-Entwurf ein RR der zweiten Ebene der Client eines RR der Ebene 1 sein kann, aber sie können keine Clients voneinander sein.

Wenn jedoch zwei Ressourceneinträge Clients voneinander sind und die Routen von einem Cluster zu einem anderen widergespiegelt werden, wird nur eine der Cluster-IDs in die Clusterliste aufgenommen. Dies liegt daran, dass eine Cluster-ID in der Clusterliste in diesem Fall für die Schleifenverhinderung ausreicht.

Tabelle 1 Fasst die Regeln zusammen, die Routenreflektoren verwenden, wenn sie die Cluster-Liste einer reflektierten Route mit Cluster-IDs füllen.

Tabelle 1: Regeln für Routenreflektoren

Route Reflection Scenario

Konfiguration

Beim Spiegeln einer Route von einem der Clients zu einem Nicht-Client-Router

client -> RR -> Nicht-Client

Der Ressourceneintrag füllt die Cluster-ID aus, die diesem Client in der Clusterliste der reflektierten Route zugeordnet ist.

Beim Spiegeln einer Route von einem Nicht-Client-Router zu einem Client-Router

non-client -> RR -> client

Der Ressourceneintrag füllt die Cluster-ID aus, die diesem Client in der Clusterliste der reflektierten Route zugeordnet ist.

Beim Spiegeln einer Route von einem Client-Router zu einem anderen Client-Router, der sich in einem anderen Cluster befindet

client1 -> RR -> client2 (anderer Cluster)

Der Ressourceneintrag füllt die Cluster-ID aus, die client1 in der Clusterliste zugeordnet ist, bevor die Cluster-ID client2 zurückgegeben wird. Die Cluster-ID, die Client 2 zugeordnet ist, wird nicht hinzugefügt.

Beim Spiegeln einer Route von einem Client-Router zu einem Nicht-Client-Router, der sich in einem anderen autonomen System befindet.

Beispiel: Wenn Sie eine Tier-2-RR- und 2-BGP-Gruppe konfiguriert haben, eine für die RR-Clients und die andere für Tier-1-RR, und Sie eine Route von einem autonomen System zu einem anderen autonomen System widerspiegeln.

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

Der Ressourceneintrag füllt die Clusterliste nicht mit der Cluster-ID, bevor er die Route zum Nicht-Client-Gerät wiedergibt, 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 Route Reflector (RR)konfiguriert wird, der zu zwei verschiedenen Clustern gehört. Dies ist kein häufiges 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 ein RR-Setup, das die Schnittstelle und die IGP-Konfiguration enthält, finden Sie unter Beispiel: Konfigurieren eines Routenreflektors.

Überblick

In diesem Beispiel ist Gerät RR1 ein Routenreflektor für Gerät R3 und Gerät RR2. Dem Routenreflektor RR1 sind zwei verschiedene Cluster-IDs zugeordnet, eine ist 10.13.1.3 für RR1-R3 und 10.12.1.2 für RR1-RR2.

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

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

Gerät RR1

Gerät RR2

Konfigurieren von Gerät RR1

Schritt-für-Schritt-Anleitung

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

So konfigurieren Sie Gerät RR1:

  1. Konfigurieren Sie die Peeringbeziehung mit Gerät R3.

  2. Konfigurieren Sie die Peeringbeziehung 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 nicht die gewünschte Konfiguration anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Wenn Sie mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf commit .

Konfigurieren des Geräts RR2

Schritt-für-Schritt-Anleitung

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

So konfigurieren Sie Gerät 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 nicht die gewünschte Konfiguration anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Wenn Sie mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf commit .

Verifizierung

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

Überprüfen der für Route 10angekündigten Cluster-ID.3. Sonstiges3. Sonstiges3

Zweck

Stellen Sie sicher, dass BGP auf konfigurierten Schnittstellen ausgeführt wird und dass die BGP-Sitzung für jede Nachbaradresse eingerichtet ist.

Action!

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

Bedeutung

Die 10.3. Sonstiges3. SonstigesDie Route 3/32 stammt vom Clientpeer des Geräts RR1, Gerät R3. Wenn diese Route an den Client von RR1, Device RR2, gesendet wird, hat die Route die 10.13. Der Teufel1. Sonstiges 3 angehängte Cluster-ID, bei der es sich um die Cluster-ID für RR1-R3handelt.

Überprüfen der für Route 10.1angekündigten Cluster-ID.0,1

Zweck

Überprüfen Sie die Routenankündigung von Gerät RR1 zu Gerät RR2.

Action!

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

Bedeutung

Die 10.1.Die Route 0.1/32 stammt vom Nicht-Client-Peer des Geräts RR1, Gerät R0. Wenn diese Route an den Client von RR1, Device RR2, gesendet wird, hat die Route die 10.12. Der Teufel1. Sonstiges 2 angehängte Cluster-ID, bei der es sich um die Cluster-ID für RR1-RR2 handelt.

Gerät RR1 behält die eingehende Cluster-ID von Gerät RR2 bei, wenn es für einen anderen Client in einem anderen Cluster (Gerät R4) angekündigt wird.

Grundlegendes zur BGP Optimal Route Reflection

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 anzukündigen. Dies geschieht, indem die kürzeste IGP-Metrik aus der Perspektive eines Clients anstelle der Ansicht des Routenreflektors verwendet wird.

Client-Gruppen mit derselben oder ähnlicher IGP-Topologie können als eine BGP-Peer-Gruppe gruppiert werden. Sie können die Aktivierung von BGP-ORR in dieser BGP-Peergruppe konfigurieren optimal-route-reflection . Sie können auch einen der Reflektorknoten als primären Knoten (igp-primary) in einer BGP-Peergruppe konfigurieren, sodass die IGP-Metrik dieses primären Knotens verwendet wird, um den besten Pfad auszuwählen und ihn den Clients in derselben BGP-Peergruppe anzukündigen. Optional können Sie auch einen anderen Reflektorknoten als Backup-Knoten (igp-backup) auswählen, der verwendet wird, wenn der primäre Reflektorknoten (igp-primary) ausfällt oder nicht erreichbar ist.

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

HINWEIS:

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.

HINWEIS:

Damit BGP-ORR funktioniert, sollte das BGP-Präfix über IGP aufgelöst werden. In normalen Layer-3-VPN-, Layer-2-VPN- oder VPLS-, 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 nächsten Hop des Präfixes entweder RSVP oder LDP (und kein 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-, Layer-2-VPN- oder VPLS-, MVPN- oder EVPN-Präfixen verwendet. Sie können dies mit den folgenden Befehlen 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 leaken und sie als primäre Route in inet.3 zu machen.

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

Konfigurieren der BGP Optimal Route Reflection auf einem Route Reflector zur Ankündigung 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 anzukündigen. Dies geschieht, indem die kürzeste IGP-Metrik aus der Perspektive eines Clients anstelle der Ansicht des Routenreflektors verwendet wird.

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

Client-Gruppen mit derselben oder ähnlicher IGP-Topologie können als eine BGP-Peer-Gruppe gruppiert werden. Sie können die Aktivierung von BGP-ORR in dieser BGP-Peergruppe konfigurieren optimal-route-reflection .

So konfigurieren Sie BGP-ORR:

  1. Konfigurieren Sie die optimale Routenreflexion.
  2. Konfigurieren Sie einen der Clientknoten als primären Knoten (igp-primary) in einer BGP-Peergruppe, sodass die IGP-Metrik dieses primären Knotens verwendet wird, um den besten Pfad auszuwählen und ihn den Clients in derselben BGP-Peergruppe bekannt zu geben.
  3. (Optional) Konfigurieren Sie einen anderen Clientknoten als Backup-Knoten (igp-backup), der verwendet wird, wenn der primäre Knoten (igp-primary) ausfällt oder nicht erreichbar ist.

Verwenden Sie die folgenden CLI-Befehle, um die Konfiguration für BGP-ORR zu überwachen und Fehler zu beheben:

  • show bgp group: Zeigen Sie die primären und Backup-Konfigurationen von BGP-ORR an.

  • show isis bgp-orr– Zeigen Sie die IS-IS BGP-ORR-Metrik (RIB) an.

  • show ospf bgp-orr– Zeigen Sie die OSPF BGP-ORR-Metrik (RIB) an.

  • show ospf route—Anzeigen der Einträge in der OSPF-Routing-Tabelle

  • show route: Zeigt die aktiven Einträge in den Routing-Tabellen an.

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

BGP Route Server – Übersicht

Ein BGP-Route-Server ist das externe BGP-Äquivalent (EBGP) eines internen IBGP-(IBGP)-Routenreflektors, der die Anzahl der in einem Netzwerk erforderlichen direkten Punkt-zu-Punkt-EBGP-Sitzungen vereinfacht. EBGP-Route-Server sind in Bezug auf die Weitergabe von BGP-Attributen transparent, sodass eine von einem Route-Server empfangene Route den Satz von BGP-Attributen (NEXT_HOP, AS_PATH, MULTI_EXIT_DISC, AIGP und Communities) trägt, wenn die Route von einem direkt verbundenen EBGP-Peer stammt.

Wie bei einem IBGP-Routenreflektor wird ein EBGP-Routenserver mithilfe der Route-Server-Funktionalitä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 ermöglichen (typisch für Datencenter-Netzwerke).

Das BGP-Protokoll wurde erweitert, um Route-Server-Funktionen mit den folgenden in RFC 7947 beschriebenen Funktionalitäten bereitzustellen:

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

  • Clientspezifische Richtliniensteuerung und mehrere Route-Server-RIBs zur Vermeidung von Pfadausblendungen.

Die BGP-Programmierbarkeit nutzt die Route-Server-Funktionalität. Die BGP JET-API bgp_route_service.proto wurde wie folgt erweitert, um die Funktionalität von Routenservern zu unterstützen:

  • Programmieren Sie den EBGP-Routing-Server.

  • Fügen Sie Routen in die spezifische Route-Server-RIB ein, um sie selektiv den Clientgruppen in clientspezifischen RIBs anzukündigen.

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

Die Funktionalität des Routing-Servers ist im Allgemeinen unabhängig von der Adressfamilie, obwohl die Unterstützung bestimmter BGP-Attribute spezifisch für die Adressfamilie sein kann (z. B. wird AIGP nur für Unicast-Adressfamilien mit Bezeichnungen unterstützt). Die Route-Server-Funktionalität wird für alle EBGP-Adressfamilien unterstützt.

BGP-Attributtransparenz

Die EBGP-Attributtransparenz [RFC7947] für den Routing-Server wird unterstützt, indem die normale BGP-Routenweitergabe so geändert wird, dass weder transitive noch nicht-transitive Attribute während der Weitergabe von Routen entfernt oder geändert werden.

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

  • Der Routingserver 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.

  • Sie route-server-client können auf Protokoll-, Gruppen- oder Nachbarebene der [edit protocol bgp]-Hierarchie konfiguriert werden.

  • Die route-server-client Konfiguration ist nur anwendbar, wenn der Gruppentyp . external Wenn die route-server-client für internal Gruppen konfiguriert ist, wird beim Versuch, einen Commit auszuführen, ein Konfigurationsfehler ausgegeben.

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

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

HINWEIS:

Attribute werden in Bezug auf die Attributtransparenz unabhängig behandelt. Auch wenn Next-Hops vom Route-Server nicht unverändert gesendet werden können, werden andere Attribute transparent gesendet, die für diese Attribute gelten.

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

Nächster Hop

Das next-hop-Attribut darf nicht geändert werden, indem next-hop self erzwungen oder der next-hop anderweitig geändert wird, es sei denn, es wird explizit über eine Richtlinie konfiguriert. Der Routingserver muss BGP-Next-Hops gemäß den Next-Hop-Regeln von Drittanbietern in RFC 4271 weitergeben.

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

  • Wenn bei LAN- und WAN-Verbindungen der Routingserver über ein gemeinsam genutztes LAN- und WAN-Subnetz mit Clientpeers verbunden ist, werden die empfangenen Next-Hops von Drittanbietern vom Routingserver ohne Änderung wie in RFC 4271 definiert angekündigt.

  • Wenn im Fall einer Multihop-Verbindung im Datencenter der Route-Server über eine Multihop-Verbindung mit Clientpeers verbunden ist, muss der EBGP-Multihop konfiguriert werden, und das Verhalten der no-nexthop-change CLI-Konfiguration wird implizit durch die route-server-client Konfiguration erzwungen. Die empfangenen Next-Hops von Drittanbietern werden vom Routingserver unverändert gemäß dem optionalen Drittanbieterverhalten, das in RFC 4271 definiert ist, angekündigt.

  • In anderen Fällen, z. B. bei Punkt-zu-Punkt-Single-Hop-Verbindungen zwischen dem Routingserver und Client-Peers, werden normale Next-Hop-Ankündigungsverfahren verwendet, um die Ankündigung von Next-Hops zu verhindern, die von BGP-Peers abgelehnt werden könnten (z. B. lehnen die meisten BGP-Implementierungen standardmäßig Next-Hop-Adressen ab, die nicht von der Subnetzadresse in Nicht-Multipoint-Sitzungen abgedeckt werden.

AS-Pfad

Der AS-Pfad darf nicht geändert werden, indem der lokalen AS-Nummer des Routing-Servers vorangestellt wird. Beim Konfigurieren route-server-client der CLI für einen Peer wird das Vorstellen der lokalen AS-Nummer in den Ankündigungen unterdrückt. Darüber hinaus wird der show route advertising-protocol bgp peer CLI-Befehl für Peers, bei denen es sich um Routingserver-Clients handelt, so geändert, dass der lokale AS nicht in den angekündigten Metriken angezeigt wird.

Andere Attribute

  • MULTI_EXIT_DISC Attribut (optional, nicht transitiv) muss so weitergegeben werden, wie es empfangen wurde.

  • Alle Community-Attribute, einschließlich No-Advertise-, No-Export und Non-Transitive Extended Communities, müssen so weitergegeben werden, wie sie empfangen wurden.

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

    HINWEIS:

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

BGP-Route-Server-Client-RIB

Ein Route-Server-Client-spezifisches RIB ist eine eindeutige Ansicht eines BGP-Loc-RIB, die andere Routen für dasselbe Ziel als andere Ansichten enthalten kann. Routingserverclients können über ihre Peergruppen einer einzelnen clientspezifischen Ansicht oder einem gemeinsam genutzten RIB zugeordnet werden.

Um die Möglichkeit zu bieten, verschiedene Routen für verschiedene Clients für dasselbe Ziel anzukündigen, ist es konzeptionell notwendig, mehrere Instanzen der BGP-Pfadauswahl für dasselbe Ziel, aber in unterschiedlichen Client-/Gruppenkontexten zuzulassen.

Um die übergeordnete Anforderung einer flexiblen Richtliniensteuerung mit Pfadauswahl pro Client/Gruppe zu implementieren, verfolgt der BGP-Routing-Server den Ansatz, NFIs (Non-Forwarding Routing Instances) zu verwenden, um die BGP-Pipeline mit mehreren Instanzen zu versorgen, einschließlich BGP-Pfadauswahl, Loc-RIB und Richtlinie. Der Routing-Server ist so konfiguriert, dass Route-Server-Clients innerhalb von BGP-Gruppen gruppiert werden, die in separaten nicht weiterleitenden Routing-Instanzen konfiguriert sind. Dieser Ansatz macht sich die Tatsache zunutze, dass BGP, das in einer Routinginstanz ausgeführt wird, die Pfadauswahl vornimmt und über ein RIB verfügt, das von BGP getrennt ist, das in anderen Routinginstanzen ausgeführt wird.

Politische Anforderungen und Überlegungen

Um Routen zwischen Routing-Server-Clients weiterzugeben, werden Routen zwischen den RIBs der Routing-Instanzen basierend auf konfigurierten Richtlinien durchgesickert.

Bei der Konfiguration des Routingservers für die Richtliniensteuerung werden die folgenden Überlegungen berücksichtigt:

  • Routing-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.

  • Routing-Server-Clients sollten in verschiedenen BGP-Peergruppen in derselben Routing-Instanz konfiguriert werden, um unterschiedliche Exportrichtlinien für dieselbe Loc-RIB-Ansicht zu haben.

  • Damit die clientspezifischen RIB-Ansichten des Routing-Servers standardmäßig alle Routen aus anderen Tabellen empfangen, wird ein vollständiges Netz von instance-import Richtlinien mit instance-anykonfiguriert. Bei der Konfiguration instance-import mit einer Richtlinie, die Folgendes enthält 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 als instance-import hat keine Auswirkungen.

  • Die Konfiguration vieler unterschiedlicher Routing-Instanzen und Peer-Gruppen wirkt sich auf Skalierung und Leistung aus.

  • Die BGP-CLI-Konfiguration forwarding-context auf der Hierarchieebene [edit protocols bgp group neighbor] teilt die Routing-Instanz für einen BGP-Nachbarn in eine Konfigurationsinstanz und eine Weiterleitungsinstanz auf. Die BGP-CLI-Konfiguration forwarding-context unterstützt auch Nicht-Weiterleitungsinstanzen mit BGP-Peers, die so konfiguriert sind, dass route-server-client die angegebene Instanz eine beliebige Instanz ist, die in der Lage ist, eine primäre Instanz oder eine Routing-Instanz weiterzuleiten, die nicht vom Typ no-forwarding ist.

Tabellarischer Änderungsverlauf

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

Release
Beschreibung
15.1
Ab Junos OS Version 15.1 eliminiert die Anweisung die no-install Interaktion zwischen dem Routing-Protokoll-Daemon (RPD) und anderen Komponenten im Junos-System, z. B. dem Kernel oder dem Distributed Firewall Daemon (dfwd).
15.1
In Versionen vor Junos OS Version 15.1 können Sie die Arbeitsauslastung eines Routenreflektors, der sich nicht im Datenverkehrsweiterleitungspfad befindet, reduzieren, indem Sie eine Exportrichtlinie für Weiterleitungstabellen verwenden, die von BGP gelernte Routen ablehnt.