Auf dieser Seite
Beispiel: Anwendung von Routing-Richtlinien auf verschiedenen Ebenen der BGP-Hierarchie
Beispiel: Injizieren von OSPF-Routen in die BGP-Routing-Tabelle
Konfigurieren von Routing-Richtlinien zur Steuerung von BGP-Routenanzeigen
Beispiel: Konfiguration der präfixbasierten Filterung ausgehender Routen mit BGP
Grundlegendes zur Standard-BGP-Routing-Richtlinie auf Paketübertragungs-Routern (PTX-Serie)
Bedingte Werbung Für die bedingte Installation von Präfixen – Anwendungsfälle
Impliziter Filter für Standard-EBGP-Routenausbreitungsverhalten ohne Richtlinien
Grundlegende BGP-Routing-Richtlinien
Grundlegendes zu Routing-Richtlinien
Jede Routing-Richtlinie wird durch einen Richtliniennamen identifiziert. Der Name kann Buchstaben, Zahlen und Bindestriche (-) enthalten und kann bis zu 255 Zeichen lang sein. Um Leerzeichen in den Namen einzufügen, schließen Sie den gesamten Namen in doppelte Anführungszeichen ein. Jeder Routing-Richtlinienname muss innerhalb einer Konfiguration eindeutig sein.
Sobald eine Richtlinie erstellt und benannt wurde, muss sie angewendet werden, bevor sie aktiv wird. Sie wenden Routing-Richtlinien mit den import Anweisungen export auf der protocols protocol-name Ebene der Konfigurationshierarchie an.
In der import Anweisung listen Sie den Namen der Routing-Richtlinie auf, die bewertet werden soll, wenn Routen aus dem Routingprotokoll in die Routingtabelle importiert werden.
In der export Anweisung listen Sie den Namen der Routing-Richtlinie auf, die bewertet werden soll, wenn Routen aus der Routingtabelle in ein dynamisches Routingprotokoll exportiert werden. Aus der Routing-Tabelle werden nur aktive Routen exportiert.
Um mehr als eine Richtlinie anzugeben und eine Richtlinienkette zu erstellen, listen Sie die Richtlinien auf, die ein Leerzeichen als Trennzeichen verwenden. Wenn mehrere Richtlinien angegeben werden, werden die Richtlinien in der Reihenfolge ausgewertet, in der sie angegeben werden. Sobald eine Annahme- oder Ablehnungsaktion ausgeführt wird, endet die Bewertung der Richtlinienkette.
Siehe auch
Beispiel: Anwendung von Routing-Richtlinien auf verschiedenen Ebenen der BGP-Hierarchie
Dieses Beispiel zeigt, wie BGP in einer einfachen Netzwerktopologie konfiguriert ist, und erklärt, wie Routing-Policen 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
importundexportAnweisungen: Fügen Sie diese Anweisungen auf Hierarchieebene[edit protocols bgp]ein (für Routing-Instanzen diese Anweisungen auf Hierarchieebene[edit routing-instances routing-instance-name protocols bgp]einschließen).Gruppieren
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[edit routing-instances routing-instance-name protocols bgp group group-name]Hierarchieebene ein).Peer
importundexportAnweisungen: Fügen Sie diese Anweisungen auf Hierarchieebene[edit protocols bgp group group-name neighbor address]ein (für Routing-Instanzen diese Anweisungen auf Hierarchieebene[edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]einschließen).
Eine Peer-Ebene import oder export Anweisung überschreibt eine Gruppe import oder export Anweisung. Eine Gruppe oder importexport Anweisung überschreibt einen globalen BGP import oder export eine Anweisung.
In diesem Beispiel wird eine Richtlinie mit dem Namen auf send-direct globaler Ebene angewendet, eine weitere Richtlinie, die auf Gruppenebene benannt send-192.168.0.1 ist, und eine dritte Richtlinie, die auf Nachbarnebene benannt send-192.168.20.1 ist, 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 explizitste Richtlinie angewendet wird. Eine Richtlinie auf Nachbarschaftsebene ist expliziter als eine Richtlinie auf Gruppenebene, was wiederum expliziter ist als eine globale Richtlinie.
Für den Nachbarn 172.16.2.2 gilt nur die Richtlinie send-192.168.20.1. Der Nachbar 172.16.3.3, ohne etwas spezifischer, wird nur der Richtlinie send-192.168.0.1 unterworfen. In der Zwischenzeit hat Neighbor 172.16.4.4 in Group Other-Group keine Richtlinie auf Gruppen- oder Nachbarschaftsebene, sodass er die Send-Direct-Richtlinie verwendet.
Wenn Der Neighbor 172.16.2 die Funktion aller drei Richtlinien ausführt, können Sie eine neue Richtlinie auf Nachbarschaftsebene schreiben und anwenden, die die Funktionen der anderen drei umfasst, oder Sie können alle drei vorhandenen Richtlinien als Kette auf Neighbor 172.16.2.2 anwenden.
Topologie
Abbildung 1 zeigt das Beispielnetzwerk.
CLI-Schnellkonfiguration zeigt die Konfiguration für alle Geräte in Abbildung 1.
In diesem Abschnitt #d186e202__d186e456 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 in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, und kopieren Sie dann die Befehle und fügen sie auf Hierarchieebene in die [edit] CLI ein.
Gerät R1
set interfaces fe-1/2/0 unit 0 description to-R2 set interfaces fe-1/2/0 unit 0 family inet address 10.10.10.1/30 set interfaces lo0 unit 0 family inet address 172.16.1.1/32 set protocols bgp local-address 172.16.1.1 set protocols bgp export send-direct set protocols bgp group internal-peers type internal set protocols bgp group internal-peers export send-static-192.168.0 set protocols bgp group internal-peers neighbor 172.16.2.2 export send-static-192.168.20 set protocols bgp group internal-peers neighbor 172.16.3.3 set protocols bgp group other-group type internal set protocols bgp group other-group neighbor 172.16.4.4 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface fe-1/2/0.0 set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set policy-options policy-statement send-static-192.168.0 term 1 from protocol static set policy-options policy-statement send-static-192.168.0 term 1 from route-filter 192.168.0.0/24 orlonger set policy-options policy-statement send-static-192.168.0 term 1 then accept set policy-options policy-statement send-static-192.168.20 term 1 from protocol static set policy-options policy-statement send-static-192.168.20 term 1 from route-filter 192.168.20.0/24 orlonger set policy-options policy-statement send-static-192.168.20 term 1 then accept set routing-options static route 192.168.0.1/32 discard set routing-options static route 192.168.20.1/32 discard set routing-options router-id 172.16.1.1 set routing-options autonomous-system 17
Gerät R2
set interfaces fe-1/2/0 unit 0 description to-R1 set interfaces fe-1/2/0 unit 0 family inet address 10.10.10.2/30 set interfaces fe-1/2/1 unit 0 description to-R3 set interfaces fe-1/2/1 unit 0 family inet address 10.10.10.5/30 set interfaces lo0 unit 0 family inet address 172.16.2.2/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 172.16.2.2 set protocols bgp group internal-peers neighbor 172.16.3.3 set protocols bgp group internal-peers neighbor 172.16.1.1 set protocols bgp group internal-peers neighbor 172.16.4.4 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface fe-1/2/0.0 set protocols ospf area 0.0.0.0 interface fe-1/2/1.0 set routing-options router-id 172.16.2.2 set routing-options autonomous-system 17
Gerät R3
set interfaces fe-1/2/1 unit 0 description to-R2 set interfaces fe-1/2/1 unit 0 family inet address 10.10.10.6/30 set interfaces fe-1/2/2 unit 0 description to-R4 set interfaces fe-1/2/2 unit 0 family inet address 10.10.10.9/30 set interfaces lo0 unit 0 family inet address 172.16.3.3/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 172.16.3.3 set protocols bgp group internal-peers neighbor 172.16.2.2 set protocols bgp group internal-peers neighbor 172.16.1.1 set protocols bgp group internal-peers neighbor 172.16.4.4 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface fe-1/2/1.0 set protocols ospf area 0.0.0.0 interface fe-1/2/2.0 set routing-options router-id 172.16.3.3 set routing-options autonomous-system 17
Gerät R4
set interfaces fe-1/2/2 unit 0 description to-R3 set interfaces fe-1/2/2 unit 0 family inet address 10.10.10.10/30 set interfaces lo0 unit 0 family inet address 172.16.4.4/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 172.16.4.4 set protocols bgp group internal-peers neighbor 172.16.2.2 set protocols bgp group internal-peers neighbor 172.16.1.1 set protocols bgp group internal-peers neighbor 172.16.3.3 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface fe-1/2/2.0 set routing-options router-id 172.16.4.4 set routing-options autonomous-system 17
Verfahren
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie auf verschiedenen Ebenen in der Konfigurationshierarchie navigieren. 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 Protocol (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 Nummer des autonomen Systems (AS).
[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 Ihre Konfiguration im Konfigurationsmodus, indem Sie die show interfacesBefehle , show protocols, show policy-optionsund show routing-options . Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@R1# show interfaces
fe-1/2/0 {
unit 0 {
description to-R2;
family inet {
address 10.10.10.1/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 172.16.1.1/32;
}
}
}
user@R1# show protocols
bgp {
local-address 172.16.1.1;
export send-direct;
group internal-peers {
type internal;
export send-static-192.168.0;
neighbor 172.16.2.2 {
export send-static-192.168.20;
}
neighbor 172.16.3.3;
}
group other-group {
type internal;
neighbor 172.16.4.4;
}
}
ospf {
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface fe-1/2/0.0;
}
}
user@R1# show policy-options
policy-statement send-direct {
term 1 {
from protocol direct;
then accept;
}
}
policy-statement send-static-192.168.0 {
term 1 {
from {
protocol static;
route-filter 192.168.0.0/24 orlonger;
}
then accept;
}
}
policy-statement send-static-192.168.20 {
term 1 {
from {
protocol static;
route-filter 192.168.20.0/24 orlonger;
}
then accept;
}
}
user@R1# show routing-options
static {
route 192.168.0.1/32 discard;
route 192.168.20.1/32 discard;
}
router-id 172.16.1.1;
autonomous-system 17;
Überprüfung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
Überprüfung von BGP-Routenlernen
Zweck
Stellen Sie sicher, dass die BGP-Exportrichtlinien wie erwartet funktionieren, indem Sie die Routing-Tabellen überprüfen.
Aktion
user@R1> show route protocol direct
inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.1.1/32 *[Direct/0] 1d 22:19:47
> via lo0.0
10.10.10.0/30 *[Direct/0] 1d 22:19:47
> via fe-1/2/0.0
user@R1> show route protocol static
inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.1/32 *[Static/5] 02:20:03
Discard
192.168.20.1/32 *[Static/5] 02:20:03
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üfung 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.
Aktion
user@R2> show route receive-protocol bgp 172.16.1.1 inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 192.168.20.1/32 172.16.1.1 100 I
user@R3> show route receive-protocol bgp 172.16.1.1 inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 192.168.0.1/32 172.16.1.1 100 I
user@R4> show route receive-protocol bgp 172.16.1.1 inet.0: 9 destinations, 11 routes (9 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 172.16.1.1/32 172.16.1.1 100 I 10.10.10.0/30 172.16.1.1 100 I
Bedeutung
Auf Gerät R2 zeigt der 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.
Wenn in BGP mehrere Richtlinien an verschiedenen CLI-Hierarchien angewendet werden, wird nur die spezifischste Anwendung bewertet, ausgenommen andere, weniger spezifische Richtlinienanwendungen. Obwohl dieser Punkt sinnvoll erscheinen mag, wird er während der Routerkonfiguration leicht vergessen, wenn Sie fälscht glauben, dass eine Richtlinie auf Nachbarschaftsebene mit einer Richtlinie auf globaler oder Gruppenebene kombiniert wird, nur um festzustellen, dass Ihr Richtlinienverhalten nicht wie erwartet entspricht.
Beispiel: Injizieren von OSPF-Routen in die BGP-Routing-Tabelle
Dieses Beispiel zeigt, wie Sie eine Richtlinie erstellen, die OSPF-Routen in die BGP-Routingtabelle einspeist.
Anforderungen
Bevor Sie beginnen:
Konfigurieren Sie Netzwerkschnittstellen.
Konfigurieren Sie externe Peer-Sitzungen. Siehe Beispiel: Konfigurieren externer BGP Point-to-Point-Peer-Sitzungen.
Konfigurieren Sie Interior Gateway Protocol (IGP)-Sitzungen zwischen Peers.
Überblick
In diesem Beispiel erstellen Sie eine Routing-Richtlinie mit dem injectterm1Namen injectpolicy1 . Die Richtlinie injiziert OSPF-Routen in die BGP-Routingtabelle.
Topologie
Konfiguration
Konfigurieren der Routing-Richtlinie
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen sie in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, kopieren Sie die Befehle, fügen Sie sie auf Hierarchieebene [bearbeiten] in die CLI ein, und geben Sie commit dann im Konfigurationsmodus ein.
set policy-options policy-statement injectpolicy1 term injectterm1 from protocol ospf set policy-options policy-statement injectpolicy1 term injectterm1 from area 0.0.0.1 set policy-options policy-statement injectpolicy1 term injectterm1 then accept set protocols bgp export injectpolicy1
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie auf verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI-Benutzerhandbuch.
So injizieren Sie OSPF-Routen in eine BGP-Routing-Tabelle:
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 die show policy-options Befehle aus dem Konfigurationsmodus eingeben. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@host# show policy-options
policy-statement injectpolicy1 {
term injectterm1 {
from {
protocol ospf;
area 0.0.0.1;
}
then accept;
}
}
user@host# show protocols bgp export injectpolicy1;
Wenn Sie mit der Konfiguration des Geräts fertig sind, geben Sie im Konfigurationsmodus ein commit .
Konfigurieren der Ablaufverfolgung für die Routing-Richtlinie
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen sie in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, kopieren Sie die Befehle, fügen Sie sie auf Hierarchieebene [bearbeiten] in die CLI ein, und geben Sie commit dann im Konfigurationsmodus ein.
set policy-options policy-statement injectpolicy1 term injectterm1 then trace set routing-options traceoptions file ospf-bgp-policy-log set routing-options traceoptions file size 5m set routing-options traceoptions file files 5 set routing-options traceoptions flag policy
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie auf verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI-Benutzerhandbuch.
Fügen Sie eine Trace-Aktion in die Richtlinie ein.
[edit policy-options policy-statement injectpolicy1 term injectterm1] user@host# then trace
Konfigurieren Sie die Ablaufverfolgungsdatei für die Ausgabe.
[edit routing-options traceoptions] user@host# set file ospf-bgp-policy-log user@host# set file size 5m user@host# set file files 5 user@host# set flag policy
Ergebnisse
Bestätigen Sie Ihre Konfiguration, indem Sie die Befehle und show routing-options die show policy-options Befehle aus dem Konfigurationsmodus eingeben. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@host# show policy-options
policy-statement injectpolicy1 {
term injectterm1 {
then {
trace;
}
}
}
user@host# show routing-options
traceoptions {
file ospf-bgp-policy-log size 5m files 5;
flag policy;
}
Wenn Sie mit der Konfiguration des Geräts fertig sind, geben Sie im Konfigurationsmodus ein commit .
Überprüfung
Fehlerbehebung
Verwenden des Befehls "Protokoll anzeigen", um die Aktionen der Routing-Richtlinie zu überprüfen
Problem
Die Routingtabelle enthält unerwartete Routen, oder routen fehlen in der Routingtabelle.
Lösung
Wenn Sie die Richtlinienverfolgung konfigurieren, wie in diesem Beispiel dargestellt, 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 sie einwirkt.
Konfigurieren von Routing-Richtlinien zur Steuerung von BGP-Routenanzeigen
Alle Routing-Protokolle verwenden die Routingtabelle Junos OS, um die gelernten Routen zu speichern und zu bestimmen, welche Routen sie in ihren Protokollpaketen ankündigen sollen. Mit der Routingrichtlinie können Sie steuern, welche Routen die Routingprotokolle in der Routingtabelle speichern und aus ihnen abrufen. Informationen zur Routing-Richtlinie finden Sie im Benutzerhandbuch für Routing-Richtlinien, Firewall-Filter und Traffic Policer.
Beim Konfigurieren einer BGP-Routing-Richtlinie können Sie die folgenden Aufgaben ausführen:
- Anwendung von Routing-Richtlinien
- Festlegen von BGP zum Ankündigen inaktiver Routen
- Konfigurieren von BGP zur Ankündigung der besten externen Route für interne Peers
- Konfigurieren der Anzahl von BGP-Austauschrouten mit der Routing-Tabelle
- Deaktivieren der Unterdrückung von Routenanzeigen
Anwendung von Routing-Richtlinien
Sie definieren Eine Routing-Richtlinie auf [edit policy-options] Hierarchieebene. Um richtlinien anzuwenden, die Sie für BGP definiert haben, fügen Sie die import und export Anweisungen in die BGP-Konfiguration ein.
Sie können Richtlinien wie folgt anwenden:
BGP global
importundexportAnweisungen: Fügen Sie diese Anweisungen auf Hierarchieebene[edit protocols bgp]ein (für Routing-Instanzen diese Anweisungen auf Hierarchieebene[edit routing-instances routing-instance-name protocols bgp]einschließen).Gruppieren
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[edit routing-instances routing-instance-name protocols bgp group group-name]Hierarchieebene ein).Peer
importundexportAnweisungen: Fügen Sie diese Anweisungen auf Hierarchieebene[edit protocols bgp group group-name neighbor address]ein (für Routing-Instanzen diese Anweisungen auf Hierarchieebene[edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]einschließen).
Eine Peer-Ebene import oder export Anweisung überschreibt eine Gruppe import oder export Anweisung. Eine Gruppe oder importexport Anweisung überschreibt einen globalen BGP import oder export eine Anweisung.
Informationen zur Anwendung von Richtlinien finden Sie in den folgenden Abschnitten:
- Anwenden von Richtlinien auf Routen, die aus 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 aus BGP in die Routing-Tabelle importiert werden
Wenn Sie eine Richtlinie auf Routen anwenden möchten, die aus BGP in die Routing-Tabelle importiert werden, fügen Sie die import Anweisung ein und führen die Namen einer oder mehrerer zu bewertenden Richtlinien auf:
import [ policy-names ];
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.
Wenn Sie mehr als eine Richtlinie angeben, werden diese in der angegebenen Reihenfolge ausgewertet, von der ersten bis zur letzten, und der erste übereinstimmende Filter wird auf die Route angewendet. Wenn keine Übereinstimmung gefunden wird, platziert BGP in die Routing-Tabelle nur die Routen, die von BGP-Routing-Geräten gelernt wurden.
Anwenden von Richtlinien auf Routen, die aus der Routing-Tabelle in BGP exportiert werden
Wenn Sie eine Richtlinie auf Routen anwenden möchten, die aus der Routing-Tabelle in BGP exportiert werden, fügen Sie die export Anweisung ein und listet die Namen einer oder mehrerer zu bewertenden Richtlinien auf:
export [ policy-names ];
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.
Wenn Sie mehr als eine Richtlinie angeben, werden diese in der angegebenen Reihenfolge ausgewertet, von der ersten bis zur letzten, und der erste übereinstimmende Filter wird auf die Route angewendet. Wenn keine Routen mit den Filtern übereinstimmen, exportiert die Routing-Tabelle in BGP nur die Routen, die sie von BGP gelernt hat.
Festlegen von BGP zum Ankündigen inaktiver Routen
Standardmäßig speichert BGP die Routeninformationen, die es von Updatemeldungen erhält, in der Junos OS-Routingtabelle, und die Routingtabelle exportiert nur aktive Routen in BGP, die BGP dann seinen Peers ankündigen. Fügen Sie die Anweisung ein, um die Routing-Tabelle in BGP die beste von BGP gelernte Route zu exportieren, advertise-inactive auch wenn Junos OS sie nicht als aktive Route ausgewählt hat:
advertise-inactive;
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.
Konfigurieren von BGP zur Ankündigung der besten externen Route für interne Peers
Im Allgemeinen geben bereitgestellte BGP-Implementierungen die externe Route mit dem höchsten lokalen Präferenzwert internen Peers nicht an, es sei denn, sie ist die beste Route. Obwohl dieses Verhalten in einer früheren Version der BGP-Version 4-Spezifikation, RFC 1771, erforderlich war, wurde es in der Regel nicht befolgt, um die Menge der angekündigten Informationen zu minimieren und Routing-Schleifen zu verhindern. Es gibt jedoch Szenarien, in denen die Werbung für die beste externe Route von Vorteil ist, insbesondere Situationen, die zu IBGP-Routenoszillation 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 einer internen BGP (IBGP)-Mesh-Gruppe, einem Routenreflektor-Cluster oder einer Konföderation für autonome Systeme (AS) angekündigt wird, selbst wenn die beste Route eine interne Route ist.
Um die advertise-external Anweisung auf einem Route Reflector zu konfigurieren, müssen Sie die Intracluster-Reflexion 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-Kennung empfangen wird oder beide Peers keine Cluster-Kennung konfiguriert haben. Eine Route, die von einem internen Peer empfangen wird, der zu einem anderen Cluster gehört, das heißt mit einem anderen Clusterbezeichner, wird als extern betrachtet.
In einer Konföderation wird jede Route von einer anderen Sub-AS der Konföderation 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. Infolgedessen wird eine externe Route mit einem AS-Pfad schlechter (d. h. länger) als der des aktiven Pfads nicht angekündigt.
Junos OS unterstützt auch die Konfiguration einer BGP-Exportrichtlinie, die mit dem Status einer angekündigten Route übereinstimmt. Sie können auf aktiven oder inaktiven Routen abgleichen. Weitere Informationen finden Sie im Benutzerhandbuch für Routing-Richtlinien, Firewall-Filter und Traffic Policer.
Um BGP zu konfigurieren, um den besten externen Pfad zu internen Peers anzukündigen, fügen Sie die Anweisung ein advertise-external :
advertise-external;
Die advertise-external Anweisung wird sowohl auf Gruppen- als auch auf Nachbarnebene unterstützt. Wenn Sie die Anweisung auf Nachbarnebene 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 zur Anweisungszusammenfassung für diese Anweisung.
Um BGP so zu konfigurieren, dass der beste externe Pfad nur dann angekündigt wird, wenn die Routenauswahl den Punkt erreicht, an dem der MED-Wert ausgewertet wird, fügen Sie die Anweisung ein conditional :
advertise-external {
conditional;
}
Konfigurieren der Anzahl von BGP-Austauschrouten mit der Routing-Tabelle
BGP speichert die Routeninformationen, die es von Update-Nachrichten in der Routing-Tabelle erhält, und die Routingtabelle exportiert aktive Routen aus der Routing-Tabelle in BGP. BGP kündigt dann die exportierten Routen an seine Peers an. Standardmäßig erfolgt der Austausch von Routeninformationen zwischen BGP und der Routingtabelle unmittelbar nach dem Empfang der Routen. Dieser sofortige Austausch von Routeninformationen kann zu Instabilitäten in den Informationen zur Netzwerkverfügbarkeit führen. Um dies zu schützen, können Sie die Zeit zwischen dem Austausch von Routing-Informationen mit BGP und der Routingtabelle hinauszögern.
Um zu konfigurieren, wie oft BGP und die Routingtabelle Routeninformationen austauschen, fügen Sie die Anweisung ein out-delay :
out-delay seconds;
Standardmäßig enthält die Routing-Tabelle einige der aus BGP gelernten Routeninformationen. Um alle oder keine dieser Informationen in der Routingtabelle zu behalten, fügen Sie die Anweisung hinzu keep :
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 Routingtabelle kann die aus BGP gelernten Routeninformationen auf eine der folgenden Arten beibehalten:
Standard (auslassen der
keepAnweisung): Behalten Sie alle Routeninformationen, die von BGP gelernt wurden, mit Ausnahme von Routen, deren AS-Pfad in einer Schleife ausgeführt wird und deren Schleife den lokalen AS enthält.keep all– Behalten Sie alle Routeninformationen, die aus BGP gelernt wurden.keep none– Verwerfen Sie Routen, die von einem Peer empfangen wurden und die durch Importrichtlinien oder andere Überprüfung der Vernunft abgelehnt wurden, z. B. AS-Pfad oder next Hop. Wenn Sie für die BGP-Sitzung konfigurierenkeep noneund änderungen an den eingehenden Richtlinien ändern, erzwist Junos OS die Readvertisement der vollständigen, vom Peer angekündigten Routen.
In einer AS-Pfadheilungssituation könnten Routen mit schleiften Pfaden theoretisch während einer weichen Neukonfiguration nutzbar werden, wenn die Begrenzung der AS-Pfadschleife geändert wird. Es gibt jedoch einen erheblichen Unterschied zur Speichernutzung zwischen dem Standard und keep all.
Betrachten Sie die folgenden Szenarien:
Ein Peer liest Routen zurück zu dem Peer, von dem er gelernt hat.
Dies kann in den folgenden Fällen der Fall sein:
Das Routing-Gerät eines anderen Anbieters kündigt die Routen zurück zum sendenden Peer an.
Das Standardverhalten des Junos OS-Peers, Routen nicht zurück zum sendenden Peer zu lesen, wird durch die Konfiguration
advertise-peer-asüberschrieben.
Ein Provider Edge (PE)-Routinggerät verwirft jede VPN-Route, die keine der erwarteten Routenziele hat.
Bei keep all der Konfiguration wird das Verhalten des Verwerfens von Routen, die in den oben genannten Szenarien empfangen werden, außer Kraft gesetzt.
Deaktivieren der Unterdrückung von Routenanzeigen
Junos OS gibt nicht die Routen an, die von einem EBGP-Peer gelernt wurden, zurück zum gleichen externen BGP (EBGP)-Peer. Darüber hinaus bietet die Software nicht die Routen zurück zu EBGP-Peers, die sich im selben AS wie der Ursprungs-Peer befinden, unabhängig von der Routing-Instanz. Sie können dieses Verhalten ändern, indem Sie die advertise-peer-as Anweisung in die Konfiguration integrieren. Um die Standardunterdrückung der Ankündigung zu deaktivieren, fügen Sie die Anweisung ein advertise-peer-as :
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 einbeziehen, 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 die Und-Anweisungen as-overrideno-advertise-peer-as in die Konfiguration einbeziehen, wird die no-advertise-peer-as Anweisung ignoriert. Sie können diese Anweisungen auf mehreren Hierarchieebenen einschließen.
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisungen einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisungen.
Siehe auch
Beispiel: Konfigurieren einer Routing-Richtlinie zur Ankündigung der besten externen Route für interne Peers
Die BGP-Protokollspezifikation, wie in RFC 1771 definiert, legt fest, dass ein BGP-Peer seinen internen Peers den externen Pfad mit höherer Präferenz anpreist, auch wenn dieser Pfad nicht der insgesamt 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 das Abweichen von der Spezifikation sind wie folgt:
Minimierung der Menge an ausgeschriebenen Informationen. BGP skaliert entsprechend der Anzahl der verfügbaren Pfade.
Vermeidung von Routing- und Weiterleitungsschleifen.
Es gibt jedoch mehrere Szenarien, in denen das in RFC 1771 festgelegte Verhalten der Werbung für die beste externe Route von Vorteil sein könnte. Eine Begrenzung der Pfadinformationen ist nicht immer wünschenswert, da die Pfaddiversität dazu beitragen kann, die Wiederherstellungszeiten zu verkürzen. Die Werbung für den besten externen Pfad kann auch interne BGP (IBGP)-Routenoszillationsprobleme beheben, wie in RFC 3345, Border Gateway Protocol (BGP) Persistent Route Oscillation Condition beschrieben.
Die advertise-external Anweisung ändert das Verhalten eines BGP-Speakers, um den besten externen Pfad für IBGP-Peers anzukündigen, selbst wenn der beste Gesamtpfad ein interner Pfad ist.
Die advertise-external Anweisung wird sowohl auf Gruppen- als auch auf Nachbarnebene unterstützt. Wenn Sie die Anweisung auf Nachbarnebene 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 begrenzt das Verhalten der advertise-external Einstellung, sodass die externe Route nur dann angekündigt wird, wenn die Routenauswahl den Punkt erreicht, an dem die Med-Metrik (Multiple Exit Discriminator) ausgewertet wird. Daher wird eine externe Route nicht angekündigt, wenn sie z. B. einen AS-Pfad hat, der schlechter (länger) ist als der des aktiven Pfads. Die conditional Option beschränkt die Ankündigung externer Pfade darauf, wenn der beste externe und der aktive Pfad bis zum MED-Schritt des Routenauswahlprozesses 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 unterstützt auch die Konfiguration einer BGP-Exportrichtlinie, die dem Status einer angekündigten Route entspricht. Sie können aktive oder inaktive Routen wie folgt abgleichen:
policy-options {
policy-statement name{
from state (active|inactive);
}
}
Diese Qualifikation wird nur dann erfüllt, wenn sie im Kontext einer Exportrichtlinie verwendet wird. Wenn eine Route von einem Protokoll angekündigt wird, das inaktive Routen ankündigt (z. B. BGP), state inactive entspricht Routen, die advertise-inactive aufgrund der Anweisungen angekündigt advertise-external wurden.
Die folgende Konfiguration kann beispielsweise als BGP-Exportrichtlinie für interne Peers verwendet werden, um Routen zu markieren, die aufgrund der advertise-external Einstellung bei einer benutzerdefinierten Community angekündigt wurden. 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 nicht für die Weiterleitung durch den Absender 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 (EBGP)-Verbindung zum Gerät R1. Gerät R2 verfügt über eine IBGP-Verbindung zum Gerät R3.
Gerät R1 kündigt 172.16.6.0/24 an. Gerät R2 setzt nicht die lokale Voreinstellung in einer Importrichtlinie für die Routen von Gerät R1, und daher hat 172.16.6.0/24 die lokale Standardeinstellung von 100.
Gerät R3 wirbt für 172.16.6.0/24 mit einer lokalen Präferenz von 200.
Wenn die advertise-external Anweisung auf Gerät R2 nicht konfiguriert ist, wird 172.16.6.0/24 von Gerät R2 nicht für Gerät R3 angekündigt.
Wenn die advertise-external Anweisung auf Gerät R2 in der Sitzung in Richtung Gerät R3 konfiguriert ist, wird 172.16.6.0/24 von Gerät R2 in Richtung Gerät R3 angekündigt.
Wenn advertise-external conditional auf Gerät R2 in der Sitzung in Richtung Gerät R3 konfiguriert wird, wird 172.16.6.0/24 von Gerät R2 nicht für Gerät R3 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 der Routenauswahl gleich sind), wird 172.16.6.0/24 von Gerät R2 gegenüber Gerät R3 angekündigt.
Um die advertise-external Anweisung auf einem Route Reflector zu konfigurieren, müssen Sie die Intracluster-Reflexion mit der no-client-reflect Anweisung deaktivieren, und der Client-Cluster muss vollständig vermaschten sein, um das Senden redundanter Routenanzeigen 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-Kennung empfangen wird oder beide Peers keine Cluster-Kennung konfiguriert haben. Eine Route, die von einem internen Peer empfangen wird, der zu einem anderen Cluster gehört, das heißt mit einem anderen Clusterbezeichner, wird als extern betrachtet.
Topologie
Abbildung 2 zeigt das Beispielnetzwerk.
CLI-Schnellkonfiguration zeigt die Konfiguration für alle Geräte in Abbildung 2.
In diesem Abschnitt #d189e166__d189e344 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 in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, und kopieren Sie dann die Befehle und fügen sie auf Hierarchieebene in die [edit] CLI ein.
Gerät R1
set interfaces fe-1/2/0 unit 0 description to-R2 set interfaces fe-1/2/0 unit 0 family inet address 10.0.0.1/30 set interfaces lo0 unit 0 family inet address 192.168.0.1/32 set protocols bgp group ext type external set protocols bgp group ext export send-static set protocols bgp group ext peer-as 200 set protocols bgp group ext neighbor 10.0.0.2 set policy-options policy-statement send-static term 1 from protocol static set policy-options policy-statement send-static term 1 from route-filter 172.16.6.0/24 exact set policy-options policy-statement send-static term 1 then accept set policy-options policy-statement send-static term 2 then reject set routing-options static route 172.16.6.0/24 reject set routing-options router-id 192.168.0.1 set routing-options autonomous-system 100
Gerät R2
set interfaces fe-1/2/0 unit 0 description to-R1 set interfaces fe-1/2/0 unit 0 family inet address 10.0.0.2/30 set interfaces fe-1/2/1 unit 0 description to-R3 set interfaces fe-1/2/1 unit 0 family inet address 10.0.0.5/30 set interfaces lo0 unit 0 family inet address 192.168.0.2/32 set protocols bgp group ext type external set protocols bgp group ext peer-as 100 set protocols bgp group ext neighbor 10.0.0.1 set protocols bgp group int type internal set protocols bgp group int local-address 192.168.0.2 set protocols bgp group int advertise-external set protocols bgp group int neighbor 192.168.0.3 set protocols ospf area 0.0.0.0 interface fe-1/2/1.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set routing-options router-id 192.168.0.2 set routing-options autonomous-system 200
Gerät R3
set interfaces fe-1/2/0 unit 6 family inet address 10.0.0.6/30 set interfaces lo0 unit 0 family inet address 192.168.0.3/32 set protocols bgp group int type internal set protocols bgp group int local-address 192.168.0.3 set protocols bgp group int export send-static set protocols bgp group int neighbor 192.168.0.2 set protocols ospf area 0.0.0.0 interface fe-1/2/0.6 set protocols ospf area 0.0.0.0 interface lo0.0 passive set policy-options policy-statement send-static term 1 from protocol static set policy-options policy-statement send-static term 1 then local-preference 200 set policy-options policy-statement send-static term 1 then accept set routing-options static route 172.16.6.0/24 reject set routing-options static route 0.0.0.0/0 next-hop 10.0.0.5 set routing-options autonomous-system 200
Verfahren
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie auf verschiedenen Ebenen in der Konfigurationshierarchie navigieren. 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 zum 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 zum 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-Gruppen-Peering-Sitzung hinzu.[edit protocols bgp group int] user@R2# set advertise-external
Konfigurieren Sie die Autonome Systemnummer (AS) und die Router-ID.
[edit routing-options ] user@R2# set router-id 192.168.0.2 user@R2# set autonomous-system 200
Ergebnisse
Bestätigen Sie Ihre Konfiguration im Konfigurationsmodus, indem Sie die show interfacesBefehle , show protocols, show policy-optionsund show routing-options eingeben. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@R2# show interfaces
fe-1/2/0 {
unit 0{
description to-R1;
family inet {
address 10.0.0.2/30;
}
}
}
fe-1/2/1 {
unit 0 {
description to-R3;
family inet {
address 10.0.0.5/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.2/32;
}
}
}
user@R2# show protocols
bgp {
group ext {
type external;
peer-as 100;
neighbor 10.0.0.1;
}
group int {
type internal;
local-address 192.168.0.2;
advertise-external;
neighbor 192.168.0.3;
}
}
ospf {
area 0.0.0.0 {
interface fe-1/2/1.0;
interface lo0.0 {
passive;
}
}
}
user@R2# show routing-options router-id 192.168.0.2; autonomous-system 200;
Wenn Sie mit der Konfiguration des Geräts fertig sind, geben Sie im Konfigurationsmodus ein commit .
Überprüfung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
- Überprüfen des aktiven BGP-Pfads
- Verifizieren der externen Routenanzeige
- Überprüfen der Route auf Gerät R3
- Experimentieren mit der bedingten Option
Überprüfen des aktiven BGP-Pfads
Zweck
Stellen Sie auf Gerät R2 sicher, dass sich das Präfix 172.16.6.0/24 in der Routing-Tabelle befindet und den erwarteten aktiven Pfad hat.
Aktion
user@R2> show route 172.16.6
inet.0: 8 destinations, 9 routes (8 active, 1 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.6.0/24 *[BGP/170] 00:00:07, localpref 200, from 192.168.0.3
AS path: I, validation-state: unverified
> to 10.0.0.6 via fe-1/2/1.0
[BGP/170] 03:23:03, localpref 100
AS path: 100 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
Bedeutung
Gerät R2 empfängt die Route 172.16.6.0/24 von Gerät R1 und R3. Die Route von Gerät R3 ist der aktive Pfad, wie durch den Sternchen (*) angegeben. Der aktive Pfad hat die höchste lokale Präferenz. Selbst wenn die lokalen Einstellungen der beiden Routen gleich wären, bliebe die Route vom Gerät R3 aktiv, da sie den kürzesten AS-Pfad hat.
Verifizieren der externen Routenanzeige
Zweck
Stellen Sie auf Gerät R2 sicher, dass die Route 172.16.6.0/24 für Gerät R3 angekündigt ist.
Aktion
user@R2> show route advertising-protocol bgp 192.168.0.3 inet.0: 8 destinations, 9 routes (8 active, 1 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 172.16.6.0/24 10.0.0.1 100 100 I
Bedeutung
Gerät R2 wirbt für die Route 172.16.6.0/24 zum Gerät R3.
Überprüfen der Route auf Gerät R3
Zweck
Stellen Sie sicher, dass sich das Präfix 172.16.6.0/24 in der Routing-Tabelle des Geräts R3 befindet.
Aktion
user@R3> show route 172.16.6.0/24
inet.0: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.6.0/24 *[Static/5] 03:34:14
Reject
[BGP/170] 06:34:43, localpref 100, from 192.168.0.2
AS path: 100 I, validation-state: unverified
> to 10.0.0.5 via fe-1/2/0.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 ist, wenn die Route nicht erreichbar ist oder der nächste Hop nicht aufgelöst werden kann. Um diese Anforderung zu erfüllen, umfasst 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
Sehen Sie, wie die conditional Option im Kontext des BGP-Pfadauswahlalgorithmus funktioniert.
Aktion
Fügen Sie auf Gerät R2 die
conditionalOption hinzu.[edit protocols bgp group int] user@R2# set advertise-external conditional user@R2# commit
Prüfen Sie auf Gerät R2, ob die Route 172.16.6.0/24 für Gerät R3 angekündigt ist.
user@R2> show route advertising-protocol bgp 192.168.0.3
Wie erwartet wird die Route nicht mehr ausgeschrieben. Möglicherweise müssen Sie einige Sekunden warten, um dieses Ergebnis zu 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
Prüfen Sie auf Gerät R2, ob die Route 172.16.6.0/24 für Gerät R3 angekündigt ist.
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 nun angekündigt, weil die AS-Pfadlänge ignoriert wird und die lokalen Einstellungen gleich sind.
Beispiel: Konfiguration der präfixbasierten Filterung ausgehender Routen mit BGP
Dieses Beispiel zeigt, wie Sie einen Router von Juniper Networks so konfigurieren, dass er Routenfilter von Remote-Peers akzeptiert und ausgehende Routen mithilfe der empfangenen Filter filtert.
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 ausgehende Routenfilter mithilfe der empfangenen Filter durchführen kann. 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 für die Verarbeitung von Updates erforderlich sind. Diese Funktion kann zum Beispiel in einem virtuellen privaten Netzwerk (VPN) nützlich sein, in dem Teilmengen von Kunden-Edge-Geräten (CE) nicht alle Routen im VPN verarbeiten können. Die CE-Geräte können präfixbasierte Ausgehende Routenfilterung verwenden, um mit dem Provider-Edge-Routinggerät (PE) zu kommunizieren, um nur einen Teil 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 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 ist Gerät CE1 ein Router eines anderen Anbieters. Die in diesem Beispiel gezeigte Konfiguration entspricht dem Juniper Networks Router PE1.
Abbildung 3 zeigt das Beispielnetzwerk.
Konfiguration
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen sie in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, und kopieren Sie dann die Befehle und fügen sie auf Hierarchieebene in die [edit] CLI ein.
PE1
set protocols bgp group cisco-peers type external set protocols bgp group cisco-peers description “to CE1” set protocols bgp group cisco-peers local-address 192.168.165.58 set protocols bgp group cisco-peers peer-as 35 set protocols bgp group cisco-peers outbound-route-filter bgp-orf-cisco-mode set protocols bgp group cisco-peers outbound-route-filter prefix-based accept inet set protocols bgp group cisco-peers neighbor 192.168.165.56 set routing-options autonomous-system 65500
Verfahren
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie auf verschiedenen Ebenen in der Konfigurationshierarchie navigieren. 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 vom Gerät CE1 akzeptiert und ausgehende Routenfilter mithilfe der empfangenen Filter ausfü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 vom Gerät CE1 akzeptiert und ausgehende Routenfilter mithilfe der empfangenen Filter ausführt.
[edit protocols bgp group cisco-peers] user@PE1# set outbound-route-filter prefix-based accept inet
(Optional) Ermöglichung der 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 ihre Konfiguration im Konfigurationsmodus, indem Sie die show protocols befehle eingeben show routing-options . Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@PE1# show protocols
group cisco-peers {
type external;
description “to CE1”;
local-address 192.168.165.58;
peer-as 35;
outbound-route-filter {
bgp-orf-cisco-mode;
prefix-based {
accept {
inet;
}
}
}
neighbor 192.168.165.56;
}
user@PE1# show routing-options autonomous-system 65500;
Wenn Sie mit der Konfiguration des Geräts fertig sind, geben Sie im Konfigurationsmodus ein commit .
Überprüfung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
Verifizieren des ausgehenden Routenfilters
Zweck
Zeigt Informationen über den präfixbasierten ausgehenden Routenfilter an, der vom Gerät CE1 empfangen wird.
Aktion
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üfung des BGP Neighbor Mode
Zweck
Überprüfen Sie, ob 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.
Aktion
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 Standard-BGP-Routing-Richtlinie auf Paketübertragungs-Routern (PTX-Serie)
Auf Paketübertragungs-Routern der PTX-Serie unterscheidet sich die Standard-BGP-Routing-Richtlinie von denen anderer Junos OS-Routing-Geräte.
Bei den Routern der PTX-Serie handelt es sich um MPLS-Transitplattformen, die IP-Weiterleitungen durchführen, typischerweise über IGP-Routen (Interior Gateway Protocol). Die Packet Forwarding Engine der PTX-Serie kann eine relativ geringe Anzahl von Präfixen mit variabler Länge aufnehmen.
Ein Router der PTX-Serie kann vollständige BGP-Routen in der Steuerungsebene unterstützen, sodass er als Route Reflector (RR) verwendet werden kann. Es kann multicast-Weiterleitungen mit exakter Länge suchen und die Multicast-Weiterleitungsebene für die Verwendung durch die Unicast-Steuerungsebene erstellen (z. B. um eine Reverse-Path-Forwarding-Suche für Multicast durchzuführen).
Aufgrund der PFE-Einschränkung ist die Routing-Richtlinie für Router der PTX-Serie standardmässig, dass BGP-Routen nicht in der Weiterleitungstabelle installiert werden. Sie können die Standard-Routing-Richtlinie überschreiben 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 Merkmale:
Ermöglicht es Ihnen, das Standardverhalten zu überschreiben, ohne die Standardrichtlinie direkt ändern zu müssen
Reduziert das Risiko von versehentlichen Änderungen, die die Standardeinstellungen annullieren
Legt keine Ablaufsteuerungsaktionen fest, z. B. Akzeptieren und Ablehnen
Die Standard-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 dargestellt, ist die junos-ptx-series-default Richtlinie in [edit policy-options]definiert. Die Richtlinie wird mithilfe der default-export Anweisung in [edit routing-options forwarding-table]angewendet. Sie können diese Standardkonfigurationen mithilfe des | display inheritance Flags anzeigen.
Außerdem können Sie den show policy Befehl 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-packetWir empfehlen dringend, die junos-ptx-series-default Routing-Richtlinie 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 (im Wege der impliziten nächsten Richtlinienaktion) für jede Route ausgeführt. So können Sie alle aktionen, die von der junos-ptx-series-default Richtlinie festgelegt werden, außer Kraft setzen. Wenn Sie keine Exportrichtlinie konfigurieren, sind die von junos-ptx-series-default der Richtlinie festgelegten Aktionen die einzigen Aktionen.
Mit der Richtlinienaktion install-to-fib können Sie die no-install-to-fib Aktion außer Kraft setzen.
Ebenso können Sie festlegen, dass die load-balance per-prefix Aktion überschreiben load-balance per-packet wird.
Siehe auch
Beispiel: Überschreiben der Standard-BGP-Routing-Richtlinie auf Paketübertragungs-Routern der PTX-Serie
Dieses Beispiel zeigt, wie sie die Standard-Routing-Richtlinie auf Paketübertragungsroutern wie den Paketübertragungs-Routern der PTX-Serie außer Kraft setzt.
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 wie auf anderen Junos OS-Routing-Geräten. 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. Das ist das erwartete Verhalten.
Dieses Beispiel zeigt, wie Sie mithilfe der then install-to-fib Aktion die Standard-BGP-Routingrichtlinie effektiv außer Kraft setzen.
Konfiguration
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen sie in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, und kopieren Sie dann die Befehle und fügen sie auf Hierarchieebene in die [edit] CLI ein.
set policy-options prefix-list install-bgp 66.0.0.1/32 set policy-options policy-statement override-ptx-series-default term 1 from prefix-list install-bgp set policy-options policy-statement override-ptx-series-default term 1 then load-balance per-prefix set policy-options policy-statement override-ptx-series-default term 1 then install-to-fib set routing-options forwarding-table export override-ptx-series-default
Installation ausgewählter BGP-Routen in der Weiterleitungstabelle
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie auf verschiedenen Ebenen in der Konfigurationshierarchie navigieren. 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 der zu installierenden Präfixe in der Weiterleitungstabelle.
[edit policy-options prefix-list install-bgp] user@host# set 66.0.0.1/32
Konfigurieren Sie die Routing-Richtlinie und wenden Sie die Präfixliste als 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 ihre Konfiguration im Konfigurationsmodus, indem Sie die show policy-options befehle eingeben show routing-options . Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@host# show policy-options
prefix-list install-bgp {
66.0.0.1/32;
}
policy-statement override-ptx-series-default {
term 1 {
from {
prefix-list install-bgp;
}
then {
load-balance per-prefix;
install-to-fib;
}
}
}
user@host# show routing-options
forwarding-table {
export override-ptx-series-default;
}
Wenn Sie mit der Konfiguration des Geräts fertig sind, geben Sie im Konfigurationsmodus ein commit .
Überprüfung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
Überprüfen der Installation der ausgewählten Route in der Weiterleitungstabelle
Zweck
Stellen Sie sicher, dass die konfigurierte Richtlinie die Standardrichtlinie überschreibt.
Aktion
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 Werbung Für die bedingte Installation von Präfixen – Anwendungsfälle
Netzwerke werden in der Regel in kleinere, besser zu verwaltende Einheiten unterteilt, die als autonome Systeme (ASs) bezeichnet werden. Wenn BGP von Routern verwendet wird, um Peer-Beziehungen in derselben AS zu bilden, wird es als internal BGP (IBGP) bezeichnet. Wenn BGP von Routern verwendet wird, um Peer-Beziehungen in verschiedenen ASs zu bilden, wird es als externes BGP (EBGP) bezeichnet.
Nach der Durchführung von Routensanitätsprüfungen akzeptiert ein BGP-Router die von seinen Peers empfangenen Routen und installiert sie in die Routing-Tabelle. Standardmäßig folgen alle Router in IBGP- und EBGP-Sitzungen den Standardregeln für BGP-Ankündigungen. Während ein Router in einer IBGP-Sitzung nur die Routen anpreist, die von seinen direkten Peers gelernt wurden, gibt ein Router in einer EBGP-Sitzung alle Routen an, die von seinen direkten und indirekten Peers (Peers of Peers) gelernt wurden. Daher fügt ein Router in einem typischen EBGP-Netzwerk alle von einem EBGP-Peer empfangenen Routen in seine Routing-Tabelle ein und gibt fast alle Routen an alle EBGP-Peers an.
Ein Service Provider, der BGP-Routen mit Kunden und Peers im Internet austauscht, ist von böswilligen und unbeabsichtigten Bedrohungen bedroht, die sowohl das korrekte Routing des Datenverkehrs als auch den Betrieb der Router gefährden 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 einen Aggregierten seines Adressraums. Angesichts der Größe der Internet-Routing-Tabelle muss dies sorgfältig kontrolliert werden. Ein Edge-Router benötigt möglicherweise auch nur eine Standardroute in Richtung 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-Routingtabelle ändert, kann er verhindern, dass der Datenverkehr sein beabsichtigtes Ziel erreicht.
BGP route hijacking— Ein nicht autorisierter Administrator eines BGP-Peers könnte böswillig die Präfixe eines Netzwerks ankündigen, um den für das Opfer bestimmten Datenverkehr auf das Netzwerk des Administrators umzuleiten, um zugriff auf die Inhalte des Datenverkehrs zu erhalten oder die Online-Services 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 die Fähigkeit des Routers beeinträchtigen, gültige BGP-Routeninformationen zu verarbeiten.
Die bedingte Installation von Präfixen kann verwendet werden, um alle zuvor genannten Probleme zu lösen. 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, sodass die bedingte Installation von Präfixen unerlässlich ist.
ASs sind nicht nur an physische Beziehungen, sondern auch an Geschäftliche oder andere organisatorische Beziehungen gebunden. Ein AS kann Services für ein anderes Unternehmen bereitstellen oder als Transit-AS zwischen zwei anderen ASs fungieren. Diese Transit-ASs sind an vertragliche Vereinbarungen zwischen den Parteien gebunden, die Parameter für die Verbindung zueinander und vor allem die Art und Menge des Datenverkehrs, den sie füreinander übertragen, enthalten. Daher müssen Service Provider aus rechtlichen und finanziellen Gründen Richtlinien implementieren, die steuern, wie BGP-Routen mit Nachbarn ausgetauscht werden, welche Routen von diesen Nachbarn akzeptiert werden und wie diese Routen den Datenverkehr zwischen den ASs beeinflussen.
Es gibt viele verschiedene Optionen, um Routen zu filtern, die von einem BGP-Peer empfangen werden, um sowohl Inter-AS-Richtlinien durchzusetzen als auch das Risiko des Empfangens potenziell schädlicher Routen zu minimieren. 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 Next-Hop-Wert, 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 den Abgleich eines bestimmten Attributwerts nicht aus. Möglicherweise muss der Service Provider 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 Upstream-Peer empfangen wird, nur dann, wenn überprüft werden kann, ob dieser Peer zu anderen Netzwerken weiter upstream erreichbar ist. Diese bedingte Routeninstallation vermeidet die Installation einer Standardroute, die verwendet wird, um Datenverkehr an diesen Peer zu senden, wenn der Peer seine Routen im Upstream verloren hat, was zu black-holed Datenverkehr führt. Um dies zu erreichen, kann der Router so konfiguriert werden, dass er in der Routingtabelle nach dem Vorhandensein einer bestimmten Route sucht und basierend auf diesem Wissen ein anderes Präfix akzeptiert oder ablehnen kann.
Beispiel: Konfigurieren einer Routing-Richtlinie 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 looped 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 dann in die Routingtabelle inet.0 importiert. In Fällen, in denen nur bestimmte Routen importiert werden müssen, können Bestimmungen getroffen werden, die so aussehen, dass das Peer-Routing-Gerät Routen basierend auf einer Bedingung oder einer Reihe von Bedingungen exportiert.
Die Bedingung für den Export einer Route kann basieren auf:
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 wird im Beispiel beschrieben: Konfigurieren einer Routing-Richtlinie für bedingte Ankündigung Aktivieren der bedingten Installation von Präfixen in einer Routing-Tabelle.
Bedingungen in Routing-Richtlinien können unabhängig davon konfiguriert werden, ob sie Teil der Export- oder Importrichtlinien oder beides sind. Die Exportrichtlinie unterstützt diese Bedingungen, die von der Routing-Richtlinie übernommen wurden, basierend auf der Existenz einer anderen Route in der Routing-Richtlinie. Die Importrichtlinie unterstützt diese Bedingungen jedoch nicht, und die Bedingungen werden auch dann nicht ausgeführt, wenn sie vorhanden sind.
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 angezeigt werden. Eine Exportrichtlinie wird auf ausgehende Routen angewendet, die in der Ausgabe des show route advertising-protocol bgp neighbor-address Befehls angezeigt werden.
Um eine bedingte Installation von Präfixen zu ermöglichen, muss eine Exportrichtlinie auf dem Gerät konfiguriert werden, auf dem der Prefix-Export erfolgen muss. Die Exportrichtlinie bewertet jede Route, um zu überprüfen, ob sie alle Übereinstimmungsbedingungen gemäß der from Anweisung erfüllt. Es sucht auch nach der Existenz der Route, die unter der condition Anweisung definiert wurde (auch unter der from Anweisung konfiguriert).
Wenn die Route nicht mit dem gesamten Satz der erforderlichen Bedingungen übereinstimmt, die in der Richtlinie definiert wurden, oder wenn die unter der condition Anweisung definierte Route nicht in der Routingtabelle vorhanden ist, wird die Route nicht in ihre BGP-Peers exportiert. Daher entspricht eine bedingte Exportrichtlinie den Routen für die gewünschte Route oder das gewünschte Präfix, das Sie in der Routing-Tabelle der Peers installieren möchten.
So konfigurieren Sie die bedingte Installation von Präfixen mithilfe 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 eine Exportrichtlinie mit der neu erstellten Bedingung mithilfe der
conditionAnweisung.[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, für das nur ausgewählte Präfixe aus der Routingtabelle exportiert werden müssen.
[edit] protocols bgp { group group-name { export policy-name; } }
Siehe auch
Beispiel: Konfigurieren einer Routing-Richtlinie für bedingte Ankündigung Aktivieren der bedingten Installation von Präfixen in einer Routing-Tabelle
Dieses Beispiel zeigt, wie sie die bedingte Installation von Präfixen in einer Routingtabelle mithilfe der BGP-Exportrichtlinie konfigurieren.
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 werden drei Router in drei verschiedenen autonomen Systemen (ASs) mit dem BGP-Protokoll verbunden und konfiguriert. Der Als Internet gekennzeichnete Router, der Upstream-Router, 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) wird als Router-ID konfiguriert. Diese sechs Adressen werden in BGP exportiert, um den Inhalt einer BGP-Routing-Tabelle eines mit dem Internet verbundenen Routers zu emulieren und im Norden bekannt zu machen.
Die Nord- und Süd-Router 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 North exportiert eine Standardroute in BGP und kündigt die Standardroute und die fünf BGP-Routen an Router South an, den Downstream-Router. Router South empfängt die Standardroute und nur eine andere Route (172.16.11.1/32) und installiert diese Route und die Standardroute in seiner Routing-Tabelle.
Kurz gesagt erfüllt das Beispiel die folgenden Anforderungen:
Senden Sie im Norden nur 0/0 nach Süden, wenn auch eine bestimmte Route gesendet wird (im Beispiel 172.16.11.1/32).
Akzeptieren Sie auf South die Standardroute und die Route 172.16.11.1/32. Lassen Sie alle anderen Routen fallen. Denken Sie daran, dass South möglicherweise die gesamte Internettabelle empfängt, während der Betreiber nur den Standard und ein anderes spezifisches Präfix haben möchte.
Die erste Anforderung wird mit einer Exportrichtlinie auf North erfüllt:
user@North# show policy-options
policy-statement conditional-export-bgp {
term prefix_11 {
from {
protocol bgp;
route-filter 10.11.0.0/5 orlonger;
}
then accept;
}
term conditional-default {
from {
route-filter 0.0.0.0/0 exact;
condition prefix_11;
}
then accept;
}
term others {
then reject;
}
}
condition prefix_11 {
if-route-exists {
172.16.11.1/32;
table inet.0;
}
}
Die Logik der bedingten Exportrichtlinie 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, senden Sie nicht 0/0.
Die zweite Anforderung ist mit einer Importrichtlinie für South erfüllt:
user@South# show policy-options
policy-statement import-selected-routes {
term 1 {
from {
rib inet.0;
neighbor 10.0.78.14;
route-filter 0.0.0.0/0 exact;
route-filter 10.11.0.0/8 orlonger;
}
then accept;
}
term 2 {
then reject;
}
}
In diesem Beispiel werden vier Routen aufgrund der Importrichtlinie in South gelöscht. Dies liegt daran, dass die Exportrichtlinie für North alle vom Internet empfangenen Routen ausleckt, und die Importrichtlinie für Süd schließt einige dieser Routen aus.
Es ist wichtig zu verstehen, dass in Junos OS eine Importrichtlinie (Eingehender Routenfilter) eine Route möglicherweise ablehnen, nicht für die Weiterleitung des Datenverkehrs verwendet und nicht in eine Ankündigung für andere Peers aufgenommen wird, der Router diese Routen als versteckte Routen beibehält. Diese versteckten Routen sind für Richtlinien- oder Routing-Zwecke nicht verfügbar. Sie belegen jedoch Speicherplatz auf dem Router. Ein Service Provider, der Routen filtert, um die Menge an Informationen zu kontrollieren, die im Speicher aufbewahrt und von einem Router verarbeitet werden, möchte möglicherweise, dass der Router die Routen, die von der Importrichtlinie abgelehnt werden, vollständig ausfällt.
Ausgeblendete Routen können mithilfe des show route receive-protocol bgp neighbor-address hidden Befehls angezeigt werden. Die ausgeblendeten Routen können dann beibehalten oder aus der Routingtabelle entfernt werden, indem Sie die keep all | none Anweisung auf Hierarchie [edit protocols bgp] - oder [edit protocols bgp group group-name] Hierarchieebene konfigurieren.
Die Regeln für die BGP-Routenbindung sind wie folgt:
Standardmäßig werden alle Routen, die aus BGP gelernt wurden, beibehalten, außer denen, bei denen der AS-Pfad geschleifet wird. (Der AS-Pfad umfasst 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 die Konfiguration der
keep noneAnweisung verwirft BGP Routen, die von einem Peer empfangen wurden und die durch eine Importrichtlinie oder andere Überprüfung der Vernunft 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 die Routenaktualisierung konfigurieren keep all oder keep none und die Peers die Routenaktualisierung unterstützen, sendet der lokale Sprecher eine Aktualisierungsnachricht und führt eine Importauswertung durch. Für diese Peers werden die Sitzungen nicht neu gestartet. Um zu bestimmen, ob ein Peer die Aktualisierung unterstützt, überprüfen Sie Peer supports Refresh capability in der Ausgabe des show bgp neighbor Befehls nach.
Wenn Sie den keep allkeep none Sitzungsneustart nicht unterstützen, 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 in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, und kopieren Sie dann die Befehle und fügen sie auf Hierarchieebene in die [edit] CLI ein.
Router-Internet
set interfaces lo0 unit 0 family inet address 172.16.11.1/32 set interfaces lo0 unit 0 family inet address 172.16.12.1/32 set interfaces lo0 unit 0 family inet address 172.16.13.1/32 set interfaces lo0 unit 0 family inet address 172.16.14.1/32 set interfaces lo0 unit 0 family inet address 172.16.15.1/32 set interfaces lo0 unit 0 family inet address 192.168.9.1/32 set interfaces fe-0/1/3 unit 0 family inet address 10.0.89.14/30 set protocols bgp group toNorth local-address 10.0.89.14 set protocols bgp group toNorth peer-as 200 set protocols bgp group toNorth neighbor 10.0.89.13 set protocols bgp group toNorth export into-bgp set policy-options policy-statement into-bgp term 1 from interface lo0.0 set policy-options policy-statement into-bgp term 1 then accept set routing-options router-id 192.168.9.1 set routing-options autonomous-system 300
Router Nord
set interfaces fe-1/3/1 unit 0 family inet address 10.0.78.14/30 set interfaces fe-1/3/0 unit 0 family inet address 10.0.89.13/30 set interfaces lo0 unit 0 family inet address 192.168.8.1/32 set protocols bgp group toInternet local-address 10.0.89.13 set protocols bgp group toInternet peer-as 300 set protocols bgp group toInternet neighbor 10.0.89.14 set protocols bgp group toSouth local-address 10.0.78.14 set protocols bgp group toSouth export conditional-export-bgp set protocols bgp group toSouth peer-as 100 set protocols bgp group toSouth neighbor 10.0.78.13 set policy-options policy-statement conditional-export-bgp term prefix_11 from protocol bgp set policy-options policy-statement conditional-export-bgp term prefix_11 from route-filter 10.11.0.0/5 orlonger set policy-options policy-statement conditional-export-bgp term prefix_11 then accept set policy-options policy-statement conditional-export-bgp term conditional-default from route-filter 0.0.0.0/0 exact set policy-options policy-statement conditional-export-bgp term conditional-default from condition prefix_11 set policy-options policy-statement conditional-export-bgp term conditional-default then accept set policy-options policy-statement conditional-export-bgp term others then reject set policy-options condition prefix_11 if-route-exists 172.16.11.1/32 set policy-options condition prefix_11 if-route-exists table inet.0 set routing-options static route 0/0 reject set routing-options router-id 192.168.8.1 set routing-options autonomous-system 200
Router Süd
set interfaces fe-0/1/2 unit 0 family inet address 10.0.78.13/30 set interfaces lo0 unit 0 family inet address 192.168.7.1/32 set protocols bgp group toNorth local-address 10.0.78.13 set protocols bgp group toNorth import import-selected-routes set protocols bgp group toNorth peer-as 200 set protocols bgp group toNorth neighbor 10.0.78.14 set policy-options policy-statement import-selected-routes term 1 from neighbor 10.0.78.14 set policy-options policy-statement import-selected-routes term 1 from route-filter 10.11.0.0/8 orlonger set policy-options policy-statement import-selected-routes term 1 from route-filter 0.0.0.0/0 exact set policy-options policy-statement import-selected-routes term 1 then accept set policy-options policy-statement import-selected-routes term 2 then reject set routing-options router-id 192.168.7.1 set routing-options autonomous-system 100
Konfigurieren bedingter Installation von Präfixen
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie auf verschiedenen Ebenen in der Konfigurationshierarchie navigieren. 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 Routerschnittstellen, die die Verbindungen zwischen den drei Routern bilden.
Router Internet [edit interfaces] user@Internet# set fe-0/1/3 unit 0 family inet address 10.0.89.14/30
Router North [edit interfaces] user@North# set fe-1/3/1 unit 0 family inet address 10.0.78.14/30 user@North# set fe-1/3/0 unit 0 family inet address 10.0.89.13/30
Router South [edit interfaces] user@South# set fe-0/1/2 unit 0 family inet address 10.0.78.13/30
Konfigurieren Sie fünf Loopback-Schnittstellenadressen im Router-Internet, um aus dem Internet gelernte BGP-Routen zu emulieren, die in die Routingtabelle von Router South 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 auch 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 North, die an Router South angekündigt wird.
[edit routing-options] user@North# set static route 0/0 reject
Definieren Sie die Bedingung für den Export von Präfixen aus der Routing-Tabelle auf Router North.
[edit policy-options condition prefix_11] user@North# set if-route-exists 172.16.11.1/32 user@North# set if-route-exists table inet.0
Definieren Sie Exportrichtlinien (
into-bgpundconditional-export-bgp) auf Routern Internet bzw. North, um Routen zu BGP anzukündigen.HINWEIS:Stellen Sie sicher,
prefix_11dass Sie die Bedingung (in Schritt 4konfiguriert) in der Exportrichtlinie referenzieren.Router Internet [edit policy-options policy-statement into-bgp ] user@Internet# set term 1 from interface lo0.0 user@Internet# set term 1 then accept
Router North [edit policy-options policy-statement conditional-export-bgp] user@North# set term prefix_11 from protocol bgp user@North# set term prefix_11 from route-filter 10.11.0.0/5 orlonger user@North# set term prefix_11 then accept user@North# set term conditional-default from route-filter 0.0.0.0/0 exact user@North# set term conditional-default from condition prefix_11 user@North# set term conditional-default then accept user@North# set term others then reject
Definieren Sie eine Importrichtlinie (
import-selected-routes) auf Router South, um einige der von Router North 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 10.11.0.0/8 orlonger user@South# set term 1 from route-filter 0.0.0.0/0 exact user@South# set term 1 then accept user@South# set term 2 then reject
Konfigurieren 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äfix-Ankündigung stattfinden soll.
Router Internet [edit protocols bgp group toNorth] user@Internet# set local-address 10.0.89.14 user@Internet# set peer-as 200 user@Internet# set neighbor 10.0.89.13 user@Internet# set export into-bgp
Router North [edit protocols bgp group toInternet] user@North# set local-address 10.0.89.13 user@North# set peer-as 300 user@North# set neighbor 10.0.89.14
[edit protocols bgp group toSouth] user@North# set local-address 10.0.78.14 user@North# set peer-as 100 user@North# set neighbor 10.0.78.13 user@North# set export conditional-export-bgp
Router South [edit protocols bgp group toNorth] user@South# set local-address 10.0.78.13 user@South# set peer-as 200 user@South# set neighbor 10.0.78.14 user@South# set import import-selected-routes
Konfigurieren Sie die Router-ID und die autonome Systemnummer für alle drei Router.
HINWEIS:In diesem Beispiel wird die Router-ID basierend auf der IP-Adresse konfiguriert, die auf der lo0.0-Schnittstelle des Routers konfiguriert wurde.
Router Internet [edit routing options] user@Internet# set router-id 192.168.9.1 user@Internet# set autonomous-system 300
Router North [edit routing options] user@North# set router-id 192.168.8.1 user@North# set autonomous-system 200
Router South [edit routing options] user@South# set router-id 192.168.7.1 user@South# set autonomous-system 100
Ergebnisse
Bestätigen Sie Ihre Konfiguration im Konfigurationsmodus, indem Sie die show interfacesBefehle , show protocols bgp, show policy-optionsund show routing-options . Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
Geräte-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 200;
neighbor 10.0.89.13;
}
user@Internet# show policy-options
policy-statement into-bgp {
term 1 {
from interface lo0.3;
then accept;
}
}
user@Internet# show routing-options router-id 192.168.9.1; autonomous-system 300;
Gerät 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 300;
neighbor 10.0.89.14;
}
group toSouth {
local-address 10.0.78.14;
export conditional-export-bgp;
peer-as 100;
neighbor 10.0.78.13;
}
user@North# show policy-options
policy-statement conditional-export-bgp {
term prefix_11 {
from {
protocol bgp;
route-filter 10.11.0.0/5 orlonger;
}
then accept;
}
term conditional-default {
from {
route-filter 0.0.0.0/0 exact;
condition prefix_11;
}
then accept;
}
term others {
then reject;
}
}
condition prefix_11 {
if-route-exists {
172.16.11.1/32;
table inet.0;
}
}
user@North# show routing-options
static {
route 0.0.0.0/0 reject;
}
router-id 192.168.8.1;
autonomous-system 200;
Gerät 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 200;
neighbor 10.0.78.14;
}
}
user@South# show policy-options
policy-statement import-selected-routes {
term 1 {
from {
neighbor 10.0.78.14;
route-filter 10.11.0.0/8 orlonger;
route-filter 0.0.0.0/0 exact;
}
then accept;
}
term 2 {
then reject;
}
}
user@South# show routing-options router-id 192.168.7.1; autonomous-system 100;
Wenn Sie mit der Konfiguration der Router fertig sind, geben Sie im Konfigurationsmodus ein commit .
Überprüfung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
- BGP überprüfen
- Überprüfung der Prefix-Ankündigung vom Router Internet zum Router North
- Überprüfung der Präfix-Ankündigung von Router Nord zu Router Süd
- Überprüfen der BGP-Importrichtlinie für die Installation von Präfixen
- Überprüfung des bedingten Exports von Router Nord zu Router Süd
- Überprüfen des Vorhandenseins von Routen, die von der Richtlinie ausgeblendet werden (optional)
BGP überprüfen
Zweck
Stellen Sie sicher, dass BGP-Sitzungen zwischen den drei Routern eingerichtet wurden.
Aktion
Führen Sie den Befehl im show bgp neighbor neighbor-address Betriebsmodus aus.
Überprüfen Sie die BGP-Sitzung auf Router Internet, um zu überprüfen, ob Router North ein Nachbar ist.
user@Internet> show bgp neighbor 10.0.89.13 Peer: 10.0.89.13+179 AS 200 Local: 10.0.89.14+56187 AS 300 Type: External State: Established Flags: [ImportEval Sync] Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ into-bgp ] Options: [Preference LocalAddress PeerAS Refresh] Local Address: 10.0.89.14 Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 192.168.8.1 Local ID: 192.168.9.1 Active Holdtime: 90 Keepalive Interval: 30 Group index: 0 Peer index: 0 BFD: disabled, down Local Interface: fe-0/1/3.0 NLRI for restart configured on peer: inet-unicast NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Stale routes from peer are kept for: 300 Peer does not support Restarter functionality NLRI that restart is negotiated for: inet-unicast NLRI of received end-of-rib markers: inet-unicast NLRI of all end-of-rib markers sent: inet-unicast Peer supports 4 byte AS extension (peer-as 200) Peer does not support Addpath Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 0 Accepted prefixes: 0 Suppressed due to damping: 0 Advertised prefixes: 6 Last traffic (seconds): Received 9 Sent 18 Checked 28 Input messages: Total 12 Updates 1 Refreshes 0 Octets 232 Output messages: Total 14 Updates 1 Refreshes 0 Octets 383 Output Queue[0]: 0Überprüfen Sie die BGP-Sitzung auf Router North, um zu überprüfen, ob Router Internet ein Nachbar ist.
user@North> show bgp neighbor 10.0.89.14 Peer: 10.0.89.14+56187 AS 300 Local: 10.0.89.13+179 AS 200 Type: External State: Established Flags: [ImportEval Sync] Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Options: [Preference LocalAddress PeerAS Refresh] Local Address: 10.0.89.13 Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 192.168.9.1 Local ID: 192.168.8.1 Active Holdtime: 90 Keepalive Interval: 30 Group index: 0 Peer index: 0 BFD: disabled, down Local Interface: fe-1/3/0.0 NLRI for restart configured on peer: inet-unicast NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Stale routes from peer are kept for: 300 Peer does not support Restarter functionality NLRI that restart is negotiated for: inet-unicast NLRI of received end-of-rib markers: inet-unicast NLRI of all end-of-rib markers sent: inet-unicast Peer supports 4 byte AS extension (peer-as 300) Peer does not support Addpath Table inet.0 Bit: 10001 RIB State: BGP restart is complete Send state: in sync Active prefixes: 6 Received prefixes: 6 Accepted prefixes: 6 Suppressed due to damping: 0 Advertised prefixes: 0 Last traffic (seconds): Received 14 Sent 3 Checked 3 Input messages: Total 16 Updates 2 Refreshes 0 Octets 402 Output messages: Total 15 Updates 0 Refreshes 0 Octets 348 Output Queue[0]: 0
Überprüfen Sie die folgenden Felder in diesen Ausgaben, um zu überprüfen, ob BGP-Sitzungen eingerichtet wurden:
Peer— Prüfen Sie, ob die Peer-AS-Nummer aufgeführt ist.
Local– Prüfen Sie, ob die lokale AS-Nummer aufgeführt ist.
State— Stellen Sie sicher, dass der Wert .
EstablishedWenn nicht, überprüfen Sie die Konfiguration noch einmal und finden Sieshow bgp neighborweitere Details zu den Ausgabefeldern.
Stellen Sie auch sicher, dass die Router Nord und Süd zueinander Peer-Beziehungen bilden.
Bedeutung
BGP-Sitzungen werden zwischen den drei Routern eingerichtet.
Überprüfung der Prefix-Ankündigung vom Router Internet zum Router North
Zweck
Stellen Sie sicher, dass die vom Router-Internet gesendeten Routen von Router North empfangen werden.
Aktion
Führen Sie den Befehl im Betriebsmodus des Router-Internets
show route advertising-protocol bgp neighbor-addressaus.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 Loopback-Adresse, die als Router-ID verwendet wird) an Router North.
Führen Sie den
show route receive-protocol bgp neighbor-addressBefehl im Betriebsmodus des Routers 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 300 I * 172.16.12.1/32 10.0.89.14 300 I * 172.16.13.1/32 10.0.89.14 300 I * 172.16.14.1/32 10.0.89.14 300 I * 172.16.15.1/32 10.0.89.14 300 I * 192.168.9.1/32 10.0.89.14 300 I
Die Ausgabe überprüft, ob Router North alle von Router Internet angekündigten Routen empfangen hat.
Bedeutung
Präfixe, die von Router Internet gesendet werden, wurden erfolgreich in die Routing-Tabelle auf Router North installiert.
Überprüfung der Präfix-Ankü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 North to Router South angekündigt werden.
Aktion
Führen Sie den
show route 0/0 exactBefehl im Betriebsmodus des Routers 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 North.
Führen Sie den
show route advertising-protocol bgp neighbor-addressBefehl im Betriebsmodus des Routers 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 300 I * 172.16.12.1/32 Self 300 I * 172.16.13.1/32 Self 300 I * 172.16.14.1/32 Self 300 I * 172.16.15.1/32 Self 300 I
Die Ausgabe überprüft, ob Router North die statische Route und die 172.16.11.1/32-Route angibt, die vom Router-Internet sowie viele andere Routen zu Router South empfangen wird.
Ü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.
Aktion
Prüfen Sie, ob die Importrichtlinie auf Router South betriebsbereit ist, indem Sie prüfen, ob nur die statische Standardroute von Router North und die 172.16.11.1/32-Route von Router South in der Routing-Tabelle installiert sind.
Führen Sie den Befehl im show route receive-protocol bgp neighbor-address 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 200 I * 172.16.11.1/32 10.0.78.14 200 300 I
Die Ausgabe überprüft, ob die BGP-Importrichtlinie auf Router South betriebsbereit ist, und nur die statische Standardroute 0.0.0.0/0 von Router North und die 172.16.11.1/32-Route vom Router Internet sind in der Routing-Tabelle auf Router South durchgesickert.
Bedeutung
Die Installation von Präfixen ist aufgrund der konfigurierten BGP-Importrichtlinie erfolgreich.
Überprüfung des bedingten Exports von Router Nord zu Router Süd
Zweck
Stellen Sie sicher, dass Device North die Standard-0/0-Route nicht mehr sendet, wenn geräteintern die Route 172.16.1.1/32 nicht mehr gesendet wird.
Aktion
Veranlassen Sie das Internet des Geräts, die 172.16.11.1/32-Route nicht mehr zu senden, indem Sie die 172.16.11.1/32-Adresse 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 des Routers 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 300 I * 172.16.13.1/32 Self 300 I * 172.16.14.1/32 Self 300 I * 172.16.15.1/32 Self 300 I
In der Ausgabe wird überprüft, ob Router North nicht die Standardroute zu Router South angibt. Dies ist das erwartete Verhalten, wenn die Route 172.16.11.1/32 nicht vorhanden ist.
Aktivieren Sie die 172.16.11.1/32-Adresse auf der Loopback-Schnittstelle des Internets des Geräts.
[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 von der Richtlinie ausgeblendet werden (optional)
Zweck
Überprüfen Sie das Vorhandensein von Routen, die durch die auf Router South konfigurierte Importrichtlinie ausgeblendet werden.
In diesem Abschnitt werden die Auswirkungen verschiedener Änderungen veranschaulicht, die Sie je nach Ihren Anforderungen an der Konfiguration vornehmen können.
Aktion
Anzeigen von Routen, die in der Routing-Tabelle von Router South ausgeblendet sind:
Verwenden der
hiddenOption für denshow route receive-protocol bgp neighbor-addressBefehl.Deaktivierung der Importrichtlinie.
Führen Sie den
show route receive-protocol bgp neighbor-address hiddenBefehl im Betriebsmodus aus, um versteckte 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 200 300 I 172.16.13.1/32 10.0.78.14 200 300 I 172.16.14.1/32 10.0.78.14 200 300 I 172.16.15.1/32 10.0.78.14 200 300 I
Die Ausgabe überprüft das Vorhandensein von Routen, die 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 South versteckt sind.
Deaktivieren Sie die BGP-Importrichtlinie, indem Sie die
deactivate importAnweisung auf[edit protocols bgp group group-name]Hierarchieebene konfigurieren.[edit protocols bgp group toNorth] user@South# deactivate import user@South# commit
Führen Sie den
show route receive-protocol bgp neighbor-addressBefehl im Betriebsmodus 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 200 I * 172.16.11.1/32 10.0.78.14 200 300 I * 172.16.12.1/32 10.0.78.14 200 300 I * 172.16.13.1/32 10.0.78.14 200 300 I * 172.16.14.1/32 10.0.78.14 200 300 I * 172.16.15.1/32 10.0.78.14 200 300 I
Die Ausgabe überprüft das Vorhandensein von bisher versteckten 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 Routingtabelle, indem Sie die Anweisungen bzw
keep none. dieactivate importAnweisungen 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 den
show route receive-protocol bgp neighbor-address hiddenBefehl im Betriebsmodus 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 versteckten Routen aufgrund der konfigurierten
keep noneAnweisung nicht in der Routingtabelle verwaltet werden.
Impliziter Filter für Standard-EBGP-Routenausbreitungsverhalten ohne Richtlinien
SUMMARY In diesem Abschnitt geht es um die Verwendung eines impliziten Filters zur Regulierung des EBGP-Routenausbreitungsverhaltens, wenn keine explizite Richtlinie konfiguriert ist.
Vorteile
Diese Funktion bietet die folgenden Vorteile:
Regulates BGP implementation— Verhindert, dass EBGP-Lautsprecher zu einem unbeaufsichtigten Pass-Through werden, bei dem sie standardmäßig alle Routen akzeptiert und angekündigt haben. Diese Funktion senkt den Anstieg des Transitverkehrs in autonomen Leaf-Systemen, insbesondere, wenn diese multi-homed zu beliebigen upstream-Internet Service Providern werden. So verhindert es auch den leisen Ausfall 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 festgelegt ist, dass alle Routen standardmäßig empfangen und ankündigen. Die Konfigurationsaussage fügt nur bei Bedarf eine Option hinzu, um für Akzeptieren-, Ablehnen- und Ablehnungsklauseln aktivieren oder deaktivieren zu können. Der implizite Filter stellt sicher, dass die Benutzer mit vorhandenen Bereitstellungen, die auf der Standard-BGP-Richtlinie basieren, keine Betriebsunterbrechungen erleben.
Überblick
BGP ist das aktuelle autonome Inter-Domain-Protokoll, das für globales Internet-Routing verwendet wird. Es unterstützt auch verschiedene Services wie VPNs und Link State, die nicht für die globale Nutzung vorgesehen sind.
Die BGP-Implementierung, einschließlich des Standard-EBGP-Verhaltens, wird von RFC4271, A Border Gateway Protocol 4 (BGP-4) geleitet. Es gibt jedoch keine expliziten Anleitungen für die Festlegung der Routen, die verteilt werden sollen. Dies führt dazu, dass die ursprüngliche BGP-Implementierung ein unbeaufsichtigter Pass-Through für Routen ohne jegliche Filterung ist, was zu einem Anstieg des Datenverkehrs führt, was zu globalen Internetausfällen führt.
Ab Junos OS Version 20.3R1 haben wir einen impliziten Filter defaults ebgp no-policy auf der bestehenden [edit protocols bgp] Hierarchieebene eingeführt. Die Konfiguration trennt die Standardrichtlinie für "Receive" und "Werben" in separate Klauseln (akzeptieren, ablehnen oder immer ablehnen), damit das Verhalten unabhängig voneinander variieren kann.
Wenn keine explizite Richtlinie konfiguriert ist, ermöglicht Ihnen der implizite Filter die Aktivierung des Standard-eBGP-Empfangs- und Werbeverhaltens in einem von drei Status wie folgt:
Werte |
Standardrichtlinie |
Was macht es? |
|---|---|---|
Akzeptieren |
Erhalten |
Akzeptiert alle Routen (auch das Standardverhalten). |
Werben |
Akzeptiert, alle Routen anzukündigen (auch das Standardverhalten). |
|
Ablehnen |
Erhalten |
Lehnt den Empfang von Routen vom Typ inet Unicast und inet6 Unicast in den Instanztypen primary, vrf, virtual-router und non-forwarding ab. |
Werben |
Lehnt ab, um Routen des Typs Inet-Unicast und inet6-Unicast in instanztypen primary, vrf, virtual-router und non-forwarding anzukündigen. |
|
Immer ablehnen |
Erhalten |
Lehnt ab, um alle Routen zu erhalten. |
Werben |
Lehnt es ab, alle Routen anzukündigen. |