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.
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.
- Unterstützte Standards
- Funktionsweise der Ursprungsvalidierung
- BGP-Interaktion mit der Routenvalidierungsdatenbank
- Community-Attribut zur Ankündigung des RPKI-Validierungsstatus für IBGP-Nachbarn
- Unterbrechungsfreie aktive Routing- und Ursprungsvalidierung
- Markieren eines Prefix-Bereichs als nie zulässig
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.
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.
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.
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.
[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 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
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 wird 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;
}
}
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.
Siehe auch
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.
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 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:
[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 Routinggerät zu konfigurieren und somit 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 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.
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
- Konfigurieren von Gerät 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 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
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 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:
-
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 Routingtabelle in BGP exportiert werden.Wenden Sie die
validationImportrichtlinie 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.
[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 und der Loopback-Schnittstelle gegenübersteht.
Anmerkung:Wenn Sie die Loopback-Schnittstellenadresse in der IBGP-Anweisung
neighborverwenden, müssen Sie ein 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 Routingtabelle 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-Cache-Server.
[edit routing-options validation] user@R0# set group test session 10.0.0.10
-
Konfigurieren Sie die autonome Systemnummer (AS).
[edit routing-options] user@R0# set autonomous-system 65100
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.
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 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:
-
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 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.
[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
-
OSPF konfigurieren.
[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 Validierungsstatus-Attribut der BGP-Community für die 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 autonome Systemnummer (AS).
[edit routing-options] user@R1# set autonomous-system 65100
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.
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 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:
-
Konfigurieren Sie die Schnittstellen.
Auf der Loopback-Schnittstelle werden mehrere Adressen konfiguriert, um als Routen für Demonstrationszwecke zu 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 autonome Systemnummer (AS).
[edit routing-options] user@R2# set autonomous-system 65200
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.
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 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
- Verwendung von Trace-Vorgängen
- Validierungsinformationen anzeigen
Ü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.
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 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.
[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 an 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 Trace-Datei.
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 läuft wie erwartet.
Validierungsinformationen anzeigen
Zweck
Führen Sie die verschiedenen Validierungsbefehle aus.
Aktion
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