Auf dieser Seite
Beispiel: Anwenden von Routing-Richtlinien auf verschiedenen Ebenen der BGP-Hierarchie
Beispiel: Einfügen von OSPF-Routen in die BGP-Routing-Tabelle
Konfigurieren von Routing-Richtlinien zur Steuerung von BGP-Routenankündigungen
Beispiel: Konfigurieren der BGP-Präfix-basierten Filterung ausgehender Routen
Grundlegendes zur standardmäßigen BGP-Routing-Richtlinie auf Paketübertragungs-Routern (PTX-Serie)
Bedingte Ankündigung, die die bedingte Installation von Präfixen ermöglicht Anwendungsfälle
Impliziter Filter für das standardmäßige EBGP-Routenweitergabeverhalten ohne Richtlinien
Grundlegende BGP-Routing-Richtlinien
Grundlegendes zu Routing-Richtlinien
Jede Routingrichtlinie wird durch einen Richtliniennamen identifiziert. Der Name kann Buchstaben, Zahlen und Bindestriche (-) enthalten und bis zu 255 Zeichen lang sein. Wenn Sie Leerzeichen im Namen einfügen möchten, schließen Sie den gesamten Namen in doppelte Anführungszeichen ein. Der Name jeder Routingrichtlinie muss innerhalb einer Konfiguration eindeutig sein.
Nachdem eine Richtlinie erstellt und benannt wurde, muss sie angewendet werden, bevor sie aktiv wird. Routing-Richtlinien wenden Sie mithilfe der und-Anweisungen importexport auf der Ebene in der protocols protocol-name Konfigurationshierarchie an.
In der import Anweisung geben Sie den Namen der Routing-Richtlinie an, die ausgewertet werden soll, wenn Routen aus dem Routing-Protokoll in die Routing-Tabelle importiert werden.
In der export Anweisung geben Sie den Namen der Routing-Richtlinie an, die ausgewertet werden soll, wenn Routen aus der Routing-Tabelle in ein dynamisches Routing-Protokoll exportiert werden. Nur aktive Routen werden aus der Routing-Tabelle exportiert.
Um mehr als eine Richtlinie anzugeben und eine Richtlinienkette zu erstellen, listen Sie die Richtlinien mit einem Leerzeichen als Trennzeichen auf. Wenn mehrere Richtlinien angegeben sind, werden die Richtlinien in der Reihenfolge ausgewertet, in der sie angegeben wurden. Sobald eine Annahme- oder Ablehnungsaktion ausgeführt wird, endet die Richtlinienkettenauswertung.
Siehe auch
Beispiel: Anwenden von Routing-Richtlinien auf verschiedenen Ebenen der BGP-Hierarchie
Dieses Beispiel zeigt die BGP-Konfiguration in einer einfachen Netzwerktopologie und erläutert, wie Routing-Richtlinien wirksam werden, wenn sie auf verschiedenen Ebenen der BGP-Konfiguration angewendet werden.
Anforderungen
Vor der Konfiguration dieses Beispiels ist keine spezielle Konfiguration erforderlich, die über die Geräteinitialisierung hinausgeht.
Überblick
Für BGP können Sie Richtlinien wie folgt anwenden:
BGP global
importand-Anweisungenexport: Fügen Sie diese Anweisungen auf Hierarchieebene[edit protocols bgp]ein (für Routing-Instanzen schließen Sie diese Anweisungen auf Hierarchieebene[edit routing-instances routing-instance-name protocols bgp]ein).Gruppe
importundexportAnweisungen: Fügen Sie diese Anweisungen auf Hierarchieebene[edit protocols bgp group group-name]ein (für Routing-Instanzen schließen Sie diese Anweisungen auf Hierarchieebene[edit routing-instances routing-instance-name protocols bgp group group-name]ein).importPeer undexportAnweisungen: Fügen Sie diese Anweisungen auf Hierarchieebene[edit protocols bgp group group-name neighbor address]ein (für Routing-Instanzen schließen Sie diese Anweisungen auf Hierarchieebene[edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]ein).
Eine Peerebene import oder export Anweisung überschreibt eine Gruppe import oder export Anweisung. Eine Anweisung auf Gruppenebene import überschreibt export eine globale BGP import oder export Anweisung.
In diesem Beispiel wird eine Richtlinie mit dem Namen send-direct auf globaler Ebene angewendet, eine andere Richtlinie mit dem Namen send-192.168.0.1 wird auf Gruppenebene angewendet und eine dritte Richtlinie mit dem Namen send-192.168.20.1 wird auf Nachbarebene 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 missverstanden wird und zu Problemen führen kann, ist, dass in einer solchen Konfiguration nur die expliziteste Richtlinie angewendet wird. Eine Richtlinie auf Nachbarschaftsebene ist expliziter als eine Richtlinie auf Gruppenebene, die wiederum expliziter ist als eine globale Richtlinie.
Der Nachbar 172.16.2.2 unterliegt nur der Richtlinie send-192.168.20.1. Der Nachbar 172.16.3.3 unterliegt nur der Richtlinie send-192.168.0.1. In der Zwischenzeit hat Nachbar 172.16.4.4 in der Gruppe other-group keine Richtlinie auf Gruppen- oder Nachbarebene, daher wird die Richtlinie send-direct verwendet.
Wenn Nachbar 172.16.2.2 die Funktion aller drei Richtlinien ausführen soll, können Sie eine neue Richtlinie auf Nachbarebene schreiben und anwenden, die die Funktionen der anderen drei umfasst, oder Sie können alle drei vorhandenen Richtlinien als Kette auf Nachbar 172.16.2.2 anwenden.
Topologie
Abbildung 1 zeigt das Beispielnetzwerk an.
CLI-Schnellkonfiguration Zeigt die Konfiguration für alle Geräte in Abbildung 1an.
In diesem Abschnitt #d100e205__d100e459 werden die Schritte auf Gerät R1 beschrieben.
Konfiguration
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für Ihre Netzwerkkonfiguration erforderlich sind, und kopieren Sie dann die Befehle und fügen Sie sie in die CLI auf Hierarchieebene [edit] ein.
Gerät 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-Anleitung
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Weitere Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI-Benutzerhandbuch.
So konfigurieren Sie eine IS-IS-Standardroutenrichtlinie:
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 Sie OSPF oder ein anderes Interior Gateway Protocols (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
Konfigurieren Sie statische 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 Sie die 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 Sie BGP, und wenden Sie die Exportrichtlinien an.
[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 AS-Nummer (Autonomous System).
[edit routing-options] user@R1# set router-id 172.16.1.1 user@R1# set autonomous-system 17
Wenn Sie mit der Konfiguration des Geräts fertig sind, bestätigen Sie die Konfiguration.
[edit] user@R1# commit
Ergebnisse
Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie die show interfacesBefehle , show protocols, show policy-optionsund show routing-options eingeben. Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@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;
Verifizierung
Vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.
Verifizieren des BGP-Routenlernens
Zweck
Stellen Sie sicher, dass die BGP-Exportrichtlinien wie erwartet funktionieren, indem Sie die Routing-Tabellen überprüfen.
Action!
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
Discarduser@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.0user@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.0user@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.0Bedeutung
Auf Gerät R1 zeigt der show route protocol direct Befehl zwei direkte Routen 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 show route protocol bgp Befehl an, dass die einzige Route, die Gerät R2 über BGP gelernt hat, die Route 192.168.20.1/32 ist.
Auf Gerät R3 zeigt der show route protocol bgp Befehl an, dass die einzige Route, die Gerät R3 über BGP gelernt hat, die Route 192.168.0.1/32 ist.
Auf Gerät R4 zeigt der show route protocol bgp Befehl an, dass die einzigen Routen, die Gerät R4 über BGP gelernt hat, die Routen 172.16.1.1/32 und 10.10.10.0/30 sind.
Überprüfen des BGP-Routenempfangs
Zweck
Stellen Sie sicher, dass die BGP-Exportrichtlinien wie erwartet funktionieren, indem Sie die von Gerät R1 empfangenen BGP-Routen überprüfen.
Action!
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 route receive-protocol bgp 172.16.1.1 Befehl an, dass Gerät R2 nur eine BGP-Route, 192.168.20.1/32, von Gerät R1 empfangen hat.
Auf Gerät R3 zeigt der route receive-protocol bgp 172.16.1.1 Befehl an, dass Gerät R3 nur eine BGP-Route, 192.168.0.1/32, von Gerät R1 empfangen hat.
Auf Gerät R4 zeigt der route receive-protocol bgp 172.16.1.1 Befehl an, dass Gerät R4 zwei BGP-Routen, 172.16.1.1/32 und 10.10.10.0/30, von Gerät R1 empfangen hat.
Zusammenfassend lässt sich sagen, dass, wenn mehrere Richtlinien auf verschiedene CLI-Hierarchien in BGP angewendet werden, nur die spezifischste Anwendung ausgewertet wird, während andere, weniger spezifische Richtlinienanwendungen ausgeschlossen werden. Obwohl dieser Punkt sinnvoll erscheint, wird er bei der Routerkonfiguration leicht vergessen, wenn Sie fälschlicherweise glauben, dass eine Richtlinie auf Nachbarebene mit einer globalen Richtlinie oder einer Richtlinie auf Gruppenebene kombiniert wird, nur um festzustellen, dass Ihr Richtlinienverhalten nicht wie erwartet ist.
Beispiel: Einfügen von OSPF-Routen in die BGP-Routing-Tabelle
In diesem Beispiel wird gezeigt, wie eine Richtlinie erstellt wird, die OSPF-Routen in die BGP-Routingtabelle einfügt.
Anforderungen
Bevor Sie beginnen:
Konfigurieren Sie Netzwerkschnittstellen.
Konfigurieren Sie externe Peersitzungen. Siehe Beispiel: Konfigurieren externer BGP-Punkt-zu-Punkt-Peer-Sitzungen
Konfigurieren Sie IGP-Sitzungen (Interior Gateway Protocol) zwischen Peers.
Überblick
In diesem Beispiel erstellen Sie eine Routingrichtlinie mit dem Namen injectpolicy1 und einen Routingbegriff mit dem Namen injectterm1. Die Richtlinie fügt OSPF-Routen in die BGP-Routing-Tabelle ein.
Topologie
Konfiguration
Konfigurieren der Routing-Richtlinie
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für Ihre Netzwerkkonfiguration erforderlich sind, kopieren Sie die Befehle und fügen Sie sie in die CLI auf der Hierarchieebene [edit] ein, und geben Sie sie dann im Konfigurationsmodus ein commit .
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-Anleitung
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Weitere Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI-Benutzerhandbuch.
So fügen Sie OSPF-Routen in eine BGP-Routing-Tabelle ein:
Erstellen Sie den Richtlinienbegriff.
[edit policy-options policy-statement injectpolicy1] user@host# set term injectterm1
Geben Sie 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 die Route akzeptiert werden soll, wenn die vorherigen Bedingungen erfüllt sind.
[edit policy-options policy-statement injectpolicy1 term injectterm1] user@host# set then accept
Wenden Sie die Routing-Richtlinie auf BGP an.
[edit] user@host# set protocols bgp export injectpolicy1
Ergebnisse
Bestätigen Sie Ihre Konfiguration, indem Sie die Befehle und show protocols bgp aus dem show policy-optionsKonfigurationsmodus eingeben. Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, 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 mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf commit .
Konfigurieren der Ablaufverfolgung für die Routingrichtlinie
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für Ihre Netzwerkkonfiguration erforderlich sind, kopieren Sie die Befehle und fügen Sie sie in die CLI auf der Hierarchieebene [edit] ein, und geben Sie sie dann im Konfigurationsmodus ein commit .
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-Anleitung
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Weitere Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI-Benutzerhandbuch.
Fügen Sie eine Ablaufverfolgungsaktion 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ätigen Sie Ihre Konfiguration, indem Sie die Befehle und show routing-options aus dem show policy-optionsKonfigurationsmodus eingeben. Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, 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 mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf commit .
Verifizierung
Fehlerbehebung
Verwenden des Befehls show log zum Untersuchen der Aktionen der Routingrichtlinie
Problem
Die Routing-Tabelle enthält unerwartete Routen, oder Routen fehlen in der Routing-Tabelle.
Lösung
Wenn Sie die Richtlinienablaufverfolgung wie in diesem Beispiel gezeigt konfigurieren, können Sie den show log ospf-bgp-policy-log Befehl ausführen, um Probleme mit der Routingrichtlinie zu diagnostizieren. Der show log ospf-bgp-policy-log Befehl zeigt Informationen zu den Routen an, die der injectpolicy1 Richtlinienbegriff analysiert und auf die er reagiert.
Konfigurieren von Routing-Richtlinien zur Steuerung von BGP-Routenankündigungen
Alle Routing-Protokolle verwenden die Routing-Tabelle von Junos OS, um die erlernten Routen zu speichern und zu bestimmen, welche Routen sie in ihren Protokollpaketen ankündigen sollen. Mit der Routing-Richtlinie können Sie steuern, welche Routen die Routing-Protokolle in der Routing-Tabelle speichern und abrufen. Weitere Informationen zu Routingrichtlinien finden Sie im Benutzerhandbuch für Routingrichtlinien, Firewallfilter und Traffic Policers.
Bei der Konfiguration der BGP-Routing-Richtlinie können Sie die folgenden Aufgaben ausführen:
- Anwenden der Routing-Richtlinie
- Festlegen von BGP für die Ankündigung inaktiver Routen
- BGP so konfigurieren, dass internen Peers die beste externe Route angekündigt wird
- Konfigurieren der Häufigkeit, mit der BGP Routen mit der Routing-Tabelle austauscht
- Deaktivieren der Unterdrückung von Routenankündigungen
Anwenden der Routing-Richtlinie
Sie definieren die Routing-Richtlinie auf Hierarchieebene [edit policy-options] . Um Richtlinien anzuwenden, die Sie für BGP definiert haben, fügen Sie die import Anweisungen and export in die BGP-Konfiguration ein.
Sie können Richtlinien wie folgt anwenden:
BGP global
importand-Anweisungenexport: Fügen Sie diese Anweisungen auf Hierarchieebene[edit protocols bgp]ein (für Routing-Instanzen schließen Sie diese Anweisungen auf Hierarchieebene[edit routing-instances routing-instance-name protocols bgp]ein).Gruppe
importundexportAnweisungen: Fügen Sie diese Anweisungen auf Hierarchieebene[edit protocols bgp group group-name]ein (für Routing-Instanzen schließen Sie diese Anweisungen auf Hierarchieebene[edit routing-instances routing-instance-name protocols bgp group group-name]ein).importPeer undexportAnweisungen: Fügen Sie diese Anweisungen auf Hierarchieebene[edit protocols bgp group group-name neighbor address]ein (für Routing-Instanzen schließen Sie diese Anweisungen auf Hierarchieebene[edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]ein).
Eine Peerebene import oder export Anweisung überschreibt eine Gruppe import oder export Anweisung. Eine Anweisung auf Gruppenebene import überschreibt export eine globale BGP import oder export Anweisung.
Informationen zum Anwenden von Richtlinien finden Sie in den folgenden Abschnitten:
- Anwenden von Richtlinien auf Routen, die von BGP in die Routing-Tabelle importiert werden
- Anwenden von Richtlinien auf Routen, die aus der Routing-Tabelle in BGP exportiert werden
Anwenden von Richtlinien auf Routen, die von BGP in die Routing-Tabelle importiert werden
Um eine Richtlinie auf Routen anzuwenden, die aus BGP in die Routing-Tabelle importiert werden, fügen Sie die import Anweisung ein, in der die Namen einer oder mehrerer zu bewertender Richtlinien aufgeführt sind:
import [ policy-names ];
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt Anweisungszusammenfassung für diese Anweisung.
Wenn Sie mehr als eine Richtlinie angeben, werden diese in der angegebenen Reihenfolge von der ersten bis zur letzten ausgewertet, und der erste übereinstimmende Filter wird auf die Route angewendet. Wenn keine Übereinstimmung gefunden wird, fügt BGP nur die Routen in die Routing-Tabelle ein, die von BGP-Routing-Geräten gelernt wurden.
Anwenden von Richtlinien auf Routen, die aus der Routing-Tabelle in BGP exportiert werden
Um eine Richtlinie auf Routen anzuwenden, die aus der Routing-Tabelle in BGP exportiert werden, fügen Sie die export Anweisung ein, in der die Namen einer oder mehrerer zu bewertender Richtlinien aufgeführt sind:
export [ policy-names ];
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt Anweisungszusammenfassung für diese Anweisung.
Wenn Sie mehr als eine Richtlinie angeben, werden diese in der angegebenen Reihenfolge von der ersten bis zur letzten ausgewertet, und der erste übereinstimmende Filter wird auf die Route angewendet. Wenn keine Routen mit den Filtern übereinstimmen, exportiert die Routing-Tabelle nur die Routen, die sie von BGP gelernt hat, in BGP.
Festlegen von BGP für die Ankündigung inaktiver Routen
Standardmäßig speichert BGP die Routeninformationen, die es von Aktualisierungsmeldungen erhält, in der Routing-Tabelle von Junos OS, und die Routing-Tabelle exportiert nur aktive Routen in BGP, die BGP dann seinen Peers ankündigt. Damit die Routing-Tabelle die beste von BGP gelernte Route in BGP exportiert, auch wenn Junos OS sie nicht als aktive Route ausgewählt hat, fügen Sie die advertise-inactive folgende Anweisung ein:
advertise-inactive;
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt Anweisungszusammenfassung für diese Anweisung.
BGP so konfigurieren, dass internen Peers die beste externe Route angekündigt wird
Im Allgemeinen kündigen bereitgestellte BGP-Implementierungen die externe Route mit dem höchsten lokalen Präferenzwert internen Peers nicht an, es sei denn, es handelt sich um die beste Route. Obwohl dieses Verhalten in einer früheren Version der BGP-Spezifikation Version 4, RFC 1771, gefordert wurde, wurde es in der Regel nicht befolgt, um die Menge der angekündigten Informationen zu minimieren und Routingschleifen zu vermeiden. Es gibt jedoch Szenarien, in denen die Werbung für die beste externe Route von Vorteil ist, insbesondere Situationen, die zu IBGP-Routenoszillationen führen können.
In Junos OS Version 9.3 und höher können Sie BGP so konfigurieren, dass die beste externe Route in eine interne BGP (IBGP)-Mesh-Gruppe, einen Routenreflektor-Cluster oder eine AS-Konföderation (Autonomous System) angekündigt wird, selbst wenn die beste Route eine interne Route ist.
Um die advertise-external Anweisung für einen Routenreflektor zu konfigurieren, müssen Sie die clusterinterne Reflektion mit der no-client-reflect Anweisung deaktivieren.
Wenn ein Routinggerät als Routenreflektor für einen Cluster konfiguriert ist, wird eine vom Routenreflektor angekündigte Route als intern betrachtet, wenn sie von einem internen Peer mit derselben Cluster-ID empfangen wird oder wenn für beide Peers keine Cluster-ID konfiguriert ist. Eine Route, die von einem internen Peer empfangen wird, der zu einem anderen Cluster gehört, d. h. mit einer anderen Cluster-ID, wird als extern betrachtet.
Wenn in einer Konföderation eine Route zu einem Konföderationsgrenzrouter angekündigt wird, wird jede Route von einem anderen Konföderations-Sub-AS als extern betrachtet.
Sie können BGP auch so konfigurieren, dass die externe Route nur dann angekündigt wird, wenn der Routenauswahlprozess den Punkt erreicht, an dem die MED-Metrik (Multiple Exit Discriminator) ausgewertet wird. Daher wird eine externe Route mit einem AS-Pfad, der schlechter (d. h. länger) als der des aktiven Pfads ist, nicht angekündigt.
Junos OS bietet auch Unterstützung für die Konfiguration einer BGP-Exportrichtlinie, die mit dem Status einer angekündigten Route übereinstimmt. Sie können eine Übereinstimmung entweder auf aktiven oder inaktiven Routen durchführen. Weitere Informationen finden Sie im Benutzerhandbuch zu Routing-Richtlinien, Firewall-Filtern und Traffic Policers.
Um BGP so zu konfigurieren, dass der beste externe Pfad für interne Peers angekündigt wird, fügen Sie die advertise-external folgende Anweisung ein:
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 aufgeteilt.
Eine vollständige Liste der Hierarchieebenen, auf denen Sie diese Anweisung konfigurieren können, finden Sie im Abschnitt Anweisungszusammenfassung zu dieser Anweisung.
Fügen Sie die conditional folgende Anweisung ein, um BGP so zu konfigurieren, dass der beste externe Pfad nur dann angekündigt wird, wenn der Routenauswahlprozess den Punkt erreicht, an dem der MED-Wert ausgewertet wird:
advertise-external {
conditional;
}
Konfigurieren der Häufigkeit, mit der BGP Routen mit der Routing-Tabelle austauscht
BGP speichert die Routeninformationen, die es von Aktualisierungsnachrichten erhält, in der Routing-Tabelle, und die Routing-Tabelle exportiert aktive Routen aus der Routing-Tabelle in BGP. BGP kündigt dann die exportierten Routen seinen Peers an. Standardmäßig erfolgt der Austausch von Routeninformationen zwischen BGP und der Routing-Tabelle unmittelbar nach dem Empfang der Routen. Dieser unmittelbare Austausch von Routeninformationen kann zu Instabilitäten in den Informationen zur Netzwerkerreichbarkeit führen. Um dies zu verhindern, können Sie die Zeit zwischen dem Austausch von Routeninformationen zwischen BGP und der Routing-Tabelle verzögern.
Um zu konfigurieren, wie oft BGP und die Routing-Tabelle Routeninformationen austauschen, fügen Sie die out-delay folgende Anweisung ein:
out-delay seconds;
Standardmäßig behält die Routing-Tabelle einige der von BGP gelernten Routeninformationen bei. Damit die Routing-Tabelle alle oder keine dieser Informationen beibehält, fügen Sie die keep folgende Anweisung ein:
keep (all | none);
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisungen einschließen können, finden Sie in den Abschnitten zur Anweisungszusammenfassung für diese Anweisungen.
Die Routing-Tabelle kann die von BGP gelernten Routeninformationen auf eine der folgenden Arten beibehalten:
Standard (Anweisung
keepweglassen): Behalten Sie alle Routeninformationen bei, die von BGP gelernt wurden, mit Ausnahme von Routen, deren AS-Pfad eine Schleife ist und deren Schleife den lokalen AS enthält.keep all—Behalten Sie alle Routeninformationen bei, die von BGP gelernt wurden.keep none: Routen verwerfen, die von einem Peer empfangen wurden und die durch Importrichtlinien oder andere Plausibilitätsprüfungen wie AS-Pfad oder nächster Hop abgelehnt wurden. Wenn Sie die BGP-Sitzung konfigurierenkeep noneund sich die eingehenden Richtlinien ändern, erzwingt Junos OS die erneute Ankündigung des vollständigen Satzes von Routen, die vom Peer angekündigt wurden.
In einer AS-Pfad-Heilungssituation könnten Routen mit Schleifenpfaden theoretisch während einer weichen Rekonfiguration nutzbar werden, wenn die AS-Pfad-Schleifenbegrenzung geändert wird. Es gibt jedoch einen erheblichen Unterschied bei der Speichernutzung zwischen der Standardeinstellung und keep all.
Betrachten Sie die folgenden Szenarien:
Ein Peer kündigt Routen erneut an den Peer zurück, von dem er sie gelernt hat.
Dies kann in folgenden Fällen der Fall sein:
Das Routinggerät eines anderen Anbieters kündigt die Routen zurück an den sendenden Peer an.
Das Standardverhalten des Junos OS-Peers, Routen nicht erneut an den sendenden Peer anzukündigen, wird durch die Konfiguration
advertise-peer-asvon .
Ein Provider-Edge-Routinggerät (PE) verwirft jede VPN-Route, die keines der erwarteten Routenziele hat.
Wenn keep all diese Option konfiguriert ist, wird das Verhalten beim Verwerfen von Routen, die in den obigen Szenarien empfangen wurden, überschrieben.
Deaktivieren der Unterdrückung von Routenankündigungen
Junos OS kündigt die von einem EBGP-Peer gelernten Routen nicht an denselben externen BGP-Peer (EBGP) an. Darüber hinaus kündigt die Software diese Routen nicht an EBGP-Peers an, die sich in derselben AS wie der ursprüngliche Peer befinden, unabhängig von der Routing-Instanz. Sie können dieses Verhalten ändern, indem Sie die advertise-peer-as Anweisung in die Konfiguration aufnehmen. Um die standardmäßige Werbeunterdrückung zu deaktivieren, fügen Sie die advertise-peer-as folgende Anweisung ein:
advertise-peer-as;
Das Standardverhalten der Routenunterdrückung ist deaktiviert, wenn die as-override Anweisung in der Konfiguration enthalten ist.
Wenn Sie die advertise-peer-as Anweisung in die Konfiguration aufnehmen, kündigt BGP die Route unabhängig von dieser Prüfung an.
Um das Standardverhalten wiederherzustellen, fügen Sie die no-advertise-peer-as Anweisung in die Konfiguration ein:
no-advertise-peer-as;
Wenn Sie sowohl die as-override Anweisung als no-advertise-peer-as auch in die Konfiguration aufnehmen, wird die no-advertise-peer-as Anweisung ignoriert. Sie können diese Anweisungen auf mehreren Hierarchieebenen einbinden.
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisungen einschließen können, finden Sie im Abschnitt Anweisungszusammenfassung für diese Anweisungen.
Siehe auch
Beispiel: Konfigurieren einer Routingrichtlinie, um internen Peers die beste externe Route anzukündigen
Die BGP-Protokollspezifikation, wie in RFC 1771 definiert, gibt an, dass ein BGP-Peer seinen internen Peers den externen Pfad mit höherer Präferenz ankündigen muss, auch wenn dieser Pfad insgesamt nicht der beste ist (mit anderen Worten, selbst wenn der beste Pfad ein interner Pfad ist). In der Praxis folgen bereitgestellte BGP-Implementierungen dieser Regel nicht. Die Gründe für die Abweichung von der Spezifikation sind wie folgt:
Minimierung der Menge der beworbenen Informationen. BGP skaliert entsprechend der Anzahl der verfügbaren Pfade.
Vermeiden von Routing- und Weiterleitungsschleifen.
Es gibt jedoch mehrere Szenarien, in denen das in RFC 1771 spezifizierte Verhalten, die beste externe Route anzukündigen, von Vorteil sein kann. Eine Begrenzung der Pfadinformationen ist nicht immer wünschenswert, da die Pfadvielfalt dazu beitragen kann, die Wiederherstellungszeiten zu verkürzen. Durch die Ankündigung des besten externen Pfads können auch interne BGP (IBGP)-Routenoszillationsprobleme behoben werden, wie in RFC 3345, Border Gateway Protocol (BGP) Persistent Route Oscillation Condition, beschrieben.
Die advertise-external Anweisung ändert das Verhalten eines BGP-Sprechers, um IBGP-Peers den besten externen Pfad anzukündigen, selbst wenn der beste Gesamtpfad ein interner 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 aufgeteilt.
Die conditional Option schränkt das Verhalten der advertise-external Einstellung ein, sodass die externe Route nur dann angekündigt wird, wenn der Routenauswahlprozess den Punkt erreicht, an dem die MED-Metrik (Multiple Exit Discriminator) ausgewertet wird. So wird eine externe Route nicht angekündigt, wenn sie z.B. einen AS-Pfad hat, der schlechter (länger) ist als der des aktiven Pfades. Die conditional Option schränkt die Ankündigung externer Pfade bis zum MED-Schritt des Routenauswahlprozesses auf den Zeitpunkt ein, in dem der beste externe Pfad und der aktive Pfad gleich sind. Beachten Sie, dass die Kriterien für die Auswahl des besten externen Pfads dieselben sind, unabhängig davon, ob die conditional Option konfiguriert ist oder nicht.
Junos OS bietet auch Unterstützung für die Konfiguration einer BGP-Exportrichtlinie, die mit dem Status einer angekündigten Route übereinstimmt. Sie können aktive oder inaktive Routen wie folgt abgleichen:
policy-options {
policy-statement name{
from state (active|inactive);
}
}
Dieser Qualifizierer stimmt nur überein, wenn er im Kontext einer Exportrichtlinie verwendet wird. Wenn eine Route von einem Protokoll angekündigt wird, das inaktive Routen ankündigen kann (z. B. BGP), stimmt dies mit Routen überein, state inactive die als Ergebnis der advertise-inactive and-Anweisungen advertise-external angekündigt wurden.
Die folgende Konfiguration kann beispielsweise als BGP-Exportrichtlinie für interne Peers verwendet werden, um Routen, die aufgrund der advertise-external Einstellung angekündigt wurden, mit einer benutzerdefinierten Community zu markieren. Diese Community kann später von den empfangenden Routern verwendet werden, um solche Routen aus der Weiterleitungstabelle herauszufiltern. Ein solcher Mechanismus kann verwendet werden, um Bedenken auszuräumen, dass Werbepfade, die vom Absender nicht für die 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 ist erforderlich.
Überblick
Dieses Beispiel zeigt drei Routing-Geräte. Gerät R2 verfügt über eine externe BGP-Verbindung (EBGP) zu Gerät R1. Gerät R2 verfügt über eine IBGP-Verbindung zu Gerät R3.
Gerät R1 wirbt mit 172.16.6.0/24. Gerät R2 legt die lokale Einstellung in einer Importrichtlinie für die Routen von Gerät R1 nicht fest, und daher hat 172.16.6.0/24 die lokale Standardeinstellung von 100.
Gerät R3 kündigt 172.16.6.0/24 mit einer lokalen Präferenz von 200 an.
Wenn die advertise-external Anweisung auf Gerät R2 nicht konfiguriert ist, wird 172.16.6.0/24 nicht von Gerät R2 für Gerät R3 angekündigt.
Wenn die advertise-external Anweisung auf Gerät R2 in der Sitzung für Gerät R3 konfiguriert ist, wird 172.16.6.0/24 von Gerät R2 für Gerät R3 angekündigt.
Wenn advertise-external conditional 172.16.6.0/24 auf Gerät R2 in der Sitzung für Gerät R3 konfiguriert ist, wird es von Gerät R2 gegenüber Gerät R3 nicht angekündigt. Wenn Sie die then local-preference 200 Einstellung auf Gerät R3 entfernen und die path-selection as-path-ignore Einstellung auf Gerät R2 hinzufügen (wodurch die Pfadauswahlkriterien bis zum MED-Schritt des Routenauswahlprozesses gleich werden), wird 172.16.6.0/24 von Gerät R2 für Gerät R3 angekündigt.
Um die advertise-external Anweisung auf einem Routenreflektor zu konfigurieren, müssen Sie die clusterinterne Reflektion mit der no-client-reflect Anweisung deaktivieren, und der Clientcluster muss vollständig vernetzt sein, um das Senden redundanter Routenankündigungen zu verhindern.
Wenn ein Routinggerät als Routenreflektor für einen Cluster konfiguriert ist, wird eine vom Routenreflektor angekündigte Route als intern betrachtet, wenn sie von einem internen Peer mit derselben Cluster-ID empfangen wird oder wenn für beide Peers keine Cluster-ID konfiguriert ist. Eine Route, die von einem internen Peer empfangen wird, der zu einem anderen Cluster gehört, d. h. mit einer anderen Cluster-ID, wird als extern betrachtet.
Topologie
Abbildung 2 zeigt das Beispielnetzwerk an.
CLI-Schnellkonfiguration Zeigt die Konfiguration für alle Geräte in Abbildung 2an.
In diesem Abschnitt #d103e169__d103e347 werden die Schritte auf Gerät R2 beschrieben.
Konfiguration
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für Ihre Netzwerkkonfiguration erforderlich sind, und kopieren Sie dann die Befehle und fügen Sie sie in die CLI auf Hierarchieebene [edit] ein.
Gerät 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-Anleitung
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Weitere Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI-Benutzerhandbuch.
So konfigurieren Sie Gerät 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
Konfigurieren Sie OSPF oder ein anderes 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
Konfigurieren Sie die EBGP-Verbindung mit Gerät R1.
[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 mit 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 die
advertise-externalAnweisung der IBGP-Gruppenpeering-Sitzung hinzu.[edit protocols bgp group int] user@R2# set advertise-external
Konfigurieren Sie die AS-Nummer (Autonomous System) 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 im Konfigurationsmodus Ihre Konfiguration, indem Sie die show interfacesBefehle , show protocols, show policy-optionsund show routing-options eingeben. Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@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 mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf commit .
Verifizierung
Vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.
- Verifizieren des aktiven BGP-Pfads
- Überprüfen der externen Routenankündigung
- Verifizieren der Route auf Gerät R3
- Experimentieren mit der bedingten Option
Verifizieren 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 über den erwarteten aktiven Pfad verfügt.
Action!
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 sowohl von Gerät R1 als auch von Gerät R3. Die Route von Gerät R3 ist der aktive Pfad, der durch das Sternchen (*) gekennzeichnet ist. Der aktive Pfad hat die höchste lokale Präferenz. Selbst wenn die lokalen Einstellungen der beiden Routen gleich wären, würde die Route von Gerät R3 aktiv bleiben, da es den kürzesten AS-Pfad hat.
Überprüfen der externen Routenankündigung
Zweck
Stellen Sie sicher, dass auf Gerät R2 die Route 172.16.6.0/24 für Gerät R3 angekündigt wird.
Action!
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 kündigt die Route 172.16.6.0/24 zu Gerät R3 an.
Verifizieren der Route auf Gerät R3
Zweck
Stellen Sie sicher, dass das Präfix 172.16.6.0/24 in der Routing-Tabelle von Gerät R3 enthalten ist.
Action!
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.6Bedeutung
Gerät R3 verfügt über die statische Route und die BGP-Route für 172.16.6.0/24.
Beachten Sie, dass die BGP-Route auf Gerät R3 ausgeblendet wird, wenn die Route nicht erreichbar ist oder wenn der nächste Hop nicht aufgelö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).
Experimentieren mit der bedingten Option
Zweck
Erfahren Sie, wie die conditional Option im Kontext des BGP-Pfadauswahlalgorithmus funktioniert.
Action!
Fügen Sie auf Gerät R2 die
conditionalOption hinzu.[edit protocols bgp group int] user@R2# set advertise-external conditional user@R2# commit
Überprüfen Sie auf Gerät R2, ob die Route 172.16.6.0/24 für Gerät R3 angekündigt wird.
user@R2> show route advertising-protocol bgp 192.168.0.3
Wie erwartet wird die Strecke nicht mehr ausgeschrieben. Möglicherweise müssen Sie einige Sekunden warten, um dieses Ergebnis zu sehen.
Deaktivieren Sie auf Gerät R3 die
then local-preferenceRichtlinienaktion.[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.0Fügen Sie auf Gerät R2 die
as-path-ignoreAnweisung hinzu.[edit protocols bgp] user@R2# set path-selection as-path-ignore user@R2# commit
Überprüfen Sie auf Gerät R2, ob die Route 172.16.6.0/24 für 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 angekündigt, da die AS-Pfadlänge ignoriert wird und die lokalen Einstellungen gleich sind.
Beispiel: Konfigurieren der BGP-Präfix-basierten Filterung ausgehender Routen
In diesem Beispiel wird gezeigt, wie ein Router von Juniper Networks so konfiguriert wird, dass er Routenfilter von Remote-Peers akzeptiert und die Filterung ausgehender Routen mithilfe der empfangenen Filter durchführt.
Anforderungen
Bevor Sie beginnen:
Konfigurieren Sie die Routerschnittstellen.
Konfigurieren Sie ein Interior Gateway Protocol (IGP).
Überblick
Sie können einen BGP-Peer so konfigurieren, dass er Routenfilter von Remote-Peers akzeptiert und die Filterung ausgehender Routen mithilfe der empfangenen Filter durchführt. Durch das Herausfiltern unerwünschter Updates spart der sendende Peer Ressourcen, die zum Generieren und Übertragen von Updates benötigt werden, und der empfangende Peer spart Ressourcen, die zum Verarbeiten von Updates benötigt werden. Diese Funktion kann z. B. in einem virtuellen privaten Netzwerk (VPN) nützlich sein, in dem Teilmengen von Kunden-Edge-Geräten (CE) nicht in der Lage sind, alle Routen im VPN zu verarbeiten. Die CE-Geräte können präfixbasierte ausgehende Routenfilterung verwenden, um mit dem Provider-Edge-Routinggerät (PE) zu kommunizieren und nur eine Teilmenge der Routen zu übertragen, z. B. nur Routen zu den Hauptdatencentern.
Die maximale Anzahl präfixbasierter ausgehender Routenfilter, die ein BGP-Peer akzeptieren kann, beträgt 5000. Wenn ein Remote-Peer mehr als 5000 ausgehende Routenfilter an eine Peer-Adresse sendet, werden die zusätzlichen Filter verworfen, und es wird eine Systemprotokollmeldung generiert.
Sie können die Interoperabilität für das Routinggerät als Ganzes oder nur für bestimmte BGP-Gruppen oder Peers konfigurieren.
Topologie
Im Beispielnetzwerk handelt es sich bei Gerät CE1 um einen Router eines anderen Anbieters. Die in diesem Beispiel gezeigte Konfiguration befindet sich auf dem Juniper Networks Router PE1.
Abbildung 3 zeigt das Beispielnetzwerk an.
Konfiguration
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für Ihre Netzwerkkonfiguration erforderlich sind, und kopieren Sie dann die Befehle und fügen Sie sie in die CLI auf Hierarchieebene [edit] ein.
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-Anleitung
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Weitere Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI-Benutzerhandbuch.
So konfigurieren Sie Router PE1 so, dass er Routenfilter von Gerät CE1 akzeptiert und die Filterung ausgehender Routen mithilfe der empfangenen Filter durchführt:
Konfigurieren Sie das lokale autonome System.
[edit routing-options] user@PE1# set autonomous-system 65500
Konfigurieren Sie externes Peering mit Gerät 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 so, dass er IPv4-Routenfilter von Gerät CE1 akzeptiert und die Filterung ausgehender Routen mit den empfangenen Filtern durchführt.
[edit protocols bgp group cisco-peers] user@PE1# set outbound-route-filter prefix-based accept inet
(Optional) Aktivieren Sie die Interoperabilität mit Routing-Geräten, die den herstellerspezifischen Kompatibilitätscode 130 für ausgehende Routenfilter und den Codetyp 128 verwenden.
Der IANA-Standardcode ist 3 und der Standardcodetyp ist 64.
[edit protocols bgp group cisco-peers] user@PE1# set outbound-route-filter bgp-orf-cisco-mode
Ergebnisse
Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie die show protocols Befehle und show routing-options eingeben. Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@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 mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf commit .
Verifizierung
Vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.
Überprüfen des Filters für ausgehende Routen
Zweck
Zeigt Informationen über den präfixbasierten ausgehenden Routenfilter an, der von Gerät CE1 empfangen wurde.
Action!
Geben Sie im Betriebsmodus den show bgp neighbor orf detail Befehl 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üfen des BGP-Nachbarmodus
Zweck
Stellen Sie sicher, dass die bgp-orf-cisco-mode Einstellung für den Peer aktiviert ist, indem Sie sicherstellen, dass die ORFCiscoMode Option in der show bgp neighbor Befehlsausgabe angezeigt wird.
Action!
Geben Sie im Betriebsmodus den show bgp neighbor Befehl 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
Grundlegendes zur standardmäßigen BGP-Routing-Richtlinie auf Paketübertragungs-Routern (PTX-Serie)
Auf Paketübertragungs-Routern der PTX-Serie unterscheidet sich die standardmäßige BGP-Routing-Richtlinie von der anderer Junos OS-Routing-Geräte. Die standardmäßige Routing-Richtlinie der Router der PTX-Serie 3000 und 5000 installiert keine BGP-Routen in der Weiterleitungstabelle, es sei denn, Sie konfigurieren eine andere Richtlinie, um sie außer Kraft zu setzen. Alle anderen Router der PTX-Serie installieren BGP-gelernte Routen zur Forwarding Information Base (FIB) und Packet Forwading Engine (PFE), ohne dass eine Richtlinie erforderlich ist.
Bei den Routern der PTX-Serie handelt es sich um MPLS-Transitplattformen, die IP-Weiterleitungsfunktionen durchführen und in der Regel IGP-Routen (Interior Gateway Protocol) verwenden. Die Paketweiterleitungs-Engine der PTX-Serie kann eine relativ kleine Anzahl von Präfixen variabler Länge aufnehmen.
Ein Router der PTX-Serie kann vollständige BGP-Routen in der Steuerungsebene unterstützen, sodass er als Routenreflektor (RR) verwendet werden kann. Er kann eine Multicastweiterleitung mit exakter Länge durchführen und die Multicastweiterleitungsebene für die Verwendung durch die Unicast-Steuerungsebene erstellen (z. B. um eine Weiterleitungssuche für den umgekehrten Pfad für Multicast durchzuführen).
Aufgrund der PFE-Einschränkung sieht die Standard-Routing-Richtlinie für Router der PTX-Serie vor, dass BGP-Routen nicht in der Weiterleitungstabelle installiert werden. Sie können die standardmäßige Routing-Richtlinie außer Kraft setzen und bestimmte BGP-Routen auswählen, die in der Weiterleitungstabelle installiert werden sollen.
Das Standardverhalten für Load Balancing und BGP-Routen auf Routern der PTX-Serie lautet wie folgt. Es hat die folgenden wünschenswerten Eigenschaften:
Ermöglicht es Ihnen, das Standardverhalten außer Kraft zu setzen, ohne die Standardrichtlinie direkt ändern zu müssen
Verringert die Wahrscheinlichkeit versehentlicher Änderungen, die die Standardeinstellungen aufheben
Legt keine Flusssteuerungsaktionen fest, wie z. B. Annehmen und Ablehnen
Die standardmäßige Routing-Richtlinie auf den Routern der PTX-Serie lautet wie folgt:
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 hier gezeigt, ist die junos-ptx-series-default Richtlinie in [edit policy-options]definiert. Die Richtlinie wird in [edit routing-options forwarding-table]angewendet, wobei die Anweisung verwendet wird default-export . Sie können diese Standardkonfigurationen mithilfe des Flags | display inheritance anzeigen.
Sie können den show policy Befehl auch verwenden, um die Standardrichtlinie anzuzeigen.
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-packetEs wird dringend empfohlen, die junos-ptx-series-default Routingrichtlinie nicht direkt zu ändern.
Junos OS verkettet die junos-ptx-series-default Richtlinie und alle vom Benutzer konfigurierten Exportrichtlinien. Da die junos-ptx-series-default Richtlinie keine Flusssteuerungsaktionen verwendet, wird jede von Ihnen konfigurierte Exportrichtlinie (über die implizite Aktion next-policy) für jede Route ausgeführt. Daher können Sie alle von der junos-ptx-series-default Richtlinie festgelegten Aktionen außer Kraft setzen. Wenn Sie keine Exportrichtlinie konfigurieren, sind die von junos-ptx-series-default der Richtlinie festgelegten Aktionen die einzigen Aktionen.
Sie können die Richtlinienaktion install-to-fib verwenden, um die no-install-to-fib Aktion außer Kraft zu setzen.
Auf ähnliche Weise können Sie die load-balance per-prefix Aktion so festlegen, dass sie die load-balance per-packet Aktion außer Kraft setzt.
Siehe auch
Beispiel: Überschreiben der standardmäßigen BGP-Routing-Richtlinie auf Paketübertragungs-Routern der PTX-Serie
In diesem Beispiel wird gezeigt, wie die Standardroutingrichtlinie auf Paketübertragungsroutern, wie z. B. den Paketübertragungsroutern der PTX-Serie, außer Kraft gesetzt wird.
Anforderungen
Für dieses Beispiel ist Junos OS Version 12.1 oder höher erforderlich.
Überblick
Standardmäßig installieren die Router der PTX-Serie keine BGP-Routen in der Weiterleitungstabelle.
Bei Routern der PTX-Serie hat die Konfiguration der from protocols bgp Bedingung mit der then accept Aktion nicht das übliche Ergebnis, das sie auf anderen Junos OS-Routing-Geräten hat. Mit der folgenden Routing-Richtlinie auf Routern der PTX-Serie werden BGP-Routen 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
In der Weiterleitungstabelle sind keine BGP-Routen installiert. Dies ist das erwartete Verhalten.
In diesem Beispiel wird gezeigt, wie die then install-to-fib Aktion verwendet wird, um die standardmäßige BGP-Routing-Richtlinie effektiv außer Kraft zu setzen.
Konfiguration
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für Ihre Netzwerkkonfiguration erforderlich sind, und kopieren Sie dann die Befehle und fügen Sie sie in die CLI auf Hierarchieebene [edit] ein.
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
Installieren ausgewählter BGP-Routen in der Weiterleitungstabelle
Schritt-für-Schritt-Anleitung
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Weitere Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI-Benutzerhandbuch.
So installieren Sie ausgewählte BGP-Routen in der Weiterleitungstabelle:
Konfigurieren Sie eine Liste von Präfixen, die in der Weiterleitungstabelle installiert werden sollen.
[edit policy-options prefix-list install-bgp] user@host# set 66.0.0.1/32
Konfigurieren Sie die Routingrichtlinie, und wenden Sie die Präfixliste als Bedingung 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 Routingrichtlinie auf die Weiterleitungstabelle an.
[edit routing-options forwarding-table] user@host# set export override-ptx-series-default
Ergebnisse
Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie die show policy-options Befehle und show routing-options eingeben. Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@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 mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf commit .
Verifizierung
Vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.
Überprüfen, ob die ausgewählte Route in der Weiterleitungstabelle installiert ist
Zweck
Stellen Sie sicher, dass die konfigurierte Richtlinie die Standardrichtlinie außer Kraft setzt.
Action!
Geben Sie im Betriebsmodus den show route forwarding-table Befehl 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, die die bedingte Installation von Präfixen ermöglicht Anwendungsfälle
Netzwerke sind in der Regel in kleinere, leichter zu verwaltende Einheiten unterteilt, die als autonome Systeme (ASs) bezeichnet werden. Wenn BGP von Routern verwendet wird, um Peer-Beziehungen im selben AS zu bilden, wird es als internes BGP (IBGP) bezeichnet. Wenn BGP von Routern verwendet wird, um Peer-Beziehungen in verschiedenen ASs aufzubauen, wird dies als externes BGP (EBGP) bezeichnet.
Nach dem Ausführen von Routen-Plausibilitätsprüfungen akzeptiert ein BGP-Router die von seinen Peers empfangenen Routen und installiert sie in der Routing-Tabelle. Standardmäßig befolgen alle Router in IBGP- und EBGP-Sitzungen die standardmäßigen BGP-Ankündigungsregeln. Während ein Router in einer IBGP-Sitzung nur die Routen ankündigt, die er von seinen direkten Peers gelernt hat, kündigt ein Router in einer EBGP-Sitzung alle Routen an, die er von seinen direkten und indirekten Peers (Peers of Peers) gelernt hat. Daher fügt ein Router in einem typischen Netzwerk, das mit EBGP konfiguriert ist, alle von einem EBGP-Peer empfangenen Routen zu seiner Routing-Tabelle hinzu und kündigt fast alle Routen an alle EBGP-Peers an.
Ein Service Provider, der BGP-Routen sowohl mit Kunden als auch mit Peers im Internet austauscht, ist dem Risiko böswilliger und unbeabsichtigter Bedrohungen ausgesetzt, die das ordnungsgemäße Routing des Datenverkehrs sowie den Betrieb der Router beeinträchtigen können.
Dies hat mehrere Nachteile:
Non-aggregated route advertisements—Ein Kunde könnte dem ISP fälschlicherweise alle seine Präfixe ankündigen und nicht eine Summe seines Adressraums. Angesichts der Größe der Internet-Routingtabelle muss dies sorgfältig kontrolliert werden. Ein Edge-Router benötigt möglicherweise auch nur eine Standardroute zum Internet und empfängt stattdessen die gesamte BGP-Routing-Tabelle von seinem Upstream-Peer.
BGP route manipulation—Wenn ein böswilliger Administrator den Inhalt der BGP-Routing-Tabelle ändert, kann er verhindern, dass der Datenverkehr sein beabsichtigtes Ziel erreicht.
BGP route hijacking—Ein unbefugter Administrator eines BGP-Peers könnte in böswilliger Absicht die Präfixe eines Netzwerks ankündigen, um den für das Netzwerk des Opfers bestimmten Datenverkehr in das Netzwerk des Administrators umzuleiten, um entweder Zugriff auf den Inhalt des Datenverkehrs 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-Ressourcen des Routers zu nutzen, kann dies dazu führen, dass die Fähigkeit des Routers, gültige BGP-Routeninformationen zu verarbeiten, beeinträchtigt wird.
Die bedingte Installation von Präfixen kann verwendet werden, um alle zuvor genannten Probleme zu beheben. Wenn ein Kunde Zugriff auf Remote-Netzwerke benötigt, ist es möglich, eine bestimmte Route in der Routing-Tabelle des Routers zu installieren, der mit dem Remote-Netzwerk verbunden ist. Dies ist in einem typischen EBGP-Netzwerk nicht der Fall, weshalb eine bedingte Installation von Präfixen unerlässlich ist.
AS sind nicht nur durch physische Beziehungen, sondern auch durch geschäftliche oder andere organisatorische Beziehungen gebunden. Ein AS kann Services für eine andere Organisation bereitstellen oder als Transit-AS zwischen zwei anderen AS fungieren. Diese Transit-ASs sind an vertragliche Vereinbarungen zwischen den Parteien gebunden, die Parameter für die Verbindung untereinander und vor allem die Art und Menge des Datenverkehrs, den sie füreinander befördern, enthalten. Daher müssen Service Provider sowohl aus rechtlichen als auch aus finanziellen Gründen 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 stehen viele verschiedene Optionen zum Filtern von Routen zur Verfügung, die von einem BGP-Peer empfangen werden, um sowohl Inter-AS-Richtlinien durchzusetzen als auch das Risiko des Empfangs potenziell schädlicher Routen zu mindern. Die konventionelle Routenfilterung untersucht die Attribute einer Route und akzeptiert oder lehnt die Route basierend auf diesen Attributen ab. Eine Richtlinie oder ein Filter kann den Inhalt des AS-Pfads, den Wert für den nächsten Hop, einen Community-Wert, eine Liste von Präfixen, die Adressfamilie der Route usw. untersuchen.
In einigen Fällen reicht die standardmäßige "Akzeptanzbedingung" für die Übereinstimmung mit einem bestimmten Attributwert nicht aus. Möglicherweise muss der Dienstanbieter eine andere Bedingung außerhalb der Route selbst verwenden, z. B. eine andere Route in der Routing-Tabelle. Beispielsweise kann es wünschenswert sein, eine Standardroute zu installieren, die von einem Upstreampeer empfangen wird, nur wenn überprüft werden kann, dass dieser Peer für andere Netzwerke weiter vorgelagert erreichbar ist. Durch diese Installation bedingter Routen wird die Installation einer Standardroute vermieden, die zum Senden von Datenverkehr an diesen Peer verwendet wird, wenn der Peer möglicherweise seine Routen stromaufwärts verloren hat, was zu Datenverkehr mit schwarzen Löchern geführt hat. Um dies zu erreichen, kann der Router so konfiguriert werden, dass er nach dem Vorhandensein einer bestimmten Route in der Routing-Tabelle sucht und basierend auf diesem Wissen ein anderes Präfix akzeptiert oder ablehnt.
Beispiel: Konfigurieren einer Routingrichtlinie für bedingte Ankündigung Aktivieren der bedingten Installation von Präfixen in einer Routingtabelle erläutert, wie die bedingte Installation von Präfixen konfiguriert und überprüft werden kann.
Siehe auch
Bedingte Ankündigung und Importrichtlinie (Routing-Tabelle) mit bestimmten Übereinstimmungsbedingungen
BGP akzeptiert alle nicht geloopten Routen, die von Nachbarn gelernt wurden, und importiert sie in die RIB-In-Tabelle. Wenn diese Routen von der BGP-Importrichtlinie akzeptiert werden, werden sie in die inet.0-Routing-Tabelle importiert. In Fällen, in denen nur bestimmte Routen importiert werden müssen, kann vorgesehen werden, dass das Peerroutinggerät Routen basierend auf einer Bedingung oder einer Reihe von Bedingungen exportiert.
Die Bedingung für den Export einer Route kann auf folgenden Faktoren basieren:
Der Peer, von dem die Route gelernt wurde
Die Schnittstelle, auf der die Route gelernt wurde
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 in Beispiel: Konfigurieren einer Routingrichtlinie für bedingte Ankündigung Aktivieren der bedingten Installation von Präfixen in einer Routingtabelle.
Bedingungen in Routing-Richtlinien können unabhängig davon konfiguriert werden, ob sie Teil der Export- oder Importrichtlinien oder beider sind. Die Exportrichtlinie unterstützt diese Bedingungen, die von der Routingrichtlinie geerbt wurden, basierend auf dem Vorhandensein einer anderen Route in der Routingrichtlinie . Die Importrichtlinie unterstützt diese Bedingungenjedochnicht , und die Bedingungen werden auch dann nicht ausgeführt, wenn sie vorhandensind.
Abbildung 4 veranschaulicht, wo BGP-Import- und -Exportrichtlinien angewendet werden. Eine Importrichtlinie wird auf eingehende Routen angewendet, die in der Ausgabe des show route receive-protocol bgp neighbor-address Befehls sichtbar sind. Eine Exportrichtlinie wird auf ausgehende Routen angewendet, die in der Ausgabe des show route advertising-protocol bgp neighbor-address Befehls sichtbar sind.
Um die bedingte Installation von Präfixen zu ermöglichen, muss auf dem Gerät, auf dem der Präfixexport stattfinden soll, eine Exportrichtlinie konfiguriert werden. Die Exportrichtlinie wertet jede Route aus, um sicherzustellen, dass sie alle Übereinstimmungsbedingungen gemäß der from Anweisung erfüllt. Außerdem wird nach der Existenz der Route gesucht, die unter der condition Anweisung definiert ist (die ebenfalls unter der from Anweisung konfiguriert ist).
Wenn die Route nicht mit dem gesamten Satz der erforderlichen Bedingungen übereinstimmt, die in der Richtlinie definiert sind, oder wenn die unter der condition Anweisung definierte Route nicht in der Routing-Tabelle vorhanden ist, wird die Route nicht in ihre BGP-Peers exportiert. Daher stimmt eine bedingte Exportrichtlinie mit den Routen für die gewünschte Route oder das gewünschte Präfix überein, das bzw. das in der Routing-Tabelle der Peers installiert werden soll.
So konfigurieren Sie die bedingte Installation von Präfixen mit Hilfe einer Exportrichtlinie:
Erstellen Sie eine
conditionAnweisung, um Präfixe zu überprüfen.[edit] policy-options { condition condition-name { if-route-exists address table table-name; } }Erstellen Sie mithilfe der
conditionAnweisung eine Exportrichtlinie mit der neu erstellten 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, bei dem nur ausgewählte Präfixe aus der Routing-Tabelle exportiert werden müssen.
[edit] protocols bgp { group group-name { export policy-name; } }
Siehe auch
Beispiel: Konfigurieren einer Routingrichtlinie für bedingte Ankündigung Aktivieren der bedingten Installation von Präfixen in einer Routingtabelle
In diesem Beispiel wird gezeigt, wie die bedingte Installation von Präfixen in einer Routingtabelle mithilfe der BGP-Exportrichtlinie konfiguriert wird.
Anforderungen
In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:
Multiservice-Edge-Router der M-Serie, universelle 5G-Routing-Plattformen der MX-Serie oder Core-Router der T-Serie
Junos OS Version 9.0 oder höher
Überblick
In diesem Beispiel sind drei Router in drei verschiedenen autonomen Systemen (ASs) verbunden und mit dem BGP-Protokoll konfiguriert. Der Router mit der Bezeichnung Internet, bei dem es sich um den Upstream-Router handelt, verfügt über fünf Adressen, die auf seiner lo0.0-Loopback-Schnittstelle konfiguriert sind (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 zusätzliche Loopback-Adresse (192.168.9.1/32) ist 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 North angekündigt.
Die Router Nord und Süd verwenden die Netzwerke 10.0.89.12/30 bzw. 10.0.78.12/30 und verwenden 192.168.7.1 und 192.168.8.1 für ihre jeweiligen Loopback-Adressen.
Abbildung 5 Zeigt die in diesem Beispiel verwendete Topologie.
Router Nord exportiert die 172.16.0.0/16 BGP-Routen , die er vom Router Internet lernt, zu Router Süd. Diese Routen können die Routen darstellen, die sich im Besitz der Domäne des Internetrouters befinden. Wenn die spezifische Route 172.16.11.1/32 vorhanden ist, kündigt Router Nord außerdem eine Standardroutean. Die Route 172.16.11.1 kann die Verbindung des Internetrouters zu einem Transitpeeringanbieter der Ebene 1 darstellen, der vollständige Internetkonnektivität bereitstellt.
Router Süd empfängt alle sechs Routen, sollte aber nur die Standardroute und eine weitere spezifische Route (172.16.11.1/32) in seiner Routing-Tabelle installieren.
Zusammenfassend lässt sich sagen, dass das Beispiel die folgenden Anforderungen erfüllt:
-
Senden Sie auf Norden alle 172.16/16-Präfixe. Senden Sie außerdem nur dann 0/0 nach Süden, wenn eine bestimmte Route in der Routing-Tabelle inet.0 vorhanden ist (in diesem Beispiel 172.16.11.1/32).
-
Akzeptieren und installieren Sie unter "Süden" die Standardroute und die Route 172.16.11.1/32 in den Routing- und Weiterleitungstabellen. Lassen Sie alle anderen Routen fallen. Bedenken Sie, dass South möglicherweise ein Gerät der unteren Preisklasse ist , das keine vollständige Internet-Routingtabelle akzeptieren kann. Daher möchte der Betreiber nur, dass South die Standardroute und ein weiteres spezifisches Präfix hat.
Die erste Anforderung wird mit einer Exportpolitik für den Norden erfüllt:
user@North# show policy-options
policy-statement conditional-export-bgp {
term prefix_11 {
from {
protocol bgp;
route-filter 172.16.0.0/16 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 kann wie folgt zusammengefasst werden: Wenn 0/0 vorhanden ist und 172.16.11.1/32 vorhanden ist, senden Sie das Präfix 0/0. Dies bedeutet, dass, wenn 172.16.11.1/32 nicht vorhanden ist, 0/0 nicht gesendet wird.
Die zweite Anforderung wird mit einer Importpolitik für den Süden 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 172.16.11.1/32 exact;
}
then accept;
}
term 2 {
then reject;
}
}
In diesem Beispiel werden vier Routen aufgrund der Importrichtlinie für "Süden" verworfen. Dies liegt daran, dass die Exportrichtlinie für Norden alle vom Internet empfangenen Routen durchsickern lässt und die Importrichtlinie für Süd einige dieser Routen ausschließt.
Es ist wichtig zu verstehen, dass in Junos OS zwar eine Importrichtlinie (Filter für eingehende Routen) eine Route ablehnen, sie nicht für die Weiterleitung des Datenverkehrs verwenden und sie nicht in eine Ankündigung für andere Peers aufnehmen kann, der Router diese Routen jedoch als versteckte Routen beibehält. Diese ausgeblendeten Routen sind für Richtlinien- oder Routingzwecke nicht verfügbar. Sie belegen jedoch Speicherplatz auf dem Router. Ein Dienstanbieter, der Routen filtert, um die Menge der Informationen zu steuern, die im Arbeitsspeicher gehalten und von einem Router verarbeitet werden, möchte möglicherweise, dass der Router die Routen, die von der Importrichtlinie abgelehnt werden, vollständig verwirft.
Ausgeblendete Routen können mit dem show route receive-protocol bgp neighbor-address hidden Befehl angezeigt werden. Die ausgeblendeten Routen können dann beibehalten oder aus der Routing-Tabelle gelöscht werden, indem die keep all | none Anweisung auf der [edit protocols bgp] Hierarchieebene or [edit protocols bgp group group-name] konfiguriert wird.
Die Regeln für die BGP-Routenaufbewahrung lauten wie folgt:
-
Standardmäßig werden alle von BGP gelernten Routen beibehalten, mit Ausnahme derjenigen, bei denen der AS-Pfad in einer Schleife ausgeführt wird. (Der AS-Pfad enthält den lokalen AS.)
-
Durch die Konfiguration der
keep allAnweisung werden alle von BGP gelernten Routen beibehalten, auch diejenigen mit dem lokalen AS im AS-Pfad. -
Durch Konfigurieren der
keep noneAnweisung verwirft BGP Routen, die von einem Peer empfangen und von der Importrichtlinie oder einer anderen Plausibilitätsprüfung abgelehnt wurden. Wenn diese Anweisung konfiguriert ist und sich die eingehende Richtlinie ändert, kündigt Junos OS alle vom Peer angekündigten Routen erneut an.
Wenn Sie keep all oder konfigurieren und keep none die Peers die Routenaktualisierung unterstützen, sendet der lokale Sprecher eine Aktualisierungsnachricht und führt eine Importauswertung durch. Bei diesen Peers werden die Sitzungen nicht neu gestartet. Um festzustellen, ob ein Peer die Aktualisierung unterstützt, überprüfen Sie in der Ausgabe des show bgp neighbor Befehls nach Peer supports Refresh capability.
Wenn Sie oder keep none konfigurieren keep allund der Peer den Neustart der Sitzung nicht unterstützt, werden die zugehörigen BGP-Sitzungen neu gestartet (Flapped).
Topologie
Konfiguration
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für Ihre Netzwerkkonfiguration erforderlich sind, und kopieren Sie dann die Befehle und fügen Sie sie in die CLI auf Hierarchieebene [edit] ein.
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 65200 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 65300
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 65300 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 65100 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 172.16.0.0/16 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 65200
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 65200 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 172.16.11.1/32 exact 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 65100
Konfigurieren der bedingten Installation von Präfixen
Schritt-für-Schritt-Anleitung
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Weitere Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI-Benutzerhandbuch.
So konfigurieren Sie die bedingte Installation von Präfixen:
Konfigurieren Sie die Router-Schnittstellen, 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-Internet, um aus dem Internet gelernte BGP-Routen zu emulieren, die in die Routing-Tabelle von Router Süd importiert werden sollen, und konfigurieren Sie eine zusätzliche 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 außerdem die Loopback-Schnittstellenadressen auf den Routern Nord und Süd.
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 Nord, die für Router Süd angekündigt werden soll.
[edit routing-options] user@North# set static route 0/0 reject
Definieren Sie die Bedingung für das Exportieren von Präfixen aus der Routing-Tabelle auf Router Nord.
[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-bgpundconditional-export-bgp) auf den Routern Internet bzw. North, um Routen zu BGP anzukündigen.HINWEIS:Stellen Sie sicher,
prefix_11dass Sie in der Exportrichtlinie auf die Bedingung verweisen (die in Schritt 4konfiguriert wurde).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 172,16.0.0/16 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 (
import-selected-routes) auf Router Süd, um einige der von Router Nord angekündigten Routen in die Routing-Tabelle 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 172.16.11.1/32 exact 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 Sie BGP auf allen drei Routern, um den Fluss von Präfixen zwischen den autonomen Systemen zu ermöglichen.
HINWEIS:Stellen Sie sicher, dass Sie die definierten Import- und Exportrichtlinien auf die jeweiligen BGP-Gruppen anwenden, damit die Präfixankündigung erfolgen kann.
Router Internet [edit protocols bgp group toNorth] user@Internet# set local-address 10.0.89.14 user@Internet# set peer-as 65200 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 65300 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 65100 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 65200 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.
HINWEIS:In diesem Beispiel wird die Router-ID basierend auf der IP-Adresse konfiguriert, die auf der lo0.0-Schnittstelle des Routers konfiguriert ist.
Router Internet [edit routing options] user@Internet# set router-id 192.168.9.1 user@Internet# set autonomous-system 65300
Router North [edit routing options] user@North# set router-id 192.168.8.1 user@North# set autonomous-system 65200
Router South [edit routing options] user@South# set router-id 192.168.7.1 user@South# set autonomous-system 65100
Ergebnisse
Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie die show interfacesBefehle , show protocols bgp, show policy-optionsund show routing-options eingeben. Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
Gerät Internet
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 65200;
neighbor 10.0.89.13;
}
user@Internet# show policy-options
policy-statement into-bgp {
term 1 {
from interface lo0.0;
then accept;
}
}
user@Internet# show routing-options router-id 192.168.9.1; autonomous-system 65300;
Gerät Nord
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 65300;
neighbor 10.0.89.14;
}
group toSouth {
local-address 10.0.78.14;
export conditional-export-bgp;
peer-as 65100;
neighbor 10.0.78.13;
}
user@North# show policy-options
policy-statement conditional-export-bgp {
term prefix_11 {
from {
protocol bgp;
route-filter 172.16.0.0/16 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 65200;
Gerät Süd
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 65200;
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 172.16.11.1 exact;
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 65100;
Wenn Sie mit der Konfiguration der Router fertig sind, rufen Sie den Konfigurationsmodus auf commit .
Verifizierung
Vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.
- BGP verifizieren
- Überprüfen der Präfixankündigung vom Router-Internet zum Router Nord
- Überprüfen der Präfixankündigung von Router Nord zu Router Süd
- Überprüfen der BGP-Importrichtlinie für die Installation von Präfixen
- Überprüfen des bedingten Exports von Router Nord zu Router Süd
- Überprüfen des Vorhandenseins von Routen, die durch Richtlinien ausgeblendet sind (optional)
BGP verifizieren
Zweck
Stellen Sie sicher, dass BGP-Sitzungen zwischen den drei Routern eingerichtet wurden.
Action!
Führen Sie den show bgp neighbor neighbor-address Befehl im Betriebsmodus aus.
Überprüfen Sie die BGP-Sitzung im Router Internet, um sicherzustellen, dass Router Nord ein Nachbar ist.
user@Internet> show bgp neighbor 10.0.89.13 Peer: 10.0.89.13+179 AS 65200 Local: 10.0.89.14+56187 AS 65300 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 65200) 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 Nord, um sicherzustellen, dass Router Internet ein Nachbar ist.
user@North> show bgp neighbor 10.0.89.14 Peer: 10.0.89.14+56187 AS 65300 Local: 10.0.89.13+179 AS 65200 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 65300) 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 sicherzustellen, dass BGP-Sitzungen eingerichtet wurden:
Peer– Überprüfen Sie, ob die AS-Nummer des Peers aufgeführt ist.
Local– Überprüfen Sie, ob die lokale AS-Nummer aufgeführt ist.
State—Stellen Sie sicher, dass der Wert .
EstablishedWenn nicht, überprüfen Sie die Konfiguration erneut und suchen Sieshow bgp neighbornach weiteren Details zu den Ausgabefeldern.
Stellen Sie außerdem sicher, dass Router Nord und Süd Peer-Beziehungen zueinander aufbauen.
Bedeutung
Zwischen den drei Routern werden BGP-Sitzungen eingerichtet.
Überprüfen der Präfixankündigung vom Router-Internet zum Router Nord
Zweck
Stellen Sie sicher, dass die vom Router Internet gesendeten Routen von Router Nord empfangen werden.
Action!
Führen Sie den
show route advertising-protocol bgp neighbor-addressBefehl im Betriebsmodus des Routers Internet 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 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) an Router Nord ankündigt.
Führen Sie den
show route receive-protocol bgp neighbor-addressBefehl im Betriebsmodus auf Router Nord 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 65300 I * 172.16.12.1/32 10.0.89.14 65300 I * 172.16.13.1/32 10.0.89.14 65300 I * 172.16.14.1/32 10.0.89.14 65300 I * 172.16.15.1/32 10.0.89.14 65300 I * 192.168.9.1/32 10.0.89.14 65300 I
Die Ausgabe überprüft, ob Router Nord alle vom Router Internet angekündigten Routen empfangen hat.
Bedeutung
Die vom Router Internet gesendeten Präfixe wurden erfolgreich in der Routing-Tabelle auf Router Nord installiert.
Überprüfen der Präfixankündigung von Router Nord zu Router Süd
Zweck
Stellen Sie sicher, dass die vom Router Internet empfangenen Routen und die statische Standardroute von Router Nord bis Router Süd angekündigt werden.
Action!
Führen Sie den
show route 0/0 exactBefehl im Betriebsmodus auf Router Nord 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 RejectDie Ausgabe überprüft das Vorhandensein der statischen Standardroute (0.0.0.0/0) in der Routing-Tabelle auf Router Nord.
Führen Sie den
show route advertising-protocol bgp neighbor-addressBefehl im Betriebsmodus auf Router Nord 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 65300 I * 172.16.12.1/32 Self 65300 I * 172.16.13.1/32 Self 65300 I * 172.16.14.1/32 Self 65300 I * 172.16.15.1/32 Self 65300 I
In der Ausgabe wird überprüft, ob Router Nord die statische Route und die vom Router Internet empfangene Route 172.16.11.1/32 sowie viele andere Routen für Router Süd ankündigt.
Überprüfen der BGP-Importrichtlinie für die Installation von Präfixen
Zweck
Stellen Sie sicher, dass die BGP-Importrichtlinie die erforderlichen Präfixe erfolgreich installiert.
Action!
Überprüfen Sie, ob die Importrichtlinie auf Router Süd funktionsfähig ist, indem Sie überprüfen, ob nur die statische Standardroute von Router Nord und die Route 172.16.11.1/32 von Router Süd in der Routing-Tabelle installiert sind.
Führen Sie den show route receive-protocol bgp neighbor-address Befehl im Betriebsmodus 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 65200 I * 172.16.11.1/32 10.0.78.14 65200 65300 I
Die Ausgabe überprüft, ob die BGP-Importrichtlinie auf Router Süd funktionsfähig ist und nur die statische Standardroute 0.0.0.0/0 von Router Nord und die Route 172.16.11.1/32 vom Router Internet in die Routing-Tabelle auf Router Süd durchgesickert sind.
Bedeutung
Die Installation von Präfixen ist aufgrund der konfigurierten BGP-Importrichtlinie erfolgreich.
Überprüfen des bedingten Exports von Router Nord zu Router Süd
Zweck
Stellen Sie sicher, dass, wenn Device Internet die Route 172.16.11.1/32 nicht mehr sendet, Gerät Nord die Standardroute 0/0 nicht mehr sendet.
Action!
Veranlassen Sie, dass Device Internet das Senden der Route 172.16.11.1/32 stoppt, indem Sie die Adresse 172.16.11.1/32 auf der Loopback-Schnittstelle deaktivieren.
[edit interfaces lo0 unit 0 family inet] user@Internet# deactivate address 172.16.11.1/32 user@Internet# commit
Führen Sie den
show route advertising-protocol bgp neighbor-addressBefehl im Betriebsmodus auf Router Nord 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 65300 I * 172.16.13.1/32 Self 65300 I * 172.16.14.1/32 Self 65300 I * 172.16.15.1/32 Self 65300 I
Die Ausgabe überprüft, ob Router Nord nicht die Standardroute für Router Süd ankündigt. Dies ist das erwartete Verhalten, wenn die Route 172.16.11.1/32 nicht vorhanden ist.
Reaktivieren Sie die Adresse 172.16.11.1/32 in der Loopback-Schnittstelle des Geräteinternets.
[edit interfaces lo0 unit 0 family inet] user@Internet# activate address 172.16.11.1/32 user@Internet# commit
Überprüfen des Vorhandenseins von Routen, die durch Richtlinien ausgeblendet sind (optional)
Zweck
Überprüfen Sie, ob Routen vorhanden sind, die von der auf Router Süd konfigurierten Importrichtlinie ausgeblendet werden.
In diesem Abschnitt werden die Auswirkungen verschiedener Änderungen veranschaulicht, die Sie je nach Bedarf an der Konfiguration vornehmen können.
Action!
Zeigen Sie Routen an, die in der Routing-Tabelle des Routers Süd ausgeblendet sind, nach:
Verwenden der
hiddenOption für denshow route receive-protocol bgp neighbor-addressBefehl.Deaktivieren der Importrichtlinie.
Führen Sie den
show route receive-protocol bgp neighbor-address hiddenBefehl im Betriebsmodus aus, um ausgeblendete Routen anzuzeigen.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 65200 65300 I 172.16.13.1/32 10.0.78.14 65200 65300 I 172.16.14.1/32 10.0.78.14 65200 65300 I 172.16.15.1/32 10.0.78.14 65200 65300 I
Die Ausgabe überprüft das Vorhandensein von Routen, die durch die Importrichtlinie (172.16.12.1/32, 172.16.13.1/32, 172.16.14.1/32 und 172.16.15.1/32) auf Router Süd ausgeblendet sind.
Deaktivieren Sie die BGP-Importrichtlinie, indem Sie die
deactivate importAnweisung auf Hierarchieebene[edit protocols bgp group group-name]konfigurieren.[edit protocols bgp group toNorth] user@South# deactivate import user@South# commit
Führen Sie den
show route receive-protocol bgp neighbor-addressBefehl operational mode aus, um die Routen nach dem Deaktivieren der Importrichtlinie zu überprü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 65200 I * 172.16.11.1/32 10.0.78.14 65200 65300 I * 172.16.12.1/32 10.0.78.14 65200 65300 I * 172.16.13.1/32 10.0.78.14 65200 65300 I * 172.16.14.1/32 10.0.78.14 65200 65300 I * 172.16.15.1/32 10.0.78.14 65200 65300 I
Die Ausgabe überprüft das Vorhandensein zuvor ausgeblendeter Routen (172.16.12.1/32, 172.16.13.1/32, 172.16.14.1/32 und 172.16.15.1/32).
Aktivieren Sie die BGP-Importrichtlinie und entfernen Sie die ausgeblendeten Routen aus der Routing-Tabelle, indem Sie die
activate importund-Anweisungenkeep nonejeweils auf Hierarchieebene[edit protocols bgp group group-name]konfigurieren.[edit protocols bgp group toNorth] user@South# activate import user@South# set keep none user@South# commit
Führen Sie im Betriebsmodus den
show route receive-protocol bgp neighbor-address hiddenBefehl aus, um die Routen zu überprüfen, nachdem Sie die Importrichtlinie aktiviert und diekeep noneAnweisung 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 ausgeblendeten Routen aufgrund der konfigurierten
keep noneAnweisung nicht in der Routingtabelle verwaltet werden.
Impliziter Filter für das standardmäßige EBGP-Routenweitergabeverhalten ohne Richtlinien
In diesem Abschnitt wird die Verwendung eines impliziten Filters zur Regulierung des EBGP-Routenweitergabeverhaltens beschrieben, wenn keine explizite Richtlinie konfiguriert ist.
Vorteile
Diese Funktion bietet die folgenden Vorteile:
Regulates BGP implementation—Verhindert, dass EBGP-Sprecher zu einem stillen Passthrough werden, bei dem standardmäßig alle Routen akzeptiert und angekündigt werden. Diese Funktion verringert effektiv den Anstieg des Transitverkehrs auf blattautonomen Systemen, insbesondere wenn sie mit vorgeschalteten Internetdienstanbietern multivernetzt sind. So verhindert es auch das stille Verwerfen des Datenverkehrs, Denial-of-Service und globale Internetausfälle.
Implicit filter—Die Konfiguration erleichtert die Verwendung eines impliziten Filters, bei dem das Standardverhalten weiterhin so eingestellt ist, dass standardmäßig alle Routen empfangen und angekündigt werden. Die Konfigurationsanweisung fügt nur bei Bedarf eine Option zum Angeben von enable oder disable für accept-, reject- und reject-always-Klauseln hinzu. Der implizite Filter stellt sicher, dass bei Benutzern mit vorhandenen Bereitstellungen, die auf die standardmäßige BGP-Richtlinie angewiesen sind, keine Betriebsunterbrechungen auftreten.
Überblick
BGP ist das aktuelle autonome Inter-Domain-Protokoll, das für das globale Internet-Routing verwendet wird. Es unterstützt auch verschiedene Dienste wie VPNs und Link State, die nicht für die globale Nutzung vorgesehen sind.
Die BGP-Implementierung, einschließlich des EBGP-Standardverhaltens, orientiert sich an RFC4271, A Border Gateway Protocol 4 (BGP-4). Es enthält jedoch keine expliziten Anleitungen zur Angabe, welche Routen verteilt werden sollen. Dies führt dazu, dass die ursprüngliche BGP-Implementierung ein stilles Pass-Through für Routen ohne jegliche Filterung ist und daher einen Anstieg des Datenverkehrs verursacht, was zu globalen Internetausfällen führt.
Ab Junos OS Version 20.3R1 haben wir einen impliziten Filter defaults ebgp no-policy auf der vorhandenen [edit protocols bgp] Hierarchieebene eingeführt. Die Konfiguration unterteilt die Standardrichtlinie für "Empfangen" und "Ankündigung" in separate Klauseln (accept, reject oder reject-always), damit das Verhalten unabhängig variieren kann.
Wenn keine explizite Richtlinie konfiguriert ist, können Sie mit dem impliziten Filter das standardmäßige eBGP-Empfangs- und -Ankündigungsverhalten in einem von drei Zuständen wie folgt aktivieren:
Werte |
Standardrichtlinie |
Funktionsweise |
|---|---|---|
annehmen |
empfangen |
Akzeptiert, um alle Routen zu empfangen (auch das Standardverhalten). |
inserieren |
Akzeptiert, dass alle Routen angekündigt werden (auch das Standardverhalten). |
|
ablehnen |
empfangen |
Lehnt den Empfang von Routen vom Typ inet unicast und inet6 unicast in den Instance-Typen primary, vrf, virtual-router und non-forwarding ab. |
inserieren |
Lehnt die Ankündigung von Routen vom Typ inet unicast und inet6 unicast in den Instance-Typen primary, vrf, virtual-router und non-forwarding ab. |
|
immer ablehnen |
empfangen |
Lehnt ab, um alle Routen zu empfangen. |
inserieren |
Lehnt es ab, alle Routen zu bewerben. |