Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
Sur cette page
 

Stratégies de routage BGP de base

Comprendre les stratégies de routage

Chaque stratégie de routage est identifiée par un nom de stratégie. Le nom peut contenir des lettres, des chiffres et des traits d’union (-) et peut comporter jusqu’à 255 caractères. Pour inclure des espaces dans le nom, placez le nom entier entre guillemets. Chaque nom de stratégie de routage doit être unique au sein d’une configuration.

Une fois qu’une stratégie est créée et nommée, elle doit être appliquée avant d’être active. Vous appliquez les stratégies de routage à l’aide des instructions import et export au niveau de la protocols protocol-name hiérarchie de configuration.

Dans l’instruction import , vous indiquez le nom de la stratégie de routage à évaluer lorsque des routes sont importées dans la table de routage à partir du protocole de routage.

Dans l’instruction export , vous indiquez le nom de la stratégie de routage à évaluer lorsque les routes sont exportées de la table de routage vers un protocole de routage dynamique. Seuls les itinéraires actifs sont exportés à partir de la table de routage.

Pour spécifier plusieurs stratégies et créer une chaîne de stratégies, vous devez répertorier les stratégies à l’aide d’un espace comme séparateur. Si plusieurs stratégies sont spécifiées, elles sont évaluées dans l’ordre dans lequel elles sont spécifiées. Dès qu’une action d’acceptation ou de rejet est exécutée, l’évaluation de la chaîne de stratégies se termine.

Voir également

Exemple : Application de stratégies de routage à différents niveaux de la hiérarchie BGP

Cet exemple montre BGP configuré dans une topologie de réseau simple et explique comment les stratégies de routage prennent effet lorsqu’elles sont appliquées à différents niveaux de la configuration BGP.

Conditions préalables

Aucune configuration spéciale au-delà de l’initialisation de l’appareil n’est requise avant de configurer cet exemple.

Présentation

Pour BGP, vous pouvez appliquer les stratégies comme suit :

  • BGP global import and export statements (Instructions et globales BGP ) : incluez ces instructions au niveau de la [edit protocols bgp] hiérarchie (pour les instances de routage, incluez-les au niveau de la [edit routing-instances routing-instance-name protocols bgp] hiérarchie).

  • Group and statements (Group import and export statements) : incluez ces instructions au niveau de la [edit protocols bgp group group-name] hiérarchie (pour les instances de routage, incluez-les au niveau de la [edit routing-instances routing-instance-name protocols bgp group group-name] hiérarchie).

  • Peer import and export statements (Homologue et instructions) : incluez ces instructions au niveau de la [edit protocols bgp group group-name neighbor address] hiérarchie (pour les instances de routage, incluez-les au niveau de la [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address] hiérarchie).

Un niveau homologue import ou export une instruction remplace un groupe import ou export une instruction. Un niveau homologue import ou export une instruction remplace un groupe import ou export une instruction.

Dans cet exemple, une stratégie nommée send-direct est appliquée au niveau global, une autre stratégie nommée send-192.168.0.1 est appliquée au niveau du groupe et une troisième stratégie nommée send-192.168.20.1 est appliquée au niveau voisin.

Un point clé, souvent mal compris et qui peut entraîner des problèmes, est que dans une telle configuration, seule la politique la plus explicite est appliquée. Une stratégie de voisinage est plus explicite qu’une stratégie de groupe, qui à son tour est plus explicite qu’une stratégie globale.

Le voisin 172.16.2.2 n’est soumis qu’à la politique send-192.168.20.1. Le voisin 172.16.3.3, n’ayant rien de plus spécifique, n’est soumis qu’à la politique send-192.168.0.1. Pendant ce temps, le voisin 172.16.4.4 dans le groupe autre-groupe n’a pas de stratégie de groupe ou de voisinage, il utilise donc la stratégie d’envoi direct.

Si vous avez besoin que le voisin 172.16.2.2 exécute la fonction des trois stratégies, vous pouvez écrire et appliquer une nouvelle stratégie de voisinage qui englobe les fonctions des trois autres, ou vous pouvez appliquer les trois stratégies existantes, en tant que chaîne, au voisin 172.16.2.2.

Topologie

Figure 1 montre l’exemple de réseau.

Figure 1 : Application de stratégies de routage à BGPApplication de stratégies de routage à BGP

Configuration rapide de l’interface de ligne de commande affiche la configuration de tous les périphériques dans Figure 1.

Cette section #d99e203__d99e457 décrit les étapes à suivre sur l’appareil R1.

Configuration

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 R1

Appareil R2

Appareil R3

Appareil R4

Procédure

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 de configuration dans le Guide de l’utilisateur de l’interface de ligne de commande.

Pour configurer une stratégie de routage IS-IS par défaut :

  1. Configurez les interfaces de l’appareil.

  2. Activez OSPF, ou un autre protocole IGP (Interior Gateway Protocols), sur les interfaces.

  3. Configurez les routes statiques.

  4. Activez les stratégies de routage.

  5. Configurez BGP et appliquez les stratégies d’exportation.

  6. Configurez l’ID du routeur et le numéro du système autonome (AS).

  7. Si vous avez terminé de configurer l’appareil, validez la configuration.

Résultats

À partir du mode configuration, confirmez votre configuration en exécutant les commandes show interfaces, 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.

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérification de BGP Route Learning

But

Assurez-vous que les stratégies d’exportation BGP fonctionnent comme prévu en consultant les tables de routage.

Action
Sens

Sur l’appareil R1, la show route protocol direct commande affiche deux itinéraires directs : 172.16.1.1/32 et 10.10.10.0/30. La show route protocol static commande affiche deux routes statiques : 192.168.0.1/32 et 192.168.20.1/32.

Sur le périphérique R2, la commande indique que le show route protocol bgp seul itinéraire que le périphérique R2 a appris via BGP est l’itinéraire 192.168.20.1/32.

Sur le périphérique R3, la commande indique que le show route protocol bgp seul itinéraire que le périphérique R3 a appris via BGP est l’itinéraire 192.168.0.1/32.

Sur le périphérique R4, la commande indique que les seules routes que le show route protocol bgp périphérique R4 a apprises via BGP sont les routes 172.16.1.1/32 et 10.10.10.0/30.

Vérification de la réception d’une route BGP

But

Assurez-vous que les stratégies d’exportation BGP fonctionnent comme prévu en vérifiant les routes BGP reçues de l’appareil R1.

Action
Sens

Sur le périphérique R2, la commande indique que le route receive-protocol bgp 172.16.1.1 périphérique R2 n’a reçu qu’une seule route BGP, 192.168.20.1/32, du périphérique R1.

Sur l’appareil R3, la commande route receive-protocol bgp 172.16.1.1 indique que l’appareil R3 n’a reçu qu’une seule route BGP, 192.168.0.1/32, de l’appareil R1.

Sur le périphérique R4, la commande indique que le route receive-protocol bgp 172.16.1.1 périphérique R4 a reçu deux routes BGP, 172.16.1.1/32 et 10.10.10.0/30, du périphérique R1.

En résumé, lorsque plusieurs politiques sont appliquées à différentes hiérarchies CLI dans BGP, seule l’application la plus spécifique est évaluée, à l’exclusion des autres applications de politiques moins spécifiques. Bien que ce point puisse sembler logique, il est facilement oublié lors de la configuration du routeur, lorsque vous croyez à tort qu’une stratégie de voisinage est combinée à une stratégie globale ou de groupe, pour constater que le comportement de votre stratégie n’est pas celui prévu.

Voir également

Exemple : Injection de routes OSPF dans la table de routage BGP

Cet exemple montre comment créer une stratégie qui injecte des routes OSPF dans la table de routage BGP.

Conditions préalables

Avant de commencer :

Présentation

Dans cet exemple, vous créez une stratégie de routage appelée injectpolicy1 et un terme de routage appelé injectterm1. La stratégie injecte des routes OSPF dans la table de routage BGP.

Topologie

Configuration

