Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Validation d’origine BGP

Understanding Origin Validation for BGP

La validation en amont permet d’empêcher la publicité non intentionnelle de routes. Parfois, les administrateurs réseau font la publicité à tort 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 en amont (également appelée routage interdomaine sécurisé). La validation de l’origine est un mécanisme permettant d’authentifier les messages de routage comme provenant d’un système autonome attendu (AS). La validation en amont utilise un ou plusieurs serveurs de cache RPKI (Resource Public Key Infrastructure) pour l’authentification des préfixes BGP spécifiés. Pour authentifier un préfixe, le routeur (interlocuteur BGP) interroge la base de données de mappages de 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.

Remarque :

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.

Junos OS prend en charge la validation de l’origine pour les préfixes IPv4 et IPv6.

Figure 1 illustre une topologie d’exemple.

Figure 1 : Topologie d’échantillon pour la validation de l’origineTopologie d’échantillon pour la validation de l’origine

Normes prises en charge

L’implémentation de la validation de l’origine du système d’exploitation Junos OS prend en charge les RFC et les ébauches suivantes :

  • RFC 6810, The Resource Public Key Infrastructure (RPKI) to Router Protocol

  • RFC 6811, Validation de l’origine des préfixes BGP

  • Internet draft-ietf-sidr-origin-validation-signaling-00, BGP Prefix Origin Validation State Extended Community (prise en charge partielle)

    La communauté étendue (état de validation de l’origine) est prise en charge dans la stratégie de routage 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 en origine utilisent des certificats X.509 avec des extensions spécifiées dans les extensions RFC 3779, X.509 pour les adresses IP et les identifiants AS.

Le RPKI consiste en un ensemble distribué d’informations. Chaque autorité de certification publie ses certificats DE (End-Entity), 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 à la disposition de chaque serveur de cache RPKI.

Chaque serveur de cache RPKI gère 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 base de données sont formatées en tant qu’enregistrements de validation de route (RV). Un enregistrement rv est un triple (préfixe, longueur maximale, as d’origine). Il correspond à toute route dont le préfixe correspond au préfixe du RV, dont la longueur de préfixe ne dépasse pas la longueur maximale indiquée dans l’enregistrement du RV, et dont le as d’origine est égal au as d’origine indiqué dans l’enregistrement du 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 permet de vérifier qu’un détenteur d’un bloc d’adresses IP a autorisé un AS à établir des routes vers un ou plusieurs préfixes du 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 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 dans la famille d’adresses (32 pour IPv4 et 128 pour IPv6). La longueur maximale définit le préfixe d’adresse IP que le AS est autorisé à promouvoir.

Par exemple, si le préfixe de l’adresse IP est 200.4.66/24 et que la longueur maximale est 26, le AS est autorisé à promouvoir 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, le AS est uniquement autorisé à annoncer exactement le préfixe spécifié dans le RV.

Par 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 autorise le AS à annoncer tout préfixe commençant par 200.4.66 d’une longueur d’au moins 24 et n’excédant pas 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 le AS d’origine lors d’une mise à jour de routage avec le AS source autorisé publié dans les enregistrements des RV.

À elle seule, la sécurité fournie par la validation de l’origine est faible contre un pirate informatique déterminé, car il n’existe aucune protection contre une telle usurpation de l’AS source. Cela dit, la validation de l’origine offre une protection utile contre les annonces accidentelles.

Bien que la validation en amont puisse être implémentée par la participation directe de chaque routeur au RPKI, elle est jugée trop gourmande en ressources (car de nombreuses opérations cryptographies à clé publique sont requises pour valider les données RPKI) et intensive en termes d’exploitation pour configurer et maintenir une configuration RPKI sur chaque routeur. C’est pourquoi un serveur de cache RPKI distinct procède aux validations des clés publiques 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, à l’exception du mot de passe de transport chiffré. 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 de serveur, vous pouvez regrouper les sessions et configurer les paramètres de session pour chaque session du groupe. Le routeur tente périodiquement de configurer un nombre maximal de connexions configurables aux serveurs de cache. Si la configuration de la connexion échoue, une nouvelle tentative de connexion est effectuée périodiquement.

Dans l’intervalle, une fois que la stratégie d’importation de validation est appliquée à la session BGP, la validation de route est effectuée indépendamment de l’état de session du cache (en hausse ou en baisse) et de la base de données RV (vide ou non vide). Si la base de données des RV est vide ou qu’aucune des sessions du serveur de cache n’est opérationnelle, l’état de validation de chaque route est défini comme inconnu, car aucun enregistrement de RV n’existe pour évaluer un préfixe BGP reçu.

