Validation de l’origine BGP
Comprendre la validation de l’origine pour BGP
La validation de l’origine permet d’éviter la publication involontaire d’itinéraires. Parfois, les administrateurs réseau annoncent par erreur des chemins 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 connue sous le nom de routage interdomaine sécurisé). La validation d’origine est un mécanisme par lequel les annonces de route peuvent être authentifiées comme provenant d’un système autonome (AS) attendu. La validation d’origine utilise un ou plusieurs serveurs de cache RPKI (Resource 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 préfixe à AS validés, qui sont téléchargés à partir du serveur de cache, et s’assure que le préfixe provient d’un AS attendu.
Avant Junos OS versions 20.1R3, 20.2R3, 20.3R2, 20.4R2, 21.1R1, 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 pour les préfixes IPv4 et IPv6.
Figure 1 montre un exemple de topologie.
- Normes prises en charge
- Fonctionnement de la validation de l’origine
- Interaction BGP avec la base de données de validation de route
- Attribut de communauté pour annoncer l’état de validation RPKI aux voisins IBGP
- Routage actif et validation de l’origine en continu
- Marquage d’une plage de préfixes comme jamais autorisé
Normes prises en charge
L’implémentation Junos OS de la validation d’origine prend en charge les RFC et les brouillons suivants :
RFC 6810, Infrastructure à clé publique de ressources (RPKI) vers protocole de routeur
RFC 6811, Validation de l’origine du préfixe BGP
Internet draft draft-ietf-sidr-origin-validation-signaling-00, BGP Prefix Origin Validation State Communauté étendue (prise en charge partielle)
La communauté étendue (état de validation de l’origine) est prise en charge dans Junos OS stratégie de routage. La modification spécifiée dans la procédure de sélection d’itinéraire 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, X.509 Extensions for IP Addresses and AS Identifiers.
L’ICRP 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 particulier. Tous ces référentiels 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 mises en forme sous forme d’enregistrements de validation de route (RV). Un enregistrement RV est un triplet (préfixe, longueur maximale, AS d’origine). Il correspond à n’importe quel itinéraire dont le préfixe correspond au préfixe RV, dont la longueur du préfixe n’excède 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 RV est une version simplifiée d’une autorisation d’origine d’itinéraire (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 à émettre des chemins vers un ou plusieurs préfixes dans le bloc d’adresses. Les ROA ne sont pas directement utilisés dans la validation des routes. Le serveur de cache exporte une version simplifiée du ROA vers le routeur sous la forme d’un 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 n’est autorisé qu’à annoncer exactement le préfixe spécifié dans le VR.
Autre exemple, un RV peut contenir le préfixe 200.4.66/24 d’une longueur maximale de 26, ainsi que le préfixe 200.4.66.0/28 d’une longueur maximale de 28. Ce RV autoriserait l’AS à annoncer tout préfixe commençant par 200.4.66 d’une longueur d’au moins 24 et d’au plus 26, ainsi que le préfixe spécifique 200.4.66.0/28.
L’origine d’un itinéraire est représentée par le numéro AS le plus à droite dans l’attribut AS_PATH. La validation de l’origine s’effectue en comparant l’AS d’origine dans une mise à jour de routage avec l’AS source autorisée publiée dans les enregistrements RV.
La sécurité fournie par la seule validation de l’origine est connue pour être faible face à un attaquant déterminé, car il n’existe aucune protection contre l’usurpation de l’AS source par un tel attaquant. 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 en sorte que chaque routeur participe directement à l’IDRP, cette méthode est considérée comme trop gourmande en ressources (car de nombreuses opérations de cryptographie à clé publique sont nécessaires pour valider les données de l’ICRP) et trop gourmande en ressources 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 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’a donc besoin que de peu d’informations sur l’infrastructure RPKI et n’a pas d’exigences en matière de cryptographie à clé publique, si ce n’est le mot de passe de transport chiffré. Le routeur utilise ensuite les données téléchargées pour valider les mises à jour d’itinéraire reçues.
Lorsque vous configurez des sessions de serveur, vous pouvez regrouper les sessions et configurer les paramètres de session pour chaque session du groupe. Le routeur tente régulièrement de configurer un nombre maximal configurable de connexions aux serveurs de cache. En cas d’échec de l’établissement de la connexion, une nouvelle tentative de connexion est effectuée périodiquement.
Dans l’intervalle, 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 (active ou inactive) et de la base de données RV (vide ou non vide). 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 unknown, car il n’existe pas d’enregistrement RV pour évaluer un préfixe BGP reçu.
La période de nouvelle tentative est configurable. Après s’être connecté à 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 vivacité en fonction d’un intervalle configurable. Pour ce faire, une unité de données du protocole de requête série (PDU) avec le même numéro de série que celui indiqué par le serveur de cache dans sa dernière PDU de notification. Le serveur de cache répond avec zéro ou plusieurs mises à jour et une PDU de fin de données (EOD), qui actualise également l’état d’activité du serveur de cache et réinitialise un minuteur de durée de vie record.
Lorsqu’un préfixe provient d’un homologue BGP (EBGP) externe, il est examiné par une stratégie d’importation et marqué comme Valide, Non valide, Inconnu ou Non vérifié :
Valid (Valide) : indique que le préfixe et la paire AS se trouvent 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 fait pas partie des préfixes ou des 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é renseignée et que la validation n’est pas demandée 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’une d’entre elles pour être valide. Dans le cas contraire, il n’est pas valide. N’importe quelle correspondance est suffisante pour rendre l’itinéraire valide. Il n’est pas nécessaire qu’il s’agisse d’une 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 la base de données de mappage préfixe à AS, reportez-vous à la Section 2 du brouillon Internet draft-ietf-sidr-pfx-validate-01, Validation de l’origine du préfixe BGP.
La validation RPKI n’est disponible que dans l’instance principale. Si vous configurez la validation RPKI pour une instance de routage, la validation RPKI échoue avec le message RV instance is not runningd’erreur suivant .
Interaction BGP avec la base de données de validation de route
La base de données de validation de route (RV) contient un ensemble 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 susceptibles d’être affectés par les enregistrements RV dans la base de données. (RIB-Local contient les routes IPv4 et IPv6 indiqué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).
Figure 2 montre le processus.
Les politiques 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 qui sont affichées dans la sortie de la commande, tandis que les show route receive-protocol bgp stratégies d’exportation sont appliquées aux routes qui sont affichées par la show route advertising-protocol bgp commande.
Comme illustré dans Figure 3, vous utilisez des stratégies de routage d’importation pour contrôler les routes que BGP place 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 vers ses voisins.
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 l’itinéraire et à définir le validation-state dans la table de routage sur 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). Au sein d’un AS, vous ne souhaitez probablement pas qu’une session RPKI s’exécute sur chaque routeur BGP interne (IBGP). Au lieu de cela, vous avez besoin d’un moyen de transporter l’état de validation sur le maillage IBGP afin que tous les haut-parleurs IBGP disposent d’informations cohérentes. Ceci est accompli en transportant 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.
Junos OS prend en charge les communautés étendues bien connues suivantes pour la validation de routage :
état de validation d’origine valide
état de validation d’origine non valide
état de validation d’origine inconnu
L’exemple suivant de stratégie d’importation BGP 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;
}
}
Routage actif et validation de l’origine en continu
Lorsque vous configurez la validation d’origine sur un routeur doté de deux moteurs de routage et que le routage actif en continu est activé, les moteurs de routage principal et de secours disposent tous deux 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 inactive.
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 et show validation replication database .
Marquage d’une plage de préfixes comme jamais autorisé
Le modèle de validation d’itinéraire présente une lacune majeure : 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 issu d’un AS donné. Cette fonctionnalité peut être fournie dans une certaine mesure à l’aide d’une solution de contournement 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 apparié comme n’importe quel autre. Cela permet une solution de contournement pour marquer une plage de préfixes comme n’ayant jamais été autorisée à être annoncée, car AS 0 n’est pas un AS valide. L’AS de l’enregistrement RV ne correspond jamais à l’AS reçu de l’homologue EBGP. Ainsi, tout préfixe correspondant est marqué comme non valide.
Voir également
Cas d’usage et avantage de la validation de l’origine pour BGP
Si un administrateur d’un système autonome (AS) commence à faire de la publicité pour tout ou partie du réseau attribué à une autre entreprise, BGP ne dispose d’aucune 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 l’AS 2. En raison du fonctionnement des routeurs, la plupart d’entre eux sélectionnent l’itinéraire le plus spécifique et envoient le trafic vers l’AS 1 au lieu de l’AS 2.
Le préfixe piraté est largement visible sur Internet lorsque les routeurs de transit propagent les informations de chemin mises à jour. Les routes non valides peuvent être largement distribuées sur Internet, car les routeurs de la zone franche par défaut (DFZ) transportent la route détournée. Finalement, le chemin AS correct est rétabli vers les homologues BGP, mais dans l’intervalle, il faut s’attendre à des interruptions de service.
Le BGP étant basé 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 erronée pour 10.65.153.0/24. En acceptant cette publicité et en la republiant auprès de ses pairs et de ses fournisseurs, AS 1 propageait la mauvaise voie. Les routeurs qui ont reçu cette route de l’AS 1 l’ont sélectionnée car il s’agissait d’une route plus spécifique. Le fournisseur de contenu réel faisait de la publicité 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 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 pour leur préfixe peut être interrompu pendant de nombreuses 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 produit, il y a un regain d’intérêt pour les solutions à cette vulnérabilité. Le BGP est essentiel aux relations avec les fournisseurs et n’est pas près de disparaître. 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 publicités 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 également
Exemple : Configuration de la validation d’origine pour BGP
Cet exemple montre comment configurer la validation d’origine entre homologues BGP en s’assurant que les annonces de routage reçues sont envoyées (à origine) à partir du système autonome (AS) attendu. Si l’AS d’origine est validé, une stratégie peut spécifier que les préfixes sont, à leur tour, annoncés.
Conditions préalables
Cet exemple a les exigences matérielles et logicielles suivantes :
-
Serveur de cache RPKI (Resource Public Key Infrastructure), qui utilise un logiciel tiers pour authentifier les préfixes BGP.
-
Junos OS version 12.2 ou ultérieure s’exécute sur le périphérique de routage qui communique avec le serveur de cache via une connexion TCP.
Présentation
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 qu’il valide l’AS d’origine et rejette 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’origine AS :
[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 { session address { } } }
Le [edit routing-options validation static] niveau hiérarchique 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 stratégie 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 stratégie 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 homologues IBGP.
Figure 4 montre l’exemple de topologie.
Dans cet exemple, l’appareil R0 dispose d’une connexion IBGP à l’appareil R1 et d’une connexion EBGP à l’appareil R2. L’appareil R0 reçoit les enregistrements de validation de route (RV) du serveur de cache à l’aide du protocole défini dans Internet draft 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’appareil 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 le routage.
Configuration
- Configuration rapide de l’interface de ligne de commande
- Configuration de l’appareil R0
- Configuration de l’appareil R1
- Configuration de l’appareil R2
Configuration rapide de l’interface de ligne de commande
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 l’interface de ligne de commande au niveau de la [edit] hiérarchie.
Appareil 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’appareil 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 l’interface de ligne de commande, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration du Guide de l’utilisateur de l’interface de ligne de commande 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 l’état de validation et les attributs de communauté BGP pour toutes les routes importées (ou reçues) à partir des homologues EBGP de l’appareil R0.Configurez une session IBGP avec l’appareil 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 IGP [Interior Gateway Protocol]) sur l’interface faisant 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. Dans le cas contraire, 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 stratégie 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 stratégie 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
À partir du mode de configuration, confirmez votre configuration en saisissant les show interfacescommandes , show protocols, show policy-optionset 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, passez commit en mode de configuration.
Configuration de l’appareil 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 l’interface de ligne de commande, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration du Guide de l’utilisateur de l’interface de ligne de commande 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 l’état de validation et les attributs de communauté BGP pour toutes les routes reçues des homologues IBGP de l’appareil R1.Configurez une session IBGP avec l’appareil 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 stratégie de routage qui spécifie les attributs à modifier en fonction de l’attribut de communauté BGP d’état de validation des routes BGP reçues de l’appareil 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
À partir du mode de configuration, confirmez votre configuration en saisissant les show interfacescommandes , show protocols, show policy-optionset 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, passez commit en mode de configuration.
Configuration de l’appareil 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 l’interface de ligne de commande, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration du Guide de l’utilisateur de l’interface de ligne de commande 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 stratégie 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
À partir du mode de configuration, confirmez votre configuration en saisissant les show interfacescommandes , show protocols, show policy-optionset 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, passez commit en mode de 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
But
Vérifiez que les routes BGP sur les périphériques R0 et R1 ont les états de validation attendus et les préférences locales attendues.
Action
À 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
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
MultiRecvSens
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
But
Configurez les opérations de traçage pour la validation de l’origine et surveillez les résultats d’un nouvel itinéraire publié.
Action
-
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
Sens
La validation de l’itinéraire fonctionne comme prévu.
Affichage des informations de validation
But
Exécutez les différentes commandes de validation.
Action
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