Configuration de la stratégie de routage

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, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la hiérarchie [modifier], puis passez commit en mode de configuration.

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 de configuration dans le Guide de l’utilisateur de l’interface de ligne de commande.

Pour injecter des routes OSPF dans une table de routage BGP :

  1. Créez le terme de la stratégie.

  2. Spécifiez OSPF comme condition de correspondance.

  3. Spécifiez les routes à partir d’une zone OSPF en tant que condition de correspondance.

  4. Spécifiez que l’itinéraire doit être accepté si les conditions précédentes sont remplies.

  5. Appliquez la stratégie de routage au BGP.

Résultats

Confirmez votre configuration en entrant les show policy-options commandes et show protocols bgp à partir du mode de configuration. 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é de configurer l’appareil, passez commit en mode de configuration.

Configuration du suivi pour la stratégie de routage

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, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la hiérarchie [modifier], puis passez commit en mode de configuration.

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 de configuration dans le Guide de l’utilisateur de l’interface de ligne de commande.

  1. Incluez une action de suivi dans la stratégie.

  2. Configurez le fichier de suivi pour la sortie.

Résultats

Confirmez votre configuration en entrant les show policy-options commandes et show routing-options à partir du mode de configuration. 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é de configurer l’appareil, passez commit en mode de configuration.

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérification de la présence des routes BGP attendues

But

Vérifiez l’effet de la stratégie d’exportation.

Action

À partir du mode opérationnel, entrez la show route commande.

Dépannage

Utilisation de la commande show log pour examiner les actions de la stratégie de routage

Problème

La table de routage contient des routes inattendues ou des routes sont manquantes dans la table de routage.

Solution

Si vous configurez le suivi de stratégie comme indiqué dans cet exemple, vous pouvez exécuter la commande pour diagnostiquer les problèmes liés à la show log ospf-bgp-policy-log stratégie de routage. La show log ospf-bgp-policy-log commande affiche des informations sur les routes que le terme de stratégie analyse et sur lesquelles il injectpolicy1 agit.

Configuration des stratégies de routage pour contrôler les annonces de routage BGP

Tous les protocoles de routage utilisent le Junos OS table de routage pour stocker les routes qu’ils apprennent et pour déterminer les routes qu’ils doivent annoncer dans leurs paquets de protocole. La stratégie de routage vous permet de contrôler les routes que les protocoles de routage stockent et récupèrent à partir de la table de routage. Pour plus d’informations sur la stratégie de routage, consultez le Guide de l’utilisateur Stratégies de routage, filtres de pare-feu et mécanismes de contrôle du trafic.

Lors de la configuration de la stratégie de routage BGP, vous pouvez effectuer les tâches suivantes :

Application d’une stratégie de routage

Vous définissez la stratégie de routage au niveau de la [edit policy-options] hiérarchie. Pour appliquer les stratégies que vous avez définies pour BGP, incluez les instructions import et export dans la configuration BGP.

Vous pouvez appliquer les stratégies comme suit :

  • BGP global import and export statements (Instructions et globales BGP ) : incluez ces instructions au niveau de la [edit protocols bgp] hiérarchie (pour les instances de routage, incluez-les au niveau de la [edit routing-instances routing-instance-name protocols bgp] hiérarchie).

  • Group and statements (Group import and export statements) : incluez ces instructions au niveau de la [edit protocols bgp group group-name] hiérarchie (pour les instances de routage, incluez-les au niveau de la [edit routing-instances routing-instance-name protocols bgp group group-name] hiérarchie).

  • Peer import and export statements (Homologue et instructions) : incluez ces instructions au niveau de la [edit protocols bgp group group-name neighbor address] hiérarchie (pour les instances de routage, incluez-les au niveau de la [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address] hiérarchie).

Un niveau homologue import ou export une instruction remplace un groupe import ou export une instruction. Un niveau homologue import ou export une instruction remplace un groupe import ou export une instruction.

Pour appliquer des stratégies, consultez les sections suivantes :

Application de stratégies aux routes importées dans la table de routage à partir de BGP

Pour appliquer une stratégie aux routes importées dans la table de routage à partir de BGP, incluez l’instruction import répertoriant les noms d’une ou plusieurs stratégies à évaluer :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

Si vous spécifiez plusieurs stratégies, elles sont évaluées dans l’ordre spécifié, de la première à la dernière, et le premier filtre correspondant est appliqué à l’itinéraire. Si aucune correspondance n’est trouvée, BGP place dans la table de routage uniquement les routes qui ont été apprises à partir de périphériques de routage BGP.

Application de stratégies aux routes exportées de la table de routage vers BGP

Pour appliquer une stratégie aux routes exportées de la table de routage vers BGP, incluez l’instruction répertoriant les noms d’une export ou de plusieurs stratégies à évaluer :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

Si vous spécifiez plusieurs stratégies, elles sont évaluées dans l’ordre spécifié, de la première à la dernière, et le premier filtre correspondant est appliqué à l’itinéraire. Si aucune route ne correspond aux filtres, la table de routage exporte dans BGP uniquement les routes qu’elle a apprises de BGP.

Définition de BGP pour annoncer les routes inactives

Par défaut, BGP stocke les informations de route qu’il reçoit des messages de mise à jour dans le Junos OS table de routage, et le table de routage exporte uniquement les routes actives dans BGP, que BGP publie ensuite à ses homologues. Pour que la table de routage exporte vers BGP le meilleur itinéraire appris par BGP, même si Junos OS ne l’a pas sélectionné comme route active, incluez l’instruction advertise-inactive suivante :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

Configuration de BGP pour annoncer le meilleur itinéraire externe à ses homologues internes

En général, les implémentations BGP déployées n’annoncent pas la route externe avec la valeur de préférence locale la plus élevée aux homologues internes, sauf s’il s’agit de la meilleure route. Bien que ce comportement ait été exigé par une version antérieure de la spécification BGP version 4, RFC 1771, il n’était généralement pas suivi afin de minimiser la quantité d’informations annoncées et d’éviter les boucles de routage. Cependant, il existe des scénarios dans lesquels la publicité de la meilleure route externe est bénéfique, en particulier les situations qui peuvent entraîner une oscillation de la route IBGP.

Dans Junos OS version 9.3 et ultérieure, vous pouvez configurer BGP pour annoncer la meilleure route externe dans un groupe de maillage BGP interne (IBGP), un cluster de réflecteurs de route ou une confédération de systèmes autonomes (AS), même si la meilleure route est une route interne.

REMARQUE :

Pour configurer l’instruction advertise-external sur un réflecteur de route, vous devez désactiver la réflexion intracluster avec l’instruction no-client-reflect.

Lorsqu’un périphérique de routage est configuré en tant que réflecteur de route pour un cluster, une route annoncée par le réflecteur de route est considérée comme interne si elle provient d’un homologue interne avec le même identificateur de cluster ou si les deux homologues n’ont pas configuré d’identificateur de cluster. Une route reçue d’un homologue interne qui appartient à un autre cluster, c’est-à-dire avec un identificateur de cluster différent, est considérée comme externe.

Dans une confédération, lors de la publication d’un itinéraire vers un routeur de bordure de confédération, tout itinéraire provenant d’un autre sous-AS de confédération est considéré comme externe.

Vous pouvez également configurer BGP pour qu’il publie la route externe uniquement si le processus de sélection de route atteint le point où la métrique MED (multiple exit discriminateator) est évaluée. Par conséquent, une route externe avec un chemin AS moins bon (c’est-à-dire plus long) que celui du chemin actif n’est pas annoncée.

Junos OS prend également en charge la configuration d’une stratégie d’exportation BGP qui correspond à l’état d’un itinéraire annoncé. Vous pouvez faire correspondre sur des itinéraires actifs ou inactifs. Pour plus d’informations, consultez le Guide de l’utilisateur des stratégies de routage, des filtres de pare-feu et des mécanismes de contrôle du trafic.

Pour configurer BGP afin d’annoncer le meilleur chemin d’accès externe à des homologues internes, incluez l’instruction advertise-external suivante :

REMARQUE :

