Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

BGP-Ursprungsvalidierung

Verstehen der Ursprungsvalidierung für BGP

Die Ursprungsvalidierung hilft, die unbeabsichtigte Anzeige von Routen zu verhindern. Manchmal werben Netzwerkadministratoren versehentlich Routen zu Netzwerken, die sie nicht kontrollieren. Sie können dieses Sicherheitsproblem durch Konfigurieren der Ursprungsvalidierung (auch bekannt als sicheres Interdomain-Routing) beheben. Bei der Ursprungsvalidierung handelt es sich um einen Mechanismus, über den Route-Advertisements als Ursprungsauthentifizierung von einem erwarteten autonomen System (AS) durchgeführt werden können. Die Ursprungsvalidierung verwendet einen oder mehrere Resource Public Key Infrastructure (RPKI)-Cache-Server, um die Authentifizierung für bestimmte BGP-Präfixe durchzuführen. Um ein Präfix zu authentifizieren, fragt der Router (BGP-Speaker) die Datenbank validierter Prefix-to-AS-Zuordnungen ab, die vom Cache-Server heruntergeladen werden, und stellt sicher, dass das Präfix von einem erwarteten AS stammt.

Anmerkung:

Wenn Sie die RPKI-Authentifizierung aktivieren, öffnet Junos OS den TCP-Port 2222 automatisch und ohne vorherige Ankündigung. Sie können einen Filter anwenden, um diesen Port zu blockieren und zu sichern.

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, The Resource Public Key Infrastructure (RPKI) to Router Protocol

  • RFC 6811, BGP Prefix Origin Validation

  • Internet draft draft-ietf-sidr-origin-validation-signaling-00, BGP Prefix 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.

Funktionsweise der Ursprungsvalidierung

Die RPKI- und Ursprungsvalidierung verwenden X.509-Zertifikate mit in RFC 3779, X.509 Extensions für IP-Adressen und AS Identifiers angegebenen Erweiterungen.

Das RPKI besteht aus einer verteilten Sammlung von Informationen. Jede Zertifizierungsstelle veröffentlicht ihre End-Entity-Zertifikate (EE), Zertifikats-Widerrufslisten (Certificate Revocation Lists, CRLs) und unterzeichnete Objekte an einem bestimmten Standort. Alle diese Repositorys bilden einen vollständigen Satz von Informationen, die für jeden RPKI-Cache-Server verfügbar sind.

Jeder RPKI-Cache-Server verwaltet einen lokalen Cache der gesamten Sammlung verteilter Repositorys, 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ätze formatiert. Ein RV-Datensatz ist ein Triple (Präfix, maximale Länge, Ursprungs-AS). Er entspricht jeder Route, 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 dem im RV-Datensatz angegebenen Ursprung ENTSPRICHT.

