BGP Routenreflektoren
Grundlegendes zu BGP Routenreflektoren
In diesem Thema wird die Verwendung von BGP-Routenreflektoren zur Vereinfachung der Konfiguration und Unterstützung der Skalierung erläutert.
In einem autonomen BGP-System (AS) müssen die Routen auf alle AS-Border-Router verteilt werden. Das Border Gateway Protocol (BGP) erreicht dies durch interne BGP (IBGP)-Peering-Sitzungen. Standardmäßig werden Routen, die von einem IBGP-Peer gelernt wurden, nicht an andere IBGP-Peers weitergegeben. Diese Einschränkung erfordert ein vollständiges Netz von IBGP-Sitzungen zwischen allen Routern im AS, um eine vollständige Routenvisibilität zu gewährleisten.
Die Aufrechterhaltung eines vollständigen Mesh erhöht jedoch die Konfigurationskomplexität und schränkt die Skalierbarkeit ein. Jeder neue IBGP-Peer muss mit jedem anderen Peer im AS Sitzungen aufbauen. Die Gesamtzahl der Sitzungen, die für ein vollständiges Netz erforderlich sind, wird mit der Formel v * (v - 1)/2 berechnet, wobei v die Anzahl der BGP-Peers darstellt.
Zusätzlich zum Konfigurationsaufwand kann ein Full Mesh die Routenskalierung erhöhen. Jeder IBGP-Peer empfängt alle Routen, auch wenn viele für seinen Standort im Netzwerk suboptimal sind.
Die in RFC 4456 definierte BGP-Routenreflexion adressiert die Skalierbarkeitsherausforderungen von IBGP-Full-Mesh-Topologien. Route Reflection ermöglicht es einem Router, der als Route Reflector (RR) bezeichnet wird, Routen neu zu verteilen, die von einem IBGP-Peer an andere IBGP-Peers gelernt wurden. Dadurch wird die standardmäßige BGP-Regel gelockert, die die IBGP-zu-IBGP-Ankündigung von Routen verhindert.
Da Route Reflection die Möglichkeit von Routing-Schleifen einführt, definiert RFC 4456 zwei neue BGP-Pfadattribute, die Schleifenvermeidung und konsistente Pfadauswahl gewährleisten:
-
ORIGINATOR_ID – Identifiziert die Router-ID des BGP Nachbarn, der die Route ursprünglich angekündigt hat. Das Attribut ORIGINATOR_ID wird nur angehängt, wenn die Route zum ersten Mal gespiegelt wird.
-
CLUSTER_LIST – Zeichnet die Cluster-IDs der Routenreflektoren auf, die die Route bei der Ausbreitung durch das Netzwerk reflektiert haben.
Weitere Informationen dazu, wie diese Attribute die Auswahl des besten BGP-Pfads beeinflussen, finden Sie unter Grundlegendes zur Auswahl des BGP-Pfads.
Aufgrund der Full-Mesh-Anforderungen an interne BGP (IBGP) verwenden die meisten Netzwerke Routenreflektoren, um die Konfiguration zu vereinfachen. Mithilfe eines Routenreflektors werden Router in Cluster gruppiert, die durch numerische Identifikatoren identifiziert werden, die für das autonome System 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 Route Reflection in einem AS zu verwenden, legen Sie einen oder mehrere Router als Routenreflektor fest – in der Regel einen pro Point of Presence (POP). Routenreflektoren haben die Möglichkeit, Routen, die von einem internen Peer erlernt wurden, an andere interne Peers weiterzukommunizieren. Anstatt dass alle internen Peers vollständig miteinander vermascht sein müssen, erfordert die Routenreflexion nur, dass die Routenreflektoren vollständig mit allen internen Peers vermascht sind. Der Routenreflektor und alle seine internen Peers bilden einen Cluster, wie in Abbildung 1 dargestellt.
Für einige Geräte von Juniper Networks muss auf jedem Gerät, das einen Routenreflektor verwendet, eine Advanced BGP Feature-Lizenz installiert sein. Lizenzdetails finden Sie im Handbuch zur Installation und Aktualisierung der Software.
Abbildung 1 zeigt den Router-RR, der als Routenreflektor für Cluster 127 konfiguriert ist. Die anderen Router werden innerhalb des Clusters als interne Peers 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 verknüpfen, indem Sie ein vollständiges Netz von Routenreflektoren konfigurieren (siehe Abbildung 2).
Abbildung 2 zeigt die Routenreflektoren RR 1, RR 2, RR 3 und RR 4 als voll vermaschte interne Peers. Wenn ein Router eine Route an RR 1 ankündigt, kündigt RR 1 die Route den anderen Routenreflektoren erneut an, die wiederum die Route an die verbleibenden Router innerhalb des AS weiterleiten. Route Reflection ermöglicht die Weitergabe der Route im gesamten AS ohne die Skalierungsprobleme, die durch die vollständige Mesh-Anforderung entstehen.
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 Cluster-ID konfigurieren, um die Route zu anderen Clustern widerzuspiegeln.
Ein Client ist ein IBGP-Router, der Routen vom Routenreflektor empfängt. Ein Nicht-Client ist ein weiterer IBGP-Nachbar. Der Routenreflektor zeigt Routen, die von Nicht-Clients gelernt wurden, nur für seine Clients an, nicht für Nicht-Clients. Ein Routenreflektor meldet jedoch Routen, die von Clients gelernt wurden, sowohl Clients als auch Nicht-Clients.
Wenn Cluster jedoch groß werden, wird ein volles Mesh mit einem Routenreflektor schwer zu skalieren, ebenso wie ein volles Mesh zwischen Routenreflektoren. Um dieses Problem auszugleichen, können Sie Router-Cluster für hierarchische Routenreflexion zu Cluster-Clustern gruppieren (siehe Abbildung 3).
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 an RR 2 ankündigt, kündigt RR 2 die Route an alle Router in seinem eigenen Cluster erneut an und kündigt die Route dann 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 nach unten weiter.
Siehe auch
Routenreflektoren ohne Weiterleitung
In vielen Netzwerken werden BGP-Routenreflektoren eingesetzt, um die Skalierbarkeit zu verbessern, sind aber nicht direkt an der Weiterleitung des Datenverkehrs beteiligt. Diese Routenreflektoren behalten die Funktionen der BGP-Steuerungsebene bei, ohne an der Datenweiterleitung beteiligt zu sein. Wenn sich ein Routenreflektor nicht im Datenverkehrspfad befindet, muss er die von ihm reflektierten Routen nicht in seiner Weiterleitungstabelle installieren. Solche Geräte werden als Non-Forwarding Route Reflectors bezeichnet.
Sie können Routenreflektoren ohne Weiterleitung auf eine der folgenden Arten konfigurieren:
-
Mit der
no-installAnweisung – Dieno-installin Junos OS Version 15.1 eingeführte Anweisung verhindert, dass BGP-Routen in der Weiterleitungstabelle installiert werden. Sie können diese Option pro Adressfamilie auf folgender Hierarchieebene konfigurieren:[edit protocols bgp family family-name] set no-install
-
Verwenden einer Exportrichtlinie für Weiterleitungstabellen: In Junos OS-Versionen vor 15.1 können Sie ein ähnliches Verhalten erreichen, indem Sie eine Exportrichtlinie für Weiterleitungstabellen konfigurieren, die von BGP gelernte Routen ablehnt.
Routenreflektoren ohne Weiterleitung tragen dazu bei, die Ressourcenlast auf Geräten zu reduzieren, die in erster Linie als Router der Steuerungsebene dienen, insbesondere in großen Service-Provider-Netzwerken.
Beispiel: Konfigurieren eines Routenreflektors
In diesem Beispiel wird gezeigt, wie ein Routenreflektor konfiguriert wird.
Anforderungen
Vor der Konfiguration dieses Beispiels ist keine spezielle Konfiguration erforderlich, die über die Geräteinitialisierung hinausgeht.
Überblick
Im Allgemeinen müssen interne BGP (IBGP)-fähige Geräte vollständig vermascht sein, da IBGP Updates nicht erneut an andere IBGP-fähige Geräte ankündigt. Das vollständige Netz ist ein logisches Netz, das durch die Konfiguration mehrerer neighbor Anweisungen auf jedem IBGP-fähigen Gerät erreicht wird. Das volle Netz ist nicht unbedingt ein physisches volles Netz. Die Aufrechterhaltung eines vollständigen Mesh (logisch oder physisch) lässt sich in großen Bereitstellungen nicht gut skalieren.
Abbildung 4 zeigt ein IBGP-Netzwerk mit Gerät A als Routenreflektor. 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.
In Junos OS wird jeder Nachbar in einer BGP-Gruppe mit der cluster Anweisung als Client des Routenreflektors behandelt. Gerät D und Gerät E sind keine Clients, da sie in einer BGP-Gruppe auf dem Routenreflektor (Gerät A) platziert werden, die die cluster Anweisung nicht enthält. Um Gerät D und Gerät E zu Routenreflektor-Clients zu machen, verschieben Sie sie in die Gruppe, die rr-clients die cluster Anweisung enthält.
Konfiguration
- Vorgehensweise
- Konfigurieren des Routenreflektors
- Konfigurieren von Client-Peers
- Konfigurieren von Nicht-Client-Peers
Vorgehensweise
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 erforderlichen Details, damit sie mit Ihrer Netzwerkkonfiguration übereinstimmen, und kopieren Sie dann die Befehle und fügen Sie sie in die CLI auf Hierarchieebene [edit] ein.
In diesem Beispiel werden OSPF-gelernte Routen mithilfe der send-ospf Exportrichtlinie in BGP umverteilt:
set protocols bgp group internal-peers export send-ospf
Die Umverteilung von OSPF in BGP ist normalerweise für den Betrieb von Routenreflektoren nicht erforderlich. Es wird hier nur verwendet, um BGP-Routen zu erstellen, die der Routenreflektor seinen Clients mitteilen kann, sodass Sie beobachten können, wie sich die Routenreflexion in einer einfachen Labortopologie verhält.
In einer Produktions-Bereitstellung spiegeln Routenreflektoren in der Regel BGP-Routen wider, die von Clients erlernt wurden, und verteilen IGP-Routen nicht in BGP, es sei denn, dieses Verhalten ist ausdrücklich gewünscht.
In diesem Beispiel sind die Router D und E Nicht-Client-IBGP-Peers und in einem Full-Mesh konfiguriert, um einen konsistenten Routenaustausch außerhalb des Route Reflector-Client-Clusters zu gewährleisten.
Gerät A
set interfaces fe-0/0/0 unit 1 description to-B set interfaces fe-0/0/0 unit 1 family inet address 10.10.10.1/30 set interfaces fe-0/0/1 unit 3 description to-D set interfaces fe-0/0/1 unit 3 family inet address 10.10.10.9/30 set interfaces lo0 unit 1 family inet address 192.168.6.5/32 set protocols bgp group rr-clients type internal set protocols bgp group rr-clients local-address 192.168.6.5 set protocols bgp group rr-clients export send-ospf set protocols bgp group rr-clients neighbor 192.163.6.4 set protocols bgp group rr-clients neighbor 192.168.40.4 set protocols bgp group rr-clients cluster 192.168.6.5 set protocols bgp group non-clients type internal set protocols bgp group non-clients local-address 192.168.6.5 set protocols bgp group non-clients export send-ospf set protocols bgp group non-clients neighbor 192.168.0.1 set protocols bgp group non-clients neighbor 192.168.5.5 set protocols ospf area 0.0.0.0 interface lo0.1 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.1 set protocols ospf area 0.0.0.0 interface fe-0/0/1.3 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.6.5 set routing-options autonomous-system 17
Gerät B
set interfaces fe-0/0/0 unit 2 description to-A set interfaces fe-0/0/0 unit 2 family inet address 10.10.10.2/30 set interfaces fe-0/0/1 unit 5 description to-C set interfaces fe-0/0/1 unit 5 family inet address 10.10.10.5/30 set interfaces lo0 unit 2 family inet address 192.163.6.4/32 set protocols bgp neighbor 192.168.6.5 set protocols bgp group rr-clients type internal set protocols bgp group rr-clients local-address 192.163.6.4 set protocols bgp group rr-clients export send-ospf set protocols bgp group rr-clients neighbor 192.168.6.5 set protocols ospf area 0.0.0.0 interface lo0.2 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.2 set protocols ospf area 0.0.0.0 interface fe-0/0/1.5 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.163.6.4 set routing-options autonomous-system 17
Gerät C
set interfaces fe-0/0/0 unit 6 description to-B set interfaces fe-0/0/0 unit 6 family inet address 10.10.10.6/30 set interfaces lo0 unit 3 family inet address 192.168.40.4/32 set protocols bgp group rr-clients type internal set protocols bgp group rr-clients local-address 192.168.40.4 set protocols bgp group rr-clients export send-ospf set protocols bgp group rr-clients neighbor 192.168.6.5set protocols ospf area 0.0.0.0 interface lo0.3 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.6 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.40.4 set routing-options autonomous-system 17
Gerät D
set interfaces fe-0/0/0 unit 4 description to-A set interfaces fe-0/0/0 unit 4 family inet address 10.10.10.10/30 set interfaces fe-0/0/1 unit 7 description to-E set interfaces fe-0/0/1 unit 7 family inet address 10.10.10.13/30 set interfaces lo0 unit 4 family inet address 192.168.0.1/32 set protocols bgp group non-clients type internal set protocols bgp group non-clients local-address 192.168.0.1 set protocols bgp group non-clients export send-ospf set protocols bgp group non-clients neighbor 192.168.6.5 set protocols bgp group non-clients neighbor 192.168.5.5 set protocols ospf area 0.0.0.0 interface lo0.4 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.4 set protocols ospf area 0.0.0.0 interface fe-0/0/1.7 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.0.1 set routing-options autonomous-system 17
Gerät E
set interfaces fe-0/0/0 unit 8 description to-D set interfaces fe-0/0/0 unit 8 family inet address 10.10.10.14/30 set interfaces lo0 unit 5 family inet address 192.168.5.5/32 set protocols bgp group non-clients type internal set protocols bgp group non-clients local-address 192.168.5.5 set protocols bgp group non-clients export send-ospf set protocols bgp group non-clients neighbor 192.168.0.1 set protocols bgp group non-clients neighbor 192.168.6.5 set protocols ospf area 0.0.0.0 interface lo0.5 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.8 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.5.5 set routing-options autonomous-system 17
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. Informationen zum Navigieren im CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI-Benutzerhandbuch.
So konfigurieren Sie IBGP im Netzwerk mit Juniper Networks Device A als Routenreflektor:
-
Konfigurieren Sie die Schnittstellen.
[edit interfaces] user@A# set fe-0/0/0 unit 1 description to-B user@A# set fe-0/0/0 unit 1 family inet address 10.10.10.1/30 user@A# set fe-0/0/1 unit 3 description to-D user@A# set fe-0/0/1 unit 3 family inet address 10.10.10.9/30 user@A# set lo0 unit 1 family inet address 192.168.6.5/32
-
Konfigurieren Sie die Router-ID und die Nummer des autonomen Systems (AS).
[edit routing-options] user@A# set router-id 192.168.6.5 user@A# set autonomous-system 17
-
Konfigurieren Sie die BGP-Gruppe für Routenreflektor-Clients (Gerät B und Gerät C).
Konfigurieren Sie die Cluster-Anweisung zusammen mit der Cluster-ID, um die Client-Router mit dem Routenreflektor zu einem Cluster hinzuzufügen. Der Cluster-Bezeichner kann ein beliebiger 32-Bit-Wert sein. In diesem Beispiel verwenden wir die Loopback-IP-Adresse als Cluster-ID.
[edit protocols bgp group rr-clients] user@A# set type internal user@A# set local-address 192.168.6.5 user@A# set cluster 192.168.6.5 user@A# set neighbor 192.163.6.4 user@A# set neighbor 192.168.40.4
-
Konfigurieren Sie die interne BGP-Gruppe für Nicht-Client-Peers (Gerät D und Gerät E). Konfigurieren Sie die Cluster-Anweisung nicht so, dass die Nicht-Client-Router außerhalb des Routenreflektor-Clusters bleiben.
[edit protocols bgp group non-clients user@A# set type internal user@A# set local-address 192.168.6.5 user@A# set neighbor 192.168.0.1 user@A# set neighbor 192.168.5.5
-
(Optional) Konfigurieren Sie eine IGP und eine Richtlinie, die IGP-Routen in BGP umverteilt. Beachten Sie, dass dies keine übliche Produktionsanforderung ist, sondern nur in diesem Beispiel konfiguriert ist, um zu zeigen, wie der Routenreflektor in einer einfachen Labortopologie funktioniert.
[edit protocols ospf area 0.0.0.0] user@A# set interface lo0.1 passive user@A# set interface fe-0/0/0.1 user@A# set interface fe-0/0/1.3
[edit policy-options policy-statement send-ospf term 2] user@A# set from protocol ospf user@A# set then accept
user@A# set protocols bgp group rr-clients export send-ospf user@A# set protocols bgp group non-clients export send-ospf
Ergebnisse
Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration durch Eingabe der show interfacesBefehle , show protocols, show policy-optionsund show routing-options . Wenn die Ausgabe nicht die beabsichtigte Konfiguration anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@A# show interfaces
fe-0/0/0 {
unit 1 {
description to-B;
family inet {
address 10.10.10.1/30;
}
}
}
fe-0/0/1 {
unit 3 {
description to-D;
family inet {
address 10.10.10.9/30;
}
}
}
lo0 {
unit 1 {
family inet {
address 192.168.6.5/32;
}
}
}
user@A# show protocols
bgp {
group rr-clients {
type internal;
local-address 192.168.6.5;
export send-ospf;
cluster 192.168.6.5;
neighbor 192.163.6.4;
neighbor 192.168.40.4;
}
group non-clients {
type internal;
local-address 192.168.6.5;
export send-ospf;
neighbor 192.168.0.1;
neighbor 192.168.5.5;
}
ospf {
area 0.0.0.0 {
interface lo0.1 {
passive;
}
interface fe-0/0/0.1;
interface fe-0/0/1.3;
}
}
user@A# show policy-options
policy-statement send-ospf {
term 2 {
from protocol ospf;
then accept;
}
}
user@A# show routing-options router-id 192.168.6.5; autonomous-system 17;
Wenn Sie mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf commit .
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 konsultieren Sie die Anweisungen in der Dokumentation des Geräts.
Konfigurieren von Client-Peers
Schritt-für-Schritt-Anleitung
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren im CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI-Benutzerhandbuch.
So konfigurieren Sie Clientpeers:
-
Konfigurieren Sie die Schnittstellen.
[edit interfaces] user@B# set fe-0/0/0 unit 2 description to-A user@B# set fe-0/0/0 unit 2 family inet address 10.10.10.2/30 user@B# set fe-0/0/1 unit 5 description to-C user@B# set fe-0/0/1 unit 5 family inet address 10.10.10.5/30 user@B# set lo0 unit 2 family inet address 192.163.6.4/32
-
Konfigurieren Sie die Router-ID und die AS-Nummer.
[edit routing-options] user@B# set router-id 192.163.6.4 user@B# set autonomous-system 17
-
Konfigurieren Sie die BGP-Nachbarbeziehung mit dem Routenreflektor.
[edit protocols bgp group rr-clients] user@B# set type internal user@B# set local-address 192.163.6.4 user@B# set neighbor 192.168.6.5
-
(Optional) Konfigurieren Sie eine IGP und eine Richtlinie, die IGP-Routen in BGP umverteilt. Beachten Sie, dass dies keine übliche Produktionsanforderung ist, sondern nur in diesem Beispiel konfiguriert ist, um zu zeigen, wie der Routenreflektor in einer einfachen Labortopologie funktioniert.
[edit protocols ospf area 0.0.0.0] user@B# set interface lo0.2 passive user@B# set interface fe-0/0/0.2 user@B# set interface fe-0/0/1.5
[edit policy-options policy-statement send-ospf term 2] user@B# set from protocol ospf user@B# set then accept
[edit protocols bgp group rr-clients] user@B# set export send-ospf
Ergebnisse
Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration durch Eingabe der show interfacesBefehle , show protocols, show policy-optionsund show routing-options . Wenn die Ausgabe nicht die beabsichtigte Konfiguration anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@B# show interfaces
fe-0/0/0 {
unit 2 {
description to-A;
family inet {
address 10.10.10.2/30;
}
}
}
fe-0/0/1 {
unit 5 {
description to-C;
family inet {
address 10.10.10.5/30;
}
}
}
lo0 {
unit 2 {
family inet {
address 192.163.6.4/32;
}
}
}
user@B# show protocols
bgp {
group rr-clients {
type internal;
local-address 192.163.6.4;
export send-ospf;
neighbor 192.168.6.5;
}
}
ospf {
area 0.0.0.0 {
interface lo0.2 {
passive;
}
interface fe-0/0/0.2;
interface fe-0/0/1.5;
}
}
user@B# show policy-options
policy-statement send-ospf {
term 2 {
from protocol ospf;
then accept;
}
}
user@B# show routing-options router-id 192.163.6.4; autonomous-system 17;
Wenn Sie mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf commit .
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 konsultieren Sie die Anweisungen in der Dokumentation des Geräts.
Konfigurieren von Nicht-Client-Peers
Schritt-für-Schritt-Anleitung
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren im CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI-Benutzerhandbuch.
So konfigurieren Sie Nicht-Client-Peers:
-
Konfigurieren Sie die Schnittstellen.
[edit interfaces] user@D# set fe-0/0/0 unit 4 description to-A user@D# set fe-0/0/0 unit 4 family inet address 10.10.10.10/30 user@D# set fe-0/0/1 unit 7 description to-E user@D# set fe-0/0/1 unit 7 family inet address 10.10.10.13/30 user@D# set lo0 unit 4 family inet address 192.168.0.1/32
-
Konfigurieren Sie die Router-ID und die AS-Nummer.
[edit routing-options] user@D# set router-id 192.168.0.1 user@D# set autonomous-system 17
-
Konfigurieren Sie die BGP-Nachbarbeziehungen mit dem Routenreflektor und mit den anderen Nicht-Client-Peers.
[edit protocols bgp group non-clients] user@D# set type internal user@D# set local-address 192.168.0.1 user@D# set export send-ospf user@D# set neighbor 192.168.6.5 user@D# set neighbor 192.168.5.5
-
(Optional) Konfigurieren Sie eine IGP und eine Richtlinie, die IGP-Routen in BGP umverteilt. Beachten Sie, dass dies keine übliche Produktionsanforderung ist, sondern nur in diesem Beispiel konfiguriert ist, um zu zeigen, wie der Routenreflektor in einer einfachen Labortopologie funktioniert.
[edit protocols ospf area 0.0.0.0] user@D# set interface lo0.4 passive user@D# set interface fe-0/0/0.4 user@D# set interface fe-0/0/1.7
[edit policy-options policy-statement send-ospf term 2] user@D# set from protocol ospf user@D# set then accept
[edit protocols bgp group non-clients] user@D# set export send-ospf
Ergebnisse
Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration durch Eingabe der show interfacesBefehle , show protocols, show policy-optionsund show routing-options . Wenn die Ausgabe nicht die beabsichtigte Konfiguration anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@D# show interfaces
fe-0/0/0 {
unit 4 {
description to-A;
family inet {
address 10.10.10.10/30;
}
}
}
fe-0/0/1 {
unit 7 {
description to-E;
family inet {
address 10.10.10.13/30;
}
}
}
lo0 {
unit 4 {
family inet {
address 192.168.0.1/32;
}
}
}
user@D# show protocols
bgp {
group non-clients {
type internal;
local-address 192.168.0.1;
export send-ospf;
neighbor 192.168.6.5;
neighbor 192.168.5.5;
}
}
ospf {
area 0.0.0.0 {
interface lo0.4 {
passive;
}
interface fe-0/0/0.4;
interface fe-0/0/1.7;
}
}
user@D# show policy-options
policy-statement send-ospf {
term 2 {
from protocol ospf;
then accept;
}
}
user@D# show routing-options router-id 192.168.0.1; autonomous-system 17;
Wenn Sie mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf commit .
Wenn Sie zusätzliche Client- oder Nicht-Client-Peers haben, fügen Sie deren Nachbaranweisungen der entsprechenden BGP-Gruppe hinzu — die Client-Gruppe (mit der cluster Anweisung) oder die Nicht-Client-Gruppe (ohne die cluster Anweisung). Wenn die anderen Geräte nicht von Juniper Networks stammen, finden Sie Anweisungen in der Dokumentation des Geräts.
Verifizierung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
- Überprüfen von BGP-Nachbarn
- Überprüfen von BGP-Gruppen
- Überprüfen der BGP-Zusammenfassungsinformationen
- Überprüfen von Routing-Tabelleninformationen
Überprüfen 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.
Aktion
Geben Sie im Betriebsmodus den show bgp neighbor Befehl ein.
user@A> show bgp neighbor
Peer: 192.163.6.4+179 AS 17 Local: 192.168.6.5+62857 AS 17
Type: Internal State: Established (route reflector client)Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ send-ospf ]
Options: <Preference LocalAddress Cluster Refresh>
Local Address: 192.168.6.5 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.163.6.4 Local ID: 192.168.6.5 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 0
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 17)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 6
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 6
Last traffic (seconds): Received 5 Sent 3 Checked 19
Input messages: Total 2961 Updates 7 Refreshes 0 Octets 56480
Output messages: Total 2945 Updates 6 Refreshes 0 Octets 56235
Output Queue[0]: 0
Peer: 192.168.0.1+179 AS 17 Local: 192.168.6.5+60068 AS 17
Type: Internal State: Established Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ send-ospf ]
Options: <Preference LocalAddress Cluster Refresh>
Local Address: 192.168.6.5 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.168.0.1 Local ID: 192.168.6.5 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 3
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 17)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 6
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 6
Last traffic (seconds): Received 18 Sent 20 Checked 12
Input messages: Total 15 Updates 5 Refreshes 0 Octets 447
Output messages: Total 554 Updates 4 Refreshes 0 Octets 32307
Output Queue[0]: 0
Peer: 192.168.5.5+57458 AS 17 Local: 192.168.6.5+179 AS 17
Type: Internal State: Established )Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ send-ospf ]
Options: <Preference LocalAddress Cluster Refresh>
Local Address: 192.168.6.5 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.168.5.5 Local ID: 192.168.6.5 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 2
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 17)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 7
Accepted prefixes: 7
Suppressed due to damping: 0
Advertised prefixes: 6
Last traffic (seconds): Received 17 Sent 3 Checked 9
Input messages: Total 2967 Updates 7 Refreshes 0 Octets 56629
Output messages: Total 2943 Updates 6 Refreshes 0 Octets 56197
Output Queue[0]: 0
Peer: 192.168.40.4+53990 AS 17 Local: 192.168.6.5+179 AS 17
Type: Internal State: Established (route reflector client)Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ send-ospf ]
Options: <Preference LocalAddress Cluster Refresh>
Local Address: 192.168.6.5 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.168.40.4 Local ID: 192.168.6.5 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 1
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 17)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 7
Accepted prefixes: 7
Suppressed due to damping: 0
Advertised prefixes: 6
Last traffic (seconds): Received 5 Sent 23 Checked 52
Input messages: Total 2960 Updates 7 Refreshes 0 Octets 56496
Output messages: Total 2943 Updates 6 Refreshes 0 Octets 56197
Output Queue[0]: 0
Überprüfen von BGP-Gruppen
Zweck
Stellen Sie sicher, dass die BGP-Gruppen richtig konfiguriert sind.
Aktion
Geben Sie im Betriebsmodus den show bgp group Befehl ein.
user@A> show bgp group Group Type: Internal AS: 17 Local AS: 17 Name: rr-clients Index: 0 Flags: <> Export: [ send-ospf ] Options: <Cluster> Holdtime: 0 Total peers: 2 Established: 4 192.163.6.4+179 192.168.40.4+53990 inet.0: 0/26/16/0 Group Type: Internal AS: 17 Local AS: 17 Name: non-clients Index: 0 Flags: <> Export: [ send-ospf ] Holdtime: 0 Total peers: 2 Established: 4 192.168.0.1+179 192.168.5.5+57458 inet.0: 0/26/16/0 Groups: 2 Peers:4 External: 0 Internal: 4 Down peers: 0 Flaps: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 26 0 0 0 0 0
Überprüfen der BGP-Zusammenfassungsinformationen
Zweck
Stellen Sie sicher, dass die BGP-Konfiguration korrekt ist.
Aktion
Geben Sie im Betriebsmodus den show bgp summary Befehl ein.
user@A> show bgp summary Groups: 2 Peers: 4 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 26 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 192.163.6.4 17 2981 2965 0 0 22:19:15 0/6/1/0 0/0/0/0 192.168.0.1 17 36 575 0 0 13:43 0/6/1/0 0/0/0/0 192.168.5.5 17 2988 2964 0 0 22:19:10 0/7/7/0 0/0/0/0 192.168.40.4 17 2980 2964 0 0 22:19:14 0/7/7/0 0/0/0/0
Überprüfen von Routing-Tabelleninformationen
Zweck
Stellen Sie sicher, dass die Routing-Tabelle die IBGP-Routen enthält.
Aktion
Geben Sie im Betriebsmodus den show route Befehl ein.
user@A> show route
inet.0: 12 destinations, 38 routes (12 active, 0 holddown, 10 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.10.0/30 *[Direct/0] 22:22:03
> via fe-0/0/0.1
[BGP/170] 22:20:55, MED 2, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:51, MED 3, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
10.10.10.1/32 *[Local/0] 22:22:03
Local via fe-0/0/0.1
10.10.10.4/30 *[OSPF/10] 22:21:13, metric 2
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:51, MED 4, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
10.10.10.8/30 *[Direct/0] 22:22:03
> via fe-0/0/1.3
[BGP/170] 22:20:51, MED 2, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:55, MED 3, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
10.10.10.9/32 *[Local/0] 22:22:03
Local via fe-0/0/1.3
10.10.10.12/30 *[OSPF/10] 22:21:08, metric 2
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:55, MED 4, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
192.163.6.4/32 *[OSPF/10] 22:21:13, metric 1
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:55, MED 1, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:51, MED 3, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
192.168.0.1/32 *[OSPF/10] 22:21:08, metric 1
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:51, MED 1, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:55, MED 3, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
192.168.5.5/32 *[OSPF/10] 22:21:08, metric 2
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 00:15:24, MED 1, localpref 100, from 192.168.0.1
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:55, MED 4, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
192.168.6.5/32 *[Direct/0] 22:22:04
> via lo0.1
[BGP/170] 22:20:51, MED 2, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:55, MED 2, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
192.168.40.4/32 *[OSPF/10] 22:21:13, metric 2
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:55, MED 1, localpref 100, from 192.163.6.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:51, MED 4, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
224.0.0.5/32 *[OSPF/10] 22:22:07, metric 1
MultiRecv
Verstehen eines Routenreflektors, der zu zwei verschiedenen Clustern gehört
Der Zweck der Routenreflexion ist die Schleifenverhinderung, wenn die internen BGP (IBGP)-Routing-Geräte nicht vollständig vermascht sind. Um dies zu erreichen, brechen RRs eine der Regeln des normalen BGP-Betriebs: Sie kündigen Routen, die von einem internen BGP-Peer erlernt wurden, an andere interne BGP-Peers an.
Normalerweise ist eine einzelne RR nur Mitglied eines Clusters. Bedenken Sie beispielsweise, dass in einem hierarchischen RR-Design ein Tier-2-RR der Client eines Tier-1-RR sein kann, aber nicht die Clients der anderen.
Wenn jedoch zwei RRs Clients voneinander sind und die Routen von einem Cluster zu einem anderen gespiegelt werden, ist nur eine der Cluster-IDs in der Cluster-Liste enthalten. Dies liegt daran, dass eine Cluster-ID in der Cluster-Liste 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 ausfüllen.
|
Route Reflection-Szenario |
Konfiguration |
|---|---|
|
Bei der Darstellung einer Route von einem der Clients zu einem Nicht-Client-Router client -> RR -> Nicht-Client |
Der Ressourceneintrag füllt die Cluster-ID, die diesem Client in der Cluster-Liste der reflektierten Route zugeordnet ist. |
|
Bei der Darstellung einer Route von einem Nicht-Client-Router zu einem Client-Router non-client -> RR -> client |
Der Ressourceneintrag füllt die Cluster-ID, die diesem Client in der Cluster-Liste 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 (unterschiedliche Cluster) |
Der Ressourceneintrag füllt die Cluster-ID aus, die client1 in der Cluster Liste zugeordnet ist, bevor die Cluster-ID an client2 weitergegeben wird. Die mit Client 2 verknüpfte Cluster-ID wird nicht hinzugefügt. |
|
Bei der Darstellung einer Route von einem Client-Router zu einem Nicht-Client-Router, der sich in einem anderen autonomen System befindet. Wenn Sie beispielsweise eine Ebene 2 RR und 2 BGP-Gruppen 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 (unterschiedliche AS) |
Der Ressourceneintrag füllt die Cluster-Liste nicht mit der Cluster-ID, bevor er die Route zum Nicht-Client-Gerät widerspiegelt, da die Cluster-ID für ein autonomes System spezifisch ist. |
Siehe auch
Beispiel: Konfigurieren eines Routenreflektors, der zu zwei verschiedenen Clustern gehört
In diesem Beispiel wird gezeigt, wie ein Routenreflektor (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 eine RR-Einrichtung, die die Schnittstellen- 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 R3 und Gerät RR2. Dem Routenreflektor RR1 sind zwei verschiedene Cluster-IDs zugewiesen, eine ist 10.13.1.3 für RR1-R3 und 10.12.1.2 für RR1-RR2.
Gerät RR2 ist ein Routenreflektor für Gerät R4.
Betrachten Sie Abbildung 5.
Dieses Beispiel zeigt die BGP-Konfiguration auf Gerät RR1 und Gerät RR2.
Konfiguration
Voraussetzungen
Bevor Sie BGP-Routenreflektoren in mehreren Clustern konfigurieren, stellen Sie sicher, dass die IP-Erreichbarkeit zwischen allen BGP-Peers besteht. In diesem Beispiel bietet ein Interior Gateway Protocol (IGP) wie OSPF oder IS-IS die Erreichbarkeit zwischen den für IBGP-Sitzungen verwendeten Loopback-Schnittstellen. Es wird davon ausgegangen, dass die Schnittstellen- und IGP-Konfiguration vorhanden ist, und wird hier nicht angezeigt.
Vorgehensweise
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 erforderlichen Details, damit sie mit Ihrer Netzwerkkonfiguration übereinstimmen, und kopieren Sie dann die Befehle und fügen Sie sie in die CLI auf Hierarchieebene [edit] ein.
Gerät RR1
set protocols bgp group RR1_client type internal set protocols bgp group RR1_client local-address 192.168.20.1 set protocols bgp group RR1_client cluster 10.13.1.3 set protocols bgp group RR1_client neighbor 192.168.48.1 set protocols bgp group Non_client type internal set protocols bgp group Non_client local-address 192.168.20.1 set protocols bgp group Non_client neighbor 192.168.16.1 set protocols bgp group RR1_to_RR2 type internal set protocols bgp group RR1_to_RR2 local-address 192.168.20.1 set protocols bgp group RR1_to_RR2 cluster 10.12.1.2 set protocols bgp group RR1_to_RR2 neighbor 192.168.40.1
Gerät RR2
set protocols bgp group RR2_client type internal set protocols bgp group RR2_client local-address 192.168.40.1 set protocols bgp group RR2_client cluster 10.24.2.4 set protocols bgp group RR2_client neighbor 192.168.32.1 set protocols bgp group RR2_to_RR1 type internal set protocols bgp group RR2_to_RR1 local-address 192.168.40.1 set protocols bgp group RR2_to_RR1 neighbor 192.168.20.1
Konfiguration von Gerät RR1
Schritt-für-Schritt-Anleitung
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren im CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI-Benutzerhandbuch.
So konfigurieren Sie Gerät RR1:
-
Konfigurieren Sie die Peering-Beziehung mit Gerät R3.
[edit protocols bgp group RR1_client] user@RR1# set type internal user@RR1# set local-address 192.168.20.1 user@RR1# set cluster 10.13.1.3 user@RR1# set neighbor 192.168.48.1
-
Konfigurieren Sie die Peering-Beziehung mit Gerät R0.
[edit protocols bgp group Non_client] user@RR1# set type internal user@RR1# set local-address 192.168.20.1 user@RR1# set neighbor 192.168.16.1
-
Konfigurieren Sie die Peering-Beziehung mit Gerät RR2.
[edit protocols bgp group RR1_to_RR2] user@RR1# set type internal user@RR1# set local-address 192.168.20.1 user@RR1# set cluster 10.12.1.2 user@RR1# set neighbor 192.168.40.1
Ergebnisse
Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration durch Eingabe des show protocols Befehls. Wenn die Ausgabe nicht die beabsichtigte Konfiguration anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@RR1# show protocols
bgp {
group RR1_client {
type internal;
local-address 192.168.20.1;
cluster 10.13.1.3;
neighbor 192.168.48.1;
}
group Non_client {
type internal;
local-address 192.168.20.1;
neighbor 192.168.16.1;
}
group RR1_to_RR2 {
type internal;
local-address 192.168.20.1;
cluster 10.12.1.2;
neighbor 192.168.40.1;
}
}
Wenn Sie mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf commit .
Konfiguration von Gerät RR2
Schritt-für-Schritt-Anleitung
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren im CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI-Benutzerhandbuch.
So konfigurieren Sie Gerät RR2:
-
Konfigurieren Sie die Peering-Beziehung mit Gerät R4.
[edit protocols bgp group RR2_client] user@RR2# set type internal user@RR2# set local-address 192.168.40.1 user@RR2# set cluster 10.24.2.4 user@RR2# set neighbor 192.168.32.1
-
Konfigurieren Sie die Peering-Beziehung mit Gerät RR1.
[edit protocols bgp group RR2_to_RR1] user@RR2# set type internal user@RR2# set local-address 192.168.40.1 user@RR2# set neighbor 192.168.20.1
Ergebnisse
Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration durch Eingabe des show protocols Befehls. Wenn die Ausgabe nicht die beabsichtigte Konfiguration anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@RR2# show protocols
bgp {
group RR2_client {
type internal;
local-address 192.168.40.1;
cluster 10.24.2.4;
neighbor 192.168.32.1;
}
group RR2_to_RR1 {
type internal;
local-address 192.168.40.1;
neighbor 192.168.20.1;
}
}
Wenn Sie mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf commit .
Verifizierung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
- Überprüfen der für Route 10.3.3.3 angekündigten Cluster-ID
- Überprüfen der für Route 10.1.0.1 angekündigten Cluster-ID
Überprüfen der für Route 10.3.3.3 angekündigten Cluster-ID
Zweck
Stellen Sie sicher, dass BGP auf konfigurierten Schnittstellen ausgeführt wird und dass die BGP-Sitzung für jede Nachbaradresse eingerichtet ist.
Aktion
Geben Sie im Betriebsmodus den show route advertising-protocol bgp neighbor-address Befehl ein.
user@RR1> show route advertising-protocol bgp 192.168.40.1 active-path 10.3.3.3 extensive
inet.0: 61 destinations, 61 routes (60 active, 0 holddown, 1 hidden)
* 10.3.3.3/32 (1 entry, 1 announced)
BGP group RR1_to_RR2 type Internal
Nexthop: 192.168.48.1
Localpref: 100
AS path: [100] I
Cluster ID: 10.13.1.3
Originator ID: 192.168.48.1
Bedeutung
Die Route 10.3.3.3/32 stammt vom Client-Peer des Geräts RR1, Gerät R3. Wenn diese Route an den Client von RR1, Gerät RR2, gesendet wird, ist der Route die Cluster-ID 10.13.1.3 zugeordnet, die die Cluster-ID für RR1-R3 ist.
Überprüfen der für Route 10.1.0.1 angekündigten Cluster-ID
Zweck
Überprüfen Sie die Routenankündigung von Gerät RR1 zu Gerät RR2.
Aktion
Geben Sie im Betriebsmodus den show route advertising-protocol bgp neighbor-address Befehl ein.
user@RR1> show route advertising-protocol bgp 192.168.40.1 active-path 10.1.0.1/32 extensive
inet.0: 61 destinations, 61 routes (60 active, 0 holddown, 1 hidden)
* 10.1.0.1/32 (1 entry, 1 announced)
BGP group RR1_to_RR2 type Internal
Nexthop: 192.168.16.1
Localpref: 100
AS path: [100] I
Cluster ID: 10.12.1.2
Originator ID: 192.168.16.1
Bedeutung
Die Route 10.1.0.1/32 stammt vom Nicht-Client-Peer des Geräts RR1, Gerät R0. Wenn diese Route an den Client von RR1, Gerät RR2, gesendet wird, ist der Route die Cluster-ID 10.12.1.2 zugeordnet, die die Cluster-ID für RR1-RR2 ist.
Gerät RR1 behält die eingehende Cluster-ID von Gerät RR2 bei, wenn es an einen anderen Client in einem anderen Cluster (Gerät R4) ankündigt.
Route Reflection an AS Border Routern
In den meisten Bereitstellungen arbeiten BGP-Routenreflektoren ausschließlich als interne BGP-Router (IBGP). In einigen Netzwerkdesigns kann ein Routenreflektor jedoch auch als ASBR (Autonomous System Border Router) fungieren und externe BGP (EBGP)-Peering-Sitzungen unterhalten.
Wenn ein Junos OS-Router beide Rollen ausführt und eine Route von einem EBGP-Peer empfängt, gelten besondere Überlegungen, wenn der Router diese Route mit dieser cluster Option an IBGP-Peers ankündigt, die als Route Reflector-Clients konfiguriert sind. In diesem Fall hängt Junos OS die Attribute ORIGINATOR_ID und CLUSTER_LIST path an, wenn die Route an IBGP-Clients angepasst wird.
RFC 4456, der die BGP-Routenreflexion definiert, spezifiziert nicht explizit das erwartete Verhalten für Routen, die über EBGP gelernt und anschließend von einem ASBR mit zwei Rollen und einem Routenreflektor an IBGP-Clients reflektiert werden. Junos OS wendet Routenreflexionsattribute in diesem Szenario konsistent an, um Routing-Schleifen zu verhindern und die deterministische Pfadauswahl innerhalb des autonomen Systems zu erhalten.
Berücksichtigen Sie bei der Bereitstellung von Routenreflektion auf AS-Border-Routern sorgfältig die Routing-Richtlinien, die Pfadauswahl und Fehlerszenarien, um sicherzustellen, dass reflektierte Routen kein unbeabsichtigtes Routing-Verhalten einführen.
Tabellarischer Änderungsverlauf
Die Unterstützung der Funktion hängt von der Plattform und der Version ab, die Sie benutzen. Verwenden Sie den Feature-Explorer , um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.
no-install Anweisung die Interaktion zwischen dem Routing-Protokoll-Daemon (RPD) und anderen Komponenten im Junos-System, wie dem Kernel oder dem verteilten Firewall-Daemon (DFWD).