L’instruction advertise-external est prise en charge à la fois au niveau du groupe et du voisinage. Si vous configurez l’instruction au niveau du voisin, vous devez la configurer pour tous les voisins d’un groupe. Dans le cas contraire, le groupe est automatiquement scindé en différents groupes.

Pour obtenir la liste complète des niveaux hiérarchiques auxquels vous pouvez configurer cette instruction, reportez-vous à la section Récapitulatif de cette instruction.

Pour configurer BGP afin d’annoncer le meilleur chemin externe uniquement si le processus de sélection de route atteint le point d’évaluation de la valeur MED, incluez l’instruction conditional suivante :

Configuration de la fréquence à laquelle BGP échange des routes avec la table de routage

BGP stocke les informations de route qu’il reçoit des messages de mise à jour dans la table de routage, et la table de routage exporte les routes actives de la table de routage vers BGP. BGP annonce ensuite les routes exportées à ses homologues. Par défaut, l’échange d’informations de route entre BGP et la table de routage a lieu immédiatement après la réception des routes. Cet échange immédiat d’informations de routage peut entraîner des instabilités dans les informations d’accessibilité du réseau. Pour vous prémunir contre cela, vous pouvez retarder le délai entre le moment où BGP et la table de routage échangent des informations de route.

Pour configurer la fréquence à laquelle BGP et la table de routage échangent des informations de route, incluez l’instruction out-delay suivante :

Par défaut, la table de routage conserve certaines des informations de routage apprises de BGP. Pour que la table de routage conserve tout ou rien de ces informations, incluez l’instruction keep suivante :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure ces instructions, reportez-vous aux sections de résumé des instructions pour ces instructions.

La table de routage peut conserver les informations de route apprises de BGP de l’une des manières suivantes :

  • Par défaut (omettre l’instruction) : conserve toutes les informations de route apprises à partir de BGP, à l’exception des routes dont le chemin AS est en boucle et dont la boucle inclut l’AS keep local.

  • keep all—Conserve toutes les informations de route apprises de BGP.

  • keep none—Ignorer les routes qui ont été reçues d’un homologue et qui ont été rejetées par une stratégie d’importation ou d’autres vérifications d’intégrité, telles que le chemin d’accès AS ou le saut suivant. Lorsque vous configurez keep none la session BGP et que la stratégie entrante est modifiée, Junos OS force la nouvelle publication de l’ensemble complet des routes annoncées par l’homologue.

Dans une situation de guérison de chemin AS, les routes avec des chemins en boucle peuvent théoriquement devenir utilisables lors d’une reconfiguration logicielle lorsque la limite de boucle de chemin AS est modifiée. Cependant, il existe une différence significative d’utilisation de la mémoire entre la valeur par défaut et keep all.

Envisagez les scénarios suivants :

  • Un pair relance les itinéraires vers son homologue auprès duquel il les a appris.

    Cela peut se produire dans les cas suivants :

    • Le périphérique de routage d’un autre fournisseur annonce les routes à l’homologue d’envoi.

    • Le comportement par défaut de l’homologue Junos OS, qui consiste à ne pas réannoncer les chemins vers l’homologue d’envoi, est remplacé en configurant advertise-peer-as.

  • Un périphérique de routage Provider Edge (PE) rejette toute route VPN qui n’a aucune des cibles de route attendues.

Lorsque keep all cette option est configurée, le comportement des routes de rejet reçues dans les scénarios ci-dessus est remplacé.

Désactivation de la suppression des annonces d’itinéraire

Junos OS n’annonce pas les routes apprises d’un pair EBGP vers le même homologue BGP externe (EBGP). De plus, le logiciel n’annonce pas ces routes à des homologues EBGP qui se trouvent dans le même AS que l’homologue d’origine, quelle que soit l’instance de routage. Vous pouvez modifier ce comportement en incluant l’instruction advertise-peer-as dans la configuration. Pour désactiver la suppression de la publication par défaut, incluez l’instruction advertise-peer-as suivante :

REMARQUE :

Le comportement par défaut de la suppression de route est désactivé si l’instruction as-override est incluse dans la configuration.

Si vous incluez l’instruction advertise-peer-as dans la configuration, BGP annonce le routage indépendamment de cette vérification.

Pour restaurer le comportement par défaut, incluez l’instruction no-advertise-peer-as dans la configuration :

Si vous incluez à la fois les instructions as-override et no-advertise-peer-as dans la configuration, l’instruction no-advertise-peer-as est ignorée. Vous pouvez inclure ces instructions à plusieurs niveaux hiérarchiques.

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure ces instructions, reportez-vous à la section Résumé des instructions pour ces instructions.

Voir également

Exemple : Configuration d’une stratégie de routage pour annoncer le meilleur itinéraire externe à des homologues internes

La spécification du protocole BGP, telle que définie dans la RFC 1771, spécifie qu’un pair BGP doit annoncer à ses homologues internes le chemin externe de préférence la plus élevée, même si ce chemin n’est pas le meilleur globalement (en d’autres termes, même si le meilleur chemin est un chemin interne). En pratique, les implémentations BGP déployées ne respectent pas cette règle. Les raisons de s’écarter de la spécification sont les suivantes :

  • Minimiser la quantité d’informations annoncées. BGP s’adapte en fonction du nombre de chemins disponibles.

  • Éviter les boucles de routage et de transfert.

Il existe cependant plusieurs scénarios dans lesquels le comportement, spécifié dans la RFC 1771, consistant à annoncer la meilleure route externe pourrait être bénéfique. Il n’est pas toujours souhaitable de limiter les informations sur les chemins, car la diversité des chemins peut contribuer à réduire les temps de restauration. La publicité du meilleur chemin externe peut également résoudre les problèmes internes d’oscillation de route BGP (IBGP), comme décrit dans la RFC 3345, Border Gateway Protocol (BGP) Persistent Route Oscillation Condition.

L’instruction advertise-external modifie le comportement d’un interlocuteur BGP pour annoncer le meilleur chemin externe aux homologues IBGP, même lorsque le meilleur chemin global est un chemin interne.

REMARQUE :

L’instruction advertise-external est prise en charge à la fois au niveau du groupe et du voisinage. Si vous configurez l’instruction au niveau du voisin, vous devez la configurer pour tous les voisins d’un groupe. Dans le cas contraire, le groupe est automatiquement scindé en différents groupes.

L’option conditional limite le comportement du paramètre, de sorte que l’itinéraire externe n’est annoncé que si le processus de advertise-external sélection d’itinéraire atteint le point où la métrique MED (multiple exit discriminateator) est évaluée. Ainsi, une route externe n’est pas annoncée si elle possède, par exemple, un chemin AS moins bon (plus long) que celui du chemin actif. L’option conditional limite l’annonce de chemin externe au moment où le meilleur chemin externe et le chemin actif sont égaux jusqu’à l’étape MED du processus de sélection de route. Notez que les critères utilisés pour sélectionner le meilleur chemin externe sont les mêmes, que l’option conditional soit configurée ou non.

Junos OS prend également en charge la configuration d’une stratégie d’exportation BGP correspondant à l’état d’une route annoncée. Vous pouvez faire correspondre des itinéraires actifs ou inactifs, comme suit :

Ce qualificatif ne correspond que lorsqu’il est utilisé dans le cadre d’une stratégie d’exportation. Lorsqu’une route est annoncée par un protocole qui peut annoncer des routes inactives (tel que BGP), state inactive correspond aux routes annoncées à la suite des advertise-inactive instructions and advertise-external .

Par exemple, la configuration suivante peut être utilisée comme stratégie d’exportation BGP vers des homologues internes pour marquer les itinéraires annoncés en raison du paramètre avec une communauté définie par l’utilisateur advertise-external . Cette communauté peut être utilisée ultérieurement par les routeurs de réception pour filtrer ces routes de la table de transfert. Un tel mécanisme peut être utilisé pour répondre aux préoccupations selon lesquelles les chemins publicitaires non utilisés pour le transfert par l’expéditeur pourraient conduire à des boucles de transfert.

Conditions préalables

Junos OS 9.3 ou version ultérieure est requis.

