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 von BGP zur Neuverteilung von IPv4-Routen mit IPv6 Next-Hop-Adressen
Informationen zu BGP-Datenflussrouten für Datenverkehrsfilterung
Beispiel: Ermöglicht BGP das Übertragen von Datenstromspezifikationsrouten
Beispiel: Konfigurieren von BGP zur Übertragung von IPv6-Datenstrom-Spezifikationsrouten
Multiprotocol BGP
Mehr über Multiprotocol BGP
Multiprotocol BGP (MP-BGP) ist eine Erweiterung zu BGP, mit der BGP Routing-Informationen für mehrere Netzwerkschichten und Adressfamilien übertragen kann. MP-BGP kann die für das Multicast-Routing verwendeten Unicast-Routen separat von den für die Unicast-IP-Weiterleitung verwendeten Routen übertragen.
Um MP-BGP zu aktivieren, konfigurieren Sie BGP, um NLRI (Network Layer Reachability Information) für Adressfamilien außer Unicast IPv4 zu übertragen, indem Sie die family inet
Anweisung:
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; } } } }
Damit MP-BGP NLRI für die IPv6-Adressfamilie übertragen kann, fügen Sie die family inet6
Anweisung ein:
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, um MP-BGP das Übertragen von Layer 3 Virtual Private Network (VPN) NLRI für die IPv4-Adressfamilie zu ermöglichen, fügen Sie die family inet-vpn
Anweisung ein:
family inet-vpn { (any | flow | multicast | unicast) { accepted-prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop-excess <percentage>; hide-excess <percentage>;} } <loops number>; prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop-excess <percentage>; hide-excess <percentage>;} } rib-group group-name; } }
Nur auf Routern, um MP-BGP das Übertragen von Layer 3 VPN NLRI für die IPv6-Adressfamilie zu ermöglichen, geben Sie die family inet6-vpn
Anweisung an:
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, um MP-BGP das Übertragen von Multicast-VPN-NLRI für die IPv4-Adressfamilie und das Aktivieren von VPN-Signalübertragung zu ermöglichen, ist die family inet-mvpn
Anweisung enthalten:
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>;}} } }
Damit MP-BGP Multicast-VPN-NLRI für die IPv6-Adressfamilie übertragen und VPN-Signalübertragung aktivieren kann, fügen Sie die family inet6-mvpn
Anweisung ein:
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 für Junos OS Multicast Protocols.
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisungen einbeziehen können, finden Sie in den Zusammenfassenden Abschnitten der Anweisung für diese Anweisungen.
Wenn Sie die in der [edit protocols bgp family]
Hierarchieebene angegebene Adressfamilie ändern, werden alle aktuellen BGP-Sitzungen auf dem Routinggerät abgebrochen und dann wieder hergestellt.
In Junos OS Version 9.6 und höher können Sie einen Schleifenwert für eine bestimmte BGP-Adressfamilie angeben.
BGP-Peers tragen standardmäßig nur Unicast-Routen, die für Unicastweiterleitungszwecke verwendet werden. Um BGP-Peers so zu konfigurieren, dass sie nur Multicast-Routen übertragen, geben Sie die multicast
Option an. Um BGP-Peers so zu konfigurieren, dass sie sowohl Unicast- als auch Multicastrouten übertragen, geben Sie die any
Option an.
Wenn MP-BGP konfiguriert ist, installiert BGP die MP-BGP-Routen in verschiedenen Routing-Tabellen. Jede Routing-Tabelle wird durch die Protokollfamilie oder den 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, Datenstromspezifikation
AFI=1, SAFI=134, Datenstromspezifikation
AFI=3, SAFI=128, CLNS VPN
AFI=1, SAFI=5, NG-MVPN IPv4
AFI=2, SAFI=5, NG-MVPN IPv6
AFI=1, SAFI=66, MDT-SAFI
AFI=1, SAFI=4, gekennzeichnet mit IPv4
AFI=2, SAFI=4, gekennzeichnet mit IPv6 (6PE)
In der Routingtabelle inet.2 installierte Routen können nur dann in MP-BGP-Peers exportiert werden, da sie das SAFI verwenden und diese als Routen zu Multicastquellen identifizieren. In der Routingtabelle inet.0 installierte Routen können nur in Standard-BGP-Peers exportiert werden.
Die Routingtabelle inet.2 sollte eine Teilmenge der Routen sein, die Sie in inet.0 haben, da es unwahrscheinlich ist, 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 aus den NLRI-Multicast-Updates gelernt hat. Eine inet.2-Routingtabelle wird automatisch erstellt, wenn Sie MP-BGP konfigurieren (indem Sie NLRI auf any
) einstellen.
Wenn Sie MP-BGP aktivieren, können Sie Folgendes tun:
- Begrenzung der Anzahl der auf einer BGP-Peersitzung empfangenen Präfixe
- Begrenzung der Anzahl der auf einer BGP-Peersitzung akzeptierten Präfixe
- Konfigurieren von BGP-Routingtabellengruppen
- Auflösen von Routen zu PE-Routinggeräten in anderen ASs
- Ermöglicht gekennzeichnete und nicht gekennzeichnete Routen
Begrenzung der Anzahl der auf einer BGP-Peersitzung empfangenen Präfixe
Sie können die Anzahl der Präfixe begrenzen, die in einer BGP-Peersitzung empfangen werden, und Nachrichten mit eingeschränkter Protokollrate protokollieren, wenn die Anzahl der injizierten Präfixe ein festgelegtes Limit überschreitet. Sie können auch das Peering abreißen, wenn die Anzahl der Präfixe die Grenze überschreitet.
Um eine Begrenzung auf die Anzahl der Präfixe zu konfigurieren, die in einer BGP-Sitzung empfangen werden können, fügen Sie die prefix-limit
Anweisung ein:
prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop-excess <percentage>; hide-excess <percentage>; }
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Geben maximum number
Sie für einen Wert im Bereich von 1 bis 4.294.967.295 einen Wert an. Wenn die angegebene maximale Anzahl von Präfixen überschritten wird, wird eine Systemprotokollnachricht gesendet.
Wenn Sie die teardown
Anweisung angeben, wird die Sitzung abgebrochen, wenn die maximale Anzahl der Präfixe überschritten wird. Wenn Sie einen Prozentsatz angeben, werden Nachrichten protokolliert, wenn die Anzahl der Präfixe den Prozentsatz der angegebenen maximalen Obergrenze überschreitet. Nachdem die Sitzung abgerissen wurde, wird sie in kurzer Zeit wieder hergestellt (es sei denn, Sie fügen die idle-timeout
Anweisung bei). Wenn Sie die idle-timeout
Anweisung angeben, kann die Sitzung für einen bestimmten Zeitraum oder für immer gespeichert werden. Wenn Sie angeben forever
, wird die Sitzung erst wieder hergestellt, nachdem Sie einen clear bgp neighbor
Befehl ausgelöst haben. Wenn Sie die drop-excess <percentage>
Anweisung angeben und einen Prozentsatz angeben, werden die übermäßigen Routen abgebrochen, wenn die Anzahl der Präfixe den Prozentsatz überschreitet. Wenn Sie die hide-excess <percentage>
Anweisung angeben und einen Prozentsatz angeben, werden die überhöhten Routen ausgeblendet, wenn die Anzahl der Präfixe den Prozentsatz überschreitet. Wenn der Prozentsatz geändert wird, werden die Routen automatisch neu bewertet.
In Junos OS Version 9.2 und höher können Sie alternativ eine Beschränkung auf die Anzahl der Präfixe konfigurieren, die auf einer BGP-Peersitzung akzeptiert werden können. Weitere Informationen finden Sie unter Begrenzung der Anzahl der auf einer BGP-Peersitzung akzeptierten Präfixe.
Begrenzung der Anzahl der auf einer BGP-Peersitzung akzeptierten Präfixe
In Junos OS Version 9.2 und höher können Sie die Anzahl der Präfixe begrenzen, die in einer BGP-Peersitzung akzeptiert werden können. Wenn dieses festgelegte Limit überschritten wird, wird eine Systemprotokollnachricht gesendet. Sie können auch festlegen, dass die BGP-Sitzung zurückgesetzt wird, wenn die Obergrenze für die Anzahl der angegebenen Präfixe überschritten wird.
Um eine Beschränkung auf die Anzahl der Präfixe zu konfigurieren, die in einer BGP-Peersitzung akzeptiert werden können, fügen Sie die accepted-prefix-limit
Anweisung ein:
accepted-prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop <percentage>; hide <percentage>; }
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Geben maximum numberSie für einen Wert im Bereich von 1 bis 4.294.967.295 einen Wert an.
Fügen Sie die teardown
Anweisung zum Zurücksetzen der BGP-Peer-Sitzung ein, wenn die Anzahl der akzeptierten Präfixe die konfigurierte Obergrenze überschreitet. Sie können auch einen Prozentwert von 1 bis 100 angeben, damit eine Systemprotokollnachricht gesendet wird, wenn die Anzahl der akzeptierten Präfixe diesen Prozentsatz der maximalen Obergrenze überschreitet. Standardmäßig wird eine zurückgesetzte BGP-Sitzung innerhalb kurzer Zeit erneut eingerichtet. Fügen Sie die idle-timeout
Anweisung ein, um zu verhindern, dass die BGP-Sitzung für einen bestimmten Zeitraum wieder eingerichtet wird. Sie können einen Timeout-Wert von 1 bis 2400 Minuten konfigurieren. Fügen Sie die forever Option ein, um zu verhindern, dass die BGP-Sitzung wieder hergestellt wird, bis Sie den clear bgp neighbor
Befehl ausführen. Wenn Sie die drop-excess <percentage>
Anweisung angeben und einen Prozentsatz angeben, werden die übermäßigen Routen abgebrochen, wenn die Anzahl der Präfixe den Prozentsatz überschreitet. Wenn Sie die hide-excess <percentage>
Anweisung angeben und einen Prozentsatz angeben, werden die überhöhten Routen ausgeblendet, wenn die Anzahl der Präfixe den Prozentsatz überschreitet. Wenn der Prozentsatz geändert wird, werden die Routen automatisch neu bewertet.
Wenn Nonstop Active Routing (NSR) aktiviert ist und ein Switchover zu einer Backup-Routing-Engine erfolgt, werden abgeschaltete BGP-Peers automatisch neu gestartet. Die Peers werden selbst dann neu gestartet, wenn die idle-timeout forever
Anweisung konfiguriert ist.
Alternativ können Sie eine Beschränkung auf die Anzahl der Präfixe konfigurieren, die auf einer BGP-Peer-Sitzung empfangen werden können (im Gegensatz zu akzeptiert). Weitere Informationen finden Sie unter Begrenzung der Anzahl der auf einer BGP-Peersitzung empfangenen Präfixe.
Konfigurieren von BGP-Routingtabellengruppen
Wenn eine BGP-Sitzung einen Unicast oder Multicast NLRI empfängt, installiert sie die Route in der entsprechenden Tabelle (inet.0 oder inet6.0 für Unicast und inet.2 oder inet6.2 Multicast). Um Unicast-Präfixe zu den Unicast- und Multicasttabellen hinzuzufügen, können Sie BGP-Routingtabellengruppen konfigurieren. Dies ist nützlich, wenn Sie keine Multicast NLRI-Aushandlung durchführen können.
Um BGP-Routingtabellengruppen zu konfigurieren, fügen Sie die rib-group
Anweisung ein:
rib-group group-name;
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Auflösen von Routen zu PE-Routinggeräten in anderen ASs
Sie können die Platzierung gekennzeichneter Routen zur Routenauflösung in der inet.3 Routingtabelle zulassen. Diese Routen werden dann für Provider Edge (PE)-Routinggeräteverbindungen aufgelöst, bei denen sich die Remote-PE über ein anderes autonomes System (AS) befindet. Damit ein PE-Routinggerät eine Route in der VPN Routing and Forwarding (VRF)-Routinginstanz installieren kann, muss der nächste Hop in eine in der inet.3 Tabelle gespeicherte Route aufgelöst werden.
Um Routen in die inet.3 Routingtabelle aufzulösen, fügen Sie die resolve-vpn
Anweisung ein:
resolve-vpn group-name;
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Ermöglicht gekennzeichnete und nicht gekennzeichnete Routen
Sie können den Austausch von gekennzeichneten und nicht gekennzeichneten Routen in einer einzigen Sitzung ermöglichen. Die gekennzeichneten Routen werden in die Routingtabelle inet.3 oder inet6.3 eingefügt, und sowohl gekennzeichnete als auch nicht gekennzeichnete Unicast-Routen können an das Routinggerät gesendet oder vom Routinggerät empfangen werden.
Um den Austausch von gekennzeichneten und nicht gekennzeichneten Routen zu ermöglichen, fügen Sie die rib
Anweisung ein:
rib (inet.3 | inet6.3);
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Beispiel: Konfigurieren von IPv6-BGP-Routen über IPv4-Transport
In diesem Beispiel wird veranschaulicht, wie IPv6- und IPv4-Präfixe über eine IPv4-Verbindung exportiert werden, bei der beide Seiten mit einer IPv4-Schnittstelle konfiguriert sind.
Anforderungen
Vor der Konfiguration dieses Beispiels ist keine spezielle Konfiguration über die Geräte initialisierung hinaus erforderlich.
Überblick
Beachten Sie beim Exportieren von IPv6-BGP-Präfixen Folgendes:
BGP leitet Next-Hop-Präfixe mit dem IPv4-zugeordneten IPv6-Präfix ab. Beispielsweise übersetzt das IPv4 Next-Hop-Präfix
10.19.1.1
in das IPv6 Next-Hop-Präfix ::ffff:10.19.1.1.Anmerkung:Es muss eine aktive Route zum IPv4-zugeordneten IPv6 Next Hop vorhanden sein, um IPv6-BGP-Präfixe zu exportieren.
Eine IPv6-Verbindung muss über den Link konfiguriert werden. Die Verbindung muss entweder ein IPv6-Tunnel oder eine Dual-Stack-Konfiguration sein. In diesem Beispiel wird duales Stacking verwendet.
Verwenden Sie bei der Konfiguration von IPv4-zugeordneten IPv6-Präfixen eine Maske, die länger als 96 Bits ist.
Konfigurieren Sie eine statische Route, wenn Sie normale IPv6-Präfixe verwenden möchten. In diesem Beispiel werden statische Routen verwendet.
Abbildung 1 zeigt die Beispieltopologie.