La période de tentative de nouvelle tentative est configurable. Une fois connecté à un serveur de cache, le routeur interroge le dernier numéro de série de la base de données et demande que le cache RPKI transmette toutes les entrées RV appartenant à cette version de la base de données.

Chaque message entrant réinitialise un compteur de ligne en direct pour le serveur de cache RPKI. Une fois toutes les mises à jour apprises, le routeur effectue des vérifications périodiques en direct en fonction d’un intervalle configurable. Ceci est fait en envoyant une unité de données de 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 notification PDU. Le serveur de cache répond par un minimum de mises à jour et un PDU de fin de données (EOD), ce qui actualise également l’état de la liaison en direct du serveur de cache et réinitialise un compteur à durée de vie record.

Lorsqu’un préfixe est reçu d’un pair BGP externe (EBGP), il est examiné par une stratégie d’importation et marqué comme Valide, Non valide, Inconnu ou Nonverifié :

  • 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 soit le AS correspondant reçu de l’pair EBGP n’est pas le AS qui apparaît dans la base de données, soit la longueur de préfixe du 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 plages de préfixes de la base de données.

  • Non certifié : indique que l’origine du préfixe n’est pas vérifiée par rapport à la base de données. En effet, la base de données a été remplie et 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 n’est pas activée pour les pairs BGP.

S’il existe des correspondances potentielles pour la route dans la base de données de validation, celle-ci doit correspondre à l’une d’entre elles pour être valide. Sinon, elle n’est pas valide. Toute correspondance est suffisante pour que la route soit valide. Il n’a pas besoin d’être un meilleur match. Ce n’est que s’il n’y a pas de correspondances possibles que la route est considérée comme inconnue. Pour plus d’informations sur la logique de base de données de mappage de préfixe à AS, reportez-vous à la section 2 du projet Internet draft-ietf-sidr-pfx-validate-01, BGP Prefix Origin Validation.

Remarque :

La validation RPKI est disponible uniquement 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 de RV que le routeur télécharge depuis le serveur de cache RPKI. Une fois que la base de données des RV est remplie d’enregistrements de RV, celle-ci analyse la table de routage RIB-Local pour déterminer s’il y a des préfixes dans RIB-Local susceptibles d’être affectés par les enregistrements des 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 re-évaluation BGP des stratégies d’importation BGP (et non des stratégies d’exportation).

Figure 2 affiche le processus.

Figure 2 : BGP et validation de route

Des 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 qui sont affichées par la show route advertising-protocol bgp commande.

Comme indiqué dans le livre Figure 3, vous utilisez les stratégies de routage d’importation pour contrôler les routes BGP places dans la table de routage, et les stratégies de routage d’exportation pour contrôler les routes dont BGP fait la publicité depuis la table de routage vers ses voisins.

Figure 3 : Stratégies de routage d’importation et d’exportationStratégies de routage d’importation et d’exportation

Lorsque vous configurez une stratégie d’importation de validation de routage, 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 des RV pour 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, cette from validation-database condition déclenche une recherche dans la base de données des RV du routeur. Une action est effectuée si l’état de validation est valide. L’action consiste à accepter la route et à définir la validation-state valeur valide dans la table de routage.

Attribut de la communauté pour annoncer l’état de validation RPKI aux voisins IBGP

La validation des préfixes 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 tous les routeurs BGP (IBGP) internes. Au lieu de cela, vous avez besoin d’un moyen de transporter l’état de validation sur le maillage IBGP afin que toutes les enceintes IBGP disposent d’informations cohérentes. Ceci est accompli en portant l’état de validation dans une communauté étendue non transitive. L’attribut de la communauté annonce et reçoit l’état de validation d’un préfixe entre les voisins IBGP.

Junos OS prend en charge les communautés étendues connues suivantes pour la validation de route :

  • validation d’origine- état valide

  • validation d’origine-état non valide

  • validation d’origine-état-inconnu

L’exemple suivant de stratégie d’importation BGP est configuré sur le routeur doté d’une session avec un serveur RPKI.

Routeur avec session RPKI

L’exemple suivant de stratégie d’importation BGP est configuré sur un routeur d’appairage IBGP qui ne dispose pas d’une session avec un serveur RPKI.

Routeur d’appairage IBGP sans session RPKI

Routage actif ininterrompu et validation de l’origine

Lorsque vous configurez la validation en amont sur un routeur doté de deux moteurs de routage et que le routage actif ininterrompu est activé, le moteur principal et le moteur de routage de réserve ont une copie de la base de données des RV. Ces deux bases de données de RV restent synchronisées les unes avec les autres.

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 veille, la session du serveur de cache RPKI est toujours en panne.