Présentation

Cet exemple montre trois périphériques de routage. L’appareil R2 dispose d’une connexion BGP externe (EBGP) à l’appareil R1. L’appareil R2 dispose d’une connexion IBGP à l’appareil R3.

L’appareil R1 annonce 172.16.6.0/24. Le périphérique R2 ne définit pas la préférence locale dans une stratégie d’importation pour les routes du périphérique R1, et donc 172.16.6.0/24 a la préférence locale par défaut de 100.

L’appareil R3 annonce 172.16.6.0/24 avec une préférence locale de 200.

Lorsque l’instruction n’est pas configurée sur le périphérique R2, 172.16.6.0/24 n’est pas annoncé par le périphérique R2 vers le advertise-external périphérique R3.

Lorsque l’instruction est configurée sur le advertise-external périphérique R2 sur la session vers le périphérique R3, 172.16.6.0/24 est annoncé par le périphérique R2 vers le périphérique R3.

Lorsqu’il advertise-external conditional est configuré sur l’appareil R2 sur la session vers l’appareil R3, 172.16.6.0/24 n’est pas annoncé par l’appareil R2 vers l’appareil R3. Si vous supprimez le then local-preference 200 paramètre sur l’appareil R3 et ajoutez le path-selection as-path-ignore paramètre sur l’appareil R2 (ce qui rend les critères de sélection du chemin égaux jusqu’à l’étape MED du processus de sélection de l’itinéraire), 172.16.6.0/24 est annoncé par l’appareil R2 vers l’équipement R3.

REMARQUE :

Pour configurer advertise-external l’instruction sur un réflecteur de route, vous devez désactiver la réflexion intracluster avec no-client-reflect l’instruction, et le cluster client doit être entièrement maillé pour empêcher l’envoi d’annonces de route redondantes.

Lorsqu’un périphérique de routage est configuré en tant que réflecteur de route pour un cluster, une route annoncée par le réflecteur de route est considérée comme interne si elle provient d’un homologue interne avec le même identificateur de cluster ou si les deux homologues n’ont pas configuré d’identificateur de cluster. Une route reçue d’un homologue interne qui appartient à un autre cluster, c’est-à-dire avec un identificateur de cluster différent, est considérée comme externe.

Topologie

Figure 2 montre l’exemple de réseau.

Figure 2 : Topologie BGP pour publicité externeTopologie BGP pour publicité externe

Configuration rapide de l’interface de ligne de commande affiche la configuration de tous les périphériques dans Figure 2.

Cette section #d102e166__d102e344 décrit les étapes à suivre sur l’appareil R2.

Configuration

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 R1

Appareil R2

Appareil R3

Procédure

Procédure étape par étape

L’exemple suivant nécessite que vous naviguiez à 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 :

  1. Configurez les interfaces de l’appareil.

  2. Configurez OSPF ou un autre protocole IGP (Interior Gateway Protocol).

  3. Configurez la connexion EBGP à l’appareil R1.

  4. Configurez la connexion IBGP à l’appareil R3.

  5. Ajoutez l’instruction advertise-external à la session d’appairage de groupe IBGP.

  6. Configurez le numéro du système autonome (AS) et l’ID du routeur.

Résultats

À partir du mode de configuration, confirmez votre configuration en saisissant les commandes show interfaces, 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.

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 du chemin BGP actif

But

Sur l’appareil R2, assurez-vous que le préfixe 172.16.6.0/24 figure dans la table de routage et qu’il possède le chemin d’accès actif attendu.

Action
Sens

L’équipement R2 reçoit l’itinéraire 172.16.6.0/24 de l’équipement R1 et de l’équipement R3. L’itinéraire à partir de l’appareil R3 est le chemin actif, tel que désigné par l’astérisque (*). Le chemin actif a la préférence locale la plus élevée. Même si les préférences locales des deux routes étaient égales, la route de l’appareil R3 resterait active car elle a le chemin AS le plus court.

Vérification de l’annonce d’itinéraire externe

But

Sur l’appareil R2, assurez-vous que l’itinéraire 172.16.6.0/24 est annoncé vers l’appareil R3.

Action
Sens

L’appareil R2 annonce l’itinéraire 172.16.6.0/24 vers l’appareil R3.

Vérification de l’itinéraire sur l’appareil R3

But

Assurez-vous que le préfixe 172.16.6.0/24 se trouve dans la table de routage du périphérique R3.

Action
Sens

L’équipement R3 dispose de la route statique et de la route BGP pour 172.16.6.0/24.

Notez que la route BGP est masquée sur l’appareil R3 si la route n’est pas accessible ou si le saut suivant ne peut pas être résolu. Pour répondre à cette exigence, cet exemple inclut une route statique par défaut sur l’appareil R3 (static route 0.0.0.0/0 next-hop 10.0.0.5).

Expérimentation de l’option conditionnelle

But

Découvrez comment cette conditional option fonctionne dans le contexte de l’algorithme de sélection de chemin BGP.

Action

  1. Sur l’appareil R2, ajoutez l’option conditional .

  2. Sur l’appareil R2, vérifiez si l’itinéraire 172.16.6.0/24 est annoncé vers l’appareil R3.

    Comme prévu, l’itinéraire n’est plus annoncé. Vous devrez peut-être attendre quelques secondes pour voir ce résultat.

  3. Sur l’appareil R3, désactivez l’action de then local-preference stratégie.

  4. Sur l’appareil R2, assurez-vous que les préférences locales des deux chemins sont égales.

  5. Sur l’appareil R2, ajoutez l’instruction as-path-ignore .

  6. Sur l’appareil R2, vérifiez si l’itinéraire 172.16.6.0/24 est annoncé vers l’appareil R3.

    Comme prévu, l’itinéraire est maintenant annoncé car la longueur du chemin AS est ignorée et parce que les préférences locales sont égales.

Voir également

Exemple : Configuration du filtrage des routes sortantes basé sur des préfixes BGP

Cet exemple montre comment configurer un routeur Juniper Networks pour accepter les filtres de route d’homologues distants et effectuer un filtrage de route sortant à l’aide des filtres reçus.

Conditions préalables

Avant de commencer :

  • Configurez les interfaces des routeurs.

  • Configurez un protocole IGP (Interior Gateway Protocol).

Présentation

Vous pouvez configurer un pair BGP pour accepter les filtres de route des homologues distants et effectuer un filtrage de route sortant à l’aide des filtres reçus. En filtrant les mises à jour indésirables, l’homologue émetteur économise les ressources nécessaires à la génération et à la transmission des mises à jour, tandis que l’homologue destinataire économise les ressources nécessaires au traitement des mises à jour. Cette fonctionnalité peut s’avérer utile, par exemple, dans un réseau privé virtuel (VPN) dans lequel des sous-ensembles d’appareils CE (Customer Edge) ne sont pas capables de traiter tous les itinéraires du VPN. Les appareils CE peuvent utiliser le filtrage des routes sortantes basé sur des préfixes pour communiquer avec l’équipement de routage PE (Provider Edge) afin de transmettre uniquement un sous-ensemble de routes, par exemple des routes vers les centres de données principaux uniquement.

Le nombre maximal de filtres de route sortante basés sur des préfixes qu’un pair BGP peut accepter est de 5000. Si un homologue distant envoie plus de 5 000 filtres de route sortants à une adresse homologue, les filtres supplémentaires sont ignorés et un message de journal système est généré.

Vous pouvez configurer l’interopérabilité pour le périphérique de routage dans son ensemble ou pour des groupes ou des homologues BGP spécifiques uniquement.

Topologie

Dans l’exemple de réseau, l’appareil CE1 est un routeur d’un autre fournisseur. La configuration présentée dans cet exemple est sur le routeur PE1 de Juniper Networks.

Figure 3 montre l’exemple de réseau.

Figure 3 : Filtrage des routes sortantes basé sur des préfixes BGPFiltrage des routes sortantes basé sur des préfixes BGP

Configuration

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.

PE1

Procédure

Procédure étape par étape

