Auf dieser Seite
Beispiel: Anwenden von Routing-Richtlinien auf verschiedenen Ebenen der BGP Hierarchie
Konfigurieren von Routing-Richtlinien zur Steuerung BGP Routenanzeigen
Beispiel: Konfigurieren BGP Prefix-basierter Outbound-Routenfilterung
Verstehen der Standard-BGP-Routing-Richtlinien auf Paketübertragungs-Router (PTX-Serie)
Bedingte Ankündigung zur bedingten Installation von Präfixen und Anwendungsfällen
Bedingte Ankündigung und Importrichtlinie (Routing-Tabelle) mit bestimmten Bedingungen
Impliziter Filter für Standard-EBGP-Routenausbreitung ohne Richtlinien
Grundlegende BGP Routing-Richtlinien
Grundlegende Informationen zu Routing-Richtlinien
Jede Routing-Richtlinie wird mit einem Richtliniennamen identifiziert. Der Name kann Buchstaben, Zahlen und Abstriche (-) enthalten und bis zu 255 Zeichen lang sein. Um Leerzeichen im Namen einschließt, schließen Sie den gesamten Namen in doppelten Anführungszeichen ein. Jeder Name einer Routing-Richtlinie muss in einer Konfiguration eindeutig sein.
Sobald eine Richtlinie erstellt und benannt wurde, muss sie angewendet werden, bevor sie aktiv ist. Sie wenden Routing-Richtlinien mithilfe der import
Anweisungen export
auf der Ebene in protocols protocol-name
der Konfigurationshierarchie an.
In der Anweisung führen Sie den Namen der Routing-Richtlinie auf, die bewertet werden soll, wenn Routen aus dem Routingprotokoll in die import
Routingtabelle importiert werden.
In der Anweisung führen Sie den Namen der Routing-Richtlinie auf, die bewertet werden soll, wenn Routen aus der Routing-Tabelle in ein export
dynamisches Routing-Protokoll exportiert werden. Es werden nur aktive Routen aus der Routing-Tabelle exportiert.
Um mehr als eine Richtlinie zu spezifizieren und eine Richtlinienkette zu erstellen, listen Sie die Richtlinien über einen Raum als Abseparer auf. Wenn mehrere Richtlinien festgelegt werden, werden die Richtlinien in der Reihenfolge bewertet, in der sie angegeben sind. Sobald eine Maßnahme zum Akzeptieren oder Ablehnen ausgeführt wird, endet die Auswertung der Richtlinienkette.
Siehe auch
Beispiel: Anwenden von Routing-Richtlinien auf verschiedenen Ebenen der BGP Hierarchie
In diesem Beispiel BGP Konfigurationen in einer einfachen Netzwerktopologie erläutert, wie sich Routing-Policen bei der Anwendung auf verschiedenen Ebenen der Netzwerkkonfiguration auf BGP ändern.
Anforderungen
Vor der Konfiguration dieses Beispiels ist keine besondere Konfiguration über die Gerätein initialisierung hinaus erforderlich.
Überblick
Für BGP Richtlinien folgendes:
BGP Global und Anweisungen: Geben Sie diese Anweisungen auf der Hierarchieebene an (für Routinginstanzen umfassen diese Anweisungen
import
export
auf der[edit protocols bgp]
[edit routing-instances routing-instance-name protocols bgp]
Hierarchieebene).Gruppe und Anweisungen: Enthalten diese Anweisungen auf der Hierarchieebene (für Routinginstanzen umfassen diese Anweisungen
import
export
auf der[edit protocols bgp group group-name]
[edit routing-instances routing-instance-name protocols bgp group group-name]
Hierarchieebene).Peer
import
und Anweisungen: Enthalten diese Anweisungen auf der Hierarchieebene (für Routinginstanzen umfassen diese Anweisungenexport
auf der[edit protocols bgp group group-name neighbor address]
[edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]
Hierarchieebene).
Eine Peer-Ebene import
oder export
-Anweisung setzt eine Gruppe oder import
Anweisung export
außer Kraft. Eine Gruppenebene oder import
export
-anweisung setzt eine globale BGP import
oder Anweisung export
um.
In diesem Beispiel wird eine richtlinie namens auf der globalen Ebene angewendet, eine andere Richtlinie namens wird auf der Gruppenebene angewendet, und eine dritte Richtlinie namens wird auf der Nachbarebene send-direct
send-192.168.0.1
send-192.168.20.1
angewendet.
user@host# show protocols bgp { local-address 172.16.1.1; export send-direct; group internal-peers { type internal; export send-192.168.0.1; neighbor 172.16.2.2 { export send-192.168.20.1; } neighbor 172.16.3.3; } group other-group { type internal; neighbor 172.16.4.4; } }
Ein wichtiger Punkt, der oft falsch verstanden wird und Probleme verursachen kann, ist, dass in einer solchen Konfiguration nur die explizitste Richtlinie angewendet wird. Eine Richtlinie auf Nachbarebene ist expliziter als eine Richtlinie auf Gruppenebene, die wiederum expliziter ist als eine globale Richtlinie.
Der Nachbar 172.16.2.2 wird nur der Send-192.168.20.1-Richtlinie unterliegen. Der Nachbar 172.16.3.3, bei dem etwas besonderes fehlt, wird nur der Send-192.168.0.1-Richtlinie unterliegen. In der Zwischenzeit verfügt Nachbar 172.16.4.4 in Gruppe anderen Gruppen über keine Richtlinie auf Gruppen- oder Nachbarebene, sodass die Direktrichtlinie verwendet wird.
Wenn Sie für den Nachbar 172.16.2.2 die Funktion aller drei Richtlinien benötigen, können Sie eine neue Richtlinie auf Nachbarebene schreiben und anwenden, die die Funktionen der anderen drei umfasst, oder Sie können alle drei bestehenden Richtlinien als Kette auf das Nachbar-172.16.2.2 anwenden.
Topologie
Abbildung 1 zeigt das Beispielnetzwerk an.