Ein RV-Datensatz ist eine vereinfachte Version einer Routenursprungsautorisierung (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 routen. ROAs werden nicht direkt bei der Routenvalidierung verwendet. Der Cache-Server exportiert eine vereinfachte Version des ROA als RV-Datensatz an den Router.

Der Maximale Längenwert muss größer oder gleich der Länge des autorisierten Präfixes und kleiner oder gleich der Länge (in Bits) einer IP-Adresse in der Adressfamilie sein (32 für IPv4 und 128 für IPv6). Die maximale Länge definiert das IP-Adressen-Präfix, das vom AS zur Werbung autorisiert wird.

Wenn das IP-Adressen-Präfix beispielsweise 200.4.66/24 und die maximale Länge 26 ist, ist der AS autorisiert, 200.4.66.0/24, 200.4.66.0/25 zu werben, 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. Wenn die maximale Länge nicht vorhanden ist, ist der AS nur autorisiert, genau das im RV angegebene Präfix zu werben.

Ein weiteres Beispiel: Ein RV kann 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. Dieser RV autorisiert den AS, jedes Präfix zu werben, das mit 200.4.66 beginnt, mit einer Länge von mindestens 24 und nicht größer als 26, sowie das spezifische Präfix 200.4.66.0/28.

Der Ursprung einer Route wird im Attribut AS_PATH mit der höchsten AS-Nummer rechts dargestellt. Die Ursprungsvalidierung wird durchgeführt, indem der Ursprungs-AS in einem Routing-Update mit der in RV-Datensätzen veröffentlichten autorisierten Quelle AS verglichen wird.

Allein die durch Ursprungsvalidierung bereitgestellte Sicherheit ist bekanntermaßen schwach gegen einen bestimmten Angreifer, da es keinen Schutz gegen einen solchen Angreifer gibt, der die Quell-AS manipuliert. Die Ursprungsvalidierung bietet jedoch einen nützlichen Schutz vor versehentlichen Ankündigungen.

Obwohl die Ursprungsvalidierung implementiert werden könnte, indem jeder Router direkt an der RPKI teilnimmt, wird dies als zu ressourcenintensiv angesehen (da viele Verschlüsselungsvorgänge mit öffentlichem Schlüssel für die Validierung der RPKI-Daten erforderlich sind) und als betriebsintensiv, um eine RPKI-Konfiguration auf jedem Router einzurichten und zu pflegen. Aus diesem Grund führt ein separater RPKI-Cache-Server Validierungen mit öffentlichem Schlüssel durch und generiert eine validierte Datenbank mit Prefix-to-AS-Zuordnungen. Die validierte Datenbank wird über eine sichere TCP-Verbindung auf einen Client-Router heruntergeladen. Der Router benötigt daher nur wenig Informationen über die RPKI-Infrastruktur und stellt keine verschlüsselungsfähigen öffentlichen Schlüssel außer dem verschlüsselten Übertragungskennwort. Der Router verwendet anschließend die heruntergeladenen Daten, um empfangene Routenaktualisierungen zu validieren.

Wenn Sie Serversitzungen konfigurieren, können Sie die Sitzungen zusammen gruppieren und Sitzungsparameter für jede Sitzung in der Gruppe konfigurieren. Der Router versucht regelmäßig, eine konfigurierbare maximale Anzahl von Verbindungen zu Cache-Servern einzurichten. Wenn die Verbindungseinrichtung ausfällt, wird regelmäßig ein neuer Verbindungsversuch durchgeführt.

In der Zwischenzeit wird die Routenvalidierung unabhängig vom Cache-Sitzungsstatus (up oder down) und der RV-Datenbank (leer oder nicht leer) durchgeführt, nachdem die Validierungsimportrichtlinie auf die BGP-Sitzung angewendet wurde. Wenn die RV-Datenbank leer ist oder keine der Cache-Serversitzungen eingerichtet ist, wird der Validierungsstatus für jede Route auf unbekannt festgelegt, da kein RV-Datensatz zur Bewertung eines empfangenen BGP-Präfixes vorhanden ist.

Der Wiederholungsversuchszeitraum ist konfigurierbar. Nach der erfolgreichen Verbindung mit einem Cache-Server fragt der Router nach der neuesten Datenbank-Seriennummer ab und fordert an, dass der RPKI-Cache alle RV-Einträge überträgt, die zu dieser Version der Datenbank gehören.

Jede eingehende Nachricht setzt einen Liveliness-Timer für den RPKI-Cache-Server zurück. Nachdem alle Updates erlernt sind, führt der Router regelmäßig Anhand eines konfigurierbaren Intervalls Prüfungen der Lebendigkeit durch. Dies geschieht durch Senden einer seriellen Abfrageprotokolldateneinheit (PDU) mit der gleichen Seriennummer, die der Cache-Server in seiner neuesten Benachrichtigungs-PDU gemeldet hat. Der Cache-Server reagiert mit null oder mehr Updates und einer End-of-Data (EOD)-PDU, die auch den Liveliness-Status des Cache-Servers aktualisiert und einen Record-Lifetime-Timer zurücksetzt.

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 bestätigt markiert:

  • Gültig – Gibt an, dass das Präfix- und AS-Paar in der Datenbank gefunden wird.

  • Ungültig: Gibt an, dass das Präfix gefunden wird, aber entweder der vom EBGP-Peer empfangene AS ist nicht die in der Datenbank angezeigte AS oder die Präfixlänge in der BGP-Update-Nachricht ist länger als die in der Datenbank zulässige maximale Länge.

  • Unbekannt: Gibt an, dass das Präfix nicht zu den Präfixen oder Prefix-Bereichen in der Datenbank gehört.

  • Nicht geprüft – Gibt an, dass der Ursprung des Präfixes nicht mit der Datenbank überprüft wird. Dies liegt daran, dass die Datenbank ausgefüllt wurde und die Validierung in der BGP-Importrichtlinie nicht aufgerufen 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 dieser Routen übereinstimmen, um gültig zu sein. Andernfalls ist es ungültig. Jede Übereinstimmung reicht aus, um die Route gültig zu machen. Es muss nicht die beste Übereinstimmung sein. Nur wenn es keine potenziellen Übereinstimmungen gibt, wird die Route als unbekannt angesehen. Weitere Informationen zur Prefix-to-AS-Zuordnungsdatenbanklogik finden Sie in Abschnitt 2 des Internet draft-ietf-sidr-pfx-validate-01, BGP Prefix Origin Validation.

Anmerkung:

Die RPKI-Validierung ist nur in der primären Instanz verfügbar. Wenn Sie die RPKI-Validierung für eine Routinginstanz konfigurieren, schlägt die RPKI-Validierung mit der folgenden Fehlermeldung RV instance is not runningfehl.

BGP-Interaktion mit der Routenvalidierungsdatenbank

Die Routenvalidierungsdatenbank (RV) enthält eine Sammlung von RV-Datensätzen, die der Router vom RPKI-Cacheserver herunterlädt. Nachdem die RV-Datenbank mit RV-Datensätzen gefüllt ist, scannt die RV-Datenbank die RIB-Lokale Routingtabelle, um festzustellen, ob es Präfixe in RIB-Local gibt, die von den RV-Datensätzen in der Datenbank betroffen sein könnten. (RIB-Local enthält die in der Ausgabe des show route protocol bgp Befehls angezeigten IPv4- und IPv6-Routen.)

Dieser Prozess löst eine BGP-Neubewertung der BGP-Importrichtlinien aus (nicht der Exportrichtlinien).

Abbildung 2 zeigt den Prozess.

Abbildung 2: BGP- und Routenvalidierung

Importrichtlinien werden auf RIB-In angewendet. Eine weitere Möglichkeit, dies zu verstehen, ist, 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 3dargestellt, verwenden Sie Importrouting-Richtlinien, um zu steuern, welche Routen BGP-Orte in der Routingtabelle platziert, und Exportieren von Routingrichtlinien, um zu steuern, welche Routen BGP von der Routingtabelle zu ihren Nachbarn angibt.

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 Übereinstimmungsbedingung validation-database . Diese Übereinstimmungsbedingung löst in der RV-Datenbank eine Abfrage des Validierungsstatus eines Präfixes in einer bestimmten Routinginstanz aus. Der Standardvorgang besteht darin, die Validierungsdatenbank abzufragen, die der Routinginstanz entspricht. Wenn keine Routenvalidierungsinstanz 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. Wenn der Validierungsstatus gültig ist, wird eine Aktion durchgeführt. Die Aktion besteht darin, die Route zu akzeptieren und die in der validation-state Routing-Tabelle auf gültig festzulegen.

Community-Attribut zur Ankündigung des RPKI-Validierungsstatus für IBGP-Nachbarn

Die Präfixvalidierung erfolgt nur für externe BGP (EBGP)-Aktualisierungen. In einem AS möchten Sie wahrscheinlich nicht, dass eine RPKI-Sitzung auf jedem internen BGP (IBGP)-Router ausgeführt wird. Stattdessen benötigen Sie eine Möglichkeit, den Validierungsstatus über das IBGP-Mesh zu übertragen, damit alle IBGP-Lautsprecher konsistente Informationen haben. Dies wird durch das Tragen des Validierungsstatus in einer nicht transitiven erweiterten Community erreicht. Das Community-Attribut gibt den Validierungsstatus eines Präfixes zwischen IBGP-Nachbarn an und empfängt diesen.

Junos OS unterstützt die folgenden bekannten erweiterten Communitys für die Routenvalidierung:

  • origin-validation-state-valid

  • origin-validation-state-invalid

  • origin-validation-state-unknown

Die folgende Beispiel-BGP-Importrichtlinie wird auf dem Router konfiguriert, der eine Sitzung mit einem RPKI-Server hat.

Router mit RPKI-Sitzung

Die folgende Beispiel-BGP-Importrichtlinie wird auf einem IBGP-Peer-Router konfiguriert, der keine Sitzung mit einem RPKI-Server hat.

IBGP-Peer-Router ohne RPKI-Sitzung

Unterbrechungsfreie aktive Routing- und Ursprungsvalidierung

Wenn Sie die Ursprungsvalidierung auf einem Router konfigurieren, der über zwei Routing-Engines verfügt und unterbrechungsfreies aktives Routing aktiviert ist, haben sowohl die primären als auch die Standby-Routing-Engines eine Kopie der RV-Datenbank. Diese beiden RV-Datenbanken bleiben miteinander synchronisiert.

Der Router unterhält keine zwei identischen Sitzungen mit dem RPKI-Server. Das RPKI-RTR-Protokoll wird nur auf der primären Routing-Engine ausgeführt. In der Standby-Routing-Engine ist die RPKI-Cache-Serversitzung immer deaktiviert.

Die RV-Datenbank wird durch die primäre Routing-Engine aktiv über ihre Sitzung mit dem RPKI-Server verwaltet. Diese Datenbank wird auf der Standby-Routing-Engine repliziert. Obwohl die Sitzung in der Standby-Routing-Engine ausfällt, enthält die replizierte RV-Datenbank RV-Datensätze. Wenn die Standby-Routing-Engine umschaltet und zur primären Routing-Engine wird, verfügt sie bereits über eine vollständig gefüllte RV-Datenbank.

Um den Inhalt der beiden Datenbanken anzuzeigen, verwenden Sie die show validation database Und-Befehle show validation replication database .

Markieren eines Prefix-Bereichs als nie zulässig

Das Routenvalidierungsmodell hat ein großes Manko: Es bietet nur positive Updates. Er kann deklarieren, welcher AS der legitime Eigentümer eines Präfixes ist. Ein negatives Update kann jedoch nicht explizit übermittelt werden, wie in: Dieses Präfix stammt nie von einem bestimmten AS. Diese Funktionalität kann in gewissem Maße mit einer AS 0-Problemumgehung bereitgestellt werden.

Die Junos OS-Implementierung versucht nicht, ihre Eingaben aus dem Cache zu beschränken. Beispielsweise wird ein RV-Datensatz mit Ursprung AS 0 installiert und wie jeder andere angepasst. Dies ermöglicht eine Problemumgehung, einen Prefix-Bereich als nie angekündigt zu kennzeichnen, da AS 0 keine gültige AS ist. Der AS im RV-Datensatz entspricht nie dem vom EBGP-Peer erhaltenen AS. Daher wird jedes übereinstimmende Präfix als ungültig markiert.

Anwendungsszenario und Nutzen der Ursprungsvalidierung für BGP

Wenn ein Administrator eines autonomen Systems (AS) beginnt, das gesamte oder einen Teil des zugewiesenen Netzwerks eines anderen Unternehmens zu werben, verfügt BGP über keine integrierte Methode, um den Fehler zu erkennen und so zu reagieren, dass Serviceunterbrechungen vermieden werden.

Nehmen wir zum Beispiel an, dass ein Administrator in einem Kundennetzwerk versehentlich eine Route (sagen wir 10.65.153.0/24) anwirbt, die den Datenverkehr an den Service Provider des Kunden AS 1 leitet. Diese /24-Route ist eine spezifischere Route als die des tatsächlichen Inhaltsanbieters (10.65.152.0/22), die den Datenverkehr zu AS 2 leitet. Aufgrund der Funktionsweise von Routern wählen die meisten Router die spezifischere Route aus und senden Datenverkehr an AS 1 anstelle von AS 2.

Das entführte Präfix wird im Internet weit verbreitet, wenn Transitrouter die aktualisierten Pfadinformationen verbreiten. Die ungültigen Routen können weit über das Internet verteilt werden, da die Router in der Default Free Zone (DFZ) die entführte Route tragen. Schließlich wird der richtige AS-Pfad zu BGP-Peers wiederhergestellt, aber in der Zwischenzeit sind Serviceunterbrechungen zu erwarten.

Da BGP auf einem transitiven Vertrauensmodell basiert, ist eine Validierung zwischen Kunde und Anbieter wichtig. Im obigen Beispiel hat der Service Provider AS 1 die fehlerhafte Anzeige für 10.65.153.0/24 nicht validiert. Da AS 1 diese Werbung akzeptiert und an ihre Peers und Anbieter zurücksendete, verbreitete sie den falschen Weg. Die Router, die diese Route von AS 1 erhielten, wählten sie, da es sich um eine spezifischere Route handelte. Der tatsächliche Inhaltsanbieter warb 10.65.152.0/22, bevor der Fehler auftrat. Die /24 war eine kleinere (und spezifischere) Werbung. Nach dem üblichen BGP-Routenauswahlprozess wurde dann die /24 ausgewählt, was die Kaperung effektiv abgeschlossen hat.

Selbst bei schneller Erkennung und Reaktion des Inhaltsanbieters und der Zusammenarbeit mit anderen Anbietern kann der Service für sein Präfix für viele Minuten bis zu mehreren Stunden unterbrochen werden. Die genaue Dauer des Ausfalls hängt von Ihrem Ausgangspunkt im Internet ab. Wenn diese Art von Ereignissen auftreten, gibt es neues Interesse an Lösungen für diese Schwachstelle. BGP ist für die Provider-Beziehungen von grundlegender Bedeutung und wird nicht in absehbarer Zeit verschwinden. In diesem Beispiel wird eine Lösung veranschaulicht, die Ursprungsvalidierung verwendet. Diese Lösung basiert auf kryptographischen BGP-Erweiterungen und einem verteilten Client-Server-Modell, das überforderte Router-CPUs vermeidet.

Die Ursprungsvalidierung hilft dabei, die Schwachstelle des transitiven Vertrauens zu überwinden, indem ein Anbieter die Von einem Kunden akzeptierte Werbung begrenzt. Die Mechanik beinhaltet die Kommunikation von Routing-Richtlinien basierend auf einem erweiterten BGP Community-Attribut.

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 Route-Advertisements vom erwarteten autonomen System (AS) gesendet (ursprünglich) gesendet werden. Wenn der Ursprungs-AS validiert wird, kann eine Richtlinie angeben, dass die Präfixe wiederum angekündigt werden.

Anforderungen

In diesem Beispiel werden die folgenden Hardware- und Softwareanforderungen erfüllt:

  • Resource Public Key Infrastructure (RPKI)-Cache-Server, der Software von Drittanbietern zur Authentifizierung von BGP-Präfixen verwendet.

  • Junos OS Version 12.2 oder höher, die auf dem Routing-Gerät ausgeführt wird, das über eine TCP-Verbindung mit dem Cache-Server kommuniziert.

Überblick

Manchmal werden Routen aufgrund von Bedienerfehlern unbeabsichtigt angekündigt. Um dieses Sicherheitsproblem zu verhindern, können Sie BGP so konfigurieren, dass die Ursprungs-AS validiert wird, und diese ungültigen Ankündigungen ablehnen. Diese Funktion verwendet einen Cache-Server zur Authentifizierung von Präfixen oder Prefix-Bereichen.

Die folgenden Konfigurationsanweisungen ermöglichen 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 Routinggerät zu konfigurieren und somit Datensätze zu überschreiben, die von einem RPKI-Cache-Server empfangen wurden.

Zum Beispiel:

Sie können eine Routing-Richtlinie konfigurieren, die auf dem Validierungsstatus eines Routenpräfixes basiert. Sie können ein Community-Attribut verwenden, um den Validierungsstatus eines Präfixes zwischen externem BGP (EBGP) und internen BGP (IBGP)-Peers anzukündigen und zu erhalten. 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 Validierungsstatus-Community-Attributs zwischen IBGP-Peers veranschaulicht.

Abbildung 4 zeigt die Beispieltopologie.

Abbildung 4: Topologie für die Ursprungsvalidierung Topologie 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 Route Validation (RV)-Datensätze vom Cache-Server unter Verwendung des in Internet draft-ietf-sidr-rpki-rtr-19, The RPKI/Router Protocol definierten Protokolls zum Senden der RV-Datensätze. Das RPKI-Router-Protokoll läuft über TCP. Die RV-Datensätze werden von Gerät R0 zum Erstellen einer lokalen RV-Datenbank verwendet. Auf Gerät R1 wird der Validierungsstatus basierend auf der BGP-Community namens Validierungsstatus 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 die Netzwerkkonfiguration erforderlich sind, und kopieren Sie dann die Befehle und fügen Sie sie auf Hierarchieebene in die [edit] CLI ein.

Gerät R0

Gerät R1

Gerät R2

Konfigurieren von Gerät R0

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 R0:

  1. Konfigurieren Sie die Schnittstellen.

  2. Konfigurieren Sie BGP.

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

    Wenden Sie die validation Importrichtlinie an, um die Attribute der Validierungsstatus- und BGP-Community für alle Routen festzulegen, die von EBGP-Peers von Gerät R0 importiert (oder empfangen) werden.

    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 und der Loopback-Schnittstelle gegenübersteht.

    Anmerkung:

    Wenn Sie die Loopback-Schnittstellenadresse in der IBGP-Anweisung neighbor verwenden, müssen Sie ein IGP auf der Loopback-Schnittstelle aktivieren. Andernfalls wird die IBGP-Sitzung nicht eingerichtet.

  4. Konfigurieren Sie die Routing-Richtlinie, die direkte Routen aus der Routingtabelle 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-Cache-Server.

  7. Konfigurieren Sie die autonome Systemnummer (AS).

Ergebnisse

Bestätigen Sie Im Konfigurationsmodus Ihre Konfiguration durch Eingabe der show interfacesBefehle , , show protocolsshow policy-optionsundshow routing-options. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Wenn Sie die Konfiguration des Geräts durchgeführt haben, geben Sie aus dem Konfigurationsmodus ein commit .

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:

  1. Konfigurieren Sie die Schnittstellen.

  2. Konfigurieren Sie BGP.

    Wenden Sie die validation-ibgp Importrichtlinie an, um die Attribute der Validierungsstatus- und BGP-Community für alle Routen festzulegen, die von IBGP-Peers von Gerät R1 empfangen wurden.

    Konfigurieren Sie eine IBGP-Sitzung mit Gerät R0.

  3. OSPF konfigurieren.

  4. Konfigurieren Sie die Routing-Richtlinie, die Attribute angibt, die basierend auf dem Validierungsstatus-Attribut der BGP-Community für die von Gerät R0 empfangenen BGP-Routen geändert werden sollen.

  5. Konfigurieren Sie die autonome Systemnummer (AS).

Ergebnisse

Bestätigen Sie Im Konfigurationsmodus Ihre Konfiguration durch Eingabe der show interfacesBefehle , , show protocolsshow policy-optionsundshow routing-options. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Wenn Sie die Konfiguration des Geräts durchgeführt haben, geben Sie aus dem Konfigurationsmodus ein commit .

Konfigurieren von Gerät R2

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 R2:

  1. Konfigurieren Sie die Schnittstellen.

    Auf der Loopback-Schnittstelle werden mehrere Adressen konfiguriert, um als Routen für Demonstrationszwecke zu dienen.

  2. Konfigurieren Sie BGP.

  3. Konfigurieren Sie die Routing-Richtlinie.

  4. Konfigurieren Sie die autonome Systemnummer (AS).

Ergebnisse

Bestätigen Sie Im Konfigurationsmodus Ihre Konfiguration durch Eingabe der show interfacesBefehle , , show protocolsshow policy-optionsundshow routing-options. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

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üfen, ob die geänderten Attribute in den Routingtabellen angezeigt werden

Zweck

Vergewissern Sie sich, dass die BGP-Routen auf Gerät R0 und Gerät R1 über den erwarteten Validierungsstatus und die erwarteten lokalen Präferenzen verfügen.

Aktion

Geben Sie im Betriebsmodus den show route Befehl ein.

Bedeutung

Die Routen haben den erwarteten Validierungsstatus und lokale Präferenzwerte, basierend auf den Informationen, die vom RPKI-Cacheserver empfangen wurden.

Verwendung von Trace-Vorgängen

Zweck

Konfigurieren Sie Trace-Vorgänge für die Ursprungsvalidierung und überwachen Sie die Ergebnisse einer neu angekündigten Route.

Aktion
  • Konfigurieren Sie die Ablaufverfolgung auf Gerät R0.

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

  • Überprüfen Sie auf Gerät R0 die Trace-Datei.

Bedeutung

Die Routenvalidierung läuft wie erwartet.

Validierungsinformationen anzeigen

Zweck

Führen Sie die verschiedenen Validierungsbefehle aus.

Aktion