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.
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.
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 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 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.
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 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.
Siehe auch
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).
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.
Konfiguration
- Verfahren
- Konfigurieren des Routenreflektors
- Konfigurieren von Client-Peers
- Konfigurieren von Nicht-Client-Peers
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
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 internal-peers type internal set protocols bgp group internal-peers local-address 192.168.6.5 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers cluster 192.168.6.5 set protocols bgp group internal-peers neighbor 192.163.6.4 set protocols bgp group internal-peers neighbor 192.168.40.4 set protocols bgp group internal-peers neighbor 192.168.0.1 set protocols bgp group internal-peers 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 group internal-peers type internal set protocols bgp group internal-peers local-address 192.163.6.4 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers 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 internal-peers type internal set protocols bgp group internal-peers local-address 192.168.40.4 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.6.5 set 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 internal-peers type internal set protocols bgp group internal-peers local-address 192.168.0.1 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.6.5 set protocols bgp group internal-peers 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 internal-peers type internal set protocols bgp group internal-peers local-address 192.168.5.5 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.0.1 set protocols bgp group internal-peers 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. 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:
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 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.
[edit protocols bgp group internal-peers] user@A# set type internal user@A# set local-address 192.168.6.5 user@A# set export send-ospf user@A# set cluster 192.168.6.5 user@A# set neighbor192.163.6.4 user@A# set neighbor 192.168.40.4 user@A# set neighbor 192.168.0.1 user@A# set neighbor 192.168.5.5
Konfigurieren Sie statisches Routing oder ein Interior Gateway Protocol (IGP).
In diesem Beispiel wird OSPF verwendet.
[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
Konfigurieren Sie die Richtlinie, die OSPF-Routen an BGP weiterverteilt.
[edit policy-options policy-statement send-ospf term 2] user@A# set from protocol ospf user@A# set then accept
Konfigurieren Sie die Router-ID und die AS-Nummer (Autonomous System).
[edit routing-options] user@A# set router-id 192.168.6.5 user@A# set autonomous-system 17
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.
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 internal-peers {
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;
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 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:
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 BGP-Nachbarbeziehung mit dem Routenreflektor.
Wenden Sie auch die Richtlinie an, die OSPF-Routen in BGP umverteilt.
[edit protocols bgp group internal-peers] user@B# set type internal user@B# set local-address 192.163.6.4 user@B# set export send-ospf user@B# set neighbor 192.168.6.5
Konfigurieren Sie OSPF.
[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
Konfigurieren Sie die Richtlinie, die OSPF-Routen an BGP weiterverteilt.
[edit policy-options policy-statement send-ospf term 2] user@B# set from protocol ospf user@B# set then accept
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
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.
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 internal-peers {
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 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:
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 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.
[edit protocols bgp group internal-peers] 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
Konfigurieren Sie OSPF.
[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
Konfigurieren Sie die Richtlinie, die OSPF-Routen an BGP weiterverteilt.
[edit policy-options policy-statement send-ospf term 2] user@D# set from protocol ospf user@D# set then accept
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
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.
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 internal-peers {
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 .
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
- Verifizieren von BGP-Gruppen
- Überprüfen der BGP-Zusammenfassungsinformationen
- Überprüfen von Routing-Tabelleninformationen
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.
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 (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.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 (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.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]: 0Verifizieren 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.
user@A> show bgp group Group Type: Internal AS: 17 Local AS: 17 Name: internal-peers Index: 0 Flags: <> Export: [ send-ospf ] Options: <Cluster> Holdtime: 0 Total peers: 4 Established: 4 192.163.6.4+179 192.168.40.4+53990 192.168.0.1+179 192.168.5.5+57458 inet.0: 0/26/16/0 Groups: 1 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
Überprüfen Sie, ob die BGP-Konfiguration korrekt ist.
Action!
Geben Sie im Betriebsmodus den show bgp summary Befehl ein.
user@A> show bgp summary Groups: 1 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.
Action!
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
MultiRecvGrundlegendes 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.
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. |
Siehe auch
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.
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
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
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:
-
Konfigurieren Sie die Peeringbeziehung 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 Peeringbeziehung 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, 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.
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 .
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:
-
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, 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.
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
Vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.
- Überprüfen der für Route 10angekündigten Cluster-ID.3. Sonstiges3. Sonstiges3
- Überprüfen der für Route 10.1angekündigten Cluster-ID.0,1
Ü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.
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 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.
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.1Bedeutung
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.
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.
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:
user@host# set routing-options resolution rib bgp.l3vpn.0 resolution-ribs inet.0
-
Für Layer-2-VPN oder VPLS-Präfix:
user@host# set routing-options resolution rib bgp.l2vpn.0 resolution-ribs inet.0
-
Für EVPN-Präfix:
user@host# set routing-options resolution rib bgp.evpn.0 resolution-ribs inet.0
-
Für MVPN-Präfix:
user@host# set routing-options resolution rib bgp.mvpn.0 resolution-ribs inet.0
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:
[edit protocols bgp]
group group-name{
optimal-route-reflection {
igp-primary ipv4-address;
igp-backup ipv4-address;
}
}
Siehe auch
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:
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-Tabelleshow 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.
Siehe auch
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
- Nächster Hop
- AS-Pfad
- Andere Attribute
- BGP-Route-Server-Client-RIB
- Politische Anforderungen und Überlegungen
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-clientKonfiguration implizit die Funktionalität fürno-nexthop-changeSingle-Hop- und Multi-Hop-Sitzungen. Für Multi-Hop-BGP-Sitzungen müssen Sie dasmultihopSchlüsselwort konfigurieren.Sie
route-server-clientkönnen auf Protokoll-, Gruppen- oder Nachbarebene der [edit protocol bgp]-Hierarchie konfiguriert werden.Die
route-server-clientKonfiguration ist nur anwendbar, wenn der Gruppentyp . external Wenn dieroute-server-clientfür internal Gruppen konfiguriert ist, wird beim Versuch, einen Commit auszuführen, ein Konfigurationsfehler ausgegeben.Die
route-server-clientKonfiguration hat keine Parameter.Für die
route-server-clientKonfiguration gilt die normale BGP-Berechtigung.
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 :
[edit]
protocols {
bgp {
group R0 {
type external;
route-server-client;
family inet {
unicast;
}
peer-as 100;
neighbor 10.0.0.1;
}
}
}
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-changeCLI-Konfiguration wird implizit durch dieroute-server-clientKonfiguration 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-importRichtlinien mitinstance-anykonfiguriert. Bei der Konfigurationinstance-importmit einer Richtlinie, die Folgendes enthältinstance-any:instance-anyKann verwendet werden in:policy-statement ... term ... frompolicy-statement ... frompolicy-statement ... term ... topolicy-statement ... to
instance-anyhat keine Parameter.Die Verwendung
instance-anyin anderen Richtlinien alsinstance-importhat keine Auswirkungen.
Die Konfiguration vieler unterschiedlicher Routing-Instanzen und Peer-Gruppen wirkt sich auf Skalierung und Leistung aus.
Die BGP-CLI-Konfiguration
forwarding-contextauf 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-Konfigurationforwarding-contextunterstützt auch Nicht-Weiterleitungsinstanzen mit BGP-Peers, die so konfiguriert sind, dassroute-server-clientdie 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.
Siehe auch
Tabellarischer Änderungsverlauf
Die Unterstützung der Funktion hängt von der Plattform und der Version ab, die Sie benutzen. Verwenden Sie Feature Explorer, um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.
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).