L’exemple suivant nécessite que vous naviguiez à 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 le routeur PE1 afin qu’il accepte les filtres de route de l’appareil CE1 et effectue un filtrage de route sortant à l’aide des filtres reçus :

  1. Configurez le système autonome local.

  2. Configurez l’appairage externe avec l’appareil CE1.

  3. Configurez le routeur PE1 pour qu’il accepte les filtres de route IPv4 de l’appareil CE1 et effectue le filtrage des routes sortantes à l’aide des filtres reçus.

  4. (Facultatif) Activez l’interopérabilité avec les équipements de routage qui utilisent le code de compatibilité spécifique au fournisseur 130 pour les filtres de route sortante et le type de code 128.

    Le code standard IANA est 3 et le type de code standard est 64.

Résultats

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

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 du filtre d’itinéraire sortant

But

Affichez des informations sur le filtre de route sortant basé sur un préfixe reçu de l’appareil CE1.

Action

À partir du mode opérationnel, entrez la show bgp neighbor orf detail commande.

Vérification du mode voisin BGP

But

Vérifiez que le bgp-orf-cisco-mode paramètre est activé pour l’homologue en vous assurant que l’option s’affiche ORFCiscoMode dans la sortie de la show bgp neighbor commande.

Action

À partir du mode opérationnel, entrez la show bgp neighbor commande.

Voir également

Présentation de la stratégie de routage BGP par défaut sur les routeurs de transport de paquets (PTX Series)

Sur PTX Series Routeurs de transport de paquets, le stratégie de routage BGP par défaut diffère de celui des autres périphériques de routage Junos OS.

Les routeurs PTX Series sont des plates-formes de transit MPLS qui effectuent un transfert IP, généralement à l’aide de routes IGP (Interior Gateway Protocol). Le PTX Series moteur de transfert de paquets peut accueillir un nombre relativement restreint de préfixes de longueur variable.

REMARQUE :

Un routeur PTX Series peut prendre en charge des routes BGP complètes dans le plan de contrôle afin de pouvoir l’utiliser comme réflecteur de route (RR). Il peut effectuer un transfert multicast de longueur exacte et peut construire le plan de transfert multicast à utiliser par le plan de contrôle unicast (par exemple, pour effectuer une recherche de transfert de chemin inverse pour multicast).

Compte tenu de la limitation PFE, la stratégie de routage par défaut pour les routeurs PTX Series consiste à ne pas installer de routes BGP dans la table de transfert. Vous pouvez remplacer la stratégie de routage par défaut et sélectionner certaines routes BGP à installer dans la table de transfert.

Le comportement par défaut de l’équilibrage de charge et des routes BGP sur les routeurs PTX Series est le suivant. Il présente les caractéristiques souhaitables suivantes :

  • Vous permet de remplacer le comportement par défaut sans avoir à modifier directement la stratégie par défaut

  • Réduit le risque de modifications accidentelles qui annulent les valeurs par défaut

  • Aucune action de contrôle de flux ne définit, telle que l’acceptation et le rejet

La stratégie de routage par défaut sur les routeurs PTX Series est la suivante :

Comme illustré ici, la junos-ptx-series-default stratégie est définie dans [edit policy-options]. La stratégie est appliquée dans , à [edit routing-options forwarding-table]l’aide de l’instruction default-export . Vous pouvez afficher ces configurations par défaut à l’aide de l’indicateur | display inheritance .

Vous pouvez également utiliser la commande pour afficher la show policy stratégie par défaut.

ATTENTION :

Nous vous recommandons vivement de ne pas modifier directement la junos-ptx-series-default stratégie de routage.

Junos OS chaîne la stratégie et toute stratégie d’exportation configurée par l’utilisateur junos-ptx-series-default . Étant donné que la stratégie n’utilise pas d’actions de contrôle de flux, toute stratégie d’exportation que vous configurez est exécutée (par le biais de l’action junos-ptx-series-default implicite next-policy) pour chaque route. Ainsi, vous pouvez remplacer toutes les actions définies par la junos-ptx-series-default stratégie. Si vous ne configurez pas de stratégie d’exportation, les actions définies par junos-ptx-series-default la stratégie sont les seules actions.

Vous pouvez utiliser l’action de stratégie install-to-fib pour remplacer l’action no-install-to-fib .

De même, vous pouvez définir l’action load-balance per-prefix pour qu’elle remplace l’action load-balance per-packet .

Voir également

Exemple : Remplacement de la stratégie de routage BGP par défaut sur PTX Series Routeurs de transport de paquets

Cet exemple montre comment remplacer le stratégie de routage par défaut sur les routeurs de transport de paquets, tels que le PTX Series Routeurs de transport de paquets.

Conditions préalables

Cet exemple nécessite Junos OS version 12.1 ou ultérieure.

Présentation

Par défaut, les routeurs PTX Series n’installent pas de routes BGP dans la table de transfert.

Pour les routeurs PTX Series, la configuration de la from protocols bgp condition avec l’action then accept n’a pas le résultat habituel qu’elle a sur les autres périphériques de routage Junos OS. Avec la stratégie de routage suivante sur les routeurs PTX Series, les routes BGP ne sont pas installées dans la table de transfert.

Aucune route BGP n’est installée dans la table de transfert. Il s’agit du comportement attendu.

Cet exemple montre comment utiliser l’action then install-to-fib pour remplacer efficacement la stratégie de routage BGP par défaut.

Configuration

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.

Installation des routes BGP sélectionnées dans la table de transfert

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 installer les routes BGP sélectionnées dans la table de transfert :

  1. Configurez une liste de préfixes à installer dans la table de transfert.

  2. Configurez la stratégie de routage en appliquant la liste de préfixes comme condition.

  3. Appliquez la stratégie de routage à la table de transfert.

Résultats

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

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’installation de l’itinéraire sélectionné dans la table de transfert

But

Assurez-vous que la stratégie configurée remplace la stratégie par défaut.

Action

À partir du mode opérationnel, entrez la show route forwarding-table commande.

Sens

Cette sortie montre que la route vers 66.0.0.1/32 est installée dans la table de transfert.

Voir également

Publication conditionnelle Activation de l’installation conditionnelle de préfixes Cas d’utilisation

Les réseaux sont généralement subdivisés en unités plus petites et plus faciles à gérer, appelées systèmes autonomes (AS). Lorsque BGP est utilisé par les routeurs pour établir des relations d’homologue dans le même AS, on parle de BGP interne (IBGP). Lorsque BGP est utilisé par les routeurs pour établir des relations d’homologue dans différents AS, on parle de BGP externe (EBGP).

Après avoir effectué les vérifications d’intégrité de route, un routeur BGP accepte les routes reçues de ses homologues et les installe dans la table de routage. Par défaut, tous les routeurs des sessions IBGP et EBGP suivent les règles de publication BGP standard. Alors qu’un routeur dans une session IBGP annonce uniquement les routes apprises de ses homologues directs, un routeur dans une session EBGP annonce toutes les routes apprises de ses homologues directs et indirects (pairs de pairs). Par conséquent, dans un réseau classique configuré avec EBGP, un routeur ajoute toutes les routes reçues d’un pair EBGP dans sa table de routage et annonce presque toutes les routes à tous les homologues EBGP.

Un fournisseur de services qui échange des routes BGP avec des clients et des pairs sur Internet est exposé au risque de faire face à des menaces malveillantes et involontaires pouvant compromettre le bon routage du trafic, ainsi que le fonctionnement des routeurs.

Cela présente plusieurs inconvénients :

  • Non-aggregated route advertisementsUn client pourrait annoncer par erreur tous ses préfixes au FAI plutôt qu’un agrégat de son espace d’adressage. Compte tenu de la taille de la table de routage Internet, cela doit être soigneusement contrôlé. Un routeur de périphérie peut également n’avoir besoin que d’une route par défaut vers Internet et recevoir à la place l’intégralité de la table de routage BGP de son homologue en amont.

  • BGP route manipulationSi un administrateur malveillant modifie le contenu de la table de routage BGP, il peut empêcher le trafic d’atteindre sa destination prévue.

  • BGP route hijacking—Un administrateur malveillant d’un pair BGP pourrait annoncer de manière malveillante les préfixes d’un réseau dans le but de réacheminer le trafic destiné au réseau victime vers le réseau de l’administrateur afin d’accéder au contenu du trafic ou de bloquer les services en ligne de la victime.

  • BGP denial of service (DoS): si un administrateur malveillant envoie du trafic BGP inattendu ou indésirable à un routeur dans le but d’utiliser toutes les ressources BGP disponibles du routeur, cela peut nuire à la capacité du routeur à traiter les informations de routage BGP valides.

