BGP-Routenreflektoren
Verstehen von BGP-Routenreflektoren
In diesem Thema wird die Verwendung von Routenreflektoren zur Simplifizierung der Konfiguration und Unterstützung bei der Skalierung erörtert. Eine weitere Möglichkeit, die Arbeitslast auf einem Routenreflektor zu reduzieren, der sich nicht im Datenverkehrsweiterleitungspfad befindet, besteht darin, die no-install Anweisung auf der [edit protocols bgp family family-name] Hierarchieebene zu verwenden. Ab Junos OS Version 15.1 beseitigt die Anweisung die no-install Interaktion zwischen dem Routing-Protokoll-Daemon (rpd) und anderen Komponenten im Junos-System wie dem Kernel oder dem verteilten Firewall-Daemon (dfwd). Diese Interaktion wird dadurch verhindert, dass Routen in den zugehörigen RPD-Routing-Informationsdatenbanken (RIBs), auch bekannt als Routing-Tabellen, für diese Komponenten veröffentlicht werden.
In Versionen vor Junos OS Version 15.1 können Sie die Arbeitslast auf einem Routenreflektor reduzieren, der sich nicht im Datenverkehrsweiterleitungspfad befindet, indem Sie eine Weiterleitungstabellen-Exportrichtlinie verwenden, die aus BGP gelernte Routen zurückweist.
Aufgrund der internen BGP(IBGP)-Full-Mesh-Anforderung verwenden die meisten Netzwerke Routenreflektoren, um die Konfiguration zu vereinfachen. Die Formel zur Berechnung der Anzahl der für ein full mesh erforderlichen Sitzungen lautet v * (v - 1)/2, wobei v die Anzahl der BGP-fähigen Geräte ist. Das Full-Mesh-Modell ist nicht gut skalierbar. Mithilfe eines Routenreflektors gruppieren Sie Router in Cluster, die durch numerische Kennungen identifiziert werden, die für das autonome System (AS) eindeutig sind. Innerhalb des Clusters müssen Sie eine BGP-Sitzung von einem einzelnen Router (dem Routenreflektor) zu jedem internen Peer konfigurieren. Mit dieser Konfiguration wird die IBGP Full-Mesh-Anforderung erfüllt.
Um Routenreflektion in einem AS zu verwenden, bezeichnen Sie einen oder mehrere Router als Routenreflektor – in der Regel einen pro Präsenzpunkt (POP). Routenreflektoren haben die besondere BGP-Fähigkeit, von einem internen Peer gelernte Routen auf andere interne Peers umzuverwenden. Anstatt also zu erfordern, dass alle internen Peers vollständig miteinander vernetzt sind, erfordert die Routenreflektion nur, dass der Routenreflektor vollständig mit allen internen Peers vernetzt ist. Der Routenreflektor und alle internen Peers bilden einen Cluster, wie in Abbildung 1dargestellt.
Für einige Geräte von Juniper Networks muss auf jedem Gerät, das einen Routenreflektor verwendet, eine Erweiterte BGP-Funktionslizenz installiert sein. Lizenzdetails finden Sie im Leitfaden Softwareinstallation und -upgrade.
Abbildung 1 zeigt den Router RR, der als Routenreflektor für Cluster 127 konfiguriert ist. Die anderen Router sind interne Peers innerhalb des Clusters. BGP-Routen werden von einem der internen Peers an Router RR angeboten. RR liest diese Routen dann auf alle anderen Peers innerhalb des Clusters um.
Sie können mehrere Cluster konfigurieren und verknüpfen, indem Sie ein vollständiges Mesh aus Routenreflektoren konfigurieren (siehe Abbildung 2).
Abbildung 2 zeigt die Routenreflektoren RR 1, RR 2, RR 3 und RR 4 als vollständig meshierte interne Peers. Wenn ein Router eine Route zu RR 1 angibt, liest RR 1 die Route auf die anderen Routenreflektoren um, die wiederum die Route auf die verbleibenden Router innerhalb des AS umstellen. Die Routenreflektion ermöglicht die Verbreitung der Route im gesamten AS ohne die Skalierungsprobleme, die durch die Full-Mesh-Anforderung entstehen.
Ein Routenreflektor, der mehrere Cluster unterstützt, akzeptiert keine Route mit derselben Cluster-ID von einem Nicht-Client-Router. Daher müssen Sie eine andere Cluster-ID für eine redundante RR konfigurieren, um die Route zu anderen Clustern widerzuspiegeln.
Wenn Cluster jedoch groß werden, wird es schwierig, ein Full-Mesh mit einem Routenreflektor zu skalieren, ebenso wie ein Full-Mesh zwischen Routenreflektoren. Um dieses Problem auszugleichen, können Sie Cluster von Routern zu Clustern von Clustern gruppieren, um hierarchische Routenreflektion zu ermöglichen (siehe Abbildung 3).
Abbildung 3 zeigt RR 2, RR 3 und RR 4 als Routenreflektoren für Cluster 127, 19 und 45. Anstatt diese Routenreflektoren vollständig zu vermaschen, hat der Netzwerkadministrator sie als Teil eines anderen Clusters (Cluster 6) konfiguriert, für den RR 1 der Routenreflektor ist. Wenn ein Router eine Route zu RR 2 anwirbt, liest RR 2 die Route zu allen Routern innerhalb seines eigenen Clusters um, und revertiert dann die Route auf RR 1. RR 1 liest die Route zu den Routern in seinem Cluster, und diese Router übertragen die Route durch ihre Cluster.
Siehe auch
Beispiel: Konfigurieren eines Routenreflektors
In diesem Beispiel wird die Konfiguration eines Routenreflektors dargestellt.
Anforderungen
Vor der Konfiguration dieses Beispiels ist keine spezielle Konfiguration über die Geräte initialisierung hinaus erforderlich.
Überblick
Im Allgemeinen müssen interne BGP-fähige Geräte (IBGP) vollständig meshfähig sein, da IBGP keine Updates für andere IBGP-fähige Geräte zurückgibt. Das Full-Mesh ist ein logisches Mesh, das durch die Konfiguration mehrerer neighbor Anweisungen auf jedem IBGP-fähigen Gerät erreicht wird. Das Full-Mesh ist nicht unbedingt ein physisches Full-Mesh. Die Verwaltung eines Full-Meshs (logisch oder physisch) ist in großen Bereitstellungen nicht gut skalierbar.
Abbildung 4 zeigt ein IBGP-Netzwerk mit Gerät A, das als Routenreflektor fungiert. Geräte B und Gerät C sind Clients des Routenreflektors. Gerät D und Gerät E befinden sich außerhalb des Clusters, also nichtclients des Routenreflektors.
Auf Gerät A (dem Routenreflektor) müssen Sie Peer-Beziehungen zu allen IBGP-fähigen Geräten aufbauen, indem Sie die Anweisung für die neighbor Clients (Gerät B und Gerät C) und die Nichtclients (Gerät D und Gerät E) einordnen. Sie müssen auch die cluster Anweisung und eine Cluster-Kennung enthalten. Die Cluster-Kennung kann ein beliebiger 32-Bit-Wert sein. In diesem Beispiel wird die IP-Adresse der Loopback-Schnittstelle des Routenreflektors verwendet.
Auf Gerät B und Gerät C, den Routenreflektorclients, benötigen Sie nur eine neighbor Anweisung, die eine Peer-Beziehung mit dem Routenreflektor, Gerät A, bildet.
Auf Gerät D und Gerät E, den Nichtclients, benötigen Sie für jedes Nichtclientgerät (D-to-E und E-to-D) eine neighbor Anweisung. Sie benötigen auch eine neighbor Anweisung für den Routenreflektor (D-to-A und E-to-A). Geräte D und Gerät E benötigen neighbor keine Anweisungen für die Clientgeräte (Gerät B und Gerät C).
Geräte D und Gerät E gelten als Nichtclients, da sie peer-Beziehungen explizit miteinander konfiguriert haben. Um sie zu RRroute-Reflector-Clients zu machen, entfernen Sie die neighbor 192.168.5.5 Anweisung aus der Konfiguration auf Gerät D, und entfernen Sie die neighbor 192.168.0.1 Anweisung aus der Konfiguration auf Gerät E.
Konfiguration
- Verfahren
- Konfigurieren des Routenreflektors
- Konfigurieren von Client-Peers
- Konfigurieren von Nichtclient-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 die Netzwerkkonfiguration erforderlich sind, und kopieren Sie dann die Befehle und fügen Sie sie auf Hierarchieebene in die [edit] CLI ein.
Gerät A
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-Verfahren
Konfigurieren des Routenreflektors
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Cli-Benutzerhandbuch von Junos OS.
So konfigurieren Sie IBGP im Netzwerk mit Gerät A von Juniper Networks als Routenreflektor:
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-Kennungs- und Nachbarbeziehungen mit allen IBGP-fähigen Geräten im autonomen System (AS).
Wenden Sie auch die Richtlinie an, die OSPF-Routen in BGP umverteilt.
[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 in BGP umverteilt.
[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 autonome Systemnummer (AS).
[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 durch Eingabe der show interfacesBefehle , , show protocolsshow policy-optionsundshow routing-options. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
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 die Konfiguration des Geräts durchgeführt haben, geben Sie aus dem Konfigurationsmodus ein commit .
Wiederholen Sie diese Schritte für jeden nichtclient-BGP-Peer innerhalb des Clusters, den Sie konfigurieren, wenn die anderen nichtclient-Geräte von Juniper Networks stammen. Andernfalls erhalten Sie anweisungen in der Dokumentation des Geräts.
Konfigurieren von Client-Peers
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Cli-Benutzerhandbuch von Junos OS.
So konfigurieren Sie Client-Peers:
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
OSPF konfigurieren.
[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 in BGP umverteilt.
[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 durch Eingabe der show interfacesBefehle , , show protocolsshow policy-optionsundshow routing-options. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
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 die Konfiguration des Geräts durchgeführt haben, geben Sie aus dem Konfigurationsmodus ein 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 erhalten Sie anweisungen in der Dokumentation des Geräts.
Konfigurieren von Nichtclient-Peers
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Cli-Benutzerhandbuch von Junos OS.
So konfigurieren Sie Nichtclient-Peers:
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-Reflector und mit den anderen Nichtclient-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
OSPF konfigurieren.
[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 in BGP umverteilt.
[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 durch Eingabe der show interfacesBefehle , , show protocolsshow policy-optionsundshow routing-options. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
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 die Konfiguration des Geräts durchgeführt haben, geben Sie aus dem Konfigurationsmodus ein commit .
Wiederholen Sie diese Schritte für jeden nichtclient-BGP-Peer innerhalb des Clusters, den Sie konfigurieren, wenn die anderen nichtclient-Geräte von Juniper Networks stammen. Andernfalls erhalten Sie anweisungen in der Dokumentation des Geräts.
Überprüfung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
- Überprüfen von BGP-Nachbarn
- Überprüfen von BGP-Gruppen
- Überprüfen der BGP-Zusammenfassungsinformationen
- Überprüfen der Routing-Tabelleninformationen
Überprüfen von BGP-Nachbarn
Zweck
Überprüfen Sie, ob BGP auf konfigurierten Schnittstellen ausgeführt wird und dass die BGP-Sitzung für jede Nachbaradresse eingerichtet wird.
Aktion
Geben Sie im Betriebsmodus den show bgp neighbor Befehl ein.
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]: 0Überprüfen von BGP-Gruppen
Zweck
Vergewissern Sie sich, dass die BGP-Gruppen richtig konfiguriert sind.
Aktion
Geben Sie im Betriebsmodus den show bgp group Befehl ein.
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
Vergewissern Sie sich, dass die BGP-Konfiguration korrekt ist.
Aktion
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 der Routing-Tabelleninformationen
Zweck
Vergewissern Sie sich, dass die Routingtabelle die IBGP-Routen enthält.
Aktion
Geben Sie im Betriebsmodus den show route Befehl ein.
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
MultiRecvVerständnis eines Routenreflektors, der zu zwei verschiedenen Clustern gehört
Der Zweck der Routenreflektion ist die Schleifenverhinderung, wenn die internen BGP-Routinggeräte (IBGP) nicht vollständig meshiert sind. Um dies zu erreichen, brechen RRs eines der Regeln des normalen BGP-Betriebs: Sie können die von einem internen BGP-Peer gelernten Routen auf andere interne BGP-Peers umstellen.
Normalerweise ist ein einzelnes RR Ein Mitglied von nur einem Cluster. Denken Sie beispielsweise daran, dass in einem hierarchischen RR-Design eine RR der Client einer Ebene-1-RR sein kann, aber keine Clients voneinander.
Wenn jedoch zwei RRs Clients voneinander sind und die Routen von einem Cluster zum anderen reflektiert werden, ist nur eine der Cluster-IDs in der Clusterliste enthalten. Dies liegt daran, dass eine Cluster-ID in der Clusterliste für die Schleifenverhinderung in diesem Fall geeignet ist.
Tabelle 1 fasst die Regeln zusammen, die Routenreflektoren beim Ausfüllen der Clusterliste einer reflektierten Route mit Cluster-IDs verwenden.
Routenreflektionsszenario |
Konfiguration |
|---|---|
Wenn eine Route von einem der Clients zu einem Nicht-Client-Router reflektiert wird Client -> RR -> Nicht-Client |
Die RR füllt die dem Client zugeordnete Cluster-ID in der Clusterliste der reflektierten Route aus. |
Wenn eine Route von einem Nicht-Client-Router zu einem Client-Router reflektiert wird Nicht-Client-> RR->-Client |
Die RR füllt die dem Client zugeordnete Cluster-ID in der Clusterliste der reflektierten Route aus. |
Wenn eine Route von einem Client-Router zu einem anderen Client-Router in einem anderen Cluster reflektiert wird client1 -> RR -> client2 (verschiedene Cluster) |
Die RR füllt die dem Client1 zugeordnete Cluster-ID in der Clusterliste aus, bevor die Cluster-ID an client2 angezeigt wird. Die dem Client 2 zugeordnete Cluster-ID wird nicht hinzugefügt. |
Wenn eine Route von einem Client-Router zu einem Nicht-Client-Router in einem anderen autonomen System reflektiert wird. Wenn Sie beispielsweise eine Tier 2-RR- und 2 BGP-Gruppen konfiguriert haben, eine für die RR-Clients und die andere für Ebene 1-RR, und Sie spiegeln eine Route von einem autonomen System zu einem anderen autonomen System wider. Client -> RR -> Nicht-Client (unterschiedliche AS) |
Die RR füllt die Clusterliste nicht mit der Cluster-ID, bevor die Route zum Nicht-Client-Gerät reflektiert wird, da die Cluster-ID spezifisch für ein autonomes System ist. |
Siehe auch
Beispiel: Konfigurieren eines Routenreflektors, der zu zwei verschiedenen Clustern gehört
In diesem Beispiel wird gezeigt, wie ein Routenreflektor (RRs) konfiguriert wird, der zu zwei verschiedenen Clustern gehört. Dies ist kein gängiges Szenario, kann aber in einigen Situationen nützlich sein.
Anforderungen
Konfigurieren Sie die Geräteschnittstellen und ein internes Gateway-Protokoll (IGP). Ein Beispiel für eine RR-Einrichtung, die die Schnittstelle und IGP-Konfiguration umfasst, finden Sie unter Beispiel: Konfigurieren eines Routenreflektors.
Überblick
In diesem Beispiel ist Gerät RR1 ein Routenreflektor für Gerät R2 und Gerät RR2. Der Routenreflektor RR1 hat zwei verschiedene Cluster-IDs zugewiesen, eine ist 5,5,5,5 für RR1-R2 und 6.6.6.6 für RR1-RR2.
Gerät RR2 ist ein Routenreflektor für Gerät R4.
Siehe Abbildung Abbildung 5.
Dieses Beispiel zeigt die BGP-Konfiguration auf Gerät RR1 und Gerät RR2.
Konfiguration
Verfahren
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für die Netzwerkkonfiguration erforderlich sind, und kopieren Sie dann die Befehle und fügen Sie sie auf Hierarchieebene in die [edit] CLI ein.
Gerät RR1
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 5.5.5.5 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 6.6.6.6 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 7.7.7.7 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äte-RR1
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Cli-Benutzerhandbuch von Junos OS.
So konfigurieren Sie Geräte-RR1:
Konfigurieren Sie die Peering-Beziehung mit Gerät R2.
[edit protocols bgp group RR1_client] user@RR1# set type internal user@RR1# set local-address 192.168.20.1 user@RR1# set cluster 5.5.5.5 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 6.6.6.6 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 die beabsichtigte Konfiguration nicht 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 5.5.5.5;
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 6.6.6.6;
neighbor 192.168.40.1;
}
}
Wenn Sie die Konfiguration des Geräts durchgeführt haben, geben Sie aus dem Konfigurationsmodus ein commit .
Konfigurieren von Geräte-RR2
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Cli-Benutzerhandbuch von Junos OS.
So konfigurieren Sie Geräte-RR2:
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 7.7.7.7 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 die beabsichtigte Konfiguration nicht 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 7.7.7.7;
neighbor 192.168.32.1;
}
group RR2_to_RR1 {
type internal;
local-address 192.168.40.1;
neighbor 192.168.20.1;
}
}
Wenn Sie die Konfiguration des Geräts durchgeführt haben, geben Sie aus dem Konfigurationsmodus ein commit .
Überprüfung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
- Überprüfen der für Route 2.2.2.2 angekündigten Cluster-ID
- Überprüfen der für Route 1.1.1.1 angekündigten Cluster-ID
Überprüfen der für Route 2.2.2.2 angekündigten Cluster-ID
Zweck
Überprüfen Sie, ob BGP auf konfigurierten Schnittstellen ausgeführt wird und dass die BGP-Sitzung für jede Nachbaradresse eingerichtet wird.
Aktion
Geben Sie im Betriebsmodus den show route advertising-protocol bgp neighbor-address Befehl ein.
user@RR1> show route advertising-protocol bgp 192.168.40.1 active-path 2.2.2.2 extensive
inet.0: 61 destinations, 61 routes (60 active, 0 holddown, 1 hidden)
* 2.2.2.2/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: 5.5.5.5
Originator ID: 192.168.48.1
Bedeutung
Die 2.2.2.2/32-Route stammt vom Client-Peer des Geräts RR1, Gerät R2. Wenn diese Route an den Client von RR1, Device RR2, gesendet wird, ist auf der Route die 5.5.5.5 Cluster-ID angehängt, die die Cluster-ID für RR1-R2 ist.
Überprüfen der für Route 1.1.1.1 angekündigten Cluster-ID
Zweck
Überprüfen Sie die Route-Anzeige von Gerät RR1 zu Gerät RR2.
Aktion
Geben Sie im Betriebsmodus den show route advertising-protocol bgp neighbor-address Befehl ein.
user@RR1> show route advertising-protocol bgp 192.168.40.1 active-path 1.1.1.1/32 extensive
inet.0: 61 destinations, 61 routes (60 active, 0 holddown, 1 hidden)
* 1.1.1.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: 6.6.6.6
Originator ID: 192.168.16.1Bedeutung
Die Route 1.1.1.1/32 stammt vom Geräte-RR1-Gerät R0, dem Nicht-Client-Peer. Wenn diese Route an den Client von RR1, Gerät RR2, gesendet wird, ist auf der Route die 6.6.6.6 Cluster-ID angehängt, die Die Cluster-ID für RR1-RR2.
Gerät RR1 behält die eingehende Cluster-ID von Gerät RR2 bei der Werbung an einen anderen Client in einem anderen Cluster (Gerät R4) bei.
Verstehen der optimalen BGP-Routenreflektion
Sie können BGP Optimal Route Reflection (BGP-ORR) mit IS-IS und OSPF als Interior Gateway Protocol (IGP) auf einem Routenreflektor konfigurieren, um den besten Pfad zu den BGP-ORR-Clientgruppen zu werben. Dies geschieht mit der kürzesten IGP-Metrik aus der Perspektive eines Clients anstelle der Ansicht des Routenreflektors.
Clientgruppen, die dieselbe oder ähnliche IGP-Topologie nutzen, können als eine BGP-Peergruppe gruppiert werden. Sie können BGP-ORR in dieser BGP-Peer-Gruppe aktivieren optimal-route-reflection . Sie können auch einen der Clientknoten als primären Knoten (igp-primary) in einer BGP-Peergruppe konfigurieren, sodass die IGP-Metrik aus diesem primären Knoten verwendet wird, um den besten Pfad auszuwählen und ihn den Clients in derselben BGP-Peergruppe zu präsentieren. Optional können Sie auch einen anderen Clientknoten als Backup-Knoten (igp-backup) auswählen, der beim Ausfall des primären Knotens (igp-primary) verwendet wird oder nicht erreichbar ist.
Um BGP-ORR zu aktivieren, fügen Sie die optimal-route-reflection Anweisung auf der [edit protocols bgp group group-name] Hierarchieebene ein.
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- oder Layer-2-VPN-, VPLS- oder MVPN- oder EVPN-Szenarien werden die Präfixe über inet.3 aufgelöst. In inet.3 wäre die primäre Route für den Protocol-Next-Hop des Prefix entweder RSVP oder LDP (und nicht ein IGP-Protokoll wie IS-IS oder OSPF). Damit BGP-ORR funktioniert, müssen Sie den Router so konfigurieren, dass er inet.0 für die Routenauflösung von Layer 3-VPN- oder Layer-2-VPN- oder VPLS- oder MVPN- oder EVPN-Präfixen verwendet. Sie können dies über die folgenden Befehle tun:
Für Layer-3-VPN-Präfix:
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 lecken 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 von BGP Optimale Routenreflektion auf einem Routenreflektor zur Anzeige des besten Pfads
Sie können BGP Optimal Route Reflection (BGP-ORR) mit IS-IS und OSPF als Interior Gateway Protocol (IGP) auf einem Routenreflektor konfigurieren, um den besten Pfad zu den BGP-ORR-Clientgruppen zu werben. Dies geschieht mit der kürzesten IGP-Metrik aus der Perspektive eines Clients anstelle der Ansicht des Routenreflektors.
Um BGP-ORR zu aktivieren, fügen Sie die optimal-route-reflection Anweisung auf der [edit protocols bgp group group-name] Hierarchieebene ein.
Clientgruppen, die dieselbe oder ähnliche IGP-Topologie nutzen, können als eine BGP-Peergruppe gruppiert werden. Sie können BGP-ORR in dieser BGP-Peer-Gruppe aktivieren optimal-route-reflection .
So konfigurieren Sie BGP-ORR:
Verwenden Sie die folgenden CLI-Befehle zur Überwachung und Fehlerbehebung der Konfiguration für BGP-ORR:
show bgp group— Anzeige der primären und Backup-Konfigurationen von BGP-ORR.show isis bgp-orr— Anzeige der IS-IS BGP-ORR-Metrik (RIB).show ospf bgp-orr— Anzeige der OSPF BGP-ORR-Metrik (RIB).show ospf route– Anzeigen der Einträge in der OSPF-Routingtabelleshow route— Zeigen Sie die aktiven Einträge in den Routingtabellen an.show route advertising protocol bgp peer— Überprüfen Sie, ob die Routen gemäß den BGP-ORR-Regeln angekündigt werden.
Siehe auch
Überblick über BGP Route Server
Ein BGP-Routenserver ist das externe BGP (EBGP), das einem internen IBGP-Routenreflektor entspricht, der die Anzahl der in einem Netzwerk erforderlichen direkten EBGP-Sitzungen vereinfacht. EBGP-Routenserver sind hinsichtlich der BGP-Attributausbreitung transparent, so dass eine Route, die von einem Routenserver empfangen wird, die Gruppe von BGP-Attributen (NEXT_HOP, AS_PATH, MULTI_EXIT_DISC, AIGP und Communities) transportiert, wenn die Route von einem direkt verbundenen EBGP-Peer stammt.
Wie bei einem IBGP-Routenreflektor wird ein EBGP-Routenserver mithilfe der Routenserverfunktionalität an ein Netzwerk außerhalb des direkten Weiterleitungspfads zwischen den EBGP-Peers angeschlossen. Diese Konnektivität kann über eine direkte physische Verbindung oder über Layer-2-Netzwerke wie VPLS LAN oder EVPN oder über eine IP-Fabric von Punkt-zu-Punkt-EBGP-Verbindungen erfolgen, die die Erreichbarkeit von Loopback-Adressen von Peers bieten (typisch in Rechenzentrumsnetzwerken).
Das BGP-Protokoll wird erweitert, um Route-Server-Funktionen mit den folgenden in RFC 7947 beschriebenen Funktionen bereitzustellen:
Attributtransparenz für NEXT_HOP, AS_PATH, MULTI_EXIT_DISC, AIGP und Communities.
Richtlinienkontrolle pro Client und RiBs mit mehreren Routenservern zur Abwehr von Pfadverstecken.
BGP-Programmierbarkeit nutzt die Route-Server-Funktionalität. Die BGP JET-API bgp_route_service.proto wurde zur Unterstützung der Routenserverfunktionen wie folgt erweitert:
Programmieren Sie den EBGP-Routenserver.
Einfügen von Routen in die spezifische Routingserver-RIB, um sie selektiv an die Clientgruppen in clientspezifischen RIBs zu senden.
Die BGP JET-API bgp_route_service.proto enthält ein Objekt mit Peer-Typ, das einzelne Routen entweder als EBGP oder IBGP identifiziert (Standard).
Die Funktion des Routenservers ist im Allgemeinen unabhängig von der Adressfamilie, obwohl bestimmte spezifische BGP-Attributunterstützung adressfamiliesspezifisch sein kann (z. B. wird AIGP nur für Label-Unicast-Adressfamilien unterstützt). Routenserverfunktionen werden für alle EBGP-Adressfamilien unterstützt.
- BGP-Attributtransparenz
- Nächster Hop
- AS-Pfad
- Andere Attribute
- BGP Route Server Client RIB
- Richtlinienanforderungen und -überlegungen
BGP-Attributtransparenz
EBGP-Attributtransparenz [RFC7947] für den Routenserver wird durch Eine Änderung der normalen BGP-Routenausbreitung unterstützt, so dass weder transitive noch nicht transitive Attribute beim Propagieren von Routen entfernt oder geändert werden.
Änderungen am normalen EBGP-Verhalten werden von der route-server-client CLI-Konfiguration gesteuert. Die route-server-client CLI-Konfiguration auf [edit protocols bgp group group-name] Hierarchieebene implementiert das BGP-Attributtransparenzverhalten des Routenservers.
Der Route-Server bietet Attributtransparenz sowohl für Single-Hop-EBGP- als auch Für-Multi-Hop-Konfigurationen. Daher umfasst die
route-server-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.Die
route-server-clientKonfiguration kann auf der Protokoll-, Gruppen- oder Nachbarebene der [edit protocol bgp] Hierarchie erfolgen.Die
route-server-clientKonfiguration ist nur anwendbar, wenn der Gruppentyp extern ist. Wenn dieroute-server-clientKonfiguration für interne Gruppen erfolgt, wird beim Commit-Versuch ein Konfigurationsfehler ausgegeben.Die
route-server-clientKonfiguration hat keine Parameter.Die normale BGP-Berechtigung gilt für die
route-server-clientKonfiguration.
Attribute werden in Bezug auf Attributtransparenz unabhängig gehandhabt. Selbst wenn next-hops nicht unverändert vom Route-Server gesendet werden können, werden andere Attribute transparent gesendet, wie für diese Attribute zutreffend.
Im Folgenden sehen Sie eine Beispielkonfiguration route-server-client :
[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 durch das Durchsetzen von Next-Hop-Self oder anderweitige Modifikation des next-hop geändert werden, es sei denn, es wurde explizit über eine Richtlinie konfiguriert. Der Routenserver muss BGP Next-Hops gemäß den Drittanbieter-Next-Hop-Regeln von RFC 4271 weitergeben.
Das Next-Hop-Verhalten wird für die folgenden Route-Server-Szenarien angegeben:
Im Fall von LAN- und WAN-Interconnect werden die empfangenen Next-Hops von Drittanbietern vom Routenserver ohne Modifikation gemäß RFC 4271 angekündigt, wenn der Route-Server über ein gemeinsames LAN- und WAN-Subnetz mit Client-Peers verbunden ist.
Bei Multihop Interconnect im Datencenter muss EBGP Multihop konfiguriert werden, wenn der Route-Server über eine Multihop-Verbindung mit Client-Peers verbunden ist, und das Verhalten der
no-nexthop-changeCLI-Konfiguration wird implizit von derroute-server-clientKonfiguration auferlegt. Die empfangenen Next-Hops von Drittanbietern werden vom Routenserver ohne Änderung gemäß dem optionalen Verhalten von Drittanbietern, definiert in RFC 4271, angekündigt.In anderen Fällen, z. B. Punkt-zu-Punkt-Single-Hop-Verbindungen zwischen dem Route-Server und Client-Peers, werden normale Next-Hop-Werbeverfahren verwendet, um Werbe-Next-Hops zu verhindern, die von BGP-Peers abgelehnt werden könnten (z. B. werden die meisten BGP-Implementierungen standardmäßig Next-Hops-Adressen zurückweisen, die nicht von der Subnetzadresse an Nicht-Multipoint-Sitzungen abgedeckt sind.
AS-Pfad
AS-Path darf nicht geändert werden, indem die lokale AS-Nummer des Route Servers vorab anhängig ist. Die Konfiguration der route-server-client CLI für einen Peer unterdrückt das Prepending der lokalen AS-Nummer in den Anzeigen. Darüber hinaus wird der show route advertising-protocol bgp peer CLI-Befehl für Peers geändert, bei denen es sich um Route-Server-Clients handelt, sodass der lokale AS nicht in den angekündigten Metriken dargestellt wird.
Andere Attribute
MULTI_EXIT_DISC Attribut (optional, nicht transitiv) muss nach Empfang weitergegeben werden.
Alle Community-Attribute, einschließlich nicht ausgeschriebener, exportfreier und nicht transitiver erweiterter Gemeinden, müssen nach Erhalt weitergegeben werden.
Das Accumulated IGP (AIGP)-Attribut (optional, nicht transitiv) muss als empfangen weitergegeben werden.
Anmerkung:Junos OS unterstützt AIGP nur für BGP-LU-Adressfamilien (IPv4 und IPv6).
BGP Route Server Client RIB
Bei einer clientspezifischen ROUTING-RIB handelt es sich um eine eindeutige Ansicht einer BGP-Loc-RIB, die unterschiedliche Routen für das gleiche Ziel als andere Ansichten enthalten kann. Route-Serverclients können durch ihre Peer-Gruppen einer einzelnen clientspezifischen Ansicht oder einer gemeinsamen gemeinsamen RIB zugeordnet werden.
Um die Möglichkeit zu bieten, unterschiedliche Routen für verschiedene Clients für das gleiche Ziel zu werben, ist es konzeptionell notwendig, dass mehrere Instanzen der BGP-Pfadauswahl für das gleiche Ziel, aber in verschiedenen Client-/Gruppenkontexten auftreten können.
Um die hohe Anforderung einer flexiblen Richtlinienkontrolle mit Pfadauswahl pro Client/Gruppe zu implementieren, nutzt der BGP-Routenserver nicht-weiterleitungsbasierte Routinginstanzen (NFIs) für mehrere Instanzen der BGP-Pipeline, einschließlich BGP-Pfadauswahl, Loc-RIB und Richtlinie. Der Route-Server ist so konfiguriert, dass Route-Server-Clients innerhalb von BGP-Gruppen gruppiert werden, die innerhalb separater Routing-Instanzen ohne Weiterleitung konfiguriert sind. Dieser Ansatz nutzt die Tatsache, dass BGP, das in einer Routinginstanz ausgeführt wird, die Pfadauswahl übernimmt und über eine RIB verfügt, die von BGP getrennt ist, die in anderen Routinginstanzen ausgeführt wird.
Richtlinienanforderungen und -überlegungen
Um Routen zwischen Route-Server-Clients weiterzuverbreiten, werden Routen basierend auf konfigurierten Richtlinien zwischen den ROUTING-Instanzen der Routinginstanzen übertragen.
Die Konfiguration des Routenservers für die Richtlinienkontrolle umfasst die folgenden Überlegungen:
Route-Server-Clients sollten innerhalb derselben primären Instanz oder Routing-Instanz konfiguriert werden, um dieselbe Loc-RIB-Ansicht zu erhalten.
Route-Server-Clients sollten innerhalb ihrer eigenen Routing-Instanz konfiguriert werden, um völlig eindeutige Loc-RIB-Ansichten zu erhalten.
Route-Server-Clients sollten in verschiedenen BGP-Peer-Gruppen in derselben Routing-Instanz konfiguriert werden, um unterschiedliche Exportrichtlinien in derselben Loc-RIB-Ansicht zu haben.
Damit die clientspezifischen RIB-Ansichten des Routenservers standardmäßig alle Routen von anderen Tabellen empfangen, wird ein Full-Mesh von
instance-importRichtlinien mitinstance-anykonfiguriert. Bei der Konfigurationinstance-importmit Einer Richtlinie mitinstance-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 hatinstance-importkeinen Effekt.
Die Konfiguration vieler verschiedener Routinginstanzen und Peergruppen wirkt sich auf Skalierbarkeit und Leistung aus.
Die BGP-CLI-Konfiguration
forwarding-contextauf [edit protocols bgp group neighbor] Hierarchieebene unterteilt die Routing-Instanz für einen BGP-Nachbarn in eine Konfigurationsinstanz und eine Weiterleitungsinstanz. Die BGPforwarding-contextCLI-Konfiguration unterstützt auch eine Nichtweiterleitungsinstanz mit BGP-Peers, die so konfiguriert sind, dassroute-server-clientdie angegebene Instanz jede Instanz ist, die eine primäre oder eine Routing-Instanz weiterleiten kann, die nicht vom Typ "No-Forwarding" ist.
Siehe auch
no-install Interaktion zwischen dem Routing-Protokoll-Daemon (rpd) und anderen Komponenten im Junos-System wie dem Kernel oder dem verteilten Firewall-Daemon (dfwd).