Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

BGP des Ursprungs

Verstehen der Ursprungsvalidierung für BGP

Die Ursprungsvalidierung hilft, unbeabsichtigte Werbung von Routen zu verhindern. Manchmal werben Netzwerkadministratoren falscherweise Routen zu Netzwerken, die sie nicht kontrollieren. Sie können dieses Sicherheitsproblem durch Konfigurieren der Ursprungsvalidierung (auch als sicheres Interdomain-Routing bezeichnet) lösen. Die Ursprungsvalidierung ist ein Mechanismus zur Authentifizierung von Routenanzeigen mit Ursprung in einem erwarteten autonomen System (AS). Die Ursprungsvalidierung verwendet einen oder mehrere Ressourcen-RPKI-Cache-Server (Public Key Infrastructure), um die Authentifizierung für bestimmte Präfixe BGP durchzuführen. Zur Authentifizierung eines Präfixs fragt der Router (BGP-Speaker) die Datenbank validierter Präfix-zu-AS-Zuordnungen ab, die vom Cache-Server heruntergeladen werden und stellt sicher, dass das Präfix von einer erwarteten AS.

Anmerkung:

Wenn Sie die RPKI-Authentifizierung aktivieren, Junos OS den TCP-Port 2222 automatisch und ohne Ankündigung öffnen. 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 an.

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) zu Router Protocol

  • RFC 6811, BGP Prefix Origin-Validierung

  • Internet draft-ietf-sidr-origin-validation-signaling-00, BGP Prefix Origin Validation State Erweiterte Community (teilweise Unterstützung)

    Die erweiterte Community (Ursprungsvalidierungsstatus) wird in der Junos OS unterstützt. Die angegebene Änderung im Routenauswahlverfahren wird nicht unterstützt.

Wie die Ursprungsvalidierung funktioniert

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

Die RPKI besteht aus einer verteilten Sammlung von Informationen. Jede Zertifizierungsstelle veröffentlicht ihre EE-Zertifikate (End-Entity), CRLs (Certificate Certification Lists) und signierte Objekte an einem bestimmten Standort. Alle diese Repositorys bilden einen vollständigen Satz von Informationen, der jedem RPKI-Cache-Server zur Verfügung steht.

Jeder RPKI-Cache-Server speichert einen lokalen Cache der gesamten verteilten Repository-Sammlung, indem jedes Element im lokalen Cache regelmäßig mit dem ursprünglichen Veröffentlichungspunkt des Repositorys synchronisiert wird.

Auf dem Router werden die Datenbankeinträge als RV-Datensätze (Route Validation) formatiert. Ein RV-Datensatz ist ein Triple (Präfix, maximale Länge, AS). Sie findet eine Route, deren Präfix mit dem RV-Präfix entspricht, deren Präfixlänge die im RV-Datensatz angegebenen maximale Länge nicht überschreitet und deren Ursprung AS dem im RV-Datensatz angegebenen AS entspricht.

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 der Inhaber der IP-Adressenblockierung einen Zugriff auf AS hat, um Routen zu einem oder mehrere Präfixe innerhalb des Adressblocks zu erstellen. ROAs werden nicht direkt für die Routenvalidierung verwendet. Der Cache-Server exportiert eine vereinfachte Version des ROA als RV-Datensatz in den Router.

Der maximale Längenwert muss größer oder gleich der Länge des autorisierten Präfixes sein und weniger als oder gleich der Länge (in Bits) einer IP-Adresse in der Adressfamilie (32 bei IPv4 und 128 bei IPv6). Die maximale Länge definiert das IP-Adressen-Präfix, zu dem der AS autorisiert ist, zu werben.

Wenn das IP-Adressen-Prä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 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 berechtigt, genau das im RV angegebene Präfix anzugeben.

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. Diese RV autorisiert den AS, beliebige Präfixe beginnend mit 200.4.66 mit einer Länge von mindestens 24 und nicht mehr als 26 sowie das spezielle Präfix 200.4.66.0/28 zu werben.

Der Ursprung einer Route wird durch die nummer rechts am AS im AS_PATH-Attribut dargestellt. Die Ursprungsvalidierung wird durch den Vergleich des AS Origin-AS in einem Routing-Update mit der autorisierten AS in RV-Datensätzen veröffentlicht.

