Auf dieser Seite
Beispiel: Konfigurieren von IPv6-BGP-Routen über IPv4-Transport
Anzeigen von IPv4-Routen über BGP IPv6-Sitzungen – Übersicht
Verständnis der Neuverteilung von IPv4-Routen mit IPv6 Next Hop in BGP
Konfigurieren von BGP zur Neuverteilung von IPv4-Routen mit IPv6-Next-Hop-Adressen
Grundlegendes zu BGP-Flow-Routen für die Filterung des Datenverkehrs
Beispiel: Ermöglichen von BGP zur Übertragung von Datenstromspezifikationsrouten
Beispiel: Konfiguration von BGP für die Übertragung von IPv6-Datenstromspezifikationsrouten
Konfiguration der BGP Flow Specification Action Umleitung zu IP zum Filtern von DDoS-Datenverkehr
Weiterleitung des Datenverkehrs mithilfe der DSCP-Aktion der BGP-Datenstromspezifikation
Multiprotocol BGP
Grundlegendes zu Multiprotocol-BGP
Multiprotocol BGP (MP-BGP) ist eine Erweiterung von BGP, die es BGP ermöglicht, Routing-Informationen für mehrere Netzwerkschichten und Adressfamilien zu übertragen. MP-BGP kann die für Multicast-Routing verwendeten Unicast-Routen separat von den Für unicast-IP-Weiterleitungen verwendeten Routen übertragen.
Um MP-BGP zu aktivieren, konfigurieren Sie BGP so, dass Die Netzwerkschicht-Erreichbarkeitsinformationen (NLRI) für andere Adressfamilien als Unicast-IPv4 übertragen werden, indem Sie die family inet Anweisung einfügen:
family inet { (any | flow | labeled-unicast | multicast | unicast) { accepted-prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop-excess <percentage>; hide-excess <percentage>;} } <loops number>; prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop-excess <percentage>; hide-excess <percentage>;} } rib-group group-name; topology name { community { target identifier; } } } }
Um MP-BGP zu ermöglichen, NLRI für die IPv6-Adressfamilie zu übertragen, fügen Sie die Anweisung ein family inet6 :
family inet6 { (any | labeled-unicast | multicast | unicast) { accepted-prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop-excess <percentage>; hide-excess <percentage>;} } <loops number>; prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop-excess <percentage>; hide-excess <percentage>;} } rib-group group-name; } }
Fügen Sie nur auf Routern die Anweisung ein, um MP-BGP zur Übertragung von Layer 3-NLRI für virtuelle private Netzwerke (VPN) für die IPv4-Adressfamilie zu family inet-vpn aktivieren:
family inet-vpn { (any | flow | multicast | unicast) { accepted-prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop-excess <percentage>; hide-excess <percentage>;} } <loops number>; prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop-excess <percentage>; hide-excess <percentage>;} } rib-group group-name; } }
Nur auf Routern, um MP-BGP zur Übertragung von Layer-3-VPN-NLRI für die IPv6-Adressfamilie zu aktivieren, fügen Sie die family inet6-vpn Anweisung ein:
family inet6-vpn { (any | multicast | unicast) { accepted-prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop-excess <percentage>; hide-excess <percentage>;} } <loops number>; prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop-excess <percentage>; hide-excess <percentage>;}} rib-group group-name; } }
Um MP-BGP nur auf Routern zu aktivieren, um Multicast-VPN-NLRI für die IPv4-Adressfamilie zu übertragen und VPN-Signalübertragung zu aktivieren, fügen Sie die Anweisung ein family inet-mvpn :
family inet-mvpn {
signaling {
accepted-prefix-limit {
maximum number;
teardown <percentage> <idle-timeout (forever | minutes)>;
drop-excess <percentage>;
hide-excess <percentage>;}}
<loops number>;
prefix-limit {
maximum number;
teardown <percentage> <idle-timeout (forever | minutes)>;
drop-excess <percentage>;
hide-excess <percentage>;}}
}
}
Um MP-BGP zu ermöglichen, Multicast VPN NLRI für die IPv6-Adressfamilie zu übertragen und VPN-Signalisierung zu aktivieren, fügen Sie die Anweisung ein family inet6-mvpn :
family inet6-mvpn {
signaling {
accepted-prefix-limit {
maximum number;
teardown <percentage> <idle-timeout (forever | minutes)>;
drop-excess <percentage>;
hide-excess <percentage>;}}
<loops number>;
prefix-limit {
maximum number;
teardown <percentage> <idle-timeout <forever | minutes>;
drop-excess <percentage>;
hide-excess <percentage>;}}
}
}
Weitere Informationen zu BGP-basierten Multicast-VPNs mit mehreren Protokollen finden Sie im Junos OS Multicast Protocols Benutzerhandbuch.
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisungen einschließen können, finden Sie in den Abschnitten zur Anweisungszusammenfassung für diese Anweisungen.
Wenn Sie die in der [edit protocols bgp family] Hierarchieebene angegebene Adressfamilie ändern, werden alle aktuellen BGP-Sitzungen auf dem Routinggerät unterbrochen und dann wieder aufgebaut.
In Junos OS Version 9.6 und höher können Sie einen Schleifenwert für eine bestimmte BGP-Adressfamilie angeben.
Standardmäßig tragen BGP-Peers nur Unicast-Routen, die für Unicast-Weiterleitungszwecke verwendet werden. Um BGP-Peers so zu konfigurieren, dass nur Multicast-Routen übertragen werden, geben Sie die multicast Option an. Um BGP-Peers so zu konfigurieren, dass sie sowohl Unicast- als auch Multicast-Routen übertragen, geben Sie die any Option an.
Wenn MP-BGP konfiguriert ist, installiert BGP die MP-BGP-Routen in verschiedene Routing-Tabellen. Jede Routing-Tabelle wird durch den Indikator der Protokollfamilie oder Adressfamilie (AFI) und einem nachfolgenden Adressfamilienbezeichner (SAFI) identifiziert.
Die folgende Liste zeigt alle möglichen AFI- und SAFI-Kombinationen:
AFI=1, SAFI=1, IPv4-Unicast
AFI=1, SAFI=2, IPv4-Multicast
AFI=1, SAFI=128, L3VPN IPv4-Unicast
AFI=1, SAFI=129, L3VPN IPv4-Multicast
AFI=2, SAFI=1, IPv6-Unicast
AFI=2, SAFI=2, IPv6-Multicast
AFI=25, SAFI=65, BGP-VPLS/BGP-L2VPN
AFI=2, SAFI=128, L3VPN IPv6-Unicast
AFI=2, SAFI=129, L3VPN IPv6-Multicast
AFI=1, SAFI=132, RT-Eingeschränkt
AFI=1, SAFI=133, Flow-spec
AFI=1, SAFI=134, Flow-spec
AFI=3, SAFI=128, CLNS VPN
AFI=1, SAFI=5, NG-MVPN IPv4
AFI=2, SAFI=5, NG-MVPN IPv6
AFI=1, SAFI=66, MDT-SAFI
AFI=1, SAFI=4, gekennzeichnet mit IPv4
AFI=2, SAFI=4, gekennzeichnet mit IPv6 (6PE)
In der Routingtabelle inet.2 installierte Routen können nur in MP-BGP-Peers exportiert werden, da sie SAFI verwenden, um sie als Routen zu Multicast-Quellen zu identifizieren. In der Routingtabelle inet.0 installierte Routen können nur in Standard-BGP-Peers exportiert werden.
Die Routingtabelle inet.2 sollte eine Teilmenge der Routen sein, die Sie inet.0 haben, da es unwahrscheinlich ist, dass Sie eine Route zu einer Multicast-Quelle haben, an die Sie keinen Unicast-Datenverkehr senden konnten. Die Routingtabelle inet.2 speichert die Unicast-Routen, die für Multicast-Reverse-Path-Forwarding-Prüfungen verwendet werden, und die zusätzlichen Erreichbarkeitsinformationen, die von MP-BGP aus den NLRI-Multicast-Updates gelernt werden. Eine inet.2-Routing-Tabelle wird automatisch erstellt, wenn Sie MP-BGP konfigurieren (indem Sie NLRI auf any).
Wenn Sie MP-BGP aktivieren, können Sie folgendes tun:
- Begrenzung der Anzahl der Präfixe, die in einer BGP-Peer-Sitzung empfangen werden
- Begrenzung der Anzahl der in einer BGP-Peer-Sitzung akzeptierten Präfixe
- Konfigurieren von BGP-Routing-Tabellengruppen
- Auflösung von Routen zu PE-Routing-Geräten in anderen ASs
- Zulassen von gekennzeichneten und nicht gekennzeichneten Routen
Begrenzung der Anzahl der Präfixe, die in einer BGP-Peer-Sitzung empfangen werden
Sie können die Anzahl der in einer BGP-Peersitzung empfangenen Präfixe begrenzen und Meldungen mit begrenzter Geschwindigkeit protokollieren, wenn die Anzahl der injizierten Präfixe eine festgelegte Obergrenze überschreitet. Sie können auch das Peering herunterreißen, wenn die Anzahl der Präfixe die Obergrenze überschreitet.
Um eine Begrenzung auf die Anzahl der Präfixe zu konfigurieren, die in einer BGP-Sitzung empfangen werden können, fügen Sie die Anweisung ein prefix-limit :
prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop-excess <percentage>; hide-excess <percentage>; }
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.
Für maximum numbergeben Sie einen Wert im Bereich von 1 bis 4.294.967.295 an. Wenn die angegebene maximale Anzahl von Präfixen überschritten wird, wird eine Systemprotokollnachricht gesendet.
Wenn Sie die teardown Anweisung einschließen, wird die Sitzung abgerissen, wenn die maximale Anzahl von Präfixen überschritten wird. Wenn Sie einen Prozentsatz angeben, werden Nachrichten protokolliert, wenn die Anzahl der Präfixe diesen Prozentsatz des angegebenen Maximalen Limits überschreitet. Nachdem die Sitzung abgerissen wurde, wird sie in kurzer Zeit wieder eingerichtet (es sei denn, Sie fügen die Anweisung bei idle-timeout ). Wenn Sie die idle-timeout Anweisung einschließen, kann die Sitzung für eine bestimmte Zeit oder für immer geschlossen werden. Wenn Sie angeben forever, wird die Sitzung erst wieder aufgebaut, nachdem Sie einen clear bgp neighbor Befehl ausstellen. Wenn Sie die drop-excess <percentage> Option einschließen, werden die überschüssigen Routen gelöscht, wenn die maximale Anzahl von Präfixen erreicht ist. Wenn Sie einen Prozentsatz angeben, werden die Routen protokolliert, wenn die Anzahl der Präfixe diesen Prozentwert der maximalen Anzahl übersteigt. Wenn Sie die hide-excess <percentage> Option einschließen, werden die überschüssigen Routen ausgeblendet, wenn die maximale Anzahl von Präfixen erreicht ist. Wenn Sie einen Prozentsatz angeben, werden die Routen protokolliert, wenn die Anzahl der Präfixe diesen Prozentwert der maximalen Anzahl übersteigt. Wenn der Prozentsatz geändert wird, werden die Routen automatisch neu bewertet. Wenn die aktiven Routen unter den angegebenen Prozentsatz fallen, werden diese Routen als ausgeblendet beibehalten.
In Junos OS Version 9.2 und höher können Sie alternativ eine Begrenzung auf die Anzahl der Präfixe konfigurieren, die in einer BGP-Peer-Sitzung akzeptiert werden können. Weitere Informationen finden Sie unter Begrenzung der Anzahl der in einer BGP-Peer-Sitzung akzeptierten Präfixe.
Begrenzung der Anzahl der in einer BGP-Peer-Sitzung akzeptierten Präfixe
In Junos OS Version 9.2 und höher können Sie die Anzahl der Präfixe begrenzen, die in einer BGP-Peer-Sitzung akzeptiert werden können. Wenn die angegebene Grenze überschritten wird, wird eine Systemprotokollnachricht gesendet. Sie können auch angeben, dass die BGP-Sitzung zurückgesetzt wird, wenn die Begrenzung auf die Anzahl der angegebenen Präfixe überschritten wird.
Um eine Begrenzung auf die Anzahl der Präfixe zu konfigurieren, die in einer BGP-Peersitzung akzeptiert werden können, fügen Sie die Anweisung ein accepted-prefix-limit :
accepted-prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop <percentage>; hide <percentage>; }
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.
Für maximum numbergeben Sie einen Wert im Bereich von 1 bis 4.294.967.295 an.
Fügen Sie die teardown Anweisung ein, um die BGP-Peersitzung zurückzusetzen, wenn die Anzahl der akzeptierten Präfixe die konfigurierte Grenze überschreitet. Sie können auch einen Prozentwert von 1 bis 100 angeben, um eine Systemprotokollnachricht zu senden, wenn die Anzahl der akzeptierten Präfixe diesen Prozentsatz des maximalen Limits überschreitet. Standardmäßig wird eine zurückgesetzte BGP-Sitzung innerhalb kurzer Zeit wieder eingerichtet. Fügen Sie die idle-timeout Anweisung ein, um zu verhindern, dass die BGP-Sitzung für einen bestimmten Zeitraum erneut eingerichtet wird. Sie können einen Timeout-Wert von 1 bis 2400 Minuten konfigurieren. Fügen Sie die forever Option ein, um zu verhindern, dass die BGP-Sitzung erneut aufgebaut wird, bis Sie den clear bgp neighbor Befehl ausstellen. Wenn Sie die drop-excess <percentage> Anweisung einschließen und einen Prozentsatz angeben, werden die überschüssigen Routen gelöscht, wenn die Anzahl der Präfixe den Prozentsatz übersteigt. Wenn Sie die hide-excess <percentage> Anweisung einschließen und einen Prozentsatz angeben, werden die überschüssigen Routen ausgeblendet, wenn die Anzahl der Präfixe den Prozentsatz übersteigt. Wenn der Prozentsatz geändert wird, werden die Routen automatisch neu bewertet.
Wenn nonstop Active Routing (NSR) aktiviert ist und ein Switchover zu einer Backup-Routing-Engine erfolgt, werden unterbrochene BGP-Peers automatisch neu gestartet. Die Peers werden auch dann neu gestartet, wenn die idle-timeout forever Anweisung konfiguriert ist.
Alternativ können Sie eine Begrenzung auf die Anzahl der Präfixe konfigurieren, die in einer BGP-Peersitzung empfangen werden können (im Gegensatz zu akzeptiert). Weitere Informationen finden Sie unter Begrenzung der Anzahl der Präfixe, die in einer BGP-Peer-Sitzung empfangen werden.
Konfigurieren von BGP-Routing-Tabellengruppen
Wenn eine BGP-Sitzung ein Unicast- oder Multicast-NLRI empfängt, installiert sie die Route in der entsprechenden Tabelle (inet.0 oder inet6.0 für Unicast und inet.2 oder inet6.2 für Multicast). Um Unicast-Präfixe sowohl den Unicast- als auch den Multicast-Tabellen hinzuzufügen, können Sie BGP-Routing-Tabellengruppen konfigurieren. Dies ist nützlich, wenn Sie keine Multicast-NLRI-Aushandlung durchführen können.
Um BGP-Routing-Tabellengruppen zu konfigurieren, fügen Sie die rib-group Anweisung ein:
rib-group group-name;
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.
Auflösung von Routen zu PE-Routing-Geräten in anderen ASs
Sie können zulassen, dass gekennzeichnete Routen zur Routenauflösung in die inet.3 Routing-Tabelle aufgenommen werden. Diese Routen werden dann für Routing-Geräteverbindungen von Provider Edge (PE) aufgelöst, bei denen sich das Remote-PE über ein anderes autonomes System (AS) befindet. Damit ein PE-Routinggerät eine Route in der VPN-Routing- und Weiterleitungsinstanz (VRF) installiert, muss der nächste Hop zu einer in der inet.3 Tabelle gespeicherten Route aufgelöst werden.
Um Routen in die inet.3 Routing-Tabelle aufzulösen, fügen Sie die Anweisung ein resolve-vpn :
resolve-vpn group-name;
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.
Zulassen von gekennzeichneten und nicht gekennzeichneten Routen
Sie können den Austausch von gekennzeichneten und nicht gekennzeichneten Routen in einer einzigen Sitzung zulassen. Die gekennzeichneten Routen werden in die Routingtabelle inet.3 oder inet6.3 aufgenommen, und sowohl gekennzeichnete als auch nicht gekennzeichnete Unicast-Routen können an das Routinggerät gesendet oder von diesem empfangen werden.
Geben Sie die rib Anweisung ein, um den Austausch von gekennzeichneten und nicht gekennzeichneten Routen zu ermöglichen:
rib (inet.3 | inet6.3);
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.
Beispiel: Konfigurieren von IPv6-BGP-Routen über IPv4-Transport
In diesem Beispiel wird veranschaulicht, wie sowohl IPv6- als auch IPv4-Präfixe über eine IPv4-Verbindung exportiert werden, bei der beide Seiten mit einer IPv4-Schnittstelle konfiguriert sind.
Anforderungen
Vor der Konfiguration dieses Beispiels ist keine spezielle Konfiguration erforderlich, die über die Geräteinitialisierung hinausgeht.
Überblick
Beachten Sie beim Exportieren von IPv6-BGP-Präfixen Folgendes:
BGP leitet Next-Hop-Präfixe mit dem IPv4-zugeordneten IPv6-Präfix ab. So übersetzt sich das IPv4-Next-Hop-Präfix
10.19.1.1in das IPv6-Next-Hop-Präfix ::ffff:10.19.1.1.HINWEIS:Es muss eine aktive Route zum IPv4-zugeordneten IPv6-Hop neben Hop vorhanden sein, um IPv6-BGP-Präfixe zu exportieren.
Eine IPv6-Verbindung muss über den Link konfiguriert werden. Die Verbindung muss entweder ein IPv6-Tunnel oder eine Dual-Stack-Konfiguration sein. In diesem Beispiel wird Dual-Stacking verwendet.
Verwenden Sie beim Konfigurieren von IPv4-zugeordneten IPv6-Präfixen eine Maske, die länger als 96 Bits ist.
Konfigurieren Sie eine statische Route, wenn Sie normale IPv6-Präfixe verwenden möchten. In diesem Beispiel werden statische Routen verwendet.
Abbildung 1 zeigt die Beispieltopologie.
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 1 family inet address 192.168.10.1/24 set interfaces fe-1/2/0 unit 1 family inet6 address ::ffff:192.168.10.1/120 set interfaces lo0 unit 1 family inet address 10.10.10.1/32 set protocols bgp group ext type external set protocols bgp group ext family inet unicast set protocols bgp group ext family inet6 unicast set protocols bgp group ext export send-direct set protocols bgp group ext export send-static set protocols bgp group ext peer-as 200 set protocols bgp group ext neighbor 192.168.10.10 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 term 1 from protocol static set policy-options policy-statement send-static term 1 then accept set routing-options rib inet6.0 static route ::ffff:192.168.20.0/120 next-hop ::ffff:192.168.10.10 set routing-options static route 192.168.20.0/24 next-hop 192.168.10.10 set routing-options autonomous-system 100
Gerät R2
set interfaces fe-1/2/0 unit 2 family inet address 192.168.10.10/24 set interfaces fe-1/2/0 unit 2 family inet6 address ::ffff:192.168.10.10/120 set interfaces fe-1/2/1 unit 3 family inet address 192.168.20.21/24 set interfaces fe-1/2/1 unit 3 family inet6 address ::ffff:192.168.20.21/120 set interfaces lo0 unit 2 family inet address 10.10.0.1/32 set protocols bgp group ext type external set protocols bgp group ext family inet unicast set protocols bgp group ext family inet6 unicast set protocols bgp group ext export send-direct set protocols bgp group ext export send-static set protocols bgp group ext neighbor 192.168.10.1 peer-as 100 set protocols bgp group ext neighbor 192.168.20.1 peer-as 300 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 term 1 from protocol static set policy-options policy-statement send-static term 1 then accept set routing-options autonomous-system 200
Gerät R3
set interfaces fe-1/2/0 unit 4 family inet address 192.168.20.1/24 set interfaces fe-1/2/0 unit 4 family inet6 address ::ffff:192.168.20.1/120 set interfaces lo0 unit 3 family inet address 10.10.20.1/32 set protocols bgp group ext type external set protocols bgp group ext family inet unicast set protocols bgp group ext family inet6 unicast set protocols bgp group ext export send-direct set protocols bgp group ext export send-static set protocols bgp group ext peer-as 200 set protocols bgp group ext neighbor 192.168.20.21 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 term 1 from protocol static set policy-options policy-statement send-static term 1 then accept set routing-options rib inet6.0 static route ::ffff:192.168.10.0/120 next-hop ::ffff:192.168.20.21 set routing-options static route 192.168.10.0/24 next-hop 192.168.20.21 set routing-options autonomous-system 300
Konfigurieren von Gerät R1
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 R1:
Konfigurieren Sie die Schnittstellen, einschließlich einer IPv4-Adresse und einer IPv6-Adresse.
[edit interfaces] user@R1# set fe-1/2/0 unit 1 family inet address 192.168.10.1/24 user@R1# set fe-1/2/0 unit 1 family inet6 address ::ffff:192.168.10.1/120 user@R1# set lo0 unit 1 family inet address 10.10.10.1/32
Konfigurieren Sie EBGP.
[edit protocols bgp group ext] user@R1# set type external user@R1# set export send-direct user@R1# set export send-static user@R1# set peer-as 200 user@R1# set neighbor 192.168.10.10
-
Aktivieren Sie BGP zur Übertragung von IPv4-Unicast- und IPv6-Unicast-Routen.
[edit protocols bgp group ext] user@R1# set family inet unicast user@R1# set family inet6 unicast
IPv4-Unicast-Routen sind standardmäßig aktiviert. Wenn Sie jedoch andere NLRI-Adressfamilien konfigurieren, muss IPv4-Unicast explizit konfiguriert werden.
-
Konfigurieren Sie die Routing-Richtlinie.
[edit 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 term 1 from protocol static user@R1# set policy-statement send-static term 1 then accept
Konfigurieren Sie einige statische Routen.
[edit routing-options] user@R1# set rib inet6.0 static route ::ffff:192.168.20.0/120 next-hop ::ffff:192.168.10.10 user@R1# set static route 192.168.20.0/24 next-hop 192.168.10.10
Konfigurieren Sie die Nummer des autonomen Systems (AS).
[edit routing-options] user@R1# set autonomous-system 100
Ergebnisse
Bestätigen Sie Ihre Konfiguration im Konfigurationsmodus, indem Sie die show interfacesBefehle , show policy-options, show protocolsund 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@R1# show interfaces
fe-1/2/0 {
unit 1 {
family inet {
address 192.168.10.1/24;
}
family inet6 {
address ::ffff:192.168.10.1/120;
}
}
}
lo0 {
unit 1 {
family inet {
address 10.10.10.1/32;
}
}
}
user@R1# show policy-options
policy-statement send-direct {
term 1 {
from protocol direct;
then accept;
}
}
policy-statement send-static {
term 1 {
from protocol static;
then accept;
}
}
user@R1# show protocols
bgp {
group ext {
type external;
family inet {
unicast;
}
family inet6 {
unicast;
}
export [ send-direct send-static ];
peer-as 200;
neighbor 192.168.10.10;
}
}
user@R1# show routing-options
rib inet6.0 {
static {
route ::ffff:192.168.20.0/120 next-hop ::ffff:192.168.10.10;
}
}
static {
route 192.168.20.0/24 next-hop 192.168.10.10;
}
autonomous-system 100;
Wenn Sie mit der Konfiguration des Geräts fertig sind, geben Sie im Konfigurationsmodus ein commit . Wiederholen Sie die Konfiguration auf Gerät R2 und Gerät R3 und ändern Sie die Schnittstellennamen und IP-Adressen nach Bedarf.
Überprüfung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
Überprüfen des Neighbor-Status
Zweck
Stellen Sie sicher, dass BGP aktiviert ist, um IPv6-Unicast-Routen zu übertragen.
Aktion
Geben Sie im Betriebsmodus den show bgp neighbor Befehl ein.
user@R2> show bgp neighbor
Peer: 192.168.10.1+179 AS 100 Local: 192.168.10.10+54226 AS 200
Type: External State: Established Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ send-direct send-static ]
Options: <Preference AddressFamily PeerAS Refresh>
Address families configured: inet-unicast inet6-unicast
Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 10.10.10.1 Local ID: 10.10.0.1 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 0
BFD: disabled, down
Local Interface: fe-1/2/0.2
NLRI for restart configured on peer: inet-unicast inet6-unicast
NLRI advertised by peer: inet-unicast inet6-unicast
NLRI for this session: inet-unicast inet6-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 inet6-unicast
NLRI of received end-of-rib markers: inet-unicast inet6-unicast
NLRI of all end-of-rib markers sent: inet-unicast inet6-unicast
Peer supports 4 byte AS extension (peer-as 100)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 1
Received prefixes: 3
Accepted prefixes: 2
Suppressed due to damping: 0
Advertised prefixes: 4
Table inet6.0 Bit: 20000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 1
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 2
Last traffic (seconds): Received 24 Sent 12 Checked 60
Input messages: Total 132 Updates 6 Refreshes 0 Octets 2700
Output messages: Total 133 Updates 3 Refreshes 0 Octets 2772
Output Queue[0]: 0
Output Queue[1]: 0
Peer: 192.168.20.1+179 AS 300 Local: 192.168.20.21+54706 AS 200
Type: External State: Established Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ send-direct send-static ]
Options: <Preference AddressFamily PeerAS Refresh>
Address families configured: inet-unicast inet6-unicast
Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 10.10.20.1 Local ID: 10.10.0.1 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 1
BFD: disabled, down
Local Interface: fe-1/2/1.3
NLRI for restart configured on peer: inet-unicast inet6-unicast
NLRI advertised by peer: inet-unicast inet6-unicast
NLRI for this session: inet-unicast inet6-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 inet6-unicast
NLRI of received end-of-rib markers: inet-unicast inet6-unicast
NLRI of all end-of-rib markers sent: inet-unicast inet6-unicast
Peer supports 4 byte AS extension (peer-as 300)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 1
Received prefixes: 3
Accepted prefixes: 2
Suppressed due to damping: 0
Advertised prefixes: 4
Table inet6.0 Bit: 20000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 1
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 2
Last traffic (seconds): Received 1 Sent 15 Checked 75
Input messages: Total 133 Updates 6 Refreshes 0 Octets 2719
Output messages: Total 131 Updates 3 Refreshes 0 Octets 2734
Output Queue[0]: 0
Output Queue[1]: 0Bedeutung
Die verschiedenen Vorkommen in inet6-unicast der Ausgabe zeigen, dass BGP aktiviert ist, IPv6-Unicast-Routen zu übertragen.
Überprüfen der Routing-Tabelle
Zweck
Stellen Sie sicher, dass Gerät R2 BGP-Routen in der Routingtabelle inet6.0 enthält.
Aktion
Geben Sie im Betriebsmodus den show route protocol bgp inet6.0 Befehl ein.
user@R2> show route protocol bgp table inet6.0
inet6.0: 7 destinations, 10 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
::ffff:192.168.10.0/120 [BGP/170] 01:03:49, localpref 100, from 192.168.20.1
AS path: 300 I
> to ::ffff:192.168.20.21 via fe-1/2/1.3
::ffff:192.168.20.0/120 [BGP/170] 01:03:53, localpref 100, from 192.168.10.1
AS path: 100 I
> to ::ffff:192.168.10.10 via fe-1/2/0.2Anzeigen von IPv4-Routen über BGP IPv6-Sitzungen – Übersicht
In einem IPv6-Netzwerk kündigt BGP in der Regel Informationen zur Erreichbarkeit der IPv6-Netzwerkebene über eine IPv6-Sitzung zwischen BGP-Peers an. In früheren Versionen unterstützt Junos OS nur den Austausch von inet6-Unicast-, inet6-Multicast- oder inet6-Unicast-Adressfamilien mit Labeled-Unicast. Diese Funktion ermöglicht den Austausch aller BGP-Adressfamilien. In einer Dual-Stack-Umgebung mit IPv6 im Core. Mit dieser Funktion kann BGP die IPv4-Unicast-Erreichbarkeit mit IPv4 next Hop über eine IPv6-BGP-Sitzung ankündigen.
Diese Funktion ist nur für BGP-IPv6-Sitzungen, bei denen IPv4 an beiden Endgeräten konfiguriert wird. Dies local-ipv4-address kann eine Loopback-Adresse oder eine beliebige IPv4-Adresse für eine IBGP- oder Multi-Hop-EBGP-Sitzung sein. Für externe Single-Hop-BGP-Lautsprecher, die nicht Teil von BGP-Konföderationen sind, wird die BGP-Sitzung geschlossen, wenn die konfigurierte lokale IPv4-Adresse nicht direkt verbunden ist, die BGP-Sitzung wird geschlossen, bleibt untätig und es wird ein Fehler generiert, der in der Ausgabe des show bgp neighbor Befehls angezeigt wird.
Um IPv4-Routenwerbung über IPv6-Sitzung zu aktivieren, konfigurieren Sie local-ipv4-address wie folgt:
[edit protocols bgp family inet unicast] local-ipv4-address local ipv4 address;
Sie können diese Funktion nicht für die Adressfamilien inet6 unicast, inet6 Multicast oder inet6 mit Labeled-Unicast konfigurieren, da BGP bereits in der Lage ist, diese Adressfamilien über eine IPv6-BGP-Sitzung anzukündigen.
Die konfigurierte local-ipv4-address Lösung wird nur verwendet, wenn BGP Routen mit Self-Next-Hop ankünbt. Wenn IBGP Routen ankündigt, die von EBGP-Peers gelernt wurden, oder der Routenreflektor BGP-Routen an seine Clients ankündigt, ändert BGP den Route next Hop nicht, ignoriert die konfigurierte local-ipv4-addressund verwendet den ursprünglichen IPv4 next Hop.
Siehe auch
Beispiel: Werbung für IPv4-Routen über IPv6-BGP-Sitzungen
Dieses Beispiel zeigt, wie Sie IPv4-Routen über eine IPv6-BGP-Sitzung ankündigen. In einer Dual-Stack-Umgebung mit IPv6 im Core müssen Remote-IPv4-Hosts erreicht werden. Daher kündigt BGP IPv4-Routen mit IPv4 Next Hops an BGP-Peers über BGP-Sitzungen unter Verwendung von IPv6-Quell- und Zieladressen an. Mit dieser Funktion kann BGP die IPv4-Unicast-Erreichbarkeit mit IPv4 next Hop über IPv6 BGP-Sitzungen ankündigen.
Anforderungen
In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:
Drei Router mit Dual-Stacking-Funktion
Junos OS Version 16.1 oder höher, die auf allen Geräten ausgeführt wird
Bevor Sie IPv4-Ankündigungen über IPv6 BGP-Sitzungen aktivieren, sollten Sie folgendes beachten:
Konfigurieren Sie die Geräteschnittstellen.
Konfigurieren Sie Dual-Stacking auf allen Geräten.
Überblick
Ab Version 16.1 ermöglicht Junos OS BGP, die IPv4-Unicast-Erreichbarkeit mit IPv4 Next Hop über eine IPv6-BGP-Sitzung anzukündigen. In früheren Junos OS-Versionen konnte BGP nur Inet6-Unicast-, inet6-Multicast- und inet6-gekennzeichnete Unicast-Adressfamilien über IPv6-BGP-Sitzungen ankündigen. Mit dieser Funktion kann BGP alle BGP-Adressfamilien über eine IPv6-Sitzung austauschen. Sie können BGP aktivieren, um IPv4-Routen mit IPv4 Next Hops an BGP-Peers über eine IPv6-Sitzung anzukündigen. Die konfigurierte local-ipv4-address Lösung wird nur verwendet, wenn BGP Routen mit Self-Next-Hop ankünbt.
Sie können diese Funktion nicht für die Adressfamilien inet6 unicast, inet6 Multicast oder inet6 mit Labeled-Unicast konfigurieren, da BGP bereits in der Lage ist, diese Adressfamilien über eine IPv6-BGP-Sitzung anzukündigen.
Topologie
In Abbildung 2wird eine externe IPv6-BGP-Sitzung zwischen den Routern R1 und R2 ausgeführt. Zwischen Router R2 und Router R3 wird eine IPv6-IBGP-Sitzung eingerichtet. Statische IPv4-Routen werden an die BGP auf R1 verteilt. Um die IPv4-Routen über die IPv6-BGP-Sitzung zu verteilen, muss die neue Funktion auf allen Routern auf [edit protocols bgp address family] Hierarchieebene aktiviert sein.
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, kopieren Sie die Befehle, fügen Sie sie auf Hierarchieebene in die [edit] CLI ein, und geben Sie dann aus dem Konfigurationsmodus ein commit .
Router R1
set interfaces ge-0/0/0 unit 0 description R1->R2 set interfaces ge-0/0/0 unit 0 family inet address 140.1.1.1/24 set interfaces ge-0/0/0 unit 0 family inet6 address ::140.1.1.1/126 set interfaces lo0 unit 0 family inet6 address 1::1/128 set routing-options static route 11.1.1.1/32 discard set routing-options static route 11.1.1.2/32 discard set routing-options autonomous-system 64497 set protocols bgp group ebgp-v6 type external set protocols bgp group ebgp-v6 export p1 set protocols bgp group ebgp-v6 peer-as 64496 set protocols bgp group ebgp-v6 neighbor ::140.1.1.2 description R2 set protocols bgp group ebgp-v6 neighbor ::140.1.1.2 family inet unicast local-ipv4-address 140.1.1.1 set policy-options policy-statement p1 from protocol static set policy-options policy-statement p1 then accept
Router R2
set interfaces ge-0/0/0 unit 0 description R2->R1 set interfaces ge-0/0/0 unit 0 family inet address 140.1.1.2/24 set interfaces ge-0/0/0 unit 0 family inet6 address ::140.1.1.2/126 set interfaces ge-0/0/1 unit 0 description R2->R3 set interfaces ge-0/0/1 unit 0 family inet address 150.1.1.1/24 set interfaces ge-0/0/1 unit 0 family inet6 address ::150.1.1.1/126 set interfaces lo0 unit 0 family inet6 address 1::2/128 set routing-options autonomous-system 64496 set protocols bgp group ibgp-v6 type internal set protocols bgp group ibgp-v6 export change-nh set protocols bgp group ibgp-v6 neighbor ::150.1.1.2 description R3 set protocols bgp group ibgp-v6 neighbor ::150.1.1.2 family inet unicast local-ipv4-address 150.1.1.1 set protocols bgp group ebgp-v6 type external set protocols bgp group ebgp-v6 peer-as 64497 set protocols bgp group ebgp-v6 neighbor ::140.1.1.1 description R1 set protocols bgp group ebgp-v6 neighbor ::140.1.1.1 family inet unicast local-ipv4-address 140.1.1.2 set policy-options policy-statement change-nh from protocol bgp set policy-options policy-statement change-nh then next-hop self set policy-options policy-statement change-nh then accept
Router R3
set interfaces ge-0/0/0 unit 0 description R3->R2 set interfaces ge-0/0/0 unit 0 family inet address 150.1.1.2/24 set interfaces ge-0/0/0 unit 0 family inet6 address ::150.1.1.2/126 set interfaces lo0 unit 0 family inet6 address 1::3/128 set routing-options autonomous-system 64496 set protocols bgp group ibgp-v6 type internal set protocols bgp group ibgp-v6 neighbor ::150.1.1.1 description R2 set protocols bgp group ibgp-v6 neighbor ::150.1.1.1 family inet unicast local-ipv4-address 150.1.1.2
Router R1 konfigurieren
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 Router R1:
Wiederholen Sie diese Prozedur für andere Router, nachdem Sie die entsprechenden Schnittstellennamen, Adressen und andere Parameter geändert haben.
Konfigurieren Sie die Schnittstellen mit IPv4- und IPv6-Adressen.
[edit interfaces] user@R1# set ge-0/0/0 unit 0 description R1->R2 user@R1# set ge-0/0/0 unit 0 family inet address 140.1.1.1/24 user@R1# set ge-0/0/0 unit 0 family inet6 address ::140.1.1.1/126
Konfigurieren Sie die Loopback-Adresse.
[edit interfaces] user@R1# set lo0 unit 0 family inet6 address 1::1/128
Konfigurieren Sie eine statische IPv4-Route, die angekündigt werden muss.
[edit routing-options] user@R1# set static route 11.1.1.1/32 discard user@R1# set static route 11.1.1.2/32 discard
Konfigurieren Sie das autonome System für BGP-Hosts.
[edit routing-options] user@R1# set autonomous-system 64497
Konfigurieren Sie EBGP auf den externen Edge-Routern.
[edit protocols] user@R1# set bgp group ebgp-v6 type external user@R1# set bgp group ebgp-v6 peer-as 64496 user@R1# set bgp group ebgp-v6 neighbor ::140.1.1.2 description R2
Aktivieren Sie die Funktion, um IPv4-Adddress 140.1.1.1 über BGP-IPv6-Sitzungen anzukündigen.
[edit protocols] user@R1# set bgp group ebgp-v6 neighbor ::140.1.1.2 family inet unicast local-ipv4-address 140.1.1.1
Definieren Sie eine Richtlinie p1, die alle statischen Routen akzeptiert.
[edit policy-options] user@R1# set policy-statement p1 from protocol static user@R1# set policy-statement p1 then accept
Wenden Sie die Richtlinie p1 auf die EBGP-Gruppe ebgp-v6 an.
[edit protocols] user@R1# set bgp group ebgp-v6 export p1
Ergebnisse
Bestätigen Sie Ihre Konfiguration im Konfigurationsmodus, indem Sie die show interfacesBefehle , show protocols, show routing-optionsund show policy-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.
[edit]
user@R1# show interfaces
ge-0/0/0 {
unit 0 {
description R1->R2;
family inet {
address 140.1.1.1/24;
}
family inet6 {
address ::140.1.1.1/126;
}
}
lo0 {
unit 0 {
family inet {
address 1::1/128;
}
}
}
}
[edit]
user@R1# show protocols
bgp {
group ebgp-v6 {
type external;
export p1;
peer-as 64496;
neighbor ::140.1.1.2 {
description R2;
family inet {
unicast {
local-ipv4-address 140.1.1.1;
}
}
}
}
}
[edit]
user@R1# show routing-options
static {
route 11.1.1.1/32 discard;
route 11.1.1.2/32 discard;
}
autonomous-system 64497;
[edit]
user@R1# show policy-options
policy-statement p1 {
from {
protocol static;
}
then accept;
}
Wenn Sie mit der Konfiguration des Geräts fertig sind, bestätigen Sie die Konfiguration.
user@R1# commit
Überprüfung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
- Überprüfen, ob die BGP-Sitzung aktiv ist
- Stellen Sie sicher, dass die IPv4-Adresse angekündigt wird
- Überprüfen, ob der BGP Neighbor Router R2 die angekündigte IPv4-Adresse empfängt
Überprüfen, ob die BGP-Sitzung aktiv ist
Zweck
Stellen Sie sicher, dass BGP auf den konfigurierten Schnittstellen ausgeführt wird und dass die BGP-Sitzung für jede Nachbaradresse aktiv ist.
Aktion
Führen Sie den show bgp summary Befehl im Betriebsmodus auf Router R1 aus.
user@R1> show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
0 0 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
::140.1.1.2 64496 4140 4158 0 0 1d 7:10:36 0/0/0/0 0/0/0/0
Bedeutung
Die BGP-Sitzung ist einsatzbereit, und BGP-Peering ist eingerichtet.
Stellen Sie sicher, dass die IPv4-Adresse angekündigt wird
Zweck
Stellen Sie sicher, dass die konfigurierte IPv4-Adresse von Router R1 den konfigurierten BGP-Nachbarn angekündigt wird.
Aktion
Führen Sie den show route advertising-protocol bgp ::150.1.1.2 Befehl im Betriebsmodus auf Router R1 aus.
user@R1> show route advertising-protocol bgp ::150.1.1.2 inet.0: 48 destinations, 48 routes (48 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 11.1.1.1/32 Self 64497 64497 I * 11.1.1.2/32 Self 64497 64497 I
Bedeutung
Die statische IPv4-Route wird dem BGP-Neighbor-Router R2 angekündigt.
Überprüfen, ob der BGP Neighbor Router R2 die angekündigte IPv4-Adresse empfängt
Zweck
Stellen Sie sicher, dass Router R2 die IPv4-Adresse empfängt, die Router R1 dem BGP-Nachbarn über IPv6 ankünbt.
Aktion
user@R2> show route receive-protocol bgp ::140.1.1.1 inet.0: 48 destinations, 48 routes (48 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 11.1.1.1/32 140.1.1.1 64497 I * 11.1.1.2/32 140.1.1.1 64497 I iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) inet6.0: 9 destinations, 10 routes (9 active, 0 holddown, 0 hidden)
Bedeutung
Das Vorhandensein der statischen IPv4-Route in der Routing-Tabelle von Router R2 zeigt an, dass sie die angekündigten IPv4-Routen von Router R1 empfängt.
Verständnis der Neuverteilung von IPv4-Routen mit IPv6 Next Hop in BGP
In einem Netzwerk, das hauptsächlich IPv6-Datenverkehr transportiert, müssen IPv4-Routen bei Bedarf geroutet werden. Zum Beispiel ein Internet Service Provider, der über ein nur IPv6-Netzwerk verfügt, aber Kunden hat, die weiterhin IPv4-Datenverkehr routen. In diesem Fall ist es notwendig, auf solche Kunden einzugehen und IPv4-Datenverkehr über ein IPv6-Netzwerk weiterzuleiten. Wie in RFC 5549 beschrieben, Werbeinformationen zur IPv4-Netzwerkschicht-Erreichbarkeit mit einem IPv6 Next Hop IPv4-Datenverkehr wird von CPE-Geräten (Customer Premises Equipment) zu IPv4-over-IPv6-Gateways getunnelt. Diese Gateways werden CPE-Geräten über Anycast-Adressen angekündigt. Die Gateway-Geräte erstellen dann dynamische IPv4-over-IPv6-Tunnel zu Remote-CPE-Geräten und veröffentlichen IPv4-aggregierte Routen zur Steuerung des Datenverkehrs.
Die dynamische IPv4-over-IPv6-Tunnelfunktion unterstützt unified ISSU in Junos OS Version 17.3R1 nicht.
Route Reflectors (RRs) mit einer programmierbaren Schnittstelle sind über IBGP mit den Gateway-Routern und Host-Routen mit IPv6-Adresse als nächstem Hop verbunden. Diese RRs geben die IPv4/32-Adressen an, um die Tunnelinformationen in das Netzwerk einzuschleusen. Die Gateway-Router erstellen dynamische IPv4-over-IPv6-Tunnel zum Remote-Kunden-Provider-Edge. Der Gateway-Router kündigt auch die IPv4-aggregierten Routen an, um den Datenverkehr zu steuern. Die RR kündigt dann die Tunnel-Quellrouten an den ISP an. Wenn die RR die Tunnelroute entfernt, zieht BGP auch die Route zurück, wodurch der Tunnel abgerissen und der CPE nicht erreichbar ist. Der Gateway-Router zieht auch die IPv4-aggregierten Routen und IPv6-Tunnel-Quellrouten aus, wenn alle aggregierten Routen mitwirkende Routen entfernt werden. Der Gateway-Router sendet route withdraw, wenn die Packet Forwarding Engine Linecard ausfällt, sodass der Datenverkehr an andere Gateway-Router umgeleitet wird.
Die folgenden Erweiterungen werden eingeführt, um IPv4-Routen mit einem IPv6 next Hop zu unterstützen:
- BGP Next Hop Encoding
- Tunnellokalisierung
- Tunnelhandhabung
- Tunnel Load Balancing und Anchor Packet Forwarding Engine Failure Handling
- Tunnel Loopback-Stream-Statistik
BGP Next Hop Encoding
BGP wird um die Next Hop-Codierungsfunktion erweitert, die zum Senden von IPv4-Routen mit IPv6 Next Hops verwendet wird. Wenn diese Funktion auf dem Remote-Peer nicht verfügbar ist, gruppiert BGP die Peers basierend auf dieser Codierungsfunktion und entfernt die BGP-Familie ohne Codierungsfunktion aus der ausgehandelten Liste der Netzwerkschicht Erreichbarkeitsinformationen (NLRI). Junos OS erlaubt nur eine Lösungstabelle wie inet.0. Um IPv4-BGP-Routen mit IPv6 Next Hops zuzulassen, erstellt BGP einen neuen Lösungsbaum. Diese Funktion ermöglicht es einer Junos OS-Routing-Tabelle, mehrere Auflösungsbäume zu haben.
Neben RFC 5549, Werbung für IPv4-Netzwerkschicht-Erreichbarkeitsinformationen mit einem IPv6 Next Hop wird eine neue Kapselungs-Community eingeführt, die in RFC 5512, The BGP Encapsulation Subsequent Address Family Identifier (SAFI) und dem BGP Tunnel Encapsulation Attribute angegeben ist, um die Adressfamilie der Next-Hop-Adresse zu bestimmen. Die Kapselungs-Community gibt an, welche Tunnel der Eingangsknoten erstellen muss. Wenn BGP IPv4-Routen mit der IPv6-Next-Hop-Adresse und der V4oV6-Kapselungs-Community empfängt, erstellt BGP dynamische IPv4-über-IPv6-dynamische Tunnel. Wenn BGP Routen ohne Kapselungs-Community empfängt, werden BGP-Routen ohne erstellung des V4oV6-Tunnels aufgelöst.
Eine neue Richtlinienaktion dynamic-tunnel-attributes dyan-attribute ist auf Hierarchieebene [edit policy-statement policy name term then] verfügbar, um die neue erweiterte Kapselung zu unterstützen.
Tunnellokalisierung
Die dynamische Tunnelinfrastruktur wird durch Tunnellokalisierung erweitert, um eine größere Anzahl von Tunneln zu unterstützen. Es ist eine Tunnellokalisierung erforderlich, um Ausfallsicherheit zu gewährleisten, um den Datenverkehr zu bewältigen, wenn der Anker ausfällt. Ein oder mehrere Gehäuse werden wieder miteinander aufgebaut und der Routing-Protokollprozess (rpd) lenkt den Datenverkehr vom Fehlerpunkt weg zum Backup-Chassis. Das Gehäuse kündigt nur diese aggregierten Präfixe anstelle der einzelnen Loopback-Adressen in das Netzwerk an.
Tunnelhandhabung
IPv4-über IPv6-Tunnel nutzen die dynamische Tunnelinfrastruktur zusammen mit Tunnel-Verankerung, um die erforderliche Gehäuseweite zu unterstützen. Der Tunnelstatus wird auf eine Packet Forwarding Engine lokalisiert, und die anderen Packet Forwarding Engines leiten den Datenverkehr zum Tunnelanker.
Tunnel-Eingang
Verkapselt IPv4-Datenverkehr innerhalb des IPv6-Headers.
Die maximale MTU-Durchsetzung (Transmission Unit) wird vor der Kapselung durchgeführt. Wenn die gekapselte Paketgröße die Tunnel-MTU übersteigt und die IPv4-Pakete
DF-bitnicht festgelegt sind, wird das Paket fragmentiert und diese Fragmente werden gekapselt.Verwendet Hash-basiertes Datenverkehrs-Load Balancing in inneren Paket-Headern.
Leitet den Datenverkehr an die IPv6-Zieladresse weiter. Die IPv6-Adresse wird aus dem IPv6-Header übernommen.
Tunnel-Ausgang
Entkapselt das im IPv6-Paket vorhandene IPv4-Paket.
Führt Anti-Spoof-Überprüfung durch, um sicherzustellen, dass das IPv6- und IPv4-Paar mit den Informationen übereinstimmt, die für die Einrichtung des Tunnels verwendet wurden.
Sucht die IPv4-Zieladresse aus dem IPv4-Header des entkapselten Pakets und leitet das Paket an die angegebene IPv4-Adresse weiter.
Tunnel Load Balancing und Anchor Packet Forwarding Engine Failure Handling
Der Fehler der Packet Forwarding Engine muss umgehend behandelt werden, um eine Filterung von Null-Routen für den in der Packet Forwarding Engine verankerten Tunneldatenverkehr zu vermeiden. Die Tunnellokalisierung beinhaltet die Verwendung von BGP-Ankündigungen, um den Fehler weltweit zu beheben. Der Tunnelverkehr wird vom Fehlerpunkt weg zu einem anderen Backup-Chassis geleitet, das den gleichen Tunnelstatus enthält. Für das Load Balancing des Datenverkehrs ist das Gehäuse so konfiguriert, dass für jeden Prefix-Satz unterschiedliche MED-Werte (Multiple Exit Discriminator) bekannt gegeben werden, sodass nur der Datenverkehr für ein Viertel der Tunnel durch jedes Chassis geht. Der CPE-Datenverkehr wird auch auf ähnliche Weise gehandhabt, indem dieselben Anycast-Adressen in jedem Gehäuse konfiguriert werden und nur ein Viertel des Datenverkehrs auf jedes Gehäuse geleitet wird.
Anchor Packet Forwarding Engine ist die einzige Entität, die die gesamte Verarbeitung eines Tunnels übernimmt. Die Auswahl der Packet Forwarding Engine erfolgt durch statische Bereitstellung und ist an die physischen Schnittstellen der Packet Forwarding Engine gebunden. Wenn eine der Packet Forwarding Engines ausfällt, markiert der Daemon alle Packet Forwarding Engines auf der Linecard und kommuniziert diese Informationen an den Routing-Protokollprozess und andere Daemons. Der Routingprotokollprozess sendet BGP-Auszahlungen für die Präfixe, die auf der ausgefallenen Packet Forwarding Engine verankert sind, und für die IPv6-Adressen, die der heruntergefahrenen Packet Forwarding Engine zugewiesen sind. Diese Ankündigungen umleiten den Datenverkehr auf ein anderes Backup-Chassis. Wenn die ausgefallene Packet Forwarding Engine wieder aktiv ist, markiert das Gehäuse die Packet Forwarding Engine als up und aktualisiert den Routing-Protokollprozess. Der Routing-Protokollprozess löst BGP-Aktualisierungen für seine Peers aus, die an der spezifischen Packet Forwarding Engine verankerte Tunnel jetzt für das Routing des Datenverkehrs verfügbar sind. Dieser Prozess kann minutenlang dauern, um eine groß angelegte Tunnelkonfiguration zu erhalten. Daher ist der Ack Mechanismus in das System integriert, um einen minimalen Datenverkehrsverlust zu gewährleisten und gleichzeitig den Datenverkehr wieder in das ursprüngliche Gehäuse zu wechseln.
Tunnel Loopback-Stream-Statistik
Die dynamische Tunnelinfrastruktur verwendet Loopback-Streams in der Packet Forwarding Engine zum Looping des Pakets nach der Kapselung. Da die Bandbreite dieses Loopback-Streams begrenzt ist, muss die Leistung von Tunnel-Loopback-Streams überwacht werden.
Um die Statistiken des Loopback-Streams zu überwachen, verwenden Sie den Betriebsbefehl show pfe statistics traffic detail , der die aggregierten Loopback-Stream-Statistiken einschließlich Weiterleitungsrate, Drop Packet-Rate und byterate anzeigt.
Siehe auch
Konfigurieren von BGP zur Neuverteilung von IPv4-Routen mit IPv6-Next-Hop-Adressen
Ab Version 17.3R1 können Junos OS-Geräte IPv4-Datenverkehr über ein rein IPv6-Netzwerk weiterleiten, das IPv4-Datenverkehr in der Regel nicht weiterleiten kann. Wie in RFC 5549 beschrieben, wird IPv4-Datenverkehr von CPE-Geräten zu IPv4-over-IPv6-Gateways tunnelt. Diese Gateways werden CPE-Geräten über Anycast-Adressen angekündigt. Die Gateway-Geräte erstellen dann dynamische IPv4-over-IPv6-Tunnel zu Remote-Geräten des Kunden und veröffentlichen IPv4-aggregierte Routen zur Steuerung des Datenverkehrs. Routenreflektoren mit programmierbaren Schnittstellen injizieren die Tunnelinformationen in das Netzwerk. Die Routenreflektoren sind über IBGP mit Gateway-Routern verbunden, die die IPv4-Adressen der Host-Routen mit IPv6-Adressen als nächsten Hop ankündigen.
Die dynamische IPv4-over-IPv6-Tunnelfunktion unterstützt unified ISSU in Junos OS Version 17.3R1 nicht.
Führen Sie folgendes aus, bevor Sie mit der Konfiguration von BGP beginnen, um IPv4-Routen mit IPv6-Next-Hop-Adressen zu verteilen:
Konfigurieren Sie die Geräteschnittstellen.
Konfigurieren Sie OSPF oder ein anderes IGP-Protokoll.
Konfigurieren Sie MPLS und LDP.
Konfigurieren Sie BGP.
So konfigurieren Sie BGP zur Verteilung von IPv4-Routen mit IPv6-Next-Hop-Adressen:
Siehe auch
Aktivierung von Layer 2-VPN- und VPLS-Signalübertragung
Sie können BGP aktivieren, um Layer-2-VPN- und VPLS-NLRI-Nachrichten zu übertragen.
Um VPN- und VPLS-Signalisierung zu aktivieren, fügen Sie die Anweisung ein family :
family { l2vpn { signaling { prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop-excess <percentage>; hide-excess <percentage>; } } } }
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.
Um eine maximale Anzahl von Präfixen zu konfigurieren, fügen Sie die Anweisung ein prefix-limit :
prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop-excess <percentage>; hide-excess <percentage>;}
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 die maximale Anzahl von Präfixen festlegen, wird eine Nachricht protokolliert, wenn diese Zahl erreicht wird. Wenn Sie die teardown Anweisung einschließen, wird die Sitzung abgerissen, wenn die maximale Anzahl von Präfixen erreicht ist. Wenn Sie einen Prozentsatz angeben, werden Nachrichten protokolliert, wenn die Anzahl der Präfixe diesen Prozentsatz erreicht. Sobald die Sitzung abgerissen ist, wird sie in kurzer Zeit wieder eingerichtet. Fügen Sie die Anweisung ein idle-timeout , um die Sitzung für einen bestimmten Zeitraum oder für immer unten zu halten. Wenn Sie angeben forever, wird die Sitzung erst wieder aufgebaut, nachdem Sie den clear bgp neighbor Befehl verwendet haben. Wenn Sie die drop-excess <percentage> Anweisung einschließen und einen Prozentsatz angeben, werden die überschüssigen Routen gelöscht, wenn die Anzahl der Präfixe den Prozentsatz übersteigt. Wenn Sie die hide-excess <percentage> Anweisung einschließen und einen Prozentsatz angeben, werden die überschüssigen Routen ausgeblendet, wenn die Anzahl der Präfixe den Prozentsatz übersteigt. Wenn der Prozentsatz geändert wird, werden die Routen automatisch neu bewertet.
Siehe auch
Grundlegendes zu BGP-Flow-Routen für die Filterung des Datenverkehrs
Eine Datenstromroute ist eine Aggregation von Übereinstimmungsbedingungen für IP-Pakete. Datenstromrouten werden als Eingabeweiterleitungstabellenfilter (implizit) installiert und mithilfe von Flow-Spezifikationsmeldungen zur Netzwerkschicht Erreichbarkeitsinformationen (NLRI) im Netzwerk weitergegeben und in die Flow-Routing-Tabelle instance-name.inetflow.0installiert. Pakete können nur dann durch Datenstromrouten geleitet werden, wenn bestimmte Übereinstimmungsbedingungen erfüllt sind.
Datenstromrouten und Firewall-Filter sind insofern ähnlich, als sie Pakete basierend auf ihren Komponenten filtern und eine Aktion für die pakete ausführen, die übereinstimmen. Flussrouten bieten Datenverkehrsfilterung und Geschwindigkeitsbegrenzungsfunktionen, ähnlich wie Firewall-Filter. Darüber hinaus können Sie Datenstromrouten über verschiedene autonome Systeme hinweg verbreiten.
Flussrouten werden von BGP über FLOW-Spezifikations-NLRI-Nachrichten weitergegeben. Sie müssen BGP aktivieren, um diese NLRIs zu verbreiten.
Ab Junos OS Version 15.1 werden Änderungen implementiert, um die Nonstop Active Routing (NSR)-Unterstützung für bestehende Inet-Flow- und InetVPN-flow-Familien zu erweitern und die Routenvalidierung für BGP-Flowspec pro draft-ietf-idr-bgp-flowspec-oid-01 zu erweitern. Im Rahmen dieser Verbesserung werden zwei neue Aussagen eingeführt. Sehen Sie enforce-first-as und no-install.
Ab Junos OS Version 16.1 wird die IPv6-Unterstützung auf die BGP-Flow-Spezifikation erweitert, die die Verbreitung von Datenverkehrsflussspezifikationsregeln für IPv6- und VPN-IPv6-Pakete ermöglicht. Die BGP-Flow-Spezifikation automatisiert die Koordination von Datenverkehrsfilterregeln, um verteilte Denial-of-Service-Angriffe während des nonstop active Routing (NSR) abzuwehren.
Ab Junos OS Version 16.1R1 unterstützt die BGP-Datenstromspezifikation Filteraktionen zur Datenverkehrsmarkierung extended-community . Für IPv4-Datenverkehr ändert Junos OS die DiffServ-Codepunkt (DSCP)-Bits eines übertragenen IPv4-Pakets zum entsprechenden Wert der erweiterten Community. Für IPv6-Pakete ändert Junos OS die ersten sechs Bits des traffic class Feldes des übertragenden IPv6-Pakets an den entsprechenden Wert der erweiterten Community.
Ab Junos OS Version 17.1R1 BGP kann NlRI-Nachrichten (Network Layer Reachability) auf Routern der PTX-Serie übertragen, auf denen FPCs der dritten Generation (FPC3-PTX-U2 und FPC3-PTX-U3 auf PTX5000 und FPC3-SFF-PTX-U0 und FPC3-SFF-PTX-U1 auf PTX3000) installiert sind. Durch die Weitergabe von Firewall-Filterinformationen als Teil von BGP können Sie Firewall-Filter gegen Denial-of-Service-Angriffe (DOS) dynamisch über autonome Systeme verteilen.
Ab Junos OS Version 17.2R1 kann BGP flow-spezifikationsbasierte NLRI-Meldungen (Network Layer Reachability) auf PTX1000-Routern übertragen, auf denen FPCs der dritten Generation installiert sind. Durch die Weitergabe von Firewall-Filterinformationen als Teil von BGP können Sie Firewall-Filter gegen Denial-of-Service-Angriffe (DOS) dynamisch über autonome Systeme verteilen.
Ab cRPD-Version 20.3R1 werden Flow-Routen und Policing-Regeln, die über die BGP-Flow-Spezifikation NLRI propagiert werden, über das Linux Netfilter Framework auf cRPD-Umgebungen auf den Linux-Kernel heruntergeladen.
- Bedingungen für Flow-Routen abgleichen
- Aktionen für Flow-Routen
- Validierung von Datenstromrouten
- Unterstützung für BGP Flow-Specification Algorithm Version 7 und höher
Bedingungen für Flow-Routen abgleichen
Sie geben Bedingungen an, die das Paket erfüllen muss, bevor die Aktion in der then Anweisung für eine Datenstromroute durchgeführt wird. Alle Bedingungen in der from Erklärung müssen für die zu ergreifenden Maßnahmen übereinstimmen. Die Reihenfolge, in der Sie die Übereinstimmungsbedingungen angeben, ist nicht wichtig, da ein Paket alle Bedingungen in einem Begriff erfüllen muss, damit eine Übereinstimmung auftritt.
Um eine Übereinstimmungsbedingung zu konfigurieren, fügen Sie die match Anweisung auf [edit routing-options flow] Hierarchieebene ein.
Tabelle 1 beschreibt die Bedingungen für die Übereinstimmung der Datenstromroute.
|
Übereinstimmungsbedingung |
Beschreibung |
|---|---|
|
|
IP-Zieladressenfeld. Sie können das |
|
|
TCP- oder UDP-Ziel-Portfeld (User Datagram Protocol). Sie können sowohl die Bedingungen als Anstelle des numerischen Wertes können Sie eines der folgenden Text-Synonyme angeben (die Portnummern sind auch aufgeführt): |
|
|
Differenzierter Services-Codepunkt (DSCP). Das DiffServ-Protokoll verwendet das Typ-of-Service-Byte (ToS) im IP-Header. Die wichtigsten sechs Bits dieses Byte bilden das DSCP. Sie können DSCP in hexadezimaler oder dezimaler Form angeben. |
|
|
Passen Sie den Wert des Datenstrometiketts an. Der Wert dieses Feldes reicht von 0 bis 1048575. Diese Übereinstimmungsbedingung wird nur auf Junos-Geräten mit erweiterten MPCs unterstützt, die für |
|
|
Feld "Fragmenttyp". Die Schlüsselwörter werden nach dem Fragmenttyp gruppiert, dem sie zugeordnet sind:
Diese Übereinstimmungsbedingung wird nur auf Junos OS-Geräten mit erweiterten MPCs unterstützt, die für |
|
|
ICMP-Codefeld. Dieser Wert oder dieses Schlüsselwort bietet spezifischere Informationen als Anstelle des numerischen Wertes können Sie eines der folgenden Text-Synonyme angeben (die Feldwerte werden auch aufgeführt). Die Keywords werden nach dem ICMP-Typ gruppiert, dem sie zugeordnet sind:
|
|
|
ICMP-Pakettypfeld. Normalerweise geben Sie diese Übereinstimmung zusammen mit der Anstelle des numerischen Wertes können Sie eines der folgenden Text-Synonyme angeben (die Feldwerte sind auch aufgeführt): |
|
|
Ip-Paketlänge insgesamt. |
|
|
TCP- oder UDP-Quell- oder Ziel-Port-Feld. Sie können nicht sowohl die Anstelle des numerischen Werts können Sie eines der unter . |
|
|
IP-Protokollfeld. Anstelle des numerischen Wertes können Sie eines der folgenden Text-Synonyme angeben (die Feldwerte sind auch aufgeführt): Diese Übereinstimmungsbedingung wird für IPv6 nur auf Junos-Geräten mit erweiterten MPCs unterstützt, die für |
|
|
IP-Quelladressfeld. Sie können das |
|
|
TCP- oder UDP-Quell-Port-Feld. Sie können die Bedingungen nicht mit demselben Anstelle des numerischen Felds können Sie eines der unter . |
|
|
TCP-Header-Format. |
Aktionen für Flow-Routen
Sie können die Aktion angeben, die ergriffen werden soll, wenn das Paket den Bedingungen entspricht, die Sie in der Datenstromroute konfiguriert haben. Um eine Aktion zu konfigurieren, fügen Sie die then Anweisung auf [edit routing-options flow] Hierarchieebene ein.
Tabelle 2 beschreibt die Flow-Route-Aktionen.
|
Aktions- oder Aktionsmodifizierer |
Beschreibung |
|---|---|
| Aktionen | |
|
|
Akzeptieren Sie ein Paket. Dies ist der Standard. |
|
|
Verwerfen Sie ein Paket unbemerkt, ohne eine ICMP-Nachricht (Internet Control Message Protocol) zu senden. |
|
|
Ersetzen Sie alle Communitys auf der Route durch die angegebenen Communities. |
|
Mark value |
Legen Sie einen DSCP-Wert für Den Datenverkehr fest, der diesem Datenstrom entspricht. Geben Sie einen Wert von 0 bis 63 an. Diese Aktion wird nur auf Junos-Geräten mit erweiterten MPCs unterstützt, die für |
|
|
Fahren Sie mit der Nächsten Spielbedingung zur Auswertung fort. |
|
|
Geben Sie eine Routing-Instanz an, an die Pakete weitergeleitet werden. |
|
|
Begrenzen Sie die Bandbreite auf der Datenstromroute. Geben Sie die Grenze in Bits pro Sekunde (bps) aus. Ab Junos OS Version 16.1R4 beträgt der Geschwindigkeitslimitbereich [0 bis 1000000000000000000]. |
|
|
Testen Sie den Datenverkehr auf der Datenstromroute. |
Validierung von Datenstromrouten
Das Junos OS installiert Datenstromrouten nur in die Datenstrom-Routing-Tabelle, wenn sie mit dem Validierungsverfahren validiert wurden. Die Routing-Engine führt die Validierung durch, bevor Routen in die Flow-Routing-Tabelle installiert werden.
Flussrouten, die mit den NLRI-Nachrichten (Network Layer Reachability) empfangen werden, werden validiert, bevor sie in die Routing-Tabelle instance.inetflow.0für den Datenfluss der primären Instanz installiert werden. Das Validierungsverfahren wird im Draft-ietf-idr-flow-spec-09.txt, Dissemination of Flow Specification Rules beschrieben. Sie können den Validierungsprozess für Datenstromrouten mit BGP NLRI-Nachrichten umgehen und Ihre eigene spezifische Importrichtlinie verwenden.
Um Validierungsvorgänge nachzuverfolgen, fügen Sie die validation Anweisung auf [edit routing-options flow] Hierarchieebene ein.
Unterstützung für BGP Flow-Specification Algorithm Version 7 und höher
Standardmäßig verwendet Junos OS den Begriffsordnungsalgorithmus, der in Version 6 des Entwurfs für die BGP-Datenstromspezifikation definiert ist. In Junos OS Version 10.0 und höher können Sie den Router so konfigurieren, dass er dem Begriffsordnungsalgorithmus entspricht, der zuerst in Version 7 der BGP-Datenstromspezifikation definiert und durch RFC 5575, Verbreitung von Flussspezifikationsrouten unterstützt wird.
Wir empfehlen, das Junos OS so zu konfigurieren, dass der Begriffsordnungsalgorithmus verwendet wird, der zuerst in Version 7 des Entwurfs für die BGP-Datenstromspezifikation definiert wurde. Wir empfehlen auch, das Junos OS so zu konfigurieren, dass auf allen Routing-Instanzen, die auf einem Router konfiguriert sind, derselbe Algorithmus für die Reihenfolge des Begriffs verwendet wird.
Um BGP so zu konfigurieren, dass der Datenstromspezifikationsalgorithmus verwendet wird, der zuerst in Version 7 des Internetentwurfs definiert wurde, fügen Sie die standard Anweisung auf Hierarchieebene [edit routing-options flow term-order] ein.
Wenn Sie den in Version 6 definierten Algorithmus für die Terminierung von Begriffen wiederherstellen möchten, fügen Sie die legacy Anweisung auf Hierarchieebene [edit routing-options flow term-order] ein.
Die konfigurierte Terminreihenfolge hat nur lokale Bedeutung. Das heißt, der Begriff Reihenfolge wird nicht mit Flussrouten weitergegeben, die an die entfernten BGP-Peers gesendet werden, deren Termreihenfolge vollständig durch ihre eigene Termreihenfolge-Konfiguration bestimmt wird. Daher sollten Sie bei der Konfiguration der auftragsabhängigen Aktion next term vorsichtig sein, wenn Ihnen der Begriff Reihenfolgenkonfiguration der Remote-Peers nicht bekannt ist. Der Lokale next term kann von der next term Konfiguration auf dem Remote-Peer abweichen.
Unter Junos OS Evolved next term kann nicht als letzter Begriff der Aktion angezeigt werden. Ein Filterbegriff, bei dem next term als Aktion angegeben wird, aber ohne Konfiguration der Übereinstimmungsbedingungen, wird nicht unterstützt.
Ab Junos OS Version 16.1 haben Sie die Option, den Filter nicht auf datenverkehr anzuwenden, der flowspec an bestimmten Schnittstellen empfangen wird. Zu Beginn des Filters wird ein neuer Begriff hinzugefügt, der alle Pakete akzeptiert, die flowspec über diese spezifischen Schnittstellen empfangen werden. Der neue Ausdruck ist eine Variable, die eine Ausschlussliste von Begriffen erstellt, die dem Weiterleitungstabellenfilter als Teil des Datenstromspezifikationsfilters zugeordnet sind.
Um den Filter von der flowspec Anwendung auf datenverkehr auszuschließen, der an bestimmten Schnittstellen empfangen wird, müssen Sie zuerst eine group-id auf solchen Schnittstellen konfigurieren, indem Sie die Filtergruppenanweisung group-id der Familie inet auf Hierarchieebene [edit interfaces] einschließen und dann den flowspec Filter mit der Schnittstellengruppe anfügen, indem Sie die flow interface-group group-id exclude Anweisung auf [edit routing-options] Hierarchieebene hinzufügen. Sie können nur eine group-id Pro Routing-Instanz mit der set routing-options flow interface-group group-id Anweisung konfigurieren.
Siehe auch
Beispiel: Ermöglichen von BGP zur Übertragung von Datenstromspezifikationsrouten
Dieses Beispiel zeigt, wie BGP die Übertragung von NLRI-Nachrichten (Network Layer Reachability) mit Datenstromspezifikation ermöglicht.
Anforderungen
Bevor Sie beginnen:
Konfigurieren Sie die Geräteschnittstellen.
Konfigurieren Sie ein Interior Gateway Protocol (IGP).
Konfigurieren Sie BGP.
Konfigurieren Sie eine Routingrichtlinie, die Routen (z. B. direkte Routen oder IGP-Routen) aus der Routingtabelle in BGP exportiert.
Überblick
Durch die Weitergabe von Firewall-Filterinformationen als Teil von BGP können Sie Firewall-Filter gegen Denial-of-Service-Angriffe (DOS) dynamisch über autonome Systeme verteilen. Datenstromrouten werden in das Flow-Spezifikations-NLRI gekapselt und über ein Netzwerk oder virtuelle private Netzwerke (VPNs) weitergegeben, um filterähnliche Informationen zu teilen. Flussrouten sind eine Aggregation von Übereinstimmungsbedingungen und daraus resultierenden Aktionen für Pakete. Sie bieten Ihnen Datenverkehrsfilterung und geschwindigkeitsbeschränkende Funktionen, ähnlich wie Firewall-Filter. Unicast-Flow-Routen werden für die Standardinstanz, VPN-Routing- und Weiterleitungsinstanzen (VRF) und virtuelle Router-Instanzen unterstützt.
Import- und Exportrichtlinien können auf die NLRI der Familie inet flow oder Familie inet-vpn flow angewendet werden, was sich auf die akzeptierten oder angekündigten Datenstromrouten auswirkt, ähnlich wie die Art und Weise, wie Import- und Exportrichtlinien auf andere BGP-Familien angewendet werden. Der einzige Unterschied besteht darin, dass die Datenflussrichtlinienkonfiguration die from-Anweisung rib inetflow.0 enthalten muss. Diese Anweisung bewirkt, dass die Richtlinie auf die Datenstromrouten angewendet wird. Eine Ausnahme von dieser Regel tritt ein, wenn die Richtlinie nur die then reject Anweisung oder die then accept Anweisung und keine from Anweisung hat. Dann betrifft die Richtlinie alle Routen, einschließlich IP-Unicast und IP-Datenstrom.
Die Datenstromroutenfilter werden zuerst statisch auf einem Router konfiguriert, wobei eine Reihe von übereinstimmenden Kriterien gefolgt von den zu ergreifenden Aktionen folgt. Dann wird zusätzlich zu family inet unicast, family inet flow (oder family inet-vpn flow) zwischen diesem BGP-fähigen Gerät und seinen Peers konfiguriert.
Standardmäßig werden statisch konfigurierte Datenstromrouten (Firewall-Filter) für andere BGP-fähige Geräte angekündigt, die die NLRI oder family inet-vpn flow NLRI family inet flow unterstützen.
Das empfangende BGP-fähige Gerät führt einen Validierungsprozess durch, bevor der Firewall-Filter in die Flow-Routing-Tabelle instance-name.inetflow.0installiert wird. Das Validierungsverfahren wird in RFC 5575, Dissemination of Flow Specification Rules beschrieben.
Das empfangende BGP-fähige Gerät akzeptiert eine Datenstromroute, wenn sie die folgenden Kriterien erfüllt:
Der Originator einer Datenstromroute stimmt mit dem Absender der am besten übereinstimmenden Unicast-Route für die in die Route eingebettete Zieladresse ab.
Im Vergleich zur Zieladresse der Datenstromroute, für die die aktive Route von einem anderen autonomen Next-Hop-System empfangen wurde, gibt es keine spezifischeren Unicast-Routen.
Das erste Kriterium stellt sicher, dass der Filter vom Next-Hop ankündigen wird, der von der Unicast-Weiterleitung für die in die Datenstromroute eingebettete Zieladresse verwendet wird. Wenn beispielsweise eine Datenstromroute als 10.1.1.1, proto=6, port=80 angegeben ist, wählt das empfangende Gerät die spezifischere Unicast-Route in der Unicast-Routing-Tabelle aus, die dem Zielpräfix 10.1.1.1/32 entspricht. In einer Unicast-Routing-Tabelle, die 10.1/16 und 10.1.1/24 enthält, wird letztere als Unicast-Route zum Vergleich ausgewählt. Nur der aktive Unicast-Routeneintrag wird berücksichtigt. Dies folgt dem Konzept, dass eine Datenstromroute gültig ist, wenn sie vom Absender der besten Unicast-Route angekündigt wird.
Das zweite Kriterium adressiert Fälle, in denen ein geordneter Adressblock verschiedenen Einheiten zugewiesen wird. Datenströme, die zu einer am besten passenden Unicast-Route aufgelöst werden, bei der es sich um eine aggregierte Route handelt, werden nur akzeptiert, wenn sie nicht spezifischere Routen abdecken, die an verschiedene autonome Next-Hop-Systeme geroutet werden.
Sie können den Validierungsprozess für Datenstromrouten mit BGP NLRI-Nachrichten umgehen und Ihre eigene spezifische Importrichtlinie verwenden. Wenn BGP NLRI-Nachrichten mit Datenstromspezifikation mit sich führt, wird die Validierungsprozedur für Datenstromrouten bei der no-validate[edit protocols bgp group group-name family inet flow] Anweisung auf Hierarchieebene weggelassen, nachdem Pakete von einer Richtlinie akzeptiert wurden. Sie können die Importrichtlinie so konfigurieren, dass sie mit der Zieladresse und den Pfadattributen wie Community, Next-Hop und AS-Pfad übereinstimmt. Sie können die Aktion angeben, die ergriffen werden soll, wenn das Paket den Bedingungen entspricht, die Sie in der Datenstromroute konfiguriert haben. Um eine Aktion zu konfigurieren, fügen Sie die Anweisung auf [edit routing-options flow] Hierarchieebene ein. Der NlRI-Typ der Datenstromspezifikation umfasst Komponenten wie Zielpräfix, Quellpräfix, Protokoll und Ports, wie im RFC 5575 definiert. Die Importrichtlinie kann eine eingehende Route mithilfe von Pfadattributen und Zieladresse in der Datenstromspezifikation NLRI filtern. Die Importrichtlinie kann keine anderen Komponenten im RFC 5575 filtern.
Die Datenstromspezifikation definiert die erforderlichen Protokollerweiterungen, um die häufigsten Anwendungen von IPv4-Unicast- und VPN-Unicast-Filterung zu adressieren. Derselbe Mechanismus kann wiederverwendet und neue Übereinstimmungskriterien hinzugefügt werden, um ähnliche Filter für andere BGP-Adressfamilien (z. B. IPv6-Unicast) zu adressieren.
Nach der Installation einer Flow-Route in der inetflow.0 Tabelle wird sie auch zur Liste der Firewall-Filter im Kernel hinzugefügt.
Nur auf Routern werden NLRI-Nachrichten mit Datenstromspezifikation in VPNs unterstützt. Das VPN vergleicht die erweiterte Route Target Community im NLRI mit der Importrichtlinie. Wenn es eine Übereinstimmung gibt, kann das VPN beginnen, die Datenstromrouten zu verwenden, um den Paketverkehr zu filtern und die Geschwindigkeit zu begrenzen. Empfangene Datenstromrouten werden in die Flow-Routing-Tabelle instance-name.inetflow.0installiert. Datenstromrouten können auch über ein VPN-Netzwerk verteilt und unter VPNs geteilt werden. Um multiprotocol BGP (MP-BGP) zur Übertragung von Flow-Spezifikations-NLRI für die inet-vpn Adressfamilie zu aktivieren, fügen Sie die flow Anweisung auf Hierarchieebene [edit protocols bgp group group-name family inet-vpn] ein. VPN-Flow-Routen werden nur für die Standardinstanz unterstützt. Flussrouten, die für VPNs mit Familie inet-vpn konfiguriert wurden, werden nicht automatisch validiert, sodass die no-validate Anweisung auf [edit protocols bgp group group-name family inet-vpn] Hierarchieebene nicht unterstützt wird. Wenn die Datenstromrouten lokal zwischen Geräten in einem einzigen AS konfiguriert sind, ist keine Validierung erforderlich.
Import- und Exportrichtlinien können auf die family inet flow NLRI oder family inet-vpn flow NLRI angewendet werden, was sich auf die akzeptierten oder angekündigten Datenstromrouten auswirkt, ähnlich wie die Art und Weise, wie Import- und Exportrichtlinien auf andere BGP-Familien angewendet werden. Der einzige Unterschied besteht darin, dass die Datenstromrichtlinienkonfiguration die from rib inetflow.0 Anweisung enthalten muss. Diese Anweisung bewirkt, dass die Richtlinie auf die Datenstromrouten angewendet wird. Eine Ausnahme von dieser Regel tritt ein, wenn die Richtlinie nur die then reject Anweisung oder die then accept Anweisung und keine from Anweisung hat. Dann betrifft die Richtlinie alle Routen, einschließlich IP-Unicast und IP-Datenstrom.
Dieses Beispiel zeigt, wie Sie die folgenden Exportrichtlinien konfigurieren:
Eine Richtlinie, die die Ankündigung von Datenstromrouten ermöglicht, die durch einen Routenfilter angegeben werden. Nur die Flow-Routen, die vom Block 10.13/16 abgedeckt sind, werden ausgeschrieben. Diese Richtlinie wirkt sich nicht auf Unicast-Routen aus.
Eine Richtlinie, mit der alle Unicast- und Datenstromrouten dem Nachbarn bekannt gegeben werden können.
Eine Richtlinie, die es erlaubt, dass alle Routen (Unicast oder Datenstrom) beim Nachbarn angekündigt werden.
Topologie
Konfiguration
- Konfigurieren einer statischen Flow-Route
- Werbeflussrouten, die durch einen Routenfilter angegeben werden
- Werbung für alle Unicast- und Flow-Routen
- Werbung ohne Unicast- oder Flow-Routen
- Begrenzung der Anzahl der in einer Routing-Tabelle installierten Datenstromrouten
- Begrenzung der Anzahl der Präfixe, die in einer BGP-Peering-Sitzung empfangen werden
Konfigurieren einer statischen Flow-Route
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 routing-options flow route block-10.131.1.1 match destination 10.131.1.1/32 set routing-options flow route block-10.131.1.1 match protocol icmp set routing-options flow route block-10.131.1.1 match icmp-type echo-request set routing-options flow route block-10.131.1.1 then discard set routing-options flow term-order standard
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 BGP-Peer-Sitzungen:
Konfigurieren Sie die Übereinstimmungsbedingungen.
[edit routing-options flow route block-10.131.1.1] user@host# set match destination 10.131.1.1/32 user@host# set match protocol icmp user@host# set match icmp-type echo-request
Konfigurieren Sie die Aktion.
[edit routing-options flow route block-10.131.1.1] user@host# set then discard
(Empfohlen) Konfigurieren Sie für den Datenstromspezifikationsalgorithmus die standardbasierte Terminreihenfolge.
[edit routing-options flow] user@host# set term-order standard
Im Standard-Begriffsordnungsalgorithmus, wie im flowspec RFC-Entwurf Version 6 angegeben, wird ein Begriff mit weniger spezifischen Abgleichbedingungen immer vor einem Begriff mit spezifischeren Übereinstimmungsbedingungen bewertet. Dies führt dazu, dass der Begriff mit spezifischeren Matching-Bedingungen niemals bewertet wird. Version 7 des RFC 5575 hat den Algorithmus überarbeitet, sodass die spezifischeren Übereinstimmungsbedingungen vor den weniger spezifischen Matching-Bedingungen ausgewertet werden. Aus Gründen der Abwärtskompatibilität wird das Standardverhalten in Junos OS nicht geändert, auch wenn der neuere Algorithmus sinnvoller ist. Um den neueren Algorithmus zu verwenden, fügen Sie die
term-order standardAnweisung in die Konfiguration ein. Diese Anweisung wird in Junos OS Version 10.0 und höher unterstützt.
Ergebnisse
Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie den show routing-options Befehl eingeben. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
[edit]
user@host# show routing-options
flow {
term-order standard;
route block-10.131.1.1 {
match {
destination 10.131.1.1/32;
protocol icmp;
icmp-type echo-request;
}
then discard;
}
}
Wenn Sie mit der Konfiguration des Geräts fertig sind, geben Sie im Konfigurationsmodus ein commit .
Werbeflussrouten, die durch einen Routenfilter angegeben werden
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 protocols bgp group core family inet unicast set protocols bgp group core family inet flow set protocols bgp group core export p1 set protocols bgp group core peer-as 65000 set protocols bgp group core neighbor 10.12.99.5 set policy-options policy-statement p1 term a from rib inetflow.0 set policy-options policy-statement p1 term a from route-filter 10.13.0.0/16 orlonger set policy-options policy-statement p1 term a then accept set policy-options policy-statement p1 term b then reject set routing-options autonomous-system 65001
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 BGP-Peer-Sitzungen:
Konfigurieren Sie die BGP-Gruppe.
[edit protocols bgp group core] user@host# set family inet unicast user@host# set family inet flow user@host# set export p1 user@host# set peer-as 65000 user@host# set neighbor 10.12.99.5
Konfigurieren Sie die Datenstromrichtlinie.
[edit policy-options policy-statement p1] user@host# set term a from rib inetflow.0 user@host# set term a from route-filter 10.13.0.0/16 orlonger user@host# set term a then accept user@host# set term b then reject
Konfigurieren Sie die Nummer des lokalen autonomen Systems (AS).
[edit routing-options] user@host# set autonomous-system 65001
Ergebnisse
Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie die show protocolsBefehle und show routing-optionsshow policy-optionsdie Befehle eingeben. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
[edit]
user@host# show protocols
bgp {
group core {
family inet {
unicast;
flow;
}
export p1;
peer-as 65000;
neighbor 10.12.99.5;
}
}
[edit]
user@host# show policy-options
policy-statement p1 {
term a {
from {
rib inetflow.0;
route-filter 10.13.0.0/16 orlonger;
}
then accept;
}
term b {
then reject;
}
}
[edit] user@host# show routing-options autonomous-system 65001;
Wenn Sie mit der Konfiguration des Geräts fertig sind, geben Sie im Konfigurationsmodus ein commit .
Werbung für alle Unicast- und Flow-Routen
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 protocols bgp group core family inet unicast set protocols bgp group core family inet flow set protocols bgp group core export p1 set protocols bgp group core peer-as 65000 set protocols bgp group core neighbor 10.12.99.5 set policy-options policy-statement p1 term a then accept set routing-options autonomous-system 65001
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 BGP-Peer-Sitzungen:
Konfigurieren Sie die BGP-Gruppe.
[edit protocols bgp group core] user@host# set family inet unicast user@host# set family inet flow user@host# set export p1 user@host# set peer-as 65000 user@host# set neighbor 10.12.99.5
Konfigurieren Sie die Datenstromrichtlinie.
[edit policy-options policy-statement p1] user@host# set term a then accept
Konfigurieren Sie die Nummer des lokalen autonomen Systems (AS).
[edit routing-options] user@host# set autonomous-system 65001
Ergebnisse
Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie die show protocolsBefehle und show routing-optionsshow policy-optionsdie Befehle eingeben. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
[edit]
user@host# show protocols
bgp {
group core {
family inet {
unicast;
flow;
}
export p1;
peer-as 65000;
neighbor 10.12.99.5;
}
}
[edit]
user@host# show policy-options
policy-statement p1 {
term a {
prefix-list inetflow;
}
then accept;
}
}
[edit] user@host# show routing-options autonomous-system 65001;
Wenn Sie mit der Konfiguration des Geräts fertig sind, geben Sie im Konfigurationsmodus ein commit .
Werbung ohne Unicast- oder Flow-Routen
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 protocols bgp group core family inet unicast set protocols bgp group core family inet flow set protocols bgp group core export p1 set protocols bgp group core peer-as 65000 set protocols bgp group core neighbor 10.12.99.5 set policy-options policy-statement p1 term a then reject set routing-options autonomous-system 65001
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 BGP-Peer-Sitzungen:
Konfigurieren Sie die BGP-Gruppe.
[edit protocols bgp group core] user@host# set family inet unicast user@host# set family inet flow user@host# set export p1 user@host# set peer-as 65000 user@host# set neighbor 10.12.99.5
Konfigurieren Sie die Datenstromrichtlinie.
[edit policy-options policy-statement p1] user@host# set term a then reject
Konfigurieren Sie die Nummer des lokalen autonomen Systems (AS).
[edit routing-options] user@host# set autonomous-system 65001
Ergebnisse
Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie die show protocolsBefehle und show routing-optionsshow policy-optionsdie Befehle eingeben. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
[edit]
user@host# show protocols
bgp {
group core {
family inet {
unicast;
flow;
}
export p1;
peer-as 65000;
neighbor 10.12.99.5;
}
}
[edit]
user@host# show policy-options
policy-statement p1 {
term a {
then reject;
}
}
[edit] user@host# show routing-options autonomous-system 65001;
Wenn Sie mit der Konfiguration des Geräts fertig sind, geben Sie im Konfigurationsmodus ein commit .
Begrenzung der Anzahl der in einer Routing-Tabelle installierten Datenstromrouten
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 routing-options rib inetflow.0 maximum-prefixes 1000 set routing-options rib inetflow.0 maximum-prefixes threshold 50
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.
Die Anwendung einer Routenbeschränkung kann zu einem unvorhersehbaren dynamischen Routenprotokollverhalten führen. Wenn beispielsweise die Grenze erreicht und Routen abgelehnt werden, versucht BGP nicht unbedingt, die abgelehnten Routen neu zu installieren, nachdem die Anzahl der Routen unter den Limit fällt. BGP-Sitzungen müssen möglicherweise freigegeben werden, um dieses Problem zu beheben.
So begrenzen Sie die Datenstromrouten:
Setzen Sie eine Obergrenze für die Anzahl der in
inetflow.0der Tabelle installierten Präfixe.[edit routing-options rib inetflow.0] user@host# set maximum-prefixes 1000
Setzen Sie einen Schwellenwert von 50 Prozent, wobei bei der Installation von 500 Routen eine Warnung im Systemprotokoll protokolliert wird.
[edit routing-options rib inetflow.0] user@host# set maximum-prefixes threshold 50
Ergebnisse
Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie den show routing-options Befehl eingeben. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
[edit]
user@host# show routing-options
rib inetflow.0 {
maximum-prefixes 1000 threshold 50;
}
Wenn Sie mit der Konfiguration des Geräts fertig sind, geben Sie im Konfigurationsmodus ein commit .
Begrenzung der Anzahl der Präfixe, die in einer BGP-Peering-Sitzung empfangen werden
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 protocols bgp group x1 neighbor 10.12.99.2 family inet flow prefix-limit maximum 1000 set protocols bgp group x1 neighbor 10.12.99.2 family inet flow prefix-limit teardown 50 set protocols bgp group x1 neighbor 10.12.99.2 family inet flow prefix-limit drop-excess 50 set protocols bgp group x1 neighbor 10.12.99.2 family inet flow prefix-limit hide-excess 50
Sie können entweder die Anweisungsoption teardown <percentage>, drop-excess <percentage>oder hide-excess<percentage> die Anweisungsoption nacheinander einschließen.
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.
Die Konfiguration einer Präfix-Begrenzung für einen bestimmten Nachbarn bietet eine besser vorhersagbare Kontrolle darüber, welcher Peer wie viele Datenstromrouten ankündigen kann.
So begrenzen Sie die Anzahl der Präfixe:
Setzen Sie ein Limit von 1000 BGP-Routen vom Nachbarn 10.12.99.2.
[edit protocols bgp group x1] user@host# set neighbor 10.12.99.2 family inet flow prefix-limit maximum 1000
-
Konfigurieren Sie die Nachbarsitzung oder präfixe so, dass sie entweder
teardown <percentage>oderdrop-excess <percentage>diehide-excess<percentage>Anweisungsoption ausführen, wenn die Sitzung oder präfixe ihre Grenze erreicht.[edit routing-options rib inetflow.0] user@host# set neighbor 10.12.99.2 family inet flow prefix-limit teardown 50 set neighbor 10.12.99.2 family inet flow prefix-limit drop-excess 50 set neighbor 10.12.99.2 family inet flow prefix-limit hide-excess 50
Wenn Sie die
teardown <percentage>Anweisung angeben und einen Prozentsatz angeben, werden Nachrichten protokolliert, wenn die Anzahl der Präfixe diesen Prozentsatz erreicht. Nachdem die Sitzung heruntergefahren wurde, wird die Sitzung in kurzer Zeit wieder eingerichtet, es sei denn, Sie fügen die Anweisung beiidle-timeout.Wenn Sie die
drop-excess <percentage>Anweisung angeben und einen Prozentsatz angeben, werden die überschüssigen Routen gelöscht, wenn die Anzahl der Präfixe diesen Prozentsatz übersteigtWenn Sie die
hide-excess <percentage>Anweisung angeben und einen Prozentsatz angeben, werden die überschüssigen Routen ausgeblendet, wenn die Anzahl der Präfixe diesen Prozentsatz übersteigt.
Ergebnisse
Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie den show protocols Befehl eingeben. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
[edit]
user@host# show protocols
bgp {
group x1 {
neighbor 10.12.99.2 {
flow {
prefix-limit {
maximum 1000;
teardown 50;
drop-excess <percentage>;
hide-excess <percentage>;
}
}
}
}
}
}
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üfung des NLRI
- Verifizieren von Routen
- Überprüfung der Datenstromvalidierung
- Firewall-Filter überprüfen
- Überprüfung der Systemprotokollierung bei Überschreitung der Anzahl zulässiger Datenstromrouten
- Überprüfung der Systemprotokollierung bei Überschreiten der Anzahl der Präfixe, die in einer BGP-Peering-Sitzung empfangen werden
Überprüfung des NLRI
Zweck
Sehen Sie sich die NLRI für den Nachbarn an.
Aktion
Führen Sie den Befehl im show bgp neighbor 10.12.99.5 Betriebsmodus aus. inet-flow Suchen Sie in der Ausgabe.
user@host> show bgp neighbor 10.12.99.5 Peer: 10.12.99.5+3792 AS 65000 Local: 10.12.99.6+179 AS 65002 Type: External State: Established Flags: <Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ direct ] Options: <Preference HoldTime AddressFamily PeerAS Refresh> Address families configured: inet-unicast inet-multicast inet-flow Holdtime: 90 Preference: 170 Number of flaps: 1 Error: 'Cease' Sent: 0 Recv: 1 Peer ID: 10.255.71.161 Local ID: 10.255.124.107 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 0 Local Interface: e1-3/0/0.0 NLRI advertised by peer: inet-unicast inet-multicast inet-flow NLRI for this session: inet-unicast inet-multicast inet-flow Peer supports Refresh capability (2) Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 2 Received prefixes: 2 Suppressed due to damping: 0 Advertised prefixes: 3 Table inet.2 Bit: 20000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 0 Suppressed due to damping: 0 Advertised prefixes: 0 Table inetflow.0 Bit: 30000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 0 Suppressed due to damping: 0 Advertised prefixes: 0 Last traffic (seconds): Received 29 Sent 15 Checked 15 Input messages: Total 5549 Updates 2618 Refreshes 0 Octets 416486 Output messages: Total 2943 Updates 1 Refreshes 0 Octets 55995 Output Queue[0]: 0 Output Queue[1]: 0 Output Queue[2]: 0
Verifizieren von Routen
Zweck
Sehen Sie sich die Datenstromrouten an. Die Beispielausgabe zeigt eine Datenstromroute, die aus BGP gelernt wurde, und eine statisch konfigurierte Datenflussroute.
Für lokal konfigurierte Flussrouten (konfiguriert [edit routing-options flow] auf Hierarchieebene) werden die Routen durch das Datenstromprotokoll installiert. Daher können Sie die Datenstromrouten anzeigen, indem Sie die Tabelle angeben, wie in show route table inetflow.0 oder show route table instance-name.inetflow.0, wo instance-name der Name der Routing-Instanz ist. Alternativ können Sie alle lokal konfigurierten Datenstromrouten über mehrere Routing-Instanzen hinweg anzeigen, indem Sie den show route protocol flow Befehl ausführen.
Wenn eine Datenstromroute nicht lokal konfiguriert, aber vom BGP-Peer des Routers empfangen wird, wird diese Datenstromroute von BGP in der Routing-Tabelle installiert. Sie können die Datenstromrouten anzeigen, indem Sie die Tabelle angeben oder indem Sie ausführen show route protocol bgp, in der alle BGP-Routen (Datenstrom und Nicht-Datenstrom) angezeigt werden.
Aktion
Führen Sie den Befehl im show route table inetflow.0 Betriebsmodus aus.
user@host> show route table inetflow.0
inetflow.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
100.100.100.100,*,proto=1,icmp-type=8/term:1
*[BGP/170] 00:00:18, localpref 100, from 100.0.12.2
AS path: 2000 I, validation-state: unverified
Fictitious
200.200.200.200,*,proto=6,port=80/term:2
*[BGP/170] 00:00:18, localpref 100, from 100.0.12.2
AS path: 2000 I, validation-state: unverified
Fictitious
user@host> show route table inetflow.0 extensive
inetflow.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
7.7.7.7,8.8.8.8/term:1 (1 entry, 1 announced)
TSI:
KRT in dfwd;
Action(s): accept,count
*Flow Preference: 5
Next hop type: Fictitious
Address: 0x8d383a4
Next-hop reference count: 3
State: <Active>
Local AS: 65000
Age: 9:50
Task: RT Flow
Announcement bits (1): 0-Flow
AS path: I
user@host> show route hidden
inetflow.0: 2 destinations, 2 routes (0 active, 0 holddown, 2 hidden)
+ = Active Route, - = Last Active, * = Both
100.100.100.100,*,proto=1,icmp-type=8/term:N/A
[BGP ] 00:00:17, localpref 100, from 100.0.12.2
AS path: 2000 I, validation-state: unverified
Fictitious
200.200.200.200,*,proto=6,port=80/term:N/A
[BGP ] 00:00:17, localpref 100, from 100.0.12.2
AS path: 2000 I, validation-state: unverified
Fictitious
Bedeutung
Eine Datenstromroute repräsentiert den Begriff eines Firewall-Filters. Wenn Sie eine Datenstromroute konfigurieren, geben Sie die Übereinstimmungsbedingungen und die Aktionen an. In den Übereinstimmungsattributen können Sie eine Quelladresse, eine Zieladresse und andere Qualifizierer wie den Port und das Protokoll abgleichen. Für eine einzelne Datenstromroute, die mehrere Übereinstimmungsbedingungen enthält, werden alle Übereinstimmungsbedingungen im Prefix-Feld der Route gekapselt. Wenn Sie den show route Befehl für eine Datenstromroute ausstellen, wird das Prefix-Feld der Route mit allen Übereinstimmungsbedingungen angezeigt. 10.12.44.1,* Das bedeutet, dass die übereinstimmende Bedingung ist match destination 10.12.44.1/32. Wenn das Präfix in der Ausgabe wäre *,10.12.44.1, bedeutet dies, dass die Übereinstimmungsbedingung match source 10.12.44.1/32. Wenn die übereinstimmenden Bedingungen sowohl eine Quelle als auch ein Ziel enthalten, wird das Sternchen durch die Adresse ersetzt.
Die Begriffsreihenfolgen geben die Reihenfolge der Begriffe an, die im Firewall-Filter ausgewertet werden (Flussrouten). Der show route extensive Befehl zeigt die Aktionen für jeden Begriff (Route) an.
Überprüfung der Datenstromvalidierung
Zweck
Zeigen Sie Datenflussrouteninformationen an.
Aktion
Führen Sie den Befehl im show route flow validation detail Betriebsmodus aus.
user@host> show route flow validation detail
inet.0:
0.0.0.0/0
Internal node: best match, inconsistent
10.0.0.0/8
Internal node: no match, inconsistent
10.12.42.0/24
Internal node: no match, consistent, next-as: 65003
Active unicast route
Dependent flow destinations: 1
Origin: 10.255.124.106, Neighbor AS: 65003
10.12.42.1/32
Flow destination (1 entries, 1 match origin)
Unicast best match: 10.12.42.0/24
Flags: Consistent
10.131.0.0/16
Internal node: no match, consistent, next-as: 65001
Active unicast route
Dependent flow destinations: 5000
Origin: 10.12.99.2, Neighbor AS: 65001
10.131.0.0/19
Internal node: best match
10.131.0.0/20
Internal node: best match
10.131.0.0/21
Firewall-Filter überprüfen
Zweck
Zeigen Sie die Firewall-Filter an, die im Kernel installiert sind.
Aktion
Führen Sie den Befehl im show firewall Betriebsmodus aus.
user@host> show firewall Filter: __default_bpdu_filter__ Filter: __flowspec_default_inet__ Counters: Name Bytes Packets 10.12.42.1,* 0 0 196.1.28/23,* 0 0 196.1.30/24,* 0 0 196.1.31/24,* 0 0 196.1.32/24,* 0 0 196.1.56/21,* 0 0 196.1.68/24,* 0 0 196.1.69/24,* 0 0 196.1.70/24,* 0 0 196.1.75/24,* 0 0 196.1.76/24,* 0 0
Überprüfung der Systemprotokollierung bei Überschreitung der Anzahl zulässiger Datenstromrouten
Zweck
Wenn Sie eine Begrenzung für die Anzahl der installierten Datenstromrouten konfigurieren, wie in Begrenzung der Anzahl der in einer Routing-Tabelle installierten Datenstromroutenbeschrieben, zeigen Sie die Systemprotokollmeldung an, wenn der Schwellenwert erreicht wird.
Aktion
Führen Sie den Befehl im show log <message> Betriebsmodus aus.
user@host> show log message Jul 12 08:19:01 host rpd[2748]: RPD_RT_MAXROUTES_WARN: Number of routes (1000) in table inetflow.0 exceeded warning threshold (50 percent of configured maximum 1000)
Überprüfung der Systemprotokollierung bei Überschreiten der Anzahl der Präfixe, die in einer BGP-Peering-Sitzung empfangen werden
Zweck
Wenn Sie eine Begrenzung für die Anzahl der installierten Datenstromrouten konfigurieren, wie in Begrenzung der Anzahl der Präfixe, die in einer BGP-Peering-Sitzung empfangen werdenbeschrieben, zeigen Sie die Systemprotokollmeldung an, wenn der Schwellenwert erreicht wird.
Aktion
Führen Sie den Befehl im show log message Betriebsmodus aus.
Wenn Sie die Anweisungsoption teradown <percentage> angeben:
user@host> show log message Jul 12 08:44:47 host rpd[2748]: 10.12.99.2 (External AS 65001): Shutting down peer due to exceeding configured maximum prefix-limit(1000) for inet-flow nlri: 1001
Wenn Sie die Anweisungsoption drop-excess <percentage> angeben:
user@host> show log message Jul 27 15:26:57 R1_re rpd[32443]: BGP_DROP_PREFIX_LIMIT_EXCEEDED: 1.1.1.2 (Internal AS 1): Exceeded drop-excess maximum prefix-limit(4) for inet-unicast nlri: 5 (instance master)
Wenn Sie die Anweisungsoption hide-excess <percentage> angeben:
user@host> show log message Jul 27 15:26:57 R1_re rpd[32443]: BGP_HIDE_PREFIX_LIMIT_EXCEEDED: 1.1.1.2 (Internal AS 1): Exceeded hide-excess maximum prefix-limit(4) for inet-unicast nlri: 5 (instance master)
Beispiel: Konfiguration von BGP für die Übertragung von IPv6-Datenstromspezifikationsrouten
Dieses Beispiel zeigt, wie Sie die IPv6-Datenstromspezifikation für die Filterung des Datenverkehrs konfigurieren. Die BGP-Datenstromspezifikation kann verwendet werden, um domänen- und domäneninterne Koordination von Datenverkehrsfilterregeln zu automatisieren, um Denial-of-Service-Angriffe abzuwehren.
Anforderungen
In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:
Zwei Router der MX-Serie
Junos OS Version 16.1 oder höher
Bevor Sie BGP aktivieren, um IPv6-Datenstromspezifikationsrouten zu übertragen:
Konfigurieren Sie IP-Adressen auf den Geräteschnittstellen.
Konfigurieren Sie BGP.
Konfigurieren Sie eine Routingrichtlinie, die Routen (z. B. statische Routen, direkte Routen oder IGP-Routen) aus der Routing-Tabelle in BGP exportiert.
Überblick
Die Datenstromspezifikation bietet Schutz vor Denial-of-Service-Angriffen und beschränkt schlechten Datenverkehr, der die Bandbreite verbraucht und ihn in der Nähe der Quelle stoppt. In früheren Junos OS-Versionen wurden Datenstromspezifikationsregeln für IPv4 über BGP als Informationen zur Erreichbarkeit auf Netzwerkebene weitergegeben. Ab Junos OS Version 16.1 wird die Datenstromspezifikationsfunktion auf der IPv6-Familie unterstützt und ermöglicht die Verbreitung von Datenverkehrsspezifikationsregeln für IPv6 und IPv6 VPN.
Topologie
Abbildung 7 zeigt die Beispieltopologie. Router R1 und Router R2 gehören zu verschiedenen autonomen Systemen. Die IPv6-Datenstromspezifikation wird auf Router R2 konfiguriert. Der gesamte eingehende Datenverkehr wird basierend auf den Bedingungen der Datenstromspezifikation gefiltert und der Datenverkehr wird je nach der angegebenen Aktion unterschiedlich behandelt. In diesem Beispiel wird der gesamte Datenverkehr zu abcd::11:11:11:11:10/128, der den Bedingungen der Datenstromspezifikation entspricht, verworfen. während Datenverkehr, der für abcd::11:11:11:11:30/128 bestimmt ist, akzeptiert wird und den Bedingungen der Datenstromspezifikation entspricht.
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, kopieren Sie die Befehle, fügen Sie sie auf Hierarchieebene in die [edit] CLI ein, und geben Sie dann aus dem Konfigurationsmodus ein commit .
Router R1
set interfaces ge-1/1/4 unit 0 family inet6 address abcd::13:14:2:1/120 set interfaces lo0 unit 0 family inet6 address abcd::128:220:21:197/128 set routing-options router-id 128.220.21.197 set routing-options autonomous-system 64496 set protocols bgp group ebgp type external set protocols bgp group ebgp family inet6 unicast set protocols bgp group ebgp family inet6 flow set protocols bgp group ebgp peer-as 64497 set protocols bgp group ebgp neighbor abcd::13:14:2:2
Router R2
set interfaces ge-1/0/0 unit 0 family inet6 address abcd::192:2:1:1/120 set interfaces ge-1/1/5 unit 0 family inet6 address abcd::13:14:2:2/120 set interfaces lo0 unit 0 family inet6 address abcd::128:220:41:229/128 set routing-options rib inet6.0 static route abcd::11:11:11:0/120 next-hop abcd::192:2:1:2 set routing-options rib inet6.0 flow route route-1 match destination abcd::11:11:11:10/128 set routing-options rib inet6.0 flow route route-1 match protocol tcp set routing-options rib inet6.0 flow route route-1 match destination-port http set routing-options rib inet6.0 flow route route-1 match source-port 65535 set routing-options rib inet6.0 flow route route-1 then discard set routing-options rib inet6.0 flow route route-2 match destination abcd::11:11:11:30/128 set routing-options rib inet6.0 flow route route-2 match icmp6-type echo-request set routing-options rib inet6.0 flow route route-2 match packet-length 100 set routing-options rib inet6.0 flow route route-2 match dscp 10 set routing-options rib inet6.0 flow route route-2 then accept set routing-options router-id 128.220.41.229 set routing-options autonomous-system 64497 set protocols bgp group ebgp type external set protocols bgp group ebgp family inet6 unicast set protocols bgp group ebgp family inet6 flow set protocols bgp group ebgp export redis set protocols bgp group ebgp peer-as 64496 set protocols bgp group ebgp neighbor abcd::13:14:2:1 set policy-options policy-statement redis from protocol static set policy-options policy-statement redis then accept
Router R2 konfigurieren
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 Router R2:
Wiederholen Sie diese Prozedur für Router R1, nachdem Sie die entsprechenden Schnittstellennamen, Adressen und andere Parameter geändert haben.
Konfigurieren Sie die Schnittstellen mit IPv6-Adressen.
[edit interfaces] user@R2# set ge-1/0/0 unit 0 family inet6 address abcd::192:2:1:1/120 user@R2# set ge-1/1/5 unit 0 family inet6 address abcd::13:14:2:2/120
Konfigurieren Sie die IPv6-Loopback-Adresse.
[edit interfaces] user@R2# set lo0 unit 0 family inet6 address abcd::128:220:41:229/128
Konfigurieren Sie die Router-ID und die Nummer des autonomen Systems (AS).
[edit routing-options] user@R2# set router-id 128.220.41.229 user@R2# set autonomous-system 64497
Konfigurieren Sie eine EBGP-Peering-Sitzung zwischen Router R1 und Router R2.
[edit protocols] user@R2# set bgp group ebgp type external user@R2# set bgp group ebgp family inet6 unicast user@R2# set bgp group ebgp family inet6 flow user@R2# set bgp group ebgp export redis user@R2# set bgp group ebgp peer-as 64496 user@R2# set bgp group ebgp neighbor abcd::13:14:2:1
Konfigurieren Sie eine statische Route und einen nächsten Hop. Daher wird zur Routingtabelle eine Route hinzugefügt, um die Funktion in diesem Beispiel zu überprüfen.
[edit routing-options] user@R2# set rib inet6.0 static route abcd::11:11:11:0/120 next-hop abcd::192:2:1:2
Geben Sie die Bedingungen der Datenstromspezifikation an.
[edit routing-options] user@R2# set rib inet6.0 flow route route-1 match destination abcd::11:11:11:10/128 user@R2# set rib inet6.0 flow route route-1 match protocol tcp user@R2# set rib inet6.0 flow route route-1 match destination-port http user@R2# set rib inet6.0 flow route route-1 match source-port 65535
Konfigurieren Sie eine discard Aktion zum Verwerfen von Paketen, die den angegebenen Übereinstimmungsbedingungen entsprechen.
[edit routing-options] user@R2# set rib inet6.0 flow route route-1 then discard
Geben Sie die Bedingungen der Datenstromspezifikation an.
[edit routing-options] user@R2# set rib inet6.0 flow route route-2 match destination abcd::11:11:11:30/128 user@R2# set rib inet6.0 flow route route-2 match icmp6-type echo-request user@R2# set rib inet6.0 flow route route-2 match packet-length 100 user@R2# set rib inet6.0 flow route route-2 match dscp 10
Konfigurieren Einer accept Aktion zur Annahme von Paketen, die den angegebenen Übereinstimmungsbedingungen entsprechen
[edit routing-options] user@R2# set rib inet6.0 flow route route-2 then accept
Definieren Sie eine Richtlinie, die es BGP ermöglicht, statische Routen zu akzeptieren.
[edit policy-options] user@R2# set policy-statement redis from protocol static user@R2# set policy-statement redis then accept
Ergebnisse
Bestätigen Sie Ihre Konfiguration im Konfigurationsmodus, indem Sie die show interfacesBefehle , show protocols, show routing-optionsund show policy-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.
[edit]
user@R2# show interfaces
ge-1/0/0 {
unit 0 {
family inet6 {
address abcd::192:2:1:1/120;
}
}
}
ge-1/1/5 {
unit 0 {
family inet6 {
address abcd::13:14:2:2/120;
}
}
}
lo0 {
unit 0 {
family inet6 {
address abcd::128:220:41:229/128;
}
}
}
[edit]
user@R2# show protocols
bgp {
group ebgp {
type external;
family inet6 {
unicast;
flow;
}
export redis;
peer-as 64496;
neighbor abcd::13:14:2:1;
}
}
[edit]
user@R2# show routing-options
rib inet6.0 {
static {
route abcd::11:11:11:0/120 next-hop abcd::192:2:1:2;
}
flow {
route route-1 {
match {
destination abcd::11:11:11:10/128;
protocol tcp;
destination-port http;
source-port 65535;
}
then discard;
}
route route-2 {
match {
destination abcd::11:11:11:30/128;
icmp6-type echo-request;
packet-length 100;
dscp 10;
}
then accept;
}
}
}
router-id 128.220.41.229;
autonomous-system 64497;
[edit]
user@R2# show policy-options
policy-statement redis {
from protocol static;
then accept;
}
Überprüfung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
- Überprüfen des Vorhandenseins von IPv6-Datenstromspezifikationsrouten in der inet6flow-Tabelle
- Überprüfung der BGP-Zusammenfassungsinformationen
- Überprüfung der Datenstromvalidierung
- Überprüfung der Datenstromspezifikation von IPv6-Routen
Überprüfen des Vorhandenseins von IPv6-Datenstromspezifikationsrouten in der inet6flow-Tabelle
Zweck
Zeigen Sie die Routen in der inet6flow Tabelle in Router R1 und R2 an, und überprüfen Sie, ob BGP die Datenstromrouten gelernt hat.
Aktion
Führen Sie den show route table inet6flow.0 extensive Befehl im Betriebsmodus auf Router R1 aus.
user@R1> show route table inet6flow.0 extensive
inet6flow.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
abcd::11:11:11:10/128,*,proto=6,dstport=80,srcport=65535/term:1 (1 entry, 1 announced)
TSI:
KRT in dfwd;
Action(s): discard,count
*BGP Preference: 170/-101
Next hop type: Fictitious, Next hop index: 0
Address: 0x9b24064
Next-hop reference count: 2
State:<Active Ext>
Local AS: 64496 Peer AS: 64497
Age: 20:55
Validation State: unverified
Task: BGP_64497.abcd::13:14:2:2
Announcement bits (1): 0-Flow
AS path: 64497 I
Communities: traffic-rate:64497:0
Accepted
Validation state: Accept, Originator: abcd::13:14:2:2, Nbr AS: 64497
Via: abcd::11:11:11:0/120, Active
Localpref: 100
Router ID: 128.220.41.229
abcd::11:11:11:30/128,*,icmp6-type=128,len=100,dscp=10/term:2 (1 entry, 1 announced)
TSI:
KRT in dfwd;
Action(s): accept,count
*BGP Preference: 170/-101
Next hop type: Fictitious, Next hop index: 0
Address: 0x9b24064
Next-hop reference count: 2
State: <Active Ext>
Local AS: 64496 Peer AS: 64497
Age: 12:51
Validation State: unverified
Task: BGP_64497.abcd::13:14:2:2
Announcement bits (1): 0-Flow
AS path: 64497 I
Accepted
Validation state: Accept, Originator: abcd::13:14:2:2, Nbr AS: 64497
Via: abcd::11:11:11:0/120, Active
Localpref: 100
Router ID: 128.220.41.229Führen Sie den show route table inet6flow.0 extensive Befehl im Betriebsmodus auf Router R2 aus.
user@R2> show route table inet6flow.0 extensive
inet6flow.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
abcd::11:11:11:10/128,*,proto=6,dstport=80,srcport=65535/term:1 (1 entry, 1 announced)
TSI:
KRT in dfwd;
Action(s): discard,count
Page 0 idx 0, (group pe-v6 type External) Type 1 val 0xaec8850 (adv_entry)
Advertised metrics:
Nexthop: Self
AS path: [64497]
Communities: traffic-rate:64497:0
Path abcd::11:11:11:10/128,*,proto=6,dstport=80,srcport=65535 Vector len 4. Val: 0
*Flow Preference: 5
Next hop type: Fictitious, Next hop index: 0
Address: 0x9b24064
Next-hop reference count: 3
State: <Active>
Local AS: 64497
Age: 14:21
Validation State: unverified
Task: RT Flow
Announcement bits (2): 0-Flow 1-BGP_RT_Background
AS path: I
Communities: traffic-rate:64497:0
abcd::11:11:11:30/128,*,proto=17,port=65535/term:2 (1 entry, 1 announced)
TSI:
KRT in dfwd;
Action(s): accept,count
Page 0 idx 0, (group pe-v6 type External) Type 1 val 0xaec8930 (adv_entry)
Advertised metrics:
Nexthop: Self
AS path: [64497]
Communities:
Path abcd::11:11:11:30/128,*,proto=17,port=65535 Vector len 4. Val: 0
*Flow Preference: 5
Next hop type: Fictitious, Next hop index: 0
Address: 0x9b24064
Next-hop reference count: 3
State: <Active>
Local AS: 64497
Age: 14:21
Validation State: unverified
Task: RT Flow
Announcement bits (2): 0-Flow 1-BGP_RT_Background
AS path: I Bedeutung
Das Vorhandensein von Routen abcd::11:11:11:10/128 und abcd::11:11:11:30/128 inet6flow bestätigt, dass BGP die Flow-Routen gelernt hat.
Überprüfung der BGP-Zusammenfassungsinformationen
Zweck
Stellen Sie sicher, dass die BGP-Konfiguration korrekt ist.
Aktion
Führen Sie den Befehl im Betriebsmodus auf Den show bgp summary Routern R1 und R2 aus.
user@R1> show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet6.0
1 1 0 0 0 0
inet6flow.0
2 2 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
abcd::13:14:2:2 2000 58 58 0 2 19:48 Establ
inet6.0: 1/1/1/0
inet6flow.0: 2/2/2/0
user@R2> show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet6.0
0 0 0 0 0 0
inet6flow.0
0 0 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
abcd::13:14:2:1 64496 51 52 0 0 23:03 Establ
inet6.0: 0/0/0/0
inet6flow.0: 0/0/0/0Bedeutung
Stellen Sie sicher, dass die inet6.0 Tabelle die BGP-Nachbarnadresse enthält und eine Peering-Sitzung mit ihrem BGP-Nachbarn eingerichtet wurde.
Überprüfung der Datenstromvalidierung
Zweck
Zeigen Sie Datenflussrouteninformationen an.
Aktion
Führen Sie den show route flow validation Befehl im Betriebsmodus auf Router R1 aus.
user@R1> show route flow validation
inet6.0:
abcd::11:11:11:0/120
Active unicast route
Dependent flow destinations: 2
Origin: abcd::13:14:2:2, Neighbor AS: 64497
abcd::11:11:11:10/128
Flow destination (1 entries, 1 match origin, next-as)
Unicast best match: abcd::11:11:11:0/120
Flags: Consistent
abcd::11:11:11:30/128
Flow destination (1 entries, 1 match origin, next-as)
Unicast best match: abcd::11:11:11:0/120
Flags: ConsistentBedeutung
Die Ausgabe zeigt die Datenstromrouten in der inet6.0 Tabelle an.
Überprüfung der Datenstromspezifikation von IPv6-Routen
Zweck
Zeigt die Anzahl der Pakete an, die basierend auf den angegebenen Datenstromspezifikationsrouten verworfen und akzeptiert werden.
Aktion
Führen Sie den show firewall filter_flowspec_default_inet6_ Befehl im Betriebsmodus auf Router R2 aus.
user@R2> show firewall filter __flowspec_default_inet6__ Filter: __flowspec_default_inet6__ Counters: Name Bytes Packets abcd::11:11:11:10/128,*,proto=6,dstport=80,srcport=65535 0 0 abcd::11:11:11:30/128,*,proto=17,port=65535 6395472 88826
Bedeutung
Die Ausgabe zeigt an, dass Pakete, die für abcd:::11:11:11:10/128 bestimmt sind, verworfen und 88826 Pakete für die Route abcd:::11:11:11:11:11:11:30/128 akzeptiert wurden.
Konfiguration der BGP Flow Specification Action Umleitung zu IP zum Filtern von DDoS-Datenverkehr
Ab Junos OS Version 18.4R1, BGP-Flow-Spezifikation, wie in BGP Flow-Spec Internet Draft draft-ietf-idr-flowspec-redirect-ip-02.txt beschrieben, wird Redirect to IP Action unterstützt. Umleitung zur IP-Aktion nutzt eine erweiterte BGP-Community, um Datenverkehrsfilteroptionen für die DDoS-Abwehr in Service Provider-Netzwerken bereitzustellen. Umleitung älterer Datenstromspezifikationen zur IP verwendet das BGP nexthop-Attribut. Junos OS kündigt standardmäßig eine Umleitung zur IP-Flow-Spezifikationsaktion mit der erweiterten Community an. Diese Funktion ist erforderlich, um die Serviceverkettung im virtuellen Service Control Gateway (vSCG) zu unterstützen. Die Aktion "Redirect to IP" ermöglicht es, den übereinstimmenden Datenstromdatenverkehr an eine global erreichbare Adresse umzuleiten, die mit einem Filtergerät verbunden werden könnte, das den DDoS-Datenverkehr filtern und den sauberen Datenverkehr an das Ausgangsgerät senden kann.
Gehen Sie wie folgt vor, den Datenverkehr für BGP-Datenspezifikationsrouten an IP umzuleiten:
Konfigurieren Sie die Geräteschnittstellen.
Konfigurieren Sie OSPF oder ein anderes IGP-Protokoll.
Konfigurieren Sie MPLS und LDP.
Konfigurieren Sie BGP.
Konfigurieren Sie die Funktion "Redirect to IP" mithilfe der erweiterten BGP-Community.
Konfigurieren Sie die Umleitung der älteren Datenstromspezifikation zur IP-Funktion mithilfe des nexthop-Attributs.
Sie können Richtlinien nicht so konfigurieren, dass der Datenverkehr mithilfe der erweiterten BGP-Community und der älteren Umleitung zur IP-Adresse des nächsten Hops an eine IP-Adresse umgeleitet wird.
Konfigurieren Sie die Umleitung älterer Datenstromspezifikationen an die IP, die im Internet-Entwurf draft-ietf-idr-flowspec-redirect-ip-00.txt angegeben wurde , BGP Flow-Spec Extended Community for Traffic Redirect to IP Next Hop include auf Hierarchieebene.
[edit group bgp-group neighbor bgp neighbor family inet flow] user@host# set legacy-redirect-ip-action
Definieren Sie eine Richtlinie, die mit dem Attribut des nächsten Hops übereinstimmt.
[edit policy options] user@host#policy statement policy_name user@host#from community community-name user@host#from next-hop ip-address
Definieren Sie beispielsweise eine Richtlinie p1, um den Datenverkehr an die IP-Adresse 10.1.1.1 des nächsten Hops umzuleiten.
[edit policy options] user@host#policy statement p1 user@host#from community redirnh user@host#from next-hop 10.1.1.1
Definieren Sie eine Richtlinie zum Festlegen, Hinzufügen oder Löschen der BGP-Community mithilfe der veralteten Datenstromspezifikation next Hop-Attribut, das zur IP-Aktion umleitet.
[edit policy-options] user@host# policy-statement policy_name user@host# then community set community-name user@host# then community add community-name user@host# then community delete community-name user@host# then next-hop next-hop-address
Definieren Sie beispielsweise eine Richtlinie p1 und setzen, hinzufügen oder löschen Sie eine BGP-Community redirnh, um den DDoS-Datenverkehr an die IP-Adresse 10.1.1 des nächsten Hops umzuleiten.
[edit policy-options policy-statement p1] user@host# then community set redirnh user@host# then community add redirnh user@host# then community delete redirnh user@host# then next-hop 10.1.1.1
Siehe auch
Weiterleitung des Datenverkehrs mithilfe der DSCP-Aktion der BGP-Datenstromspezifikation
Konfigurieren Sie BGP Flow Specification (FlowSpec) DSCP-Aktion, um Pakete mithilfe der Weiterleitungsklassen- und Verlustprioritätsinformationen effektiv über das Netzwerk weiterzuleiten.
Vorteile der BGP FlowSpec DSCP-Aktion zur Weiterleitung von Paketen
-
Leitet den Datenverkehr an die beabsichtigten COS-Warteschlangen weiter, in denen COS-Richtlinien korrekt auf den Datenverkehr angewendet werden.
-
Beeinflusst das lokale Weiterleitungsverhalten (z. B. die Auswahl des Tunnels) basierend auf dem bereitgestellten DSCP-Wert.
-
Hilft bei der effektiven Verwaltung des Datenverkehrs in Ihrem Netzwerk.
Wenn ein Paket in einen Router gelangt, durchläuft das Paket die Funktionen (z. B. Firewall, COS usw.), die an der Eingangsschnittstelle angewendet werden. Wenn Sie den BGP FlowSpec-Filter auf der Eingangsschnittstelle konfigurieren, wird der Filter basierend auf der DSCP-Aktion auf die Pakete pro Routing-Instanz angewendet. Die DSCP-Aktion klassifiziert und schreibt die Pakete neu, zusammen mit der DSCP-Codeänderung durch den BGP FlowSpec-Filter. Basierend auf den Informationen zu Weiterleitungsklasse und Verlustpriorität werden die Pakete in die richtige Weiterleitungswarteschlange gestellt. Pakete werden nur dann durch Flussrouten geleitet, wenn bestimmte Übereinstimmungsbedingungen erfüllt sind. Die passenden Bedingungen können Quell- und Ziel-IP-Adresse, Quell- und Ziel-Port, DSCP, Protokollnummer usw. sein. Die Weiterleitungsklassen- und Verlustprioritätsinformationen werden über die Reverse-Zuordnungstabelle aktualisiert.
Hier ist eine Topologie einer BGP-Sitzung, die zwischen dem Service Provider und den Netzwerken der Unternehmenskunden eingerichtet wurde.
In dieser Topologie wird eine BGP-Sitzung zwischen dem Service Provider und dem Unternehmenskundennetzwerk für BGP FlowSpec konfiguriert. Der BGP FlowSpec-Filter wird sowohl auf PE1- als auch auf PE2-Routern angewendet. Pakete, die diese Router eingeben, werden basierend auf dem BGP FlowSpec-Filter und der DSCP-Aktion umgeschrieben.
Um den BGP FlowSpec-Filter auf einem Gerät zu aktivieren, müssen Sie die dscp-mapping-classifier Konfigurationsaussage auf der Hierarchieebene [edit forwarding-options family (inet | inet6)] hinzufügen:
forwarding-options {
family inet {
dscp-mapping-classifier ipv4-classifer;
}
family inet6 {
dscp-mapping-classifier ipv6-classifer;
}
}
Die folgende Beispielkonfiguration der Serviceklasse ordnet DSCP-Codepunkte der Weiterleitungsklasse und der Verlustpriorität zu:
class-of-service {
classifiers {
dscp dscp1 {
forwarding-class best-effort {
loss-priority low code-points 000000;
}
}
}
}
extended-community .