L’installation conditionnelle de préfixes peut être utilisée pour résoudre tous les problèmes mentionnés précédemment. Si un client a besoin d’accéder à des réseaux distants, il est possible d’installer une route spécifique dans la table de routage du routeur connecté au réseau distant. Cela ne se produit pas dans un réseau EBGP typique et, par conséquent, l’installation conditionnelle des préfixes devient essentielle.

Les AS ne sont pas seulement liés par des relations physiques, mais aussi par des relations d’affaires ou d’autres relations organisationnelles. Un AS peut fournir des services à une autre organisation, ou agir comme un AS de transit entre deux autres AS. Ces AS de transit sont liés par des accords contractuels entre les parties qui incluent des paramètres sur la façon de se connecter les uns aux autres et, surtout, le type et la quantité de trafic qu’ils transportent les uns pour les autres. Par conséquent, pour des raisons juridiques et financières, les fournisseurs de services doivent implémenter des stratégies qui contrôlent la façon dont les routes BGP sont échangées avec les voisins, celles qui sont acceptées par ces voisins et la manière dont ces routes affectent le trafic entre les AS.

Il existe de nombreuses options différentes pour filtrer les routes reçues d’un pair BGP homologue afin d’appliquer des stratégies inter-OS et d’atténuer les risques de réception de routes potentiellement dangereuses. Le filtrage de route conventionnel examine les attributs d’une route et accepte ou rejette la route en fonction de ces attributs. Une stratégie ou un filtre peut examiner le contenu de l’AS-Path, la valeur du tronçon suivant, une valeur de communauté, une liste de préfixes, la famille d’adresses de l’itinéraire, etc.

Dans certains cas, la « condition d’acceptation » standard consistant à faire correspondre une valeur d’attribut particulière n’est pas suffisante. Le fournisseur de services peut avoir besoin d’utiliser une autre condition en dehors de l’itinéraire lui-même, par exemple, un autre itinéraire dans la table de routage. À titre d’exemple, il peut être souhaitable d’installer une route par défaut reçue d’un homologue en amont, uniquement s’il peut être vérifié que cet homologue a une accessibilité à d’autres réseaux plus en amont. Cette installation de route conditionnelle évite d’installer une route par défaut qui est utilisée pour envoyer du trafic vers cet homologue, lorsque celui-ci peut avoir perdu ses routes en amont, ce qui entraîne un trafic bloqué. Pour ce faire, le routeur peut être configuré pour rechercher la présence d’un itinéraire particulier dans la table de routage et, en fonction de ces connaissances, accepter ou rejeter un autre préfixe.

Exemple : La configuration d’une stratégie de routage pour la publication conditionnelle L’activation de l’installation conditionnelle des préfixes dans une table de routage explique comment l’installation conditionnelle des préfixes peut être configurée et vérifiée.

Voir également

Publication conditionnelle et stratégie d’importation (table de routage) avec certaines conditions de correspondance

BGP accepte toutes les routes non bouclées apprises des voisins et les importe dans la table RIB-In. Si ces routes sont acceptées par la stratégie d’importation BGP, elles sont ensuite importées dans la table de routage inet.0. Dans les cas où seuls certains itinéraires doivent être importés, des dispositions peuvent être prises pour que le périphérique de routage homologue exporte les itinéraires en fonction d’une condition ou d’un ensemble de conditions.

La condition d’exportation d’un itinéraire peut être basée sur :

  • L’homologue à partir duquel l’itinéraire a été appris

  • L’interface sur laquelle l’itinéraire a été appris

  • Un autre attribut obligatoire

Par exemple :

C’est ce qu’on appelle l’installation conditionnelle de préfixes et est décrite dans Exemple : Configuration d’une stratégie de routage pour la publication conditionnelle permettant l’installation conditionnelle de préfixes dans une table de routage.

Les conditions des stratégies de routage peuvent être configurées, qu’elles fassent partie des stratégies d’exportation ou d’importation, ou des deux. La stratégie d’exportation prend en charge ces conditions héritées de la stratégie de routage en fonction de l’existence d’un autre itinéraire dans la stratégie de routage. Toutefois, la stratégie d’importation ne prend pas en charge ces conditions , et les conditions ne sont pas exécutées même si elles sont présentes.

Figure 4 illustre où les stratégies d’importation et d’exportation BGP sont appliquées. Une stratégie d’importation est appliquée aux itinéraires entrants visibles dans la sortie de la show route receive-protocol bgp neighbor-address commande. Une stratégie d’exportation est appliquée aux itinéraires sortants visibles dans la sortie de la show route advertising-protocol bgp neighbor-address commande.

Figure 4 : Stratégies d’importation et d’exportation BGPStratégies d’importation et d’exportation BGP

Pour activer l’installation conditionnelle des préfixes, une stratégie d’exportation doit être configurée sur l’appareil sur lequel l’exportation des préfixes doit avoir lieu. La stratégie d’exportation évalue chaque itinéraire pour vérifier qu’il répond à toutes les conditions de correspondance de l’instruction from . Il recherche également l’existence de la route définie sous l’instruction condition (également configurée sous l’instruction from ).

Si la route ne correspond pas à l’ensemble des conditions requises définies dans la stratégie ou si la route définie sous l’instruction condition n’existe pas dans la table de routage, elle n’est pas exportée vers ses homologues BGP. Ainsi, une stratégie d’exportation conditionnelle correspond aux routes de l’itinéraire ou du préfixe souhaité que vous souhaitez installer dans la table de routage des homologues.

Pour configurer l’installation conditionnelle des préfixes à l’aide d’une stratégie d’exportation :

  1. Créez une condition instruction pour vérifier les préfixes.

  2. Créez une stratégie d’exportation avec la condition que vous venez de créer à l’aide de l’instruction condition .

  3. Appliquez la stratégie d’exportation à l’appareil qui nécessite uniquement l’exportation des préfixes sélectionnés à partir de la table de routage.

Voir également

Exemple : Configuration d’une stratégie de routage pour la publication conditionnelle Activation de l’installation conditionnelle de préfixes dans une table de routage

Cet exemple montre comment configurer l’installation conditionnelle de préfixes dans une table de routage à l’aide de la stratégie d’exportation BGP.

Conditions préalables

Cet exemple utilise les composants matériels et logiciels suivants :

  • M Series routeurs de périphérie multiservice, MX Series Plates-formes de routage universelles 5G ou routeurs centraux T Series

  • Junos OS version 9.0 ou ultérieure

Présentation

Dans cet exemple, trois routeurs de trois systèmes autonomes (AS) différents sont connectés et configurés avec le protocole BGP. Le routeur étiqueté Internet, qui est le routeur en amont, a cinq adresses configurées sur son interface de bouclage lo0.0 (172.16.11.1/32, 172.16.12.1/32, 172.16.13.1/32, 172.16.14.1/32 et 172.16.15.1/32), et une adresse de bouclage supplémentaire (192.168.9.1/32) est configurée comme ID de routeur. Ces six adresses sont exportées dans BGP pour émuler le contenu d’une table de routage BGP d’un routeur connecté à Internet et annoncé sur North.

Les routeurs Nord et Sud utilisent respectivement les réseaux 10.0.89.12/30 et 10.0.78.12/30, et utilisent respectivement 192.168.7.1 et 192.168.8.1 pour leurs adresses de bouclage respectives.

Figure 5 Affiche la topologie utilisée dans cet exemple.

Figure 5 : Installation conditionnelle des préfixesInstallation conditionnelle des préfixes