Allein die durch die Validierung des Ursprungs bereitgestellte Sicherheit ist bekannterisch wenig gegen einen bestimmten Angreifer, da es keinen Schutz vor dem Spoofing der Quell-AS. Der Ursprung ist jedoch ein nützlicher Schutz vor versehentlichen Ankündigungen.

Obwohl die Ursprungsvalidierung implementiert werden könnte, indem jeder Router direkt in die RPKI aufgenommen wird, wird dies als zu ressourcenintensiv (da viele Verschlüsselungsvorgänge mit öffentlichen Schlüsseln für die Validierung der RPKI-Daten erforderlich sind) sowie arbeitsintensiv für die Einrichtung und Wartung einer RPKI-Konfiguration auf jedem Router. Aus diesem Grund führt ein separater RPKI-Cache-Server Public-Key-Validierungen durch und generiert eine validierte Datenbank aus Prefix-to-AS-Zuordnungen. Die validierte Datenbank wird über eine sichere TCP-Verbindung an einen Client-Router heruntergeladen. Der Router benötigt daher wenig Informationen über die RPKI-Infrastruktur und verfügt über keine verschlüsselungsspezifischen Anforderungen an den öffentlichen Schlüssel (ab hinaus vom verschlüsselten Transportkennwort). Anschließend nutzt der Router die heruntergeladenen Daten zur Validierung empfangener Routen-Updates.

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

In der Zwischenzeit wird nach der Anwendung der Importrichtlinie auf die BGP-Sitzung die Routenvalidierung unabhängig vom Cache-Sitzungsstatus (auf- oder abwärts) und der RV-Datenbank (leer oder nicht leer) durchgeführt. Wenn die RV-Datenbank leer ist oder keine Cache-Serversitzungen verfügbar sind, wird der Validierungsstatus der einzelnen Route auf unbekannt festgelegt, da kein RV-Datensatz vorhanden ist, um ein empfangenes Präfix BGP beurteilen.

Der Wiederholungszeitraum kann konfigurierbar sein. Nach der erfolgreichen Verbindung mit einem Cache-Server fragt der Router nach der aktuellen Datenbankseriennummer und fordert an, dass der RPKI-Cache alle RV-Einträge, die zu dieser Datenbankversion gehören, überträgt.

Jede eingehende Nachricht setzt einen Live-Timer für den RPKI-Cacheserver zurück. Nachdem alle Updates gelernt wurden, führt der Router regelmäßige Prüfungen der Lebensadern anhand eines konfigurierbaren Intervalls durch. Dies erfolgt durch Senden einer seriellen Query Protocol Data Unit (PDU) mit derselben Seriennummer, die der Cache-Server in seiner neuesten Benachrichtigungs-PDU gemeldet hat. Der Cache-Server reagiert mit Null oder mehr Updates und einer EOD-Du (End-of-Data), die ebenfalls den Zustand des Cache-Servers aktualisiert und einen Timer mit der Rekordlebensdauer zurückgesetzt.

Wenn ein Präfix von einem externen EBGP-Peer (BGP) empfangen wird, wird es durch eine Importrichtlinie untersucht und als gültig, ungültig, unbekannt oder nicht geprüft markiert:

  • Gültig: Gibt an, dass das Präfix- und AS paar in der Datenbank enthalten sind.

  • Ungültig: Gibt an, dass das Präfix gefunden wurde. Entweder das entsprechende AS, das vom EBGP-Peer empfangen wird, ist jedoch nicht der AS der in der Datenbank angezeigt wird, oder die Präfixlänge in der BGP-Aktualisierungsnachricht ist länger als die in der Datenbank maximal zulässige 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 in der Datenbank verifiziert wurde. Dies liegt daran, dass die Datenbank ausfüllt wird und die Validierung in der BGP-Importrichtlinie nicht erforderlich ist. Die Ursprungsvalidierung ist jedoch aktiviert oder die Ursprungsvalidierung ist für die anderen Peers BGP aktiviert.

