Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

BGP Origin Validation

Understanding Origin Validation for BGP

La validation en origine permet d’empêcher la publicité non intentionnelle des routes. Parfois, les administrateurs réseau font souvent la publicité de 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 origine (également appelée routage interdomaine sécurisé). La validation en origine est un mécanisme permettant d’authentifier les publicités de route comme étant issues d’un système (AS). La validation en origine utilise un ou plusieurs serveurs de cache RPKI (Resource Public Key Infrastructure) pour l’authentification BGP préfixes. Pour authentifier un préfixe, le routeur (BGP speaker) interroge la base de données de mappages validées de préfixe à AS, téléchargées depuis le serveur de cache, et garantit que le préfixe est originaire d’une AS attendue.

Remarque :

Lorsque vous activez l’authentification RPKI, Junos OS le port TCP 2222 ouvre automatiquement le port TCP 2222 sans préavis. Vous pouvez appliquer un filtre pour bloquer et sécuriser ce port.

Junos OS processus de validation en origine pour les préfixes IPv4 et IPv6.

Figure 1 présente un exemple de topologie.

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

Normes prise en charge

L’Junos OS de validation en origine prend en charge les RFC et les ébauches suivantes:

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

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

  • Projet Internet draft-ietf-sidr-origin-validation-signaling-00, BGP Préfix Origin Validation State Extended Community (assistance partielle)

    La communauté étendue (état de validation de l’origine) est prise en charge Junos OS routage. La modification spécifiée de la procédure de sélection du route n’est pas prise en charge.

Fonctionnement de la validation en origine

L’utilisation des certificats RPKI et de validation d’origine X.509 avec extensions spécifiées dans les RFC 3779, X.509 Extensions pour adresses IPet identifiants AS IP .

La RPKI se compose d’une collecte d’informations distribuée. Chaque autorité de certification publie ses certificats d’entité finale, ses listes devocation de certificats 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 conserve un cache local de l’ensemble de la collecte de référentiels distribués en synchronisant régulièrement chaque élément du cache local par rapport au point de publication du référentiel d’origine.

Sur le routeur, les entrées de la base de données sont formatées comme enregistrements de validation de route (RV). Un enregistrement de rv est un triple (préfixe, longueur maximale, origine AS). Il est équivalent à toute route dont le préfixe est en correspondance avec le préfixe RV, dont la longueur de préfixe ne dépasse pas la longueur maximale donnée dans l’enregistrement de RV et dont la AS d’origine équivaut à la AS d’origine donnée dans le dossier de 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 de bloc d’adresse IP a autorisé un AS à origine des routes vers un ou plusieurs préfixes du bloc d’adresse. Les roA ne sont pas directement utilisés pour la validation de route. Le serveur de cache exporte une version simplifiée du roa vers le routeur en tant qu’enregistrement de 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 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 d’adresse IP est 200.4.66/24 et que la longueur maximale est 26, l’AS est autorisée à 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é à promouvoir exactement le préfixe spécifié dans le RV.

Autre exemple, une 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. Cette rv autoriserait l’AS à promouvoir tout préfixe commençant par 200.4.66 avec une longueur d’au moins 24 et au plus 26, ainsi que le préfixe spécifique 200.4.66.0/28.

L’origine d’un routeur est représentée par le numéro de AS droit de l’attribut AS_PATH. La validation en origine fonctionne en comparant les AS en origine dans une mise à jour de routage avec la AS source autorisée publiée dans les enregistrements RV.

À lui seul, la sécurité fournie par la validation de l’origine est faible face à un pirate informatique déterminé, car aucune protection ne protège contre l’usurpation de la AS. Cela dit, la validation de l’origine fournit une protection utile contre les annonces accidentelles.

Bien que la validation de l’origine puisse être implémentée en faisant participer directement chaque routeur au RPKI, cette opération est considérée comme trop importante en matière de ressources (de nombreuses opérations de cryptage à clé publique sont nécessaires pour valider les données RPKI) et opérationnellement intensive pour mettre en place et entretenir une configuration RPKI sur chaque routeur. Pour cette raison, un serveur de cache RPKI distinct effectue des validations à clés publiques et génère une base de données validée de mappages préfixes vers AS sécurisés. La base de données validée est téléchargée sur un routeur client par une connexion TCP sécurisée. Le routeur ne nécessite donc que peu d’informations sur l’infrastructure RPKI et ne nécessite aucune exigence de cryptage à clé publique, autre que le 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 serveur, vous pouvez grouper les sessions ensemble et configurer les paramètres de session pour chaque session du groupe. Le routeur tente régulièrement de configurer un nombre maximal de connexions configurables vers des serveurs de cache. En cas d’échec de la configuration de la connexion, une nouvelle tentative de connexion est régulièrement réalisée.