La base de données du RV est gérée activement par le moteur de routage principal par le biais de sa session avec le serveur RPKI. Cette base de données est répliquée sur le moteur de routage de veille. Bien que la session soit en panne sur le moteur de routage de veille, la base de données des RV répliquées contient des enregistrements de RV. Lorsque les commutateurs du moteur de routage de réserve sont terminés et deviennent le moteur de routage principal, il dispose déjà d’une base de données de RV entièrement remplie.

Pour afficher le contenu des deux bases de données, utilisez les commandes et show validation replication database lesshow validation database.

Marquage d’une plage de préfixes non autorisée

Le modèle de validation de route présente une lacune majeure : Il ne fournit que des mises à jour positives. Il peut indiquer quel AS est le propriétaire légitime d’un préfixe. Cependant, il ne peut pas explicitement transmettre 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 n’essaie pas de restreindre les entrées du cache. Par exemple, un enregistrement de RV avec as 0 d’origine est installé et assorti comme n’importe quel autre. Cela permet à une solution de contournement de marquer une plage de préfixes comme jamais autorisé à être annoncé, car l’AS 0 n’est pas un AS valide. Le record de l’AS dans le RV ne correspond jamais à l’AS reçu de l’pair EBGP. Par conséquent, tout préfixe correspondant est marqué non valide.

Cas d’utilisation et validation des avantages de l’origine pour BGP

Si un administrateur d’un système autonome (AS) commence à annoncer tout ou partie du réseau assigné d’une autre entreprise, BGP n’a pas de méthode intégrée pour reconnaître l’erreur et répondre d’une manière qui éviterait les interruptions de service.

Supposons, par exemple, qu’un administrateur d’un réseau client présente par erreur un itinéraire (disons 10.65.153.0/24) dirigeant le trafic vers le fournisseur de services AS 1 du client. 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 du fonctionnement des routeurs, la plupart des routeurs sélectionnent le routage le plus spécifique et envoient le trafic à l’AS 1 au lieu de l’AS 2.

Le préfixe détourné est largement visible sur Internet à mesure que les routeurs de transit propagent les informations de chemin mises à jour. Les routes non valides peuvent être distribuées largement sur Internet, car les routeurs de la zone libre par défaut (DFZ) effectuent la route détournée. Le chemin AS correct est finalement rétabli dans les pairs BGP, mais dans l’intervalle, des interruptions de service doivent être attendues.

BGP s’appuyant 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é la publicité défectueuse pour 10.65.153.0/24. En acceptant cette publicité et en la revertant à ses pairs et fournisseurs, AS 1 propageait la mauvaise route. Les routeurs qui ont reçu cette route de l’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é 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 efficacement le détournement.

Même avec la détection et la réaction rapides du fournisseur de contenu et la coopération avec d’autres fournisseurs, le service pour leur 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 type d’événements survient, les solutions à cette vulnérabilité ne ce sont pas les mêmes. 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 vers BGP et un modèle client-serveur distribué qui évite la surtaxation des processeurs du routeur.

La validation origin permet de surmonter la vulnérabilité de confiance transitive en permettant à un fournisseur de limiter les publicités qu’il accepte d’un client. La mécanique implique la communication de stratégies de routage basées sur un attribut de communauté BGP étendu.

Exemple : Configuration de la validation en origine pour BGP

Cet exemple montre comment configurer la validation en amont entre les pairs BGP en veillant à ce que les annonces de route reçues soient envoyées (provenant) du système autonome attendu (AS). Si le 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 présente les exigences matérielles et logicielles suivantes :

  • Serveur de cache RPKI (Resource Public Key Infrastructure), utilisant un logiciel tiers pour authentifier les préfixes BGP.

  • Junos OS Version 12.2 ou ultérieure s’exécutant sur l’équipement de routage qui communique avec le serveur de cache via une connexion TCP.

Présentation

Parfois, des routes sont annoncées non intentionnellement en raison d’une erreur de l’opérateur. Pour éviter ce problème de sécurité, vous pouvez configurer BGP pour valider le 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 as d’origine :

Cet exemple utilise des 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 :

Le [edit routing-options validation static] niveau hiérarchique vous permet de configurer des enregistrements statiques sur un équipement de routage, ce qui permet d’écraser les enregistrements reçus à partir d’un serveur de cache RPKI.

