Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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.

HINWEIS:

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.

Abbildung 1: Beispieltopologie für die UrsprungsvalidierungBeispieltopologie für die Ursprungsvalidierung

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.

HINWEIS:

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.

Abbildung 2: BGP und Routenvalidierung

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.

Abbildung 3: Importieren und Exportieren von Routing-RichtlinienImportieren und Exportieren von Routing-Richtlinien

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.

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

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

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.

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.

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:

In diesem Beispiel werden Standardeinstellungen für die Validierungsparameter verwendet.

Die meisten verfügbaren Konfigurationsanweisungen sind optional. Die erforderlichen Einstellungen lauten wie folgt:

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:

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.

Abbildung 4: Topologie für die UrsprungsvalidierungTopologie für die Ursprungsvalidierung

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

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

Gerät R1

Gerät R2

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:

  1. Konfigurieren Sie die Schnittstellen.

  2. Konfigurieren Sie BGP.

    Wenden Sie die send-direct Exportrichtlinie so an, dass direkte Routen aus der Routing-Tabelle in BGP exportiert werden.

    Wenden Sie die validation Importrichtlinie 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.

  3. 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 neighbor verwenden, müssen Sie eine IGP auf der Loopback-Schnittstelle aktivieren. Andernfalls wird die IBGP-Sitzung nicht eingerichtet.

  4. Konfigurieren Sie die Routing-Richtlinie, die direkte Routen aus der Routing-Tabelle in BGP exportiert.

  5. Konfigurieren Sie die Routing-Richtlinie, die Attribute angibt, die basierend auf dem Validierungsstatus jeder BGP-Route geändert werden sollen.

  6. Konfigurieren Sie die Sitzung mit dem RPKI-Cacheserver.

  7. Konfigurieren Sie die AS-Nummer (Autonomous System).

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.

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:

  1. Konfigurieren Sie die Schnittstellen.

  2. Konfigurieren Sie BGP.

    Wenden Sie die validation-ibgp Importrichtlinie 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.

  3. Konfigurieren Sie OSPF.

  4. 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.

  5. Konfigurieren Sie die AS-Nummer (Autonomous System).

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.

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:

  1. Konfigurieren Sie die Schnittstellen.

    Auf der Loopback-Schnittstelle sind mehrere Adressen konfiguriert, die zu Demonstrationszwecken als Routen dienen.

  2. Konfigurieren Sie BGP.

  3. Konfigurieren Sie die Routing-Richtlinie.

  4. Konfigurieren Sie die AS-Nummer (Autonomous System).

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.

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

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.

Bedeutung

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.

  • Fügen Sie auf Gerät R2 eine Route hinzu, indem Sie eine weitere Adresse in der Loopback-Schnittstelle hinzufügen.

  • Überprüfen Sie auf Gerät R0 die Ablaufverfolgungsdatei.

Bedeutung

Die Routenvalidierung funktioniert wie erwartet.

Anzeigen von Validierungsinformationen

Zweck

Führen Sie die verschiedenen Validierungsbefehle aus.

Action!