Dans l’intervalle, après l’application de la stratégie d’importation de validation à la session BGP, la validation de route est effectuée indépendamment de l’état de la session de cache (en hausse ou en panne) et de la base de données rv (vide ou non vide). Si la base de données de rv est vide ou qu’aucune session du serveur de cache n’est en cours de mise en place, l’état de validation de chaque route est définir vers inconnu, car il n’existe aucun enregistrement rv pour évaluer un préfixe de BGP’utilisateur.

La période de nouvelle tentative est configurable. Une fois la connexion réussie à 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 convivialité pour le serveur de cache RPKI. Une fois toutes les mises à jour apprises, le routeur effectue des contrôles périodiques de la qualité de vie en fonction d’un intervalle configurable. Pour cela, il est possible d’envoyer une unité de données de protocole de requête série (PDU) avec le même numéro de série que celui signalé par le serveur de cache dans son dernier PDU de notification. Le serveur de cache répond avec une mise à jour zéro ou plus et un PDU de fin de données (EOD), qui actualise également l’état de qualité du serveur de cache et réinitialise un compteur à vie record.

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

  • Valide: indique que la paire de préfixes et de AS est trouvée dans la base de données.

  • Non valide: indique que le préfixe est trouvé, mais la AS correspondante reçue de l’pair EBGP n’est pas la AS qui apparaît dans la base de données, ou la longueur de préfixe du message de mise à jour BGP est plus longue que la longueur maximale autorisée dans la base de données.

  • Inconnue: indique que le préfixe ne se trouve pas dans la plage de préfixes ou de préfixes de la base de données.

  • Non vérifiée: 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 appelée dans la stratégie d’importation du BGP, bien que la validation en origine soit activée ou que la validation en origine ne soit pas activée pour les pairs BGP.

S’il existe des correspondances potentielles pour le routeur dans la base de données de validation, la route doit correspondre à l’une d’entre elles pour être valide. Dans le cas contraire, elle n’est pas valide. Toutes les correspondances sont suffisantes pour assurer la validité de la route. Il n’a pas besoin d’être la meilleure correspondance. La route considérée comme inconnue n’est possible que si aucune correspondance n’est possible. Pour plus d’informations sur la logique de base de données de mappage de préfixes à AS, consultez la section 2 du projet d’Internet draft-ietf-sidr-pfx-validate-01, BGP Prefix Origin Validation.

Remarque :

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 d’erreur RV instance is not running suivant.

BGP interaction 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 téléchargés par le routeur à partir du serveur de cache RPKI. Une fois que la base de données de rv est remplie d’enregistrements de RV, la base de données de rv analyse la table de routage RIB-Local pour déterminer s’il y a des préfixes dans RIB-Local qui peuvent être affectés par les enregistrements de RV dans la base de données. (RIB-Local contient les routes IPv4 et IPv6 indiquées dans le résultat de la show route protocol bgp commande.)

Ce processus déclenche une BGP de nouvelles BGP d’importation (et non des stratégies d’exportation).

Figure 2 indique le processus.

Figure 2 : BGP et validation de route

Les stratégies d’importation sont appliquées à la rib-in. Une autre façon de comprendre cela est que les stratégies d’importation s’appliquent aux routes indiquées dans le résultat de la commande, tandis que les stratégies d’exportation s’appliquent aux routes indiquées par show route receive-protocol bgp la show route advertising-protocol bgp commande.

Comme illustré dans ce rapport, vous utilisez des stratégies de routage d’importation pour contrôler quels BGP lieux dans la table de routage et exporter les stratégies de routage pour contrôler les routes BGP qui font la publicité de la table de routage vers ses Figure 3 voisins.

Figure 3 : Importation et exportation des polices de routageImportation et exportation des polices de routage

Lorsque vous configurez une stratégie d’importation de validation de route, la configuration de la stratégie utilise une validation-database condition de correspondance. Cette condition de correspondance déclenche une requête dans la base de données de 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é.

Dans les BGP d’importation suivantes, cette condition déclenche une recherche dans la base de données de rv du from validation-database routeur. Une action est prise si l’état de validation est valide. L’action consiste à accepter le routage et à définir la table de validation-state routage comme valide.

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). Dans un AS, vous ne souhaitez probablement pas qu’une session RPKI s’exécute sur chaque routeur de BGP interne (IBGP). Vous avez plutôt besoin d’un moyen de valider l’état de validation sur l’ensemble du maillage IBGP afin que tous les intervenants IBGP ont des informations cohérentes. Pour cela, il est possible de transporter l’état de validation au sein d’une communauté étendue non transitive. L’attribut de 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 suivantes, connues pour la validation de route:

  • validation d’origine- valide sur l’état

  • origin-validation-state-invalid

  • origin-validation-state-unknown

