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.
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.
- Unterstützte Standards
- Wie die Ursprungsvalidierung funktioniert
- BGP Interaktion mit der Routenvalidierungsdatenbank
- Community-Attribut zur Ankündigung des RPKI-Validierungsstatus für IBGP-Nachbarn
- Nonstop Active Routing and Origin Validation
- Nie zugelassenes Prefix-Bereichs markieren
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.
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.
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.
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.
[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 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
policy-statement validation-1 {
term valid {
from {
protocol bgp;
validation-database valid;
}
then {
validation-state valid;
community add origin-validation-state-valid;
accept;
}
}
}
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
policy-statement validation-2 {
term valid {
from community origin-validation-state-valid;
then validation-state valid;
}
}
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.
Siehe auch
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.
Siehe auch
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:
[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 Konfigurationserklärungen sind optional. Die erforderlichen Einstellungen lauten wie folgt:
validation { group group-name { session address { } } }
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:
[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 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.
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
set interfaces ge-1/2/0 unit 2 description to-R1 set interfaces ge-1/2/0 unit 2 family inet address 10.0.0.2/30 set interfaces ge-1/2/1 unit 5 description to-R2 set interfaces ge-1/2/1 unit 5 family inet address 10.0.0.5/30 set interfaces ge-1/2/2 unit 9 description to-cache set interfaces ge-1/2/2 unit 9 family inet address 10.0.0.9/30 set interfaces lo0 unit 1 family inet address 1.0.1.1/32 set protocols bgp group int type internal set protocols bgp group int local-address 1.0.1.1 set protocols bgp group int export send-direct set protocols bgp group int neighbor 1.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 200 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.1 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 100 set routing-options validation group test session 10.0.0.10
Gerät R1
set interfaces ge-1/2/0 unit 1 family inet address 10.0.0.1/30 set interfaces lo0 unit 2 family inet address 1.1.1.1/32 set protocols bgp group int type internal set protocols bgp group int local-address 1.1.1.1 set protocols bgp group int import validation-ibgp set protocols bgp group int neighbor 1.0.1.1 set protocols ospf area 0.0.0.0 interface ge-1/2/0.1 set protocols ospf area 0.0.0.0 interface lo0.2 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 100
Gerät R2
set interfaces ge-1/2/0 unit 6 family inet address 10.0.0.6/30 set interfaces lo0 unit 5 family inet address 172.16.1.1/32 set interfaces lo0 unit 5 family inet address 192.168.2.3/32 set interfaces lo0 unit 5 family inet address 2.2.0.2/32 set protocols bgp group ext export send-direct set protocols bgp group ext peer-as 100 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 200
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:
Konfigurieren Sie die Schnittstellen.
[edit interfaces] user@R0# set ge-1/2/0 unit 2 description to-R1 user@R0# set ge-1/2/0 unit 2 family inet address 10.0.0.2/30 user@R0# set ge-1/2/1 unit 5 description to-R2 user@R0# set ge-1/2/1 unit 5 family inet address 10.0.0.5/30 user@R0# set ge-1/2/2 unit 9 description to-cache user@R0# set ge-1/2/2 unit 9 family inet address 10.0.0.9/30 user@R0# set lo0 unit 1 family inet address 1.0.1.1/32
Konfiguration BGP.
Wenden Sie die
send-directExportrichtlinie 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
validationEBGP-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.
[edit protocols bgp] user@R0# set group int type internal user@R0# set group int local-address 1.0.1.1 user@R0# set group int export send-direct user@R0# set group int neighbor 1.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 200 user@R0# set group ext neighbor 10.0.0.6
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
neighborder 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.2 user@R0# set interface lo0.1 passive
Konfigurieren Sie die Routing-Richtlinie, die Direkte Routen aus der Routingtabelle in BGP.
[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 auf dem Validierungsstatus jeder Routingroute BGP werden.
[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 100
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.
user@R0# show interfaces
ge-1/2/0 {
unit 2 {
description to-R1;
family inet {
address 10.0.0.2/30;
}
}
}
ge-1/2/1 {
unit 5 {
description to-R2;
family inet {
address 10.0.0.5/30;
}
}
}
ge-1/2/2 {
unit 9 {
description to-cache;
family inet {
address 10.0.0.9/30;
}
}
}
lo0 {
unit 1 {
family inet {
address 1.0.1.1/32;
}
}
}
user@R0# show protocols
bgp {
group int {
type internal;
local-address 1.0.1.1;
export send-direct;
neighbor 1.1.1.1;
}
group ext {
type external;
import validation;
export send-direct;
peer-as 200;
neighbor 10.0.0.6;
}
}
ospf {
area 0.0.0.0 {
interface ge-1/2/0.2;
interface lo0.1 {
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 100;
validation {
group test {
session 10.0.0.10;
}
}
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:
Konfigurieren Sie die Schnittstellen.
[edit interfaces] user@R1# set ge-1/2/0 unit 1 family inet address 10.0.0.1/30 user@R1# set lo0 unit 2 family inet address 1.1.1.1/32
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-ibgpIBGP-Peers von Device R1 empfangen werden.Konfigurieren Sie eine IBGP-Sitzung mit Gerät R0.
[edit protocols bgp group int] user@R1# set type internal user@R1# set local-address 1.1.1.1 user@R1# set import validation-ibgp user@R1# set neighbor 1.0.1.1
Konfiguration OSPF.
[edit protocols ospf area 0.0.0.0] user@R1# set interface ge-1/2/0.1 user@R1# set interface lo0.2 passive
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.
[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 100
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.
user@R1# show interfaces
ge-1/2/0 {
unit 1 {
family inet {
address 10.0.0.1/30;
}
}
}
lo0 {
unit 2 {
family inet {
address 1.1.1.1/32;
}
}
}
user@R1# show protocols
bgp {
group int {
type internal;
local-address 1.1.1.1;
import validation-ibgp;
neighbor 1.0.1.1;
}
}
ospf {
area 0.0.0.0 {
interface ge-1/2/0.1;
interface lo0.2 {
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 100;
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:
Konfigurieren Sie die Schnittstellen.
Auf der Loopback-Schnittstelle werden mehrere Adressen konfiguriert, die als Routen für Demonstrationszwecke dienen.
[edit interfaces] user@R2# set ge-1/2/0 unit 6 family inet address 10.0.0.6/30 user@R2# set lo0 unit 5 family inet address 172.16.1.1/32 user@R2# set lo0 unit 5 family inet address 192.168.2.3/32 user@R2# set lo0 unit 5 family inet address 2.2.0.2/32
Konfiguration BGP.
[edit protocols bgp] user@R2# set group ext export send-direct user@R2# set group ext peer-as 100 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 200
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.
user@R2# show interfaces
ge-1/2/0 {
unit 6 {
family inet {
address 10.0.0.6/30;
}
}
}
lo0 {
unit 5 {
family inet {
address 172.16.1.1/32;
address 192.168.2.3/32;
address 2.2.0.2/32;
}
}
}
user@R2# show protocols
bgp {
group ext {
export send-direct;
peer-as 100;
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 200;
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
- Verwendung von Trace-Vorgängen
- Anzeige von Validierungsinformationen
Ü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.
user@R0> show route
inet.0: 12 destinations, 13 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.0.1.1/32 *[Direct/0] 04:53:39
> via lo0.1
1.1.1.1/32 *[OSPF/10] 04:50:53, metric 1
> to 10.0.0.1 via lt-1/2/0.2
2.2.0.2/32 *[BGP/170] 01:30:37, localpref 100
AS path: 200 I, validation-state: valid
> to 10.0.0.6 via lt-1/2/0.5
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: 200 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: 200 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: 200 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
2.2.0.2/32 *[BGP/170] 01:06:58, localpref 100, from 1.0.1.1
AS path: 200 I, validation-state: valid
> to 10.0.0.2 via lt-1/2/0.1
172.16.1.1/32 *[BGP/170] 00:40:52, localpref 100, from 1.0.1.1
AS path: 200 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: 200 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 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.
[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 der Loopbackschnittstelle eine weitere Adresse hinzufügen.
[edit interfaces lo0 unit 5 family inet] user@R2# set address 10.4.4.4/32 user@R2# commit
Prüfen Sie auf Device 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 200, 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 wird wie erwartet ausgeführt.
Anzeige von Validierungsinformationen
Zweck
Führen Sie die verschiedenen Validierungsbefehle aus.
Aktion
user@R0> show validation statistics Total RV records: 3 Total Replication RV records: 3 Prefix entries: 3 Origin-AS entries: 3 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 2.0.0.0/8-32 200 10.0.0.10 valid 10.0.0.0/8-32 200 10.0.0.10 valid 172.0.0.0/8-12 200 10.0.0.10 invalid IPv4 records: 3 IPv6 records: 0
user@R0> show validation replication database RRV replication database for instance master Prefix Origin-AS Session State 2.0.0.0/8-32 200 10.0.0.10 valid 10.0.0.0/8-32 200 10.0.0.10 valid 172.0.0.0/8-12 200 10.0.0.10 invalid IPv4 records: 3 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 3 IPv4 records Enqueued 0 IPv6 records