Par exemple :

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 les pairs BGP externe (EBGP) et BGP interne (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 de communauté validation-état entre pairs IBGP.

Figure 4 illustre la topologie de l’échantillon.

Figure 4 : Topologie de validation de l’origine Topologie de validation de l’origine

Dans cet exemple, l’unité R0 dispose d’une connexion IBGP à l’unité R1 et d’une connexion EBGP à l’équipement R2. L’unité R0 reçoit des enregistrements de validation de route (RV) à partir du serveur de cache à l’aide du protocole défini dans Internet draft-ietf-sidr-rpki-rtr-19, Le protocole RPKI/routeur pour envoyer les enregistrements RV. Le protocole RPKI-Router s’exécute sur TCP. Les enregistrements des RV sont utilisés par l’unité R0 pour créer une base de données de RV locale. Sur l’unité R1, l’état de validation est défini en fonction de la communauté BGP appelée « validation-état », reçue avec la route.

Configuration

Configuration rapide CLI

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez tous les sauts de ligne, modifiez tous les détails nécessaires pour correspondre à la configuration de votre réseau, puis copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie.

Équipement R0

Équipement R1

Équipement R2

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 l’interface de ligne de commande, reportez-vous à Using the CLI Editor in Configuration Mode dans le Junos OS CLI User Guide.

Pour configurer l’unité R0 :

  1. Configurez les interfaces.

  2. Configurer BGP.

    Appliquez la send-direct stratégie d’exportation pour exporter les routes directes de la table de routage vers BGP.

    Appliquez la validation stratégie d’importation pour définir l’état de validation et les attributs de la communauté BGP pour toutes les routes importées (ou reçues) des pairs EBGP de l’équipement R0.

    Configurez une session IBGP avec l’équipement R1. Configurez une session EBGP avec l’équipement R2.

  3. Configurez OSPF (ou un autre protocole de passerelle intérieure [IGP]) sur l’interface face à l’pair 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.

  4. Configurez la stratégie de routage qui exporte les routes directes de la table de routage vers BGP.

  5. Configurez la stratégie de routage qui spécifie les attributs à modifier en fonction de l’état de validation de chaque route BGP.

  6. Configurez la session avec le serveur de cache RPKI.

  7. Configurez le numéro de système autonome (AS).

Résultats

À partir du mode de configuration, confirmez votre configuration en entrant les show interfacescommandes , show protocolset show policy-optionsshow routing-options . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez terminé la configuration de l’unité, entrez commit dans le mode de 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 l’interface de ligne de commande, reportez-vous à Using the CLI Editor in Configuration Mode dans le Junos OS CLI User Guide.

Pour configurer l’équipement R1 :

  1. Configurez les interfaces.

  2. Configurer BGP.

    Appliquez la validation-ibgp stratégie d’importation pour définir les attributs de la communauté BGP et de l’état de validation pour toutes les routes reçues des pairs IBGP de l’équipement R1.

    Configurez une session IBGP avec l’équipement R0.

  3. Configurez OSPF.

  4. Configurez la stratégie de routage qui spécifie les attributs à modifier en fonction de l’attribut de communauté BGP de validation-état des routes BGP reçues de l’équipement R0.

  5. Configurez le numéro de système autonome (AS).

Résultats

À partir du mode de configuration, confirmez votre configuration en entrant les show interfacescommandes , show protocolset show policy-optionsshow routing-options . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez terminé la configuration de l’unité, entrez commit dans le mode de 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 l’interface de ligne de commande, reportez-vous à Using the CLI Editor in Configuration Mode dans le Junos OS CLI User Guide.

Pour configurer l’équipement R2 :

  1. Configurez les interfaces.

    Plusieurs adresses sont configurées sur l’interface de bouclage pour servir de routes à des fins de démonstration.

  2. Configurer BGP.

  3. Configurez la stratégie de routage.

  4. Configurez le numéro de système autonome (AS).

Résultats

À partir du mode de configuration, confirmez votre configuration en entrant les show interfacescommandes , show protocolset show policy-optionsshow routing-options . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez terminé la configuration de l’unité, entrez commit dans le 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

But

Vérifiez que les routes BGP des équipements R0 et R1 disposent des états de validation attendus et des préférences locales attendues.

Action

Dans le mode opérationnel, saisissez la show route commande.

Sens

Les routes ont les états de validation attendus et les valeurs de préférence locale, basées sur les informations reçues du serveur de cache RPKI.

Utilisation des opérations trace

But

Configurez les opérations de traçage pour la validation de l’origine et surveillez les résultats d’un routage nouvellement annoncé.

Action
  • Sur l’unité R0, configurez le traçage.

  • Sur l’unité R2, ajoutez un routage en ajoutant une autre adresse sur l’interface de bouclage.

  • Sur l’unité R0, vérifiez le fichier de trace.

Sens

La validation du routage fonctionne comme prévu.

Affichage des informations de validation

But

Exécutez les diverses commandes de validation.

Action