L’exemple suivant BGP d’importation est configuré sur le routeur qui dispose d’une session avec un serveur RPKI.

Routeur avec session RPKI

L’échantillon suivant BGP d’importation est configuré sur un routeur pair IBGP qui n’a pas de session avec un serveur RPKI.

Routeur pair IBGP sans session RPKI

Validation du routage actif et de l’origine en continu

Lorsque vous configurez la validation d’origine sur un routeur 2 moteurs de routage et que le routage actif sans arrêt est activé, les moteurs de routage principaux et de veille disposent à la fois d’une copie de la base de données rv. Ces deux bases de données de rv restent synchronisées entre elles.

Le routeur ne conserve pas deux sessions identiques avec le serveur RPKI. Le protocole RPKI-RTR s’exécute uniquement sur le moteur de routage principal. En veille, moteur de routage la session du serveur de cache RPKI est toujours en veille.

La base de données des rv est activement conservée par le serveur MOTEUR DE ROUTAGE de sa session avec le serveur RPKI. Cette base de données est répliquée en veille moteur de routage. Bien que la session soit down on the standby moteur de routage, la base de données DE RV dupliquée contient des enregistrements de RV. Lors de la mise en moteur de routage de commutateurs en veille et de devenir la moteur de routage principale, elle 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 show validation database les commandes et les show validation replication database données.

Marquage d’une plage de préfixes comme jamais autorisé

Le modèle de validation de route présente une lacune majeure: Seules les mises à jour sont positives. Il peut déclarer qui AS propriétaire légitime d’un préfixe. Cependant, il ne peut transmettre une mise à jour négative, comme dans: Ce préfixe n’est jamais issu d’AS. Cette fonctionnalité peut être fournie dans une certaine mesure avec une solution AS 0.

L Junos OS implémentation ne tente pas de limiter ses entrées dans le cache. Par exemple, un enregistrement de rv avec l’AS 0 est installé et assorti comme n’importe quel autre. Ceci permet à une solution de contournement de marquer une plage de préfixes non autorisée car AS 0 n’est pas une AS. La AS dans l’enregistrement de rv n’est jamais égal à AS de l’pair EBGP. Ainsi, tout préfixe correspondant est marqué non valide.

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

Si un administrateur d’un système autonome (AS) commence à publicitairer tout ou partie du réseau assigné par une autre entreprise, BGP ne dispose d’aucune méthode intégrée pour identifier l’erreur et répondre de manière à éviter les interruptions de service.

Imaginons par exemple qu’un administrateur d’un réseau client fait la publicité d’une route (voyons 10.65.153.0/24) diriger 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 contenus réel (10.65.152.0/22) qui dirige le trafic vers AS 2. Étant donné le mode de travail des routeurs, la plupart des routeurs choisissent le routeur le plus spécifique et envoient le trafic AS 1 au lieu de AS 2.

Le préfixe détourné est largement visible sur Internet, car les routeurs de transit propagent les informations de chemin mises à jour. Les routes non valides peuvent être largement distribuées sur Internet, les routeurs de la zone de libre par défaut (DFZ) étant porteurs de la route détournée. Le chemin d’accès AS correct est éventuellement rétabli pour les pairs BGP, mais il est donc temps de s’attendre à des interruptions de service.

Parce BGP’un modèle de confiance transitif, la validation entre le client et le fournisseur est importante. Dans l’exemple ci-dessus, le fournisseur de AS 1 n’a pas validé la publicité défa etc. pour 10.65.153.0/24. En acceptant cette publicité et en la lisant pour ses pairs et fournisseurs, AS 1 propageait la mauvaise route. Les routeurs qui ont reçu ce routeur AS 1 l’ont choisie, car il s’agissait d’un routeur plus spécifique. Le fournisseur de contenus faisait effectivement de la publicité sur la valeur 10.65.152.0/22 avant que l’erreur ne se produit. Le /24 était une publicité plus petite (et plus spécifique). Conformément au processus habituel BGP de sélection du routeur, le /24 a ensuite été choisi, ce qui a terminé la détourner.

Même avec une détection et une réaction rapides du fournisseur de contenus et grâce à la coopération avec d’autres fournisseurs, le service pour leurs préfixes peut être interrompu de plusieurs minutes, voire plusieurs heures. La durée exacte de la panne dépend de votre position sur Internet. Lorsque ce type d’événement se produit, l’intérêt pour les solutions de cette vulnérabilité se fait de plus en plus nombreux. BGP les relations fournisseur sont fondamentales et ne s’en vont pas de sitôt. Cet exemple illustre une solution qui utilise la validation de l’origine. Cette solution s’appuie sur des extensions cryptographiques pour BGP et sur un modèle client-serveur distribué qui évite le surtaxage des processeurs de routeur.

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