Wenn in der Validierungsdatenbank potenzielle Treffer für die Route vorhanden sind, muss die Route mit einer übereinstimmungen, um gültig zu sein. Anderenfalls ist sie ungültig. Alle Übereinstimmungen passen dazu, dass die Route gültig wird. Sie muss nicht die beste Lösung sein. Nur wenn keine potenziellen Treffer erzielt werden können, wird der Weg als unbekannt angesehen. Weitere Informationen zur Datenbanklogik für die Zuordnung von Prefix-to-AS-Datenbank finden Sie in Abschnitt 2 des Internet draft-ietf-sidr-pfx-validate-01, BGP Prefix Origin Validation.

Anmerkung:

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

BGP Interaktion mit der Routenvalidierungsdatenbank

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

Dieser Prozess löst eine BGP neubewertung der BGP aus (nicht die Exportrichtlinien).

Abbildung 2 zeigt den Prozess an.

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 Befehls angezeigt werden, während Exportrichtlinien auf routen angewendet werden, die durch den Befehl show route receive-protocol bgp angezeigt show route advertising-protocol bgp werden.

Wie in gezeigt, verwenden Sie Import-Routingrichtlinien, um zu steuern, BGP Routen in der Routingtabelle zu routen und Routing-Richtlinien zu exportieren, um zu steuern, welche Routen BGP aus der Routingtabelle zu ihren Nachbarn aus angezeigt Abbildung 3 werden.

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 für den Validierungsstatus eines Präfixs in einer bestimmten Routinginstanz aus. Standardmäßig wird die Validierungsdatenbank, die der Routinginstanz entsprechen, abfragen. Wenn keine Routenvalidierungsinstanz gefunden wird, wird die primäre Instanz abgefragt.

In der BGP Importrichtlinie löst der Zustand eine Suche in der RV-Datenbank des from validation-database Routers aus. Wenn der Validierungsstatus gültig ist, wird eine Aktion ergriffen. Die Aktion besteht in dem Akzeptieren der Route und Festlegen validation-state der in der Routingtabelle auf gültig.

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

Die Prefix-Validierung wird nur für externe BGP (EBGP) durchgeführt. Innerhalb eines AS möchten Sie wahrscheinlich keine RPKI-Sitzung auf jedem internen BGP (IBGP) Router ausführen lassen. Stattdessen benötigen Sie eine Möglichkeit, den Validierungsstatus über das IBGP-Mesh zu tragen, damit alle IBGP-Sprecher über konsistente Informationen verfügen. Dies wird durch die Übertragung des Validierungsstatus in einer nicht transitiven erweiterten Community erreicht. Das Community-Attribut meldet und empfängt den Validierungsstatus eines Präfixes zwischen IBGP-Nachbarn.

Junos OS unterstützt die folgenden bekannten, erweiterten Communitys zur Routenvalidierung:

  • Ursprungsvalidierung – gültig

  • Ungültiger Ursprungsvalidierungsstatus

  • origin-validation-state-unknown

Im folgenden Beispiel BGP-Richtlinie wird auf dem Router mit einer Sitzung mit einem RPKI-Server konfiguriert.

Router mit RPKI-Sitzung

Das 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

Nonstop Active Routing and Origin Validation

Bei der Konfiguration der Ursprungsvalidierung auf einem Router mit doppelten Routing-Engines und aktivem Nonstop-Routing verfügen sowohl primäre als auch Standby-Routing-Engines über eine Kopie der RV-Datenbank. Diese beiden RV-Datenbanken bleiben synchronisiert.

Der Router führt keine zwei identischen Sitzungen mit dem RPKI-Server aus. Das RPKI-RTR-Protokoll wird nur auf den primären Routing-Engine ausgeführt. In der Standby-Routing-Engine rpki-Cache-Serversitzung immer aus.

Die RV-Datenbank wird durch die Routing-Engine Sitzung mit dem RPKI-Server aktiv verwaltet. Diese Datenbank wird in der Standby-Konfiguration repliziert Routing-Engine. Obwohl die Sitzung auf dem Standby-Server Routing-Engine wird, enthält die replizierte RV-Datenbank keine RV-Datensätze. Wenn die Standby Routing-Engine umgeschaltet wird und der primäre Routing-Engine wird, verfügt es bereits über eine voll gefüllte RV-Datenbank.

