BGP-Ursprungsvalidierung
Grundlegendes zur Ursprungsvalidierung für BGP
Die Herkunftsvalidierung hilft, die unbeabsichtigte Ankündigung von Routen zu verhindern. Manchmal kündigen Netzwerkadministratoren fälschlicherweise Routen zu Netzwerken an, die sie nicht kontrollieren. Sie können dieses Sicherheitsproblem beheben, indem Sie die Ursprungsvalidierung (auch als sicheres domänenübergreifendes Routing bezeichnet) konfigurieren. Die Ursprungsvalidierung ist ein Mechanismus, mit dem Routenankündigungen als von einem erwarteten autonomen System (Expected Autonomous System, AS) stammend authentifiziert werden können. Bei der Ursprungsvalidierung werden ein oder mehrere RPKI-Cacheserver (Resource Public Key Infrastructure) verwendet, um die Authentifizierung für bestimmte BGP-Präfixe durchzuführen. Um ein Präfix zu authentifizieren, fragt der Router (BGP-Lautsprecher) die Datenbank der validierten Präfix-zu-AS-Zuordnungen ab, die vom Cache-Server heruntergeladen werden, und stellt sicher, dass das Präfix von einem erwarteten AS stammt.
Vor den Junos OS-Versionen 20.1R3, 20.2R3, 20.3R2, 20.4R2, 21.1R1 öffnete Junos OS den TCP-Port 2222 automatisch und ohne vorherige Ankündigung, wenn Sie die RPKI-Authentifizierung aktivierten. Sie können einen Filter anwenden, um diesen Port zu blockieren und zu sichern.
Ab den Junos OS-Versionen 20.1R3, 20.2R3, 20.3R2, 20.4R2, 21.1R1 öffnet Junos OS die TCP-Ports 2222 nicht mehr automatisch, wenn Sie die RPKI-Authentifizierung aktivieren.
Junos OS unterstützt die Ursprungsvalidierung für IPv4- und IPv6-Präfixe.
Abbildung 1 zeigt eine Beispieltopologie.
- Unterstützte Standards
- So funktioniert die Ursprungsvalidierung
- BGP-Interaktion mit der Routenvalidierungsdatenbank
- Community-Attribut zur Bekanntgabe des RPKI-Validierungsstatus an IBGP-Nachbarn
- Nonstop Active Routing und Ursprungsvalidierung
- Markieren eines Präfixbereichs als "Nie zulässig"
Unterstützte Standards
Die Junos OS-Implementierung der Ursprungsvalidierung unterstützt die folgenden RFCs und Entwürfe:
RFC 6810, Das Resource Public Key Infrastructure (RPKI)-to-Router-Protokoll
RFC 6811, Ursprungsvalidierung von BGP-Präfixen
Internet-Entwurf draft-ietf-sidr-origin-validation-signaling-00, BGP-Präfix Origin Validation State, Extended Community (teilweise Unterstützung)
Die erweiterte Community (Ursprungsvalidierungsstatus) wird in der Routing-Richtlinie von Junos OS unterstützt. Die angegebene Änderung im Routenauswahlverfahren wird nicht unterstützt.
So funktioniert die Ursprungsvalidierung
Die RPKI- und Ursprungsvalidierung verwenden X.509-Zertifikate mit Erweiterungen, die in RFC 3779, X.509-Erweiterungen für IP-Adressen und AS-Identifikatorenangegeben sind.
Das RPKI besteht aus einer verteilten Sammlung von Informationen. Jede Zertifizierungsstelle veröffentlicht ihre Endentitätszertifikate (EE), Zertifikatsperrlisten (Certificate Revocation Lists, CRLs) und signierten Objekte an einem bestimmten Speicherort. Alle diese Repositories bilden einen vollständigen Satz von Informationen, der jedem RPKI-Cache-Server zur Verfügung steht.
Jeder RPKI-Cacheserver verwaltet einen lokalen Cache der gesamten verteilten Repository-Sammlung, indem jedes Element im lokalen Cache regelmäßig mit dem ursprünglichen Repository-Veröffentlichungspunkt synchronisiert wird.
Auf dem Router werden die Datenbankeinträge als Route Validation (RV)-Datensätzeformatiert. Ein RV-Datensatz ist ein Tripel (Präfix, maximale Länge, Ursprungs-AS). Sie stimmt mit jeder Route überein, deren Präfix mit dem RV-Präfix übereinstimmt, deren Präfixlänge die im RV-Datensatz angegebene maximale Länge nicht überschreitet und deren Ursprungs-AS mit dem im RV-Datensatz angegebenen Ursprungs-AS übereinstimmt.
Ein RV-Datensatz ist eine vereinfachte Version einer Route Origin Authorization (ROA). Ein ROA ist ein digital signiertes Objekt, mit dem überprüft werden kann, ob ein Inhaber eines IP-Adressblocks einen AS autorisiert hat, Routen zu einem oder mehreren Präfixen innerhalb des Adressblocks zu erstellen. ROAs werden nicht direkt bei der Routenvalidierung verwendet. Der Cache-Server exportiert eine vereinfachte Version der ROA als RV-Eintrag an den Router.
Der Wert für die maximale Länge muss größer oder gleich der Länge des autorisierten Präfixes und kleiner oder gleich der Länge (in Bit) einer IP-Adresse in der Adressfamilie (32 für IPv4 und 128 für IPv6) sein. Die maximale Länge definiert das IP-Adresspräfix, zu dessen Ankündigung der AS berechtigt ist.
Wenn das IP-Adresspräfix beispielsweise 200.4.66/24 und die maximale Länge 26 beträgt, ist der AS berechtigt, 200.4.66.0/24, 200.4.66.0/25, 200.4.66.128/25, 200.4.66.0/26, 200.4.66.64/26, 200.4.66.128/26 und 200.4.66.192/26 anzukündigen. Wenn die maximale Länge nicht vorhanden ist, ist der AS nur berechtigt, genau das im RV angegebene Präfix anzukündigen.
Als weiteres Beispiel kann ein RV das Präfix 200.4.66/24 mit einer maximalen Länge von 26 sowie das Präfix 200.4.66.0/28 mit einer maximalen Länge von 28 enthalten. Dieses RV würde den AS ermächtigen, jedes Präfix zu bewerben, das mit 200.4.66 beginnt und eine Länge von mindestens 24 und nicht größer als 26 hat, sowie das spezifische Präfix 200.4.66.0/28.
Der Ursprung einer Route wird durch die AS-Nummer ganz rechts im Attribut AS_PATH dargestellt. Bei der Ursprungsvalidierung wird der Ursprungs-AS in einer Routing-Aktualisierung mit dem autorisierten Quell-AS verglichen, der in RV-Datensätzen veröffentlicht wurde.
Es ist bekannt, dass die Sicherheit, die allein durch die Ursprungsvalidierung geboten wird, gegen einen entschlossenen Angreifer schwach ist, da es keinen Schutz vor einem solchen Angreifer gibt, der die Quell-AS fälscht. Die Ursprungsvalidierung bietet jedoch einen nützlichen Schutz vor versehentlichen Ankündigungen.
Obwohl die Ursprungsvalidierung dadurch implementiert werden könnte, dass jeder Router direkt am RPKI teilnimmt, wird dies als zu ressourcenintensiv (da viele Public-Key-Kryptografieoperationen zur Validierung der RPKI-Daten erforderlich sind) sowie als zu betriebsintensiv angesehen, um eine RPKI-Konfiguration auf jedem Router einzurichten und zu verwalten. Aus diesem Grund führt ein separater RPKI-Cacheserver Validierungen mit öffentlichen Schlüsseln durch und generiert eine validierte Datenbank mit Präfix-zu-AS-Zuordnungen. Die validierte Datenbank wird über eine sichere TCP-Verbindung auf einen Client-Router heruntergeladen. Der Router benötigt daher nur wenige Informationen über die RPKI-Infrastruktur und hat außer dem verschlüsselten Transportkennwort keine Anforderungen an die Public-Key-Kryptographie. Der Router verwendet anschließend die heruntergeladenen Daten, um empfangene Routenaktualisierungen zu validieren.
Wenn Sie Serversitzungen konfigurieren, können Sie die Sitzungen gruppieren und Sitzungsparameter für jede Sitzung in der Gruppe konfigurieren. Der Router versucht in regelmäßigen Abständen, eine konfigurierbare maximale Anzahl von Verbindungen zu Cache-Servern einzurichten. Wenn der Verbindungsaufbau fehlschlägt, wird in regelmäßigen Abständen ein neuer Verbindungsversuch unternommen.
In der Zwischenzeit, nachdem die Validierungsimportrichtlinie auf die BGP-Sitzung angewendet wurde, wird die Routenvalidierung unabhängig vom Status der Cache-Sitzung (aktiv oder inaktiv) und der RV-Datenbank (leer oder nicht leer) durchgeführt. Wenn die RV-Datenbank leer ist oder keine der Cacheserversitzungen aktiv ist, wird der Validierungsstatus für jede Route auf unbekannt festgelegt, da kein RV-Eintrag vorhanden ist, um ein empfangenes BGP-Präfix auszuwerten.
Der Wiederholungsversuchszeitraum ist konfigurierbar. Nach erfolgreicher Verbindung mit einem Cache-Server fragt der Router die neueste Seriennummer der Datenbank ab und fordert den RPKI-Cache auf, alle RV-Einträge zu übertragen, die zu dieser Version der Datenbank gehören.
Jede eingehende Nachricht setzt einen Lebendigkeitstimer für den RPKI-Cache-Server zurück. Nachdem alle Updates gelernt wurden, führt der Router regelmäßige Lebendigkeitsprüfungen durch, die auf einem konfigurierbaren Intervall basieren. Dazu wird eine PDU (Serial Query Protocol Data Unit) mit derselben Seriennummer gesendet, die der Cacheserver in seiner letzten Benachrichtigungs-PDU gemeldet hat. Der Cacheserver antwortet mit null oder mehr Aktualisierungen und einer EOD-PDU (End-of-Data), wodurch auch der Lebendigkeitsstatus des Cacheservers aktualisiert und ein Timer für die Datensatzlebensdauer zurückgesetzt wird.
Wenn ein Präfix von einem externen BGP-Peer (EBGP) empfangen wird, wird es von einer Importrichtlinie untersucht und als Gültig, Ungültig, Unbekannt oder Nicht verifiziert markiert:
Gültig: Gibt an, dass das Präfix und das AS-Paar in der Datenbank gefunden wurden.
Ungültig – Gibt an, dass das Präfix gefunden wurde, aber entweder ist der entsprechende AS, der vom EBGP-Peer empfangen wird, nicht der AS, der in der Datenbank angezeigt wird, oder die Präfixlänge in der BGP-Aktualisierungsnachricht ist länger als die maximal zulässige Länge in der Datenbank.
Unbekannt: Gibt an, dass das Präfix nicht zu den Präfixen oder Präfixbereichen in der Datenbank gehört.
Nicht überprüft: Gibt an, dass der Ursprung des Präfixes nicht anhand der Datenbank überprüft wurde. Dies liegt daran, dass die Datenbank aufgefüllt wurde und die Validierung in der BGP-Importrichtlinie nicht gefordert wird, obwohl die Ursprungsvalidierung aktiviert ist oder die Ursprungsvalidierung für die BGP-Peers nicht aktiviert ist.
Wenn es potenzielle Übereinstimmungen für die Route in der Validierungsdatenbank gibt, muss die Route mit einer davon übereinstimmen, um gültig zu sein. Andernfalls ist sie ungültig. Jede Übereinstimmung ist ausreichend, um die Route gültig zu machen. Es muss nicht unbedingt die beste Übereinstimmung sein. Nur wenn es keine potenziellen Übereinstimmungen gibt, wird die Route als unbekannt betrachtet. Weitere Informationen zur Datenbanklogik für die Zuordnung von Präfixen zu ASs finden Sie in Abschnitt 2 des Internetentwurfs draft-ietf-sidr-pfx-validate-01, BGP Prefix Origin Validation.
Die RPKI-Validierung ist nur in der primären Instanz verfügbar. Wenn Sie die RPKI-Validierung für eine Routing-Instanz konfigurieren, schlägt die RPKI-Validierung mit der folgenden Fehlermeldung RV instance is not runningfehl.
BGP-Interaktion mit der Routenvalidierungsdatenbank
Die RV-Datenbank (Route Validation) enthält eine Sammlung von RV-Einträgen, die der Router vom RPKI-Cache-Server herunterlädt. Nachdem die RV-Datenbank mit RV-Einträgen aufgefüllt wurde, durchsucht die RV-Datenbank die RIB-Local-Routing-Tabelle, um festzustellen, ob es Präfixe in RIB-Local gibt, die von den RV-Einträgen in der Datenbank betroffen sein könnten. (RIB-Local enthält die IPv4- und IPv6-Routen, die in der Ausgabe des show route protocol bgp Befehls angezeigt werden.)
Dieser Prozess löst eine BGP-Neubewertung der BGP-Importrichtlinien (nicht der Exportrichtlinien) aus.
Abbildung 2 zeigt den Prozess.
Importrichtlinien werden auf RIB-In angewendet. Eine andere Möglichkeit, dies zu verstehen, besteht darin, dass Importrichtlinien auf die Routen angewendet werden, die in der Ausgabe des show route receive-protocol bgp Befehls angezeigt werden, während Exportrichtlinien auf Routen angewendet werden, die show route advertising-protocol bgp vom Befehl angezeigt werden.
Wie in Abbildung 3gezeigt, verwenden Sie Import-Routing-Richtlinien, um zu steuern, welche Routen BGP in der Routing-Tabelle platziert, und Export-Routing-Richtlinien, um zu steuern, welche Routen BGP von der Routing-Tabelle zu ihren Nachbarn ankündigt.
Wenn Sie eine Importrichtlinie für die Routenvalidierung konfigurieren, verwendet die Richtlinienkonfiguration eine validation-database Übereinstimmungsbedingung. Diese Übereinstimmungsbedingung löst eine Abfrage in der RV-Datenbank nach dem Validierungsstatus eines Präfixes in einer bestimmten Routing-Instanz aus. Der Standardvorgang besteht darin, die Validierungsdatenbank abzufragen, die der Routinginstanz entspricht. Wenn keine Routingvalidierungsinstanz gefunden wird, wird die primäre Instanz abgefragt.
In der folgenden BGP-Importrichtlinie löst die from validation-database Bedingung eine Suche in der RV-Datenbank des Routers aus. Eine Aktion wird ausgeführt, wenn der Validierungsstatus gültig ist. Die Aktion besteht darin, die Route zu akzeptieren und die validation-state in der Routing-Tabelle auf gültig zu setzen.
[edit protocols bgp] import validation;
[edit policy-options]
policy-statement validation-1 {
term valid {
from {
protocol bgp;
validation-database valid; # Triggers a lookup in the RV database
}
then {
validation-state valid; # Sets the validation state in the routing table
accept;
}
}
}
Community-Attribut zur Bekanntgabe des RPKI-Validierungsstatus an IBGP-Nachbarn
Die Präfixvalidierung erfolgt nur für externe BGP-Updates (EBGP). Innerhalb eines AS möchten Sie wahrscheinlich nicht, dass auf jedem internen BGP-Router (IBGP) eine RPKI-Sitzung ausgeführt wird. Stattdessen benötigen Sie eine Möglichkeit, den Validierungsstatus über das IBGP-Mesh zu übertragen, damit alle IBGP-Sprecher über konsistente Informationen verfügen. Dies wird erreicht, indem der Validierungszustand in einer nicht-transitiven erweiterten Gemeinschaft übertragen wird. Das community-Attribut kündigt den Validierungsstatus eines Präfixes zwischen IBGP-Nachbarn an und empfängt ihn.
Junos OS unterstützt die folgenden bekannten erweiterten Communitys für die Routenvalidierung:
origin-validation-state-valid
origin-validation-state-invalid
ursprünglicher-validierungsstatus-unbekannt
Die folgende Beispiel-BGP-Importrichtlinie ist auf dem Router konfiguriert, der eine Sitzung mit einem RPKI-Server hat.
Router mit RPKI-Sitzung
policy-statement validation-1 {
term valid {
from {
protocol bgp;
validation-database valid;
}
then {
validation-state valid;
community add origin-validation-state-valid;
accept;
}
}
}
Die folgende Beispiel-BGP-Importrichtlinie ist auf einem IBGP-Peer-Router konfiguriert, der keine Sitzung mit einem RPKI-Server hat.
IBGP-Peer-Router ohne RPKI-Sitzung
policy-statement validation-2 {
term valid {
from community origin-validation-state-valid;
then validation-state valid;
}
}
Nonstop Active Routing und Ursprungsvalidierung
Wenn Sie die Ursprungsvalidierung auf einem Router konfigurieren, der über zwei Routing-Engines verfügt und das unterbrechungsfreie aktive Routing aktiviert ist, verfügen sowohl die primäre als auch die Standby-Routing-Engine über eine Kopie der RV-Datenbank. Diese beiden RV-Datenbanken bleiben miteinander synchronisiert.
Der Router unterhält nicht zwei identische Sitzungen mit dem RPKI-Server. Das RPKI-RTR-Protokoll läuft nur auf der primären Routing-Engine. In der Standby-Routing-Engine ist die RPKI-Cacheserversitzung immer ausgefallen.
Die RV-Datenbank wird von der primären Routing-Engine während ihrer Sitzung mit dem RPKI-Server aktiv verwaltet. Diese Datenbank wird auf der Standby-Routing-Engine repliziert. Obwohl die Sitzung auf der Standby-Routing-Engine ausgefallen ist, enthält die replizierte RV-Datenbank RV-Datensätze. Wenn die Standby-Routing-Engine umgeschaltet und zur primären Routing-Engine wird, verfügt sie bereits über eine vollständig aufgefüllte RV-Datenbank.
Um den Inhalt der beiden Datenbanken anzuzeigen, verwenden Sie die show validation database Befehle und show validation replication database .
Markieren eines Präfixbereichs als "Nie zulässig"
Das Routenvalidierungsmodell weist einen großen Nachteil auf: Es gibt nur positive Updates. Er kann deklarieren, welcher AS der rechtmäßige Besitzer eines Präfixes ist. Es kann jedoch nicht explizit ein negatives Update vermitteln, wie in: Dieses Präfix wird niemals von einem bestimmten AS erstellt. Diese Funktionalität kann bis zu einem gewissen Grad mithilfe einer AS 0-Problemumgehung bereitgestellt werden.
Die Junos OS-Implementierung versucht nicht, ihre Eingaben aus dem Cache einzuschränken. Beispielsweise wird ein RV-Datensatz mit dem Ursprung AS 0 installiert und wie jeder andere abgeglichen. Dadurch kann eine Problemumgehung einen Präfixbereich als nie angekündigt markieren, da AS 0 kein gültiger AS ist. Der AS im RV-Datensatz stimmt nie mit dem AS überein, der vom EBGP-Peer empfangen wurde. Daher wird jedes übereinstimmende Präfix als ungültig markiert.
Siehe auch
Anwendungsfall und Nutzen der Herkunftsvalidierung für BGP
Wenn ein Administrator eines autonomen Systems (Autonomous System, AS) beginnt, das gesamte oder einen Teil des zugewiesenen Netzwerks eines anderen Unternehmens zu bewerben, verfügt BGP über keine integrierte Methode, um den Fehler zu erkennen und so zu reagieren, dass Serviceunterbrechungen vermieden werden.
Angenommen, ein Administrator in einem Kundennetzwerk kündigt fälschlicherweise eine Route (z. B. 10.65.153.0/24) an, die den Datenverkehr an den Service Provider AS 1 des Kunden weiterleitet. Bei dieser /24-Route handelt es sich um eine spezifischere Route als die, die vom eigentlichen Inhaltsanbieter (10.65.152.0/22) verwendet wird, der den Datenverkehr an AS 2 weiterleitet. Aufgrund der Funktionsweise von Routern wählen die meisten Router die spezifischere Route und senden Datenverkehr an AS 1 statt an AS 2.
Das gekaperte Präfix ist im Internet weit verbreitet, da Transit-Router die aktualisierten Pfadinformationen weitergeben. Die ungültigen Routen können weit über das Internet verteilt werden, da die Router in der standardmäßigen freien Zone (DFZ) die gekaperte Route übertragen. Schließlich wird der korrekte AS-Pfad zu den BGP-Peers wiederhergestellt, aber in der Zwischenzeit ist mit Serviceunterbrechungen zu rechnen.
Da BGP auf einem transitiven Vertrauensmodell basiert, ist die Validierung zwischen Kunde und Anbieter wichtig. Im obigen Beispiel hat der Dienstanbieter AS 1 die fehlerhafte Ankündigung für 10.65.153.0/24 nicht validiert. Durch die Annahme dieser Werbung und die erneute Werbung bei seinen Kollegen und Anbietern propagierte AS 1 den falschen Weg. Die Router, die diese Route von AS 1 erhielten, wählten sie aus, da es sich um eine spezifischere Route handelte. Der eigentliche Inhaltsanbieter warb für 10.65.152.0/22, bevor der Fehler auftrat. Die /24 war eine kleinere (und spezifischere) Werbung. Gemäß dem üblichen BGP-Routenauswahlprozess wurde dann die /24 ausgewählt, wodurch die Entführung effektiv abgeschlossen wurde.
Selbst bei schneller Erkennung und Reaktion des Inhaltsanbieters und der Zusammenarbeit mit anderen Anbietern kann der Dienst für deren Vorwahl für viele Minuten bis zu mehreren Stunden unterbrochen werden. Die genaue Dauer des Ausfalls hängt von Ihrem Standpunkt im Internet ab. Wenn diese Art von Ereignissen eintritt, besteht ein erneutes Interesse an Lösungen für diese Schwachstelle. BGP ist für die Beziehungen zu Anbietern von grundlegender Bedeutung und wird in absehbarer Zeit nicht verschwinden. In diesem Beispiel wird eine Lösung veranschaulicht, die die Ursprungsüberprüfung verwendet. Diese Lösung basiert auf kryptografischen Erweiterungen für BGP und einem verteilten Client-Server-Modell, das eine Überlastung der Router-CPUs vermeidet.
Die Ursprungsvalidierung trägt dazu bei, die Schwachstelle der transitiven Vertrauensstellung zu überwinden, indem sie es einem Anbieter ermöglicht, die von einem Kunden akzeptierte Werbung einzuschränken. Die Mechanik umfasst die Kommunikation von Routing-Richtlinien, die auf einem erweiterten BGP-Community-Attribut basieren.
Siehe auch
Beispiel: Konfigurieren der Ursprungsvalidierung für BGP
In diesem Beispiel wird gezeigt, wie die Ursprungsvalidierung zwischen BGP-Peers konfiguriert wird, indem sichergestellt wird, dass empfangene Routenankündigungen vom erwarteten autonomen System (AS) gesendet (stammend) werden. Wenn der Ursprungs-AS validiert wird, kann eine Richtlinie angeben, dass die Präfixe wiederum angekündigt werden.
Anforderungen
Für dieses Beispiel gelten die folgenden Hardware- und Softwareanforderungen:
-
RPKI-Cache-Server (Resource Public Key Infrastructure), der Software von Drittanbietern zur Authentifizierung von BGP-Präfixen verwendet.
-
Junos OS Version 12.2 oder höher, das auf dem Routinggerät ausgeführt wird, das über eine TCP-Verbindung mit dem Cache-Server kommuniziert.
Überblick
Manchmal werden Routen aufgrund von Bedienungsfehlern unbeabsichtigt beworben. Um dieses Sicherheitsproblem zu vermeiden, können Sie BGP so konfigurieren, dass der ursprüngliche AS validiert und diese ungültigen Ankündigungen zurückgewiesen werden. Diese Funktion verwendet einen Cacheserver, um Präfixe oder Präfixbereiche zu authentifizieren.
Die folgenden Konfigurationsanweisungen aktivieren die Ursprungs-AS-Validierung:
[edit routing-options] validation { group group-name { max-sessions number; session address { hold-time seconds; local-address local-ip-address; port port-number; preference number; record-lifetime seconds; refresh-time seconds; traceoptions { file filename <files number> <size size> <(world-readable | no-world-readable)>; flag flag { disable; flag-modifier; } } } static { record destination { maximum-length prefix-length { origin-autonomous-system as-number { validation-state (invalid | valid); } } } } traceoptions { file filename <files number> <size size> <world-readable | no-world-readable>; flag flag { disable; flag-modifier; } } }
In diesem Beispiel werden Standardeinstellungen für die Validierungsparameter verwendet.
Die meisten verfügbaren Konfigurationsanweisungen sind optional. Die erforderlichen Einstellungen lauten wie folgt:
validation { group group-name { session address { } } }
Die [edit routing-options validation static] Hierarchieebene ermöglicht es Ihnen, statische Datensätze auf einem Routing-Gerät zu konfigurieren und so Datensätze zu überschreiben, die von einem RPKI-Cache-Server empfangen wurden.
Zum Beispiel:
[edit routing-options validation] user@R0# set static record 10.0.0.0/16 maximum-length 24 origin-autonomous-system 200 validation-state valid
Sie können eine Routing-Richtlinie konfigurieren, die auf der Grundlage des Validierungsstatus eines Routing-Präfixes ausgeführt wird. Sie können ein Community-Attribut verwenden, um den Validierungsstatus eines Präfixes zwischen externen BGP- (EBGP) und internen BGP-Peers (IBGP) anzukündigen und zu empfangen. Die Verwendung einer Routing-Richtlinie kann auf einigen Routern bequemer sein als die Konfiguration einer Sitzung mit einem RPKI-Server. In diesem Beispiel wird die Verwendung des community-Attributs validation-state zwischen IBGP-Peers veranschaulicht.
Abbildung 4 zeigt die Beispieltopologie.
In diesem Beispiel verfügt Gerät R0 über eine IBGP-Verbindung zu Gerät R1 und eine EBGP-Verbindung zu Gerät R2. Gerät R0 empfängt RV-Datensätze (Route Validation – RV) vom Cacheserver unter Verwendung des Protokolls, das in Internetentwurf draft-ietf-sidr-rpki-rtr-19, The RPKI/Router Protocol (The RPKI/Router Protocol , zum Senden der RV-Datensätze) definiert ist. Das RPKI-Router-Protokoll läuft über TCP. Die RV-Datensätze werden von Gerät R0 verwendet, um eine lokale RV-Datenbank zu erstellen. Auf Gerät R1 wird der Validierungsstatus basierend auf der BGP-Community namens validation-state festgelegt, die mit der Route empfangen wird.
Konfiguration
- CLI-Schnellkonfiguration
- Konfigurieren des Geräts R0
- Konfigurieren von Gerät R1
- Konfigurieren von Gerät R2
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für Ihre Netzwerkkonfiguration erforderlich sind, und kopieren Sie dann die Befehle und fügen Sie sie in die CLI auf Hierarchieebene [edit] ein.
Gerät R0
set interfaces ge-1/2/0 unit 2 description to-R1 set interfaces ge-1/2/0 unit 0 family inet address 10.0.0.2/30 set interfaces ge-1/2/1 unit 0 description to-R2 set interfaces ge-1/2/1 unit 0 family inet address 10.0.0.5/30 set interfaces ge-1/2/2 unit 0 description to-cache set interfaces ge-1/2/2 unit 0 family inet address 10.0.0.9/30 set interfaces lo0 unit 0 family inet address 10.0.1.1/32 set protocols bgp group int type internal set protocols bgp group int local-address 10.0.1.1 set protocols bgp group int export send-direct set protocols bgp group int neighbor 10.1.1.1 set protocols bgp group ext type external set protocols bgp group ext import validation set protocols bgp group ext export send-direct set protocols bgp group ext peer-as 65200 set protocols bgp group ext neighbor 10.0.0.6 set protocols ospf area 0.0.0.0 interface ge-1/2/0.2 set protocols ospf area 0.0.0.0 interface lo0.0 passive set policy-options policy-statement send-direct from protocol direct set policy-options policy-statement send-direct then accept set policy-options policy-statement validation term valid from protocol bgp set policy-options policy-statement validation term valid from validation-database valid set policy-options policy-statement validation term valid then validation-state valid set policy-options policy-statement validation term valid then community add origin-validation-state-valid set policy-options policy-statement validation term valid then accept set policy-options policy-statement validation term invalid from protocol bgp set policy-options policy-statement validation term invalid from validation-database invalid set policy-options policy-statement validation term invalid then validation-state invalid set policy-options policy-statement validation term invalid then community add origin-validation-state-invalid set policy-options policy-statement validation term invalid then reject set policy-options policy-statement validation term unknown from protocol bgp set policy-options policy-statement validation term unknown then validation-state unknown set policy-options policy-statement validation term unknown then community add origin-validation-state-unknown set policy-options policy-statement validation term unknown then accept set policy-options community origin-validation-state-invalid members 0x4300:0.0.0.0:2 set policy-options community origin-validation-state-unknown members 0x4300:0.0.0.0:1 set policy-options community origin-validation-state-valid members 0x4300:0.0.0.0:0 set routing-options autonomous-system 65100 set routing-options validation group test session 10.0.0.10
Gerät R1
set interfaces ge-1/2/0 unit 0 family inet address 10.0.0.1/30 set interfaces lo0 unit 0 family inet address 10.1.1.1/32 set protocols bgp group int type internal set protocols bgp group int local-address 10.1.1.1 set protocols bgp group int import validation-ibgp set protocols bgp group int neighbor 10.0.1.1 set protocols ospf area 0.0.0.0 interface ge-1/2/0.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set policy-options policy-statement validation-ibgp term valid from community origin-validation-state-valid set policy-options policy-statement validation-ibgp term valid then validation-state valid set policy-options policy-statement validation-ibgp term invalid from community origin-validation-state-invalid set policy-options policy-statement validation-ibgp term invalid then validation-state invalid set policy-options policy-statement validation-ibgp term unknown from community origin-validation-state-unknown set policy-options policy-statement validation-ibgp term unknown then validation-state unknown set policy-options community origin-validation-state-invalid members 0x4300:0.0.0.0:2 set policy-options community origin-validation-state-unknown members 0x4300:0.0.0.0:1 set policy-options community origin-validation-state-valid members 0x4300:0.0.0.0:0 set routing-options autonomous-system 65100
Gerät R2
set interfaces ge-1/2/0 unit 0 family inet address 10.0.0.6/30 set interfaces lo0 unit 0 family inet address 172.16.1.1/32 set interfaces lo0 unit 0 family inet address 192.168.2.3/32 set protocols bgp group ext export send-direct set protocols bgp group ext peer-as 65100 set protocols bgp group ext neighbor 10.0.0.5 set policy-options policy-statement send-direct from protocol direct set policy-options policy-statement send-direct from protocol local set policy-options policy-statement send-direct then accept set routing-options autonomous-system 65200
Konfigurieren des Geräts R0
Schritt-für-Schritt-Anleitung
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Weitere Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI-Benutzerhandbuch.
So konfigurieren Sie Gerät R0:
-
Konfigurieren Sie die Schnittstellen.
[edit interfaces] user@R0# set ge-1/2/0 unit 0 description to-R1 user@R0# set ge-1/2/0 unit 0 family inet address 10.0.0.2/30 user@R0# set ge-1/2/1 unit 0 description to-R2 user@R0# set ge-1/2/1 unit 0 family inet address 10.0.0.5/30 user@R0# set ge-1/2/2 unit 0 description to-cache user@R0# set ge-1/2/2 unit 0 family inet address 10.0.0.9/30 user@R0# set lo0 unit 0 family inet address 10.0.1.1/32
-
Konfigurieren Sie BGP.
Wenden Sie die
send-directExportrichtlinie so an, dass direkte Routen aus der Routing-Tabelle in BGP exportiert werden.Wenden Sie die
validationImportrichtlinie an, um den Validierungsstatus und die BGP-Community-Attribute für alle Routen festzulegen, die von den EBGP-Peers von Gerät R0 importiert (oder empfangen) wurden.Konfigurieren Sie eine IBGP-Sitzung mit Gerät R1. Konfigurieren Sie eine EBGP-Sitzung mit Gerät R2.
[edit protocols bgp] user@R0# set group int type internal user@R0# set group int local-address 10.0.1.1 user@R0# set group int export send-direct user@R0# set group int neighbor 10.1.1.1 user@R0# set group ext type external user@R0# set group ext import validation user@R0# set group ext export send-direct user@R0# set group ext peer-as 65200 user@R0# set group ext neighbor 10.0.0.6
-
Konfigurieren Sie OSPF (oder ein anderes Interior Gateway Protocol [IGP]) auf der Schnittstelle, die dem IBGP-Peer zugewandt ist, und auf der Loopback-Schnittstelle.
HINWEIS:Wenn Sie die Loopback-Schnittstellenadresse in der IBGP-Anweisung
neighborverwenden, müssen Sie eine IGP auf der Loopback-Schnittstelle aktivieren. Andernfalls wird die IBGP-Sitzung nicht eingerichtet.[edit protocols ospf area 0.0.0.0] user@R0# set interface ge-1/2/0.0 user@R0# set interface lo0.0 passive
-
Konfigurieren Sie die Routing-Richtlinie, die direkte Routen aus der Routing-Tabelle in BGP exportiert.
[edit policy-options policy-statement send-direct] user@R0# set from protocol direct user@R0# set then accept
-
Konfigurieren Sie die Routing-Richtlinie, die Attribute angibt, die basierend auf dem Validierungsstatus jeder BGP-Route geändert werden sollen.
[edit policy-options policy-statement validation] user@R0# set term valid from protocol bgp user@R0# set term valid from validation-database valid user@R0# set term valid then validation-state valid user@R0# set term valid then community add origin-validation-state-valid user@R0# set term valid then accept user@R0# set term invalid from protocol bgp user@R0# set term invalid from validation-database invalid user@R0# set term invalid then validation-state invalid user@R0# set term invalid then community add origin-validation-state-invalid user@R0# set term invalid then reject user@R0# set term unknown from protocol bgp user@R0# set term unknown then validation-state unknown user@R0# set term unknown then community add origin-validation-state-unknown user@R0# set term unknown then accept [edit policy-options] user@R0# set community origin-validation-state-invalid members 0x4300:0.0.0.0:2 user@R0# set community origin-validation-state-unknown members 0x4300:0.0.0.0:1 user@R0# set community origin-validation-state-valid members 0x4300:0.0.0.0:0
-
Konfigurieren Sie die Sitzung mit dem RPKI-Cacheserver.
[edit routing-options validation] user@R0# set group test session 10.0.0.10
-
Konfigurieren Sie die AS-Nummer (Autonomous System).
[edit routing-options] user@R0# set autonomous-system 65100
Ergebnisse
Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie die show interfacesBefehle , show protocols, show policy-optionsund show routing-options eingeben. Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@R0# show interfaces
ge-1/2/0 {
unit 0 {
description to-R1;
family inet {
address 10.0.0.2/30;
}
}
}
ge-1/2/1 {
unit 0 {
description to-R2;
family inet {
address 10.0.0.5/30;
}
}
}
ge-1/2/2 {
unit 0 {
description to-cache;
family inet {
address 10.0.0.9/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.0.1.1/32;
}
}
}
user@R0# show protocols
bgp {
group int {
type internal;
local-address 10.0.1.1;
export send-direct;
neighbor 10.1.1.1;
}
group ext {
type external;
import validation;
export send-direct;
peer-as 65200;
neighbor 10.0.0.6;
}
}
ospf {
area 0.0.0.0 {
interface ge-1/2/0.0;
interface lo0.0 {
passive;
}
}
}
user@R0# show policy-options
policy-statement send-direct {
from protocol direct;
then accept;
}
policy-statement validation {
term valid {
from {
protocol bgp;
validation-database valid;
}
then {
validation-state valid;
community add origin-validation-state-valid;
accept;
}
}
term invalid {
from {
protocol bgp;
validation-database invalid;
}
then {
validation-state invalid;
community add origin-validation-state-invalid;
reject;
}
}
term unknown {
from protocol bgp;
then {
validation-state unknown;
community add origin-validation-state-unknown;
accept;
}
}
}
community origin-validation-state-invalid members 0x4300:0.0.0.0:2;
community origin-validation-state-unknown members 0x4300:0.0.0.0:1;
community origin-validation-state-valid members 0x4300:0.0.0.0:0;
}
user@R0# show routing-options
autonomous-system 65100;
validation {
group test {
session 10.0.0.10;
}
}
Wenn Sie mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf commit .
Konfigurieren von Gerät R1
Schritt-für-Schritt-Anleitung
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Weitere Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI-Benutzerhandbuch.
So konfigurieren Sie Gerät R1:
-
Konfigurieren Sie die Schnittstellen.
[edit interfaces] user@R1# set ge-1/2/0 unit 0 family inet address 10.0.0.1/30 user@R1# set lo0 unit 0 family inet address 10.1.1.1/32
-
Konfigurieren Sie BGP.
Wenden Sie die
validation-ibgpImportrichtlinie an, um den Validierungsstatus und die BGP-Community-Attribute für alle Routen festzulegen, die von den IBGP-Peers von Gerät R1 empfangen werden.Konfigurieren Sie eine IBGP-Sitzung mit Gerät R0.
[edit protocols bgp group int] user@R1# set type internal user@R1# set local-address 10.1.1.1 user@R1# set import validation-ibgp user@R1# set neighbor 10.0.1.1
-
Konfigurieren Sie OSPF.
[edit protocols ospf area 0.0.0.0] user@R1# set interface ge-1/2/0.0 user@R1# set interface lo0.0 passive
-
Konfigurieren Sie die Routing-Richtlinie, die Attribute angibt, die basierend auf dem BGP-Community-Attribut des Validierungsstatus der von Gerät R0 empfangenen BGP-Routen geändert werden sollen.
[edit policy-options policy-statement validation-ibgp] user@R1# set term valid from community origin-validation-state-valid user@R1# set term valid then validation-state valid user@R1# set term invalid from community origin-validation-state-invalid user@R1# set term invalid then validation-state invalid user@R1# set term unknown from community origin-validation-state-unknown user@R1# set term unknown then validation-state unknown [edit policy-options] user@R1# set community origin-validation-state-invalid members 0x4300:0.0.0.0:2 user@R1# set community origin-validation-state-unknown members 0x4300:0.0.0.0:1 user@R1# set community origin-validation-state-valid members 0x4300:0.0.0.0:0
-
Konfigurieren Sie die AS-Nummer (Autonomous System).
[edit routing-options] user@R1# set autonomous-system 65100
Ergebnisse
Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie die show interfacesBefehle , show protocols, show policy-optionsund show routing-options eingeben. Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@R1# show interfaces
ge-1/2/0 {
unit 0 {
family inet {
address 10.0.0.1/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.1.1.1/32;
}
}
}
user@R1# show protocols
bgp {
group int {
type internal;
local-address 10.1.1.1;
import validation-ibgp;
neighbor 10.0.1.1;
}
}
ospf {
area 0.0.0.0 {
interface ge-1/2/0.0;
interface lo0.0 {
passive;
}
}
}
user@R1# show policy-options
policy-statement validation-ibgp {
term valid {
from community origin-validation-state-valid;
then validation-state valid;
}
term invalid {
from community origin-validation-state-invalid;
then validation-state invalid;
}
term unknown {
from community origin-validation-state-unknown;
then validation-state unknown;
}
}
community origin-validation-state-invalid members 0x4300:0.0.0.0:2;
community origin-validation-state-unknown members 0x4300:0.0.0.0:1;
community origin-validation-state-valid members 0x4300:0.0.0.0:0;
}
user@R1# show routing-options autonomous-system 65100;
Wenn Sie mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf commit .
Konfigurieren von Gerät R2
Schritt-für-Schritt-Anleitung
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Weitere Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI-Benutzerhandbuch.
So konfigurieren Sie Gerät R2:
-
Konfigurieren Sie die Schnittstellen.
Auf der Loopback-Schnittstelle sind mehrere Adressen konfiguriert, die zu Demonstrationszwecken als Routen dienen.
[edit interfaces] user@R2# set ge-1/2/0 unit 0 family inet address 10.0.0.6/30 user@R2# set lo0 unit 0 family inet address 172.16.1.1/32 user@R2# set lo0 unit 0 family inet address 192.168.2.3/32
-
Konfigurieren Sie BGP.
[edit protocols bgp] user@R2# set group ext export send-direct user@R2# set group ext peer-as 65100 user@R2# set group ext neighbor 10.0.0.5
-
Konfigurieren Sie die Routing-Richtlinie.
[edit policy-options policy-statement send-direct] user@R2# set from protocol direct user@R2# set from protocol local user@R2# set then accept
-
Konfigurieren Sie die AS-Nummer (Autonomous System).
[edit routing-options] user@R2# set autonomous-system 65200
Ergebnisse
Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie die show interfacesBefehle , show protocols, show policy-optionsund show routing-options eingeben. Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@R2# show interfaces
ge-1/2/0 {
unit 0 {
family inet {
address 10.0.0.6/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 172.16.1.1/32;
address 192.168.2.3/32;
}
}
}
user@R2# show protocols
bgp {
group ext {
export send-direct;
peer-as 65100;
neighbor 10.0.0.5;
}
}
user@R2# show policy-options
policy-statement send-direct {
from protocol [ direct local ];
then accept;
}
user@R2# show routing-options autonomous-system 65200;
Wenn Sie mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf commit .
Verifizierung
Vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.
- Überprüfen, ob die geänderten Attribute in den Routing-Tabellen angezeigt werden
- Verwenden von Ablaufverfolgungsvorgängen
- Anzeigen von Validierungsinformationen
Überprüfen, ob die geänderten Attribute in den Routing-Tabellen angezeigt werden
Zweck
Stellen Sie sicher, dass die BGP-Routen auf Gerät R0 und Gerät R1 die erwarteten Validierungszustände und die erwarteten lokalen Einstellungen aufweisen.
Action!
Geben Sie im Betriebsmodus den show route Befehl ein.
user@R0> show route
inet.0: 12 destinations, 13 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.1.1/32 *[Direct/0] 04:53:39
> via lo0.1
10.1.1.1/32 *[OSPF/10] 04:50:53, metric 1
> to 10.0.0.1 via lt-1/2/0.2
10.0.0.0/30 *[Direct/0] 04:51:44
> via lt-1/2/0.2
10.0.0.2/32 *[Local/0] 04:51:45
Local via lt-1/2/0.2
10.0.0.4/30 *[Direct/0] 04:51:44
> via lt-1/2/0.5
[BGP/170] 02:24:57, localpref 100
AS path: 65200 I, validation-state: valid
> to 10.0.0.6 via lt-1/2/0.5
10.0.0.5/32 *[Local/0] 04:51:45
Local via lt-1/2/0.5
10.0.0.8/30 *[Direct/0] 03:01:28
> via lt-1/2/0.9
10.0.0.9/32 *[Local/0] 04:51:45
Local via lt-1/2/0.9
172.16.1.1/32 *[BGP/170] 02:24:57, localpref 100
AS path: 65200 I, validation-state: invalid
> to 10.0.0.6 via lt-1/2/0.5
192.168.2.3/32 *[BGP/170] 02:24:57, localpref 100
AS path: 65200 I, validation-state: validation-state: unknown
> to 10.0.0.6 via lt-1/2/0.5
224.0.0.5/32 *[OSPF/10] 04:53:46, metric 1
MultiRecvuser@R1> show route
inet.0: 10 destinations, 12 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.1.1/32 *[BGP/170] 00:40:52, localpref 100, from 1.0.1.1
AS path: 65200 I, validation-state: invalid
> to 10.0.0.2 via lt-1/2/0.1
192.168.2.3/32 *[BGP/170] 01:06:58, localpref 100, from 1.0.1.1
AS path: 65200 I, validation-state: unknown
> to 10.0.0.2 via lt-1/2/0.1
224.0.0.5/32 *[OSPF/10] 04:57:09, metric 1
MultiRecvBedeutung
Die Routen weisen die erwarteten Validierungszustände und lokalen Präferenzwerte auf, basierend auf Informationen, die vom RPKI-Cacheserver empfangen wurden.
Verwenden von Ablaufverfolgungsvorgängen
Zweck
Konfigurieren Sie Ablaufverfolgungsvorgänge für die Ursprungsvalidierung, und überwachen Sie die Ergebnisse einer neu angekündigten Route.
Action!
-
Konfigurieren Sie auf Gerät R0 die Ablaufverfolgung.
[edit routing-options validation traceoptions] user@R0# set file rv-tracing user@R0# set flag all user@R0# commit
-
Fügen Sie auf Gerät R2 eine Route hinzu, indem Sie eine weitere Adresse in der Loopback-Schnittstelle hinzufügen.
[edit interfaces lo0 unit 0 family inet] user@R2# set address 10.4.4.4/32 user@R2# commit
-
Überprüfen Sie auf Gerät R0 die Ablaufverfolgungsdatei.
user@R0> file show /var/log/rv-tracing Jan 27 11:27:43.804803 rv_get_policy_state: rt 10.4.4.4/32 origin-as 65200, validation result valid Jan 27 11:27:43.944037 task_job_create_background: create prio 7 job Route-validation GC for task Route Validation Jan 27 11:27:43.986580 background dispatch running job Route-validation GC for task Route Validation Jan 27 11:27:43.987374 task_job_delete: delete background job Route-validation GC for task Route Validation Jan 27 11:27:43.987463 background dispatch completed job Route-validation GC for task Route Validation
Bedeutung
Die Routenvalidierung funktioniert wie erwartet.
Anzeigen von Validierungsinformationen
Zweck
Führen Sie die verschiedenen Validierungsbefehle aus.
Action!
user@R0> show validation statistics Total RV records: 2 Total Replication RV records: 2 Prefix entries: 2 Origin-AS entries: 2 Memory utilization: 9789 bytes Policy origin-validation requests: 114 Valid: 32 Invalid: 54 Unknown: 28 BGP import policy reevaluation notifications: 156 inet.0, 156 inet6.0, 0
user@R0> show validation database RV database for instance master Prefix Origin-AS Session State Mismatch 10.0.0.0/8-32 65200 10.0.0.10 valid 172.0.0.0/8-12 65200 10.0.0.10 invalid IPv4 records: 2 IPv6 records: 0
user@R0> show validation replication database RRV replication database for instance master Prefix Origin-AS Session State 10.0.0.0/8-32 65200 10.0.0.10 valid 172.0.0.0/8-12 65200 10.0.0.10 invalid IPv4 records: 2 IPv6 records: 0
user@R0> show validation group
master
Group: test, Maximum sessions: 2
Session 10.0.0.10, State: Connect, Preference: 100user@R0> show validation session Session State Flaps Uptime #IPv4/IPv6 records 10.0.0.10 Up 0 00:02:28 1/0
user@R0> request validation policy Enqueued 2 IPv4 records Enqueued 0 IPv6 records