Konfiguration
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für die Netzwerkkonfiguration erforderlich sind, und kopieren Sie dann die Befehle und fügen Sie sie auf Hierarchieebene in die [edit]
CLI ein.
Gerät R1
set interfaces fe-1/2/0 unit 1 family inet address 192.168.10.1/24 set interfaces fe-1/2/0 unit 1 family inet6 address ::ffff:192.168.10.1/120 set interfaces lo0 unit 1 family inet address 10.10.10.1/32 set protocols bgp group ext type external set protocols bgp group ext family inet unicast set protocols bgp group ext family inet6 unicast set protocols bgp group ext export send-direct set protocols bgp group ext export send-static set protocols bgp group ext peer-as 200 set protocols bgp group ext neighbor 192.168.10.10 set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set policy-options policy-statement send-static term 1 from protocol static set policy-options policy-statement send-static term 1 then accept set routing-options rib inet6.0 static route ::ffff:192.168.20.0/120 next-hop ::ffff:192.168.10.10 set routing-options static route 192.168.20.0/24 next-hop 192.168.10.10 set routing-options autonomous-system 100
Gerät R2
set interfaces fe-1/2/0 unit 2 family inet address 192.168.10.10/24 set interfaces fe-1/2/0 unit 2 family inet6 address ::ffff:192.168.10.10/120 set interfaces fe-1/2/1 unit 3 family inet address 192.168.20.21/24 set interfaces fe-1/2/1 unit 3 family inet6 address ::ffff:192.168.20.21/120 set interfaces lo0 unit 2 family inet address 10.10.0.1/32 set protocols bgp group ext type external set protocols bgp group ext family inet unicast set protocols bgp group ext family inet6 unicast set protocols bgp group ext export send-direct set protocols bgp group ext export send-static set protocols bgp group ext neighbor 192.168.10.1 peer-as 100 set protocols bgp group ext neighbor 192.168.20.1 peer-as 300 set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set policy-options policy-statement send-static term 1 from protocol static set policy-options policy-statement send-static term 1 then accept set routing-options autonomous-system 200
Gerät R3
set interfaces fe-1/2/0 unit 4 family inet address 192.168.20.1/24 set interfaces fe-1/2/0 unit 4 family inet6 address ::ffff:192.168.20.1/120 set interfaces lo0 unit 3 family inet address 10.10.20.1/32 set protocols bgp group ext type external set protocols bgp group ext family inet unicast set protocols bgp group ext family inet6 unicast set protocols bgp group ext export send-direct set protocols bgp group ext export send-static set protocols bgp group ext peer-as 200 set protocols bgp group ext neighbor 192.168.20.21 set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set policy-options policy-statement send-static term 1 from protocol static set policy-options policy-statement send-static term 1 then accept set routing-options rib inet6.0 static route ::ffff:192.168.10.0/120 next-hop ::ffff:192.168.20.21 set routing-options static route 192.168.10.0/24 next-hop 192.168.20.21 set routing-options autonomous-system 300
Konfigurieren von Gerät R1
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Cli-Benutzerhandbuch von Junos OS.
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 Sie BGP, um IPv4-Unicast- und IPv6-Unicastrouten zu übertragen. .
[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 zur Vollständigkeit dargestellt.
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 Im Konfigurationsmodus Ihre Konfiguration durch Eingabe der show interfaces
Befehle , , show policy-options
show protocols
undshow routing-options
. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, 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 durchgeführt haben, geben Sie aus dem Konfigurationsmodus ein commit . Wiederholen Sie die Konfiguration auf Gerät R2 und Gerät R3, und ändern Sie bei Bedarf die Schnittstellennamen und IP-Adressen.
Überprüfung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
Überprüfen des Nachbarstatus
Zweck
Stellen Sie sicher, dass BGP für IPv6-Unicastrouten aktiviert ist.
Aktion
Geben Sie im Betriebsmodus den show bgp neighbor
Befehl ein.
user@R2> show bgp neighbor Peer: 192.168.10.1+179 AS 100 Local: 192.168.10.10+54226 AS 200 Type: External State: Established Flags: <Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ send-direct send-static ] Options: <Preference AddressFamily PeerAS Refresh> Address families configured: inet-unicast inet6-unicast Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 10.10.10.1 Local ID: 10.10.0.1 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 0 BFD: disabled, down Local Interface: fe-1/2/0.2 NLRI for restart configured on peer: inet-unicast inet6-unicast NLRI advertised by peer: inet-unicast inet6-unicast NLRI for this session: inet-unicast inet6-unicast Peer supports Refresh capability (2) Stale routes from peer are kept for: 300 Peer does not support Restarter functionality NLRI that restart is negotiated for: inet-unicast inet6-unicast NLRI of received end-of-rib markers: inet-unicast inet6-unicast NLRI of all end-of-rib markers sent: inet-unicast inet6-unicast Peer supports 4 byte AS extension (peer-as 100) Peer does not support Addpath Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 1 Received prefixes: 3 Accepted prefixes: 2 Suppressed due to damping: 0 Advertised prefixes: 4 Table inet6.0 Bit: 20000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 1 Accepted prefixes: 1 Suppressed due to damping: 0 Advertised prefixes: 2 Last traffic (seconds): Received 24 Sent 12 Checked 60 Input messages: Total 132 Updates 6 Refreshes 0 Octets 2700 Output messages: Total 133 Updates 3 Refreshes 0 Octets 2772 Output Queue[0]: 0 Output Queue[1]: 0 Peer: 192.168.20.1+179 AS 300 Local: 192.168.20.21+54706 AS 200 Type: External State: Established Flags: <Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ send-direct send-static ] Options: <Preference AddressFamily PeerAS Refresh> Address families configured: inet-unicast inet6-unicast Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 10.10.20.1 Local ID: 10.10.0.1 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 1 BFD: disabled, down Local Interface: fe-1/2/1.3 NLRI for restart configured on peer: inet-unicast inet6-unicast NLRI advertised by peer: inet-unicast inet6-unicast NLRI for this session: inet-unicast inet6-unicast Peer supports Refresh capability (2) Stale routes from peer are kept for: 300 Peer does not support Restarter functionality NLRI that restart is negotiated for: inet-unicast inet6-unicast NLRI of received end-of-rib markers: inet-unicast inet6-unicast NLRI of all end-of-rib markers sent: inet-unicast inet6-unicast Peer supports 4 byte AS extension (peer-as 300) Peer does not support Addpath Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 1 Received prefixes: 3 Accepted prefixes: 2 Suppressed due to damping: 0 Advertised prefixes: 4 Table inet6.0 Bit: 20000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 1 Accepted prefixes: 1 Suppressed due to damping: 0 Advertised prefixes: 2 Last traffic (seconds): Received 1 Sent 15 Checked 75 Input messages: Total 133 Updates 6 Refreshes 0 Octets 2719 Output messages: Total 131 Updates 3 Refreshes 0 Octets 2734 Output Queue[0]: 0 Output Queue[1]: 0
Bedeutung
Die verschiedenen Vorkommnisse inet6-unicast in der Ausgabe zeigen, dass BGP IPv6-Unicastrouten übertragen kann.
Überprüfen der Routing-Tabelle
Zweck
Stellen Sie sicher, dass Gerät R2 über BGP-Routen in seiner Inet6.0-Routingtabelle verfügt.
Aktion
Geben Sie im Betriebsmodus den show route protocol bgp inet6.0
Befehl ein.
user@R2> show route protocol bgp table inet6.0 inet6.0: 7 destinations, 10 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both ::ffff:192.168.10.0/120 [BGP/170] 01:03:49, localpref 100, from 192.168.20.1 AS path: 300 I > to ::ffff:192.168.20.21 via fe-1/2/1.3 ::ffff:192.168.20.0/120 [BGP/170] 01:03:53, localpref 100, from 192.168.10.1 AS path: 100 I > to ::ffff:192.168.10.10 via fe-1/2/0.2
Werben von IPv4-Routen über BGP IPv6-Sitzungen – Übersicht
In einem IPv6-Netzwerk meldet BGP normalerweise Erreichbarkeitsinformationen der IPv6-Netzwerkschicht über eine IPv6-Sitzung zwischen BGP-Peers. In früheren Versionen unterstützte Junos OS nur den Austausch von Inet6-Unicast-, Inet6-Multicast- oder inet6-Unicast-Adressfamilien mit Label inet6. Diese Funktion ermöglicht den Austausch aller BGP-Adressfamilien. In einer Dual-Stack-Umgebung mit IPv6 im Core. mit dieser Funktion kann BGP die IPv4-Unicast-Erreichbarkeit mit IPv4 Next Hop über eine IPv6-BGP-Sitzung anzeigen.
Diese Funktion ist nur für BGP-IPv6-Sitzungen vorgesehen, bei denen IPv4 an beiden Endpunkten konfiguriert ist. Dies local-ipv4-address
kann eine Loopback-Adresse oder eine beliebige IPv4-Adresse für eine IBGP- oder Multi-Hop-EBGP-Sitzung sein. Bei externen Single-Hop-BGP-Lautsprechern, die nicht teil von BGP-Konföderationen sind, wird die BGP-Sitzung geschlossen, und es wird ein Fehler generiert, der in der Ausgabe des show bgp neighbor
Befehls angezeigt wird.
Konfigurieren Sie wie folgt, local-ipv4-address
um IPv4-Routenwerbung über IPv6-Sitzungen zu aktivieren:
[edit protocols bgp family inet unicast] local-ipv4-address local ipv4 address;
Sie können diese Funktion nicht für die Inet6-Unicast-, Inet6-Multicast- oder Inet6-Unicastadressfamilien konfigurieren, da BGP bereits in der Lage ist, diese Adressfamilien über eine IPv6-BGP-Sitzung zu bewerben.
Das konfigurierte local-ipv4-address
wird nur verwendet, wenn BGP Routen mit Self-Next Hop angibt. Wenn IBGP Routen angibt, die von EBGP-Peers gelernt wurden, oder der Routenreflektor BGP-Routen an seine Clients angibt, ändert BGP den route next hop nicht, ignoriert den konfigurierten local-ipv4-address
und verwendet den ursprünglichen IPv4 Next Hop.
Siehe auch
Beispiel: Werben von IPv4-Routen über IPv6-BGP-Sitzungen
In diesem Beispiel wird gezeigt, wie IPv4-Routen über IPv6-BGP-Sitzungen angekündigt werden. In einer Dual-Stack-Umgebung mit IPv6 im Core müssen Remote-IPv4-Hosts erreicht werden. Daher kündigt BGP IPv4-Routen mit IPv4-Next Hops zu BGP-Peers über BGP-Sitzungen mithilfe von IPv6-Quell- und Zieladressen an. Mit dieser Funktion kann BGP die IPv4-Unicast-Erreichbarkeit mit IPv4 Next Hop über IPv6-BGP-Sitzungen anzeigen.
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-Anzeigen über IPv6-BGP-Sitzungen aktivieren, achten Sie auf Folgendes:
Konfigurieren Sie die Geräteschnittstellen.
Konfiguration von Dual-Stacking auf allen Geräten.
Überblick
Ab Version 16.1 ermöglicht Junos OS BGP, die IPv4-Unicast-Erreichbarkeit mit dem nächsten IPv4-Hop über eine IPv6-BGP-Sitzung zu werben. In früheren Junos OS-Versionen konnte BGP nur Inet6-Unicast-, Inet6-Multicast- und inet6-gekennzeichnete Unicastadressfamilien über IPv6-BGP-Sitzungen anzeigen. Mit dieser Funktion kann BGP alle BGP-Adressfamilien über eine IPv6-Sitzung austauschen. Sie können BGP aktivieren, um IPv4-Routen mit IPv4 Next Hops zu BGP-Peers über IPv6-Sitzung zu bewerben. Das konfigurierte local-ipv4-address
wird nur verwendet, wenn BGP Routen mit Self-Next Hop angibt.
Sie können diese Funktion nicht für die Inet6-Unicast-, Inet6-Multicast- oder Inet6-Unicastadressfamilien konfigurieren, da BGP bereits in der Lage ist, diese Adressfamilien über eine IPv6-BGP-Sitzung zu bewerben.
Topologie
In Abbildung 2wird eine externe IPv6-BGP-Sitzung zwischen den Routern R1 und R2 ausgeführt. Zwischen Router R2 und Router R3 wird eine IPv6-IBGP-Sitzung eingerichtet. Statische IPv4-Routen werden auf R1 an das BGP umverteilt. Um die IPv4-Routen über die IPv6-BGP-Sitzung neu zu verteilen, muss die neue Funktion auf allen Routern auf Hierarchieebene [edit protocols bgp address family]
aktiviert sein.