Verwenden Sie die und die Befehle, um die Inhalte der beiden Datenbanken show validation databaseshow validation replication database anzuzeigen.

Nie zugelassenes Prefix-Bereichs markieren

Eines der größten Defizite beim Routenvalidierungsmodell: Es liefert nur positive Updates. Er kann erklären, AS rechtmäßiger Inhaber eines Präfixes ist. Eine negative Aktualisierung kann jedoch nicht explizit übermittelt werden, wie in: Dieses Präfix hat nie ihren Ursprung in einem bestimmten AS. Diese Funktionalität kann bis zu einem gewissen Grad mithilfe von Umgehungslösung AS 0 bereitgestellt werden.

Die Junos OS-Implementierung versucht nicht, die Eingaben aus dem Cache zu beschränken. Beispielsweise wird ein RV-Datensatz mit dem Ursprung AS 0 wie jede andere installiert und darauf abgestimmt. So können Sie einen Präfixbereich kennzeichnen, der nie bekanntgegeben werden darf, da AS 0 nicht gültig AS. Der AS im RV-Datensatz entspricht nie dem Protokoll, AS vom EBGP-Peer empfangen wurde. Dementsprechend werden alle entsprechenden Präfixe als ungültig markiert.

Use Case and Benefit of Origin Validation for BGP

Wenn ein Administrator eines autonomen Systems (AS) damit beginnt, das zugewiesene Netzwerk eines anderen Unternehmens ganz oder teilweise zu werben, verfügt BGP nicht über eine integrierte Methode, um den Fehler zu erkennen und so zu reagieren, dass Serviceunterbrechungen vermieden werden.

Beispiel: Ein Administrator in einem Kundennetzwerk gibt falscherweise eine Route an (10.65.153.0/24), die Datenverkehr zum Dienstanbieter des Kunden AS 1 leitet. Diese /24-Route ist eine spezifischere Route als die Route, die vom tatsächlichen Inhaltsanbieter (10.65.152.0/22) verwendet wird und den Datenverkehr an AS 2. Aufgrund der Arbeit von Routern wählen die meisten Router die spezifischere Route aus und senden den Datenverkehr an AS 1 anstelle von AS 2.

Das kaperte Präfix wird häufig im Internet als Übertragungsrouter für die Übertragung der aktualisierten Pfadinformationen gesehen. Die ungültigen Routen können grob über das Internet verteilt werden, da die Router auf der kaperten Route in der Standard-Free Zone (DFZ) unterwegs sind. Irgendwann wird AS Pfad wieder für BGP Peers wiederhergestellt, in der Zwischenzeit sind jedoch Serviceunterbrechungen zu erwarten.

Weil BGP auf einem transitiven Vertrauensmodell basiert, ist die Validierung zwischen Kunden und Anbieter wichtig. In dem oben genannten Beispiel hat Service Provider AS 1 die fehlerhafte Werbung für 10.65.153.0/24 nicht validiert. Indem wir diese Werbung akzeptieren und an peers und provider lesen, hat AS 1 den falschen Weg verbreitet. Die Router, die diese Route von AS 1 erhielten, wählten sie aus, da es sich um eine spezifischere Route ging. Der eigentliche Inhaltsanbieter beknte 10.65.152.0/22, bevor der Fehler eintrat. Die /24 war eine kleinere (und spezifischere) Werbung. Wie immer bei der BGP Routenauswahlprozess, wurde dann der /24 gewählt, um den Kapern wirkungsvoll zu machen.

Selbst wenn Die Inhalteanbieter schnell erkannt und reaktionsschnell reagieren und mit anderen Anbietern zusammenarbeiten, kann die Dienstzeit für ihr Präfix für viele Minuten bis zu mehrere Stunden unterbrochen werden. Wie lange der Ausfall genau dauert, hängt von Ihrem Ausgangspunkt im Internet ab. Wenn solche Vorfälle auftreten, kommt wieder das Interesse an Lösungen für diese Schwachstelle auf. BGP sind für die Anbieterbeziehungen von grundlegender Bedeutung und werden in der Zukunft nicht mehr verfügbar sein. In diesem Beispiel wird eine Lösung veranschaulicht, die die Ursprungsvalidierung nutzt. Diese Lösung basiert auf Verschlüsselungserweiterungen BGP verteilten Client-Server-Modells, bei denen eine Überhappung von Router-CPUs vermieden wird.