CLI-Konfiguration zeigt die Konfiguration für alle Geräte in Abbildung 1 an.
In diesem #d185e195__d185e448 Abschnitt werden die Schritte auf Gerät R1 beschrieben.
Konfiguration
CLI-Konfiguration
Um dieses Beispiel schnell konfigurieren zu können, kopieren Sie die folgenden Befehle, fügen Sie diese in eine Textdatei ein, entfernen Sie alle Zeilenbrüche, ändern Sie alle Details, die zur Übereinstimmung mit der Netzwerkkonfiguration erforderlich sind, und kopieren Sie die Befehle, und fügen Sie die Befehle CLI der Hierarchieebene [edit]
ein.
Gerät R1
set interfaces fe-1/2/0 unit 0 description to-R2 set interfaces fe-1/2/0 unit 0 family inet address 10.10.10.1/30 set interfaces lo0 unit 0 family inet address 172.16.1.1/32 set protocols bgp local-address 172.16.1.1 set protocols bgp export send-direct set protocols bgp group internal-peers type internal set protocols bgp group internal-peers export send-static-192.168.0 set protocols bgp group internal-peers neighbor 172.16.2.2 export send-static-192.168.20 set protocols bgp group internal-peers neighbor 172.16.3.3 set protocols bgp group other-group type internal set protocols bgp group other-group neighbor 172.16.4.4 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface fe-1/2/0.0 set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set policy-options policy-statement send-static-192.168.0 term 1 from protocol static set policy-options policy-statement send-static-192.168.0 term 1 from route-filter 192.168.0.0/24 orlonger set policy-options policy-statement send-static-192.168.0 term 1 then accept set policy-options policy-statement send-static-192.168.20 term 1 from protocol static set policy-options policy-statement send-static-192.168.20 term 1 from route-filter 192.168.20.0/24 orlonger set policy-options policy-statement send-static-192.168.20 term 1 then accept set routing-options static route 192.168.0.1/32 discard set routing-options static route 192.168.20.1/32 discard set routing-options router-id 172.16.1.1 set routing-options autonomous-system 17
Gerät R2
set interfaces fe-1/2/0 unit 0 description to-R1 set interfaces fe-1/2/0 unit 0 family inet address 10.10.10.2/30 set interfaces fe-1/2/1 unit 0 description to-R3 set interfaces fe-1/2/1 unit 0 family inet address 10.10.10.5/30 set interfaces lo0 unit 0 family inet address 172.16.2.2/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 172.16.2.2 set protocols bgp group internal-peers neighbor 172.16.3.3 set protocols bgp group internal-peers neighbor 172.16.1.1 set protocols bgp group internal-peers neighbor 172.16.4.4 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface fe-1/2/0.0 set protocols ospf area 0.0.0.0 interface fe-1/2/1.0 set routing-options router-id 172.16.2.2 set routing-options autonomous-system 17
Gerät R3
set interfaces fe-1/2/1 unit 0 description to-R2 set interfaces fe-1/2/1 unit 0 family inet address 10.10.10.6/30 set interfaces fe-1/2/2 unit 0 description to-R4 set interfaces fe-1/2/2 unit 0 family inet address 10.10.10.9/30 set interfaces lo0 unit 0 family inet address 172.16.3.3/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 172.16.3.3 set protocols bgp group internal-peers neighbor 172.16.2.2 set protocols bgp group internal-peers neighbor 172.16.1.1 set protocols bgp group internal-peers neighbor 172.16.4.4 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface fe-1/2/1.0 set protocols ospf area 0.0.0.0 interface fe-1/2/2.0 set routing-options router-id 172.16.3.3 set routing-options autonomous-system 17
Gerät R4
set interfaces fe-1/2/2 unit 0 description to-R3 set interfaces fe-1/2/2 unit 0 family inet address 10.10.10.10/30 set interfaces lo0 unit 0 family inet address 172.16.4.4/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 172.16.4.4 set protocols bgp group internal-peers neighbor 172.16.2.2 set protocols bgp group internal-peers neighbor 172.16.1.1 set protocols bgp group internal-peers neighbor 172.16.3.3 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface fe-1/2/2.0 set routing-options router-id 172.16.4.4 set routing-options autonomous-system 17
Verfahren
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zur Navigation in CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI Benutzerhandbuch.
So konfigurieren Sie eine IS-IS Standard-Routenrichtlinie:
Konfigurieren Sie die Geräteschnittstellen.
[edit interfaces] user@R1# set fe-1/2/0 unit 0 description to-R2 user@R1# set fe-1/2/0 unit 0 family inet address 10.10.10.1/30 user@R1# set lo0 unit 0 family inet address 172.16.1.1/32
Aktivieren OSPF oder eines anderen Interior Gateway-Protokolls (IGP) auf den Schnittstellen.
[edit protocols OSPF area 0.0.0.0] user@R1# set interface lo0.0 passive user@R1# set interface fe-1/2/0.0
Konfiguration statischer Routen.
[edit routing-options] user@R1# set static route 192.168.0.1/32 discard user@R1# set static route 192.168.20.1/32 discard
Aktivieren der Routing-Richtlinien.
[edit protocols policy-options] user@R1# set policy-statement send-direct term 1 from protocol direct user@R1# set policy-statement send-direct term 1 then accept user@R1# set policy-statement send-static-192.168.0 term 1 from protocol static user@R1# set policy-statement send-static-192.168.0 term 1 from route-filter 192.168.0.0/24 orlonger user@R1# set policy-statement send-static-192.168.0 term 1 then accept user@R1# set policy-statement send-static-192.168.20 term 1 from protocol static user@R1# set policy-statement send-static-192.168.20 term 1 from route-filter 192.168.20.0/24 orlonger user@R1# set policy-statement send-static-192.168.20 term 1 then accept
Konfigurieren BGP und Anwenden der Exportrichtlinien.
[edit protocols bgp] user@R1# set local-address 172.16.1.1 user@R1# set protocols bgp export send-direct user@R1# set group internal-peers type internal user@R1# set group internal-peers export send-static-192.168.0 user@R1# set group internal-peers neighbor 172.16.2.2 export send-static-192.168.20 user@R1# set group internal-peers neighbor 172.16.3.3 user@R1# set group other-group type internal user@R1# set group other-group neighbor 172.16.4.4
Konfigurieren Sie die Router-ID und die autonome Systemnummer (AS).
[edit routing-options] user@R1# set router-id 172.16.1.1 user@R1# set autonomous-system 17
Wenn Sie die Konfiguration des Geräts bereits durchgeführt haben, commit die Konfiguration.
[edit] user@R1# commit
Ergebnisse
Bestätigen Sie Ihre Konfiguration im Konfigurationsmodus mit der Ausgabe von show interfaces
show protocols
, und show policy-options
show routing-options
Befehlen. Wenn in der Ausgabe nicht die beabsichtigte Konfiguration angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@R1# show interfaces fe-1/2/0 { unit 0 { description to-R2; family inet { address 10.10.10.1/30; } } } lo0 { unit 0 { family inet { address 172.16.1.1/32; } } }
user@R1# show protocols bgp { local-address 172.16.1.1; export send-direct; group internal-peers { type internal; export send-static-192.168.0; neighbor 172.16.2.2 { export send-static-192.168.20; } neighbor 172.16.3.3; } group other-group { type internal; neighbor 172.16.4.4; } } ospf { area 0.0.0.0 { interface lo0.0 { passive; } interface fe-1/2/0.0; } }
user@R1# show policy-options policy-statement send-direct { term 1 { from protocol direct; then accept; } } policy-statement send-static-192.168.0 { term 1 { from { protocol static; route-filter 192.168.0.0/24 orlonger; } then accept; } } policy-statement send-static-192.168.20 { term 1 { from { protocol static; route-filter 192.168.20.0/24 orlonger; } then accept; } }
user@R1# show routing-options static { route 192.168.0.1/32 discard; route 192.168.20.1/32 discard; } router-id 172.16.1.1; autonomous-system 17;
Überprüfung
Stellen Sie sicher, dass die Konfiguration ordnungsgemäß funktioniert.
Überprüfung von BGP Routen-Learning
Zweck
Stellen Sie sicher, dass BGP-Exportrichtlinien wie erwartet funktionieren, indem Sie die Routingtabellen überprüfen.
Aktion
user@R1> show route protocol direct inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.1.1/32 *[Direct/0] 1d 22:19:47 > via lo0.0 10.10.10.0/30 *[Direct/0] 1d 22:19:47 > via fe-1/2/0.0
user@R1> show route protocol static inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.0.1/32 *[Static/5] 02:20:03 Discard 192.168.20.1/32 *[Static/5] 02:20:03 Discard
user@R2> show route protocol bgp inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.20.1/32 *[BGP/170] 02:02:40, localpref 100, from 172.16.1.1 AS path: I, validation-state: unverified > to 10.10.10.1 via fe-1/2/0.0
user@R3> show route protocol bgp inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.0.1/32 *[BGP/170] 02:02:51, localpref 100, from 172.16.1.1 AS path: I, validation-state: unverified > to 10.10.10.5 via fe-1/2/1.0
user@R4> show route protocol bgp inet.0: 9 destinations, 11 routes (9 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.1.1/32 [BGP/170] 1d 20:38:54, localpref 100, from 172.16.1.1 AS path: I, validation-state: unverified > to 10.10.10.9 via fe-1/2/2.0 10.10.10.0/30 [BGP/170] 1d 20:38:54, localpref 100, from 172.16.1.1 AS path: I, validation-state: unverified > to 10.10.10.9 via fe-1/2/2.0
Bedeutung
Auf Gerät R1 zeigt show route protocol direct
der Befehl zwei Direktrouten an: 172.16.1.1/32 und 10.10.10.0/30. Der show route protocol static
Befehl zeigt zwei statische Routen an: 192.168.0.1/32 und 192.168.20.1/32.
Auf Gerät R2 zeigt der Befehl, dass die einzige Route, die Geräte R2 über BGP gelernt hat, die show route protocol bgp
192.168.20.1/32-Route ist.
Auf Gerät R3 zeigt der Befehl, dass die einzige Route, die Geräte R3 über BGP gelernt hat, die show route protocol bgp
192.168.0.1/32-Route ist.
Auf Gerät R4 zeigt der Befehl, dass die einzigen Routen, die Geräte R4 über BGP gelernt show route protocol bgp
hat, die 172.16.1.1/32- und 10.10.10.0/30-Routen sind.
Überprüfung des BGP Route-Empfangs
Zweck
Stellen Sie sicher, dass BGP-Exportrichtlinien wie erwartet funktionieren, indem Sie die Von Gerät R1 empfangenen BGP Routen prüfen.
Aktion
user@R2> show route receive-protocol bgp 172.16.1.1 inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 192.168.20.1/32 172.16.1.1 100 I
user@R3> show route receive-protocol bgp 172.16.1.1 inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 192.168.0.1/32 172.16.1.1 100 I
user@R4> show route receive-protocol bgp 172.16.1.1 inet.0: 9 destinations, 11 routes (9 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 172.16.1.1/32 172.16.1.1 100 I 10.10.10.0/30 172.16.1.1 100 I
Bedeutung
Auf Gerät R2 zeigt der Befehl, dass Gerät R2 nur eine route receive-protocol bgp 172.16.1.1
BGP-Route, 192.168.20.1/32, von Gerät R1 empfangen hat.
Auf Gerät R3 zeigt der Befehl, dass Gerät R3 nur eine route receive-protocol bgp 172.16.1.1
BGP-Route, 192.168.0.1/32, von Gerät R1 empfangen hat.
Auf Gerät R4 zeigt der Befehl, dass Gerät R4 zwei route receive-protocol bgp 172.16.1.1
BGP-Routen, 172.16.1.1/32 und 10.10.10.0/30, vom Gerät R1, empfangen hat.
Wenn mehrere Richtlinien in unterschiedlichen Hierarchien CLI in BGP werden nur die spezifischere Anwendung ausgewertet, unter Ausschluss anderer, weniger spezifischer Richtlinienanwendungen. Obwohl dieser Punkt sinnvoll erscheinen mag, wird er bei der Routerkonfiguration leicht vergessen, wenn Sie falscherweise der Meinung sind, dass eine Richtlinie auf Nachbarebene mit einer globalen oder gruppenbasierten Richtlinie kombiniert wird, nur um dann herauszufinden, dass Ihr Richtlinienverhalten nicht wie erwartet erwartet ist.
Beispiel: Einfing OSPF Routen in die BGP Routing-Tabelle
In diesem Beispiel wird dargestellt, wie eine Richtlinie erstellt wird, die OSPF in die Routing BGP tabelle einleitiert.
Anforderungen
Bevor Sie beginnen:
Konfigurieren Sie Netzwerkschnittstellen.
Konfigurieren Sie externe Peer-Sitzungen. Siehe Beispiel: Konfigurieren externer BGP Point-to-Point-Peer-Sitzungen.
Konfigurieren Sie Interior Gateway Protocol (IGP)-Sitzungen zwischen Peers.
Überblick
In diesem Beispiel erstellen Sie eine Routing-Richtlinie namens injectpolicy1
und einen Routing-Begriff namens injectterm1
. Die Richtlinie fügt OSPF in die Routing-Tabelle BGP.
Topologie
Konfiguration
Konfigurieren der Routing-Richtlinie
CLI-Konfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenbrüche, ändern Sie alle details, die zur Übereinstimmung mit Ihrer Netzwerkkonfiguration erforderlich sind, kopieren Sie die Befehle, und fügen Sie die Befehle in die CLI-Hierarchieebene ein und geben Sie sie dann im Konfigurationsmodus commit
ein.
set policy-options policy-statement injectpolicy1 term injectterm1 from protocol ospf set policy-options policy-statement injectpolicy1 term injectterm1 from area 0.0.0.1 set policy-options policy-statement injectpolicy1 term injectterm1 then accept set protocols bgp export injectpolicy1
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zur Navigation auf der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI Benutzerhandbuch.
So in OSPF Routen in eine Routing BGP Routing-Tabelle ein:
Richtlinienbegriff erstellen.
[edit policy-options policy-statement injectpolicy1] user@host# set term injectterm1
Geben OSPF als Übereinstimmungsbedingung an.
[edit policy-options policy-statement injectpolicy1 term injectterm1] user@host# set from protocol ospf
Geben Sie die Routen aus einem OSPF-Bereich als Übereinstimmungsbedingung an.
[edit policy-options policy-statement injectpolicy1 term injectterm1] user@host# set from area 0.0.0.1
Geben Sie an, dass der Route akzeptiert werden soll, wenn die vorherigen Bedingungen übereinstimmen.
[edit policy-options policy-statement injectpolicy1 term injectterm1] user@host# set then accept
Wenden Sie die Routing-Richtlinie auf BGP.
[edit] user@host# set protocols bgp export injectpolicy1
Ergebnisse
Bestätigung Ihrer Konfiguration durch Eingabe der Befehle show policy-options
im show protocols bgp
Konfigurationsmodus Wenn in der Ausgabe nicht die beabsichtigte Konfiguration angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@host# show policy-options policy-statement injectpolicy1 { term injectterm1 { from { protocol ospf; area 0.0.0.1; } then accept; } }
user@host# show protocols bgp export injectpolicy1;
Wenn Sie die Konfiguration des Geräts erledigt haben, geben Sie commit
den Konfigurationsmodus ein.
Konfigurieren von Ablaufverfolgung für die Routing-Richtlinie
CLI-Konfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenbrüche, ändern Sie alle details, die zur Übereinstimmung mit Ihrer Netzwerkkonfiguration erforderlich sind, kopieren Sie die Befehle, und fügen Sie die Befehle in die CLI-Hierarchieebene ein und geben Sie sie dann im Konfigurationsmodus commit
ein.
set policy-options policy-statement injectpolicy1 term injectterm1 then trace set routing-options traceoptions file ospf-bgp-policy-log set routing-options traceoptions file size 5m set routing-options traceoptions file files 5 set routing-options traceoptions flag policy
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zur Navigation auf der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI Benutzerhandbuch.
Fügen Sie eine Trace-Aktion in die Richtlinie ein.
[edit policy-options policy-statement injectpolicy1 term injectterm1] user@host# then trace
Konfigurieren Sie die Ablaufverfolgungsdatei für die Ausgabe.
[edit routing-options traceoptions] user@host# set file ospf-bgp-policy-log user@host# set file size 5m user@host# set file files 5 user@host# set flag policy
Ergebnisse
Bestätigung Ihrer Konfiguration durch Eingabe der Befehle show policy-options
im show routing-options
Konfigurationsmodus Wenn in der Ausgabe nicht die beabsichtigte Konfiguration angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@host# show policy-options policy-statement injectpolicy1 { term injectterm1 { then { trace; } } }
user@host# show routing-options traceoptions { file ospf-bgp-policy-log size 5m files 5; flag policy; }
Wenn Sie die Konfiguration des Geräts bereits durchgeführt haben, geben Sie commit
sie im Konfigurationsmodus ein.
Überprüfung
Fehlerbehebung
Verwenden des "show log Command" zur Untersuchung der Aktionen der Routingrichtlinie
Problem
Die Routingtabelle enthält unerwartete Routen oder Routen, die in der Routingtabelle fehlen.
Lösung
Wenn Sie die in diesem Beispiel dargestellte Richtlinienverfolgung konfigurieren, können Sie den Befehl ausführen, um Probleme mit der show log ospf-bgp-policy-log
Routing-Richtlinie zu diagnostizieren. Der show log ospf-bgp-policy-log
Befehl zeigt Informationen zu den Routen an, auf die der injectpolicy1
Richtlinienbegriff analysiert und agiert.
Konfigurieren von Routing-Richtlinien zur Steuerung BGP Routenanzeigen
Alle Routing-Protokolle verwenden die Junos OS Routing-Tabelle zum Speichern der von ihnen erlernten Routen und zur Ermittlung der Routen, die sie in ihren Protokollpaketen anzeigen sollten. Mit der Routing-Richtlinie können Sie steuern, welche Routen die Routingprotokolle speichern und aus der Routingtabelle abrufen. Informationen zur Routing-Richtlinie finden Sie im Benutzerhandbuch für Routing-Richtlinien, Firewall-Filter und Datenverkehrsrichtlinien.
Bei der Konfiguration BGP Routing-Richtlinie können Sie die folgenden Aufgaben ausführen:
- Anwenden der Routing-Richtlinie
- Einstellung BGP zur Ankündigung inaktiver Routen
- Konfiguration BGP, um die beste externe Route zu internen Peers zu werben
- Konfigurieren, wie oft BGP Routen mit der Routingtabelle austauscht
- Deaktivierung der Routenunterdrückung
Anwenden der Routing-Richtlinie
Sie definieren Routing-Richtlinien auf [edit policy-options]
der Hierarchieebene. Um Richtlinien anzuwenden, die Sie für BGP definiert haben, fügen Sie die import
export
Anweisungen und Anweisungen in der BGP- konfiguration ein.
Sie können folgende Richtlinien anwenden:
BGP Global und Anweisungen: Geben Sie diese Anweisungen auf der Hierarchieebene an (für Routinginstanzen umfassen diese Anweisungen
import
export
auf der[edit protocols bgp]
[edit routing-instances routing-instance-name protocols bgp]
Hierarchieebene).Gruppe und Anweisungen: Enthalten diese Anweisungen auf der Hierarchieebene (für Routinginstanzen umfassen diese Anweisungen
import
export
auf der[edit protocols bgp group group-name]
[edit routing-instances routing-instance-name protocols bgp group group-name]
Hierarchieebene).Peer
import
und Anweisungen: Enthalten diese Anweisungen auf der Hierarchieebene (für Routinginstanzen umfassen diese Anweisungenexport
auf der[edit protocols bgp group group-name neighbor address]
[edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]
Hierarchieebene).
Eine Peer-Ebene import
oder export
-Anweisung setzt eine Gruppe oder import
Anweisung export
außer Kraft. Eine Gruppenebene oder import
export
-anweisung setzt eine globale BGP import
oder Anweisung export
um.
Die Anwendung von Richtlinien finden Sie in den folgenden Abschnitten:
- Anwenden von Richtlinien auf Routen, die in die Routing-Tabelle von BGP
- Anwenden von Richtlinien auf Routen, die aus der Routingtabelle in ein Routing-BGP
Anwenden von Richtlinien auf Routen, die in die Routing-Tabelle von BGP
Um die Richtlinie auf Routen anzuwenden, die in die Routingtabelle von BGP importieren, fügen Sie die Anweisung und die Namen einer oder mehrere zu bewertende Richtlinien import
ein:
import [ policy-names ];
Eine Liste von Hierarchieebenen, in denen Sie diese Aussage enthalten können, finden Sie im Abschnitt "Statement Summary" in dieser Anweisung.
Wenn Sie mehrere Richtlinien angeben, werden diese in der angegebenen Reihenfolge zuerst bis zuletzt ausgewertet, und der erste übereinstimmende Filter wird auf die Route angewendet. Wenn keine Übereinstimmung gefunden wurde, BGP nur die Routen in die Routingtabelle ein, die von den Routing BGP gelernt wurden.
Anwenden von Richtlinien auf Routen, die aus der Routingtabelle in ein Routing-BGP
Um die Richtlinie auf Routen anzuwenden, die aus der Routingtabelle in BGP exportiert werden, fügen Sie die Anweisung und die Namen einer oder mehrere zu evaluierende Richtlinien export
ein:
export [ policy-names ];
Eine Liste von Hierarchieebenen, in denen Sie diese Aussage enthalten können, finden Sie im Abschnitt "Statement Summary" in dieser Anweisung.
Wenn Sie mehrere Richtlinien angeben, werden diese in der angegebenen Reihenfolge zuerst bis zuletzt ausgewertet, und der erste übereinstimmende Filter wird auf die Route angewendet. Wenn keine Routen den Filtern übereinstimmen, wird die Routingtabelle in BGP in nur die Routen exportiert, die sie von diesem gelernt BGP.
Einstellung BGP zur Ankündigung inaktiver Routen
Standardmäßig speichert BGP die Routeninformationen, die er von Nachrichten in der Junos OS-Routingtabelle empfängt, und exportiert aktive Routen nur in BGP, die BGP dann den Peers angezeigt werden. Um den Export der Routingtabelle in BGP die von BGP am besten erlernte Route zu erhalten, selbst wenn Junos OS diese Route nicht als aktive Route auswählen Junos OS fügen Sie die Anweisung advertise-inactive
hinzu:
advertise-inactive;
Eine Liste von Hierarchieebenen, in denen Sie diese Aussage enthalten können, finden Sie im Abschnitt "Statement Summary" in dieser Anweisung.
Konfiguration BGP, um die beste externe Route zu internen Peers zu werben
Generell wird bei einer BGP externe Route nicht mit dem höchsten lokalen Einstellungswert für interne Peers angegeben, es sei denn, dies ist die beste Route. Dieses Verhalten wurde zwar von einer früheren Version der Spezifikation für BGP Version 4, RFC 1771, gefordert, es wurde jedoch normalerweise nicht befolgt, um die Menge der angekündigten Informationen zu minimieren und Routing-Schleifen zu verhindern. Es gibt jedoch Szenarien, in denen die Werbung für die beste externe Route von Vorteil ist, insbesondere Situationen, die zu IBGP-Routen-Oscilation führen können.
In Junos OS Version 9.3 und höher können Sie BGP so konfigurieren, dass der beste externe Route zu einer internen BGP (IBGP)-Mesh-Gruppe, einem Route Reflector-Cluster oder einem autonomen System (AS) angegeben wird, selbst wenn die beste Route ein interner Route ist.
Um die Anweisung auf einem Route Reflector zu konfigurieren, müssen Sie advertise-external
Intracluster Reflection mit der Anweisung no-client-reflect
deaktivieren.
Wenn ein Routinggerät als Route Reflector für einen Cluster konfiguriert wird, gilt ein vom Route Reflector angekündigtes Routing als intern, wenn es von einem internen Peer mit derselben Cluster-Kennung empfangen wird oder wenn beide Peers nicht über eine Clusterkennung konfiguriert sind. Eine Route, die von einem internen Peer empfangen wird, der einem anderen Cluster gehört, der eine andere Cluster-Kennung hat, gilt als extern.
Bei der Werbung eines Routes zu einem Confederation Border Router wird in einer Confederation-Untergruppe jede Route aus verschiedenen Untergruppen AS als extern betrachtet.
Sie können die Konfiguration BGP die externe Route nur dann anzeigen, wenn der Routenauswahlprozess den Punkt erreicht, an dem die Multiple Exit Discriminator (MED)-Metrik ausgewertet wird. Daher wird eine externe Route mit einem besseren Pfad AS (d. h. länger) als der aktive Pfad nicht ausgeschrieben.
Junos OS bietet außerdem Unterstützung für die Konfiguration einer BGP-Exportrichtlinie, die dem Status einer angegebenen Route entspricht. Sie können sowohl auf aktiven als auch auf inaktiven Routen übereinstimmen. Weitere Informationen finden Sie im Benutzerhandbuch für Routing-Richtlinien, Firewall-Filter und Datenverkehrsrichtlinien.
Um die Konfiguration BGP zur Ankündigung des besten externen Pfads zu internen Peers zu konfigurieren, fügen Sie die Aussage advertise-external
hinzu:
advertise-external;
Die advertise-external
Anweisung wird sowohl auf Gruppen- als auch auf Nachbarebene unterstützt. Wenn Sie die Anweisung auf Nachbarebene konfigurieren, müssen Sie sie für alle Nachbarn in einer Gruppe konfigurieren. Andernfalls wird die Gruppe automatisch in verschiedene Gruppen unterteilt.
Eine vollständige Liste von Hierarchieebenen, in denen Sie diese Anweisung konfigurieren können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.
Um eine BGP, um den besten externen Pfad zu anzeigen, nur wenn der Routenauswahlprozess den Punkt erreicht, an dem der MED-Wert ausgewertet wird, fügen Sie die Aussage conditional
hinzu:
advertise-external { conditional; }
Konfigurieren, wie oft BGP Routen mit der Routingtabelle austauscht
BGP speichert die Routeninformationen, die er von Aktualisierungsmeldungen in der Routingtabelle erhält, und exportiert aktive Routen aus der Routingtabelle in BGP. BGP dann die exportierten Routen zu ihren Peers an. Standardmäßig erfolgt der Austausch von Routeninformationen zwischen BGP und der Routing-Tabelle sofort nach dem Empfangen der Routen. Dieser sofortige Austausch von Routeninformationen kann zu Instabilitäten in den Informationen zur Netzwerkverfügbarkeit führen. Wenn Sie sich dagegen schützen möchten, können Sie die Zeit zwischen dem Verbindungswechsel BGP und den Routingtabellen-Routeninformationen verzögern.
Um zu konfigurieren, wie oft BGP Routendaten und der Routingtabellen-Tauschrouteninformationen verwendet werden, fügen Sie die Aussage out-delay
hinzu:
out-delay seconds;
Standardmäßig werden in der Routingtabelle einige der in der Routingtabelle gelernten Routeninformationen BGP. Damit alle oder keine dieser Informationen in der Routingtabelle bleiben, müssen Sie die Aussage keep
beinhalten:
keep (all | none);
Eine Liste von Hierarchieebenen, in denen Sie diese Anweisungen enthalten können, finden Sie in den Abschnitten mit einer Zusammenfassung der Anweisungen.
Die Routing-Tabelle kann die routeninformationen, die aus diesem BGP gelernt werden, auf eine der folgenden Arten beibehalten:
Standard (aus der Anweisung weglassen): Alle aus BGP gelernten Routeninformationen behalten, außer für Routen, deren AS-Pfad eine Schleife hat und deren Schleife die lokalen
keep
AS.keep all
—Halten Sie alle Aushedungsinformationen, die sie BGP.keep none
— Verwerfen Sie Routen, die von einem Peer empfangen wurden und die durch eine Importrichtlinie oder andere Überprüfungen des desinheitsgef weges (z. B. Pfad AS oder nächster Hop) abgelehnt wurden. Wenn Sie die Konfiguration für die BGP Sitzung und die eingehenden Richtlinienänderungen vornehmen, muss dies Junos OS der gesamten vom Peer angekündigten Routenkeep none
rückgängig machen.
In einer AS von Pfadheilungssituation könnten Routen mit schlaufenden Pfaden theoretischeerweise bei einer Soft-Rekonfiguration verwendet werden, wenn die Begrenzung AS Pfadschleifen geändert wird. Es besteht jedoch ein beträchtlicher Unterschied bei der Speichernutzung zwischen Standard und keep all
.
Stellen Sie sich die folgenden Szenarien vor:
Ein Peer liest die Routen zurück zum Peer, von dem er sie gelernt hat.
Dies kann in den folgenden Fällen vorkommen:
Das Routinggerät eines anderen Herstellers gibt die Routen zurück zum sendenden Peer aus.
Das Junos OS des Peer-Standardverhaltens, bei dem keine Readvertising-Routen zurück zum sendenden Peer vorkonvertiert werden, wird durch die Konfiguration
advertise-peer-as
überschrieben.
Ein Provider-Edge-Routinggerät (PE) verworfen alle VPN-Routen, die keine der erwarteten Routenziele haben.
Wenn die Konfiguration vorkonfiguriert ist, wird das Verhalten des Verwerfens von Routen, die in den oben genannten Szenarien empfangen keep all
werden, außer Kraft gesetzt.
Deaktivierung der Routenunterdrückung
Junos OS werden die von einem EBGP-Peer erlernten Routen nicht zurück zum selben externen BGP (EBGP)-Peer angezeigt. Darüber hinaus werbet die Software diese Routen nicht zu EBGP-Peers zurück, die sich in derselben Ausgangs AS wie der Ursprungs-Peer befinden, unabhängig von der Routinginstanz. Sie können dieses Verhalten ändern, indem Sie die advertise-peer-as
Anweisung in der Konfiguration wieder hinzufügen. Um die Standard-Ankündigungsunterdrückung zu deaktivieren, schließen Sie die advertise-peer-as
Anweisung ein:
advertise-peer-as;
Das Standardverhalten zur Routenunterdrückung wird deaktiviert, wenn die as-override
Anweisung in der Konfiguration enthalten ist.
Wenn Sie die Anweisung in die Konfiguration beinhalten, BGP unabhängig von dieser advertise-peer-as
Prüfung den Route an.
Um das Standardverhalten wiederherzustellen, fügen Sie die no-advertise-peer-as
Anweisung in die Konfiguration ein:
no-advertise-peer-as;
Wenn Sie in die Konfiguration sowohl die Anweisungen als auch die Anweisungen as-override
no-advertise-peer-as
enthalten, no-advertise-peer-as
wird die Aussage ignoriert. Sie können diese Anweisungen auf mehreren Hierarchieebenen enthalten.
Eine Liste von Hierarchieebenen, in denen Sie diese Anweisungen enthalten können, finden Sie im Abschnitt "Statement Summary" für diese Anweisungen.
Siehe auch
Beispiel: Konfigurieren einer Routingrichtlinie, um die beste externe Route zu internen Peers zu werben
Die in RFC 1771 definierte Spezifikation des BGP-Protokolls gibt an, dass ein BGP-Peer seinen internen Peers den externen Pfad mit höherer Einstellung anspricht, auch wenn dieser Pfad nicht der insgesamt beste ist (mit anderen Worten, selbst wenn der beste Pfad ein interner Pfad ist). In der Praxis befolgen BGP Implementierungen nicht diese Regel. Folgende Spezifizierungsabweisungen wurden als Gründe genannt:
Minimieren der ausgeschriebenen Daten. BGP kann je nach Anzahl der verfügbaren Pfade skaliert werden.
Vermeidung von Routing- und Weiterleitungsschleifen.
Es gibt jedoch mehrere Szenarien, in denen das in RFC 1771 angegebene Verhalten der Werbung der besten externen Route nützlich sein könnte. Die Begrenzung der Pfadinformationen ist nicht immer wünschenswert, da eine Vielfalt von Pfaden dazu beitragen könnte, die Wiederherstellungszeiten zu reduzieren. Die Werbung für den besten externen Pfad kann auch Probleme mit internen BGP (IBGP)-Routen-Oscilation beheben, wie in RFC 3345, Border Gateway Protocol (BGP) Persistent Route Oscilation Conditionbeschrieben.
Die Erklärung ändert das Verhalten eines BGP Sprechers, um den besten externen Pfad zu IBGP-Peers zu werben, selbst wenn der beste Gesamtpfad ein interner advertise-external
Pfad ist.
Die advertise-external
Anweisung wird sowohl auf Gruppen- als auch auf Nachbarebene unterstützt. Wenn Sie die Anweisung auf Nachbarebene konfigurieren, müssen Sie sie für alle Nachbarn in einer Gruppe konfigurieren. Andernfalls wird die Gruppe automatisch in verschiedene Gruppen unterteilt.
Die Option beschränkt das Verhalten der Einstellung, so dass die externe Route nur angekündigt wird, wenn der Routenauswahlprozess den Punkt erreicht, an dem die Multiple Exit conditional
advertise-external
Discriminator (MED)-Metrik ausgewertet wird. Daher wird eine externe Route nicht ausgeschrieben, wenn sie beispielsweise über einen pfad verfügt, der AS schlechter (länger) als der des aktiven Pfads ist. Die Option beschränkt externe Pfadanzeigen darauf, wenn der beste externe Pfad und der aktive Pfad bis zum conditional
MED-Schritt des Routenauswahlprozesses gleich sind. Beachten Sie, dass die Kriterien zur Auswahl des besten externen Pfads unabhängig davon, ob die Option conditional
konfiguriert ist, dieselben sind.
Junos OS bietet außerdem Unterstützung für die Konfiguration einer BGP-Exportrichtlinie, die dem Status einer angegebenen Route entspricht. Sie können aktiven oder inaktiven Routen wie folgt übereinstimmen:
policy-options { policy-statement name{ from state (active|inactive); } }
Dieser Qualifikationsqualifizierer entspricht nur dann, wenn es im Kontext einer Exportrichtlinie verwendet wird. Wenn eine Route von einem Protokoll ausgeschrieben wird, das inaktive Routen (wie z. B. BGP) ausgeschrieben hat, werden die aus den Anweisungen angegebenen Routen state inactive
advertise-inactive
advertise-external
wiedererkungen.
Beispielsweise kann die folgende Konfiguration als BGP-Exportrichtlinie in interne Peers verwendet werden, um aufgrund der Einstellung einer benutzerdefinierten Community neue Routen advertise-external
zu kennzeichnen. Diese Community kann später von den empfangenden Routern verwendet werden, um solche Routen aus der Weiterleitungstabelle heraus zu filtern. Mit einem solchen Mechanismus können Sie Bedenken ausräumen, dass Werbepfade, die nicht vom Absender zur Weiterleitung verwendet werden, zu Weiterleitungsschleifen führen könnten.
user@host# show policy-options policy-statement mark-inactive { term inactive { from state inactive; then { community set comm-inactive; } } term default { from protocol bgp; then accept; } then reject; } community comm-inactive members 65536:65284;
Anforderungen
Junos OS 9.3 oder höher erforderlich.
Überblick
In diesem Beispiel sind drei Routing-Geräte zu sehen. Gerät R2 verfügt über eine externe BGP (EBGP)-Verbindung zu Gerät R1. Gerät R2 verfügt über eine IBGP-Verbindung zu Gerät R3.
Device R1 gibt 172.16.6.0/24 an. Gerät R2 wird in einer Importrichtlinie für die Routen von Device R1 nicht die lokale Einstellung festgelegt. Daher wird für 172.16.6.0/24 die lokale Standardpräferenz von 100 festgelegt.
Device R3 gibt 172.16.6.0/24 mit einer lokalen Präferenz für 200 an.
Wenn die Aussage auf Device R2 nicht konfiguriert ist, wird advertise-external
172.16.6.0/24 von Gerät R2 nicht für Gerät R3 angekündigt.
Wenn die Anweisung auf Gerät R2 in der Sitzung in Richtung Gerät R3 konfiguriert ist, wird advertise-external
172.16.6.0/24 von Gerät R2 in Richtung Gerät R3 angekündigt.
Wenn auf Gerät R2 in der Sitzung in Richtung Gerät R3 konfiguriert ist, wird advertise-external conditional
172.16.6.0/24 von Gerät R2 nicht in Richtung Gerät R3 ausgeschrieben. Wenn Sie die Einstellung auf Gerät R3 entfernen und die Einstellung auf Gerät R2 hinzufügen (wodurch die Kriterien für die Pfadauswahl bis zum MED-Schritt des Routenauswahlprozesses gleich sind), wird then local-preference 200
path-selection as-path-ignore
172.16.6.0/24 von Device R2 in Richtung Gerät R3 angekündigt.
Um die Anweisung auf einem Route Reflector zu konfigurieren, müssen Sie die Intracluster Reflection mit der Anweisung deaktivieren, und der Client-Cluster muss vollständig vermascht werden, um das Senden redundanter Route-Ankündigungen advertise-external
no-client-reflect
zu verhindern.
Wenn ein Routinggerät als Route Reflector für einen Cluster konfiguriert wird, gilt ein vom Route Reflector angekündigtes Routing als intern, wenn es von einem internen Peer mit derselben Cluster-Kennung empfangen wird oder wenn beide Peers nicht über eine Clusterkennung konfiguriert sind. Eine Route, die von einem internen Peer empfangen wird, der einem anderen Cluster gehört, der eine andere Cluster-Kennung hat, gilt als extern.
Topologie
Abbildung 2 zeigt das Beispielnetzwerk an.

CLI-Konfiguration zeigt die Konfiguration für alle Geräte in Abbildung 2 an.
In diesem #d188e161__d188e338 Abschnitt werden die Schritte auf Gerät R2 beschrieben.
Konfiguration
CLI-Konfiguration
Um dieses Beispiel schnell konfigurieren zu können, kopieren Sie die folgenden Befehle, fügen Sie diese in eine Textdatei ein, entfernen Sie alle Zeilenbrüche, ändern Sie alle Details, die zur Übereinstimmung mit der Netzwerkkonfiguration erforderlich sind, und kopieren Sie die Befehle, und fügen Sie die Befehle CLI der Hierarchieebene [edit]
ein.
Gerät R1
set interfaces fe-1/2/0 unit 0 description to-R2 set interfaces fe-1/2/0 unit 0 family inet address 10.0.0.1/30 set interfaces lo0 unit 0 family inet address 192.168.0.1/32 set protocols bgp group ext type external set protocols bgp group ext export send-static set protocols bgp group ext peer-as 200 set protocols bgp group ext neighbor 10.0.0.2 set policy-options policy-statement send-static term 1 from protocol static set policy-options policy-statement send-static term 1 from route-filter 172.16.6.0/24 exact set policy-options policy-statement send-static term 1 then accept set policy-options policy-statement send-static term 2 then reject set routing-options static route 172.16.6.0/24 reject set routing-options router-id 192.168.0.1 set routing-options autonomous-system 100
Gerät R2
set interfaces fe-1/2/0 unit 0 description to-R1 set interfaces fe-1/2/0 unit 0 family inet address 10.0.0.2/30 set interfaces fe-1/2/1 unit 0 description to-R3 set interfaces fe-1/2/1 unit 0 family inet address 10.0.0.5/30 set interfaces lo0 unit 0 family inet address 192.168.0.2/32 set protocols bgp group ext type external set protocols bgp group ext peer-as 100 set protocols bgp group ext neighbor 10.0.0.1 set protocols bgp group int type internal set protocols bgp group int local-address 192.168.0.2 set protocols bgp group int advertise-external set protocols bgp group int neighbor 192.168.0.3 set protocols ospf area 0.0.0.0 interface fe-1/2/1.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set routing-options router-id 192.168.0.2 set routing-options autonomous-system 200
Gerät R3
set interfaces fe-1/2/0 unit 6 family inet address 10.0.0.6/30 set interfaces lo0 unit 0 family inet address 192.168.0.3/32 set protocols bgp group int type internal set protocols bgp group int local-address 192.168.0.3 set protocols bgp group int export send-static set protocols bgp group int neighbor 192.168.0.2 set protocols ospf area 0.0.0.0 interface fe-1/2/0.6 set protocols ospf area 0.0.0.0 interface lo0.0 passive set policy-options policy-statement send-static term 1 from protocol static set policy-options policy-statement send-static term 1 then local-preference 200 set policy-options policy-statement send-static term 1 then accept set routing-options static route 172.16.6.0/24 reject set routing-options static route 0.0.0.0/0 next-hop 10.0.0.5 set routing-options autonomous-system 200
Verfahren
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zur Navigation in CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI Benutzerhandbuch.
So konfigurieren Sie Gerät R2:
Konfigurieren Sie die Geräteschnittstellen.
[edit interfaces] user@R2# set fe-1/2/0 unit 0 description to-R1 user@R2# set fe-1/2/0 unit 0 family inet address 10.0.0.2/30 user@R2# set fe-1/2/1 unit 0 description to-R3 user@R2# set fe-1/2/1 unit 0 family inet address 10.0.0.5/30 user@R2# set lo0 unit 0 family inet address 192.168.0.2/32
Konfiguration OSPF oder eines anderen Interior Gateway Protocol (IGP).
[edit protocols ospf area 0.0.0.0] user@R2# set interface fe-1/2/1.0 user@R2# set interface lo0.0 passive
EbGP-Verbindung zu Gerät R1 konfigurieren.
[edit protocols bgp group ext] user@R2# set type external user@R2# set peer-as 100 user@R2# set neighbor 10.0.0.1
Konfigurieren Sie die IBGP-Verbindung zu Gerät R3.
[edit protocols bgp group int] user@R2# set type internal user@R2# set local-address 192.168.0.2 user@R2# set neighbor 192.168.0.3
Fügen Sie
advertise-external
die Anweisung der PEERing-Sitzung der IBGP-Gruppe hinzu.[edit protocols bgp group int] user@R2# set advertise-external
Konfigurieren Sie die autonome Systemnummer (AS) und die Router-ID.
[edit routing-options ] user@R2# set router-id 192.168.0.2 user@R2# set autonomous-system 200
Ergebnisse
Bestätigen Sie Ihre Konfiguration im Konfigurationsmodus, indem Sie die show interfaces
show protocols
, und Befehle show policy-options
show routing-options
eingeben. Wenn in der Ausgabe nicht die beabsichtigte Konfiguration angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@R2# show interfaces fe-1/2/0 { unit 0{ description to-R1; family inet { address 10.0.0.2/30; } } } fe-1/2/1 { unit 0 { description to-R3; family inet { address 10.0.0.5/30; } } } lo0 { unit 0 { family inet { address 192.168.0.2/32; } } }
user@R2# show protocols bgp { group ext { type external; peer-as 100; neighbor 10.0.0.1; } group int { type internal; local-address 192.168.0.2; advertise-external; neighbor 192.168.0.3; } } ospf { area 0.0.0.0 { interface fe-1/2/1.0; interface lo0.0 { passive; } } }
user@R2# show routing-options router-id 192.168.0.2; autonomous-system 200;
Wenn Sie die Konfiguration des Geräts bereits durchgeführt haben, geben Sie commit
sie im Konfigurationsmodus ein.
Überprüfung
Stellen Sie sicher, dass die Konfiguration ordnungsgemäß funktioniert.
- Überprüfung des aktiven BGP Pfads
- Prüfung der externen Routenanzeige
- Überprüfung der Route auf Gerät R3
- Test mit bedingter Option
Überprüfung des aktiven BGP Pfads
Zweck
Stellen Sie auf Gerät R2 sicher, dass sich das Präfix 172.16.6.0/24 in der Routingtabelle befindet und den erwarteten aktiven Pfad auf dem Gerät hat.
Aktion
user@R2> show route 172.16.6 inet.0: 8 destinations, 9 routes (8 active, 1 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.6.0/24 *[BGP/170] 00:00:07, localpref 200, from 192.168.0.3 AS path: I, validation-state: unverified > to 10.0.0.6 via fe-1/2/1.0 [BGP/170] 03:23:03, localpref 100 AS path: 100 I, validation-state: unverified > to 10.0.0.1 via fe-1/2/0.0
Bedeutung
Gerät R2 empfängt die Route 172.16.6.0/24 von R1 und Gerät R3. Die Route von Gerät R3 ist der aktive Pfad, der durch das Sternchen (*) bestimmt ist. Der aktive Pfad hat die lokale Präferenz. Selbst wenn die lokalen Einstellungen der beiden Routen gleich wären, bleibt die Route von Gerät R3 aktiv, da sie den AS hat.
Prüfung der externen Routenanzeige
Zweck
Stellen Sie auf Device R2 sicher, dass die Route 172.16.6.0/24 auf Gerät R3 angekündigt wird.
Aktion
user@R2> show route advertising-protocol bgp 192.168.0.3 inet.0: 8 destinations, 9 routes (8 active, 1 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 172.16.6.0/24 10.0.0.1 100 100 I
Bedeutung
Gerät R2 gibt die Route 172.16.6.0/24 in Richtung Gerät R3 an.
Überprüfung der Route auf Gerät R3
Zweck
Stellen Sie sicher, dass das Präfix 172.16.6.0/24 in der Routingtabelle von Device R3 enthalten ist.
Aktion
user@R3> show route 172.16.6.0/24 inet.0: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.6.0/24 *[Static/5] 03:34:14 Reject [BGP/170] 06:34:43, localpref 100, from 192.168.0.2 AS path: 100 I, validation-state: unverified > to 10.0.0.5 via fe-1/2/0.6
Bedeutung
Gerät R3 verfügt über die statische Route und die BGP route für 172.16.6.0/24.
Beachten Sie, dass BGP-Route auf Gerät R3 verborgen ist, wenn die Route nicht erreichbar ist oder der nächste Hop nicht gelöst werden kann. Um diese Anforderung zu erfüllen, enthält dieses Beispiel eine statische Standardroute auf Gerät R3 ( static route 0.0.0.0/0 next-hop 10.0.0.5
).
Test mit bedingter Option
Zweck
Erfahren Sie im conditional
Kontext des Algorithmus für die Pfadauswahl, BGP Option funktioniert.
Aktion
Auf Gerät R2 die Option
conditional
hinzufügen.[edit protocols bgp group int] user@R2# set advertise-external conditional user@R2# commit
Prüfen Sie auf Device R2, ob die Route 172.16.6.0/24 auf Gerät R3 angekündigt wird.
user@R2> show route advertising-protocol bgp 192.168.0.3
Wie erwartet, wird die Route nicht mehr ausgeschrieben. Möglicherweise müssen Sie einige Sekunden warten, um dieses Ergebnis zu erhalten.
Deaktivieren Sie die Richtlinienaktion auf Gerät
then local-preference
R3.[edit policy-options policy-statement send-static term 1] user@R3# deactivate logical-systems R3 then local-preference user@R3# commit
Stellen Sie auf Gerät R2 sicher, dass die lokalen Einstellungen der beiden Pfade gleich sind.
user@R2> show route 172.16.6.0/24 inet.0: 8 destinations, 9 routes (8 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.6.0/24 *[BGP/170] 08:02:59, localpref 100 AS path: 100 I, validation-state: unverified > to 10.0.0.1 via fe-1/2/0.0 [BGP/170] 00:07:51, localpref 100, from 192.168.0.3 AS path: I, validation-state: unverified > to 10.0.0.6 via fe-1/2/1.0
Fügen Sie auf Gerät R2 die Anweisung
as-path-ignore
hinzu.[edit protocols bgp] user@R2# set path-selection as-path-ignore user@R2# commit
Prüfen Sie auf Device R2, ob die Route 172.16.6.0/24 auf Gerät R3 angekündigt wird.
user@R2> show route advertising-protocol bgp 192.168.0.3 inet.0: 8 destinations, 9 routes (8 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.6.0/24 10.0.0.1 100 100 I
Wie erwartet, wird die Route jetzt ausgeschrieben, AS Pfadlänge ignoriert wird und weil die lokalen Präferenzen gleich sind.
Beispiel: Konfigurieren BGP Prefix-basierter Outbound-Routenfilterung
In diesem Beispiel wird gezeigt, wie ein Router Juniper Networks konfiguriert wird, um Route-Filter von Remote-Peers zu akzeptieren und ausgehendes Routenfiltern mithilfe der empfangenen Filter durchzuführen.
Anforderungen
Bevor Sie beginnen:
Konfigurieren Sie die Routerschnittstellen.
Konfigurieren Sie ein Interior Gateway Protocol (IGP).
Überblick
Sie können einen Peer-BGP konfigurieren, um Routenfilter von Remote-Peers zu akzeptieren und ausgehende Routenfilter über die empfangenen Filter durchzuführen. Durch das Herausfiltern unerwünschter Updates spart der sendende Peer die Ressourcen, die für die Generierung und Übertragung von Updates benötigt werden, und der empfangende Peer spart Ressourcen, die zur Verarbeitung von Updates benötigt werden. Diese Funktion kann beispielsweise in einem virtuellen privaten Netzwerk (VPN) nützlich sein, in dem Untergruppen von Kunden-Edge-Geräten (CE) nicht alle Routen im VPN verarbeiten können. Die CE können eine prefix-basierte Outbound-Routenfilterung verwenden, um mit dem Edge-Routing-Gerät des Anbieters zu kommunizieren und nur eine Untergruppe von Routen zu übertragen, z. B. Routen zu den Hauptdatencentern.
Die maximale Anzahl von Prefix-basierten Outbound-Routenfiltern, die ein BGP-Peer akzeptieren kann, beträgt 5000. Wenn ein Remote-Peer mehr als 5.000 Ausgehende Routenfilter an eine Peer-Adresse sendet, werden die zusätzlichen Filter verworfen und eine Systemprotokollnachricht generiert.
Sie können die Interoperabilität des Routinggeräts als Ganzes oder nur für bestimmte Routing BGP oder Peers konfigurieren.
Topologie
In dem Beispielnetzwerk ist Device CE1 ein Router von einem anderen Anbieter. Die in diesem Beispiel dargestellte Konfiguration ist auf Juniper Networks-Router-PE1.
Abbildung 3 zeigt das Beispielnetzwerk an.

Konfiguration
CLI-Konfiguration
Um dieses Beispiel schnell konfigurieren zu können, kopieren Sie die folgenden Befehle, fügen Sie diese in eine Textdatei ein, entfernen Sie alle Zeilenbrüche, ändern Sie alle Details, die zur Übereinstimmung mit der Netzwerkkonfiguration erforderlich sind, und kopieren Sie die Befehle, und fügen Sie die Befehle CLI der Hierarchieebene [edit]
ein.
PE1
set protocols bgp group cisco-peers type external set protocols bgp group cisco-peers description “to CE1” set protocols bgp group cisco-peers local-address 192.168.165.58 set protocols bgp group cisco-peers peer-as 35 set protocols bgp group cisco-peers outbound-route-filter bgp-orf-cisco-mode set protocols bgp group cisco-peers outbound-route-filter prefix-based accept inet set protocols bgp group cisco-peers neighbor 192.168.165.56 set routing-options autonomous-system 65500
Verfahren
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zur Navigation in CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI Benutzerhandbuch.
Zum Konfigurieren von Router-PE1 zum Akzeptieren von Routenfiltern von Device CE1 und Zum Durchführen einer Outbound-Routenfilterung mithilfe der empfangenen Filter:
Konfigurieren Sie das lokale autonome System.
[edit routing-options] user@PE1# set autonomous-system 65500
Konfigurieren Sie externes Peering mit Device CE1.
[edit protocols bgp group cisco-peers] user@PE1# set type external user@PE1# set description “to CE1” user@PE1# set local-address 192.168.165.58 user@PE1# set peer-as 35 user@PE1# set neighbor 192.168.165.56
Konfigurieren Sie Router PE1, um IPv4-Routenfilter von Device CE1 zu akzeptieren und ausgehende Routenfilterung mithilfe der empfangenen Filter durchzuführen.
[edit protocols bgp group cisco-peers] user@PE1# set outbound-route-filter prefix-based accept inet
(optional) Ermöglichen sie die Interoperabilität mit Routinggeräten, die den anbieterspezifischen Kompatibilitätscode 130 für Outbound-Route-Filter und den Codetyp 128 verwenden.
Der IANA ist 3 und der Standardcodetyp 64.
[edit protocols bgp group cisco-peers] user@PE1# set outbound-route-filter bgp-orf-cisco-mode
Ergebnisse
Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie die Befehle show protocols
show routing-options
eingeben. Wenn in der Ausgabe nicht die beabsichtigte Konfiguration angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@PE1# show protocols group cisco-peers { type external; description “to CE1”; local-address 192.168.165.58; peer-as 35; outbound-route-filter { bgp-orf-cisco-mode; prefix-based { accept { inet; } } } neighbor 192.168.165.56; }
user@PE1# show routing-options autonomous-system 65500;
Wenn Sie die Konfiguration des Geräts bereits durchgeführt haben, geben Sie commit
sie im Konfigurationsmodus ein.
Überprüfung
Stellen Sie sicher, dass die Konfiguration ordnungsgemäß funktioniert.
Überprüfung des Filters für ausgehende Routen
Zweck
Anzeige von Informationen zu dem Prefix-basierten Outbound-Routenfilter, der von Device CE1 empfangen wurde.
Aktion
Geben Sie im Betriebsmodus den Befehl show bgp neighbor orf detail
ein.
user@PE1> show bgp neighbor orf 192.168.165.56 detail Peer: 192.168.165.56 Type: External Group: cisco-peers inet-unicast Filter updates recv: 4 Immediate: 0 Filter: prefix-based receive Updates recv: 4 Received filter entries: seq 10 2.2.0.0/16 deny minlen 0 maxlen 0 seq 20 3.3.0.0/16 deny minlen 24 maxlen 0 seq 30 4.4.0.0/16 deny minlen 0 maxlen 28 seq 40 5.5.0.0/16 deny minlen 24 maxlen 28
Überprüfung des Nachbarmodus BGP Nachbarmodus
Zweck
Stellen Sie sicher, dass die Einstellung für den Peer aktiviert ist, indem Sie sicherstellen, dass die Option in der bgp-orf-cisco-mode
ORFCiscoMode
show bgp neighbor
Befehlsausgabe angezeigt wird.
Aktion
Geben Sie im Betriebsmodus den Befehl show bgp neighbor
ein.
user@PE1> show bgp neighbor Peer: 192.168.165.56 AS 35 Local: 192.168.165.58 AS 65500 Type: External State: Active Flags: <> Last State: Idle Last Event: Start Last Error: None Export: [ adv_stat ] Options: <Preference LocalAddress AddressFamily PeerAS Refresh> Options: <ORF ORFCiscoMode> Address families configured: inet-unicast Local Address: 192.168.165.58 Holdtime: 90 Preference: 170 Number of flaps: 0 Trace options: detail open detail refresh Trace file: /var/log/orf size 5242880 files 20
Verstehen der Standard-BGP-Routing-Richtlinien auf Paketübertragungs-Router (PTX-Serie)
Bei Routing-Paketübertragungs-Router der PTX BGP unterscheidet sich die Routing-Richtlinie von anderen Routing Junos OS geräten.
Die Router der PTX-Serie sind MPLS Transitplattformen, die IP-Weiterleitungen ermöglichen und in der Regel Routen (Interior Gateway Protocol) (IGP) verwenden. Die Packet Forwarding Engine PTX-Serie kann eine relativ kleine Anzahl von Präfixen mit variabler Länge aufnehmen.
Ein Router der PTX-Serie kann vollständige BGP Routen in der Steuerungsebene unterstützen und als Routenreflektor (RR) verwendet werden. Er kann Multicastweiterleitung mit genauer Länge suchen und die Multicastweiterleitungsebene erstellen, die von der Unicast-Steuerungsebene verwendet wird (z. B. zur Durchführung einer Reverse-Path Forwarding-Suche für Multicast).
Aufgrund der PFE-Einschränkung besteht die Standard-Routing-Richtlinie für Router der PTX-Serie dafür, dass BGP nicht in der Weiterleitungstabelle installiert werden. Sie können die Standard-Routingrichtlinie außer Kraft setzen und bestimmte Routing BGP Routen, die sie in der Weiterleitungstabelle installieren möchten, auswählen.
Das Standardverhalten für Load Balancing- BGP Routen auf Routern der PTX-Serie ist wie folgt. Sie hat die folgenden wünschenswerten Eigenschaften:
Ermöglicht es Ihnen, das Standardverhalten zu außer Kraft zu setzen, ohne die Standardrichtlinie direkt ändern zu müssen
Verkleinern der Wahrscheinlichkeit von versehentlichen Änderungen, durch die die Standardeinstellungen null sind
Legt keine Maßnahmen zur Steuerung des Datenflusses fest, z. B. "Akzeptieren" und "Ablehnen".
Für die Router der PTX-Serie gilt folgende Standardrouting-Richtlinie:
user@host# show policy-options | display inheritance defaults no-comments policy-options { policy-statement junos-ptx-series-default { term t1 { from { protocol bgp; rib inet.0; } then no-install-to-fib; } term t2 { from { protocol bgp; rib inet6.0; } then no-install-to-fib; } term t3 { then load-balance per-packet; } } } routing-options { forwarding-table { default-export junos-ptx-series-default; } } user@host# show routing-options forwarding-table default-export | display inheritance defaults no-comments default-export junos-ptx-series-default;
Wie in diesem Beispiel junos-ptx-series-default
dargestellt, ist die Richtlinie in [edit policy-options]
definiert. Die Richtlinie wird [edit routing-options forwarding-table]
mithilfe der Anweisung default-export
angewendet. Sie können diese Standardkonfigurationen über den Flag | display inheritance
anzeigen.
Sie können mit dem Befehl auch show policy
die Standardrichtlinie anzeigen.
user@host> show policy junos-ptx-series-default Policy junos-ptx-series-default: Term t1: from proto BGP inet.0 then install-to-fib no Term t2: from proto BGP inet6.0 then install-to-fib no Term t3: then load-balance per-packet
Wir empfehlen Dringend, dass Sie die junos-ptx-series-default
Routing-Richtlinie nicht direkt ändern.
Junos OS die Richtlinie junos-ptx-series-default
und benutzerkonfigurierte Exportrichtlinien. Da die Richtlinie keine Flusssteuerungsaktionen verwendet, werden von Ihnen konfigurierte Exportrichtlinien für jede Route ausgeführt (als implizite Aktion der nächsten junos-ptx-series-default
Richtlinie). So können Sie alle von der Richtlinie festgelegten Aktionen junos-ptx-series-default
außer Kraft setzen. Wenn Sie keine Exportrichtlinie konfigurieren, sind die aktionen, die von Richtlinie junos-ptx-series-default
festgelegt werden, die einzigen Aktionen.
Sie können die Richtlinienmaßnahmen verwenden, um install-to-fib
die Aktion zu außer Kraft zu no-install-to-fib
setzen.
Oder Sie können die Aktion so einrichten, dass load-balance per-prefix
sie die Aktion außer Kraft load-balance per-packet
setzt.
Siehe auch
Beispiel: Überschreiben der Standardrichtlinien BGP Routing-Richtlinien der PTX-Paketübertragungs-Router
In diesem Beispiel wird veranschaulicht, wie die Standard-Routing-Richtlinie von Paketweiterleitungs-Routern wie den Standardrichtlinien der PTX-Serie Paketübertragungs-Router.
Anforderungen
In diesem Beispiel ist Junos OS Version 12.1 oder höher erforderlich.
Überblick
Standardmäßig installieren die Router der PTX-Serie keine BGP in der Weiterleitungstabelle.
Für Router der PTX-Serie hat die Konfiguration des Zustands mit der Aktion nicht das übliche Ergebnis, das es auf anderen Routing Junos OS from protocols bgp
then accept
hat. Mit der folgenden Routing-Richtlinie auf Routern der PTX-Serie werden BGP nicht in der Weiterleitungstabelle installiert.
user@host# show policy-options policy-statement accept-no-install { term 1 { from protocol bgp; then accept; } } user@host# show routing-options forwarding-table { export accept-no-install; }
user@host> show route forwarding-table Routing table: default.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 rjct 36 2
Keine BGP werden in der Weiterleitungstabelle installiert. Das ist das erwartete Verhalten.
In diesem Beispiel wird gezeigt, wie die Aktion then install-to-fib
verwendet wird, um die Standard-Routingrichtlinie BGP effektiv zu außer Kraft zu setzen.
Konfiguration
CLI-Konfiguration
Um dieses Beispiel schnell konfigurieren zu können, kopieren Sie die folgenden Befehle, fügen Sie diese in eine Textdatei ein, entfernen Sie alle Zeilenbrüche, ändern Sie alle Details, die zur Übereinstimmung mit der Netzwerkkonfiguration erforderlich sind, und kopieren Sie die Befehle, und fügen Sie die Befehle CLI der Hierarchieebene [edit]
ein.
set policy-options prefix-list install-bgp 66.0.0.1/32 set policy-options policy-statement override-ptx-series-default term 1 from prefix-list install-bgp set policy-options policy-statement override-ptx-series-default term 1 then load-balance per-prefix set policy-options policy-statement override-ptx-series-default term 1 then install-to-fib set routing-options forwarding-table export override-ptx-series-default
Installation ausgewählter BGP Routen in der Weiterleitungstabelle
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zur Navigation in CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI Benutzerhandbuch.
So installieren Sie ausgewählte BGP Routen in der Weiterleitungstabelle:
Konfigurieren Sie eine Liste von Präfixen zur Installation in der Weiterleitungstabelle.
[edit policy-options prefix-list install-bgp] user@host# set 66.0.0.1/32
Konfigurieren Sie die Routing-Richtlinie, und wenden Sie die Präfixliste als Bedingungen an.
[edit policy-options policy-statement override-ptx-series-default term 1] user@host# set from prefix-list install-bgp user@host# set then install-to-fib user@host# set then load-balance per-prefix
Wenden Sie die Routing-Richtlinie auf die Weiterleitungstabelle an.
[edit routing-options forwarding-table] user@host# set export override-ptx-series-default
Ergebnisse
Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie die Befehle show policy-options
show routing-options
eingeben. Wenn in der Ausgabe nicht die beabsichtigte Konfiguration angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@host# show policy-options prefix-list install-bgp { 66.0.0.1/32; } policy-statement override-ptx-series-default { term 1 { from { prefix-list install-bgp; } then { load-balance per-prefix; install-to-fib; } } }
user@host# show routing-options forwarding-table { export override-ptx-series-default; }
Wenn Sie die Konfiguration des Geräts bereits durchgeführt haben, geben Sie commit
sie im Konfigurationsmodus ein.
Überprüfung
Stellen Sie sicher, dass die Konfiguration ordnungsgemäß funktioniert.
Sicherstellen, dass die ausgewählte Route in der Weiterleitungstabelle installiert ist
Zweck
Stellen Sie sicher, dass die konfigurierte Richtlinie die Standardrichtlinie überschreibt.
Aktion
Geben Sie im Betriebsmodus den Befehl show route forwarding-table
ein.
user@host> show route forwarding-table destination 66.0.0.1 Internet: Destination Type RtRef Next hop Type Index NhRef Netif 66.0.0.1/32 user 0 indr 2097159 3 ulst 2097156 2 5.1.0.2 ucst 574 1 et-6/0/0.1 5.2.0.2 ucst 575 1 et-6/0/0.2
Bedeutung
Diese Ausgabe zeigt, dass die Route zu 66.0.0.1/32 in der Weiterleitungstabelle installiert ist.
Bedingte Ankündigung zur bedingten Installation von Präfixen und Anwendungsfällen
Die Netzwerke sind in der Regel in kleinere, leichter zu verwaltende Einheiten unterteilt, die als autonome Systeme (ASs) bezeichnet werden. Wenn BGP Router zur Bildung von Peer-Beziehungen in derselben Konfiguration AS, wird dies als interne BGP (IBGP) bezeichnet. Wenn BGP Router zum Bilden von Peer-Beziehungen in verschiedenen ASs verwendet werden, wird sie als externe BGP (EBGP) bezeichnet.
Nach der Durchführung von Routing-Sanitätsprüfungen akzeptiert BGP Router die Routen, die von seinen Peers empfangen wurden, und installiert sie in der Routingtabelle. Standardmäßig folgen alle Router in IBGP- und EBGP-Sitzungen den standardmäßigen BGP Advertisement-Regeln. Während ein Router in einer IBGP-Sitzung nur die Routen anspricht, die von seinen direkten Peers gelernt werden, bietet ein Router in einer EBGP-Sitzung alle Routen an, die von seinen direkten und indirekten Peers (Peers von Peers) gelernt werden. Daher fügt ein Router in einem typischen, mit EBGP konfigurierten Netzwerk alle Routen hinzu, die von einem EBGP-Peer in seine Routing-Tabelle aufgenommen werden, und gibt fast alle Routen zu allen EBGP-Peers an.
Ein Dienstanbieter, der BGP-Routen mit Kunden und Peers im Internet austauscht, ist dem Risiko von bösartigen und unbeabsichtigten Bedrohungen ausgesetzt, die die ordnungsgemäße Weiterleitung des Datenverkehrs und den Betrieb der Router gefährden können.
Dies hat mehrere Nachteile:
Non-aggregated route advertisements— Ein Kunde könnte dem ISP alle Präfixe ausgeschrieben haben, anstatt sein Adressraum zu aggregieren. Angesichts der Größe der Internet-Routing-Tabelle muss diese sorgfältig kontrolliert werden. Ein Edge-Router benötigt möglicherweise nur eine Standardroute in Richtung Internet und empfängt stattdessen die gesamte Routingtabelle BGP Routing-Tabelle von seinem Upstream-Peer.
BGP route manipulationWenn ein böswilliger Administrator den Inhalt der Routing BGP ändern sollte, könnte er verhindern, dass der Datenverkehr seinen Bestimmungsort erreicht.
BGP route hijacking— Ein rogue Administrator eines BGP-Peers könnte in böswilliger Absicht die Präfixe eines Netzwerks ankündigen, um den Datenverkehr, der für das Opfernetzwerk bestimmt ist, entweder zum Netzwerk des Administrators umzuleiten, um Zugriff auf den Datenverkehrsinhalt zu erhalten oder die Online-Dienste des Opfers zu blockieren.
BGP denial of service (DoS)—Wenn ein böswilliger Administrator unerwarteten oder unerwünschten BGP-Datenverkehr an einen Router sendet, um alle verfügbaren BGP-Routerressourcen zu verwenden, kann dies dazu führen, dass der Router die verarbeitung zulässigen BGP-Routeninformationen beeinträchtigt.
Die verwendungsbedingte Installation von Präfixen kann verwendet werden, um alle oben genannten Probleme zu beheben. Wenn ein Kunde Zugriff auf Remote-Netzwerke benötigt, ist es möglich, eine bestimmte Route in der Routingtabelle des Routers zu installieren, der mit dem Remotenetzwerk verbunden ist. In einem typischen EBGP-Netzwerk ist dies nicht der Fall, daher ist die bedingte Installation von Präfixen unerlässlich.
ASS sind nicht nur an die physischen Beziehungen, sondern auch an geschäftliche oder andere organisatorische Beziehungen gebunden. Ein AS kann Services für ein anderes Unternehmen bereitstellen oder als Transit-AS zwischen zwei anderen ASs fungieren. Diese Transit-ASS sind an vertraglichen Vereinbarungen zwischen den Parteien gebunden. Sie enthalten Parameter für die Verbindungen untereinander sowie vor allem die Art und Anzahl des Datenverkehrs, den sie untereinander übertragen. Aus rechtlichen und finanziellen Gründen müssen Service Provider Richtlinien implementieren, die steuern, wie BGP-Routen mit Nachbarn ausgetauscht werden, welche Routen von diesen Nachbarn akzeptiert werden und wie sich diese Routen auf den Datenverkehr zwischen den ASs auswirken.
Es gibt zahlreiche verschiedene Optionen zum Filtern von Routen, die von einem BGP-Peer empfangen wurden, um Richtlinien zwischen AS durchzusetzen und die Risiken des Erhalts potenziell schädlicher Routen zu mindern. Die herkömmliche Routenfilterung untersucht die Attribute einer Route und akzeptiert oder lehnt diese Route basierend auf diesen Attributen ab. Eine Richtlinie oder ein Filter kann den Inhalt des AS Pfads, den Next-Hop-Wert, einen Community-Wert, eine Liste von Präfixen, die Adressfamilie der Route und so weiter untersuchen.
In einigen Fällen reicht die standardmäßige "Annahmebedingung", bei der ein bestimmter Attributwert abgleicht, nicht aus. Möglicherweise muss der Service Provider außerhalb der Route selbst eine weitere Bedingung verwenden, beispielsweise eine andere Route in der Routingtabelle. Es könnte beispielsweise wünschenswert sein, eine Standardroute zu installieren, die von einem Upstream-Peer empfangen wird, nur, wenn überprüft werden kann, dass dieser Peer auf andere, weiter vorgeschaltete Netzwerke erreichbar ist. Bei dieser bedingten Routeninstallation wird die Installation einer Standardroute vermieden, die zum Senden von Datenverkehr an diesen Peer verwendet wird, wenn der Peer möglicherweise seine Routen vorgeschaltet verloren hat, was zu Black-Holed-Datenverkehr führt. Hierzu kann der Router so konfiguriert werden, dass in der Routingtabelle nach einer bestimmten Route gesucht wird, und basierend auf diesen Kenntnissen kann ein anderes Präfix akzeptiert oder abgelehnt werden.
Beispiel: Konfigurieren einer Routingrichtlinie für bedingte Ankündigung Ermöglichung der bedingten Installation von Präfixen in einer Routingtabelle erläutert, wie die bedingte Installation von Präfixen konfiguriert und verifiziert werden kann.
Siehe auch
Bedingte Ankündigung und Importrichtlinie (Routing-Tabelle) mit bestimmten Bedingungen
BGP akzeptiert alle nicht looped-Routen, die von Nachbarn gelernt werden, und importiert diese in die RIB-In-Tabelle. Wenn diese Routen von der BGP-Richtlinie akzeptiert werden, werden sie in die Routing-Tabelle inet.0 importieren. Für den Fall, dass nur bestimmte Routen importiert werden müssen, kann festgelegt werden, dass die Peer Routing-Geräte-Routen mit einem bestimmten Zustand oder einer Reihe von Bedingungen exportiert werden.
Die Bedingungen für den Export einer Route können auf folgenden Bedingungen basieren:
Das Peer-Netzwerk, von dem die Route gelernt wurde
Die Schnittstelle, die die Route auf der
Ein anderes erforderliches Attribut
Zum Beispiel:
[edit] policy-options { condition condition-name { if-route-exists address table table-name; } }
Dies wird als bedingte Installation von Präfixen bezeichnet und wird im Beispiel beschrieben: Konfigurieren einer Routingrichtlinie für bedingtes Annoncen ermöglichen die bedingte Installation von Präfixen in einer Routingtabelle.
Die Bedingungen in den Routing-Richtlinien können unabhängig davon konfiguriert werden, ob sie Teil der Ein- oder Ausfuhrrichtlinien sind oder beides. Die Exportrichtlinie unterstützt diese Bedingungen, die aus der Routingrichtlinie übernommen werden, basierend auf der Existenz einer anderen Route in der Routingrichtlinie. Die Importrichtlinie unterstützt diese Bedingungen jedoch nicht und die Bedingungen werden selbst dann nicht ausgeführt, wenn sie vorhanden sind.
Abbildung 4 sehen Sie, BGP- und Exportrichtlinien angewendet werden. Eine Importrichtlinie wird auf eingehende Routen angewendet, die in der Ausgabe des Befehls sichtbar show route receive-protocol bgp neighbor-address
sind. Eine Exportrichtlinie wird auf ausgehende Routen angewendet, die in der Ausgabe des Befehls sichtbar show route advertising-protocol bgp neighbor-address
sind.

Um die verwendungsbedingte Installation von Präfixen zu ermöglichen, muss eine Exportrichtlinie auf dem Gerät konfiguriert werden, auf dem der Prefix-Export ausgeführt werden muss. Die Exportrichtlinie bewertet jede Route, um sicherzustellen, dass sie alle Übereinstimmungsbedingungen der Aussage from
erfüllt. Zudem wird nach der Existenz der in der Anweisung (in der Anweisung konfigurierten condition
Route) from
gesucht.
Wenn die Route nicht den in der Richtlinie definierten Bedingungen für die gesamte Gruppe erforderlicher Bedingungen überspricht oder wenn die in der Anweisung definierte Route nicht in der Routingtabelle vorhanden ist, wird die Route nicht in die anderen BGP condition
exportiert. Eine bedingte Exportrichtlinie entspricht daher den Routen für die gewünschte Route oder das Präfix, die in der Peers-Routingtabelle installiert werden soll.
Um die bedingte Installation von Präfixen mit Hilfe einer Exportrichtlinie zu konfigurieren:
Eine Anweisung
condition
erstellen, um Präfixe zu prüfen.[edit] policy-options { condition condition-name { if-route-exists address table table-name; } }
Erstellen Sie mithilfe der Anweisung eine Exportrichtlinie mit der neu erstellten
condition
Bedingung.[edit] policy-options { policy-statement policy-name { term 1 { from { protocols bgp; condition condition-name; } then { accept; } } } }
Wenden Sie die Exportrichtlinie auf das Gerät an, auf dem nur ausgewählte Präfixe aus der Routingtabelle exportiert werden müssen.
[edit] protocols bgp { group group-name { export policy-name; } }
Siehe auch
Beispiel: Konfigurieren einer Routingrichtlinie für bedingtes Annoncen aktivieren bedingte Installation von Präfixen in einer Routingtabelle
In diesem Beispiel wird gezeigt, wie Sie die verwendungsbedingte Installation von Präfixen in einer Routingtabelle mithilfe BGP-Exportrichtlinie konfigurieren.
Anforderungen
In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:
M Series Multiservice Edge Router, 5G-Router der MX-Universelle Routing-Plattformen oder T-Serie Core-Router
Junos OS 9.0 oder höher
Überblick
In diesem Beispiel sind drei Router in drei verschiedenen autonomen Systemen (ASs) mit dem Protokoll BGP verbunden und konfiguriert. Der als Router bezeichnete Internet als Upstream-Router verfügt über fünf auf seiner Lo0.0-Loopback-Schnittstelle konfigurierte Adressen (172.16.11.1/32, 172.16.12.1/32, 172.16.13.1/32, 172.16.14.1/32 und 172.16.15.1/32) und eine weitere Loopback-Adresse (192.168.9.1/32) wird als Router-ID konfiguriert. Diese sechs Adressen werden in BGP exportiert, um den Inhalt einer BGP-Routingtabelle eines mit dem Internet verbundenen Routers zu emulieren und nach Norden ausgeschrieben.
Die Nord- und Süd-Router verwenden die 10.0.89.12/30- bzw. 10.0.78.12/30-Netzwerke und verwenden 192.168.7.1 und 192.168.8.1 für ihre entsprechenden Loopback-Adressen.
Abbildung 5 zeigt die in diesem Beispiel verwendete Topologie.

Router North exportiert eine Standardroute in BGP und gibt die Standardroute und die fünf BGP routen zum Router South (dem nachgeschalteten Router) an. Router South empfängt die Standardroute und nur eine andere Route (172.16.11.1/32) und installiert diese Route und die Standardroute in der Routingtabelle.
Kurz zusammengefasst erfüllt das Beispiel die folgenden Anforderungen:
Senden Sie 0/0 nach Süden, wenn auch eine bestimmte Route gesendet wird (im Beispiel 172.16.11.1/32).
Im Süden übernehmen Sie die Standardroute und die Route 172.16.11.1/32. Alle anderen Routen fallen lassen. Stellen Sie sicher, dass der Süden möglicherweise die gesamte Internettabelle empfängt, während der Netzbetreiber nur eine Standard- und ein anderes Präfix anbelange.
Als Erstes wird eine Exportrichtlinie für Nord erfüllt:
user@North# show policy-options policy-statement conditional-export-bgp { term prefix_11 { from { protocol bgp; route-filter 10.11.0.0/5 orlonger; } then accept; } term conditional-default { from { route-filter 0.0.0.0/0 exact; condition prefix_11; } then accept; } term others { then reject; } } condition prefix_11 { if-route-exists { 172.16.11.1/32; table inet.0; } }
Die Logik der bedingten Exportrichtlinie lässt sich wie folgt zusammenfassen: Wenn 0/0 vorhanden ist und 172.16.11.1/32 vorhanden ist, senden Sie das 0/0-Präfix. Das bedeutet, dass 172.16.11.1/32 nicht vorhanden ist, auch nicht 0/0 senden.
Die zweite Anforderung wird mit einer Importrichtlinie für "Süd" erfüllt:
user@South# show policy-options policy-statement import-selected-routes { term 1 { from { rib inet.0; neighbor 10.0.78.14; route-filter 0.0.0.0/0 exact; route-filter 10.11.0.0/8 orlonger; } then accept; } term 2 { then reject; } }
In diesem Beispiel werden als Folge der Importrichtlinie im Süden vier Routen gelöscht. Der Grund dafür ist, dass die Exportrichtlinie auf North alle vom Internet empfangenen Routen überlauft und einige dieser Routen von der Importrichtlinie im Süden ausgeschlossen werden.
Es ist wichtig zu verstehen, dass in Junos OS zwar eine Importrichtlinie (Inbound Route Filter) eine Route ablehnen, nicht für die Weiterleitung des Datenverkehrs verwendet wird, sie aber nicht in eine Ankündigung an andere Peers einfing, der Router diese Routen als verborgene Routen beibehalten. Diese versteckten Routen sind für Richtlinien- oder Routing-Zwecke nicht verfügbar. Sie belegen jedoch den Speicherplatz auf dem Router. Ein Dienstanbieter filtert Routen, um die Menge der Von einem Router gespeicherten und verarbeiteten Informationen zu steuern. So soll der Router die Routen, die von der Importrichtlinie abgelehnt werden, vollständig fallen lassen.
Verborgene Routen können mithilfe des Befehls angezeigt show route receive-protocol bgp neighbor-address hidden
werden. Die versteckten Routen können dann durch Konfiguration der Anweisung auf der oder auf der Hierarchieebene beibehalten oder aus der keep all | none
[edit protocols bgp]
Routingtabelle [edit protocols bgp group group-name]
gelöscht werden.
Für die BGP Routenbindung gelten folgende Regeln:
Standardmäßig werden alle aus den verschiedenen Routen gelernten BGP beibehalten, außer die, bei denen der AS-Pfad eine Schleife hat. (Der AS Pfad umfasst die lokalen AS.)
Durch die Konfiguration der Anweisung werden alle aus dem E-BGP gelernten Routen beibehalten, sogar die Routen mit der lokalen AS im AS
keep all
Pfad.Durch die Konfiguration der Anweisung BGP Routen, die von einem Peer empfangen wurden und die durch eine Importrichtlinie oder andere Überprüfungen des Ungnheitsgehalts
keep none
abgelehnt wurden. Wenn diese Erklärung konfiguriert ist und die eingehende Richtlinie geändert wird, Junos OS alle vom Peer angekündigten Routen neu aus.
Wenn Sie die Routen konfigurieren oder die Peers die Routenaktualisierung unterstützen, sendet der lokale Sprecher eine keep all
keep none
Aktualisierungsnachricht und führt eine Importauswertung durch. Für diese Peers werden die Sitzungen nicht neu gestartet. Um zu bestimmen, ob ein Peer die Aktualisierung unterstützt, prüfen Sie Peer supports Refresh capability
die Ausgabe des show bgp neighbor
Befehls.
Wenn Sie die Konfiguration konfigurieren oder der Peer den Neustart der Sitzung nicht unterstützt, werden die dazugehörigen BGP neu gestartet keep all
keep none
(flapped).
Topologie
Konfiguration
CLI-Konfiguration
Um dieses Beispiel schnell konfigurieren zu können, kopieren Sie die folgenden Befehle, fügen Sie diese in eine Textdatei ein, entfernen Sie alle Zeilenbrüche, ändern Sie alle Details, die zur Übereinstimmung mit der Netzwerkkonfiguration erforderlich sind, und kopieren Sie die Befehle, und fügen Sie die Befehle CLI der Hierarchieebene [edit]
ein.
Router Internet
set interfaces lo0 unit 0 family inet address 172.16.11.1/32 set interfaces lo0 unit 0 family inet address 172.16.12.1/32 set interfaces lo0 unit 0 family inet address 172.16.13.1/32 set interfaces lo0 unit 0 family inet address 172.16.14.1/32 set interfaces lo0 unit 0 family inet address 172.16.15.1/32 set interfaces lo0 unit 0 family inet address 192.168.9.1/32 set interfaces fe-0/1/3 unit 0 family inet address 10.0.89.14/30 set protocols bgp group toNorth local-address 10.0.89.14 set protocols bgp group toNorth peer-as 200 set protocols bgp group toNorth neighbor 10.0.89.13 set protocols bgp group toNorth export into-bgp set policy-options policy-statement into-bgp term 1 from interface lo0.0 set policy-options policy-statement into-bgp term 1 then accept set routing-options router-id 192.168.9.1 set routing-options autonomous-system 300
Router Nord
set interfaces fe-1/3/1 unit 0 family inet address 10.0.78.14/30 set interfaces fe-1/3/0 unit 0 family inet address 10.0.89.13/30 set interfaces lo0 unit 0 family inet address 192.168.8.1/32 set protocols bgp group toInternet local-address 10.0.89.13 set protocols bgp group toInternet peer-as 300 set protocols bgp group toInternet neighbor 10.0.89.14 set protocols bgp group toSouth local-address 10.0.78.14 set protocols bgp group toSouth export conditional-export-bgp set protocols bgp group toSouth peer-as 100 set protocols bgp group toSouth neighbor 10.0.78.13 set policy-options policy-statement conditional-export-bgp term prefix_11 from protocol bgp set policy-options policy-statement conditional-export-bgp term prefix_11 from route-filter 10.11.0.0/5 orlonger set policy-options policy-statement conditional-export-bgp term prefix_11 then accept set policy-options policy-statement conditional-export-bgp term conditional-default from route-filter 0.0.0.0/0 exact set policy-options policy-statement conditional-export-bgp term conditional-default from condition prefix_11 set policy-options policy-statement conditional-export-bgp term conditional-default then accept set policy-options policy-statement conditional-export-bgp term others then reject set policy-options condition prefix_11 if-route-exists 172.16.11.1/32 set policy-options condition prefix_11 if-route-exists table inet.0 set routing-options static route 0/0 reject set routing-options router-id 192.168.8.1 set routing-options autonomous-system 200
Router Süd
set interfaces fe-0/1/2 unit 0 family inet address 10.0.78.13/30 set interfaces lo0 unit 0 family inet address 192.168.7.1/32 set protocols bgp group toNorth local-address 10.0.78.13 set protocols bgp group toNorth import import-selected-routes set protocols bgp group toNorth peer-as 200 set protocols bgp group toNorth neighbor 10.0.78.14 set policy-options policy-statement import-selected-routes term 1 from neighbor 10.0.78.14 set policy-options policy-statement import-selected-routes term 1 from route-filter 10.11.0.0/8 orlonger set policy-options policy-statement import-selected-routes term 1 from route-filter 0.0.0.0/0 exact set policy-options policy-statement import-selected-routes term 1 then accept set policy-options policy-statement import-selected-routes term 2 then reject set routing-options router-id 192.168.7.1 set routing-options autonomous-system 100
Konfigurieren bedingter Präfixe
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zur Navigation in der CLI finden Sie im CLI-Editor im Konfigurationsmodus Junos OS CLI Benutzerhandbuch.
So konfigurieren Sie bedingte Installation von Präfixen:
Konfigurieren Sie die Routerschnittstellen, die die Verbindungen zwischen den drei Routern bilden.
Router Internet [edit interfaces] user@Internet# set fe-0/1/3 unit 0 family inet address 10.0.89.14/30
Router North [edit interfaces] user@North# set fe-1/3/1 unit 0 family inet address 10.0.78.14/30 user@North# set fe-1/3/0 unit 0 family inet address 10.0.89.13/30
Router South [edit interfaces] user@South# set fe-0/1/2 unit 0 family inet address 10.0.78.13/30
Konfigurieren Sie fünf Loopback-Schnittstellenadressen im Router BGP-Internet, um aus dem Internet gelernte Routen zu emulieren, die in die Routingtabelle von Router South importiert werden sollen, und konfigurieren Sie eine weitere Adresse (192.168.9.1/32), die als Router-ID konfiguriert wird.
Router Internet [edit interfaces lo0 unit 0 family inet] user@Internet# set address 172.16.11.1/32 user@Internet# set address 172.16.12.1/32 user@Internet# set address 172.16.13.1/32 user@Internet# set address 172.16.14.1/32 user@Internet# set address 172.16.15.1/32 user@Internet# set address 192.168.9.1/32
Konfigurieren Sie auch die Loopback-Schnittstellenadressen auf Routern im Norden und Süden.
Router North [edit interfaces lo0 unit 0 family inet] user@North# set address 192.168.8.1/32
Router South [edit interfaces lo0 unit 0 family inet] user@South# set address 192.168.7.1/32
Konfigurieren Sie die statische Standardroute auf Router North, um für Router South ausgeschrieben zu werden.
[edit routing-options] user@North# set static route 0/0 reject
Definieren Sie die Bedingungen für den Export von Präfixen aus der Routingtabelle auf Router North.
[edit policy-options condition prefix_11] user@North# set if-route-exists 172.16.11.1/32 user@North# set if-route-exists table inet.0
Definieren Sie Exportrichtlinien (
into-bgp
und ) auf Routern Internet und Nord, um Routen zuconditional-export-bgp
BGP.Anmerkung:Stellen Sie sicher, dass Sie in der
prefix_11
Exportrichtlinie auf den zustand (in Schritt 4 konfiguriert) verweisen.Router Internet [edit policy-options policy-statement into-bgp ] user@Internet# set term 1 from interface lo0.0 user@Internet# set term 1 then accept
Router North [edit policy-options policy-statement conditional-export-bgp] user@North# set term prefix_11 from protocol bgp user@North# set term prefix_11 from route-filter 10.11.0.0/5 orlonger user@North# set term prefix_11 then accept user@North# set term conditional-default from route-filter 0.0.0.0/0 exact user@North# set term conditional-default from condition prefix_11 user@North# set term conditional-default then accept user@North# set term others then reject
Definieren Sie eine Importrichtlinie ( ) auf Router South, um einige der von Router North angekündigten Routen in die
import-selected-routes
Routingtabelle zu importieren.[edit policy-options policy-statement import-selected-routes ] user@South# set term 1 from neighbor 10.0.78.14 user@South# set term 1 from route-filter 10.11.0.0/8 orlonger user@South# set term 1 from route-filter 0.0.0.0/0 exact user@South# set term 1 then accept user@South# set term 2 then reject
Konfigurieren BGP auf allen drei Routern, um den Präfixfluss zwischen den autonomen Systemen zu ermöglichen.
Anmerkung:Stellen Sie sicher, dass Sie die definierten Import- und Exportrichtlinien in die entsprechenden BGP für Prefix-Ankündigungen anwenden.
Router Internet [edit protocols bgp group toNorth] user@Internet# set local-address 10.0.89.14 user@Internet# set peer-as 200 user@Internet# set neighbor 10.0.89.13 user@Internet# set export into-bgp
Router North [edit protocols bgp group toInternet] user@North# set local-address 10.0.89.13 user@North# set peer-as 300 user@North# set neighbor 10.0.89.14
[edit protocols bgp group toSouth] user@North# set local-address 10.0.78.14 user@North# set peer-as 100 user@North# set neighbor 10.0.78.13 user@North# set export conditional-export-bgp
Router South [edit protocols bgp group toNorth] user@South# set local-address 10.0.78.13 user@South# set peer-as 200 user@South# set neighbor 10.0.78.14 user@South# set import import-selected-routes
Konfigurieren Sie die Router-ID und die autonome Systemnummer für alle drei Router.
Anmerkung:In diesem Beispiel wird die Router-ID basierend auf der auf der Lo0.0-Schnittstelle des Routers konfigurierten IP-Adresse konfiguriert.
Router Internet [edit routing options] user@Internet# set router-id 192.168.9.1 user@Internet# set autonomous-system 300
Router North [edit routing options] user@North# set router-id 192.168.8.1 user@North# set autonomous-system 200
Router South [edit routing options] user@South# set router-id 192.168.7.1 user@South# set autonomous-system 100
Ergebnisse
Bestätigen Sie Ihre Konfiguration im Konfigurationsmodus mit der Ausgabe von show interfaces
show protocols bgp
, und show policy-options
show routing-options
Befehlen. Wenn in der Ausgabe nicht die beabsichtigte Konfiguration angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
Internetgeräte
user@Internet# show interfaces fe-0/1/3 { unit 0 { family inet { address 10.0.89.14/30; } } } lo0 { unit 0 { family inet { address 172.16.11.1/32; address 172.16.12.1/32; address 172.16.13.1/32; address 172.16.14.1/32; address 172.16.15.1/32; address 192.168.9.1/32; } } }
user@Internet# show protocols bgp group toNorth { local-address 10.0.89.14; export into-bgp; peer-as 200; neighbor 10.0.89.13; }
user@Internet# show policy-options policy-statement into-bgp { term 1 { from interface lo0.3; then accept; } }
user@Internet# show routing-options router-id 192.168.9.1; autonomous-system 300;
Gerät North
user@North# show interfaces fe-1/3/1 { unit 0 { family inet { address 10.0.78.14/30; } } } fe-1/3/0 { unit 0 { family inet { address 10.0.89.13/30; } } } lo0 { unit 0 { family inet { address 192.168.8.1/32; } } }
user@North# show protocols bgp group toInternet { local-address 10.0.89.13; peer-as 300; neighbor 10.0.89.14; } group toSouth { local-address 10.0.78.14; export conditional-export-bgp; peer-as 100; neighbor 10.0.78.13; }
user@North# show policy-options policy-statement conditional-export-bgp { term prefix_11 { from { protocol bgp; route-filter 10.11.0.0/5 orlonger; } then accept; } term conditional-default { from { route-filter 0.0.0.0/0 exact; condition prefix_11; } then accept; } term others { then reject; } } condition prefix_11 { if-route-exists { 172.16.11.1/32; table inet.0; } }
user@North# show routing-options static { route 0.0.0.0/0 reject; } router-id 192.168.8.1; autonomous-system 200;
Gerät Im Süden
user@South# show interfaces fe-0/1/2 { unit 0 { family inet { address 10.0.78.13/30; } } } lo0 { unit 0 { family inet { address 192.168.7.1/32; } } }
user@South# show protocols bgp bgp { group toNorth { local-address 10.0.78.13; import import-selected-routes; peer-as 200; neighbor 10.0.78.14; } }
user@South# show policy-options policy-statement import-selected-routes { term 1 { from { neighbor 10.0.78.14; route-filter 10.11.0.0/8 orlonger; route-filter 0.0.0.0/0 exact; } then accept; } term 2 { then reject; } }
user@South# show routing-options router-id 192.168.7.1; autonomous-system 100;
Wenn Sie die Konfiguration der Router erledigt haben, geben Sie commit
den Konfigurationsmodus ein.
Überprüfung
Stellen Sie sicher, dass die Konfiguration ordnungsgemäß funktioniert.
- Überprüfung der BGP
- Überprüfen des Prefix-Advertisements vom Router Internet zum Router North
- Überprüfen des Prefix-Advertisements von Router Nord zu Router South
- Überprüfung der BGP Importrichtlinie für die Installation von Präfixen
- Überprüfen des bedingten Exports von Router Nord nach Router Süd
- Überprüfung von bei der Richtlinie verborgenen Routen (optional)
Überprüfung der BGP
Zweck
Stellen Sie sicher BGP Dass Sitzungen zwischen den drei Routern eingerichtet wurden.
Aktion
Führen Sie im Betriebsmodus den show bgp neighbor neighbor-address
Befehl aus.
Überprüfen Sie die BGP Sitzung im Router Internet, um zu prüfen, ob Router North ein Nachbar ist.
user@Internet> show bgp neighbor 10.0.89.13 Peer: 10.0.89.13+179 AS 200 Local: 10.0.89.14+56187 AS 300 Type: External State: Established Flags: [ImportEval Sync] Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ into-bgp ] Options: [Preference LocalAddress PeerAS Refresh] Local Address: 10.0.89.14 Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 192.168.8.1 Local ID: 192.168.9.1 Active Holdtime: 90 Keepalive Interval: 30 Group index: 0 Peer index: 0 BFD: disabled, down Local Interface: fe-0/1/3.0 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) Stale routes from peer are kept for: 300 Peer does not support Restarter functionality 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 200) 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: 0 Accepted prefixes: 0 Suppressed due to damping: 0 Advertised prefixes: 6 Last traffic (seconds): Received 9 Sent 18 Checked 28 Input messages: Total 12 Updates 1 Refreshes 0 Octets 232 Output messages: Total 14 Updates 1 Refreshes 0 Octets 383 Output Queue[0]: 0
Überprüfen Sie die BGP Sitzung auf Router North, um zu prüfen, ob das Router-Internet ein Nachbar ist.
user@North> show bgp neighbor 10.0.89.14 Peer: 10.0.89.14+56187 AS 300 Local: 10.0.89.13+179 AS 200 Type: External State: Established Flags: [ImportEval Sync] Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Options: [Preference LocalAddress PeerAS Refresh] Local Address: 10.0.89.13 Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 192.168.9.1 Local ID: 192.168.8.1 Active Holdtime: 90 Keepalive Interval: 30 Group index: 0 Peer index: 0 BFD: disabled, down Local Interface: fe-1/3/0.0 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) Stale routes from peer are kept for: 300 Peer does not support Restarter functionality 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 300) Peer does not support Addpath Table inet.0 Bit: 10001 RIB State: BGP restart is complete Send state: in sync Active prefixes: 6 Received prefixes: 6 Accepted prefixes: 6 Suppressed due to damping: 0 Advertised prefixes: 0 Last traffic (seconds): Received 14 Sent 3 Checked 3 Input messages: Total 16 Updates 2 Refreshes 0 Octets 402 Output messages: Total 15 Updates 0 Refreshes 0 Octets 348 Output Queue[0]: 0
Überprüfen Sie die folgenden Felder in diesen Ausgaben, um zu prüfen BGP Dass Sitzungen eingerichtet wurden:
Peer—Prüfen Sie, ob die Peer AS nummer aufgeführt ist.
Local— Prüfen Sie, ob die lokale AS aufgeführt ist.
State— Sicherstellen, dass der Wert
Established
liegt. Wenn nicht, überprüfen Sie die Konfiguration erneut, undshow bgp neighbor
sehen Sie weitere Details zu den Ausgabefeldern.
Stellen Sie in ähnlicher Weise sicher, dass Router im Norden und Süden Peer-Beziehungen untereinander bilden.
Bedeutung
BGP sitzungen werden zwischen den drei Routern eingerichtet.
Überprüfen des Prefix-Advertisements vom Router Internet zum Router North
Zweck
Stellen Sie sicher, dass die vom Router Internet gesendeten Routen von Router North empfangen werden.
Aktion
Führen Sie im Betriebsmodus im Router-Internet den
show route advertising-protocol bgp neighbor-address
Befehl aus.user@Internet> show route advertising-protocol bgp 10.0.89.13 inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.11.1/32 Self I * 172.16.12.1/32 Self I * 172.16.13.1/32 Self I * 172.16.14.1/32 Self I * 172.16.15.1/32 Self I * 192.168.9.1/32 Self I
Die Ausgabe überprüft, ob Router Internet die Routen ausspricht 172.16.11.1/32, 172.16.12.1/32, 172.16.13.1/32, 172.16.14.1/32, 172.16.15.1/32 und 192.168.9.1/32 (die als Router-ID verwendete Loopback-Adresse) für Router North.
Führen Sie im Betriebsmodus auf Router North den
show route receive-protocol bgp neighbor-address
Befehl aus.user@North> show route receive-protocol bgp 10.0.89.14 inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.11.1/32 10.0.89.14 300 I * 172.16.12.1/32 10.0.89.14 300 I * 172.16.13.1/32 10.0.89.14 300 I * 172.16.14.1/32 10.0.89.14 300 I * 172.16.15.1/32 10.0.89.14 300 I * 192.168.9.1/32 10.0.89.14 300 I
Mit der Ausgabe wird überprüft, ob Router North alle vom Router Internet angekündigten Routen erhalten hat.
Bedeutung
Vom Router Internet gesendete Präfixe wurden erfolgreich in der Routingtabelle auf Router North installiert.
Überprüfen des Prefix-Advertisements von Router Nord zu Router South
Zweck
Stellen Sie sicher, dass die vom Router-Internet empfangenen Routen und die statische Standardroute vom Router North zum Router South angegeben werden.
Aktion
Führen Sie im Betriebsmodus auf Router North den
show route 0/0 exact
Befehl aus.user@North> show route 0/0 exact inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/5] 00:10:22 Reject
Die Ausgabe überprüft das Vorhandensein der statischen Standardroute (0.0.0.0/0) in der Routingtabelle auf Router North.
Führen Sie im Betriebsmodus auf Router North den
show route advertising-protocol bgp neighbor-address
Befehl aus.user@North> show route advertising-protocol bgp 10.0.78.13 inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 0.0.0.0/0 Self I * 172.16.11.1/32 Self 300 I * 172.16.12.1/32 Self 300 I * 172.16.13.1/32 Self 300 I * 172.16.14.1/32 Self 300 I * 172.16.15.1/32 Self 300 I
Die Ausgabe überprüft, ob Router North die statische Route und die Route 172.16.11.1/32 an Router Internet sowie viele andere Routen nach Router South meldet.
Überprüfung der BGP Importrichtlinie für die Installation von Präfixen
Zweck
Stellen Sie sicher, dass BGP Richtlinie die erforderlichen Präfixe erfolgreich installiert.
Aktion
Prüfen Sie, ob die Importrichtlinie auf Router South in Betrieb ist, indem Sie prüfen, ob nur die statische Standardroute von Router North und die Route 172.16.11.1/32 von Router South in der Routingtabelle installiert sind.
Führen Sie im Betriebsmodus den show route receive-protocol bgp neighbor-address
Befehl aus.
user@South> show route receive-protocol bgp 10.0.78.14 inet.0: 10 destinations, 11 routes (6 active, 0 holddown, 4 hidden) Prefix Nexthop MED Lclpref AS path * 0.0.0.0/0 10.0.78.14 200 I * 172.16.11.1/32 10.0.78.14 200 300 I
Die Ausgabe überprüft, ob die BGP-Importrichtlinie auf Router South einsatzbereit ist, und nur die statische Standardroute 0.0.0.0/0 von Router North und die 172.16.11.1/32-Route vom Router Internet wurden in die Routingtabelle auf Router South übertragen.
Bedeutung
Die Installation von Präfixen ist aufgrund der konfigurierten Importrichtlinie BGP erfolgreich.
Überprüfen des bedingten Exports von Router Nord nach Router Süd
Zweck
Stellen Sie sicher, dass Gerät North das Senden der Standard-0-Route nach 172.16.11.1/32 stoppt, wenn das Geräte-Internet den Versand der Standardroute nach 172.16.11.1/32 verhindert.
Aktion
Verursachen, dass das Geräte-Internet die 172.16.11.1/32-Route nicht mehr sendet, indem die 172.16.11.1/32-Adresse auf der Loopback-Schnittstelle deaktiviert wird.
[edit interfaces lo0 unit 0 family inet] user@Internet# deactivate address 172.16.11.1/32 user@Internet# commit
Führen Sie im Betriebsmodus auf Router North den
show route advertising-protocol bgp neighbor-address
Befehl aus.user@North> show route advertising-protocol bgp 10.0.78.13 inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.12.1/32 Self 300 I * 172.16.13.1/32 Self 300 I * 172.16.14.1/32 Self 300 I * 172.16.15.1/32 Self 300 I
Die Ausgabe überprüft, ob Router North nicht die Standardroute zu Router South meldet. Dies ist das erwartete Verhalten, wenn die 172.16.11.1/32-Route nicht vorhanden ist.
Reaktivierung der 172.16.11.1/32-Adresse auf der Loopback-Schnittstelle von Device Internet.
[edit interfaces lo0 unit 0 family inet] user@Internet# activate address 172.16.11.1/32 user@Internet# commit
Überprüfung von bei der Richtlinie verborgenen Routen (optional)
Zweck
Überprüfen Sie das Vorhandensein von Routen, die unter der Importrichtlinie auf Router South konfiguriert sind.
In diesem Abschnitt werden die Auswirkungen verschiedener Änderungen veranschaulicht, die je nach Ihren Anforderungen an der Konfiguration vorgenommen werden können.
Aktion
Zeigen Sie in der Routing-Tabelle von Router South verborgene Routen an wie:
Verwenden der
hidden
Option für denshow route receive-protocol bgp neighbor-address
Befehl.Deaktivierung der Importrichtlinie.
Führen Sie im Betriebsmodus den
show route receive-protocol bgp neighbor-address hidden
Befehl aus, um verborgene Routen zu anzeigen.user@South> show route receive-protocol bgp 10.0.78.14 hidden inet.0: 10 destinations, 11 routes (6 active, 0 holddown, 4 hidden) Prefix Nexthop MED Lclpref AS path 172.16.12.1/32 10.0.78.14 200 300 I 172.16.13.1/32 10.0.78.14 200 300 I 172.16.14.1/32 10.0.78.14 200 300 I 172.16.15.1/32 10.0.78.14 200 300 I
Die Ausgabe überprüft das Vorhandensein von Routen, die von der Importrichtlinie verborgen sind (172.16.12.1/32, 172.16.13.1/32, 172.16.14.1/32 und 172.16.15.1/32) auf Router South.
Deaktivieren Sie BGP Richtlinien für den Import, indem Sie die
deactivate import
Anweisung auf der[edit protocols bgp group group-name]
Hierarchieebene konfigurieren.[edit protocols bgp group toNorth] user@South# deactivate import user@South# commit
Führen Sie den
show route receive-protocol bgp neighbor-address
Betriebsmodusbefehl aus, um die Routen nach der Deaktivierung der Importrichtlinie zu prüfen.user@South> show route receive-protocol bgp 10.0.78.14 inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 0.0.0.0/0 10.0.78.14 200 I * 172.16.11.1/32 10.0.78.14 200 300 I * 172.16.12.1/32 10.0.78.14 200 300 I * 172.16.13.1/32 10.0.78.14 200 300 I * 172.16.14.1/32 10.0.78.14 200 300 I * 172.16.15.1/32 10.0.78.14 200 300 I
Die Ausgabe überprüft das Vorhandensein bisher nicht da gewesener Routen (172.16.12.1/32, 172.16.13.1/32, 172.16.14.1/32 und 172.16.15.1/32).
Aktivieren Sie BGP Importrichtlinie, und entfernen Sie die versteckten Routen aus der Routingtabelle, indem Sie die Anweisungen und Anweisungen auf
activate import
keep none
der[edit protocols bgp group group-name]
Hierarchieebene konfigurieren.[edit protocols bgp group toNorth] user@South# activate import user@South# set keep none user@South# commit
Führen Sie im Betriebsmodus den Befehl aus, um die Routen zu prüfen, nachdem Sie die
show route receive-protocol bgp neighbor-address hidden
Importrichtlinie aktiviert und die Anweisungkeep none
konfiguriert haben.user@South> show route receive-protocol bgp 10.0.78.14 hidden inet.0: 6 destinations, 7 routes (6 active, 0 holddown, 0 hidden)
Die Ausgabe überprüft, ob die versteckten Routen aufgrund der konfigurierten Anweisung nicht in der Routingtabelle gepflegt
keep none
werden.
Impliziter Filter für Standard-EBGP-Routenausbreitung ohne Richtlinien
SUMMARY In diesem Abschnitt wird die Verwendung eines impliziten Filters zur Regulierung des Verbreitungsverhaltens der EBGP-Route erläutert, wenn keine expliziten Richtlinien konfiguriert sind.
Nutzen
Diese Funktion bietet folgende Vorteile:
Regulates BGP implementation— Verhindert, dass EBGP-Sprecher ein unbedredner Pass-Through werden, bei dem alle Routen standardmäßig akzeptiert und angeboten werden. Diese Funktion sorgt für eine wirksame Hebung des Transitdatenverkehrs in autonomen Leaf-Systemen, besonders wenn sie mehrfach (Multi-Homed) mit jedem upstream Internet Service Provider genutzt werden. So verhindert sie auch den leisen Ausfall des Datenverkehrs, Denial of Service (DoS) sowie globale Internetausfälle.
Implicit filter—Die Konfiguration vereinfacht die Verwendung eines impliziten Filters, bei dem das Standardverhalten weiterhin auf das Empfangen und Ankündigung standardmäßiger Routen festgelegt ist. In der Konfigurationsauszugs-Anweisung wird nur eine Option zum Aktivieren oder Deaktivieren für "Akzeptieren", "Ablehnen" und "Ablehnen" fügt sich, wenn erforderlich, die Option zum Aktivieren oder Deaktivieren von Klauseln hinzu. Der implizite Filter stellt sicher, dass Benutzer mit vorhandenen Implementierungen, die auf der Standardrichtlinie basieren, BGP Betriebsunterbrechungen erleben.
Überblick
BGP ist das aktuelle autonome Protokoll zwischen domänenübergreifenden Protokollen, das für das globale Internet-Routing verwendet wird. Es unterstützt auch verschiedene Dienste wie VPNs und Verbindungsstatus, die nicht für die globale Nutzung bestimmt sind.
BGP Implementierung einschließlich des Standard-EBGP-Verhaltens wird von RFC4271, A Border Gateway Protocol 4 (BGP-4) geleitet. Sie enthält jedoch keine expliziten Anweisungen zur Festlegung der zu verteilenden Routen. Dies führt dazu, dass BGP Implementierung für Routen ohne jegliche Filterung eine geräuschlose Pass-Through-Verbindung ist und daher zu einem Anstieg des Datenverkehrs und weltweiten Internetausfällen führt.
Wir haben Junos OS der 20.3R1 und einen impliziten Filter auf der vorhandenen defaults ebgp no-policy
[edit protocols bgp]
Hierarchieebene eingeführt. Die Konfiguration trennt die Standardrichtlinie für Empfang und Ankündigung in separate Klauseln (akzeptieren, ablehnen oder ablehnen) und ermöglicht so, dass das Verhalten unabhängig voneinander variieren kann.
Wenn keine explizite Richtlinie konfiguriert ist, können Sie mit dem impliziten Filter das eBGP-Standard-Empfangs- und Werbeverhalten in einem von drei Zuständen aktivieren:
Werte |
Standardrichtlinie |
Was es kann |
---|---|---|
Akzeptieren |
Erhalten |
Akzeptiert den Erhalt aller Routen (auch das Standardverhalten). |
Werben |
Akzeptiert die Ankündigung aller Routen (auch das Standardverhalten). |
|
Ablehnen |
Erhalten |
Das Empfangen von Routen von Typ-Inet-Unicast- und Inet6-Unicast in Instanztypen primär, VRF, virtueller Router und Nichtweiterleitung wird abgelehnt. |
Werben |
Das Anzeigen von Routen von Typ-Inet-Unicast und Inet6-Unicast in Instanztypen primär, VRF, virtueller Router und Nichtweiterleitung wird abgelehnt. |
|
immer ablehnen |
Erhalten |
Wird zum Empfang aller Routen abgelehnt. |
Werben |
Wird abgelehnt, um alle Routen ausgeschrieben zu haben. |