Konfiguration
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für die Netzwerkkonfiguration erforderlich sind, kopieren Und fügen Sie die Befehle auf Hierarchieebene in die [edit] CLI ein und geben Sie dann aus dem Konfigurationsmodus ein commit
.
Router R1
set interfaces ge-0/0/0 unit 0 description R1->R2 set interfaces ge-0/0/0 unit 0 family inet address 140.1.1.1/24 set interfaces ge-0/0/0 unit 0 family inet6 address ::140.1.1.1/126 set interfaces lo0 unit 0 family inet6 address 1::1/128 set routing-options static route 11.1.1.1/32 discard set routing-options static route 11.1.1.2/32 discard set routing-options autonomous-system 64497 set protocols bgp group ebgp-v6 type external set protocols bgp group ebgp-v6 export p1 set protocols bgp group ebgp-v6 peer-as 64496 set protocols bgp group ebgp-v6 neighbor ::140.1.1.2 description R2 set protocols bgp group ebgp-v6 neighbor ::140.1.1.2 family inet unicast local-ipv4-address 140.1.1.1 set policy-options policy-statement p1 from protocol static set policy-options policy-statement p1 then accept
Router R2
set interfaces ge-0/0/0 unit 0 description R2->R1 set interfaces ge-0/0/0 unit 0 family inet address 140.1.1.2/24 set interfaces ge-0/0/0 unit 0 family inet6 address ::140.1.1.2/126 set interfaces ge-0/0/1 unit 0 description R2->R3 set interfaces ge-0/0/1 unit 0 family inet address 150.1.1.1/24 set interfaces ge-0/0/1 unit 0 family inet6 address ::150.1.1.1/126 set interfaces lo0 unit 0 family inet6 address 1::2/128 set routing-options autonomous-system 64496 set protocols bgp group ibgp-v6 type internal set protocols bgp group ibgp-v6 export change-nh set protocols bgp group ibgp-v6 neighbor ::150.1.1.2 description R3 set protocols bgp group ibgp-v6 neighbor ::150.1.1.2 family inet unicast local-ipv4-address 150.1.1.1 set protocols bgp group ebgp-v6 type external set protocols bgp group ebgp-v6 peer-as 64497 set protocols bgp group ebgp-v6 neighbor ::140.1.1.1 description R1 set protocols bgp group ebgp-v6 neighbor ::140.1.1.1 family inet unicast local-ipv4-address 140.1.1.2 set policy-options policy-statement change-nh from protocol bgp set policy-options policy-statement change-nh then next-hop self set policy-options policy-statement change-nh then accept
Router R3
set interfaces ge-0/0/0 unit 0 description R3->R2 set interfaces ge-0/0/0 unit 0 family inet address 150.1.1.2/24 set interfaces ge-0/0/0 unit 0 family inet6 address ::150.1.1.2/126 set interfaces lo0 unit 0 family inet6 address 1::3/128 set routing-options autonomous-system 64496 set protocols bgp group ibgp-v6 type internal set protocols bgp group ibgp-v6 neighbor ::150.1.1.1 description R2 set protocols bgp group ibgp-v6 neighbor ::150.1.1.1 family inet unicast local-ipv4-address 150.1.1.2
Konfigurieren des Routers R1
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie in verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI-Benutzerhandbuch.
So konfigurieren Sie Router R1:
Wiederholen Sie diese Vorgehensweise 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 angekündigt werden muss.
[edit routing-options] user@R1# set static route 11.1.1.1/32 discard user@R1# set static route 11.1.1.2/32 discard
Konfigurieren Sie das autonome System für BGP-Hosts.
[edit routing-options] user@R1# set autonomous-system 64497
Konfigurieren Sie EBGP auf den externen Edge-Routern.
[edit protocols] user@R1# set bgp group ebgp-v6 type external user@R1# set bgp group ebgp-v6 peer-as 64496 user@R1# set bgp group ebgp-v6 neighbor ::140.1.1.2 description R2
Aktivieren Sie die Funktion, um IPv4 Adddress 140.1.1.1 über BGP IPv6-Sitzungen zu bewerben.
[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-v6 der EBGP-Gruppe an.
[edit protocols] user@R1# set bgp group ebgp-v6 export p1
Ergebnisse
Bestätigen Sie Im Konfigurationsmodus Ihre Konfiguration durch Eingabe der show interfacesBefehle , , show protocolsshow routing-optionsundshow policy-options. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, 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 durchgeführt haben, bestätigen Sie die Konfiguration.
user@R1# commit
Überprüfung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
- Überprüfen, ob die BGP-Sitzung aktiv ist
- Überprüfen der Annoncierung der IPv4-Adresse
- Überprüfen, ob der BGP-Nachbarrouter R2 die angekündigte IPv4-Adresse erhält
Überprüfen, ob die BGP-Sitzung aktiv ist
Zweck
Vergewissern Sie sich, dass BGP auf den konfigurierten Schnittstellen ausgeführt wird und dass die BGP-Sitzung für jede Nachbaradresse aktiv ist.
Aktion
Führen Sie im Betriebsmodus den Befehl auf Router show bgp summary R1 aus.
user@R1> show bgp summary Groups: 1 Peers: 1 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... ::140.1.1.2 64496 4140 4158 0 0 1d 7:10:36 0/0/0/0 0/0/0/0
Bedeutung
Die BGP-Sitzung ist einsatzbereit und BGP-Peering wird eingerichtet.
Überprüfen der Annoncierung der IPv4-Adresse
Zweck
Vergewissern Sie sich, dass die konfigurierte IPv4-Adresse von Router R1 an die konfigurierten BGP-Nachbarn angekündigt wird.
Aktion
Führen Sie im Betriebsmodus den Befehl auf Router show route advertising-protocol bgp ::150.1.1.2 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 an den BGP-Nachbarrouter R2 weitergeleitet.
Überprüfen, ob der BGP-Nachbarrouter R2 die angekündigte IPv4-Adresse erhält
Zweck
Vergewissern Sie sich, dass Router R2 die IPv4-Adresse empfängt, die Router R1 dem BGP-Nachbarn über IPv6 meldet.
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 Routingtabelle von Router R2 zeigt an, 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 transportiert, müssen IPv4-Routen bei Bedarf geroutet werden. Beispielsweise ein Internet-Service Provider, der nur über ein IPv6-Netzwerk verfügt, aber Kunden hat, die noch IPv4-Datenverkehr routen. In diesem Fall ist es notwendig, auf solche Kunden einzugehen und IPv4-Datenverkehr über ein IPv6-Netzwerk weiterzuleiten. Wie in RFC 5549 beschrieben, werden IPv4 Network Layer Reachability Information mit einem IPv6 Next Hop IPv4-Datenverkehr von Customer Premises Equipment (CPE)-Geräten zu IPv4-over-IPv6-Gateways getunnelt. 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 bewerben IPv4-aggregierte Routen zur Steuerung des Datenverkehrs.
Die dynamische IPv4-over-IPv6-Tunnelfunktion unterstützt unified ISSU in Junos OS Version 17.3R1 nicht.
Route Reflectors (RRs) mit einer programmierbaren Schnittstelle werden über IBGP mit den Gateway-Routern verbunden und hosten Routen mit IPv6-Adresse als nächster Hop. Diese RRs werben mit den IPv4/32-Adressen, um die Tunnelinformationen in das Netzwerk einzuspeisen. Die Gateway-Router erzeugen dynamische IPv4-over-IPv6-Tunnel zum Remote-Kundenanbieter-Edge. Der Gateway-Router gibt auch die aggregierten IPv4-Routen an, um den Datenverkehr zu steuern. Die RR gibt dann die Tunnel-Quellrouten zum ISP an. Wenn die RR die Tunnelroute entfernt, zieht BGP auch die Route zurück, was dazu führt, dass der Tunnel abgerissen wird und das CPE nicht erreichbar ist. Der Gateway-Router zieht auch die aggregierten IPv4-Routen und IPv6-Tunnelquellenrouten zurück, wenn alle aggregierten Routen, die mitwirkende Routen entfernt werden. Der Gateway-Router sendet den Routenabzug, wenn die Anker-Packet Forwarding Engine-Linekarte ausfällt, sodass der Datenverkehr an andere Gateway-Router weitergeleitet wird.
Die folgenden Erweiterungen werden eingeführt, um IPv4-Routen mit einem IPv6 Next Hop zu unterstützen:
- BGP Next Hop-Codierung
- Tunnellokalisierung
- Tunnelbehandlung
- Tunnel Load Balancing und Anchor Packet Forwarding Engine Failure Handling
- Tunnel Loopback-Stream-Statistiken
BGP Next Hop-Codierung
BGP wird mit Next Hop-Codierungsfunktion erweitert, die zum Senden von IPv4-Routen mit IPv6 Next Hops verwendet wird. Wenn diese Funktion auf dem Remote-Peer nicht verfügbar ist, gruppiert BGP die Peers anhand dieser Codierungsfunktion und entfernt die BGP-Familie ohne Codierungsfunktion aus der NLRI-Liste (Network Layer Reachability Information). Junos OS ermöglicht nur eine Auflösungstabelle wie inet.0. Um IPv4-BGP-Routen mit IPv6 Next Hops zu ermöglichen, erstellt BGP einen neuen Auflösungsbaum. Diese Funktion ermöglicht es einer Junos OS-Routingtabelle, mehrere Auflösungsbäume zu haben.
Neben RFC 5549, Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop wird eine neue Kapselungs-Community gemäß RFC 5512, The 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 Einkapselungs-Community gibt die Art von Tunneln an, die der Eingangsknoten 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-Routen gelöst, ohne den V4oV6-Tunnel zu erstellen.
Eine neue Richtlinienaktion dynamic-tunnel-attributes dyan-attribute
ist auf der [edit policy-statement policy name term then]
Hierarchieebene verfügbar, um die neue erweiterte Einkapselung zu unterstützen.
Tunnellokalisierung
Die dynamische Tunnelinfrastruktur wird durch Tunnellokalisierung erweitert, um eine größere Anzahl von Tunneln zu unterstützen. Die Tunnellokalisierung muss Ausfallsicherheit bieten, um den Datenverkehr zu bewältigen, wenn der Anker ausfällt. Ein oder mehrere Gehäuse sichern sich gegenseitig und lassen den Datenverkehr durch den Routing-Protokollprozess (rpd) vom Fehlerpunkt zum Backup-Chassis lenken. 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 der Tunnelankerung, um die erforderliche gehäuseweite Skalierung zu unterstützen. Der Tunnelstatus ist an eine Packet Forwarding Engine lokalisiert, und die anderen Packet Forwarding Engines steuern den Datenverkehr zum Tunnelanker.
Tunnel-Eingang


Verkapselt IPv4-Datenverkehr innerhalb des IPv6-Headers.
Die MAXIMALE MTU-Durchsetzung (Transmission Unit) wird vor der Einkapselung durchgeführt. Wenn die eingekapselte Paketgröße die Tunnel-MTU überschreitet und die IPv4-Pakete
DF-bit
nicht festgelegt sind, ist das Paket fragmentiert und diese Fragmente werden verkapselt.Verwendet Hash-basiertes Traffic Load Balancing auf inneren Paket-Headern.
Leitet den Datenverkehr an die Ziel-IPv6-Adresse weiter. Die IPv6-Adresse wird aus dem IPv6-Header übernommen.
Tunnel-Ausgang


Entkapselt das im IPv6-Paket befindliche IPv4-Paket.
Führt Anti-Spoof-Prüfungen durch, um sicherzustellen, dass das IPv6-, IPv4-Paar mit den Informationen übereinstimmt, die zum Einrichten des Tunnels verwendet wurden.
Sucht die IPv4-Zieladresse aus dem IPv4-Header des entkapselten Pakets und leitet das Paket an die angegebene IPv4-Adresse weiter.
Tunnel Load Balancing und Anchor Packet Forwarding Engine Failure Handling
Der Fehler der Packet Forwarding Engine muss umgehend gehandhabt werden, um eine Null-Route-Filterung des tunnelbasierten Datenverkehrs zu vermeiden, der auf der Packet Forwarding Engine verankert ist. Bei der Tunnellokalisierung werden BGP-Anzeigen verwendet, um den Fehler weltweit zu reparieren. Der Tunneldatenverkehr wird vom Fehlerpunkt zu einem anderen Backup-Gehäuse mit identischem Tunnelstatus umgeleitet. Für das Load Balancing des Datenverkehrs ist das Gehäuse so konfiguriert, dass für jeden der Präfixsätze unterschiedliche MED-Werte (Multiple Exit Discriminator) angekündigt werden, sodass nur ein Viertel der Tunnel durch jedes Gehäuse übertragen wird. Der CPE-Datenverkehr wird auch auf ähnliche Weise gehandhabt, indem die gleichen Anycastadressen in jedem Gehäuse konfiguriert und nur ein Viertel des Datenverkehrs in jedes Gehäuse geleitet wird.
Anchor Packet Forwarding Engine ist die einzige Einheit, die die gesamte Verarbeitung für einen Tunnel übernimmt. Die Packet Forwarding Engine-Auswahl erfolgt über eine statische Bereitstellung und ist an die physischen Schnittstellen der Packet Forwarding Engine gebunden. Wenn eine der Packet Forwarding Engines ausfällt, markiert der Daemon alle Packet Forwarding Engines auf der Linekarte und kommuniziert diese Informationen an den Routingprotokollprozess und andere Daemons. Der Routingprotokollprozess sendet BGP-Auszahlungen für die Präfixe, die auf der fehlgeschlagenen Packet Forwarding Engine verankert sind, und die der Packet Forwarding Engine zugewiesenen IPv6-Adressen, die ausfallen. Diese Anzeigen leiten den Datenverkehr in ein anderes Backup-Gehäuse um. Wenn die fehlgeschlagene Packet Forwarding Engine wieder aktiv ist, markiert das Gehäuse die Packet Forwarding Engine und up
aktualisiert den Routingprotokollprozess. Der Routingprotokollprozess löst BGP-Aktualisierungen für seine Peers aus, die in der jeweiligen Packet Forwarding Engine verankerte Tunnel jetzt für den Routing-Datenverkehr verfügbar sind. Dieser Prozess kann minutenlang für eine umfangreiche Tunnelkonfiguration dauern. Daher ist der Mechanismus in das Ack
System integriert, um einen minimalen Datenverkehrsverlust zu gewährleisten, während der Datenverkehr zurück zum ursprünglichen Gehäuse umgestellt wird.
Tunnel Loopback-Stream-Statistiken
Die dynamische Tunnelinfrastruktur verwendet Loopback-Streams in Packet Forwarding Engine zum Looping des Pakets nach der Kapselung. Da die Bandbreite dieses Loopback-Streams begrenzt ist, müssen die Leistung von Tunnel-Loopback-Streams überwacht werden.
Zur Überwachung der Statistiken des Loopback-Streams verwenden Sie den Betriebsbefehl show pfe statistics traffic detail
, der die aggregierten Loopback-Stream-Statistiken einschließlich Weiterleitungsrate, Paketrate und Byterate anzeigt.
Siehe auch
Konfigurieren von BGP zur Neuverteilung von IPv4-Routen mit IPv6 Next-Hop-Adressen
Ab Version 17.3R1 können Junos OS-Geräte IPv4-Datenverkehr über ein nur IPv6-Netzwerk weiterleiten, das IPv4-Datenverkehr im Allgemeinen nicht weiterleiten kann. Wie in RFC 5549 beschrieben, wird IPv4-Datenverkehr von CPE-Geräten zu IPv4-over-IPv6-Gateways getunnelt. Diese Gateways werden CPE-Geräten über Anycast-Adressen bekannt gegeben. Die Gateway-Geräte erstellen dann dynamische IPv4-over-IPv6-Tunnel zu Remote-Kundenstandortgeräten und werben für IPv4-aggregierte Routen zur Steuerung des Datenverkehrs. Routenreflektoren mit programmierbaren Schnittstellen integrieren die Tunnelinformationen in das Netzwerk. Die Routenreflektoren sind über IBGP mit Gateway-Routern verbunden, die die IPv4-Adressen von Hostrouten mit IPv6-Adressen als nächsten Hop bewerben.
Die dynamische IPv4-over-IPv6-Tunnelfunktion unterstützt unified ISSU in Junos OS Version 17.3R1 nicht.
Bevor Sie mit der Konfiguration von BGP für die Verteilung von IPv4-Routen mit IPv6-Next-Hop-Adressen beginnen, gehen Sie wie folgt vor:
Konfigurieren Sie die Geräteschnittstellen.
Konfigurieren Sie OSPF oder ein anderes IGP-Protokoll.
Konfigurieren Sie MPLS und LDP.
Konfigurieren Sie BGP.
So konfigurieren Sie BGP zur Verteilung von IPv4-Routen mit IPv6-Next-Hop-Adressen:
Siehe auch
Aktivieren von Layer-2-VPN- und VPLS-Signalübertragung
Sie können BGP das Übertragen von Layer 2-VPN- und VPLS-NLRI-Nachrichten aktivieren.
Um VPN- und VPLS-Signalübertragung zu aktivieren, geben Sie die family
Anweisung ein:
family { l2vpn { signaling { prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop-excess <percentage>; hide-excess <percentage>; } } } }
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Um eine maximale Anzahl von Präfixen zu konfigurieren, geben Sie die prefix-limit
Anweisung an:
prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop-excess <percentage>; hide-excess <percentage>;}
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Wenn Sie die maximale Anzahl von Präfixen festlegen, wird bei Erreichen dieser Nummer eine Nachricht protokolliert. Wenn Sie die teardown
Anweisung angeben, wird die Sitzung abgebrochen, wenn die maximale Anzahl der Präfixe erreicht wird. Wenn Sie einen Prozentsatz angeben, werden Nachrichten protokolliert, wenn die Anzahl der Präfixe den prozentsatz erreicht. Sobald die Sitzung abgerissen ist, wird sie in kurzer Zeit wieder hergestellt. Fügen Sie die idle-timeout
Anweisung ein, um die Sitzung für einen bestimmten Zeitraum oder für immer zu halten. Wenn Sie angeben forever
, wird die Sitzung erst wieder hergestellt, nachdem Sie den clear bgp neighbor
Befehl verwendet haben. Wenn Sie die drop-excess <percentage>
Anweisung angeben und einen Prozentsatz angeben, werden die übermäßigen Routen abgebrochen, wenn die Anzahl der Präfixe den Prozentsatz überschreitet. Wenn Sie die hide-excess <percentage>
Anweisung angeben und einen Prozentsatz angeben, werden die überhöhten Routen ausgeblendet, wenn die Anzahl der Präfixe den Prozentsatz überschreitet. Wenn der Prozentsatz geändert wird, werden die Routen automatisch neu bewertet.
Siehe auch
Informationen zu BGP-Datenflussrouten für Datenverkehrsfilterung
Eine Datenflussroute ist eine Aggregation von Übereinstimmungsbedingungen für IP-Pakete. Datenflussrouten werden mithilfe von NLRI-Nachrichten (Flow-Specification Network Layer Reachability Information) über das Netzwerk weitergegeben und in die Flow-Routing-Tabelle instance-name.inetflow.0
installiert. Pakete können nur dann durch Datenstromrouten übertragen werden, wenn bestimmte Übereinstimmungsbedingungen erfüllt sind.
Flussrouten und Firewall-Filter sind ähnlich, da sie Pakete basierend auf ihren Komponenten filtern und eine Aktion für die entsprechenden Pakete ausführen. Flussrouten bieten Funktionen zur Datenverkehrsfilterung und Begrenzung der Übertragungsrate, ähnlich wie Firewall-Filter. Darüber hinaus können Sie Flussrouten über verschiedene autonome Systeme hinweg verbreiten.
Datenstromrouten werden von BGP über NLRI-Nachrichten zur Datenflussspezifikation weitergegeben. Sie müssen BGP aktivieren, um diese NLRIs weiterzuverbreiten.
Beginnend mit Junos OS Version 15.1 werden Änderungen implementiert, um die Unterstützung des nonstop active Routing (NSR) für vorhandene Inet-Flow- und Inetvpn-Flow-Familien auszuweiten und die Routenvalidierung für BGP flowspec per draft-ietf-idr-bgp-flowspec-oid-01 zu erweitern. Im Rahmen dieser Verbesserung werden zwei neue Aussagen eingeführt. Siehe Enforce-first-as und no-install.
Ab Junos OS Version 16.1 wird die IPv6-Unterstützung auf die BGP-Datenstromspezifikation erweitert, die die Verbreitung von Regeln für die Datenverkehrsflussspezifikation für IPv6- und VPN-IPv6-Pakete ermöglicht. Die BGP-Datenflussspezifikation automatisiert die Koordination von Regeln zur Filterung des Datenverkehrs, um Distributed Denial-of-Service-Angriffe während des unterbrechungsfreien aktiven Routings (NSR) zu verhindern.
Die BGP-Datenstromspezifikation beginnt mit Junos OS Version 16.1R1 und unterstützt Filtermaßnahmen zur Datenverkehrsmarkierung extended-community
. Für IPv4-Datenverkehr ändert Junos OS die DiffServ-Codepunkt-Bits (DSCP) eines transitierenden IPv4-Pakets an den entsprechenden Wert der erweiterten Community. Bei IPv6-Paketen ändert Junos OS die ersten sechs Bits des traffic class
Feldes des übertragenden IPv6-Pakets an den entsprechenden Wert der erweiterten Community.
BGP kann ab Junos OS Version 17.1R1 NLRI-Nachrichten (Flow-Specification Network Layer Reachability Information) auf Routern der PTX-Serie mit FPCs der dritten Generation (FPC3-PTX-U2 und FPC3-PTX-U3 auf PTX5000 und FPC3-SFF-PTX-U0 und FPC3-SFF-PTX-U1 auf PTX3000) übertragen. Durch die Verbreitung von Firewall-Filterinformationen als Teil von BGP können Sie Firewall-Filter gegen Denial-of-Service-Angriffe (DOS) dynamisch über autonome Systeme hinweg verbreiten.
BGP kann ab Junos OS Version 17.2R1 NLRI-Nachrichten (Flow-Specification Network Layer Reachability Information) auf PTX1000-Routern übertragen, bei denen FPCs der dritten Generation installiert sind. Durch die Verbreitung von Firewall-Filterinformationen als Teil von BGP können Sie Firewall-Filter gegen Denial-of-Service-Angriffe (DOS) dynamisch über autonome Systeme hinweg verbreiten.
Ab cRPD Version 20.3R1 werden Datenstromrouten und Richtlinien, die über die BGP Flow-Spezifikation NLRI weitergegeben werden, über das Linux Netfilter Framework in cRPD-Umgebungen auf den Linux-Kernel heruntergeladen.
- Übereinstimmungsbedingungen für Datenstromrouten
- Aktionen für Datenstromrouten
- Validieren von Datenstromrouten
- Unterstützung für BGP Flow-Specification Algorithm Version 7 und höher
Übereinstimmungsbedingungen für Datenstromrouten
Sie geben Bedingungen an, die das Paket übereinstimmen muss, bevor die Aktion in der then
Anweisung für eine Datenflussroute durchgeführt wird. Alle Bedingungen in der from
Erklärung müssen mit der zu ergreifenden Maßnahme übereinstimmen. Die Reihenfolge, in der Sie Übereinstimmungsbedingungen angeben, ist nicht wichtig, da ein Paket alle Bedingungen in einer Laufzeit für eine Übereinstimmung erfüllen muss.
Um eine Übereinstimmungsbedingung zu konfigurieren, fügen Sie die match
Anweisung auf Hierarchieebene [edit routing-options flow]
ein.
Tabelle 1 beschreibt die Bedingungen für die Datenflussrouten-Übereinstimmung.
Übereinstimmungsbedingung |
Beschreibung |
---|---|
|
IP-Zieladressenfeld. Sie können das |
|
ZIEL-Portfeld für TCP oder User Datagram Protocol (UDP). Sie können nicht sowohl die Bedingungen als auch die Anstelle des numerischen Werts können Sie eines der folgenden Text synonyme angeben (die Portnummern werden ebenfalls aufgeführt): |
|
Differenzierter Service-Codepunkt (DSCP). Das DiffServ-Protokoll verwendet das ToS-Byte (Type of Service) im IP-Header. Die wichtigsten sechs Bits dieses Byte bilden das DSCP. Sie können DSCP in Hexadezimal- oder Dezimalform angeben. |
|
Passen Sie den Datenstrom-Labelwert an. Der Wert dieses Feldes reicht von 0 bis 1048575. Diese Übereinstimmungsbedingung wird nur auf Junos-Geräten mit erweiterten MPCs unterstützt, die für |
|
Feld "Fragmenttyp". Die Keywords werden nach dem Fragmenttyp gruppiert, dem sie zugeordnet sind:
Diese Übereinstimmungsbedingung wird nur auf Junos OS-Geräten mit erweiterten MPCs unterstützt, die für |
|
ICMP-Codefeld. Dieser Wert oder dieses Schlüsselwort bietet spezifischere Informationen als Anstelle des numerischen Werts können Sie eines der folgenden Text synonyme angeben (die Feldwerte werden ebenfalls aufgeführt). Die Keywords werden nach dem ICMP-Typ gruppiert, dem sie zugeordnet sind:
|
|
ICMP-Pakettypfeld. Normalerweise legen Sie diese Übereinstimmung zusammen mit der Anstelle des numerischen Werts können Sie eines der folgenden Text synonyme angeben (die Feldwerte werden ebenfalls aufgeführt): |
|
Ip-Paketlänge insgesamt. |
|
TCP- oder UDP-Quell- oder Ziel-Portfeld. Sie können nicht sowohl die Anstelle des numerischen Werts können Sie eines der unter aufgeführten |
|
IP-Protokollfeld. Anstelle des numerischen Werts können Sie eines der folgenden Text synonyme angeben (die Feldwerte werden ebenfalls aufgeführt): Diese Übereinstimmungsbedingung wird für IPv6 nur auf Junos-Geräten mit erweiterten MPCs unterstützt, die für |
|
IP-Quelladressenfeld. Sie können das |
|
TCP- oder UDP-Quellportfeld. Sie können die Bedingungen und Anstelle des numerischen Feldes können Sie eines der unter aufgeführten |
|
TCP-Header-Format. |
Aktionen für Datenstromrouten
Sie können die zu ergreifenden Aktionen angeben, 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 Flow Route-Aktionen.
Aktions- oder Aktionsmodifizierer |
Beschreibung |
---|---|
Aktionen | |
|
Akzeptieren Sie ein Paket. Dies ist der Standard. |
|
Verwerfen Sie ein Paket unbemerkt, ohne eine ICMP-Nachricht (Internet Control Message Protocol) zu senden. |
|
Ersetzen Sie alle Gemeinden auf der Route durch die angegebenen Gemeinden. |
Markenwert |
Legen Sie einen DSCP-Wert für Datenverkehr fest, der mit diesem Datenstrom übereinstimmt. Geben Sie einen Wert von 0 bis 63 an. Diese Aktion wird nur auf Junos-Geräten mit erweiterten MPCs unterstützt, die für |
|
Fahren Sie zur nächsten Bewertungsbedingung fort. |
|
Geben Sie eine Routing-Instanz an, an die Pakete weitergeleitet werden. |
|
Begrenzen Sie die Bandbreite auf der Datenstromroute. Drücken Sie die Grenze in Bits pro Sekunde (bps) aus. Beginnend mit Junos OS Version 16.1R4 liegt der Bereich der Begrenzung der Übertragungsrate bei [0 bis 100000000000]. |
|
Probieren Sie den Datenverkehr auf der Datenstromroute aus. |
Validieren von Datenstromrouten
Das Junos OS installiert Flussrouten nur dann in der Datenstromroutingtabelle, wenn sie mit dem Validierungsverfahren validiert wurden. Die Routing-Engine führt die Validierung durch, bevor die Routen in der Datenstromroutingtabelle installiert werden.
Flussrouten, die mithilfe der NLRI-Nachrichten (Network Layer Reachability Information) von BGP empfangen werden, werden validiert, bevor sie in der Routingtabelle instance.inetflow.0
für primäre Flussinstanzen installiert werden. Das Validierungsverfahren wird in draft-ietf-idr-flow-spec-09.txt, Dissemination of Flow Specification Rules, beschrieben. Sie können den Validierungsprozess für Flussrouten mit BGP NLRI-Nachrichten umgehen und Ihre eigene spezifische Importrichtlinie verwenden.
Um Validierungsvorgänge nachzuverfolgen, fügen Sie die validation
Anweisung auf Hierarchieebene [edit routing-options flow]
ein.
Unterstützung für BGP Flow-Specification Algorithm Version 7 und höher
Standardmäßig verwendet Junos OS den in Version 6 des Entwurfs der BGP-Datenstromspezifikation definierten Algorithmus für Termanordnung. In Junos OS Version 10.0 und höher können Sie den Router so konfigurieren, dass er dem in Version 7 der BGP-Datenstromspezifikation erstmals definierten Und durch RFC 5575, Dissemination of Flow Specification Routes (Verbreitung von Datenflussspezifikationsrouten) unterstützten Algorithmus zur Terminfolge entspricht.
Wir empfehlen, das Junos OS so zu konfigurieren, dass der in Version 7 des Entwurfs der BGP-Datenstromspezifikation festgelegte Algorithmus für die Begriffsanordnung verwendet wird. Wir empfehlen ihnen auch, das Junos OS so zu konfigurieren, dass auf allen auf einem Router konfigurierten Routinginstanzen der gleiche Algorithmus für die Termanordnung verwendet wird.
Um BGP so zu konfigurieren, dass der in Version 7 des Internetentwurfs erstmals definierte Algorithmus für die Datenstromspezifikation verwendet wird, fügen Sie die standard
Anweisung auf der [edit routing-options flow term-order]
Hierarchieebene ein.
Um auf den in Version 6 definierten Begriffsanordnungsalgorithmus umzusteigen, fügen Sie die legacy
Anweisung auf Hierarchieebene [edit routing-options flow term-order]
ein.
Die konfigurierte Terminusreihenfolge hat nur lokale Bedeutung. Das heißt, der Begriffsauftrag wird nicht mit Flussrouten weitergegeben, die an die entfernten BGP-Peers gesendet werden, deren Termreihenfolge vollständig durch ihre eigene Terminfolgekonfiguration bestimmt ist. Daher sollten Sie bei der Konfiguration der orderabhängigen Aktion next term
vorsichtig sein, wenn Ihnen der Begriff Auftragskonfiguration der Remote-Peers nicht bekannt ist. Das Lokale next term
kann von dem auf dem next term
Remote-Peer konfigurierten abweichen.
Unter Junos OS Evolved next term
kann nicht als letzter Begriff der Aktion angezeigt werden. Ein Filterbegriff, der next term
als Aktion angegeben wird, jedoch ohne konfigurierte Übereinstimmungsbedingungen, wird nicht unterstützt.
Ab Junos OS Version 16.1 haben Sie die Möglichkeit, den Filter nicht auf den Datenverkehr anzuwenden, der flowspec an bestimmten Schnittstellen empfangen wird. Zu Beginn des Filters wird ein neuer Begriff hinzugefügt, der alle Pakete akzeptiert, die flowspec an diesen spezifischen Schnittstellen empfangen werden. Der neue Begriff ist eine Variable, die als Teil des Datenstromspezifikationsfilters eine Ausschlussliste der Begriffe erstellt, die dem Filter der Weiterleitungstabelle angehängt werden.
Um die Anwendung des Filters auf den flowspec datenverkehrsspezifischen Datenverkehr an bestimmten Schnittstellen auszuschließen, müssen Sie zunächst eine group-id
Anweisung auf solchen Schnittstellen konfigurieren, indem Sie die Gruppenanweisung inet
group-id
für familienspezifische Filter auf der [edit interfaces]
Hierarchieebene einbeziehen und den Filter dann mit der Schnittstellengruppe verbinden, indem Sie die flow interface-group group-id exclude
Anweisung auf Hierarchieebene [edit routing-options]
einschließenflowspec. Sie können nur eine group-id
pro Routinginstanz mit der set routing-options flow interface-group group-id
Anweisung konfigurieren.
Siehe auch
Beispiel: Ermöglicht BGP das Übertragen von Datenstromspezifikationsrouten
In diesem Beispiel wird veranschaulicht, wie BGP NLRI-Nachrichten (Flow-Specification Network Layer Reachability Information) übertragen kann.
Anforderungen
Bevor Sie beginnen:
Konfigurieren Sie die Geräteschnittstellen.
Konfigurieren Sie ein Interior Gateway Protocol (IGP).
Konfigurieren Sie BGP.
Konfigurieren Sie eine Routing-Richtlinie, die Routen (z. B. Direktrouten oder IGP-Routen) aus der Routingtabelle in BGP exportiert.
Überblick
Durch die Verbreitung von Firewall-Filterinformationen als Teil von BGP können Sie Firewall-Filter gegen Denial-of-Service-Angriffe (DOS) dynamisch über autonome Systeme hinweg verbreiten. Flussrouten werden in die FLOW-Spezifikation NLRI eingekapselt und über ein Netzwerk oder virtuelle private Netzwerke (VPNs) weitergegeben und filterähnliche Informationen weitergegeben. Flussrouten sind eine Aggregation von Übereinstimmungsbedingungen und daraus resultierenden Aktionen für Pakete. Sie bieten Ihnen Funktionen zur Datenverkehrsfilterung und Begrenzung der Übertragungsrate, ähnlich wie Firewall-Filter. Unicast Flow Routen werden für die Standardinstanz, VPN Routing and Forwarding (VRF)-Instanzen und Virtual-Router-Instanzen unterstützt.
Import- und Exportrichtlinien können auf die NLRI-Familie inet flow
oder -Familie inet-vpn flow
angewendet werden, was sich auf die akzeptierten oder angekündigten Flussrouten auswirkt, ähnlich wie die Art und Weise, wie Import- und Exportrichtlinien auf andere BGP-Familien angewendet werden. Der einzige Unterschied besteht darin, dass die Datenstromrichtlinienkonfiguration die from-Anweisung rib inetflow.0
enthalten muss. Diese Anweisung bewirkt, dass die Richtlinie auf die Datenstromrouten angewendet wird. Eine Ausnahme von dieser Regel tritt auf, wenn die Richtlinie nur die then reject
Anweisung oder die then accept
Anweisung und keine from
Anweisung hat. Dann wirkt sich die Richtlinie auf alle Routen aus, einschließlich IP-Unicast und IP-Datenfluss.
Die Flussroutenfilter werden zunächst statisch auf einem Router konfiguriert, gefolgt von einer Reihe von Abgleichkriterien, gefolgt von den zu ergreifenden Aktionen. Dann wird zusätzlich zu family inet unicast
( family inet flow
oder family inet-vpn flow
) zwischen diesem BGP-fähigen Gerät und seinen Peers konfiguriert.
Statisch konfigurierte Datenstromrouten (Firewall-Filter) werden standardmäßig anderen BGP-fähigen Geräten angeboten, die die family inet flow
family inet-vpn flow
NLRI unterstützen.
Das empfangende BGP-fähige Gerät führt vor der Installation des Firewallfilters in der Datenstromroutingtabelle instance-name.inetflow.0
einen Validierungsprozess durch. Das Validierungsverfahren wird in RFC 5575, Dissemination of Flow Specification Rules beschrieben.
Das empfangende BGP-fähige Gerät akzeptiert eine Datenstromroute, wenn es die folgenden Kriterien übergibt:
Der Originator einer Datenstromroute entspricht dem Originator der Unicastroute mit der am besten übereinstimmenden Zieladresse, die in die Route eingebettet ist.
Es gibt keine spezifischeren Unicast-Routen im Vergleich zur Zieladresse der Flow Route, für die die aktive Route von einem anderen autonomen Next-Hop-System empfangen wurde.
Das erste Kriterium stellt sicher, dass der Filter vom nächsten Hop, der von der Unicastweiterleitung für die in die Datenflussroute eingebettete Zieladresse verwendet wird, angekündigt wird. Wenn beispielsweise eine Datenstromroute als 10.1.1.1, proto=6, port=80 angegeben ist, wählt das empfangende BGP-fähige Gerät die spezifischere Unicastroute in der Unicast-Routingtabelle aus, die dem Ziel-Präfix 10.1.1.1/32 entspricht. In einer Unicast-Routingtabelle mit 10.1/16 und 10.1.1/24 wird letztere als Unicastroute gewählt, mit der sie verglichen werden soll. Es wird nur der aktive Unicastrouteneintrag berücksichtigt. Dies folgt dem Konzept, dass eine Datenstromroute gültig ist, wenn sie vom Originator der besten Unicastroute angegeben wird.
Das zweite Kriterium behebt Situationen, in denen ein bestimmter Adressblock verschiedenen Entitäten zugewiesen wird. Datenströme, die zu einer unicastfähigen, aggregierten Route aufgelöst werden, werden nur akzeptiert, wenn sie keine spezifischeren Routen abdecken, die an verschiedene autonome Next-Hop-Systeme geroutet werden.
Sie können den Validierungsprozess für Flussrouten mit BGP NLRI-Nachrichten umgehen und Ihre eigene spezifische Importrichtlinie verwenden. Wenn BGP NLRI-Nachrichten zur Datenflussspezifikation überträgt, lässt die no-validate
[edit protocols bgp group group-name family inet flow]
Anweisung auf Hierarchieebene das Validierungsverfahren für die Datenflussroute aus, nachdem Pakete von einer Richtlinie akzeptiert wurden. Sie können die Importrichtlinie so konfigurieren, dass sie den Attributen der Zieladresse und des Pfads wie Community, Next-Hop und AS-Pfad entspricht. Sie können die zu ergreifenden Aktionen angeben, 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. Der NLRI-Typ der Datenflussspezifikation umfasst Komponenten wie Ziel-Präfix, Quell-Präfix, Protokoll und Ports wie im RFC 5575 definiert. Die Importrichtlinie kann eine eingehende Route mithilfe von Pfadattributen und Zieladresse in der DATENstromspezifikation NLRI filtern. Die Importrichtlinie kann keine anderen Komponenten im RFC 5575 filtern.
Die Datenstromspezifikation definiert die erforderlichen Protokollerweiterungen für die häufigsten Anwendungen von IPv4-Unicast- und VPN-Unicastfilterung. Der gleiche Mechanismus kann wiederverwendet und neue Übereinstimmungskriterien hinzugefügt werden, um ähnliche Filter für andere BGP-Adressfamilien zu adressieren (z. B. IPv6-Unicast).
Nachdem eine Datenstromroute in der inetflow.0
Tabelle installiert wurde, wird sie auch der Liste der Firewall-Filter im Kernel hinzugefügt.
Nur auf Routern werden NLRI-Nachrichten mit Datenstromspezifikation in VPNs unterstützt. Das VPN vergleicht das Routenziel der erweiterten Community in der NLRI mit der Importrichtlinie. Wenn es eine Übereinstimmung gibt, kann das VPN die Datenflussrouten verwenden, um den Paketdatenverkehr zu filtern und die Übertragungsrate zu begrenzen. Empfangene Datenstromrouten werden in der Flow-Routing-Tabelle instance-name.inetflow.0
installiert. Flussrouten können auch über ein VPN-Netzwerk weitergegeben und unter VPNs gemeinsam genutzt werden. Um zu ermöglichen, dass Multiprotocol BGP (MP-BGP) die NLRI der Datenflussspezifikation für die inet-vpn
Adressfamilie übertragen kann, fügen Sie die flow
Anweisung auf Hierarchieebene [edit protocols bgp group group-name family inet-vpn]
ein. VPN-Datenstromrouten werden nur für die Standardinstanz unterstützt. Flussrouten, die für VPNs mit Familie inet-vpn
konfiguriert sind, werden nicht automatisch validiert, daher wird die no-validate
Anweisung auf Hierarchieebene [edit protocols bgp group group-name family inet-vpn]
nicht unterstützt. Es ist keine Validierung erforderlich, wenn die Datenstromrouten lokal zwischen Geräten in einem einzigen AS konfiguriert werden.
Import- und Exportrichtlinien können auf die oder family inet-vpn flow
NLRI family inet flow
angewendet werden, was sich auf die akzeptierten oder angekündigten Flussrouten auswirkt, ähnlich wie die Art und Weise, wie Import- und Exportrichtlinien auf andere BGP-Familien angewendet werden. Der einzige Unterschied besteht darin, dass die Datenstromrichtlinienkonfiguration die from rib inetflow.0
Anweisung enthalten muss. Diese Anweisung bewirkt, dass die Richtlinie auf die Datenstromrouten angewendet wird. Eine Ausnahme von dieser Regel tritt auf, wenn die Richtlinie nur die then reject
Anweisung oder die then accept
Anweisung und keine from
Anweisung hat. Dann wirkt sich die Richtlinie auf alle Routen aus, einschließlich IP-Unicast und IP-Datenfluss.
In diesem Beispiel erfahren Sie, wie Sie die folgenden Exportrichtlinien konfigurieren:
Eine Richtlinie, die die Anzeige von Durchflussrouten ermöglicht, die von einem Routenfilter angegeben werden. Es werden nur die Vom Block 10.13/16 abgedeckten Datenstromrouten angeboten. Diese Richtlinie wirkt sich nicht auf Unicast-Routen aus.
Eine Richtlinie, mit der alle Unicast- und Flow-Routen dem Nachbarn angeboten werden können.
Eine Richtlinie, die die Anzeige aller Routen (Unicast oder Datenstrom) für den Nachbarn unterbunden.
Topologie
Konfiguration
- Konfigurieren einer statischen Datenstromroute
- Von einem Routenfilter festgelegte Werbeflussrouten
- Werbung für alle Unicast- und Datenstromrouten
- Werbung ohne Unicast- oder Datenstromrouten
- Begrenzung der Anzahl der in einer Routing-Tabelle installierten Datenstromrouten
- Begrenzung der Anzahl der auf einer BGP-Peering-Sitzung empfangenen Präfixe
Konfigurieren einer statischen Datenstromroute
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für die Netzwerkkonfiguration erforderlich sind, und kopieren Sie dann die Befehle und fügen Sie sie auf Hierarchieebene in die [edit]
CLI ein.
set routing-options flow route block-10.131.1.1 match destination 10.131.1.1/32 set routing-options flow route block-10.131.1.1 match protocol icmp set routing-options flow route block-10.131.1.1 match icmp-type echo-request set routing-options flow route block-10.131.1.1 then discard set routing-options flow term-order standard
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie in verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Cli-Benutzerhandbuch von Junos OS.
So konfigurieren Sie die BGP-Peer-Sitzungen:
Konfigurieren Sie die Übereinstimmungsbedingungen.
[edit routing-options flow route block-10.131.1.1] user@host# set match destination 10.131.1.1/32 user@host# set match protocol icmp user@host# set match icmp-type echo-request
Konfigurieren Sie die Aktion.
[edit routing-options flow route block-10.131.1.1] user@host# set then discard
(Empfohlen) Konfigurieren Sie für den Algorithmus der Datenstromspezifikation die standardbasierte Terminusreihenfolge.
[edit routing-options flow] user@host# set term-order standard
Im Standard-Termanordnungsalgorithmus, wie im flowspec RFC-Entwurf Version 6 angegeben, wird ein Begriff mit weniger spezifischen Abgleichbedingungen immer vor einem Begriff mit spezifischeren Matching-Bedingungen bewertet. Dies führt dazu, dass der Begriff mit spezifischeren Matching-Bedingungen niemals bewertet wird. Version 7 des RFC 5575 hat eine Überarbeitung des Algorithmus vorgenommen, damit die spezifischeren Abgleichbedingungen vor den weniger spezifischen Abgleichbedingungen bewertet werden. Für die Abwärtskompatibilität wird das Standardverhalten in Junos OS nicht geändert, obwohl der neuere Algorithmus sinnvoller ist. Um den neueren Algorithmus zu verwenden, fügen Sie die
term-order standard
Anweisung in die Konfiguration ein. Diese Anweisung wird in Junos OS Version 10.0 und höher unterstützt.
Ergebnisse
Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie den show routing-options
Befehl eingeben. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, 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 durchgeführt haben, geben Sie aus dem Konfigurationsmodus ein commit
.
Von einem Routenfilter festgelegte Werbeflussrouten
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für die Netzwerkkonfiguration erforderlich sind, und kopieren Sie dann die Befehle und fügen Sie sie auf Hierarchieebene in die [edit]
CLI ein.
set protocols bgp group core family inet unicast set protocols bgp group core family inet flow set protocols bgp group core export p1 set protocols bgp group core peer-as 65000 set protocols bgp group core neighbor 10.12.99.5 set policy-options policy-statement p1 term a from rib inetflow.0 set policy-options policy-statement p1 term a from route-filter 10.13.0.0/16 orlonger set policy-options policy-statement p1 term a then accept set policy-options policy-statement p1 term b then reject set routing-options autonomous-system 65001
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie in verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Cli-Benutzerhandbuch von Junos OS.
So konfigurieren Sie die BGP-Peer-Sitzungen:
Konfigurieren Sie die BGP-Gruppe.
[edit protocols bgp group core] user@host# set family inet unicast user@host# set family inet flow user@host# set export p1 user@host# set peer-as 65000 user@host# set neighbor 10.12.99.5
Konfigurieren Sie die Datenstromrichtlinie.
[edit policy-options policy-statement p1] user@host# set term a from rib inetflow.0 user@host# set term a from route-filter 10.13.0.0/16 orlonger user@host# set term a then accept user@host# set term b then reject
Konfigurieren Sie die lokale autonome Systemnummer (AS).
[edit routing-options] user@host# set autonomous-system 65001
Ergebnisse
Bestätigen Sie ihre Konfiguration im Konfigurationsmodus durch Eingabe von show protocols
, show policy-options
und show routing-options
Befehlen. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, 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 durchgeführt haben, geben Sie aus dem Konfigurationsmodus ein commit
.
Werbung für alle Unicast- und Datenstromrouten
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für die Netzwerkkonfiguration erforderlich sind, und kopieren Sie dann die Befehle und fügen Sie sie auf Hierarchieebene in die [edit]
CLI ein.
set protocols bgp group core family inet unicast set protocols bgp group core family inet flow set protocols bgp group core export p1 set protocols bgp group core peer-as 65000 set protocols bgp group core neighbor 10.12.99.5 set policy-options policy-statement p1 term a then accept set routing-options autonomous-system 65001
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie in verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Cli-Benutzerhandbuch von Junos OS.
So konfigurieren Sie die BGP-Peer-Sitzungen:
Konfigurieren Sie die BGP-Gruppe.
[edit protocols bgp group core] user@host# set family inet unicast user@host# set family inet flow user@host# set export p1 user@host# set peer-as 65000 user@host# set neighbor 10.12.99.5
Konfigurieren Sie die Datenstromrichtlinie.
[edit policy-options policy-statement p1] user@host# set term a then accept
Konfigurieren Sie die lokale autonome Systemnummer (AS).
[edit routing-options] user@host# set autonomous-system 65001
Ergebnisse
Bestätigen Sie ihre Konfiguration im Konfigurationsmodus durch Eingabe von show protocols
, show policy-options
und show routing-options
Befehlen. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, 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 durchgeführt haben, geben Sie aus dem Konfigurationsmodus ein commit
.
Werbung ohne Unicast- oder Datenstromrouten
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für die Netzwerkkonfiguration erforderlich sind, und kopieren Sie dann die Befehle und fügen Sie sie auf Hierarchieebene in die [edit]
CLI ein.
set protocols bgp group core family inet unicast set protocols bgp group core family inet flow set protocols bgp group core export p1 set protocols bgp group core peer-as 65000 set protocols bgp group core neighbor 10.12.99.5 set policy-options policy-statement p1 term a then reject set routing-options autonomous-system 65001
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie in verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Cli-Benutzerhandbuch von Junos OS.
So konfigurieren Sie die BGP-Peer-Sitzungen:
Konfigurieren Sie die BGP-Gruppe.
[edit protocols bgp group core] user@host# set family inet unicast user@host# set family inet flow user@host# set export p1 user@host# set peer-as 65000 user@host# set neighbor 10.12.99.5
Konfigurieren Sie die Datenstromrichtlinie.
[edit policy-options policy-statement p1] user@host# set term a then reject
Konfigurieren Sie die lokale autonome Systemnummer (AS).
[edit routing-options] user@host# set autonomous-system 65001
Ergebnisse
Bestätigen Sie ihre Konfiguration im Konfigurationsmodus durch Eingabe von show protocols
, show policy-options
und show routing-options
Befehlen. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, 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 durchgeführt haben, geben Sie aus dem Konfigurationsmodus ein commit
.
Begrenzung der Anzahl der in einer Routing-Tabelle installierten Datenstromrouten
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für die Netzwerkkonfiguration erforderlich sind, und kopieren Sie dann die Befehle und fügen Sie sie auf Hierarchieebene in die [edit]
CLI ein.
set routing-options rib inetflow.0 maximum-prefixes 1000 set routing-options rib inetflow.0 maximum-prefixes threshold 50
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie in verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Cli-Benutzerhandbuch von Junos OS.
Die Anwendung einer Routenbegrenzung kann zu unvorhersehbarem dynamischem Routenprotokollverhalten führen. Wenn beispielsweise die Grenze erreicht und Routen abgelehnt werden, versucht BGP nicht unbedingt, die abgelehnten Routen neu zu installieren, nachdem die Anzahl der Routen unter die Grenze fällt. BGP-Sitzungen müssen möglicherweise gelöscht werden, um dieses Problem zu beheben.
So begrenzen Sie die Datenstromrouten:
Legen Sie eine obere Obergrenze für die Anzahl der in
inetflow.0
der Tabelle installierten Präfixe fest.[edit routing-options rib inetflow.0] user@host# set maximum-prefixes 1000
Legen Sie einen Schwellwert von 50 Prozent fest. Wenn 500 Routen installiert werden, wird eine Warnung im Systemprotokoll protokolliert.
[edit routing-options rib inetflow.0] user@host# set maximum-prefixes threshold 50
Ergebnisse
Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie den show routing-options
Befehl eingeben. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, 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 durchgeführt haben, geben Sie aus dem Konfigurationsmodus ein commit
.
Begrenzung der Anzahl der auf einer BGP-Peering-Sitzung empfangenen Präfixe
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für die Netzwerkkonfiguration erforderlich sind, und kopieren Sie dann die Befehle und fügen Sie sie auf Hierarchieebene in die [edit]
CLI ein.
set protocols bgp group x1 neighbor 10.12.99.2 family inet flow prefix-limit maximum 1000 set protocols bgp group x1 neighbor 10.12.99.2 family inet flow prefix-limit teardown 50 set protocols bgp group x1 neighbor 10.12.99.2 family inet flow prefix-limit drop-excess 50 set protocols bgp group x1 neighbor 10.12.99.2 family inet flow prefix-limit hide-excess 50
Sie können jeweils entweder die teardown <percentage>
Option , drop-excess <percentage>
oder hide-excess<percentage>
die Anweisungsoption einfügen.
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie in verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Cli-Benutzerhandbuch von Junos OS.
Die Konfiguration eines Präfixlimits für einen bestimmten Nachbarn bietet eine besser vorhersehbare Kontrolle darüber, welcher Peer wie viele Datenstromrouten angeben kann.
So begrenzen Sie die Anzahl der Präfixe:
Legen Sie eine Obergrenze von 1000 BGP-Routen vom Nachbarn 10.12.99.2 fest.
[edit protocols bgp group x1] user@host# set neighbor 10.12.99.2 family inet flow prefix-limit maximum 1000
-
Konfigurieren Sie die Nachbarsitzung oder Präfixe so, dass sie entweder
teardown <percentage>
eine Anweisungsoptiondrop-excess <percentage>
oderhide-excess<percentage>
eine Anweisung ausführt, wenn die Sitzung oder die 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
teardown <percentage>
Anweisung angeben und einen Prozentsatz angeben, werden Nachrichten protokolliert, wenn die Anzahl der Präfixe den prozentsatz erreicht. Nachdem die Sitzung beendet wurde, wird die Sitzung in kurzer Zeit wieder hergestellt, es sei denn, Sie fügen dieidle-timeout
Anweisung bei.Wenn Sie die
drop-excess <percentage>
Anweisung angeben und einen Prozentsatz angeben, werden die übermäßigen Routen abgebrochen, wenn die Anzahl der Präfixe den Prozentsatz überschreitetWenn Sie die
hide-excess <percentage>
Anweisung angeben und einen Prozentsatz angeben, werden die überhöhten Routen ausgeblendet, wenn die Anzahl der Präfixe den Prozentsatz überschreitet.
Ergebnisse
Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie den show protocols
Befehl eingeben. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, 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 durchgeführt haben, geben Sie aus dem Konfigurationsmodus ein commit
.
Überprüfung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
- Überprüfung des NLRI
- Verifizierung von Routen
- Überprüfung der Datenstromvalidierung
- Überprüfung von Firewall-Filtern
- Überprüfung der Systemprotokollierung bei Überschreitung der Anzahl zulässiger Datenstromrouten
- Überprüfung der Systemprotokollierung bei Überschreitung der Anzahl der in einer BGP-Peering-Sitzung empfangenen Präfixe
Überprüfung des NLRI
Zweck
Sehen Sie sich das NLRI an, das für den Nachbarn aktiviert ist.
Aktion
Führen Sie im Betriebsmodus den show bgp neighbor 10.12.99.5
Befehl aus. inet-flow
Suchen Sie in der Ausgabe.
user@host> show bgp neighbor 10.12.99.5 Peer: 10.12.99.5+3792 AS 65000 Local: 10.12.99.6+179 AS 65002 Type: External State: Established Flags: <Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ direct ] Options: <Preference HoldTime AddressFamily PeerAS Refresh> Address families configured: inet-unicast inet-multicast inet-flow Holdtime: 90 Preference: 170 Number of flaps: 1 Error: 'Cease' Sent: 0 Recv: 1 Peer ID: 10.255.71.161 Local ID: 10.255.124.107 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 0 Local Interface: e1-3/0/0.0 NLRI advertised by peer: inet-unicast inet-multicast inet-flow NLRI for this session: inet-unicast inet-multicast inet-flow Peer supports Refresh capability (2) Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 2 Received prefixes: 2 Suppressed due to damping: 0 Advertised prefixes: 3 Table inet.2 Bit: 20000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 0 Suppressed due to damping: 0 Advertised prefixes: 0 Table inetflow.0 Bit: 30000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 0 Suppressed due to damping: 0 Advertised prefixes: 0 Last traffic (seconds): Received 29 Sent 15 Checked 15 Input messages: Total 5549 Updates 2618 Refreshes 0 Octets 416486 Output messages: Total 2943 Updates 1 Refreshes 0 Octets 55995 Output Queue[0]: 0 Output Queue[1]: 0 Output Queue[2]: 0
Verifizierung von Routen
Zweck
Sehen Sie sich die Datenstromrouten an. Die Beispielausgabe zeigt eine aus BGP erlernte Datenflussroute und eine statisch konfigurierte Datenstromroute.
Für lokal konfigurierte Flussrouten (auf Hierarchieebene konfiguriert [edit routing-options flow]
) werden die Routen vom Datenflussprotokoll installiert. Daher können Sie die Datenstromrouten anzeigen, indem Sie die Tabelle wie in show route table inetflow.0
oder show route table instance-name.inetflow.0
, wobei instance-name
der Name der Routinginstanz angegeben wird. Oder Sie können alle lokal konfigurierten Flussrouten über mehrere Routinginstanzen anzeigen, indem Sie den show route protocol flow
Befehl ausführen.
Wenn eine Datenstromroute nicht lokal konfiguriert, sondern vom BGP-Peer des Routers empfangen wird, wird diese Datenflussroute von BGP in der Routingtabelle installiert. Sie können die Datenstromrouten anzeigen, indem Sie die Tabelle angeben oder durch Ausführen show route protocol bgp
alle BGP-Routen (Flow und Non-Flow) anzeigen.
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
Ein Datenstrompfad steht für einen Begriff eines Firewallfilters. Wenn Sie eine Datenstromroute konfigurieren, geben Sie die Übereinstimmungsbedingungen und die Aktionen an. In den Übereinstimmungsattributen können Sie einer Quelladresse, einer Zieladresse und anderen Qualifikationszeichen wie dem Port und dem Protokoll entsprechen. Für eine einzelne Flussroute, die mehrere Übereinstimmungsbedingungen enthält, sind alle Übereinstimmungsbedingungen im Prefix-Feld der Route verkapselt. Wenn Sie den show route
Befehl auf einer Datenflussroute ausstellen, wird das Prefix-Feld der Route mit allen Übereinstimmungsbedingungen angezeigt. 10.12.44.1,*
Das bedeutet, dass die übereinstimmende Bedingung ist match destination 10.12.44.1/32
. Wenn das Präfix in der Ausgabe lautet *,10.12.44.1
, bedeutet dies, dass die Übereinstimmungsbedingung lautet match source 10.12.44.1/32
. Wenn die übereinstimmenden Bedingungen sowohl eine Quelle als auch ein Ziel enthalten, wird das Sternchen durch die Adresse ersetzt.
Die Term-Order-Nummern geben die Reihenfolge der Begriffe (Flow-Routen) an, die im Firewall-Filter ausgewertet werden. Der show route extensive
Befehl zeigt die Aktionen für jeden Begriff (Route) an.
Überprüfung der Datenstromvalidierung
Zweck
Datenstromrouteninformationen anzeigen.
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 bei Überschreitung der Anzahl zulässiger Datenstromrouten
Zweck
Wenn Sie eine Obergrenze für die Anzahl der installierten Datenstromrouten konfigurieren, wie in Begrenzung der Anzahl der in einer Routing-Tabelle installierten Datenstromroutenbeschrieben, sehen Sie die Systemprotokollnachricht an, wenn der Schwellenwert 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 bei Überschreitung der Anzahl der in einer BGP-Peering-Sitzung empfangenen Präfixe
Zweck
Wenn Sie eine Obergrenze für die Anzahl der installierten Datenstromrouten konfigurieren, wie in Begrenzung der Anzahl der auf einer BGP-Peering-Sitzung empfangenen Präfixebeschrieben, sehen Sie die Systemprotokollnachricht an, wenn der Schwellenwert erreicht ist.
Aktion
Führen Sie im Betriebsmodus den show log message Befehl aus.
Wenn Sie die Anweisungsoption teradown <percentage>
angeben:
user@host> show log message Jul 12 08:44:47 host rpd[2748]: 10.12.99.2 (External AS 65001): Shutting down peer due to exceeding configured maximum prefix-limit(1000) for inet-flow nlri: 1001
Wenn Sie die Anweisungsoption drop-excess <percentage>
angeben:
user@host> show log message Jul 27 15:26:57 R1_re rpd[32443]: BGP_DROP_PREFIX_LIMIT_EXCEEDED: 1.1.1.2 (Internal AS 1): Exceeded drop-excess maximum prefix-limit(4) for inet-unicast nlri: 5 (instance master)
Wenn Sie die Anweisungsoption hide-excess <percentage>
angeben:
user@host> show log message Jul 27 15:26:57 R1_re rpd[32443]: BGP_HIDE_PREFIX_LIMIT_EXCEEDED: 1.1.1.2 (Internal AS 1): Exceeded hide-excess maximum prefix-limit(4) for inet-unicast nlri: 5 (instance master)
Beispiel: Konfigurieren von BGP zur Übertragung von IPv6-Datenstrom-Spezifikationsrouten
In diesem Beispiel wird gezeigt, wie sie die IPv6-Datenstromspezifikation für das Filtern des Datenverkehrs konfigurieren. Die BGP-Datenflussspezifikation kann zur Automatisierung der domainübergreifenden und domäneninternen Koordination von Regeln zur Datenverkehrsfilterung verwendet werden, um Denial-of-Service-Angriffe zu verhindern.
Anforderungen
In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:
Zwei Router der MX-Serie
Junos OS Version 16.1 oder höher
Bevor Sie BGP die Übertragung von IPv6-Datenstromspezifikationsrouten aktivieren:
Konfigurieren Sie IP-Adressen an den Geräteschnittstellen.
Konfigurieren Sie BGP.
Konfigurieren Sie eine Routing-Richtlinie, die Routen (z. B. statische Routen, direkte Routen oder IGP-Routen) aus der Routingtabelle in BGP exportiert.
Überblick
Die Datenstromspezifikation bietet Schutz vor Denial-of-Service-Angriffen und beschränkt schlechten Datenverkehr, der die Bandbreite verbraucht und ihn in der Nähe der Quelle stoppt. In früheren Junos OS-Versionen wurden Datenstromspezifikationsregeln für IPv4 über BGP als Erreichbarkeitsinformationen für Netzwerkschichten weitergegeben. Beginnend mit Junos OS Version 16.1 wird die Funktion zur Datenstromspezifikation in der IPv6-Familie unterstützt und ermöglicht die Verbreitung von Datenstromspezifikationsregeln für IPv6 und IPv6 VPN.
Topologie
Abbildung 7 zeigt die Beispieltopologie. Router R1 und Router R2 gehören zu verschiedenen autonomen Systemen. Die IPv6-Datenstromspezifikation wird auf Router R2 konfiguriert. Der gesamte eingehende Datenverkehr wird basierend auf den Datenstromspezifikationsbedingungen gefiltert und der Datenverkehr wird je nach der angegebenen Aktion unterschiedlich behandelt. In diesem Beispiel wird die gesamte Datenverkehrsüberschrift zu abcd::11:11:11:10/128, die mit den Datenstromspezifikationsbedingungen übereinstimmt, verworfen; während der Datenverkehr zu abcd::11:11:11:30/128 bestimmt ist und die Bedingungen der Datenstromspezifikation erfüllt.

