Sur cette page
Exemple : Application de stratégies de routage à différents niveaux de la hiérarchie BGP
Exemple : Injection de routes OSPF dans la table de routage BGP
Configuration des stratégies de routage pour contrôler les annonces de routage BGP
Exemple : Configuration du filtrage des routes sortantes basé sur des préfixes BGP
Publication conditionnelle Activation de l’installation conditionnelle de préfixes Cas d’utilisation
Filtre implicite pour le comportement de propagation de route EBGP par défaut sans stratégies
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
andexport
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
andexport
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
andexport
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.
user@host# show protocols bgp { local-address 172.16.1.1; export send-direct; group internal-peers { type internal; export send-192.168.0.1; neighbor 172.16.2.2 { export send-192.168.20.1; } neighbor 172.16.3.3; } group other-group { type internal; neighbor 172.16.4.4; } }
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.
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
set interfaces fe-1/2/0 unit 0 description to-R2 set interfaces fe-1/2/0 unit 0 family inet address 10.10.10.1/30 set interfaces lo0 unit 0 family inet address 172.16.1.1/32 set protocols bgp local-address 172.16.1.1 set protocols bgp export send-direct set protocols bgp group internal-peers type internal set protocols bgp group internal-peers export send-static-192.168.0 set protocols bgp group internal-peers neighbor 172.16.2.2 export send-static-192.168.20 set protocols bgp group internal-peers neighbor 172.16.3.3 set protocols bgp group other-group type internal set protocols bgp group other-group neighbor 172.16.4.4 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface fe-1/2/0.0 set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set policy-options policy-statement send-static-192.168.0 term 1 from protocol static set policy-options policy-statement send-static-192.168.0 term 1 from route-filter 192.168.0.0/24 orlonger set policy-options policy-statement send-static-192.168.0 term 1 then accept set policy-options policy-statement send-static-192.168.20 term 1 from protocol static set policy-options policy-statement send-static-192.168.20 term 1 from route-filter 192.168.20.0/24 orlonger set policy-options policy-statement send-static-192.168.20 term 1 then accept set routing-options static route 192.168.0.1/32 discard set routing-options static route 192.168.20.1/32 discard set routing-options router-id 172.16.1.1 set routing-options autonomous-system 17
Appareil R2
set interfaces fe-1/2/0 unit 0 description to-R1 set interfaces fe-1/2/0 unit 0 family inet address 10.10.10.2/30 set interfaces fe-1/2/1 unit 0 description to-R3 set interfaces fe-1/2/1 unit 0 family inet address 10.10.10.5/30 set interfaces lo0 unit 0 family inet address 172.16.2.2/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 172.16.2.2 set protocols bgp group internal-peers neighbor 172.16.3.3 set protocols bgp group internal-peers neighbor 172.16.1.1 set protocols bgp group internal-peers neighbor 172.16.4.4 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface fe-1/2/0.0 set protocols ospf area 0.0.0.0 interface fe-1/2/1.0 set routing-options router-id 172.16.2.2 set routing-options autonomous-system 17
Appareil R3
set interfaces fe-1/2/1 unit 0 description to-R2 set interfaces fe-1/2/1 unit 0 family inet address 10.10.10.6/30 set interfaces fe-1/2/2 unit 0 description to-R4 set interfaces fe-1/2/2 unit 0 family inet address 10.10.10.9/30 set interfaces lo0 unit 0 family inet address 172.16.3.3/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 172.16.3.3 set protocols bgp group internal-peers neighbor 172.16.2.2 set protocols bgp group internal-peers neighbor 172.16.1.1 set protocols bgp group internal-peers neighbor 172.16.4.4 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface fe-1/2/1.0 set protocols ospf area 0.0.0.0 interface fe-1/2/2.0 set routing-options router-id 172.16.3.3 set routing-options autonomous-system 17
Appareil R4
set interfaces fe-1/2/2 unit 0 description to-R3 set interfaces fe-1/2/2 unit 0 family inet address 10.10.10.10/30 set interfaces lo0 unit 0 family inet address 172.16.4.4/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 172.16.4.4 set protocols bgp group internal-peers neighbor 172.16.2.2 set protocols bgp group internal-peers neighbor 172.16.1.1 set protocols bgp group internal-peers neighbor 172.16.3.3 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface fe-1/2/2.0 set routing-options router-id 172.16.4.4 set routing-options autonomous-system 17
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 :
Configurez les interfaces de l’appareil.
[edit interfaces] user@R1# set fe-1/2/0 unit 0 description to-R2 user@R1# set fe-1/2/0 unit 0 family inet address 10.10.10.1/30 user@R1# set lo0 unit 0 family inet address 172.16.1.1/32
Activez OSPF, ou un autre protocole IGP (Interior Gateway Protocols), sur les interfaces.
[edit protocols OSPF area 0.0.0.0] user@R1# set interface lo0.0 passive user@R1# set interface fe-1/2/0.0
Configurez les routes statiques.
[edit routing-options] user@R1# set static route 192.168.0.1/32 discard user@R1# set static route 192.168.20.1/32 discard
Activez les stratégies de routage.
[edit protocols policy-options] user@R1# set policy-statement send-direct term 1 from protocol direct user@R1# set policy-statement send-direct term 1 then accept user@R1# set policy-statement send-static-192.168.0 term 1 from protocol static user@R1# set policy-statement send-static-192.168.0 term 1 from route-filter 192.168.0.0/24 orlonger user@R1# set policy-statement send-static-192.168.0 term 1 then accept user@R1# set policy-statement send-static-192.168.20 term 1 from protocol static user@R1# set policy-statement send-static-192.168.20 term 1 from route-filter 192.168.20.0/24 orlonger user@R1# set policy-statement send-static-192.168.20 term 1 then accept
Configurez BGP et appliquez les stratégies d’exportation.
[edit protocols bgp] user@R1# set local-address 172.16.1.1 user@R1# set protocols bgp export send-direct user@R1# set group internal-peers type internal user@R1# set group internal-peers export send-static-192.168.0 user@R1# set group internal-peers neighbor 172.16.2.2 export send-static-192.168.20 user@R1# set group internal-peers neighbor 172.16.3.3 user@R1# set group other-group type internal user@R1# set group other-group neighbor 172.16.4.4
Configurez l’ID du routeur et le numéro du système autonome (AS).
[edit routing-options] user@R1# set router-id 172.16.1.1 user@R1# set autonomous-system 17
Si vous avez terminé de configurer l’appareil, validez la configuration.
[edit] user@R1# commit
Résultats
À partir du mode configuration, confirmez votre configuration en exécutant les commandes show interfaces
, show protocols
, 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.
user@R1# show interfaces fe-1/2/0 { unit 0 { description to-R2; family inet { address 10.10.10.1/30; } } } lo0 { unit 0 { family inet { address 172.16.1.1/32; } } }
user@R1# show protocols bgp { local-address 172.16.1.1; export send-direct; group internal-peers { type internal; export send-static-192.168.0; neighbor 172.16.2.2 { export send-static-192.168.20; } neighbor 172.16.3.3; } group other-group { type internal; neighbor 172.16.4.4; } } ospf { area 0.0.0.0 { interface lo0.0 { passive; } interface fe-1/2/0.0; } }
user@R1# show policy-options policy-statement send-direct { term 1 { from protocol direct; then accept; } } policy-statement send-static-192.168.0 { term 1 { from { protocol static; route-filter 192.168.0.0/24 orlonger; } then accept; } } policy-statement send-static-192.168.20 { term 1 { from { protocol static; route-filter 192.168.20.0/24 orlonger; } then accept; } }
user@R1# show routing-options static { route 192.168.0.1/32 discard; route 192.168.20.1/32 discard; } router-id 172.16.1.1; autonomous-system 17;
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
user@R1> show route protocol direct inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.1.1/32 *[Direct/0] 1d 22:19:47 > via lo0.0 10.10.10.0/30 *[Direct/0] 1d 22:19:47 > via fe-1/2/0.0
user@R1> show route protocol static inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.0.1/32 *[Static/5] 02:20:03 Discard 192.168.20.1/32 *[Static/5] 02:20:03 Discard
user@R2> show route protocol bgp inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.20.1/32 *[BGP/170] 02:02:40, localpref 100, from 172.16.1.1 AS path: I, validation-state: unverified > to 10.10.10.1 via fe-1/2/0.0
user@R3> show route protocol bgp inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.0.1/32 *[BGP/170] 02:02:51, localpref 100, from 172.16.1.1 AS path: I, validation-state: unverified > to 10.10.10.5 via fe-1/2/1.0
user@R4> show route protocol bgp inet.0: 9 destinations, 11 routes (9 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.1.1/32 [BGP/170] 1d 20:38:54, localpref 100, from 172.16.1.1 AS path: I, validation-state: unverified > to 10.10.10.9 via fe-1/2/2.0 10.10.10.0/30 [BGP/170] 1d 20:38:54, localpref 100, from 172.16.1.1 AS path: I, validation-state: unverified > to 10.10.10.9 via fe-1/2/2.0
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
user@R2> show route receive-protocol bgp 172.16.1.1 inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 192.168.20.1/32 172.16.1.1 100 I
user@R3> show route receive-protocol bgp 172.16.1.1 inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 192.168.0.1/32 172.16.1.1 100 I
user@R4> show route receive-protocol bgp 172.16.1.1 inet.0: 9 destinations, 11 routes (9 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 172.16.1.1/32 172.16.1.1 100 I 10.10.10.0/30 172.16.1.1 100 I
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.
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 :
Configurez les interfaces réseau.
Configurez des sessions homologues externes. Voir l’exemple : Configuration de sessions homologues point à point BGP externes.
Configurez les sessions IGP (Interior Gateway Protocol) entre homologues.
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.
set policy-options policy-statement injectpolicy1 term injectterm1 from protocol ospf set policy-options policy-statement injectpolicy1 term injectterm1 from area 0.0.0.1 set policy-options policy-statement injectpolicy1 term injectterm1 then accept set protocols bgp export injectpolicy1
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 :
Créez le terme de la stratégie.
[edit policy-options policy-statement injectpolicy1] user@host# set term injectterm1
Spécifiez OSPF comme condition de correspondance.
[edit policy-options policy-statement injectpolicy1 term injectterm1] user@host# set from protocol ospf
Spécifiez les routes à partir d’une zone OSPF en tant que condition de correspondance.
[edit policy-options policy-statement injectpolicy1 term injectterm1] user@host# set from area 0.0.0.1
Spécifiez que l’itinéraire doit être accepté si les conditions précédentes sont remplies.
[edit policy-options policy-statement injectpolicy1 term injectterm1] user@host# set then accept
Appliquez la stratégie de routage au BGP.
[edit] user@host# set protocols bgp export injectpolicy1
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.
user@host# show policy-options policy-statement injectpolicy1 { term injectterm1 { from { protocol ospf; area 0.0.0.1; } then accept; } }
user@host# show protocols bgp export injectpolicy1;
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.
set policy-options policy-statement injectpolicy1 term injectterm1 then trace set routing-options traceoptions file ospf-bgp-policy-log set routing-options traceoptions file size 5m set routing-options traceoptions file files 5 set routing-options traceoptions flag policy
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.
Incluez une action de suivi dans la stratégie.
[edit policy-options policy-statement injectpolicy1 term injectterm1] user@host# then trace
Configurez le fichier de suivi pour la sortie.
[edit routing-options traceoptions] user@host# set file ospf-bgp-policy-log user@host# set file size 5m user@host# set file files 5 user@host# set flag policy
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.
user@host# show policy-options policy-statement injectpolicy1 { term injectterm1 { then { trace; } } }
user@host# show routing-options traceoptions { file ospf-bgp-policy-log size 5m files 5; flag policy; }
Si vous avez terminé de configurer l’appareil, passez commit
en mode de configuration.
Vérification
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
- Définition de BGP pour annoncer les routes inactives
- Configuration de BGP pour annoncer le meilleur itinéraire externe à ses homologues internes
- Configuration de la fréquence à laquelle BGP échange des routes avec la table de routage
- Désactivation de la suppression des annonces d’itinéraire
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
andexport
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
andexport
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
andexport
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
- Application de stratégies aux routes exportées de la table de routage vers BGP
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 :
import [ policy-names ];
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 :
export [ policy-names ];
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 :
advertise-inactive;
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.
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 :
advertise-external;
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 :
advertise-external { conditional; }
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 :
out-delay seconds;
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 :
keep (all | none);
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 configurezkeep 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 :
advertise-peer-as;
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 :
no-advertise-peer-as;
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.
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 :
policy-options { policy-statement name{ from state (active|inactive); } }
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.
user@host# show policy-options policy-statement mark-inactive { term inactive { from state inactive; then { community set comm-inactive; } } term default { from protocol bgp; then accept; } then reject; } community comm-inactive members 65536:65284;
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.
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.
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
set interfaces fe-1/2/0 unit 0 description to-R2 set interfaces fe-1/2/0 unit 0 family inet address 10.0.0.1/30 set interfaces lo0 unit 0 family inet address 192.168.0.1/32 set protocols bgp group ext type external set protocols bgp group ext export send-static set protocols bgp group ext peer-as 200 set protocols bgp group ext neighbor 10.0.0.2 set policy-options policy-statement send-static term 1 from protocol static set policy-options policy-statement send-static term 1 from route-filter 172.16.6.0/24 exact set policy-options policy-statement send-static term 1 then accept set policy-options policy-statement send-static term 2 then reject set routing-options static route 172.16.6.0/24 reject set routing-options router-id 192.168.0.1 set routing-options autonomous-system 100
Appareil R2
set interfaces fe-1/2/0 unit 0 description to-R1 set interfaces fe-1/2/0 unit 0 family inet address 10.0.0.2/30 set interfaces fe-1/2/1 unit 0 description to-R3 set interfaces fe-1/2/1 unit 0 family inet address 10.0.0.5/30 set interfaces lo0 unit 0 family inet address 192.168.0.2/32 set protocols bgp group ext type external set protocols bgp group ext peer-as 100 set protocols bgp group ext neighbor 10.0.0.1 set protocols bgp group int type internal set protocols bgp group int local-address 192.168.0.2 set protocols bgp group int advertise-external set protocols bgp group int neighbor 192.168.0.3 set protocols ospf area 0.0.0.0 interface fe-1/2/1.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set routing-options router-id 192.168.0.2 set routing-options autonomous-system 200
Appareil R3
set interfaces fe-1/2/0 unit 6 family inet address 10.0.0.6/30 set interfaces lo0 unit 0 family inet address 192.168.0.3/32 set protocols bgp group int type internal set protocols bgp group int local-address 192.168.0.3 set protocols bgp group int export send-static set protocols bgp group int neighbor 192.168.0.2 set protocols ospf area 0.0.0.0 interface fe-1/2/0.6 set protocols ospf area 0.0.0.0 interface lo0.0 passive set policy-options policy-statement send-static term 1 from protocol static set policy-options policy-statement send-static term 1 then local-preference 200 set policy-options policy-statement send-static term 1 then accept set routing-options static route 172.16.6.0/24 reject set routing-options static route 0.0.0.0/0 next-hop 10.0.0.5 set routing-options autonomous-system 200
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 :
Configurez les interfaces de l’appareil.
[edit interfaces] user@R2# set fe-1/2/0 unit 0 description to-R1 user@R2# set fe-1/2/0 unit 0 family inet address 10.0.0.2/30 user@R2# set fe-1/2/1 unit 0 description to-R3 user@R2# set fe-1/2/1 unit 0 family inet address 10.0.0.5/30 user@R2# set lo0 unit 0 family inet address 192.168.0.2/32
Configurez OSPF ou un autre protocole IGP (Interior Gateway Protocol).
[edit protocols ospf area 0.0.0.0] user@R2# set interface fe-1/2/1.0 user@R2# set interface lo0.0 passive
Configurez la connexion EBGP à l’appareil R1.
[edit protocols bgp group ext] user@R2# set type external user@R2# set peer-as 100 user@R2# set neighbor 10.0.0.1
Configurez la connexion IBGP à l’appareil R3.
[edit protocols bgp group int] user@R2# set type internal user@R2# set local-address 192.168.0.2 user@R2# set neighbor 192.168.0.3
Ajoutez l’instruction
advertise-external
à la session d’appairage de groupe IBGP.[edit protocols bgp group int] user@R2# set advertise-external
Configurez le numéro du système autonome (AS) et l’ID du routeur.
[edit routing-options ] user@R2# set router-id 192.168.0.2 user@R2# set autonomous-system 200
Résultats
À partir du mode de configuration, confirmez votre configuration en saisissant les commandes show interfaces
, show protocols
, 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.
user@R2# show interfaces fe-1/2/0 { unit 0{ description to-R1; family inet { address 10.0.0.2/30; } } } fe-1/2/1 { unit 0 { description to-R3; family inet { address 10.0.0.5/30; } } } lo0 { unit 0 { family inet { address 192.168.0.2/32; } } }
user@R2# show protocols bgp { group ext { type external; peer-as 100; neighbor 10.0.0.1; } group int { type internal; local-address 192.168.0.2; advertise-external; neighbor 192.168.0.3; } } ospf { area 0.0.0.0 { interface fe-1/2/1.0; interface lo0.0 { passive; } } }
user@R2# show routing-options router-id 192.168.0.2; autonomous-system 200;
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
- Vérification de l’annonce d’itinéraire externe
- Vérification de l’itinéraire sur l’appareil R3
- Expérimentation de l’option conditionnelle
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
user@R2> show route 172.16.6 inet.0: 8 destinations, 9 routes (8 active, 1 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.6.0/24 *[BGP/170] 00:00:07, localpref 200, from 192.168.0.3 AS path: I, validation-state: unverified > to 10.0.0.6 via fe-1/2/1.0 [BGP/170] 03:23:03, localpref 100 AS path: 100 I, validation-state: unverified > to 10.0.0.1 via fe-1/2/0.0
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
user@R2> show route advertising-protocol bgp 192.168.0.3 inet.0: 8 destinations, 9 routes (8 active, 1 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 172.16.6.0/24 10.0.0.1 100 100 I
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
user@R3> show route 172.16.6.0/24 inet.0: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.6.0/24 *[Static/5] 03:34:14 Reject [BGP/170] 06:34:43, localpref 100, from 192.168.0.2 AS path: 100 I, validation-state: unverified > to 10.0.0.5 via fe-1/2/0.6
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
Sur l’appareil R2, ajoutez l’option
conditional
.[edit protocols bgp group int] user@R2# set advertise-external conditional user@R2# commit
Sur l’appareil R2, vérifiez si l’itinéraire 172.16.6.0/24 est annoncé vers l’appareil R3.
user@R2> show route advertising-protocol bgp 192.168.0.3
Comme prévu, l’itinéraire n’est plus annoncé. Vous devrez peut-être attendre quelques secondes pour voir ce résultat.
Sur l’appareil R3, désactivez l’action de
then local-preference
stratégie.[edit policy-options policy-statement send-static term 1] user@R3# deactivate logical-systems R3 then local-preference user@R3# commit
Sur l’appareil R2, assurez-vous que les préférences locales des deux chemins sont égales.
user@R2> show route 172.16.6.0/24 inet.0: 8 destinations, 9 routes (8 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.6.0/24 *[BGP/170] 08:02:59, localpref 100 AS path: 100 I, validation-state: unverified > to 10.0.0.1 via fe-1/2/0.0 [BGP/170] 00:07:51, localpref 100, from 192.168.0.3 AS path: I, validation-state: unverified > to 10.0.0.6 via fe-1/2/1.0
Sur l’appareil R2, ajoutez l’instruction
as-path-ignore
.[edit protocols bgp] user@R2# set path-selection as-path-ignore user@R2# commit
Sur l’appareil R2, vérifiez si l’itinéraire 172.16.6.0/24 est annoncé vers l’appareil R3.
user@R2> show route advertising-protocol bgp 192.168.0.3 inet.0: 8 destinations, 9 routes (8 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.6.0/24 10.0.0.1 100 100 I
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.
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.
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
set protocols bgp group cisco-peers type external set protocols bgp group cisco-peers description “to CE1” set protocols bgp group cisco-peers local-address 192.168.165.58 set protocols bgp group cisco-peers peer-as 35 set protocols bgp group cisco-peers outbound-route-filter bgp-orf-cisco-mode set protocols bgp group cisco-peers outbound-route-filter prefix-based accept inet set protocols bgp group cisco-peers neighbor 192.168.165.56 set routing-options autonomous-system 65500
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 :
Configurez le système autonome local.
[edit routing-options] user@PE1# set autonomous-system 65500
Configurez l’appairage externe avec l’appareil CE1.
[edit protocols bgp group cisco-peers] user@PE1# set type external user@PE1# set description “to CE1” user@PE1# set local-address 192.168.165.58 user@PE1# set peer-as 35 user@PE1# set neighbor 192.168.165.56
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.
[edit protocols bgp group cisco-peers] user@PE1# set outbound-route-filter prefix-based accept inet
(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.
[edit protocols bgp group cisco-peers] user@PE1# set outbound-route-filter bgp-orf-cisco-mode
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.
user@PE1# show protocols group cisco-peers { type external; description “to CE1”; local-address 192.168.165.58; peer-as 35; outbound-route-filter { bgp-orf-cisco-mode; prefix-based { accept { inet; } } } neighbor 192.168.165.56; }
user@PE1# show routing-options autonomous-system 65500;
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.
user@PE1> show bgp neighbor orf 192.168.165.56 detail Peer: 192.168.165.56 Type: External Group: cisco-peers inet-unicast Filter updates recv: 4 Immediate: 0 Filter: prefix-based receive Updates recv: 4 Received filter entries: seq 10 2.2.0.0/16 deny minlen 0 maxlen 0 seq 20 3.3.0.0/16 deny minlen 24 maxlen 0 seq 30 4.4.0.0/16 deny minlen 0 maxlen 28 seq 40 5.5.0.0/16 deny minlen 24 maxlen 28
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.
user@PE1> show bgp neighbor Peer: 192.168.165.56 AS 35 Local: 192.168.165.58 AS 65500 Type: External State: Active Flags: <> Last State: Idle Last Event: Start Last Error: None Export: [ adv_stat ] Options: <Preference LocalAddress AddressFamily PeerAS Refresh> Options: <ORF ORFCiscoMode> Address families configured: inet-unicast Local Address: 192.168.165.58 Holdtime: 90 Preference: 170 Number of flaps: 0 Trace options: detail open detail refresh Trace file: /var/log/orf size 5242880 files 20
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.
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 :
user@host# show policy-options | display inheritance defaults no-comments policy-options { policy-statement junos-ptx-series-default { term t1 { from { protocol bgp; rib inet.0; } then no-install-to-fib; } term t2 { from { protocol bgp; rib inet6.0; } then no-install-to-fib; } term t3 { then load-balance per-packet; } } } routing-options { forwarding-table { default-export junos-ptx-series-default; } } user@host# show routing-options forwarding-table default-export | display inheritance defaults no-comments default-export junos-ptx-series-default;
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.
user@host> show policy junos-ptx-series-default Policy junos-ptx-series-default: Term t1: from proto BGP inet.0 then install-to-fib no Term t2: from proto BGP inet6.0 then install-to-fib no Term t3: then load-balance per-packet
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.
user@host# show policy-options policy-statement accept-no-install { term 1 { from protocol bgp; then accept; } } user@host# show routing-options forwarding-table { export accept-no-install; }
user@host> show route forwarding-table Routing table: default.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 rjct 36 2
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
- Installation des routes BGP sélectionnées dans la table de transfert
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.
set policy-options prefix-list install-bgp 66.0.0.1/32 set policy-options policy-statement override-ptx-series-default term 1 from prefix-list install-bgp set policy-options policy-statement override-ptx-series-default term 1 then load-balance per-prefix set policy-options policy-statement override-ptx-series-default term 1 then install-to-fib set routing-options forwarding-table export override-ptx-series-default
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 :
Configurez une liste de préfixes à installer dans la table de transfert.
[edit policy-options prefix-list install-bgp] user@host# set 66.0.0.1/32
Configurez la stratégie de routage en appliquant la liste de préfixes comme condition.
[edit policy-options policy-statement override-ptx-series-default term 1] user@host# set from prefix-list install-bgp user@host# set then install-to-fib user@host# set then load-balance per-prefix
Appliquez la stratégie de routage à la table de transfert.
[edit routing-options forwarding-table] user@host# set export override-ptx-series-default
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.
user@host# show policy-options prefix-list install-bgp { 66.0.0.1/32; } policy-statement override-ptx-series-default { term 1 { from { prefix-list install-bgp; } then { load-balance per-prefix; install-to-fib; } } }
user@host# show routing-options forwarding-table { export override-ptx-series-default; }
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.
user@host> show route forwarding-table destination 66.0.0.1 Internet: Destination Type RtRef Next hop Type Index NhRef Netif 66.0.0.1/32 user 0 indr 2097159 3 ulst 2097156 2 5.1.0.2 ucst 574 1 et-6/0/0.1 5.2.0.2 ucst 575 1 et-6/0/0.2
Sens
Cette sortie montre que la route vers 66.0.0.1/32 est installée dans la table de transfert.
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 :
[edit] policy-options { condition condition-name { if-route-exists address table table-name; } }
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.
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 :
Créez une
condition
instruction pour vérifier les préfixes.[edit] policy-options { condition condition-name { if-route-exists address table table-name; } }
Créez une stratégie d’exportation avec la condition que vous venez de créer à l’aide de l’instruction
condition
.[edit] policy-options { policy-statement policy-name { term 1 { from { protocols bgp; condition condition-name; } then { accept; } } } }
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.
[edit] protocols bgp { group group-name { export policy-name; } }
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.
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 :
user@North# show policy-options policy-statement conditional-export-bgp { term prefix_11 { from { protocol bgp; route-filter 172.16.0.0/16 orlonger; } then accept; } term conditional-default { from { route-filter 0.0.0.0/0 exact; condition prefix_11; } then accept; } term others { then reject; } } condition prefix_11 { if-route-exists { 172.16.11.1/32; table inet.0; } }
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 :
user@South# show policy-options policy-statement import-selected-routes { term 1 { from { rib inet.0; neighbor 10.0.78.14; route-filter 0.0.0.0/0 exact; route-filter 172.16.11.1/32 exact; } then accept; } term 2 { then reject; } }
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.
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
- Configuration de l’installation conditionnelle des préfixes
- Résultats
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
set interfaces lo0 unit 0 family inet address 172.16.11.1/32 set interfaces lo0 unit 0 family inet address 172.16.12.1/32 set interfaces lo0 unit 0 family inet address 172.16.13.1/32 set interfaces lo0 unit 0 family inet address 172.16.14.1/32 set interfaces lo0 unit 0 family inet address 172.16.15.1/32 set interfaces lo0 unit 0 family inet address 192.168.9.1/32 set interfaces fe-0/1/3 unit 0 family inet address 10.0.89.14/30 set protocols bgp group toNorth local-address 10.0.89.14 set protocols bgp group toNorth peer-as 65200 set protocols bgp group toNorth neighbor 10.0.89.13 set protocols bgp group toNorth export into-bgp set policy-options policy-statement into-bgp term 1 from interface lo0.0 set policy-options policy-statement into-bgp term 1 then accept set routing-options router-id 192.168.9.1 set routing-options autonomous-system 65300
Routeur Nord
set interfaces fe-1/3/1 unit 0 family inet address 10.0.78.14/30 set interfaces fe-1/3/0 unit 0 family inet address 10.0.89.13/30 set interfaces lo0 unit 0 family inet address 192.168.8.1/32 set protocols bgp group toInternet local-address 10.0.89.13 set protocols bgp group toInternet peer-as 65300 set protocols bgp group toInternet neighbor 10.0.89.14 set protocols bgp group toSouth local-address 10.0.78.14 set protocols bgp group toSouth export conditional-export-bgp set protocols bgp group toSouth peer-as 65100 set protocols bgp group toSouth neighbor 10.0.78.13 set policy-options policy-statement conditional-export-bgp term prefix_11 from protocol bgp set policy-options policy-statement conditional-export-bgp term prefix_11 from route-filter 172.16.0.0/16 orlonger set policy-options policy-statement conditional-export-bgp term prefix_11 then accept set policy-options policy-statement conditional-export-bgp term conditional-default from route-filter 0.0.0.0/0 exact set policy-options policy-statement conditional-export-bgp term conditional-default from condition prefix_11 set policy-options policy-statement conditional-export-bgp term conditional-default then accept set policy-options policy-statement conditional-export-bgp term others then reject set policy-options condition prefix_11 if-route-exists 172.16.11.1/32 set policy-options condition prefix_11 if-route-exists table inet.0 set routing-options static route 0/0 reject set routing-options router-id 192.168.8.1 set routing-options autonomous-system 65200
Routeur Sud
set interfaces fe-0/1/2 unit 0 family inet address 10.0.78.13/30 set interfaces lo0 unit 0 family inet address 192.168.7.1/32 set protocols bgp group toNorth local-address 10.0.78.13 set protocols bgp group toNorth import import-selected-routes set protocols bgp group toNorth peer-as 65200 set protocols bgp group toNorth neighbor 10.0.78.14 set policy-options policy-statement import-selected-routes term 1 from neighbor 10.0.78.14 set policy-options policy-statement import-selected-routes term 1 from route-filter 172.16.11.1/32 exact set policy-options policy-statement import-selected-routes term 1 from route-filter 0.0.0.0/0 exact set policy-options policy-statement import-selected-routes term 1 then accept set policy-options policy-statement import-selected-routes term 2 then reject set routing-options router-id 192.168.7.1 set routing-options autonomous-system 65100
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 :
Configurez les interfaces de routeur formant les liens entre les trois routeurs.
Router Internet [edit interfaces] user@Internet# set fe-0/1/3 unit 0 family inet address 10.0.89.14/30
Router North [edit interfaces] user@North# set fe-1/3/1 unit 0 family inet address 10.0.78.14/30 user@North# set fe-1/3/0 unit 0 family inet address 10.0.89.13/30
Router South [edit interfaces] user@South# set fe-0/1/2 unit 0 family inet address 10.0.78.13/30
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.
Router Internet [edit interfaces lo0 unit 0 family inet] user@Internet# set address 172.16.11.1/32 user@Internet# set address 172.16.12.1/32 user@Internet# set address 172.16.13.1/32 user@Internet# set address 172.16.14.1/32 user@Internet# set address 172.16.15.1/32 user@Internet# set address 192.168.9.1/32
Configurez également les adresses de l’interface de bouclage sur les routeurs Nord et Sud.
Router North [edit interfaces lo0 unit 0 family inet] user@North# set address 192.168.8.1/32
Router South [edit interfaces lo0 unit 0 family inet] user@South# set address 192.168.7.1/32
Configurez l’itinéraire statique par défaut sur le routeur Nord à annoncer sur le routeur Sud.
[edit routing-options] user@North# set static route 0/0 reject
Définissez la condition d’exportation des préfixes à partir de la table de routage sur Router North.
[edit policy-options condition prefix_11] user@North# set if-route-exists 172.16.11.1/32 user@North# set if-route-exists table inet.0
Définissez des stratégies d’exportation (
into-bgp
et ) sur les routeurs Internet etconditional-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.Router Internet [edit policy-options policy-statement into-bgp ] user@Internet# set term 1 from interface lo0.0 user@Internet# set term 1 then accept
Router North [edit policy-options policy-statement conditional-export-bgp] user@North# set term prefix_11 from protocol bgp user@North# set term prefix_11 from route-filter 172,16.0.0/16 orlonger user@North# set term prefix_11 then accept user@North# set term conditional-default from route-filter 0.0.0.0/0 exact user@North# set term conditional-default from condition prefix_11 user@North# set term conditional-default then accept user@North# set term others then reject
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.[edit policy-options policy-statement import-selected-routes ] user@South# set term 1 from neighbor 10.0.78.14 user@South# set term 1 from route-filter 172.16.11.1/32 exact user@South# set term 1 from route-filter 0.0.0.0/0 exact user@South# set term 1 then accept user@South# set term 2 then reject
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.
Router Internet [edit protocols bgp group toNorth] user@Internet# set local-address 10.0.89.14 user@Internet# set peer-as 65200 user@Internet# set neighbor 10.0.89.13 user@Internet# set export into-bgp
Router North [edit protocols bgp group toInternet] user@North# set local-address 10.0.89.13 user@North# set peer-as 65300 user@North# set neighbor 10.0.89.14
[edit protocols bgp group toSouth] user@North# set local-address 10.0.78.14 user@North# set peer-as 65100 user@North# set neighbor 10.0.78.13 user@North# set export conditional-export-bgp
Router South [edit protocols bgp group toNorth] user@South# set local-address 10.0.78.13 user@South# set peer-as 65200 user@South# set neighbor 10.0.78.14 user@South# set import import-selected-routes
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.
Router Internet [edit routing options] user@Internet# set router-id 192.168.9.1 user@Internet# set autonomous-system 65300
Router North [edit routing options] user@North# set router-id 192.168.8.1 user@North# set autonomous-system 65200
Router South [edit routing options] user@South# set router-id 192.168.7.1 user@South# set autonomous-system 65100
Résultats
À partir du mode configuration, confirmez votre configuration en exécutant les commandes show interfaces
, show protocols bgp
, 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.
Appareil Internet
user@Internet# show interfaces fe-0/1/3 { unit 0 { family inet { address 10.0.89.14/30; } } } lo0 { unit 0 { family inet { address 172.16.11.1/32; address 172.16.12.1/32; address 172.16.13.1/32; address 172.16.14.1/32; address 172.16.15.1/32; address 192.168.9.1/32; } } }
user@Internet# show protocols bgp group toNorth { local-address 10.0.89.14; export into-bgp; peer-as 65200; neighbor 10.0.89.13; }
user@Internet# show policy-options policy-statement into-bgp { term 1 { from interface lo0.0; then accept; } }
user@Internet# show routing-options router-id 192.168.9.1; autonomous-system 65300;
Nord de l’appareil
user@North# show interfaces fe-1/3/1 { unit 0 { family inet { address 10.0.78.14/30; } } } fe-1/3/0 { unit 0 { family inet { address 10.0.89.13/30; } } } lo0 { unit 0 { family inet { address 192.168.8.1/32; } } }
user@North# show protocols bgp group toInternet { local-address 10.0.89.13; peer-as 65300; neighbor 10.0.89.14; } group toSouth { local-address 10.0.78.14; export conditional-export-bgp; peer-as 65100; neighbor 10.0.78.13; }
user@North# show policy-options policy-statement conditional-export-bgp { term prefix_11 { from { protocol bgp; route-filter 172.16.0.0/16 orlonger; } then accept; } term conditional-default { from { route-filter 0.0.0.0/0 exact; condition prefix_11; } then accept; } term others { then reject; } } condition prefix_11 { if-route-exists { 172.16.11.1/32; table inet.0; } }
user@North# show routing-options static { route 0.0.0.0/0 reject; } router-id 192.168.8.1; autonomous-system 65200;
Appareil Sud
user@South# show interfaces fe-0/1/2 { unit 0 { family inet { address 10.0.78.13/30; } } } lo0 { unit 0 { family inet { address 192.168.7.1/32; } } }
user@South# show protocols bgp bgp { group toNorth { local-address 10.0.78.13; import import-selected-routes; peer-as 65200; neighbor 10.0.78.14; } }
user@South# show policy-options policy-statement import-selected-routes { term 1 { from { neighbor 10.0.78.14; route-filter 172.16.11.1 exact; route-filter 0.0.0.0/0 exact; } then accept; } term 2 { then reject; } }
user@South# show routing-options router-id 192.168.7.1; autonomous-system 65100;
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
- Vérification de l’annonce du préfixe du routeur Internet vers le routeur Nord
- Vérification de l’annonce du préfixe du routeur nord vers le routeur sud
- Vérification de la stratégie d’importation BGP pour l’installation des préfixes
- Vérification de l’exportation conditionnelle du routeur Nord vers le routeur Sud
- Vérification de la présence de routes masquées par la stratégie (facultatif)
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.
Vérifiez la session BGP sur le routeur Internet pour vérifier que le routeur Nord est un voisin.
user@Internet> show bgp neighbor 10.0.89.13 Peer: 10.0.89.13+179 AS 65200 Local: 10.0.89.14+56187 AS 65300 Type: External State: Established Flags: [ImportEval Sync] Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ into-bgp ] Options: [Preference LocalAddress PeerAS Refresh] Local Address: 10.0.89.14 Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 192.168.8.1 Local ID: 192.168.9.1 Active Holdtime: 90 Keepalive Interval: 30 Group index: 0 Peer index: 0 BFD: disabled, down Local Interface: fe-0/1/3.0 NLRI for restart configured on peer: inet-unicast NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Stale routes from peer are kept for: 300 Peer does not support Restarter functionality NLRI that restart is negotiated for: inet-unicast NLRI of received end-of-rib markers: inet-unicast NLRI of all end-of-rib markers sent: inet-unicast Peer supports 4 byte AS extension (peer-as 65200) Peer does not support Addpath Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 0 Accepted prefixes: 0 Suppressed due to damping: 0 Advertised prefixes: 6 Last traffic (seconds): Received 9 Sent 18 Checked 28 Input messages: Total 12 Updates 1 Refreshes 0 Octets 232 Output messages: Total 14 Updates 1 Refreshes 0 Octets 383 Output Queue[0]: 0
Vérifiez la session BGP sur le routeur nord pour vérifier que le routeur Internet est un voisin.
user@North> show bgp neighbor 10.0.89.14 Peer: 10.0.89.14+56187 AS 65300 Local: 10.0.89.13+179 AS 65200 Type: External State: Established Flags: [ImportEval Sync] Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Options: [Preference LocalAddress PeerAS Refresh] Local Address: 10.0.89.13 Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 192.168.9.1 Local ID: 192.168.8.1 Active Holdtime: 90 Keepalive Interval: 30 Group index: 0 Peer index: 0 BFD: disabled, down Local Interface: fe-1/3/0.0 NLRI for restart configured on peer: inet-unicast NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Stale routes from peer are kept for: 300 Peer does not support Restarter functionality NLRI that restart is negotiated for: inet-unicast NLRI of received end-of-rib markers: inet-unicast NLRI of all end-of-rib markers sent: inet-unicast Peer supports 4 byte AS extension (peer-as 65300) Peer does not support Addpath Table inet.0 Bit: 10001 RIB State: BGP restart is complete Send state: in sync Active prefixes: 6 Received prefixes: 6 Accepted prefixes: 6 Suppressed due to damping: 0 Advertised prefixes: 0 Last traffic (seconds): Received 14 Sent 3 Checked 3 Input messages: Total 16 Updates 2 Refreshes 0 Octets 402 Output messages: Total 15 Updates 0 Refreshes 0 Octets 348 Output Queue[0]: 0
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 consultezshow 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
À partir du mode opérationnel sur le routeur Internet, exécutez la
show route advertising-protocol bgp neighbor-address
commande.user@Internet> show route advertising-protocol bgp 10.0.89.13 inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.11.1/32 Self I * 172.16.12.1/32 Self I * 172.16.13.1/32 Self I * 172.16.14.1/32 Self I * 172.16.15.1/32 Self I * 192.168.9.1/32 Self I
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.
À partir du mode opérationnel sur le routeur Nord, exécutez la
show route receive-protocol bgp neighbor-address
commande.user@North> show route receive-protocol bgp 10.0.89.14 inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.11.1/32 10.0.89.14 65300 I * 172.16.12.1/32 10.0.89.14 65300 I * 172.16.13.1/32 10.0.89.14 65300 I * 172.16.14.1/32 10.0.89.14 65300 I * 172.16.15.1/32 10.0.89.14 65300 I * 192.168.9.1/32 10.0.89.14 65300 I
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
À partir du mode opérationnel sur le routeur Nord, exécutez la
show route 0/0 exact
commande.user@North> show route 0/0 exact inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/5] 00:10:22 Reject
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.
À partir du mode opérationnel sur le routeur Nord, exécutez la
show route advertising-protocol bgp neighbor-address
commande.user@North> show route advertising-protocol bgp 10.0.78.13 inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 0.0.0.0/0 Self I * 172.16.11.1/32 Self 65300 I * 172.16.12.1/32 Self 65300 I * 172.16.13.1/32 Self 65300 I * 172.16.14.1/32 Self 65300 I * 172.16.15.1/32 Self 65300 I
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.
user@South> show route receive-protocol bgp 10.0.78.14 inet.0: 10 destinations, 11 routes (6 active, 0 holddown, 4 hidden) Prefix Nexthop MED Lclpref AS path * 0.0.0.0/0 10.0.78.14 65200 I * 172.16.11.1/32 10.0.78.14 65200 65300 I
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
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.
[edit interfaces lo0 unit 0 family inet] user@Internet# deactivate address 172.16.11.1/32 user@Internet# commit
À partir du mode opérationnel sur le routeur Nord, exécutez la
show route advertising-protocol bgp neighbor-address
commande.user@North> show route advertising-protocol bgp 10.0.78.13 inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.12.1/32 Self 65300 I * 172.16.13.1/32 Self 65300 I * 172.16.14.1/32 Self 65300 I * 172.16.15.1/32 Self 65300 I
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.
Réactivez l’adresse 172.16.11.1/32 sur l’interface de bouclage de Device Internet.
[edit interfaces lo0 unit 0 family inet] user@Internet# activate address 172.16.11.1/32 user@Internet# commit
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.
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
hidden
de lashow route receive-protocol bgp neighbor-address
commande.Désactivation de la stratégie d’importation.
À partir du mode opérationnel, exécutez la commande pour afficher les
show route receive-protocol bgp neighbor-address hidden
itinéraires cachés.user@South> show route receive-protocol bgp 10.0.78.14 hidden inet.0: 10 destinations, 11 routes (6 active, 0 holddown, 4 hidden) Prefix Nexthop MED Lclpref AS path 172.16.12.1/32 10.0.78.14 65200 65300 I 172.16.13.1/32 10.0.78.14 65200 65300 I 172.16.14.1/32 10.0.78.14 65200 65300 I 172.16.15.1/32 10.0.78.14 65200 65300 I
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.
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.[edit protocols bgp group toNorth] user@South# deactivate import user@South# commit
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.user@South> show route receive-protocol bgp 10.0.78.14 inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 0.0.0.0/0 10.0.78.14 65200 I * 172.16.11.1/32 10.0.78.14 65200 65300 I * 172.16.12.1/32 10.0.78.14 65200 65300 I * 172.16.13.1/32 10.0.78.14 65200 65300 I * 172.16.14.1/32 10.0.78.14 65200 65300 I * 172.16.15.1/32 10.0.78.14 65200 65300 I
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).
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 etkeep none
au niveau de la[edit protocols bgp group group-name]
hiérarchie.[edit protocols bgp group toNorth] user@South# activate import user@South# set keep none user@South# commit
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’instructionkeep none
.user@South> show route receive-protocol bgp 10.0.78.14 hidden inet.0: 6 destinations, 7 routes (6 active, 0 holddown, 0 hidden)
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
.
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. |