Exemple: Configuration de la validation en origine pour les BGP

Cet exemple montre comment configurer la validation en origine entre les pairs BGP en s’assurant que les messages de route reçus sont envoyés (originaires) du système autonome attendu (AS). Si l’AS en origine est validée, 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 BGP préfixes.

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

Présentation

Des routes sont parfois annoncées, sans le savoir, en raison d’une erreur de l’opérateur. Pour éviter ce problème de sécurité, vous pouvez configurer les BGP valider l’AS d’origine et rejeter ces annonces non valides. Cette fonctionnalité utilise un serveur de cache pour authentifier les préfixes ou plages de préfixes.

Les instructions de configuration suivantes permettent la validation AS origine:

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:

Le niveau de hiérarchie vous permet de configurer des enregistrements statiques sur un équipement de routage, de manière à overwriter les enregistrements reçus d’un serveur [edit routing-options validation static] de cache RPKI.

Quelques chiffres clés :

Vous pouvez configurer une stratégie de routage qui fonctionne en fonction de l’état de validation d’un préfixe de routage. Vous pouvez utiliser un attribut de communauté pour annoncer et recevoir l’état de validation d’un préfixe entre les pairs EBGP (External BGP) et IBGP (Internal BGP). 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é d’état de validation entre les pairs IBGP.

Figure 4 affiche la topologie de l’exemple.

Figure 4 : Topologie pour la validation en origineTopologie pour la validation en origine

Dans cet exemple, l’unité R0 dispose d’une connexion IBGP à l’équipement R1 et d’une connexion EBGP à l’équipement R2. L’équipement R0 reçoit des enregistrements de validation de route (RV) provenant du serveur de cache à l’aide du protocole défini dans le projet Internet draft-ietf-sidr-rpki-rtr-19, the RPKI/Router Protocol to send the RV records. Le protocole RPKI-Router s’exécute sur TCP. Les enregistrements de RV sont utilisés par l’équipement R0 pour construire une base de données de RV locale. L’état de validation de l’équipement R1 est basé sur la communauté BGP appelée validation-state, reçue avec le routeur.

Configuration

CLI configuration rapide

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les interruptions de ligne, modifiez tous les détails nécessaires pour correspondre à votre configuration réseau, puis copiez/collez les commandes dans le CLI 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 dans différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la CLI, consultez le manuel Using the CLI Editor in Configuration Mode dans le Junos OS CLI User Guide.

Pour configurer l’équipement R0:

  1. Configurez les interfaces.

  2. Configurez BGP.

    Appliquez la stratégie d’exportation de sorte que les send-direct routes directes soient exportées depuis la table de routage vers BGP.

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

    Configurer 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 qui fait face à l’pair IBGP et sur l’interface de bouclation.

    Remarque :

    Si vous utilisez l’adresse d’interface de bouclation dans l’instruction IBGP, vous devez activer une neighbor IGP sur l’interface de bouclation. Sinon, la session IBGP n’est pas établie.

  4. Configurez la stratégie de routage qui exporte des routes directes depuis 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 BGP route.

  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 interfaces commandes et le , et show protocolsshow policy-optionsshow routing-options le 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’équipement, commit saisissez-le en mode de configuration.

Configuration de l’équipement R1

Procédure étape par étape

L’exemple suivant vous oblige à naviguer dans différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la CLI, consultez le manuel Using the CLI Editor in Configuration Mode dans le Junos OS CLI User Guide.

Pour configurer l’équipement R1:

  1. Configurez les interfaces.

  2. Configurez BGP.

    Appliquez la stratégie d’importation pour définir l’état de validation et BGP communauté pour toutes les routes reçues des validation-ibgp 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 validation d’état de validation des routes BGP reçues depuis 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 interfaces commandes et le , et show protocolsshow policy-optionsshow routing-options le 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’équipement, commit saisissez-le en mode de configuration.

Configuration de l’équipement R2

Procédure étape par étape

L’exemple suivant vous oblige à naviguer dans différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la CLI, consultez le manuel 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 loopback pour servir de routes à des fins de démonstration.

  2. Configurez 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 interfaces commandes et le , et show protocolsshow policy-optionsshow routing-options le 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’équipement, commit saisissez-le en mode de configuration.

Vérification

Vérifier 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 d BGP de l’équipement R0 et de l’équipement R1 ont les états de validation attendus et les préférences locales attendues.

Action

À partir du 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 valider l’origine et surveillez les résultats d’une nouvelle route annoncée.

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

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

  • Sur l’équipement R0, vérifiez le fichier de traçage.

Sens

La validation de route fonctionne comme prévu.

Affichage des informations de validation

But

Exécutez les diverses commandes de validation.

Action