Konfiguration
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für die Netzwerkkonfiguration erforderlich sind, kopieren Und fügen Sie die Befehle auf Hierarchieebene in die [edit] CLI ein und geben Sie dann aus dem Konfigurationsmodus ein commit
.
Router R1
set interfaces ge-1/1/4 unit 0 family inet6 address abcd::13:14:2:1/120 set interfaces lo0 unit 0 family inet6 address abcd::128:220:21:197/128 set routing-options router-id 128.220.21.197 set routing-options autonomous-system 64496 set protocols bgp group ebgp type external set protocols bgp group ebgp family inet6 unicast set protocols bgp group ebgp family inet6 flow set protocols bgp group ebgp peer-as 64497 set protocols bgp group ebgp neighbor abcd::13:14:2:2
Router R2
set interfaces ge-1/0/0 unit 0 family inet6 address abcd::192:2:1:1/120 set interfaces ge-1/1/5 unit 0 family inet6 address abcd::13:14:2:2/120 set interfaces lo0 unit 0 family inet6 address abcd::128:220:41:229/128 set routing-options rib inet6.0 static route abcd::11:11:11:0/120 next-hop abcd::192:2:1:2 set routing-options rib inet6.0 flow route route-1 match destination abcd::11:11:11:10/128 set routing-options rib inet6.0 flow route route-1 match protocol tcp set routing-options rib inet6.0 flow route route-1 match destination-port http set routing-options rib inet6.0 flow route route-1 match source-port 65535 set routing-options rib inet6.0 flow route route-1 then discard set routing-options rib inet6.0 flow route route-2 match destination abcd::11:11:11:30/128 set routing-options rib inet6.0 flow route route-2 match icmp6-type echo-request set routing-options rib inet6.0 flow route route-2 match packet-length 100 set routing-options rib inet6.0 flow route route-2 match dscp 10 set routing-options rib inet6.0 flow route route-2 then accept set routing-options router-id 128.220.41.229 set routing-options autonomous-system 64497 set protocols bgp group ebgp type external set protocols bgp group ebgp family inet6 unicast set protocols bgp group ebgp family inet6 flow set protocols bgp group ebgp export redis set protocols bgp group ebgp peer-as 64496 set protocols bgp group ebgp neighbor abcd::13:14:2:1 set policy-options policy-statement redis from protocol static set policy-options policy-statement redis then accept
Konfigurieren von Router R2
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie in verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI-Benutzerhandbuch.
So konfigurieren Sie Router R2:
Wiederholen Sie diese Vorgehensweise für Router R1, nachdem Sie die entsprechenden Schnittstellennamen, Adressen und anderen 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 das Feature 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
Bedingungen für die Datenstromspezifikation angeben.
[edit routing-options] user@R2# set rib inet6.0 flow route route-1 match destination abcd::11:11:11:10/128 user@R2# set rib inet6.0 flow route route-1 match protocol tcp user@R2# set rib inet6.0 flow route route-1 match destination-port http user@R2# set rib inet6.0 flow route route-1 match source-port 65535
Konfigurieren Sie eine discard Aktion, um Pakete zu verwerfen, die den angegebenen Übereinstimmungsbedingungen entsprechen.
[edit routing-options] user@R2# set rib inet6.0 flow route route-1 then discard
Bedingungen für die Datenstromspezifikation angeben.
[edit routing-options] user@R2# set rib inet6.0 flow route route-2 match destination abcd::11:11:11:30/128 user@R2# set rib inet6.0 flow route route-2 match icmp6-type echo-request user@R2# set rib inet6.0 flow route route-2 match packet-length 100 user@R2# set rib inet6.0 flow route route-2 match dscp 10
Konfigurieren einer accept Aktion zum Akzeptieren von Paketen, die den angegebenen Übereinstimmungsbedingungen entsprechen
[edit routing-options] user@R2# set rib inet6.0 flow route route-2 then accept
Definieren Sie eine Richtlinie, die es BGP ermöglicht, statische Routen zu akzeptieren.
[edit policy-options] user@R2# set policy-statement redis from protocol static user@R2# set policy-statement redis then accept
Ergebnisse
Bestätigen Sie Im Konfigurationsmodus Ihre Konfiguration durch Eingabe der show interfacesBefehle , , show protocolsshow routing-optionsundshow policy-options. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
[edit] user@R2# show interfaces ge-1/0/0 { unit 0 { family inet6 { address abcd::192:2:1:1/120; } } } ge-1/1/5 { unit 0 { family inet6 { address abcd::13:14:2:2/120; } } } lo0 { unit 0 { family inet6 { address abcd::128:220:41:229/128; } } }
[edit] user@R2# show protocols bgp { group ebgp { type external; family inet6 { unicast; flow; } export redis; peer-as 64496; neighbor abcd::13:14:2:1; } }
[edit] user@R2# show routing-options rib inet6.0 { static { route abcd::11:11:11:0/120 next-hop abcd::192:2:1:2; } flow { route route-1 { match { destination abcd::11:11:11:10/128; protocol tcp; destination-port http; source-port 65535; } then discard; } route route-2 { match { destination abcd::11:11:11:30/128; icmp6-type echo-request; packet-length 100; dscp 10; } then accept; } } } router-id 128.220.41.229; autonomous-system 64497;
[edit] user@R2# show policy-options policy-statement redis { from protocol static; then accept; }
Überprüfung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
- Überprüfen des Vorhandenseins von IPv6-Datenstromspezifikationsrouten in der inet6Flow-Tabelle
- Überprüfen der BGP-Zusammenfassungsinformationen
- Überprüfung der Datenstromvalidierung
- Überprüfung der Datenstromspezifikation für IPv6-Routen
Überprüfen des Vorhandenseins von IPv6-Datenstromspezifikationsrouten in der inet6Flow-Tabelle
Zweck
Zeigen Sie die Routen in der Tabelle in den inet6flow
Routern R1 und R2 an, und überprüfen Sie, ob BGP die Datenflussrouten gelernt hat.
Aktion
Führen Sie im Betriebsmodus den Befehl auf Router show route table inet6flow.0 extensive 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.229
Führen Sie im Betriebsmodus den Befehl auf Router show route table inet6flow.0 extensive R2 aus.
user@R2> show route table inet6flow.0 extensive inet6flow.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) abcd::11:11:11:10/128,*,proto=6,dstport=80,srcport=65535/term:1 (1 entry, 1 announced) TSI: KRT in dfwd; Action(s): discard,count Page 0 idx 0, (group pe-v6 type External) Type 1 val 0xaec8850 (adv_entry) Advertised metrics: Nexthop: Self AS path: [64497] Communities: traffic-rate:64497:0 Path abcd::11:11:11:10/128,*,proto=6,dstport=80,srcport=65535 Vector len 4. Val: 0 *Flow Preference: 5 Next hop type: Fictitious, Next hop index: 0 Address: 0x9b24064 Next-hop reference count: 3 State: <Active> Local AS: 64497 Age: 14:21 Validation State: unverified Task: RT Flow Announcement bits (2): 0-Flow 1-BGP_RT_Background AS path: I Communities: traffic-rate:64497:0 abcd::11:11:11:30/128,*,proto=17,port=65535/term:2 (1 entry, 1 announced) TSI: KRT in dfwd; Action(s): accept,count Page 0 idx 0, (group pe-v6 type External) Type 1 val 0xaec8930 (adv_entry) Advertised metrics: Nexthop: Self AS path: [64497] Communities: Path abcd::11:11:11:30/128,*,proto=17,port=65535 Vector len 4. Val: 0 *Flow Preference: 5 Next hop type: Fictitious, Next hop index: 0 Address: 0x9b24064 Next-hop reference count: 3 State: <Active> Local AS: 64497 Age: 14:21 Validation State: unverified Task: RT Flow Announcement bits (2): 0-Flow 1-BGP_RT_Background AS path: I
Bedeutung
Das Vorhandensein von Routen abcd::11:11:11:10/128 und abcd::11:11:11:30/128 in der inet6flow
Tabelle bestätigt, dass BGP die Flussrouten gelernt hat.
Überprüfen der BGP-Zusammenfassungsinformationen
Zweck
Vergewissern Sie sich, dass die BGP-Konfiguration korrekt ist.
Aktion
Führen Sie im Betriebsmodus den Befehl auf den show bgp summary Routern R1 und R2 aus.
user@R1> show bgp summary Groups: 1 Peers: 1 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet6.0 1 1 0 0 0 0 inet6flow.0 2 2 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... abcd::13:14:2:2 2000 58 58 0 2 19:48 Establ inet6.0: 1/1/1/0 inet6flow.0: 2/2/2/0 user@R2> show bgp summary Groups: 1 Peers: 1 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet6.0 0 0 0 0 0 0 inet6flow.0 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... abcd::13:14:2:1 64496 51 52 0 0 23:03 Establ inet6.0: 0/0/0/0 inet6flow.0: 0/0/0/0
Bedeutung
Vergewissern Sie sich, dass die inet6.0
Tabelle die BGP-Nachbaradresse enthält und mit ihrem BGP-Nachbarn eine Peering-Sitzung eingerichtet wurde.
Überprüfung der Datenstromvalidierung
Zweck
Datenstromrouteninformationen anzeigen.
Aktion
Führen Sie im Betriebsmodus den Befehl auf Router show route flow validation 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: Consistent
Bedeutung
Die Ausgabe zeigt die Datenstromrouten in der inet6.0
Tabelle an.
Überprüfung der Datenstromspezifikation für IPv6-Routen
Zweck
Zeigen Sie die Anzahl der Pakete an, die verworfen und basierend auf den angegebenen Datenstromspezifikationsrouten akzeptiert werden.
Aktion
Führen Sie im Betriebsmodus den Befehl auf Router show firewall filter_flowspec_default_inet6_ R2 aus.
user@R2> show firewall filter __flowspec_default_inet6__ Filter: __flowspec_default_inet6__ Counters: Name Bytes Packets abcd::11:11:11:10/128,*,proto=6,dstport=80,srcport=65535 0 0 abcd::11:11:11:30/128,*,proto=17,port=65535 6395472 88826
Bedeutung
Die Ausgabe zeigt an, dass Pakete, die für abcd::11:11:11:10/128 bestimmt sind, verworfen werden und 88826 Pakete für die Route abcd::11:11:11:11:11:30/128 akzeptiert wurden.
Konfigurieren der BGP Flow-Spezifikationsaktion Weiterleitung an IP zum Filtern von DDoS-Datenverkehr
Ab Junos OS Version 18.4R1 wird die BGP-Datenstromspezifikation, wie in BGP Flow-Spec Internet Draft draft-ietf-idr-flowspec-redirect-ip-02.txt beschrieben, Redirect to IP Action unterstützt. Umleitung zu IP-Aktionen verwendet erweiterte BGP-Community zur Bereitstellung von Filterungsoptionen für den Datenverkehr zur DDoS-Abschwächung in Dienstanbieternetzwerken. Legacy Flow Specification Redirect to IP verwendet das BGP Nexthop-Attribut. Junos OS wirbt standardmäßig mithilfe der erweiterten Community für umleitend zu Aktionen zur IP-Datenstromspezifikation. Diese Funktion ist zur Unterstützung der Serviceverkettung im virtual Service Control Gateway (vSCG) erforderlich. Umleitung zur IP-Aktion ermöglicht die Umleitung des Datenverkehrs der übereinstimmenden Datenstromspezifikation zu einer global erreichbaren 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 mit der Umleitung des Datenverkehrs zu IP für BGP-Datenstromspezifikationsrouten beginnen, gehen Sie wie folgt vor:
Konfigurieren Sie die Geräteschnittstellen.
Konfigurieren Sie OSPF oder ein anderes IGP-Protokoll.
Konfigurieren Sie MPLS und LDP.
Konfigurieren Sie BGP.
Konfigurieren Sie die Weiterleitung zur IP-Funktion mithilfe der erweiterten BGP-Community.
Konfigurieren Sie die Umleitung der Legacy-Datenstromspezifikation zur IP-Funktion mithilfe des nexthop-Attributs.
Mithilfe der erweiterten BGP-Community und der älteren Umleitung zur Next-Hop-IP-Adresse können Sie keine Richtlinien so konfigurieren, dass der Datenverkehr an eine IP-Adresse weitergeleitet wird.
Konfigurieren Sie die im Internet draft-ietf-idr-flowspec-redirect-ip-00.txt angegebene Umleitung der Legacy-Datenstromspezifikation zu IP, BGP Flow-Spec Erweiterte Community für Datenverkehr Weiterleitung auf IP Next Hop umfasst auf Hierarchieebene.
[edit group bgp-group neighbor bgp neighbor family inet flow] user@host# set legacy-redirect-ip-action
Definieren Sie eine Richtlinie, die dem Next Hop-Attribut entspricht.
[edit policy options] user@host#policy statement policy_name user@host#from community community-name user@host#from next-hop ip-address
Definieren Sie beispielsweise eine Richtlinie p1, um den Datenverkehr an die NEXT-Hop-IP-Adresse 10.1.1.1 umzuleiten.
[edit policy options] user@host#policy statement p1 user@host#from community redirnh user@host#from next-hop 10.1.1.1
Definieren Sie eine Richtlinie zum Festlegen, Hinzufügen oder Löschen der BGP-Community mithilfe des Next Hop-Attributs für die Legacy-Datenstromspezifikation Umleitung zur IP-Aktion.
[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 legen Sie eine BGP-Community-Redirnh fest, oder löschen Sie sie, um den DDoS-Datenverkehr an die NÄCHSTE Hop-IP-Adresse 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
Siehe auch
extended-community
.