Die Ursprungsvalidierung trägt dazu bei, die Schwachstelle transitiver Vertrauenswürdigkeit zu überwinden, indem es einem Anbieter ermöglicht, die von einem Kunden akzeptierten Werbungen zu beschränken. Zu den Mechanismen gehört die Kommunikation von Routing-Richtlinien basierend auf einem erweiterten BGP Community-Attribut.

Beispiel: Konfiguration des Ursprungsvalidierungs für BGP

In diesem Beispiel wird veranschaulicht, wie die Ursprungsvalidierung zwischen BGP-Peers konfiguriert wird, indem sichergestellt wird, dass empfangene Routenanzeigen vom erwarteten autonomen System gesendet (stammend) AS. Wenn der Ursprung AS bestätigt wird, kann eine Richtlinie angeben, dass die Präfixe s wiederum angegeben sind.

Anforderungen

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

  • RPKI-Cache-Server (Resource Public Key Infrastructure) mit Drittanbietersoftware zur Authentifizierung BGP Präfixe.

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

Überblick

Manchmal werden Routen unbeabsichtigt aufgrund von Betreiberfehlern ausgeschrieben. Um dieses Sicherheitsproblem zu vermeiden, können Sie die BGP konfigurieren, um die Ursprungs-AS zu überprüfen und diese ungültigen Ankündigungen abzulehnen. Diese Funktion verwendet einen Cache-Server zur Authentifizierung von Präfixen oder Prefix-Bereichen.

Die folgenden Konfigurationserklärungen ermöglichen die AS Ursprungsvalidierung:

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

Die meisten verfügbaren Konfigurationserklärungen sind optional. Die erforderlichen Einstellungen lauten wie folgt:

Die Hierarchieebene ermöglicht es Ihnen, statische Datensätze auf einem Routinggerät zu konfigurieren und somit die von einem RPKI-Cache-Server empfangenen [edit routing-options validation static] Datensätze zu überschreiben.

Zum Beispiel:

Sie können eine Routing-Richtlinie konfigurieren, die auf dem Validierungsstatus eines Routen-Präfixs basiert. Sie können ein Community-Attribut verwenden, um den Validierungsstatus eines Präfixes zwischen externen BGP (EBGP) und internen BGP (IBGP) Peers ankündigen und erhalten. Für einige Router ist die Verwendung einer Routing-Richtlinie bequemer als die Konfiguration einer Sitzung mit einem RPKI-Server. In diesem Beispiel wird die Verwendung des Community-Attributs für den Validierungsstatus zwischen IBGP-Peers veranschaulicht.

Abbildung 4 zeigt die Beispieltopologie an.

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) vom Cache-Server unter Verwendung des in Internet draft-ietf-sidr-rpki-rtr-19 definierten Protokolls, das RPKI/Router-Protokoll zum Senden der RV-Datensätze. Das RPKI-Router-Protokoll läuft über TCP. Die RV-Datensätze werden von Device R0 zum Aufbau einer lokalen RV-Datenbank verwendet. Auf Gerät R1 wird der Validierungsstatus basierend auf der Community BGP, die als Validierungsstatus bezeichnet wird und für die Route empfangen wird.

Konfiguration

CLI-Konfiguration