Le routeur Nord exporte les routes BGP 172.16.0.0/16 qu’il apprend du routeur Internet vers le routeur Sud. Ces routes peuvent représenter les routes appartenant au domaine du routeur Internet. En outre, lorsque la route spécifique 172.16.11.1/32 est présente, Router North annonce également une route par défaut. L’itinéraire 172.16.11.1 peut représenter le lien du routeur Internet vers un fournisseur d’appairage de transit de niveau 1 qui fournit une connectivité Internet complète.

Le routeur Sud reçoit les six routes, mais ne doit installer que la route par défaut et une autre route spécifique (172.16.11.1/32) dans sa table de routage.

Pour résumer, l’exemple répond aux exigences suivantes :

  • Sur North, envoyez tous les préfixes 172.16/16. En outre, envoyez également 0/0 à South uniquement si une route particulière est présente dans la table de routage inet.0 (dans cet exemple 172.16.11.1/32).

  • Sur South, acceptez et installez la route par défaut et la route 172.16.11.1/32 dans les tables de routage et de transfert. Abandonnez tous les autres itinéraires. Considérez que South peut être un périphérique bas de gamme qui ne peut pas accepter une table de routage Internet complète. Par conséquent, l’opérateur souhaite que South n’ait que la route par défaut et un autre préfixe spécifique.

La première exigence est satisfaite par une politique d’exportation sur le Nord :

La logique de la politique d’exportation conditionnelle peut être résumée comme suit : Si 0/0 est présent, et si 172.16.11.1/32 est présent, envoyez le préfixe 0/0. Cela implique que si 172.16.11.1/32 n’est pas présent, alors n’envoyez pas 0/0.

La deuxième condition est satisfaite par une politique d’importation sur le Sud :

Dans cet exemple, quatre routes sont supprimées à la suite de la politique d’importation sur le Sud. Cela s’explique par le fait que la politique d’exportation sur le Nord divulgue toutes les routes reçues d’Internet, et que la politique d’importation sur le Sud exclut certaines de ces routes.

Il est important de comprendre que sous Junos OS, bien qu’une stratégie d’importation (filtre de route entrante) puisse rejeter une route, ne pas l’utiliser pour le transfert de trafic et ne pas l’inclure dans une annonce à d’autres homologues, le routeur conserve ces routes en tant que routes masquées. Ces routes masquées ne sont pas disponibles à des fins de stratégie ou de routage. Cependant, ils occupent de l’espace mémoire sur le routeur. Un fournisseur de services qui filtre les routes pour contrôler la quantité d’informations conservées en mémoire et traitées par un routeur peut souhaiter que le routeur abandonne complètement les routes rejetées par la stratégie d’importation.

Les routes cachées peuvent être visualisées à l’aide de la show route receive-protocol bgp neighbor-address hidden commande. Les routes masquées peuvent ensuite être conservées ou supprimées de la table de routage en configurant l’instruction keep all | none au niveau de la [edit protocols bgp] hiérarchie ou [edit protocols bgp group group-name]

Les règles de conservation des routes BGP sont les suivantes :

  • Par défaut, toutes les routes apprises à partir de BGP sont conservées, à l’exception de celles où le chemin AS est bouclé. (Le chemin AS inclut l’AS local.)

  • En configurant l’instruction, toutes les routes apprises à partir de BGP sont conservées, même celles dont le chemin d’accès à l’AS keep all local se trouve.

  • En configurant l’instruction, BGP ignore les routes qui ont été reçues d’un homologue et qui ont été rejetées par une stratégie d’importation ou d’autres vérifications d’intégrité keep none . Lorsque cette instruction est configurée et que la stratégie entrante change, Junos OS annonce à nouveau toutes les routes annoncées par l’homologue.

Lorsque vous configurez keep all ou keep none et que l’actualisation de l’itinéraire de prise en charge des homologues est effectuée, le haut-parleur local envoie un message d’actualisation et effectue une évaluation de l’importation. Pour ces homologues, les sessions ne redémarrent pas. Pour déterminer si un homologue prend en charge l’actualisation, vérifiez Peer supports Refresh capability la sortie de la show bgp neighbor commande.

ATTENTION :

Si vous configurez keep all ou keep none et que l’homologue ne prend pas en charge le redémarrage de session, les sessions BGP associées sont redémarrées (battues).

Topologie

Configuration

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.

Routeur Internet

Routeur Nord

Routeur Sud

Configuration de l’installation conditionnelle des préfixes

Procédure étape par étape

L’exemple suivant nécessite que vous naviguiez à 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’installation conditionnelle des préfixes :

  1. Configurez les interfaces de routeur formant les liens entre les trois routeurs.

  2. Configurez cinq adresses d’interface de bouclage sur le routeur Internet pour émuler les routes BGP apprises sur Internet qui doivent être importées dans la table de routage du routeur Sud, puis configurez une adresse supplémentaire (192.168.9.1/32) qui sera configurée comme ID de routeur.

    Configurez également les adresses de l’interface de bouclage sur les routeurs Nord et Sud.

  3. Configurez l’itinéraire statique par défaut sur le routeur Nord à annoncer sur le routeur Sud.

  4. Définissez la condition d’exportation des préfixes à partir de la table de routage sur Router North.

  5. Définissez des stratégies d’exportation (into-bgp et ) sur les routeurs Internet et conditional-export-bgp North, respectivement, pour annoncer les routes vers BGP.

    REMARQUE :

    Assurez-vous de référencer la condition prefix_11 (configurée à l’étape 4) dans la stratégie d’exportation.

  6. Définissez une stratégie d’importation (import-selected-routes) sur Router South pour importer certaines des routes annoncées par Router North dans sa table de routage.

  7. Configurez BGP sur les trois routeurs pour permettre le flux de préfixes entre les systèmes autonomes.

    REMARQUE :

    Assurez-vous d’appliquer les stratégies d’importation et d’exportation définies aux groupes BGP respectifs pour que la publication du préfixe ait lieu.

  8. Configurez l’ID de routeur et le numéro du système autonome pour les trois routeurs.

    REMARQUE :

    Dans cet exemple, l’ID du routeur est configuré en fonction de l’adresse IP configurée sur l’interface lo0.0 du routeur.

Résultats

À partir du mode configuration, confirmez votre configuration en exécutant les commandes show interfaces, show protocols bgp, 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.

Appareil Internet

Nord de l’appareil

Appareil Sud

Si vous avez terminé de configurer les routeurs, passez commit en mode de configuration.

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérification de BGP

But

Vérifiez que des sessions BGP ont été établies entre les trois routeurs.

Action

À partir du mode opérationnel, exécutez la show bgp neighbor neighbor-address commande.

  1. Vérifiez la session BGP sur le routeur Internet pour vérifier que le routeur Nord est un voisin.

  2. Vérifiez la session BGP sur le routeur nord pour vérifier que le routeur Internet est un voisin.

Vérifiez les champs suivants dans ces sorties pour vérifier que des sessions BGP ont été établies :

  • Peer: vérifiez si le numéro AS de l’homologue est répertorié.

  • Local: vérifiez si le numéro AS local est répertorié.

  • State: assurez-vous que la valeur est Established. Si ce n’est pas le cas, vérifiez à nouveau la configuration et consultez show bgp neighbor pour plus de détails sur les champs de sortie.

De même, vérifiez que les routeurs Nord et Sud établissent des relations d’égal à égal les uns avec les autres.

Sens

Des sessions BGP sont établies entre les trois routeurs.

Vérification de l’annonce du préfixe du routeur Internet vers le routeur Nord

But

Vérifiez que les routes envoyées à partir du routeur Internet sont reçues par le routeur North.

Action

  1. À partir du mode opérationnel sur le routeur Internet, exécutez la show route advertising-protocol bgp neighbor-address commande.

    La sortie vérifie que Router Internet annonce les routes 172.16.11.1/32, 172.16.12.1/32, 172.16.13.1/32, 172.16.14.1/32, 172.16.15.1/32 et 192.168.9.1/32 (l’adresse de bouclage utilisée comme ID de routeur) vers le routeur Nord.

  2. À partir du mode opérationnel sur le routeur Nord, exécutez la show route receive-protocol bgp neighbor-address commande.

    La sortie vérifie que le routeur Nord a reçu toutes les routes annoncées par le routeur Internet.

