Auf dieser Seite
Beispiel: Konfigurieren von IPv6-BGP-Routen über IPv4-Transport
Verstehen der Neuverteilung von IPv4-Routen mit IPv6 Next Hop in BGP
Konfigurieren BGP zur Neuverteilung von IPv4-Routen mit IPv6-Next-Hop-Adressen
Informationen BGP Flussrouten für die Filterung von Datenverkehr
Beispiel: Konfigurieren BGP, um Routen zur IPv6-Datenstromspezifikation zu führen
Konfigurieren der BGP Datenstromspezifikation Aktion Weiterleitung an IP, um DDoS zu filtern
Multiprotocol BGP
Verstehen von Multiprotocol BGP
Multiprotocol BGP (MP-BGP) ist eine Erweiterung von BGP, die es BGP ermöglicht, Routinginformationen für mehrere Netzwerkschichten und Adressfamilien weiterzuleiten. MP-BGP können die unicastbasierten Routen für das Multicastrouting separat von den für die Unicast-IP-Weiterleitung verwendeten Routen übertragen.
Zur Aktivierung von MP-BGP konfigurieren Sie BGP, um NLRI (Network Layer Reachability Information) für andere Adressfamilien als Unicast IPv4 zu übertragen, indem Sie die Aussage family inet angeben:
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 die Übertragung von NLRI für die IPv6-Adressfamilie zu ermöglichen, müssen Sie die Aussage family inet6 beinhalten:
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; } }
Nur auf Routern ist eine Anweisung enthalten, BGP MP-BGP LAYER 3-NLRI (Virtual Private Network) für die IPv4-Adressfamilie family inet-vpn ermöglichen:
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 ist eine Anweisung enthalten, BGP MP-BGP Layer-3-VPN-NLRI für die IPv6-Adressfamilie family inet6-vpn ermöglichen:
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; } }
Nur auf Routern müssen MP-BGP Multicast-VPN-NLRI für die IPv4-Adressfamilie übertragen und VPN-Signalübertragung ermöglichen: 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 es MP-BGP zu ermöglichen, Multicast VPN NLRI für die IPv6-Adressfamilie zu übertragen und VPN-Signalübertragung zu ermöglichen, müssen Sie die Anweisung family inet6-mvpn beinhalten:
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 multiprotocol BGP-basierten Multicast-VPNs finden Sie im Benutzerhandbuch Junos OS Multicast Protocols.
Eine Liste von Hierarchieebenen, in denen Sie diese Anweisungen enthalten können, finden Sie in den Abschnitten mit einer Zusammenfassung der Anweisungen.
Wenn Sie die in der Hierarchieebene angegebene Adressfamilie ändern, werden alle aktuellen sitzungen BGP auf dem Routing-Gerät verworfen und [edit protocols bgp family] dann erneut installiert.
In Junos OS Version 9.6 und höher können Sie einen Schleifenwert für eine bestimmte Adressfamilie BGP angeben.
Standardmäßig übertragen BGP nur Unicast-Routen, die für Unicastweiterleitungszwecke verwendet werden. Geben Sie die BGP an, um peers zu konfigurieren, um nur Multicast-Routen multicast zu übertragen. Geben Sie die BGP an, um Peers zu konfigurieren, um Unicast- und Multicast-Routen zu any übertragen.
Wenn die MP-BGP konfiguriert ist, installiert BGP MP-BGP-Routen in verschiedenen Routing-Tabellen. Jede Routingtabelle wird durch den Protokollfamilien- oder Address Family Indicator (AFI) und einen nachfolgenden Address Family Identifier (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-Constrain
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, gekennzeichnetes IPv4
AFI=2, SAFI=4, gekennzeichneter IPv6 (6PE)
Routen, die in der Inet.2-Routingtabelle installiert sind, können nur in MP-BGP-Peers exportiert werden, da sie SAFI verwenden und sie als Routen zu Multicastquellen identifizieren. Routen, die in der Inet.0-Routingtabelle installiert sind, können nur in Standard-BGP exportiert werden.
Die inet.2-Routingtabelle sollte eine Untergruppe der Routen sein, die Sie inet.0 haben. Es ist unwahrscheinlich, dass Sie eine Route zu einer Multicastquelle haben, an die Sie keinen Unicast-Datenverkehr senden können. Die inet.2-Routingtabelle speichert die Unicast-Routen, die für Multicast Reverse Path Forwarding-Prüfungen verwendet werden, und die zusätzlichen Erreichbarkeitsinformationen, die MP-BGP von den NLRI-Multicast-Updates erhalten. Eine inet.2-Routingtabelle wird automatisch erstellt, wenn Sie MP-BGP konfigurieren (indem Sie NLRI auf any festlegen).
Wenn Sie MP-BGP aktivieren, können Sie Folgendes tun:
- Begrenzung der Anzahl von Präfixen, die in einer Peer BGP sitzung empfangen werden
- Begrenzung der Anzahl akzeptierter Präfixe in einer BGP-Peer-Sitzung
- Konfigurieren BGP Routing-Tabellengruppen
- Auflösen von Routen zu PE-Routinggeräten in anderen ASs
- Zulassen gekennzeichneter und nicht gekennzeichneter Routen
Begrenzung der Anzahl von Präfixen, die in einer Peer BGP sitzung empfangen werden
Sie können die Anzahl der Präfixe beschränken, die in einer Peer BGP sitzung empfangen werden, und nachrichten mit begrenzter Protokollrate protokollieren, wenn die Anzahl der eingeprägenen Präfixe eine Set-Limit überschreitet. Wenn die Anzahl von Präfixen die Grenze überschreitet, kann das Peering auch überschritten werden.
Um eine Begrenzung auf die Anzahl von Präfixen zu konfigurieren, die in einer Sitzung empfangen werden BGP, fügen Sie die Anweisung prefix-limit hinzu:
prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop-excess <percentage>; hide-excess <percentage>; }
Eine Liste von Hierarchieebenen, in denen Sie diese Aussage enthalten können, finden Sie im Abschnitt "Statement Summary" in dieser Anweisung.
Spezifizieren Sie einen Wert in einem Bereich zwischen maximum number 1 und 4,294,967,295. Wenn die angegebene maximale Anzahl von Präfixen überschritten wird, wird eine Systemprotokollnachricht gesendet.
Wenn Sie die Anweisung enthalten, wird die Sitzung bei Überschreitung der teardown maximalen Anzahl von Präfixen abgerissen. Wenn Sie einen Prozentwert angeben, werden Nachrichten protokolliert, wenn die Anzahl von Präfixen diesen Prozentsatz der angegebenen maximalen Begrenzung überschreitet. Nach dem Abbruch der Sitzung wird die Sitzung in kürzester Zeit erneut installiert (sofern Sie die Aussage idle-timeout nicht enthalten). Wenn Sie die Aussage angeben, kann die Sitzung für einen bestimmten Zeitraum idle-timeout oder für immer aufbewahrt werden. Wenn Sie einen Befehl angeben, wird die Sitzung erst nach der forever Eingabe eines Befehls neu clear bgp neighbor festgelegt. Wenn Sie die Anweisung angeben und einen Prozentwert angeben, werden die übermäßigen Routen fallen, wenn die Anzahl von drop-excess <percentage> Präfixen den Prozentsatz überschreitet. Wenn Sie die Anweisung angeben und einen Prozentwert angeben, bleiben die übermäßigen Routen verborgen, wenn die Anzahl von hide-excess <percentage> Präfixen den Prozentsatz überschreitet. Wird der Prozentsatz geändert, werden die Routen automatisch neu bewertet.
In Junos OS Version 9.2 und höher können Sie alternativ eine Begrenzung der Anzahl von Präfixen konfigurieren, die für eine Peer BGP sitzung akzeptiert werden können. Weitere Informationen finden Sie Begrenzung der Anzahl akzeptierter Präfixe in einer BGP-Peer-Sitzung unter.
Begrenzung der Anzahl akzeptierter Präfixe in einer BGP-Peer-Sitzung
In Junos OS Version 9.2 und höher können Sie die Anzahl von Präfixen beschränken, die in einer Peer-Sitzung BGP akzeptiert werden können. Wenn diese angegebene Begrenzung überschritten wird, wird eine Systemprotokollnachricht gesendet. Sie können auch angeben, die BGP-Sitzung zurückzusetzen, wenn die Anzahl der angegebenen Präfixe überschritten wird.
Um eine Begrenzung auf die Anzahl von Präfixen zu konfigurieren, die in einer Peer BGP sitzung akzeptiert werden können, müssen Sie die Anweisung accepted-prefix-limit hinzufügen:
accepted-prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop <percentage>; hide <percentage>; }
Eine Liste von Hierarchieebenen, in denen Sie diese Aussage enthalten können, finden Sie im Abschnitt "Statement Summary" in dieser Anweisung.
Spezifizieren Sie einen Wert in einem Bereich zwischen maximum number 1 und 4,294,967,295.
Geben Sie die Anweisung ein, um die BGP Peer-Sitzung zurückzusetzen, wenn die Anzahl akzeptierter teardown Präfixe die konfigurierte Begrenzung überschreitet. Sie können auch einen Prozentwert zwischen 1 und 100 angeben, damit eine Systemprotokollnachricht gesendet wird, wenn die Anzahl akzeptierter Präfixe diesen Prozentsatz der maximalen Begrenzung überschreitet. Standardmäßig wird eine BGP, die zurückgesetzt wird, innerhalb von kurzer Zeit wieder aktiviert. Fügen Sie die Anweisung ein, um zu verhindern, dass die sitzung für einen bestimmten Zeitraum erneut BGP idle-timeout wird. Sie können einen Timeout-Wert zwischen 1 und 2400 Minuten konfigurieren. Fügen Sie die Option ein, zu BGP, dass die Sitzung erneut hergestellt wird, bis Sie den forever Befehl clear bgp neighbor ausführen. Wenn Sie die Anweisung angeben und einen Prozentwert angeben, werden die übermäßigen Routen fallen, wenn die Anzahl von drop-excess <percentage> Präfixen den Prozentsatz überschreitet. Wenn Sie die Anweisung angeben und einen Prozentwert angeben, bleiben die übermäßigen Routen verborgen, wenn die Anzahl von hide-excess <percentage> Präfixen den Prozentsatz überschreitet. Wird der Prozentsatz geändert, werden die Routen automatisch neu bewertet.
Wenn Nonstop Active Routing (NSR) aktiviert ist und ein Switchover zu einer Backup-Routing-Engine startet, werden BGP deaktivierte Peers automatisch neu gestartet. Die Peers werden selbst dann neu gestartet, wenn die idle-timeout forever Anweisung konfiguriert ist.
Alternativ können Sie eine Begrenzung auf die Anzahl von Präfixen konfigurieren, die in einer Peer-Sitzung empfangen (statt akzeptiert) BGP können. Weitere Informationen finden Sie Begrenzung der Anzahl von Präfixen, die in einer Peer BGP sitzung empfangen werden unter.
Konfigurieren BGP Routing-Tabellengruppen
Wenn eine BGP Sitzung ein Unicast- oder Multicast-NLRI empfängt, wird die Route in der entsprechenden Tabelle ( oder für Unicast oder inet.0inet6.0 für inet.2inet6.2 Multicast) installiert. Um Unicast-Präfixe zu den Unicast- und Multicast-Tabellen hinzuzufügen, können Sie Routingtabellengruppen BGP konfigurieren. Dies ist nützlich, wenn Sie keine Multicast-NLRI-Aushandlung durchführen können.
Zum Konfigurieren BGP Routingtabellengruppen müssen Sie die Aussage rib-group beinhalten:
rib-group group-name;
Eine Liste von Hierarchieebenen, in denen Sie diese Aussage enthalten können, finden Sie im Abschnitt "Statement Summary" in dieser Anweisung.
Auflösen von Routen zu PE-Routinggeräten in anderen ASs
Zur Routenauflösung können gekennzeichnete Routen in die inet.3 Routingtabelle platziert werden. Diese Routen werden dann für die Provider Edge (PE)-Routinggeräteverbindungen gelöst, wenn sich die Remote-PE in einem anderen autonomen System befindet (AS. Damit ein PE-Routinggerät eine Route in der VPN Routing and Forwarding (VRF)-Routinginstanz installiert, muss der nächste Hop zu einer in der Tabelle gespeicherten Route inet.3 lösen.
Um Routen in die inet.3 Routing-Tabelle zu lösen, geben Sie die Anweisung resolve-vpn an:
resolve-vpn group-name;
Eine Liste von Hierarchieebenen, in denen Sie diese Aussage enthalten können, finden Sie im Abschnitt "Statement Summary" in dieser Anweisung.
Zulassen gekennzeichneter und nicht gekennzeichneter Routen
Sie können ermöglichen, dass gekennzeichnete und nicht gekennzeichnete Routen in einer Sitzung ausgetauscht werden. Die gekennzeichneten Routen werden in der Routingtabelle inet.3 oder inet6.3 platziert, und sowohl gekennzeichnete als auch nicht gekennzeichnete Unicast-Routen können vom Routinggerät gesendet oder empfangen werden.
Um den Austausch von gekennzeichneten und nicht gekennzeichneten Routen zu ermöglichen, müssen Sie die Aussage rib beinhalten:
rib (inet.3 | inet6.3);
Eine Liste von Hierarchieebenen, in denen Sie diese Aussage enthalten können, finden Sie im Abschnitt "Statement Summary" in dieser Anweisung.
Beispiel: Konfigurieren von IPv6-BGP-Routen über IPv4-Transport
In diesem Beispiel wird veranschaulicht, wie Sie IPv6- und IPv4-Präfixe über eine IPv4-Verbindung exportieren, bei der beide Seiten mit einer IPv4-Schnittstelle konfiguriert sind.
Anforderungen
Bevor Sie dieses Beispiel konfigurieren, ist keine besondere Konfiguration über die Gerätein initialisierung hinaus erforderlich.
Überblick
Beachten Sie beim Exportieren von IPv6-Präfixen folgende BGP:
BGP leitet Präfixe des nächsten Hops über das IPv4-zugeordnete IPv6-Präfix ab. So übersetzt das IPv4-Präfix im nächsten Hop beispielsweise das
10.19.1.1IPv6-Next-Hop-Präfix ::ffff:10.19.1.1.Anmerkung:Es muss eine aktive Route zum IPv4-zugeordneten IPv6-nächsten Hop geben, um IPv6-Präfixe BGP zu exportieren.
Eine IPv6-Verbindung muss über die Verbindung konfiguriert sein. Die Verbindung muss entweder ein IPv6-Tunnel oder eine Dual-Stack-Konfiguration sein. In diesem Beispiel wird Dual Stacking verwendet.
Verwenden Sie bei der Konfiguration von IPv4-zugeordneten IPv6-Präfixen eine Maske, die mehr als 96 Bits bietet.
Konfigurieren Sie eine statische Route, wenn Sie normale IPv6-Präfixe verwenden möchten. In diesem Beispiel wird statische Routen verwendet.
Abbildung 1 zeigt die Beispieltopologie an.
Konfiguration
CLI-Konfiguration
Um dieses Beispiel schnell konfigurieren zu können, kopieren Sie die folgenden Befehle, fügen Sie diese in eine Textdatei ein, entfernen Sie alle Zeilenbrüche, ändern Sie alle Details, die zur Übereinstimmung mit der Netzwerkkonfiguration erforderlich sind, und kopieren Sie die Befehle, und fügen Sie die Befehle CLI der Hierarchieebene [edit] ein.
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
Gerät konfigurieren R1
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zur Navigation in CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI Benutzerhandbuch.
So konfigurieren Sie Gerät 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
EBGP konfigurieren.
[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 BGP das Übertragen 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. Die Konfiguration wird hier als Vollständigkeit angezeigt.
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 autonome Systemnummer (AS).
[edit routing-options] user@R1# set autonomous-system 100
Ergebnisse
Bestätigen Sie Ihre Konfiguration im Konfigurationsmodus, indem Sie die show interfacesshow policy-options , und Befehle show protocolsshow routing-options eingeben. Wenn in der Ausgabe nicht die beabsichtigte Konfiguration angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@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 die Konfiguration des Geräts erledigt haben, geben Sie commit den Konfigurationsmodus ein. Wiederholen Sie die Konfiguration auf Gerät R2 und Geräte-R3 und ändern Sie schnittstellennamen und IP-Adressen nach Bedarf.
Überprüfung
Stellen Sie sicher, dass die Konfiguration ordnungsgemäß funktioniert.
Nachbarstatus prüfen
Zweck
Stellen Sie sicher, BGP IPv6-Unicast-Routen übertragen kann.
Aktion
Geben Sie im Betriebsmodus den Befehl show bgp neighbor 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 Vorfälle in der Ausgabe zeigen, dass BGP inet6-unicast IPv6-Unicast-Routen übertragen kann.
Prüfen der Routing-Tabelle
Zweck
Stellen Sie sicher, dass Gerät R2 über BGP in der inet6.0-Routingtabelle verfügt.
Aktion
Geben Sie im Betriebsmodus den Befehl show route protocol bgp inet6.0 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.2Advertising IPv4 Routes over BGP IPv6 Sessions Overview
In einem IPv6-Netzwerk gibt BGP in der Regel Informationen zur Erreichbarkeit der Netzwerkebene von IPv6 über eine IPv6-Sitzung zwischen BGP an. In früheren Versionen Junos OS nur den Austausch der Unicast-, Inet6-Multicast- oder inet6-Unicast-Adressfamilien unterstützt. Diese Funktion ermöglicht den Austausch aller Adressfamilien BGP Adressfamilien. In einer Dual-Stack-Umgebung mit IPv6 im Core. mit dieser Funktion BGP IPv4-Unicast-Erreichbarkeit mit IPv4-Next Hop über eine IPv6-BGP erhöhen.
Diese Funktion ist nur BGP IPv6-Sitzungen verwendet, in denen IPv4 an beiden Endgeräten konfiguriert ist. Dies local-ipv4-address kann eine Loopback-Adresse oder eine beliebige IPV4-Adresse für eine IBGP- oder Multiple-Hop-EBGP-Sitzung sein. Bei externen Single-Hop-BGP-Sprechern, die nicht zu BGP Confederations gehören, wird die BGP-Sitzung geschlossen und bleibt leer. Ein Fehler wird generiert, wenn die konfigurierte lokale IPv4-Adresse nicht direkt miteinander verbunden show bgp neighbor ist.
Um die IPv4-Routen-Werbung über IPv6-Sitzung zu aktivieren, konfigurieren Sie local-ipv4-address folgendes:
[edit protocols bgp family inet unicast] local-ipv4-address local ipv4 address;
Sie können diese Funktion nicht für die Unicast-, Inet6-Multicast- oder Inet6-Unicast-Adressfamilien mit inet6-Bezeichnung konfigurieren, da BGP diese Adressfamilien bereits über eine IPv6-BGP-Sitzung anzeigen kann.
Die konfigurierte local-ipv4-address wird nur verwendet, wenn BGP Routen mit Self-Next-Hop ausspricht. Wenn IBGP von EBGP-Peers erlernte Routen anknüpft oder der Route Reflector BGP-Routen zu seinen Clients anknüpft, ändert BGP die Route nicht im nächsten Hop, ignoriert die konfigurierten und verwendet den ursprünglichen local-ipv4-address IPv4-Next-Hop.
Siehe auch
Beispiel: IPv4-Routen über IPv6-BGP-Sitzungen anzeigen
In diesem Beispiel wird gezeigt, wie Sie IPv4-Routen über IPv6-BGP anzeigen. In einer Dual-Stack-Umgebung mit IPv6 im Core müssen Remote-IPv4-Hosts erreicht werden. Daher gibt BGP IPv4-Routen mit IPv4-Next-Hops an, um BGP-Peers über BGP-Sitzungen mit IPv6-Quell- und Zieladressen zu führen. Mit dieser Funktion BGP IPv4-Unicast-Erreichbarkeit mit IPv4-Next Hop-over-IPv6-BGP angekündigt.
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 aktivieren, sollten Sie sicher sein:
Konfigurieren Sie die Geräteschnittstellen.
Konfigurieren Sie Dual Stacking auf allen Geräten.
Überblick
Ab Version 16.1 ermöglicht Junos OS, BGP IPv4-Unicast-Erreichbarkeit mit dem IPv4-nächsten Hop über eine IPv6-BGP-Sitzung zu werben. In früheren Junos OS Versionen konnte BGP nur Unicast-, Inet6-Multicast- und inet6-Unicast-Adressfamilien über IPv6-BGP anzeigen. Mit dieser Funktion BGP alle Adressfamilien BGP IPv6-Sitzung austauschen. Sie können es BGP, IPv4-Routen mit IPv4-Next-Hops zu BGP über IPv6-Sitzung ausspricht. Die konfigurierte local-ipv4-address wird nur verwendet, wenn BGP Routen mit Self-Next-Hop ausspricht.
Sie können diese Funktion nicht für die Unicast-, Inet6-Multicast- oder Inet6-Unicast-Adressfamilien mit inet6-Bezeichnung konfigurieren, da BGP diese Adressfamilien bereits über eine IPv6-BGP-Sitzung anzeigen kann.
Topologie
In Abbildung 2 wird eine externe IPv6 BGP sitzung zwischen den Routern R1 und R2 ausgeführt. Eine IPv6 IBGP-Sitzung wird zwischen Router R2 und Router R3 eingerichtet. IPv4-statische Routen werden an den Paket-BGP von R1 neu verteilt. Um die IPv4-Routen über die IPv6-BGP neu zu verteilen, muss die neue Funktion auf allen Routern in der [edit protocols bgp address family] Hierarchieebene aktiviert sein.
Konfiguration
CLI-Konfiguration
Um dieses Beispiel schnell konfigurieren zu können, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenbrüche, ändern Sie alle Details, die zur Übereinstimmung mit Ihrer Netzwerkkonfiguration erforderlich sind, kopieren Sie die Befehle, kopieren Sie die Befehle in die CLI der Hierarchieebene, und geben Sie sie dann im Konfigurationsmodus [edit]commit ein.
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
Konfigurieren des Routers R1
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zur Navigation auf der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI Benutzerhandbuch.
So konfigurieren Sie Router R1:
Wiederholen Sie dieses Verfahren für andere Router, nachdem Sie die entsprechenden Schnittstellennamen, Adressen und anderen 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 ausgeschrieben 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
EbGP auf den externen Edge-Routern konfigurieren.
[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
Ermöglichen Sie die Ankündigung von IPv4-Adddress 140.1.1.1.1 über BGP IPv6-Sitzungen.
[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, um alle statischen Routen zu akzeptieren.
[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 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 interfacesshow protocols , und Befehle show routing-optionsshow policy-options eingeben. Wenn in der Ausgabe nicht die beabsichtigte Konfiguration 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 die Konfiguration des Geräts bereits durchgeführt haben, commit die Konfiguration.
user@R1# commit
Überprüfung
Stellen Sie sicher, dass die Konfiguration ordnungsgemäß funktioniert.
- Sicherstellen, dass die BGP Sitzung eingerichtet ist
- Bestätigung, dass die IPv4-Adresse ausgeschrieben wurde
- Sicherstellen, dass der BGP Neighbor-Router R2 die angekündigte IPv4-Adresse empfängt
Sicherstellen, dass die BGP Sitzung eingerichtet ist
Zweck
Stellen Sie sicher, BGP auf den konfigurierten Schnittstellen ausgeführt wird und dass die BGP-Sitzung für die einzelnen Nachbaradressen aktiv ist.
Aktion
Führen Sie im Betriebsmodus den Befehl show bgp summary 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 ist und wird ausgeführt und BGP peering eingerichtet.
Bestätigung, dass die IPv4-Adresse ausgeschrieben wurde
Zweck
Stellen Sie sicher, dass die konfigurierte IPv4-Adresse von Router R1 den konfigurierten Nachbarn BGP wird.
Aktion
Führen Sie im Betriebsmodus den Befehl show route advertising-protocol bgp ::150.1.1.2 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 Benachbarten BGP router R2 angekündigt.
Sicherstellen, dass 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 für den BGP nachbar über IPv6 ank
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, dass sie die angekündigten IPv4-Routen von Router R1 empfängt.
Verstehen der Neuverteilung von IPv4-Routen mit IPv6 Next Hop in BGP
In einem Netzwerk, das hauptsächlich IPv6-Datenverkehr über transportiert, ist bei Bedarf das Routen von IPv4-Routen erforderlich. Ein Internet-Service Provider beispielsweise, das ein IPv6-Netzwerk besitzt, aber weiterhin Kunden besitzt, die noch IPv4-Datenverkehr routen. In diesem Fall ist es erforderlich, diesen Kunden zu bedienen und den IPv4-Datenverkehr über ein IPv6-Netzwerk weiter zu geben. Wie in RFC 5549 beschrieben, werden Informationen zur IPv4-Netzwerkschicht-Erreichbarkeit mit einem IPv6 Next Hop IPv4-Datenverkehr von Customer Premises Equipment (CPE)-Geräten zu IPv4-over-IPv6-Gateways tunnelt. Diese Gateways werden CPE-Geräten über Anycast-Adressen bekannt gegeben. Die Gateway-Geräte erstellen dann dynamische IPv4-over-IPv6-Tunnel zu Remote-CPE-Geräten und geben IPv4-aggregierte Routen an, um den Datenverkehr zu lenken.
Die dynamische IPv4-over-IPv6-Tunnel-Funktion unterstützt die einheitliche ISSU in einem Junos OS Release 17.3R1.
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 ein einzuordnen. Die Gateway-Router erzeugen dynamische IPv4-over-IPv6-Tunnel zum Remote-Provider-Edge des Kunden. Der Gateway-Router gibt auch die aggregierten IPv4-Routen an, um den Datenverkehr zu lenken. Der RR gibt dann die Tunnel-Quellrouten zum ISP aus. Wenn der RR die Tunnelroute entfernt, zieht BGP auch die Route zurück, wodurch der Tunnel abgerissen und das CPE unerreicht ist. Der Gateway-Router entfernt auch die aggregierten IPv4-Routen und IPv6-Tunnel-Quellrouten, wenn alle aggregierten Routen Routen mitwirkende Routen entfernt werden. Der Gateway-Router sendet die Route "Withdraw", wenn die Packet Forwarding Engine Linecard abgeht und leitet den Datenverkehr so an andere Gateway-Router weiter.
Es werden die folgenden Erweiterungen eingeführt, um IPv4-Routen mit einem IPv6-Next Hop zu unterstützen:
- BGP-Next-Hop-Kodierung
- Tunnel-Lokalisierung
- Tunnelbehandlung
- Tunnel Load Balancing und Anker Packet Forwarding Engine Umgang mit Ausfällen
- Tunnel-Loopback-Stream-Statistiken
BGP-Next-Hop-Kodierung
BGP wird mit Next Hop-Kodierungsfunktion erweitert, die zum Senden von IPv4-Routen mit IPv6-Next-Hops verwendet wird. Wenn diese Funktion auf dem Remote-Peer nicht verfügbar ist, gruppent BGP die Peers anhand dieser Kodierungsfunktion und entfernt die BGP-Produktfamilie ohne Kodierungsfunktionen aus der ausgehandelten NLRI-Liste (Network Layer Reachability Information). Junos OS nur eine Lösungstabelle wie inet.0. Um IPv4-BGP-Routen mit IPv6-Next-Hops zu ermöglichen, BGP einen neuen Auflösungsstruktur erstellt. Mit dieser Funktion kann eine Junos OS Routing-Tabelle zu mehreren Auflösungsbäumen erstellen.
Neben RFC 5549, Advertising IPv4 Netzwerkschicht Reachability Information with an IPv6 Next Hop wird eine neue Encapsulation Community gemäß RFC 5512, die BGP Encapsulation Subsequent Address Family Identifier (SAFI) und das BGP Tunnel Encapsulation Attribute eingeführt, um die Adressfamilie der Next-Hop-Adresse zu bestimmen. Die Kapselungs-Community gibt die Art der Tunnel an, die der Ingress-Node erstellen muss. Wenn BGP IPv4-Routen mit IPv6-Next Hop-Adresse und der V4oV6-Einkapselungs-Community empfängt, erstellt BGP dynamische IPv4-over-IPv6-Tunnel. Wenn BGP Routen ohne die Kapselungs-Community empfängt, werden BGP ohne den V4oV6-Tunnel gelöst.
In der Hierarchieebene ist eine neue Richtlinienaktion verfügbar, um die neue erweiterte dynamic-tunnel-attributes dyan-attribute[edit policy-statement policy name term then] Einkapselung zu unterstützen.
Tunnel-Lokalisierung
Die dynamische Tunnelinfrastruktur wird durch Tunnel-Lokalisierung erweitert, um eine größere Anzahl von Tunneln zu unterstützen. Tunnel-Lokalisierungen müssen auch bei Ausfallsicherheit für den Datenverkehr sorgen, wenn der Anker ausfällt. Ein oder mehrere Gehäuse werden miteinander gesichert, und der Routingprotokollprozess (RPD) lenken den Datenverkehr weg vom Fehlerpunkt zum Backup-Chassis. Das Gehäuse gibt nur diese aggregierten Präfixe anstelle der einzelnen Loopback-Adressen im Netzwerk an.
Tunnelbehandlung
IPv4-over-IPv6-Tunnel nutzen die dynamische Tunnelinfrastruktur zusammen mit Tunnelankerung zur Unterstützung der erforderlichen chassisweiten Skalierung. Der Tunnelstatus wird zu einem Bestimmten Packet Forwarding Engine und die anderen Packet Forwarding Engines lenken den Datenverkehr zum Tunnel-Anker.
Tunnel-Ingress
Verkapselt IPv4-Datenverkehr innerhalb des IPv6-Headers.
Die Erzwingung MTU Maximum Transmission Unit (MTU) wird vor der Einkapselung durchgeführt. Wenn die verkapselte Paketgröße den Tunnel-Wert MTU und das IPv4-Paket nicht festgelegt wird, wird das Paket fragmentiert und diese Fragmente
DF-bitverkapselt.Verwendet hashbasiertes Traffic Load Balancing auf inneren Paket-Headern.
Weitergeleitet Datenverkehr an die IPv6-Zieladresse. Die IPv6-Adresse wird aus dem IPv6-Header übernommen.
Tunnel-Ausgangs-;
Entkapselt das im IPv6-Paket enthaltene IPv4-Paket.
Führt eine Anti-Spoof-Prüfung durch, um sicherzustellen, dass das IPv6-, IPv4-Paar mit den Informationen entspricht, die für die Einrichtung des Tunnels verwendet wurden.
Aus dem IPv4-Header des entkapselten Pakets wird die IPv4-Zieladresse angezeigt, und das Paket wird an die angegebene IPv4-Adresse weitergeleitet.
Tunnel Load Balancing und Anker Packet Forwarding Engine Umgang mit Ausfällen
Die Packet Forwarding Engine Fehler muss umgehend behandelt werden, um die Null-Route-Filterung des auf dem Netzwerk ankerten Tunneldatenverkehrs zu Packet Forwarding Engine. Bei der Tunnel-Übersetzung müssen BGP ins BGP, um Fehler global zu reparieren. Der Tunneldatenverkehr wird vom Fehlerpunkt weg an ein anderes Sicherungsgehäuse umgeleitet, das den identischen Tunnelstatus enthält. Beim Load Balancing des Datenverkehrs ist das Gehäuse so konfiguriert, dass für jedes Präfix unterschiedliche Exit Discriminator (MED)-Werte angekündigt werden, sodass nur der Datenverkehr für ein Viertel der Tunnel durch jedes Gehäuse fließt. Der CPE-Datenverkehr wird ebenfalls auf ähnliche Weise verarbeitet, indem auf jedem Gehäuse dieselben Anycast-Adressen konfiguriert werden und nur ein Viertel des Datenverkehrs zu jedem Gehäuse lenken wird.
Anker Packet Forwarding Engine ist die einzige Einheit, die alle Verarbeitungen für einen Tunnel übernimmt. Der Ankerpunkt Packet Forwarding Engine die statische Bereitstellung und ist an die physischen Packet Forwarding Engine gebunden. Wenn eine der Packet Forwarding Engines aus geht, markiert der Daemon alle Packet Forwarding Engines auf der Linecard und kommuniziert diese Informationen an den Routingprotokollprozess und andere Daemons. Der Routingprotokollprozess sendet BGP Beanhebungen der Präfixe, die auf der fehlerhaften Packet Forwarding Engine und den dem ausgefallenen Paket zugewiesenen IPv6-Adressen Packet Forwarding Engine sind. Diese Werbung routet Den Datenverkehr an ein anderes Backup-Chassis. Wenn die fehlerhafte Packet Forwarding Engine erneut verfügbar ist, markiert das Gehäuse den Routingprotokollprozess als Packet Forwarding Engine und up aktualisiert den Routingprotokollprozess. Der Routingprotokollprozess löst BGP-Aktualisierungen für seine Peers aus, die Tunnel, die mit dem spezifischen Protokoll verankert sind Packet Forwarding Engine jetzt für das Routing von Datenverkehr verfügbar sind. Dieser Vorgang kann für eine Tunnelkonfiguration im großen Rahmen Minuten dauern. Daher ist der Mechanismus in das System integriert, um minimalen Datenverkehrsverlust zu gewährleisten und den Datenverkehr wieder auf Ack das originale Gehäuse umschalten zu können.
Tunnel-Loopback-Stream-Statistiken
Die dynamische Tunnel-Infrastruktur nutzt Loopback-Streams in Packet Forwarding Engine die Paketschleife nach der Kapselung. Da die Bandbreite dieses Loopback-Streams begrenzt ist, muss die Leistung von Tunnel-Loopback-Streams überwacht werden.
Verwenden Sie zur Überwachung der Statistiken des Loopback-Streams den operativen Befehl, der die aggregierten Loopback-Stream-Statistiken einschließlich Weiterleitungsrate, Drop-Packet-Rate und show pfe statistics traffic detail Byterate anzeigt.
Siehe auch
Konfigurieren BGP zur Neuverteilung von IPv4-Routen mit IPv6-Next-Hop-Adressen
Ab Version 17.3R1 können Junos OS IPv4-Datenverkehr über ein IPv6-nur-Netzwerk weitergeleitet werden, das IPv4-Datenverkehr generell nicht weiter geben kann. Wie in RFC 5549 beschrieben, wird der IPv4-Datenverkehr von CPE-Geräten in IPv4-over-IPv6-Gateways tunnelt. Diese Gateways werden CPE-Geräten über Anycast-Adressen bekannt gegeben. Die Gateway-Geräte erstellen dann dynamische IPv4-over-IPv6-Tunnel zu Remote-Geräten am Kundenstandort und geben IPv4-aggregierte Routen an, um den Datenverkehr zu lenken. Route Reflectors mit programmierbaren Schnittstellen injizieren die Tunnelinformationen in das Netzwerk. Die Routenreflektoren sind über IBGP mit Gateway-Routern verbunden, die die IPv4-Adressen von Host-Routen als nächsten Hop mit IPv6-Adressen anzeigen.
Die dynamische IPv4-over-IPv6-Tunnel-Funktion unterstützt die einheitliche ISSU in einem Junos OS Release 17.3R1.
Bevor Sie mit der Konfiguration BGP, um IPv4-Routen mit IPv6-Next-Hop-Adressen zu verteilen, gehen Sie wie folgt vor:
Konfigurieren Sie die Geräteschnittstellen.
Konfigurieren OSPF oder eines anderen IGP Protokolls.
Konfiguration MPLS LDP.
Konfiguration BGP.
Zur Konfiguration BGP die Verteilung von IPv4-Routen mit IPv6-Next-Hop-Adressen:
Siehe auch
Ermöglichen der Layer-2-VPN- und VPLS-Signalübertragung
Sie können aktivieren, BGP Layer-2-VPN- und VPLS-NLRI-Nachrichten enthalten.
Zur Aktivierung der VPN- und VPLS-Signalübertragung müssen Sie die Anweisung family beinhalten:
family { l2vpn { signaling { prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop-excess <percentage>; hide-excess <percentage>; } } } }
Eine Liste von Hierarchieebenen, in denen Sie diese Aussage enthalten können, finden Sie im Abschnitt "Statement Summary" in dieser Anweisung.
Um eine maximale Anzahl von Präfixen zu konfigurieren, fügen Sie die Anweisung prefix-limit hinzu:
prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop-excess <percentage>; hide-excess <percentage>;}
Eine Liste von Hierarchieebenen, in denen Sie diese Aussage enthalten können, finden Sie im Abschnitt "Statement Summary" in dieser Anweisung.
Wenn Sie die maximale Anzahl von Präfixen festlegen, wird eine Nachricht protokolliert, wenn diese Nummer erreicht wird. Wenn Sie die Anweisung enthalten, wird die Sitzung bei erreichen der maximalen Anzahl teardown von Präfixen abgerissen. Wenn Sie einen Prozentwert angeben, werden Nachrichten protokolliert, wenn die Anzahl von Präfixen diesen Prozentsatz erreicht. Sobald die Sitzung abgerissen ist, wird sie in kürzester Zeit wiederhergestellt. Fügen Sie die Anweisung mit ein, um die Sitzung für einen bestimmten Zeitraum oder idle-timeout für immer beendet zu halten. Wenn Sie einen Angegebenen angeben, wird die Sitzung erst wieder installiert, forever nachdem Sie den Befehl verwendet clear bgp neighbor haben. Wenn Sie die Anweisung angeben und einen Prozentwert angeben, werden die übermäßigen Routen fallen, wenn die Anzahl von drop-excess <percentage> Präfixen den Prozentsatz überschreitet. Wenn Sie die Anweisung angeben und einen Prozentwert angeben, bleiben die übermäßigen Routen verborgen, wenn die Anzahl von hide-excess <percentage> Präfixen den Prozentsatz überschreitet. Wird der Prozentsatz geändert, werden die Routen automatisch neu bewertet.
Siehe auch
Informationen BGP Flussrouten für die Filterung von Datenverkehr
Eine Flussroute ist eine Aggregation von Bedingungen für IP-Pakete. Datenstromrouten werden über das Netzwerk mit NLRI-Nachrichten (Network Layer Reachability Information) zur Flussspezifikation verbreitet und in der Fluss-Routing-Tabelle instance-name.inetflow.0 installiert. Pakete können nur dann über Datenflussrouten übertragen werden, wenn bestimmte Bedingungen erfüllt sind.
Datenstromrouten und Firewall-Filter sind ähnlich, da sie Pakete basierend auf ihren Komponenten filtern und auf den jeweiligen Paketen eine Aktion ausführen. Flussrouten bieten Datenverkehrsfilterung und Funktionen zur Begrenzung der Datendurchsatzrate, z. B. Firewall-Filter. Außerdem können Sie Datenstromrouten in verschiedenen autonomen Systemen weiter nutzen.
Datenstromrouten werden durch BGP NLRI-Nachrichten mit Datenstromspezifikation verbreitet. Sie müssen es BGP ermöglichen, diese NLRIs weiter zu nutzen.
Beginnend mit Junos OS Version 15.1, werden Änderungen implementiert, um die Unterstützung von nonstop Active Routing (NSR) für vorhandene 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 Erweiterung werden zwei neue Aussagen eingeführt. Siehe Enforce-first-as-und no-install.
Beginnend mit Junos OS Version 16.1 wird die IPv6-Unterstützung auf die BGP Flow-Spezifikation erweitert, die die Verbreitung der Regeln zur Spezifikation des Datenverkehrsflusses für IPv6- und VPN-IPv6-Pakete ermöglicht. BGP-Datenflussspezifikation automatisiert die Koordination von Filterregeln für den Datenverkehr, um Distributed-Denial-of-Service-Angriff während nonstop Active Routing (NSR) zu reduzieren.
Beginnend mit Junos OS Release 16.1R1 unterstützt BGP Datenstromspezifikation die Filterung des extended-community Datenverkehrs. Für den IPv4-Datenverkehr ändert Junos OS die DiffServ Code Point (DSCP)-Bits eines Transit-IPv4-Pakets an den entsprechenden Wert der erweiterten Community. Für IPv6-Pakete ändert Junos OS die ersten sechs Bits des Feldes des übertragenden IPv6-Pakets an den entsprechenden Wert der erweiterten traffic class Community.
Beginnend mit cRPD Release 20.3R1, werden Flussrouten und Richtlinienregeln, die über die BGP-Datenflussspezifikation verbreitet werden, NLRI über Linux Netfilter Framework auf einem Linux Netfilter Framework in cRPD-Umgebungen heruntergeladen.
- Bedingungen für Datenstromrouten erfüllen
- Aktionen für Datenstromrouten
- Validierung von Datenstromrouten
- Unterstützung für BGP-Algorithmus der Datenstromspezifikation, Version 7 und höher
Bedingungen für Datenstromrouten erfüllen
Sie legen die Bedingungen fest, die dem Paket übereinstimmen müssen, bevor die Aktion in der Anweisung then für eine Datenflussroute ergriffen wird. Alle Bedingungen in from der Erklärung müssen mit der zu ergreifenden Aktion übereinstimmen. Die Reihenfolge, in der Sie die Übereinstimmungsbedingungen angeben, ist nicht wichtig, da ein Paket allen Bedingungen in einem Begriff für eine Übereinstimmung übereinstimmen muss.
Um eine Übereinstimmungsbedingung zu konfigurieren, fügen Sie die match Anweisung auf der [edit routing-options flow] Hierarchieebene ein.
Tabelle 1 beschreibt die Bedingungen für die Flow Route-Übereinstimmung.
Bedingungen erfüllen |
Beschreibung |
|---|---|
|
IP-Zieladressenfeld. Sie können das optionale Feld (das nur auf Junos-Geräten mit erweiterten MPCs ist, die für den Modus konfiguriert sind) verwenden, um die Anzahl der Bits anzugeben, die übersprungen werden müssen, bevor Junos OS entsprechend einem |
|
TCP- oder User Datagram Protocol (UDP)-Ziel-Portfeld. Sie können nicht sowohl die Sie können an der Stelle des numerischen Werts eines der folgenden Text Synonyme angeben (die Portnummern sind ebenfalls aufgelistet): |
|
Differentiated Services Code Point (DSCP). Das DiffServ-Protokoll verwendet das Art-of-Service-Byte (ToS) im IP-Header. Die wichtigsten sechs Bits dieses Byte bilden das DSCP. Sie können DSCP in Hexadezimal- oder Dezimalform angeben. |
|
Dem Label-Wert des Datenflusses übereinstimmen. Der Wert dieses Feldes reicht von 0 bis 1048575. Diese Bedingungen werden nur auf Junos-Geräten mit erweiterten MPCs unterstützt, die für den Modus konfiguriert |
|
Feld zum Fragmenttyp. Die Keywords werden nach dem zugehörigen Fragmenttyp gruppierungen:
Diese Bedingungen werden nur auf Junos OS mit erweiterten MPCs unterstützt, die für den Modus konfiguriert |
|
ICMP-Codefeld. Dieser Wert bzw. dieses Schlüsselwort bietet spezifischere Informationen als Sie können an der Stelle des numerischen Werts eines der folgenden Text synonyme angeben (die Feldwerte sind ebenfalls aufgeführt). Die Keywords werden nach dem zugehörigen ICMP-Typ gruppierungen:
|
|
Feld für ICMP-Pakettyp. Normalerweise geben Sie diese Übereinstimmung zusammen mit der Übereinstimmungsauszug an, um zu bestimmen, welches Protokoll Sie können an der Stelle des numerischen Werts eines der folgenden Text synonyme angeben (die Feldwerte sind ebenfalls aufgelistet): |
|
IP-Paketlänge gesamt. |
|
TCP- oder UDP-Quell- oder Ziel-Portfeld. Sie können nicht sowohl die Sie können eines der unter . |
|
IP-Protokollfeld. Sie können an der Stelle des numerischen Werts eines der folgenden Text synonyme angeben (die Feldwerte sind ebenfalls aufgelistet): Diese Übereinstimmungsbedingung wird nur auf Junos-Geräten mit erweiterten MPCs, die für den Modus konfiguriert sind, für IPv6 |
|
IP-Quelladressenfeld Sie können das optionale Feld (das nur auf Junos-Geräten mit erweiterten MPCs ist, die für den Modus konfiguriert sind) verwenden, um die Anzahl der Bits anzugeben, die übersprungen werden müssen, bevor Junos OS entsprechend einem |
|
TCP- oder UDP-Quell-Portfeld. Sie können nicht die Sie können eines der unter . |
|
TCP-Headerformat. |
Aktionen für Datenstromrouten
Sie können die Aktion angeben, die ergreifen soll, wenn das Paket den Bedingungen entspricht, die Sie in der Datenflussroute konfiguriert haben. Um eine Aktion zu konfigurieren, fügen Sie die then Anweisung auf der [edit routing-options flow] Hierarchieebene ein.
Tabelle 2 beschreibt die Maßnahmen für Datenstromrouten.
Aktions- oder Aktionsmodfikator |
Beschreibung |
|---|---|
| Aktionen | |
|
Akzeptieren Sie ein Paket. Das ist der Standard. |
|
Verwerfen Sie ein Paket unbedringt, ohne eine ICMP-Nachricht (Internet Control Message Protocol) zu senden. |
|
Ersetzen Sie alle Communitys in der Route durch die angegebenen Communitys. |
Kennzeichnungswert |
Legen Sie einen DSCP-Wert für Datenverkehr fest, der diesem Datenfluss entspricht. Einen Wert von 0 bis 63 angeben. Diese Aktion wird nur auf Junos-Geräten mit erweiterten MPCs unterstützt, die für den Modus konfiguriert |
|
Gehen Sie mit der nächsten Bedingungen zur Bewertung weiter. |
|
Geben Sie eine Routinginstanz an, an die Pakete weitergeleitet werden. |
|
Die Bandbreite der Datenflussroute einschränken. Die Begrenzung in Bits pro Sekunde (Bps) ausdrücken. Der Veröffentlichungsgrenzbereich Junos OS 16.1R4 1000000 ist [0 bis 10000000]. |
|
Mustern Sie den Datenverkehr der Datenstromroute. |
Validierung von Datenstromrouten
Das Junos OS installiert Datenstromrouten nur dann in die Fluss-Routing-Tabelle, wenn sie mithilfe des Validierungsverfahren validiert wurden. Der Routing-Engine führt die Validierung vor der Installation von Routen in die Fluss-Routing-Tabelle durch.
Datenflussrouten, die mithilfe BGP NLRI-Nachrichten (Network Layer Reachability Information) empfangen werden, werden vor ihrer Installation in der primären Datenfluss-Routingtabelle instance.inetflow.0 validiert. Das Validierungsverfahren wird im draft-ietf-idr-flow-spec-09.txt, Der Eindringungsvorgang für die Spezifikation von Datenflüssen beschrieben. Sie können den Validierungsprozess für Datenstromrouten mithilfe BGP NLRI-Nachrichten umgehen und Ihre eigene spezielle Importrichtlinie verwenden.
Um die Validierungsvorgänge nachverfolgungen zu können, fügen Sie die validation Aussage auf der [edit routing-options flow] Hierarchieebene ein.
Unterstützung für BGP-Algorithmus der Datenstromspezifikation, Version 7 und höher
Standardmäßig verwendet Junos OS den Algorithmus zur Anordnung von Begriffen, definiert in Version 6 der BGP Flussspezifikationsentwurf. In Junos OS Version 10.0 und höher können Sie den Router so konfigurieren, dass er dem Algorithmus zur Anordnung von Begriffen entspricht, der zuerst in Version 7 der BGP-Datenflussspezifikation definiert ist und durch RFC 5575, Verbreitungvon Routen zur Datenflussspezifikation unterstützt wird.
Es wird empfohlen, den Junos OS zu konfigurieren, um den Algorithmus für die Bestellung von Begriffen zu verwenden, der zuerst in Version 7 der BGP-Datenflussspezifikation definiert wurde. Außerdem empfehlen wir Ihnen, die Konfiguration Junos OS denselben Algorithmus für die Bestellung von Begriffen in allen auf einem Router konfigurierten Routinginstanzen zu verwenden.
Um die BGP, den Algorithmus der Datenstromspezifikation zu verwenden, der zuerst in Version 7 des Internet-Entwurfs definiert wurde, fügen Sie die Anweisung standard auf der [edit routing-options flow term-order] Hierarchieebene ein.
Um den in Version 6 definierten Algorithmus für die Begriffsordnung wieder verwenden zu können, fügen Sie die legacy Anweisung auf der [edit routing-options flow term-order] Hierarchieebene ein.
Die konfigurierte Begriffsordnung hat nur lokale Bedeutung. Das heißt, der Begriffsauftrag wird nicht mit Flussrouten weitergeschickt, die an Remote-BGP-Peers gesendet werden, deren Laufzeitauftrag vollständig durch ihre terme Auftragskonfiguration bestimmt wird. Daher sollten Sie bei der Konfiguration der auftragsabhängigen Aktion sorgfältig darauf achten, dass Ihnen die Begriffskonfiguration der Remote-Peers nicht next term bekannt ist. Das lokale next term Netzwerk unterscheidet sich möglicherweise next term von den Konfigurationen auf dem Remote-Peer.
Auf Junos OS Weiterentwickelt, next term kann nicht als letzter Ausdruck der Aktion erscheinen. Ein Filterbegriff, der als Aktion festgelegt wird, aber ohne die Konfiguration von Übereinstimmungsbedingungen next term wird nicht unterstützt.
Ab Version Junos OS 16.1 haben Sie die Option, den Filter auf Datenverkehr, der an bestimmten Schnittstellen flowspec empfangen wird, nicht anzuwenden. Ein neuer Begriff wird am Anfang des Filters hinzugefügt, der alle an diesen Schnittstellen flowspec empfangenen Pakete akzeptiert. Der neue Begriff ist eine Variable, die eine Ausschlussliste von Begriffen erstellt, die als Teil des Filterns der Datenstromspezifikation an den Filter der Weiterleitungstabelle angehängt werden.
Um den Filter auf Datenverkehr, der an bestimmten Schnittstellen empfangen wird, auszuschließen, müssen Sie zunächst eine Anweisung für eine Filtergruppe der Familie auf der Hierarchieebene konfigurieren und diesen Dann mit der Schnittstellengruppe anfügen, indem Sie die Anweisung auf der Hierarchieebene flowspecgroup-id einkreisen. inetgroup-id[edit interfaces]flowspecflow interface-group group-id exclude[edit routing-options] Mit der Anweisung können Sie nur eine group-id Routinginstanz set routing-options flow interface-group group-id konfigurieren.
Siehe auch
Beispiel: So können BGP Routen mit Datenstromspezifikation
In diesem Beispiel wird gezeigt, wie BGP NLRI-Nachrichten (Flow-Specification Network Layer Reachability Information) enthalten können.
Anforderungen
Bevor Sie beginnen:
Konfigurieren Sie die Geräteschnittstellen.
Konfigurieren Sie ein Interior Gateway Protocol (IGP).
Konfiguration BGP.
Konfigurieren Sie eine Routing-Richtlinie, die Routen (z. B. Direktrouten oder IGP Routen) von der Routing-Tabelle in eine BGP.
Überblick
Die Propagierung von Firewall-Filterdaten als Teil der BGP ermöglicht Ihnen die dynamische Und weitervermehrung von Firewall-Filtern gegen Denial-of-Service-Angriffe (DOS) über autonome Systeme hinweg. Datenflussrouten werden in die NLRI mit Flussspezifikation eingekapselt und über ein Netzwerk oder virtuelle private Netzwerke (VPNs) propagiert, um Informationen wie Filter zu teilen. Flussrouten sind eine Aggregation von Übereinstimmungsbedingungen und daraus resultierende Aktionen für Pakete. Sie bieten Ihnen Funktionen zur Filterung des Datenverkehrs und zur Begrenzung der Datenrate, wie Firewall-Filter. Unicast-Flussrouten werden für die Standardinstanzen, VPN Routing and Forwarding (VRF)-Instanzen und virtuelle Router-Instanzen unterstützt.
Import- und Exportrichtlinien können auf die NLRI für die Produktfamilie oder Produktfamilie angewendet werden und die akzeptierten oder angekündigten Datenstromrouten betreffen. Dies ist vergleichbar mit der Art und Weise, wie Import- und Exportrichtlinien auf andere BGP inet flowinet-vpn flow werden. Der einzige Unterschied ist, dass die Konfiguration der Datenflussrichtlinie das From-Statement rib inetflow.0 enthalten muss. Diese Anweisung bewirkt, dass die Richtlinie auf die Datenstromrouten angewendet wird. Eine Ausnahme von dieser Regel gilt, wenn die Richtlinie nur über die Anweisung then rejectthen accept oder die Anweisung from verfügt. Die Richtlinie betrifft dann alle Routen, einschließlich IP-Unicast und IP-Datenfluss.
Die Flow Route-Filter werden zuerst statisch auf einem Router konfiguriert, mit einer Reihe von Übereinstimmungskriterien, auf die die zu ergreifenden Aktionen folgen. Und dann ist zwischen diesem BGP-fähigen Gerät und seinen Peers zusätzlich family inet unicastfamily inet flowfamily inet-vpn flow (oder) eine Konfiguration möglich.
Standardmäßig werden statisch konfigurierte Flussrouten (Firewall-Filter) anderen Netzwerkgeräten BGP angeboten, die das family inet flowfamily inet-vpn flow NLRI unterstützen.
Das empfangende BGP führt einen Validierungsprozess durch, bevor der Firewall-Filter in die Flussroutingtabelle installiert instance-name.inetflow.0 wird. Das Validierungsverfahren wird in RFC 5575, Die Verbreitung der Regeln zur Datenflussspezifikation beschrieben.
Das empfangende BGP-fähige Gerät akzeptiert eine Datenstromroute, wenn folgende Kriterien erfüllt werden:
Der Originator einer Datenstromroute entspricht dem Originator der Unicastroute mit der besten Übereinstimmung für die in der Route integrierte Zieladresse.
Es gibt keine spezifischen Unicastrouten im Vergleich zur Zieladresse der Datenflussroute, für die die aktive Route von einem anderen autonomen Next-Hop-System empfangen wurde.
Mit dem ersten Kriterium wird sichergestellt, dass der Filter durch den nächsten Hop, der von der Unicastweiterleitung für die in der Datenflussroute integrierte Zieladresse verwendet wird, für den Filter angegeben wird. Wenn beispielsweise eine Flussroute als 10.1.1.1, proto=6, port=80 angegeben wird, wählt das empfangende BGP-fähige Gerät die spezifischere Unicastroute in der Unicast-Routingtabelle, die dem Ziel-Präfix 10.1.1.1/32 entspricht. In einer Unicastrouting-Tabelle mit 10.1/16 und 10.1.1/24 wird diese als Unicastroute zum Vergleich verwendet. Es wird nur der aktive Unicastroute-Eintrag berücksichtigt. Dies folgt dem Konzept, dass eine Datenflussroute gültig ist, wenn sie vom Originator der besten Unicast-Route angegeben wird.
Mit dem zweiten Kriterium werden Situationen behandelt, in denen ein gegebener Adressblock verschiedenen Einheiten zugewiesen wird. Datenflüsse, die sich zu einer Unicast-Route mit der besten Übereinstimmung lösen, die eine aggregierte Route ist, werden nur akzeptiert, wenn sie nicht spezifischere Routen abdecken, die an verschiedene autonome Systeme des nächsten Hops geroutet werden.
Sie können den Validierungsprozess für Datenstromrouten mithilfe BGP NLRI-Nachrichten umgehen und Ihre eigene spezielle Importrichtlinie verwenden. Wenn BGP NLRI-Nachrichten mit Datenflussspezifikation übertragen, wird das Validierungsverfahren zur Datenstromroute auf Hierarchieebene weglassen, nachdem Pakete von einer no-validate[edit protocols bgp group group-name family inet flow] Richtlinie akzeptiert werden. Sie können die Importrichtlinie so konfigurieren, dass sie an zieladressen- und pfadattribute wie Community, Next-Hop und AS ankommt. Sie können die Aktion angeben, die ergreifen soll, wenn das Paket den Bedingungen entspricht, die Sie in der Datenflussroute konfiguriert haben. Um eine Aktion zu konfigurieren, fügen Sie die Anweisung auf der [edit routing-options flow] Hierarchieebene ein. Die Flussspezifikation Der NLRI-Typ umfasst Komponenten wie Ziel-Präfix, Quell-Präfix, Protokoll und Ports gemäß RFC 5575. Die Importrichtlinie kann eine eingehende Route anhand von Pfadattributen und Zieladresse in der Flussspezifikation NLRI filtern. Die Importrichtlinie kann keine anderen Komponenten in RFC 5575 filtern.
Die Flussspezifikation definiert die erforderlichen Protokollerweiterungen für die gängigsten Anwendungen von IPv4-Unicast- und VPN-Unicast-Filterung. Derselbe Mechanismus kann wiederverwendbar sein und neue Übereinstimmungskriterien hinzugefügt werden, um ähnliche Filterung für andere BGP-Adressfamilien (z. B. IPv6-Unicast) zu erfüllen.
Nachdem eine Flussroute in der Tabelle installiert wurde, wird sie auch der Liste der inetflow.0 Firewall-Filter im Kernel hinzugefügt.
Nur auf Routern werden NLRI-Nachrichten mit Datenstromspezifikation in VPNs unterstützt. Das VPN vergleicht das Routenziel und die erweiterte Community im NLRI mit der Importrichtlinie. Wenn eine Übereinstimmung besteht, kann das VPN die Datenflussrouten verwenden, um den Paketdatenverkehr zu filtern und zu begrenzen. Empfangene Flussrouten werden in der Fluss-Routing-Tabelle instance-name.inetflow.0 installiert. Flussrouten können auch über ein VPN-Netzwerk verteilt und von VPNs gemeinsam genutzt werden. Um es Multiprotocol BGP (MP-BGP) zu ermöglichen, NLRI mit Datenstromspezifikation für die Adressfamilie zu tragen, fügen Sie die Anweisung auf der Hierarchieebene inet-vpnflow[edit protocols bgp group group-name family inet-vpn] ein. VPN-Flussrouten werden nur für die Standardinstanz unterstützt. Für VPNs mit Familien konfigurierte Flussrouten werden nicht automatisch validiert, sodass die Aussage auf der inet-vpnno-validate[edit protocols bgp group group-name family inet-vpn] Hierarchieebene nicht unterstützt wird. Es ist keine Validierung erforderlich, wenn die Datenstromrouten lokal zwischen Geräten in einer einzigen AS.
Import- und Exportrichtlinien können auf die NLRI angewendet werden und die akzeptierten oder angekündigten Datenstromrouten betreffen. Dies ähnelt der Art und Weise, wie Import- und Exportrichtlinien auf andere Produktfamilien angewendet BGP family inet flowfamily inet-vpn flow werden. Der einzige Unterschied ist, dass die Konfiguration der Datenflussrichtlinie die Aussage from rib inetflow.0 enthalten muss. Diese Anweisung bewirkt, dass die Richtlinie auf die Datenstromrouten angewendet wird. Eine Ausnahme von dieser Regel gilt, wenn die Richtlinie nur über die Anweisung then rejectthen accept oder die Anweisung from verfügt. Die Richtlinie betrifft dann alle Routen, einschließlich IP-Unicast und IP-Datenfluss.
In diesem Beispiel wird die Konfiguration der folgenden Exportrichtlinien veranschaulicht:
Eine Richtlinie, die die Anzeige von Flussrouten ermöglicht, die von einem Routenfilter angegeben werden. Es werden nur die Flussrouten ausgeschrieben, die unter den 10.13/16-Block fallen. Diese Richtlinie wirkt sich nicht auf Unicast-Routen aus.
Eine Richtlinie, die die Ankündigung aller Unicast- und Flussrouten zum Nachbarn ermöglicht.
Eine Richtlinie, die die Aussendung aller Routen (Unicast oder Datenfluss) dem Nachbarn ausspricht.
Topologie
Konfiguration
- Konfigurieren einer statischen Datenflussroute
- Werbeflussrouten, die durch einen Routenfilter festgelegt werden
- Alle Unicast- und Flow-Routen anzeigen
- Keine Unicast- oder Datenstromrouten anzeigen
- Begrenzung der Anzahl der in einer Routingtabelle installierten Datenstromrouten
- Begrenzung der Anzahl von Präfixen, die in einer Peering BGP sitzung empfangen werden
Konfigurieren einer statischen Datenflussroute
CLI-Konfiguration
Um dieses Beispiel schnell konfigurieren zu können, kopieren Sie die folgenden Befehle, fügen Sie diese in eine Textdatei ein, entfernen Sie alle Zeilenbrüche, ändern Sie alle Details, die zur Übereinstimmung mit der Netzwerkkonfiguration erforderlich sind, und kopieren Sie die Befehle, und fügen Sie die Befehle CLI der Hierarchieebene [edit] ein.
set 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 durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zur Navigation in CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI Benutzerhandbuch.
So konfigurieren Sie die BGP Peer-Sitzungen:
Bedingungen konfigurieren.
[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 Algorithmus der Datenflussspezifikation die standardbasierte Term-Reihenfolge.
[edit routing-options flow] user@host# set term-order standard
Im Standard-Algorithmus für die Bestellung von Begriffen, wie im flowspec RFC-Entwurf Version 6 angegeben, wird ein Begriff mit weniger spezifischen Anpassungsbedingungen immer vor einem Begriff mit spezifischeren Anpassungsbedingungen ausgewertet. Dadurch wird der Begriff mit spezifischeren Anpassungsbedingungen nie ausgewertet. Version 7 von RFC 5575 hat den Algorithmus überarbeitet, sodass die spezifischeren Anpassungsbedingungen vor den weniger spezifischen Anpassungsbedingungen ausgewertet werden. Für die Abwärtskompatibilität wird das Standardverhalten nicht Junos OS verändert, obwohl der neuere Algorithmus sinnvoller ist. Um den neuen 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 Befehl show routing-options eingeben. Wenn in der Ausgabe nicht die beabsichtigte Konfiguration angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
[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 die Konfiguration des Geräts erledigt haben, geben Sie commit den Konfigurationsmodus ein.
Werbeflussrouten, die durch einen Routenfilter festgelegt werden
CLI-Konfiguration
Um dieses Beispiel schnell konfigurieren zu können, kopieren Sie die folgenden Befehle, fügen Sie diese in eine Textdatei ein, entfernen Sie alle Zeilenbrüche, ändern Sie alle Details, die zur Übereinstimmung mit der Netzwerkkonfiguration erforderlich sind, und kopieren Sie die Befehle, und fügen Sie die Befehle CLI der Hierarchieebene [edit] ein.
set 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 durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zur Navigation in CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI Benutzerhandbuch.
So konfigurieren Sie die BGP Peer-Sitzungen:
Konfigurieren Sie BGP Netzwerkgruppe.
[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 Datenflussrichtlinie.
[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 lokale autonome Systemnummer (AS).
[edit routing-options] user@host# set autonomous-system 65001
Ergebnisse
Bestätigen Sie Ihre Konfiguration im Konfigurationsmodus, indem Sie die show protocolsshow policy-options , und Befehle show routing-options eingeben. Wenn in der Ausgabe nicht die beabsichtigte Konfiguration angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
[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 die Konfiguration des Geräts erledigt haben, geben Sie commit den Konfigurationsmodus ein.
Alle Unicast- und Flow-Routen anzeigen
CLI-Konfiguration
Um dieses Beispiel schnell konfigurieren zu können, kopieren Sie die folgenden Befehle, fügen Sie diese in eine Textdatei ein, entfernen Sie alle Zeilenbrüche, ändern Sie alle Details, die zur Übereinstimmung mit der Netzwerkkonfiguration erforderlich sind, und kopieren Sie die Befehle, und fügen Sie die Befehle CLI der Hierarchieebene [edit] ein.
set 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 durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zur Navigation in CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI Benutzerhandbuch.
So konfigurieren Sie die BGP Peer-Sitzungen:
Konfigurieren Sie BGP Netzwerkgruppe.
[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 Datenflussrichtlinie.
[edit policy-options policy-statement p1] user@host# set term a then accept
Konfigurieren Sie die lokale autonome Systemnummer (AS).
[edit routing-options] user@host# set autonomous-system 65001
Ergebnisse
Bestätigen Sie Ihre Konfiguration im Konfigurationsmodus, indem Sie die show protocolsshow policy-options , und Befehle show routing-options eingeben. Wenn in der Ausgabe nicht die beabsichtigte Konfiguration angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
[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 die Konfiguration des Geräts erledigt haben, geben Sie commit den Konfigurationsmodus ein.
Keine Unicast- oder Datenstromrouten anzeigen
CLI-Konfiguration
Um dieses Beispiel schnell konfigurieren zu können, kopieren Sie die folgenden Befehle, fügen Sie diese in eine Textdatei ein, entfernen Sie alle Zeilenbrüche, ändern Sie alle Details, die zur Übereinstimmung mit der Netzwerkkonfiguration erforderlich sind, und kopieren Sie die Befehle, und fügen Sie die Befehle CLI der Hierarchieebene [edit] ein.
set 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 durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zur Navigation in CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI Benutzerhandbuch.
So konfigurieren Sie die BGP Peer-Sitzungen:
Konfigurieren Sie BGP Netzwerkgruppe.
[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 Datenflussrichtlinie.
[edit policy-options policy-statement p1] user@host# set term a then reject
Konfigurieren Sie die lokale autonome Systemnummer (AS).
[edit routing-options] user@host# set autonomous-system 65001
Ergebnisse
Bestätigen Sie Ihre Konfiguration im Konfigurationsmodus, indem Sie die show protocolsshow policy-options , und Befehle show routing-options eingeben. Wenn in der Ausgabe nicht die beabsichtigte Konfiguration angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
[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 die Konfiguration des Geräts erledigt haben, geben Sie commit den Konfigurationsmodus ein.
Begrenzung der Anzahl der in einer Routingtabelle installierten Datenstromrouten
CLI-Konfiguration
Um dieses Beispiel schnell konfigurieren zu können, kopieren Sie die folgenden Befehle, fügen Sie diese in eine Textdatei ein, entfernen Sie alle Zeilenbrüche, ändern Sie alle Details, die zur Übereinstimmung mit der Netzwerkkonfiguration erforderlich sind, und kopieren Sie die Befehle, und fügen Sie die Befehle CLI der Hierarchieebene [edit] ein.
set 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 durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zur Navigation in CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI Benutzerhandbuch.
Die Anwendung einer Routenbegrenzung kann zu unvorhersehbarem dynamischen Routenprotokollverhalten führen. Wenn die Begrenzung beispielsweise erreicht und die Routen abgelehnt werden, werden BGP nicht notwendigerweise versuchen, die abgelehnten Routen neu zu installieren, nachdem die Anzahl der Routen unter dieser Begrenzung liegt. BGP sitzungen müssen möglicherweise genehmigt werden, um das Problem zu lösen.
Um die Flussrouten zu begrenzen:
Setzen Sie eine Obergrenze für die Anzahl der in der Tabelle installierten
inetflow.0Präfixe.[edit routing-options rib inetflow.0] user@host# set maximum-prefixes 1000
Einen Schwellenwert von 50 Prozent festlegen. Bei der Installation von 500 Routen wird eine Warnung im Systemprotokoll protokolliert.
[edit routing-options rib inetflow.0] user@host# set maximum-prefixes threshold 50
Ergebnisse
Bestätigen Sie Ihre Konfiguration im Konfigurationsmodus, indem Sie den Befehl show routing-options eingeben. Wenn in der Ausgabe nicht die beabsichtigte Konfiguration angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
[edit]
user@host# show routing-options
rib inetflow.0 {
maximum-prefixes 1000 threshold 50;
}
Wenn Sie die Konfiguration des Geräts erledigt haben, geben Sie commit den Konfigurationsmodus ein.
Begrenzung der Anzahl von Präfixen, die in einer Peering BGP sitzung empfangen werden
CLI-Konfiguration
Um dieses Beispiel schnell konfigurieren zu können, kopieren Sie die folgenden Befehle, fügen Sie diese in eine Textdatei ein, entfernen Sie alle Zeilenbrüche, ändern Sie alle Details, die zur Übereinstimmung mit der Netzwerkkonfiguration erforderlich sind, und kopieren Sie die Befehle, und fügen Sie die Befehle CLI der Hierarchieebene [edit] ein.
set 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 die Option teardown <percentage>drop-excess <percentage> bzw. die hide-excess<percentage> Aussageoption nach und nach aktivieren.
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zur Navigation in CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI Benutzerhandbuch.
Das Konfigurieren einer Präfixbegrenzung für einen bestimmten Nachbarn bietet eine vorhersehbare Kontrolle darüber, welche Peer die Anzahl der Datenflussrouten anzeigen kann.
So begrenzen Sie die Anzahl von Präfixen:
Festlegen einer Begrenzung auf 1000 BGP routen von Nachbar 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, um die Option entweder zu ausführen, oder eine Anweisungsoption, wenn die Sitzung oder
teardown <percentage>drop-excess <percentage>hide-excess<percentage>Präfixe ihre Grenze erreichen.[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 Anweisung angeben und einen Prozentwert angeben, werden Nachrichten protokolliert, wenn die Anzahl
teardown <percentage>der Präfixe diesen Prozentsatz erreicht. Nachdem die Sitzung beendet wurde, wird die Sitzung in kürzester Zeit wieder hergestellt, wenn Sie die Aussageidle-timeoutnicht enthalten.Wenn Sie die Anweisung angeben und einen Prozentwert angeben, werden die übermäßigen Routen fallen, wenn die Anzahl von
drop-excess <percentage>Präfixen diesen Prozentsatz überschreitetWenn Sie die Anweisung angeben und einen Prozentwert angeben, bleiben die übermäßigen Routen verborgen, wenn die Anzahl von
hide-excess <percentage>Präfixen diesen Prozentsatz überschreitet.
Ergebnisse
Bestätigen Sie Ihre Konfiguration im Konfigurationsmodus, indem Sie den Befehl show protocols eingeben. Wenn in der Ausgabe nicht die beabsichtigte Konfiguration 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 die Konfiguration des Geräts bereits durchgeführt haben, geben Sie commit sie im Konfigurationsmodus ein.
Überprüfung
Stellen Sie sicher, dass die Konfiguration ordnungsgemäß funktioniert.
- Prüfung des NLRI
- Routen verifizieren
- Überprüfung der Datenstromvalidierung
- Überprüfung von Firewall-Filtern
- Überprüfung der Systemprotokollierung, wenn die Anzahl zulässiger Datenflussrouten überschritten wird
- Überprüfung der Systemprotokollierung, wenn die Anzahl der Präfixe überschritten wird, die in einer peering BGP sitzung empfangen werden
Prüfung des NLRI
Zweck
Sehen Sie sich das für den Nachbarn aktivierte NLRI an.
Aktion
Führen Sie im Betriebsmodus den show bgp neighbor 10.12.99.5 Befehl aus. Achten Sie inet-flow auf die 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
Routen verifizieren
Zweck
Schauen Sie sich die Flussrouten an. Die Beispielausgabe zeigt eine aus einer statischen BGP und einer statisch konfigurierten Datenstromroute gelernte Datenflussroute.
Für lokal konfigurierte Flussrouten (in der Hierarchieebene konfiguriert) werden die Routen [edit routing-options flow] vom Flussprotokoll installiert. Sie können die Datenflussrouten anzeigen, indem Sie die Tabelle wie in oder , wo der Name show route table inetflow.0show route table instance-name.inetflow.0 der instance-name Routinginstanz angeben. Oder Sie können durch Ausführung des Befehls alle lokal konfigurierten Flussrouten über mehrere Routinginstanzen show route protocol flow anzeigen.
Wenn eine Datenflussroute nicht lokal konfiguriert ist, sondern vom BGP-Peer des Routers empfangen wird, wird diese Datenflussroute per E-BGP. Sie können die Flussrouten anzeigen, indem Sie die Tabelle oder die Ausführung angeben, die alle show route protocol bgp BGP-Routen (Datenfluss und Nicht-Datenfluss) anzeigt.
Aktion
Führen Sie im Betriebsmodus den show route table inetflow.0 Befehl 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 Datenflussroute ist der Begriff eines Firewall-Filters. Wenn Sie eine Datenflussroute konfigurieren, geben Sie die Übereinstimmungsbedingungen und die Aktionen an. In den Übereinstimmungsattributen können Sie eine Quelladresse, eine Zieladresse und andere Merkmale wie Port und Protokoll festlegen. Für eine einzelne Datenflussroute, die mehrere Übereinstimmungsbedingungen enthält, werden alle Übereinstimmungsbedingungen im Prefix-Feld der Route verkapselt. Wenn Sie den Befehl für eine Datenflussroute aus geben, wird das Prefix-Feld der Route mit allen Übereinstimmungsbedingungen angezeigt. Bedeutet, dass die Bedingungen show route10.12.44.1,* übereinstimmend match destination 10.12.44.1/32 sind. Wenn das Präfix in der Ausgabe *,10.12.44.1 wäre, würde dies bedeuten, dass die Bedingungen für diese Übereinstimmung verwendet match source 10.12.44.1/32 werden. Wenn die Bedingungen sowohl eine Quelle als auch ein Ziel enthalten, wird das Sternchen durch die Adresse ersetzt.
Die Zahlen für den Begriffsreihenfolge geben die Reihenfolge der Begriffe (Datenflussrouten) an, die im Firewall-Filter bewertet werden. Der show route extensive Befehl zeigt die Aktionen für jeden Begriff (Route) an.
Überprüfung der Datenstromvalidierung
Zweck
Anzeige von Datenstromrouteninformationen
Aktion
Führen Sie im Betriebsmodus den show route flow validation detail Befehl 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
Überprüfung von Firewall-Filtern
Zweck
Zeigen Sie die Firewall-Filter an, die im Kernel installiert sind.
Aktion
Führen Sie im Betriebsmodus den show firewall Befehl 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, wenn die Anzahl zulässiger Datenflussrouten überschritten wird
Zweck
Wenn Sie eine Begrenzung der installierten Anzahl von Flussrouten konfigurieren (wie in beschrieben), können Sie die Systemprotokollnachricht anzeigen, wenn Begrenzung der Anzahl der in einer Routingtabelle installierten Datenstromrouten der Grenzwert erreicht ist.
Aktion
Führen Sie im Betriebsmodus den show log <message> Befehl 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, wenn die Anzahl der Präfixe überschritten wird, die in einer peering BGP sitzung empfangen werden
Zweck
Wenn Sie eine Begrenzung der installierten Anzahl von Flussrouten konfigurieren (wie in beschrieben), können Sie die Systemprotokollnachricht anzeigen, wenn Begrenzung der Anzahl von Präfixen, die in einer Peering BGP sitzung empfangen werden der Grenzwert erreicht ist.
Aktion
Führen Sie im Betriebsmodus den show log message Befehl aus.
Wenn Sie die Option teradown <percentage> zur Aussage 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 Option drop-excess <percentage> zur Aussage 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 Option hide-excess <percentage> zur Aussage 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: Konfigurieren BGP, um Routen zur IPv6-Datenstromspezifikation zu führen
In diesem Beispiel wird die Konfiguration der IPv6-Datenstromspezifikation für die Filterung des Datenverkehrs veranschaulicht. BGP Datenstromspezifikation kann zur Automatisierung der Domain- und domainübergreifenden Koordination von Regeln für die Filterung des Datenverkehrs verwendet werden, um eine Denial-of-Service minimieren.
Anforderungen
In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:
Zwei Router der MX-Serie
Junos OS 16.1 oder höher
Bevor Sie die Übertragung BGP IPv6-Datenstromspezifikationsrouten aktivieren:
Konfigurieren Sie IP-Adressen auf den Geräteschnittstellen.
Konfiguration BGP.
Konfigurieren Sie eine Routing-Richtlinie, die Routen (z. B. statische Routen, direkte Routen oder IGP Routen) von der Routing-Tabelle in eine BGP.
Überblick
Die Datenflussspezifikation bietet Schutz vor angriffen Denial-of-Service beschränkt fehlerhaften Datenverkehr, der die Bandbreite verbraucht, und stoppt diesen nahe der Quelle. In früheren Junos OS Versionen wurden Die Regeln der Datenstromspezifikation für IPv4 over BGP als Informationen zur Erreichbarkeit der Netzwerkebene verbreitet. Beginnend mit Junos OS Version 16.1 wird die Funktion zur Datenflussspezifikation auf der IPv6-Produktfamilie unterstützt und ermöglicht die Verbreitung der Regeln zur Spezifikation des Datenverkehrsflusses für IPv6 und IPv6 VPN.
Topologie
Abbildung 7 zeigt die Beispieltopologie an. Router R1 und Router R2 gehören zu verschiedenen autonomen Systemen. Die IPv6-Datenflussspezifikation wird auf Router R2 konfiguriert. Der eingehende Datenverkehr wird anhand der Spezifikationen des Datenstroms gefiltert und der Datenverkehr wird je nach der angegebenen Aktion unterschiedlich behandelt. In diesem Beispiel wird der alle Datenverkehrsüberschrift nach abcd::11:11:11:10/128, die den Anforderungen der Datenflussspezifikation entspricht, verworfen. während Datenverkehr für abcd::11:11:11:30/128 und entsprechende Datenstromspezifikationsbedingungen akzeptiert wird.
Konfiguration
CLI-Konfiguration
Um dieses Beispiel schnell konfigurieren zu können, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenbrüche, ändern Sie alle Details, die zur Übereinstimmung mit Ihrer Netzwerkkonfiguration erforderlich sind, kopieren Sie die Befehle, kopieren Sie die Befehle in die CLI der Hierarchieebene, und geben Sie sie dann im Konfigurationsmodus [edit]commit ein.
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
Konfigurieren des Routers R2
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zur Navigation auf der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI Benutzerhandbuch.
So konfigurieren Sie Router R2:
Wiederholen Sie dieses Verfahren 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 autonome Systemnummer (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. So wird der 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
Spezifizieren Sie die Bedingungen der Datenflussspezifikation.
[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 discard eine Aktion zum Verwerfen von Paketen, die den angegebenen Übereinstimmungsbedingungen übereinstimmen.
[edit routing-options] user@R2# set rib inet6.0 flow route route-1 then discard
Spezifizieren Sie die Bedingungen der Datenflussspezifikation.
[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
Eine Aktion accept so konfigurieren, dass sie Pakete akzeptiert, die den angegebenen Bedingungen übereinstimmen
[edit routing-options] user@R2# set rib inet6.0 flow route route-2 then accept
Definieren Sie eine Richtlinie, die BGP das Akzeptieren statischer Routen ermöglicht.
[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 interfacesshow protocols , und Befehle show routing-optionsshow policy-options eingeben. Wenn in der Ausgabe nicht die beabsichtigte Konfiguration 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
Stellen Sie sicher, dass die Konfiguration ordnungsgemäß funktioniert.
- Prüfung des Vorhandenseins von Routen zur IPv6-Datenflussspezifikation in der Inet6flow-Tabelle
- Überprüfung zusammenfassender BGP Informationen
- Überprüfung der Datenstromvalidierung
- Prüfung der Datenflussspezifikation für IPv6-Routen
Prüfung des Vorhandenseins von Routen zur IPv6-Datenflussspezifikation in der Inet6flow-Tabelle
Zweck
Zeigen Sie die Routen in der Tabelle in Router R1 und R2 an, und stellen Sie inet6flow sicher, BGP die Datenstromrouten gelernt haben.
Aktion
Führen Sie im Betriebsmodus den Befehl show route table inet6flow.0 extensive 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 im Betriebsmodus den show route table inet6flow.0 extensive Befehl 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
Die Präsenz von Routen abcd::11:11:11:10/128 und abcd::11:11:11:30/128 in der Tabelle bestätigt, dass BGP die Flussrouten gelernt inet6flow hat.
Überprüfung zusammenfassender BGP Informationen
Zweck
Stellen Sie sicher, BGP Konfiguration korrekt ist.
Aktion
Führen Sie im Betriebsmodus den show bgp summary Befehl auf Router 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 Tabelle die BGP Nachbaradresse enthält und eine Peering-Sitzung mit seinem nächsten Nachbarn inet6.0 BGP wurde.
Überprüfung der Datenstromvalidierung
Zweck
Anzeige von Datenstromrouteninformationen
Aktion
Führen Sie im Betriebsmodus den Befehl show route flow validation 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 Datenflussrouten in der inet6.0 Tabelle an.
Prüfung der Datenflussspezifikation für IPv6-Routen
Zweck
Zeigt die Anzahl der Pakete an, die basierend auf den angegebenen Routen der Datenflussspezifikation verworfen und akzeptiert werden.
Aktion
Führen Sie im Betriebsmodus den show firewall filter_flowspec_default_inet6_ Befehl 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 gibt an, dass für abcd::11:11:11:10/128 bestimmte Pakete verworfen und 88826-Pakete für die Route abcd::11:11:11:11:30/128 akzeptiert wurden.
Konfigurieren der BGP Datenstromspezifikation Aktion Weiterleitung an IP, um DDoS zu filtern
Beginnend mit Junos OS Release 18.4R1, BGP-Datenflussspezifikation, wie in BGP Flow-Spec Internet draft-ietf-idr-flowspec-redirect-ip-02.txt beschrieben, wird Redirect an IP-Aktion unterstützt. Weiterleitung zur IP-Aktion verwendet erweiterte BGP- Community, um Datenverkehrsfilterungsoptionen für die DDoS Abschwächung von Angriffen in Dienstanbieternetzwerken zur Verfügung zu stellen. Weiterleitung der älteren Datenflussspezifikation an IP BGP Nexthop-Attribut. Junos OS gibt die Umleitung zur IP-Datenfluss-Spezifikation aus und verwendet standardmäßig die erweiterte Community. Diese Funktion ist erforderlich, um die Servicekette im Virtual Service Control Gateway (vSCG) zu unterstützen. Umleiten zur IP-Aktion ermöglicht das Umleiten des an die Datenstromspezifikation übertragenen Datenverkehrs an eine global erreichbare Adresse, die mit einem Filtergerät verbunden werden kann, das den DDoS-Datenverkehr filtern und den sauberen Datenverkehr an das Ausgangsgerät senden kann.
Bevor Sie den Datenverkehr zu IP umleiten, um für BGP Routen zur Datenstromspezifikation zu routen, gehen Sie wie folgt vor:
Konfigurieren Sie die Geräteschnittstellen.
Konfigurieren OSPF oder eines anderen IGP Protokolls.
Konfiguration MPLS LDP.
Konfiguration BGP.
Konfigurieren Sie die Weiterleitung zur IP-Funktion mithilfe BGP erweiterten Community.
Konfigurieren Sie die Umleitung der älteren Datenflussspezifikation zur IP-Funktion mithilfe des Nexthop-Attributs.
Richtlinien, die das Umleiten von Datenverkehr zu einer IP-Adresse mithilfe erweiterter Community BGP und der älteren Umleitung zur Next-Hop-IP-Adresse nicht gemeinsam konfigurieren.
Konfigurieren der älteren Flussspezifikation umleiten zu im Internet draft-ietf-idr-flowspec-redirect-ip-00.txt angegebene IP , BGP Flow-Spec Erweiterte Community für Traffic Redirect zu IP Next Hop umfassen auf der Hierarchieebene.
[edit group bgp-group neighbor bgp neighbor family inet flow] user@host# set legacy-redirect-ip-action
Definieren Sie eine Richtlinie, die auf das Next Hop-Attribut abgestimmt ist.
[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 Datenverkehr an die IP-Adresse des nächsten Hops umzuleiten 10.1.1.1.
[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 unter Verwendung der älteren Datenflussspezifikation, mit der das Next Hop-Attribut zur IP-Aktion weitergeleitet wird.
[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 fügen Sie eine BGP-Community redirnh hinzu oder löschen Sie sie, um den DDoS-Datenverkehr an die IP-Adresse des nächsten Hops 10.1.1.1 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