Um dieses Beispiel schnell konfigurieren zu können, kopieren Sie die folgenden Befehle, fügen Sie diese in eine Textdatei ein, entfernen Sie alle Zeilenbrüche, ändern Sie alle Details, die zur Übereinstimmung mit Ihrer Netzwerkkonfiguration erforderlich sind, und kopieren Sie die Befehle, und fügen Sie die Befehle in die CLI der Hierarchieebene [edit] 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 zur Navigation in 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. Konfiguration BGP.

    Wenden Sie die send-direct Exportrichtlinie an, sodass Direktrouten aus der Routingtabelle in eine BGP.

    Wenden Sie die Importrichtlinie an, um den Validierungsstatus und BGP community-Attribute für alle von validation EBGP-Peers von Gerät R0 importierten (oder empfangenen) Routen zu festlegen.

    Konfigurieren Sie eine IBGP-Sitzung mit Gerät R1. Konfigurieren Sie eine EBGP-Sitzung mit Gerät R2.

  3. Konfigurieren OSPF (oder ein anderes Interior Gateway Protocol [IGP]) an der Schnittstelle für das IBGP-Peer und auf der Loopback-Schnittstelle.

    Anmerkung:

    Wenn Sie die Loopback-Schnittstellenadresse in der IBGP-Anweisung verwenden, müssen Sie eine IGP neighbor 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.

  5. Konfigurieren Sie die Routing-Richtlinie, die Attribute angibt, die auf dem Validierungsstatus jeder Routingroute BGP werden.

  6. Konfigurieren Sie die Sitzung mit dem RPKI-Cache-Server.

  7. Konfigurieren Sie die autonome Systemnummer (AS).

Ergebnisse

Bestätigen Sie Ihre Konfiguration im Konfigurationsmodus, indem Sie die show interfacesshow protocols , und Befehle show policy-optionsshow routing-options eingeben. Wenn in der Ausgabe nicht die beabsichtigte Konfiguration angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Wenn Sie die Konfiguration des Geräts erledigt haben, geben Sie commit den Konfigurationsmodus ein.

Gerät konfigurieren R1

Schritt-für-Schritt-Verfahren

Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zur Navigation in CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI Benutzerhandbuch.

So konfigurieren Sie Gerät R1:

  1. Konfigurieren Sie die Schnittstellen.

  2. Konfiguration BGP.

    Wenden Sie die Importrichtlinie an, um den Validierungsstatus und BGP community-Attribute für alle Routen fest zu legen, die von den validation-ibgp IBGP-Peers von Device R1 empfangen werden.

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

  3. Konfiguration OSPF.

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

  5. Konfigurieren Sie die autonome Systemnummer (AS).

Ergebnisse

Bestätigen Sie Ihre Konfiguration im Konfigurationsmodus, indem Sie die show interfacesshow protocols , und Befehle show policy-optionsshow routing-options eingeben. Wenn in der Ausgabe nicht die beabsichtigte Konfiguration angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Wenn Sie die Konfiguration des Geräts erledigt haben, geben Sie commit den Konfigurationsmodus ein.

Gerät konfigurieren R2

Schritt-für-Schritt-Verfahren

Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zur Navigation in CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI Benutzerhandbuch.

So konfigurieren Sie Gerät R2:

  1. Konfigurieren Sie die Schnittstellen.

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

  2. Konfiguration BGP.

  3. Konfigurieren Sie die Routing-Richtlinie.

  4. Konfigurieren Sie die autonome Systemnummer (AS).

Ergebnisse

Bestätigen Sie Ihre Konfiguration im Konfigurationsmodus, indem Sie die show interfacesshow protocols , und Befehle show policy-optionsshow routing-options eingeben. Wenn in der Ausgabe nicht die beabsichtigte Konfiguration angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Wenn Sie die Konfiguration des Geräts bereits durchgeführt haben, geben Sie commit sie im Konfigurationsmodus ein.

Überprüfung

Stellen Sie sicher, dass die Konfiguration ordnungsgemäß funktioniert.

Überprüfen, ob die modifizierten Attribute in den Routingtabellen angezeigt werden

Zweck

Stellen Sie sicher, dass BGP auf Gerät R0 und Device R1 den erwarteten Validierungszuständen und den zu erwartenden lokalen Einstellungen entsprechen.

Aktion

Geben Sie im Betriebsmodus den Befehl show route ein.

Bedeutung

Die Routen basieren auf den vom RPKI-Cache-Server empfangenen Informationen und haben die zu erwartenden Validierungszustände und lokale Einstellungswerte.

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 tracing auf Device R0.

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

  • Prüfen Sie auf Device R0 die Trace-Datei.

Bedeutung

Die Routenvalidierung wird wie erwartet ausgeführt.

Anzeige von Validierungsinformationen

Zweck

Führen Sie die verschiedenen Validierungsbefehle aus.

Aktion