Sens

Les préfixes envoyés par le routeur Internet ont été installés avec succès dans la table de routage sur le routeur Nord.

Vérification de l’annonce du préfixe du routeur nord vers le routeur sud

But

Vérifiez que les routes reçues du routeur Internet et la route statique par défaut sont annoncées par Routeur Nord vers Routeur Sud.

Action

  1. À partir du mode opérationnel sur le routeur Nord, exécutez la show route 0/0 exact commande.

    La sortie vérifie la présence de la route statique par défaut (0.0.0.0/0) dans la table de routage sur Router North.

  2. À partir du mode opérationnel sur le routeur Nord, exécutez la show route advertising-protocol bgp neighbor-address commande.

    La sortie vérifie que le routeur Nord annonce la route statique et la route 172.16.11.1/32 reçue du routeur Internet, ainsi que de nombreuses autres routes, vers le routeur Sud.

Vérification de la stratégie d’importation BGP pour l’installation des préfixes

But

Vérifiez que la stratégie d’importation BGP installe correctement les préfixes requis.

Action

Vérifiez si la stratégie d’importation sur le routeur sud est opérationnelle en vérifiant si seuls l’itinéraire statique par défaut du routeur nord et l’itinéraire 172.16.11.1/32 du routeur sud sont installés dans la table de routage.

À partir du mode opérationnel, exécutez la show route receive-protocol bgp neighbor-address commande.

La sortie vérifie que la stratégie d’importation BGP est opérationnelle sur le routeur Sud et que seule la route statique par défaut 0.0.0.0/0 à partir du routeur Nord et la route 172.16.11.1/32 à partir du routeur Internet ont fuité dans la table de routage sur le routeur Sud.

Sens

L’installation des préfixes réussit grâce à la stratégie d’importation BGP configurée.

Vérification de l’exportation conditionnelle du routeur Nord vers le routeur Sud

But

Vérifiez que lorsque l’appareil Internet cesse d’envoyer l’itinéraire 172.16.11.1/32, l’appareil Nord cesse d’envoyer l’itinéraire 0/0 par défaut.

Action

  1. Faites en sorte que Device Internet cesse d’envoyer l’itinéraire 172.16.11.1/32 en désactivant l’adresse 172.16.11.1/32 sur l’interface de bouclage.

  2. À partir du mode opérationnel sur le routeur Nord, exécutez la show route advertising-protocol bgp neighbor-address commande.

    La sortie vérifie que le routeur nord n’annonce pas l’itinéraire par défaut vers le routeur sud. Il s’agit du comportement attendu lorsque la route 172.16.11.1/32 n’est pas présente.

  3. Réactivez l’adresse 172.16.11.1/32 sur l’interface de bouclage de Device Internet.

Vérification de la présence de routes masquées par la stratégie (facultatif)

But

Vérifiez la présence de routes masquées par la stratégie d’importation configurée sur Router South.

REMARQUE :

Cette section présente les effets des différentes modifications que vous pouvez apporter à la configuration en fonction de vos besoins.

Action

Affichez les routes masquées de la table de routage du routeur Sud en :

  • Utilisation de l’option hiddende la show route receive-protocol bgp neighbor-address commande.

  • Désactivation de la stratégie d’importation.

  1. À partir du mode opérationnel, exécutez la commande pour afficher les show route receive-protocol bgp neighbor-address hidden itinéraires cachés.

    La sortie vérifie la présence de routes masquées par la stratégie d’importation (172.16.12.1/32, 172.16.13.1/32, 172.16.14.1/32 et 172.16.15.1/32) sur le routeur sud.

  2. Désactivez la stratégie d’importation BGP en configurant l’instruction deactivate import au niveau de la [edit protocols bgp group group-name] hiérarchie.

  3. Exécutez la commande mode opérationnel pour vérifier les routes après avoir désactivé la show route receive-protocol bgp neighbor-address stratégie d’importation.

    La sortie vérifie la présence de routes précédemment masquées (172.16.12.1/32, 172.16.13.1/32, 172.16.14.1/32 et 172.16.15.1/32).

  4. Activez la stratégie d’importation BGP et supprimez les routes masquées de la table de routage en configurant respectivement les activate import instructions et keep none au niveau de la [edit protocols bgp group group-name] hiérarchie.

  5. En mode opérationnel, exécutez la commande pour vérifier les routes après avoir activé la show route receive-protocol bgp neighbor-address hidden stratégie d’importation et configuré l’instruction keep none .

    La sortie vérifie que les routes masquées ne sont pas conservées dans la table de routage en raison de l’instruction configurée keep none .

Voir également

Filtre implicite pour le comportement de propagation de route EBGP par défaut sans stratégies

SUMMARY Cette section traite de l’utilisation d’un filtre implicite pour réguler le comportement de propagation de la route EBGP lorsqu’aucune stratégie explicite n’est configurée.

Avantages

Cette fonctionnalité offre les avantages suivants :

  • Regulates BGP implementation: empêche les haut-parleurs EBGP de devenir un relais silencieux là où ils acceptaient et annonçaient toutes les routes par défaut. Cette fonctionnalité permet de réduire efficacement l’augmentation du trafic de transit sur les systèmes autonomes Leaf, en particulier lorsqu’ils sont multi-hébergés vers des fournisseurs de services Internet en amont. Ainsi, il empêche également les pertes silencieuses de trafic, les dénis de service et les pannes Internet mondiales.

  • Implicit filter: la configuration facilite l’utilisation d’un filtre implicite, où le comportement par défaut est toujours défini pour recevoir et annoncer tous les itinéraires par défaut. L’instruction de configuration ajoute uniquement une option permettant de spécifier enable ou disable pour les clauses accept, reject, reject-always, lorsque cela est nécessaire. Le filtre implicite garantit que les utilisateurs des déploiements existants qui s’appuient sur la stratégie BGP par défaut ne subissent pas d’interruptions opérationnelles.

Présentation

BGP est le protocole autonome inter-domaine actuellement utilisé pour le routage Internet global. Il prend également en charge divers services tels que les VPN et l’état des liens, qui ne sont pas destinés à une utilisation globale.

L’implémentation de BGP, y compris le comportement EBGP par défaut, est guidée par RFC4271, A Border Gateway Protocol 4 (BGP-4). Cependant, il ne fournit pas d’indications explicites sur la spécification des routes à distribuer. Par conséquent, l’implémentation BGP d’origine était un relais silencieux pour les routes sans aucun filtrage, ce qui entraînait une augmentation du trafic, entraînant des pannes Internet à l’échelle mondiale.

À partir de Junos OS version 20.3R1, nous avons introduit un filtre defaults ebgp no-policy implicite au niveau de la hiérarchie existante [edit protocols bgp] . La configuration sépare la stratégie par défaut de réception et d’annonce en clauses distinctes (accept, reject ou reject-always) pour permettre au comportement de varier indépendamment.

Si aucune stratégie explicite n’est configurée, le filtre implicite vous permet d’activer le comportement de réception et d’annonce eBGP par défaut dans l’un des trois états suivants :

Valeurs

Politique par défaut

Ce qu’il fait

Accepter

Recevoir

Accepte de recevoir toutes les routes (également le comportement par défaut).

Annoncer

Accepte de publier tous les itinéraires (également le comportement par défaut).

Rejeter

Recevoir

Rejette la réception des routes de type inet unicast et inet6 unicast dans les types d’instance primary, vrf, virtual-router et non-forwarding.

Annoncer

Refuse d’annoncer les routes de type inet unicast et inet6 unicast dans les types d’instance primary, vrf, virtual-router et non-forwarding.

reject-always

Recevoir

Refuse de recevoir tous les itinéraires.

Annoncer

Refuse d’annoncer tous les itinéraires.

Voir également