Validation de l’origine BGP
Comprendre la validation de l’origine pour BGP
La validation de l’origine permet d’éviter la publication involontaire des routes. Parfois, les administrateurs réseau annoncent par erreur des routes vers des réseaux qu’ils ne contrôlent pas. Vous pouvez résoudre ce problème de sécurité en configurant la validation de l’origine (également appelée routage interdomaine sécurisé). La validation de l’origine est un mécanisme par lequel les annonces de route peuvent être authentifiées comme provenant d’un système autonome attendu (AS). La validation de l’origine utilise un ou plusieurs serveurs de cache RPKI (Public Key Infrastructure) pour effectuer l’authentification des préfixes BGP spécifiés. Pour authentifier un préfixe, le routeur (interlocuteur BGP) interroge la base de données des mappages validés de préfixe à AS, qui sont téléchargés à partir du serveur de cache, et s’assure que le préfixe provient d’un AS attendu.
Avant les versions 20.1R3, 20.2R3, 20.3R2, 20.4R2, 21.1R1 de Junos OS, lorsque vous activez l’authentification RPKI, Junos OS ouvre automatiquement le port TCP 2222 sans préavis. Vous pouvez appliquer un filtre pour bloquer et sécuriser ce port.
À partir des versions 20.1R3, 20.2R3, 20.3R2, 20.4R2, 21.1R1 de Junos OS, lorsque vous activez l’authentification RPKI, Junos OS n’ouvre plus automatiquement les ports TCP 2222.
Junos OS prend en charge la validation de l’origine des préfixes IPv4 et IPv6.
La figure 1 montre un exemple de topologie.
de l’origine
- Standards pris en charge
- Fonctionnement de la validation de l’origine
- Interaction de BGP avec la base de données de validation de route
- Attribut de communauté pour annoncer l’état de validation RPKI aux voisins IBGP
- Validation de l’origine et du routage actif ininterrompus
- Marquage d’une plage de préfixes comme jamais autorisée
Standards pris en charge
L’implémentation Junos OS de la validation d’origine prend en charge les RFC et le projet suivants :
-
RFC 6810, La ressource RPKI (Public Key Infrastructure) to Router Protocol
-
RFC 6811, Validation de l’origine du préfixe BGP
-
Internet draft draft-ietf-sidr-origin-validation-signaling-00, préfixe BGP Origin Validation State Extended Community (support partiel)
La communauté étendue (état de validation de l’origine) est prise en charge dans la politique de routage de Junos OS. La modification spécifiée dans la procédure de sélection de route n’est pas prise en charge.
Fonctionnement de la validation de l’origine
Le RPKI et la validation de l’origine utilisent des certificats X.509 avec des extensions spécifiées dans la RFC 3779, Extensions X.509 pour les adresses IP et les identifiants AS.
Le RPKI consiste en une collection distribuée d’informations. Chaque autorité de certification publie ses certificats d’entité finale (EE), ses listes de révocation de certificats (CRL) et ses objets signés à un emplacement donné. Tous ces dépôts forment un ensemble complet d’informations qui est disponible pour chaque serveur de cache RPKI.
Chaque serveur de cache RPKI maintient un cache local de l’ensemble de la collection de référentiels distribués en synchronisant régulièrement chaque élément du cache local avec le point de publication du référentiel d’origine.
Sur le routeur, les entrées de la base de données sont formatées en tant qu’enregistrements de validation de route (RV). Un enregistrement RV est un triplet (préfixe, longueur maximale, origine AS). Il correspond à tout itinéraire dont le préfixe correspond au préfixe RV, dont la longueur du préfixe ne dépasse pas la longueur maximale indiquée dans l’enregistrement RV et dont l’origine AS est égale à l’origine AS donnée dans l’enregistrement RV.
Un enregistrement de RV est une version simplifiée d’une autorisation d’origine de route (ROA). Un ROA est un objet signé numériquement qui fournit un moyen de vérifier qu’un détenteur de bloc d’adresses IP a autorisé un AS à créer des routes vers un ou plusieurs préfixes dans le bloc d’adresses. Les ROA ne sont pas directement utilisés dans la validation de route. Le serveur de cache exporte une version simplifiée du ROA vers le routeur en tant qu’enregistrement RV.
La valeur de longueur maximale doit être supérieure ou égale à la longueur du préfixe autorisé et inférieure ou égale à la longueur (en bits) d’une adresse IP de la famille d’adresses (32 pour IPv4 et 128 pour IPv6). La longueur maximale définit le préfixe d’adresse IP que l’AS est autorisé à annoncer.
Par exemple, si le préfixe de l’adresse IP est 200.4.66/24 et que la longueur maximale est 26, l’AS est autorisé à annoncer 200.4.66.0/24, 200.4.66.0/25, 200.4.66.128/25, 200.4.66.0/26, 200.4.66.64/26, 200.4.66.128/26 et 200.4.66.192/26. Lorsque la longueur maximale n’est pas présente, l’AS est uniquement autorisé à annoncer exactement le préfixe spécifié dans le VR.
Autre exemple, un RV peut contenir le préfixe 200.4.66/24 avec une longueur maximale de 26, ainsi que le préfixe 200.4.66.0/28 avec une longueur maximale de 28. Ce RV autoriserait l’AS à annoncer tout préfixe commençant par 200.4.66 avec une longueur d’au moins 24 et pas plus de 26, ainsi que le préfixe spécifique 200.4.66.0/28.
L’origine d’une route est représentée par le numéro AS le plus à droite dans l’attribut AS_PATH. La validation de l’origine fonctionne en comparant l’AS d’origine dans une mise à jour de routage avec l’AS source autorisé publié dans les enregistrements RV.
La sécurité fournie par la validation de l’origine seule est connue pour être faible contre un attaquant déterminé, car il n’existe aucune protection contre l’usurpation de l’AS source. Cela dit, la validation de l’origine offre une protection utile contre les annonces accidentelles.
Bien que la validation de l’origine puisse être mise en œuvre en faisant participer directement chaque routeur au RPKI, cela est considéré comme trop gourmand en ressources (car de nombreuses opérations de cryptographie à clé publique sont nécessaires pour valider les données RPKI) ainsi qu’opérationnel pour mettre en place et maintenir une configuration RPKI sur chaque routeur. Pour cette raison, un serveur de cache RPKI distinct effectue des validations de clé publique et génère une base de données validée de mappages de préfixe à AS. La base de données validée est téléchargée sur un routeur client via une connexion TCP sécurisée. Le routeur nécessite donc peu d’informations sur l’infrastructure RPKI et n’a pas d’exigences de cryptographie à clé publique, autre que le mot de passe de transport crypté. Le routeur utilise ensuite les données téléchargées pour valider les mises à jour de route reçues.
Lorsque vous configurez des sessions serveur, vous pouvez les regrouper et configurer les paramètres de session pour chaque session du groupe. Le routeur essaie périodiquement de configurer un nombre maximum configurable de connexions aux serveurs de cache. Si la configuration de la connexion échoue, une nouvelle tentative de connexion est effectuée périodiquement.
Entre-temps, une fois la stratégie d’importation de validation appliquée à la session BGP, la validation du routage est effectuée indépendamment de l’état de la session de cache (actif ou désactivé) et de la base de données RV (vide ou non). Si la base de données RV est vide ou si aucune des sessions du serveur de cache n’est active, l’état de validation de chaque route est défini sur inconnu, car aucun enregistrement RV n’existe pour évaluer un préfixe BGP reçu.
La période de nouvelle tentative est configurable. Après s’être connecté avec succès à un serveur de cache, le routeur demande le dernier numéro de série de la base de données et demande au cache RPKI de transmettre toutes les entrées RV appartenant à cette version de la base de données.
Chaque message entrant réinitialise un minuteur de vivacité pour le serveur de cache RPKI. Une fois toutes les mises à jour apprises, le routeur effectue des contrôles périodiques de la vivacité en fonction d’un intervalle configurable. Pour ce faire, il faut envoyer une unité de données de protocole de requête (PDU) de requête série avec le même numéro de série que le serveur de cache a signalé dans sa dernière PDU de notification. Le serveur de cache répond avec zéro mise à jour ou plus et une PDU de fin de données (EOD), qui actualise également l’état de vivacité du serveur de cache et réinitialise un minuteur de durée de vie d’enregistrement.
Lorsqu’un préfixe est reçu d’un homologue BGP (EBGP) externe, il est examiné par une stratégie d’importation et marqué comme valide, invalide, inconnu ou non vérifié :
-
Valide : indique que le préfixe et la paire AS sont trouvés dans la base de données.
-
Non valide : indique que le préfixe est trouvé, mais que l’AS correspondant reçu de l’homologue EBGP n’est pas l’AS qui apparaît dans la base de données, ou que la longueur du préfixe dans le message de mise à jour BGP est supérieure à la longueur maximale autorisée dans la base de données.
-
Inconnu : indique que le préfixe ne figure pas parmi les préfixes ou les plages de préfixes de la base de données.
-
Non vérifié : indique que l’origine du préfixe n’est pas vérifiée par rapport à la base de données. Cela est dû au fait que la base de données a été remplie et que la validation n’est pas requise dans la stratégie d’importation BGP, bien que la validation de l’origine soit activée ou que la validation de l’origine ne soit pas activée pour les homologues BGP.
S’il existe des correspondances potentielles pour l’itinéraire dans la base de données de validation, l’itinéraire doit correspondre à l’un d’entre eux pour être valide. Sinon, elle n’est pas valide. Toute correspondance est suffisante pour rendre l’itinéraire valide. Il n’est pas nécessaire que ce soit la meilleure correspondance. Ce n’est que s’il n’y a pas de correspondances potentielles que l’itinéraire est considéré comme inconnu. Pour plus d’informations sur la logique de base de données de mappage du préfixe à l’AS, consultez la section 2 du projet Internet draft-ietf-sidr-pfx-validate-01, Validation de l’origine du préfixe BGP.
Interaction de BGP avec la base de données de validation de route
La base de données de validation de route (RV) contient une collection d’enregistrements RV que le routeur télécharge à partir du serveur de cache RPKI. Une fois que la base de données RV est remplie avec des enregistrements RV, la base de données RV analyse la table de routage RIB-Local pour déterminer s’il existe des préfixes dans RIB-Local qui pourraient être affectés par les enregistrements RV dans la base de données. (RIB-Local contient les routes IPv4 et IPv6 affichées dans la sortie de la show route protocol bgp commande.)
Ce processus déclenche une réévaluation BGP des stratégies d’importation BGP (et non des stratégies d’exportation).
La figure 2 illustre le processus.
Les stratégies d’importation sont appliquées au RIB-In. Une autre façon de comprendre cela est que les stratégies d’importation sont appliquées aux routes affichées dans la sortie de la show route receive-protocol bgp commande, tandis que les stratégies d’exportation sont appliquées aux routes affichées par la show route advertising-protocol bgp commande.
Comme illustré à la Figure 3, vous utilisez des stratégies de routage d’importation pour contrôler les routes placées par BGP dans la table de routage, et des stratégies de routage d’exportation pour contrôler les routes que BGP annonce de la table de routage à ses voisins.
de routage
Lorsque vous configurez une stratégie d’importation de validation de route, la configuration de la stratégie utilise une condition de validation-database correspondance. Cette condition de correspondance déclenche une requête dans la base de données RV pour connaître l’état de validation d’un préfixe dans une instance de routage donnée. L’opération par défaut consiste à interroger la base de données de validation correspondant à l’instance de routage. Si aucune instance de validation de route n’est trouvée, l’instance principale est interrogée.
Dans la stratégie d’importation BGP suivante, la from validation-database condition déclenche une recherche dans la base de données RV du routeur. Une action est effectuée si l’état de validation est valide. L’action consiste à accepter la route et à définir le validation-state dans la table de routage comme valide.
[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;
}
}
}
Attribut de communauté pour annoncer l’état de validation RPKI aux voisins IBGP
La validation du préfixe est effectuée uniquement pour les mises à jour BGP externes (EBGP). Dans un AS, vous ne souhaitez probablement pas qu’une session RPKI s’exécute sur chaque routeur BGP (IBGP) interne. Au lieu de cela, vous avez besoin d’un moyen de transmettre l’état de validation à travers le maillage IBGP afin que tous les locuteurs IBGP disposent d’informations cohérentes. Pour ce faire, il faut porter l’état de validation dans une communauté étendue non transitive. L’attribut community annonce et reçoit l’état de validation d’un préfixe entre voisins IBGP.
Pour la validation de route, Junos OS prend en charge les communautés étendues connues suivantes :
-
origin-validation-state-valid
-
origin-validation-state-invalid
-
origine-validation-état-inconnu
L’exemple de stratégie d’importation BGP suivant est configuré sur le routeur qui a une session avec un serveur RPKI.
Routeur avec session RPKI
policy-statement validation-1 {
term valid {
from {
protocol bgp;
validation-database valid;
}
then {
validation-state valid;
community add origin-validation-state-valid;
accept;
}
}
}
L’exemple suivant de stratégie d’importation BGP est configuré sur un routeur homologue IBGP qui n’a pas de session avec un serveur RPKI.
Routeur homologue IBGP sans session RPKI
policy-statement validation-2 {
term valid {
from community origin-validation-state-valid;
then validation-state valid;
}
}
Validation de l’origine et du routage actif ininterrompus
Lorsque vous configurez la validation de l’origine sur un routeur qui a deux moteurs de routage et que le routage actif ininterrompu est activé, les moteurs de routage principal et de secours disposent d’une copie de la base de données RV. Ces deux bases de données RV restent synchronisées l’une avec l’autre.
Le routeur ne maintient pas deux sessions identiques avec le serveur RPKI. Le protocole RPKI-RTR s’exécute uniquement sur le moteur de routage principal. Sur le moteur de routage de secours, la session du serveur de cache RPKI est toujours en panne.
La base de données RV est activement gérée par le moteur de routage principal via sa session avec le serveur RPKI. Cette base de données est répliquée sur le moteur de routage de secours. Bien que la session soit en panne sur le moteur de routage de secours, la base de données RV répliquée contient des enregistrements RV. Lorsque le moteur de routage de secours bascule et devient le moteur de routage principal, il dispose déjà d’une base de données RV entièrement remplie.
Pour afficher le contenu des deux bases de données, utilisez les show validation database commandes and show validation replication database .
Marquage d’une plage de préfixes comme jamais autorisée
Le modèle de validation de route présente un défaut majeur : il ne fournit que des mises à jour positives. Il peut déclarer quel AS est le propriétaire légitime d’un préfixe. Cependant, il ne peut pas transmettre explicitement une mise à jour négative, comme dans : Ce préfixe n’est jamais créé par un AS donné. Cette fonctionnalité peut être assurée dans une certaine mesure à l’aide d’une solution de contournement de l’AS 0.
L’implémentation de Junos OS ne tente pas de restreindre ses entrées à partir du cache. Par exemple, un enregistrement RV avec l’origine AS 0 est installé et mis en correspondance comme n’importe quel autre. Cela permet à une solution de contourner le marquage d’une plage de préfixes comme n’ayant jamais été annoncée, car l’AS 0 n’est pas un AS valide. L’AS dans l’enregistrement RV ne correspond jamais à l’AS reçu de l’homologue EBGP. Ainsi, tout préfixe correspondant est marqué comme invalide.
Voir aussi
Cas d’usage et avantages de la validation de l’origine pour BGP
Si l’administrateur d’un système autonome (AS) commence à annoncer tout ou partie du réseau attribué à une autre entreprise, BGP n’a pas de méthode intégrée pour reconnaître l’erreur et y répondre de manière à éviter les interruptions de service.
Supposons, par exemple, qu’un administrateur d’un réseau client annonce par erreur une route (disons 10.65.153.0/24) dirigeant le trafic vers le fournisseur de services du client AS 1. Cette route /24 est une route plus spécifique que celle utilisée par le fournisseur de contenu réel (10.65.152.0/22) qui dirige le trafic vers AS 2. En raison de la façon dont les routeurs fonctionnent, la plupart des routeurs sélectionnent l’itinéraire le plus spécifique et envoient le trafic vers AS 1 au lieu d’AS 2.
Le préfixe détourné est largement vu sur Internet lorsque les routeurs de transit propagent les informations de chemin mises à jour. Les routes invalides peuvent être largement distribuées sur Internet, car les routeurs de la zone franche par défaut (DFZ) portent la route détournée. Finalement, le chemin AS correct est restauré vers les homologues BGP, mais entre-temps, des interruptions de service sont à prévoir.
Étant donné que le BGP repose sur un modèle de confiance transitif, la validation entre le client et le fournisseur est importante. Dans l’exemple ci-dessus, le fournisseur de services AS 1 n’a pas validé l’annonce défectueuse pour 10.65.153.0/24. En acceptant cette annonce et en la republiant auprès de ses pairs et fournisseurs, AS 1 propageait la mauvaise voie. Les routeurs qui ont reçu cette route d’AS 1 l’ont sélectionnée parce qu’il s’agissait d’une route plus spécifique. Le véritable fournisseur de contenu faisait de la publicité pour 10.65.152.0/22 avant que l’erreur ne se produise. Le /24 était une publicité plus petite (et plus spécifique). Selon le processus habituel de sélection de la route BGP, le /24 a ensuite été choisi, complétant ainsi le détournement.
Même avec une détection et une réaction rapides du fournisseur de contenu et une coopération avec d’autres fournisseurs, le service de son préfixe peut être interrompu pendant plusieurs minutes jusqu’à plusieurs heures. La durée exacte de la panne dépend de votre point de vue sur Internet. Lorsque ce genre d’événements se produisent, il y a un regain d’intérêt pour les solutions à cette vulnérabilité. Le BGP est fondamental pour les relations avec les fournisseurs et ne disparaîtra pas de sitôt. Cet exemple illustre une solution qui utilise la validation de l’origine. Cette solution s’appuie sur des extensions cryptographiques de BGP et un modèle client-serveur distribué qui évite de surcharger les processeurs des routeurs.
La validation de l’origine permet de surmonter la vulnérabilité de la confiance transitive en permettant à un fournisseur de limiter les annonces qu’il accepte d’un client. Les mécanismes impliquent la communication de stratégies de routage basées sur un attribut de communauté BGP étendu.
Voir aussi
Exemple : configuration de la validation de l’origine pour BGP
Cet exemple montre comment configurer la validation de l’origine entre homologues BGP en s’assurant que les annonces de route reçues proviennent du système autonome attendu (AS). Si l’AS d’origine est validé, une stratégie peut spécifier que les préfixes sont, à leur tour, annoncés.
Exigences
Cet exemple présente les exigences matérielles et logicielles suivantes :
-
Serveur de cache RPKI (Public Key Infrastructure) de ressources utilisant un logiciel tiers pour authentifier les préfixes BGP.
-
Junos OS version 12.2 ou ultérieure s’exécutant sur le périphérique de routage qui communique avec le serveur de cache via une connexion TCP.
Vue d’ensemble
Parfois, des itinéraires sont annoncés involontairement en raison d’une erreur de l’opérateur. Pour éviter ce problème de sécurité, vous pouvez configurer BGP pour valider l’AS d’origine et rejeter ces annonces non valides. Cette fonctionnalité utilise un serveur de cache pour authentifier les préfixes ou les plages de préfixes.
Les instructions de configuration suivantes permettent la validation de l’AS d’origine :
[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; } } }
Cet exemple utilise les paramètres par défaut pour les paramètres de validation.
La plupart des instructions de configuration disponibles sont facultatives. Les paramètres requis sont les suivants :
validation { group group-name { sessionaddress { } } }
Le [edit routing-options validation static] niveau de hiérarchie vous permet de configurer des enregistrements statiques sur un périphérique de routage, écrasant ainsi les enregistrements reçus d’un serveur de cache RPKI.
Par exemple :
[edit routing-options validation] user@R0# set static record 10.0.0.0/16 maximum-length 24 origin-autonomous-system 200 validation-state valid
Vous pouvez configurer une politique de routage qui fonctionne en fonction de l’état de validation d’un préfixe de route. Vous pouvez utiliser un attribut de communauté pour annoncer et recevoir l’état de validation d’un préfixe entre des homologues BGP externes (EBGP) et internes BGP (IBGP). L’utilisation d’une politique de routage peut être plus pratique sur certains routeurs que la configuration d’une session avec un serveur RPKI. Cet exemple illustre l’utilisation de l’attribut validation-state community entre des homologues IBGP.
La figure 4 montre un exemple de topologie.
l’origine
Dans cet exemple, l’équipement R0 a une connexion IBGP à l’équipement R1 et une connexion EBGP à l’équipement R2. L’équipement R0 reçoit les enregistrements de validation de route (RV) du serveur de cache en utilisant le protocole défini dans le brouillon Internet draft-ietf-sidr-rpki-rtr-19, le protocole RPKI/routeur pour envoyer les enregistrements RV. Le protocole RPKI-Router fonctionne sur TCP. Les enregistrements RV sont utilisés par l’équipement R0 pour créer une base de données RV locale. Sur l’appareil R1, l’état de validation est défini en fonction de la communauté BGP appelée validation-state, qui est reçue avec la route.
La configuration
- Configuration rapide de la CLI
- Configuration de l’équipement R0
- Configuration de l’équipement R1
- Configuration de l’équipement R2
Configuration rapide de la CLI
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à votre configuration réseau, puis copiez et collez les commandes dans le CLI au niveau de la [edit] hiérarchie.
Équipement 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
Appareil 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
Appareil 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
Configuration de l’équipement R0
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans la CLI, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur de la CLI de Junos OS.
Pour configurer l’appareil R0 :
-
Configurez les interfaces.
[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
-
Configurez BGP.
Appliquez la stratégie d’exportation
send-directafin que les routes directes soient exportées de la table de routage vers BGP.Appliquez la
validationstratégie d’importation pour définir les attributs validation-state et BGP community pour toutes les routes importées (ou reçues) à partir des homologues EBGP de Device R0.Configurez une session IBGP avec l’équipement R1. Configurez une session EBGP avec l’appareil 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
-
Configurez OSPF (ou un autre protocole de passerelle intérieure [IGP]) sur l’interface qui fait face à l’homologue IBGP et sur l’interface de bouclage.
Remarque :Si vous utilisez l’adresse de l’interface de bouclage dans l’instruction IBGP
neighbor, vous devez activer un IGP sur l’interface de bouclage. Sinon, la session IBGP n’est pas établie.[edit protocols ospf area 0.0.0.0] user@R0# set interface ge-1/2/0.0 user@R0# set interface lo0.0 passive
-
Configurez la politique de routage qui exporte les routes directes de la table de routage vers BGP.
[edit policy-options policy-statement send-direct] user@R0# set from protocol direct user@R0# set then accept
-
Configurez la politique de routage qui spécifie les attributs à modifier en fonction de l’état de validation de chaque route BGP.
[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
-
Configurez la session avec le serveur de cache RPKI.
[edit routing-options validation] user@R0# set group test session 10.0.0.10
-
Configurez le numéro du système autonome (AS).
[edit routing-options] user@R0# set autonomous-system 65100
Résultats
En mode configuration, confirmez votre configuration en entrant les show interfacescommandes , show protocolsshow policy-options, , et show routing-options . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
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;
}
}
Si vous avez terminé de configurer l’appareil, entrez en commit mode configuration.
Configuration de l’équipement R1
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans la CLI, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur de la CLI de Junos OS.
Pour configurer l’appareil R1 :
-
Configurez les interfaces.
[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
-
Configurez BGP.
Appliquez la
validation-ibgpstratégie d’importation pour définir les attributs validation-state et BGP community pour toutes les routes reçues des homologues IBGP de Device R1.Configurez une session IBGP avec l’équipement 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
-
Configurez OSPF.
[edit protocols ospf area 0.0.0.0] user@R1# set interface ge-1/2/0.0 user@R1# set interface lo0.0 passive
-
Configurez la politique de routage qui spécifie les attributs à modifier en fonction de l’attribut de communauté BGP à état de validation des routes BGP reçues de l’équipement R0.
[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
-
Configurez le numéro du système autonome (AS).
[edit routing-options] user@R1# set autonomous-system 65100
Résultats
En mode configuration, confirmez votre configuration en entrant les show interfacescommandes , show protocolsshow policy-options, , et show routing-options . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
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;
Si vous avez terminé de configurer l’appareil, entrez en commit mode configuration.
Configuration de l’équipement R2
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans la CLI, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur de la CLI de Junos OS.
Pour configurer l’appareil R2 :
-
Configurez les interfaces.
Plusieurs adresses sont configurées sur l’interface de bouclage pour servir de routes à des fins de démonstration.
[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
-
Configurez 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
-
Configurez la politique de routage.
[edit policy-options policy-statement send-direct] user@R2# set from protocol direct user@R2# set from protocol local user@R2# set then accept
-
Configurez le numéro du système autonome (AS).
[edit routing-options] user@R2# set autonomous-system 65200
Résultats
En mode configuration, confirmez votre configuration en entrant les show interfacescommandes , show protocolsshow policy-options, , et show routing-options . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
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;
Si vous avez terminé de configurer l’appareil, entrez en commit mode configuration.
Vérification
Vérifiez que la configuration fonctionne correctement.
- Vérification de l’affichage des attributs modifiés dans les tables de routage
- Utilisation des opérations de traçage
- Affichage des informations de validation
Vérification de l’affichage des attributs modifiés dans les tables de routage
Objet
Vérifiez que les routes BGP sur l’équipement R0 et l’équipement R1 ont les états de validation attendus et les préférences locales attendues.
Mesures à prendre
À partir du mode opérationnel, entrez la show route commande.
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
MultiRecv
user@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
MultiRecv
Signification
Les routes ont les états de validation et les valeurs de préférence locale attendus, en fonction des informations reçues du serveur de cache RPKI.
Utilisation des opérations de traçage
Objet
Configurez les opérations de traçage pour valider l’origine et surveillez les résultats d’une nouvelle route publiée.
Mesures à prendre
-
Sur l’appareil R0, configurez le suivi.
[edit routing-options validation traceoptions] user@R0# set file rv-tracing user@R0# set flag all user@R0# commit
-
Sur l’appareil R2, ajoutez une route en ajoutant une autre adresse sur l’interface de bouclage.
[edit interfaces lo0 unit 0 family inet] user@R2# set address 10.4.4.4/32 user@R2# commit
-
Sur l’appareil R0, vérifiez le fichier de trace.
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
Signification
La validation du routage fonctionne comme prévu.
Affichage des informations de validation
Objet
Exécutez les différentes commandes de validation.
Mesures à prendre
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: 100
user@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