Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Comprendre le redémarrage progressif pour BGP

Comprendre la capacité de redémarrage progressif de BGP à longue durée de vie

Junos OS prend en charge le mécanisme permettant de conserver les détails du routage BGP pendant une période plus longue à partir d’un pair BGP défaillant que la durée pendant laquelle ces informations de routage sont conservées à l’aide de la fonctionnalité de redémarrage progressif BGP.

Historiquement, les protocoles de routage et BGP, en particulier, ont été conçus en mettant l’accent sur l’exactitude, où un aspect important de l'« exactitude » consiste à ce que l’état de transfert de chaque élément du réseau converge vers l’état actuel du réseau le plus rapidement possible. Pour cette raison, le protocole a été conçu pour supprimer l’état annoncé par les routeurs qui tombaient en panne (du point de vue du BGP) aussi rapidement que possible. En utilisant BGP Graceful Restart défini dans la RFC 4724, la fonctionnalité de convergence rapide a été une tentative de supprimer rapidement l’état « obsolète » du réseau.

Au fil du temps, deux facteurs contributifs ont entraîné la modification et l’amélioration de cette méthode d’élimination rapide des états périmés. La première est l’adoption généralisée d’infrastructures de transfert tunnelisées, par exemple MPLS. De telles infrastructures éliminent le risque de certains types de boucles de transfert qui peuvent survenir lors du transfert saut par saut, et réduisent ainsi l’une des raisons d’une forte cohérence entre les éléments de transfert. La seconde est l’utilisation croissante de BGP comme moyen de transport pour des données moins étroitement associées au transfert de paquets que ce n’était le cas à l’origine. Les exemples incluent l’utilisation de BGP pour la découverte automatique (VPLS [RFC4761]) et la programmation de filtres (FLOWSPEC [RFC5575]). Dans ce cas, les données BGP adoptent une caractéristique qui n’est pas conforme au routage traditionnel.

Il était important d’offrir aux opérateurs réseau la possibilité de conserver les données BGP plus longtemps lorsque le plan de contrôle BGP tombe en panne pour une raison ou une autre. Bien que les propriétés du redémarrage progressif BGP soient proches de cette exigence souhaitée pour préserver les informations BGP pendant une durée plus longue, plusieurs lacunes existent, notamment en ce qui concerne le temps maximal pendant lequel les informations « périmées » peuvent être conservées : le redémarrage progressif impose une limite supérieure de 4095 secondes. Junos OS prend en charge une fonctionnalité BGP appelée fonctionnalité de redémarrage gracieux à longue durée de vie, de sorte que les informations obsolètes peuvent être conservées plus longtemps lors d’une réinitialisation de session. Il prend également en charge une nouvelle communauté BGP, « LLGR_STALE », pour marquer ces informations. De telles informations obsolètes doivent être traitées comme les moins préférées, et leur publicité doit être limitée aux locuteurs BGP qui prennent en charge la nouvelle fonctionnalité.

Le redémarrage gracieux à longue durée de vie BGP (LLGR) permet à un opérateur réseau de choisir de conserver les informations de routage périmées d’un pair BGP défaillant beaucoup plus longtemps que la fonction de redémarrage gracieux BGP existante. Cette fonctionnalité permettant de maintenir les routes BGP pendant une période plus longue est conforme au projet de l’IETF, Support for Long-lived BGP Graceful Restart—draft-uttaro-idr-bgp-persistence-03. Selon ce projet, le redémarrage gracieux à longue durée de vie (LLGR) doit être explicitement configuré par NLRI, et il inclut des dispositions pour empêcher la propagation d’informations obsolètes à d’autres pairs qui ne reconnaissent pas et ne valident pas LLGR. Les avantages et opérations suivants sont causés par LLGR :

  • Les routes des nœuds défaillants sont conservées pendant une période configurée (de l’ordre du jour).

  • Vous pouvez examiner les états de négociation LLGR par NLRI à l’aide des commandes show appropriées.

  • Vous pouvez voir si LLGR est actuellement en vigueur pour un homologue et, le cas échéant, la période après laquelle il expire.

  • Les routes périmées conservées par LLGR sont explicitement marquées dans la sortie de la show bgp neighbor commande.

  • Les routes périmées apprises d’autres voisins sont explicitement marquées dans la sortie de la show bgp neighbor commande (en utilisant des communautés bien définies).

Bien que la méthodologie LLGR puisse être appliquée à un certain nombre de scénarios différents, un scénario spécifique est l’objectif principal de cette fonctionnalité. Dans un scénario où une perte de connectivité entre un réflecteur de route et un client se produit, y compris une connectivité intermittente qui peut entraîner la réinitialisation d’une connexion avant que l’ensemble du RIB puisse être transmis, une telle défaillance n’entraîne pas de redémarrage. De plus, un tel phénomène n’implique pas qu’il existe un problème de connectivité entre les clients et les sauts suivants annoncés par le réflecteur de route. On s’attend à ce qu’un temps de redémarrage typique de longue durée soit de l’ordre de 12 heures.

Toutes les directives comportementales et les points opérationnels décrits dans le projet de l’IETF, draft-uttaro-idr-bgp-persistence-03, pour LLGR sont pris en charge. En outre, la compatibilité descendante avec les fonctionnalités existantes de Junos OS dans les versions antérieures à la version 15.1, en particulier le redémarrage normal et le routage ininterrompu (NSR), est prise en charge. Lorsque LLGR est configuré, le redémarrage progressif fonctionne de la manière existante, sauf dans les cas explicitement illustrés dans le brouillon Internet. Vous pouvez également configurer LLGR et NSR en même temps, et obtenir la fonctionnalité LLGR complète. En tant que condition préalable pour LLGR, la prise en charge du brouillon IETF, la prise en charge des messages de notification pour BGP Graceful Restart—draft-ietf- idr-bgp-gr-notification-01, est implémentée. Cette ébauche étend le comportement de GR ordinaire pour lui permettre de protéger contre les interruptions de communications et les erreurs de protocole.

Comprendre la configuration de la période maximale pour la génération automatique de kepalives BGP par les temporisateurs du noyau après le basculement

Sous Junos OS, le routage actif continu (NSR) utilise la même infrastructure que GRES (Graceful Moteur de routage Switchover) pour préserver les informations de l’interface et du noyau. Toutefois, NSR enregistre également les informations de protocole de routage en exécutant le processus de protocole de routage (rpd) sur le moteur de routage de secours. En enregistrant ces informations supplémentaires, NSR est autonome et ne dépend pas de routeurs (ou commutateurs) auxiliaires pour aider la plate-forme de routage à restaurer les informations de protocole de routage. Le NSR est avantageux sur les réseaux où les routeurs (ou commutateurs) voisins ne prennent pas en charge les extensions de protocole de redémarrage dynamiques. En raison de cette fonctionnalité améliorée, NSR est un remplacement naturel pour le redémarrage progressif.

La fusion automatique de routage actif non-stop est l’un des composants du noyau de la réplication de sockets. Lors du basculement, ce composant fusionne automatiquement les paires de sockets du moteur de routage de secours vers le principal. Le basculement NSR de la sauvegarde vers la prise principale se produit lorsque rpd émet un appel de fusion pour chaque paire de sockets secondaires afin de les fusionner en une seule socket, ce qui peut entraîner un retard. Pour éviter ce délai, un module automerge dans le noyau dissocie la fusion de sockets secondaires de rpd et fusionne automatiquement les sockets secondaires lors du basculement afin que le thread de haute priorité rpd en profite et génère un keepalive plus rapide pour maintenir les connexions TCP lors du basculement.

Par défaut, BGP ne s’enregistre pas pour le service de génération automatique de keepalive fourni par le noyau juste après l’événement de basculement de la sauvegarde à la sauvegarde. Pour cela, vous devez activer l’instruction au niveau de la nonstop-routing-options hiérarchie [edit routing-options] et configurer les temporisateurs de précision dans BGP. La configuration de temporisateurs de précision dans BGP permet à BGP d’enregistrer toutes ses sessions auprès du service de génération automatique de keepalive fourni par le noyau. Une fois enregistré, le noyau génère automatiquement des keepalives à l’aide de ses temporisateurs pour le compte de BGP pour ses sessions de contrôle juste après l’événement de basculement de la sauvegarde à la primaire. Cela permet de générer des keepalives plus fiables pour les sessions de contrôle avec de très petits minuteurs pendant l’événement de basculement.

Interopérabilité des fonctionnalités avec BGP Long Lived Graceful Restart

Cette rubrique contient les sections suivantes qui décrivent le comportement de fonctionnement de différentes fonctionnalités avec le redémarrage gracieux de longue durée BGP et les différentes conditions du système :

À partir de Junos OS version 15.1, Junos OS prend en charge le mécanisme permettant de conserver les détails du routage BGP pendant une période plus longue à partir d’un homologue pair BGP défaillant que la durée pendant laquelle ces informations de routage sont conservées à l’aide de la fonctionnalité de redémarrage progressif BGP.

Limitations des NLRI pris en charge

La configuration LLGR et la négociation des capacités sont prises en charge pour les familles d’informations d’accessibilité de la couche réseau (NLRI) BGP suivantes :

  • L2VPN

  • inet étiqueté-unicast

  • Flux d’inet

  • cible_route

  • unicast inet-vpn

  • flux inet-vpn

  • Inet6-VPN unicast

La négociation de la configuration et des capacités LLGR est empêchée pour les familles suivantes :

  • inet-mvpn

  • inet6-mvpn

  • inet-mdt

Pour les familles NLRI pour lesquelles la fonctionnalité LLGR est empêchée, cela indique qu’une tentative de validation d’une configuration qui inclut une configuration LLGR pour ces familles est rejetée et que ces paramètres ne sont pas enregistrés. Les NLRI associés à ces familles ne sont pas inclus dans une annonce de capacités LLGR et ne sont pas pris en compte dans une annonce de capacités LLGR reçue.

La configuration LLGR et la négociation des capacités sont autorisées, mais masquées, pour les autres familles.

Mode de redémarrage LLGR sous NSR

Lorsque NSR et LLGR sont configurés ensemble, le routeur négocie la capacité LLGR de la manière habituelle et régulière, y compris un temps d’expiration de longue durée pour déclencher le mode récepteur LLGR dans ses homologues. Cependant, la fonctionnalité complète de redémarrage LLGR (retardant la transmission des marqueurs de fin de RIB jusqu’à ce que les EoR soient reçus de tous les pairs) ne fonctionne pas sous NSR. Lors d’un redémarrage complet du système (les deux moteurs de routage), le démon du protocole de routage (rpd) n’attend pas les EoR d’autres homologues avant d’envoyer son propre EoR. Il transmet l’EoR dès qu’il a transmis le contenu actuel du RIB. Cette condition peut entraîner des pannes temporaires lorsque le réseau converge à nouveau. NSR est considéré comme adéquat pour gérer tous les scénarios de redémarrage du moteur de routage unique. La restriction du mode de redémarrage n’affecte que les scénarios où les deux moteurs de routage (ou les deux copies de rpd) redémarrent simultanément. La configuration du mode de redémarrage ordinaire n’est pas activée avec NSR.

La configuration ordinaire du mode de redémarrage progressif n’est toujours pas prise en charge avec NSR.

Capacité LLGR au niveau global, du groupe BGP et du voisin BGP

Le mode récepteur de redémarrage progressif de longue durée est activé par défaut, sauf si le mode de récepteur de redémarrage progressif ordinaire est désactivé. Pour activer la fonctionnalité de redémarrage gracieux de longue durée (LLGR) BGP, incluez l’instruction long-lived receiver enable au niveau de la [edit protocols bgp graceful-restart] hiérarchie. Outre l’activation de BGP LLGR au niveau global ou à l’échelle du système, vous pouvez également inclure l’instruction long-lived receiver enable au niveau de la hiérarchie [edit protocols bgp group group-name graceful- restart] pour configurer le LLGR pour un groupe BGP particulier et au niveau de la [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] hiérarchie pour configurer le LLGR pour un voisin BGP particulier. Pour désactiver le mécanisme BGP LLGR, incluez long-lived receiver disable l’option [edit protocols bgp graceful-restart],[edit protocols bgp group group-name graceful-restart] ou [edit protocols bgp group-name-name neighbor neighbor-address graceful-restart] niveau hiérarchique. La désactivation de LLGR désactive toutes les fonctionnalités LLGR (modes récepteur et redémarrage) pour toutes les familles NLRI. Cette propriété est héritée par les groupes de la configuration globale et par les voisins de la configuration de groupe.

Surveillance et administration du redémarrage progressif de longue durée BGP

Cette rubrique décrit les commandes opérationnelles et leur importance pour vous permettre d’analyser et d’afficher les paramètres liés au redémarrage gracieux de longue durée BGP. Vous pouvez analyser les compteurs statistiques et les métriques liés à toute perte de trafic et prendre une mesure corrective appropriée. Les champs affichés dans la sortie des commandes show aident à diagnostiquer et à déboguer les problèmes de performances réseau et d’efficacité de gestion du trafic.

Le clear bgp neighbor neighbor-address stale-routes provoque toutes les routes périmées actuellement retenues pour le voisin spécifié en raison d’opérations en mode récepteur GR (Graceful Restart) ou LLGR (Long Lived Graceful Restart). La clear bgp neighbor neighbor-address gracefully commande est la même que clear bgp neighbor hard (la valeur par défaut pour clear bgp neighbor), mais elle n’utilise pas le nouveau sous-code de réinitialisation matérielle sur les messages Notifier et Cesser qui sont envoyés. Cela permet au voisin d’entrer en mode d’assistance GR ou LLGR, s’il est négocié. La session est toujours effacée sur ce routeur et ce routeur n’entre pas en mode d’assistance GR ou LLGR.

Une commande cachée clear est disponible ajoutée pour la fonctionnalité de redémarrage gracieux de longue durée de BGP à des fins de débogage :

clear bgp neighbor neighbor-address socket.

Cette commande interrompt la connexion TCP pour une session d’appairage établie. C’est la seule implication directe de la commande et toutes les autres implications sont des effets secondaires de la rupture de la connexion. L’effet résultant est que (à moins que les extensions de notification GR n’aient été désactivées) les deux côtés de la connexion passeront en mode d’assistance GR ou LLGR, s’ils sont négociés, et la connexion TCP sera rétablie.

La sortie de la show bgp neighbor commande est améliorée pour afficher les informations supplémentaires suivantes :

  • L’option de redémarrage progressif et de longue durée

  • Les paramètres LLGR que l’homologue a négociés

  • Les paramètres LLGR que le routeur de redémarrage a négociés

  • Les heures sont affichées au format %#0T du démon de protocole de routage (rpd) :

    <weeks>w<days>d <hours>:<minutes>:<seconds>

    Les éléments de début zéro sont omis, par exemple, une valeur inférieure à une semaine n’inclut pas les semaines.

Si le redémarrage normal de longue durée est complètement désactivé pour un voisin, ce qui suit s’affiche :

Si un voisin ne prend pas entièrement en charge LLGR, ce qui suit s’affiche :

Lorsque le mode récepteur LLGR est actif (un homologue qui a négocié LLGR s’est déconnecté et n’est pas encore reconnecté), la sortie de la show bgp neighbor commande affiche le temps restant jusqu’à l’expiration du LLGR, le temps restant sur le temporisateur périmé GR et les détails du RIB :

Lorsque le mode récepteur de redémarrage gracieux BGP est actif pour un voisin, des informations supplémentaires s’affichent dans la sortie de la show bgp neighbor commande. Ces détails incluent la liste des NLRI pour lesquels les routes périmées sont conservées (NLRI, nous conservons les routes périmées pour le champ), le temps restant sur le temporisateur de redémarrage (Temps jusqu’à ce que les routes périmées soient supprimées ou deviennent un champ périmé à longue durée de vie), le temps restant sur le temporisateur périmé (Temps jusqu’à ce que la fin de la nervure soit supposée pour les routes périmées) et les détails du RIB. L’heure est affichée au format Temps universel coordonné (UTC) (AAAA-MM-JJ-HH :MM :SS). Notez que l’affichage du minuteur périmé ('Temps jusqu’à ce que la fin de la nervure soit supposée') est également présent lorsqu’une session est active, mais que le voisin n’a pas encore envoyé toutes les indications de fin de nervure.

Lorsque le mode de redémarrage normal ou le mode d’assistance LLGR est actif, les informations RIB sont désormais affichées par la show bgp summary commande. Si une session BGP est établie sur l’unité de routage principale, le champ indique le nombre de routes actives, reçues, acceptées et amorties qui sont reçues d’un voisin et apparaissent dans les tables de routage inet.0 (main) et inet.2 (multicast). Par exemple, 8/10/10/2 et 2/4/4/0 indiquent ce qui suit :

  • 8 routes actives, 10 routes reçues, 10 routes acceptées et 2 routes amorties provenant d’un pair BGP pair apparaissent dans la table de routage inet.0.

  • 2 routes actives, 4 routes reçues, 4 routes acceptées et aucune route amortie provenant d’un pair BGP pair apparaissent dans la table de routage inet.2.

La show route detail commande (avec et sans l’option) est améliorée pour identifier les routes qui sont maintenues dans l’état receive-protocol bgp périmé de longue durée. L’indicateur LongLivedStale indique que la route a été marquée LLGR-stale par ce routeur, dans le cadre du fonctionnement du mode récepteur LLGR. L’indicateur LongLivedStaleImport indique que la route a été marquée LLGR-stale lorsqu’elle a été reçue d’un homologue ou par une stratégie d’importation. L’un ou l’autre de ces indicateurs, ou les deux, peuvent être affichés pour un itinéraire. Ni l’un ni l’autre de ces drapeaux ne sera affiché en même temps que le drapeau Stale (GR ordinaire périmé). Lorsqu’une route est dépréférencée parce qu’elle est obsolète depuis longtemps, le champ Motif inactif de la sortie de la commande show route detail affiche LLGR obsolète. Le nouveau motif d’inactivité obsolète LLGR s’inscrit dans la hiérarchie de sélection d’itinéraire entre Préférence et Préférence locale.

Conseil :

Selon le Centre d’assistance technique de Juniper (JTAC), la commande est une commande utile pour aider à résoudre les show route table bgp.l2vpn.0 detail hidden problèmes liés au redémarrage normal de longue durée de BGP. La sortie de la commande vous aide à détecter si les routes BGP existent toujours après la fin de la session BGP. L’utilisation de cette hidden option vous permet de voir les itinéraires pendant et après un incident, et de découvrir des informations expliquant pourquoi les itinéraires sont masqués. D’autres indices vous aident à résoudre ce scénario incluent l’apparition d’entrées de journal BGP obsolètes (telles que bgp_mark_route_stale) et l’affichage de routes masquées dans la sortie de la show bgp summary commande.

Augmentation de la durée de conservation des routes BGP sur des homologues à redémarrage lent par redémarrage progressif BGP

Junos OS prend en charge le mécanisme permettant de conserver les détails du routage BGP pendant une période plus longue à partir d’un pair BGP défaillant que la durée pendant laquelle ces informations de routage sont conservées à l’aide de la fonctionnalité de redémarrage progressif BGP.

Le mode récepteur de redémarrage progressif de longue durée est activé par défaut, sauf si le mode de récepteur de redémarrage progressif ordinaire est désactivé. Pour activer la fonctionnalité de redémarrage gracieux de longue durée (LLGR) BGP, incluez l’instruction long-lived receiver enable au niveau de la [edit protocols bgp graceful-restart] hiérarchie. Outre l’activation de BGP LLGR au niveau global ou à l’échelle du système, vous pouvez également inclure l’instruction long-lived receiver enable au niveau de la [edit protocols bgp group group-name graceful-restart] hiérarchie pour configurer le LLGR pour un groupe BGP particulier et au niveau de la [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] hiérarchie pour configurer le LLGR pour un voisin BGP particulier. Pour désactiver le mécanisme BGP LLGR, incluez long-lived receiver disable l’option [edit protocols bgp graceful-restart], [edit protocols bgp group group-name graceful-restart] ou [edit protocols bgp group-name-name neighbor neighbor-address graceful-restart] niveau hiérarchique. La désactivation de LLGR désactive toutes les fonctionnalités LLGR (modes récepteur et redémarrage) pour toutes les familles NLRI. Cette propriété est héritée par les groupes de la configuration globale et par les voisins de la configuration de groupe.

Les voisins BGP peuvent être configurés aux niveaux hiérarchiques suivants :

  • [edit protocols bgp group group-name]: système logique par défaut et instance de routage par défaut.

  • [edit routing-instances instance-name protocols bgp group group-name]: système logique par défaut avec une instance de routage spécifiée.

  • [edit logical-systems logical-system-name protocols bgp group group-name]: système logique configuré et instance de routage par défaut.

  • [edit logical-systems logical-system-name routing-instances instance-name protocols bgp group group-name]: système logique configuré avec une instance de routage spécifiée.

Le long-lived receiver enable remplace une option de désactivation héritée d’un niveau supérieur dans la configuration. Il n’active pas le mode de redémarrage progressif de longue durée pour toutes les familles : le mode de redémarrage doit être configuré explicitement pour chaque famille.

Pour permettre aux routes obsolètes LLGR d’être annoncées aux voisins qui n’annoncent pas la capacité LLGR, incluez l’instruction advertise-to-non-llgr-neighbor au niveau [edit protocols bgp graceful-restart long-lived], [edit protocols bgp group group-name graceful-restart long-lived]ou [edit protocols bgp group group-name neighbor neighbor-address graceful-restart long-lived] de la hiérarchie. Ce paramètre s’applique à la fois aux routes qui ont été marquées LLGR-stale par ce routeur et aux routes LLGR-stale reçues des voisins. Idéalement, tous les routeurs d’un système autonome prennent en charge le projet de spécification IETF avant qu’elle ne soit activée. Toutefois, pour faciliter le déploiement incrémentiel, il peut être nécessaire d’annoncer les routes obsolètes aux voisins qui n’ont pas annoncé la capacité de redémarrage normal de longue durée dans les conditions suivantes : Les voisins doivent être des voisins internes (IBGP ou Confédération). La communauté NO_EXPORT doit être rattachée aux routes périmées. L’attribut LOCAL_PREF des routes périmées doit être défini sur zéro. Si cette technique de déploiement partiel est utilisée, vous devez mettre LOCAL_PREF à zéro pour toutes les routes LLGR dans l’ensemble du système autonome. Cette configuration compense une légère réduction de la flexibilité (l’ordre peut ne pas être conservé entre les routes LLGR concurrentes) pour la cohérence entre les routeurs qui prennent en charge et ne prennent pas en charge cette spécification. Étant donné que la cohérence de la sélection de route peut être importante pour éviter les boucles de transfert, la dernière prise en compte des routeurs qui ne prennent pas en charge cette spécification précède.

Pour éviter que la communauté BGP sans exportation ne soit automatiquement ajoutée aux routes annoncées vers des voisins BGP externes (présumés être des routeurs CE), incluez l’instruction omit- no-export au niveau [edit protocols bgp graceful-restart long-lived], [edit protocols bgp group group-name graceful-restart long-lived] ou [edit protocols bgp group group-name neighbor neighbor-address graceful-restart long-lived] de la hiérarchie. Dans les déploiements VPN, par exemple, BGP est souvent utilisé comme protocole PE-CE. Dans de tels déploiements, il peut s’avérer nécessaire d’assurer l’interopérabilité avec des systèmes d’enseignement supérieur qui ne peuvent pas être facilement mis à niveau pour prendre en charge des spécifications telles que celle-ci. Cette exigence pose un problème tout en garantissant que les informations de routage « périmées » ne s’échappent pas au-delà du périmètre des routeurs qui prennent en charge ces procédures lorsqu’un ou plusieurs routeurs IBGP ne sont pas mis à niveau. Dans le cas du VPN PE-CE, le protocole utilisé est EBGP et le LOCAL_PREF, un attribut de chemin IBGP uniquement, est utilisé. La principale motivation pour restreindre la propagation de l’information de routage « périmée » est la raison pour l’empêcher de se propager sans limite une fois qu’elle a quitté la frontière de la confédération BGP. Les déploiements de VPN sont généralement soumis à des contraintes topologiques, ce qui élimine ce problème. Pour cette raison, une implémentation peut annoncer des routes obsolètes sur une session PE-CE, lorsqu’elle est configurée explicitement. Dans un tel scénario, l’implémentation doit attacher la communauté NO_EXPORT aux routes en question par défaut, comme une protection supplémentaire contre les routes obsolètes qui se propagent sans limite. L’attachement de la communauté NO_EXPORT peut être désactivé explicitement pour tenir compte de cas exceptionnels. Il peut être nécessaire d’annoncer des routes obsolètes vers un CE dans certains déploiements VPN, même si le CE ne prend pas en charge cette spécification. Dans ce cas, si vous configurez les routeurs PE pour annoncer de telles routes, vous devez en informer l’opérateur du CE qui reçoit les routes, et le CE doit être configuré pour déréférencer les routes. Les implémentations BGP classiques effectuent cette opération en effectuant une mise en correspondance sur la communauté LLGR_STALE et en définissant la LOCAL_PREF des routes correspondantes sur zéro.

Lorsque le mode récepteur LLGR est activé ou désactivé, la session est réinitialisée. Ce comportement permet d’envoyer la nouvelle valeur de fonctionnalité au voisin. Lorsque l’option est activée ou désactivée, la stratégie d’exportation advertise-to-non-llgr-neighbor est réévaluée et les routes obsolètes LLGR peuvent être annoncées ou supprimées. Lorsque l’option omit-no-export est ajoutée ou supprimée, la session est réinitialisée. Ce repos de session permet aux routes obsolètes LLGR d’être réannoncées avec ou sans la communauté no- export (qui est ajoutée en dehors de la stratégie d’exportation).

Pour activer la fonctionnalité de redémarrage gracieux de longue durée de BGP au niveau système ou global et configurer ses propriétés :

Pour activer la fonctionnalité de redémarrage gracieux de longue durée BGP au niveau du groupe BGP et configurer ses propriétés, procédez comme suit :

Pour activer la fonctionnalité de redémarrage gracieux de longue durée de BGP au niveau du voisin ou du groupe d’homologues et configurer ses propriétés :

Configuration des communautés de redémarrage progressif à longue durée de vie BGP dans les stratégies de routage

Junos OS prend en charge le mécanisme permettant de conserver les détails du routage BGP pendant une période plus longue à partir d’un pair BGP défaillant que la durée pendant laquelle ces informations de routage sont conservées à l’aide de la fonctionnalité de redémarrage progressif BGP.

Deux nouvelles communautés bien connues sont introduites. Ces nouvelles communautés BGP peuvent être utilisées à n’importe quel niveau de la hiérarchie de configuration en tant que communautés symboliques bien connues (par exemple, no-advertise, no-export et no-export-subconfed) dans l’attribut community des définitions de route statiques ou dans une définition de communauté policy-options. Les deux nouvelles communautés sont les suivantes :

  • llgr-stale: ajoute une communauté à un itinéraire périmé de longue durée lorsqu’il est réannoncé.

  • no-llgr—Marque les routes qu’un interlocuteur BGP ne souhaite pas conserver par LLGR. Aucun paramètre de configuration n’est associé à la fonctionnalité Message de notification.

Vous pouvez inclure les options llgr-stale et no-llgr avec l’instruction community name members pour associer les informations de communauté BGP à une route statique, agrégée ou générée aux niveaux hiérarchiques suivants :

Pour configurer les communautés de redémarrage gracieux de longue durée BGP à utiliser dans une condition de correspondance de stratégie de routage :

La configuration de LLGR ne nécessite pas que le redémarrage normal BGP soit également configuré. Les valeurs pour les communautés bien connues llgr-stale et no-llgr sont respectivement 0xFFFF0006 et 0xFFFF0007. Les privilèges sont les mêmes que pour les protocoles bgp. La section long-lived-graceful-restart n’est visible que pour les familles l2vpn, inet labeled-unicast, inet flow et route-target. Il est interdit pour inet-mvpn, inet6-mvpn et inet-mdt. Il est caché pour les autres familles.

Junos OS prend également en charge la configuration d’une stratégie d’exportation BGP correspondant à l’état d’une route pour le redémarrage gracieux de longue durée BGP. Vous pouvez associer la communauté que vous avez précédemment définie et une liste de préfixes d’adresses dans une stratégie de routage pour accepter ou rejeter de manière sélective les routes pour un redémarrage normal de longue durée pour les préfixes spécifiés, comme suit :

Deux instructions de configuration masquées sont ajoutées sous le niveau hiérarchique ] pour la [edit protocols bgp graceful-restartconfiguration globale, au niveau du groupe et au niveau du groupe voisin.

L’instruction disable-notification-flag au niveau [edit protocols bgp graceful-restart], [edit protocols bgp group group-name graceful-restart] ou [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] de la hiérarchie désactive la transmission de l’indicateur N dans la négociation de la capacité de redémarrage progressif. L’instruction disable-notification-extensions au niveau [edit protocols bgp graceful-restart], [edit protocols bgp group group-name graceful-restart] ou [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] de la hiérarchie désactive également la transmission de l’indicateur N dans la négociation de la capacité de redémarrage progressif, mais en outre, elle désactive les nouvelles règles d’appel du mode récepteur de redémarrage progressif comme spécifié dans le brouillon de notification bgp-gr de l’IETF, et désactive la transmission du sous-code de réinitialisation matérielle. Le sous-code de réinitialisation matérielle continue d’être observé lorsqu’il est reçu dans un message de notification ou de cessation.

Pour désactiver la transmission de N drapeaux et pour désactiver les règles de déclenchement du redémarrage progressif au niveau global ou à l’échelle du système :

Pour désactiver la transmission de N drapeaux et pour désactiver les règles de déclenchement du redémarrage progressif au niveau du groupe :

Pour désactiver la transmission de N drapeaux et pour désactiver les règles de déclenchement du redémarrage progressif au niveau du voisin ou de l’homologue :

Configuration d’une négociation en mode de redémarrage normal de longue durée pour une famille d’adresses spécifique dans les systèmes logiques et les instances de routage

Junos OS prend en charge le mécanisme permettant de conserver les détails du routage BGP pendant une période plus longue à partir d’un pair BGP défaillant que la durée pendant laquelle ces informations de routage sont conservées à l’aide de la fonctionnalité de redémarrage progressif BGP.

Vous pouvez également configurer le mécanisme de négociation du mode de redémarrage gracieux BGP de longue durée pour une famille d’adresses particulière au lieu de configurer cette fonctionnalité pour toutes les familles d’adresses d’un système, d’un système logique ou d’une instance de routage. Pour activer BGP LLGR pour une famille d’adresses spécifique, incluez l’instruction à l’un graceful-restart long-lived restarter stale-time interval des niveaux hiérarchiques suivants.

Chaque table de routage est identifiée par la famille de protocoles ou l’indicateur de famille d’adresses (AFI) et un identifiant de famille d’adresses ultérieur (SAFI). Le paramètre AFI peut être l’un des protocoles (l2vpn | inet | route-target) et le paramètre SAFI peut être l’un des protocoles (flow | labeled-unicast) de la famille inet et l’un des protocoles (auto-discovery-mspw | auto-discovery-only | signaling) de la famille L2VPN.

La configuration de LLGR ne nécessite pas que le redémarrage normal BGP soit également configuré. La section long-lived-graceful-restart n’est visible que pour les familles l2vpn, inet labeled-unicast, inet flow et route-target. Il est interdit pour inet-mvpn, inet6-mvpn et inet-mdt. Il est caché pour les autres familles.

Les strophes de la section de configuration du redémarrage gracieux et de longue durée par famille permettent la négociation du mode de redémarrage LLGR pour BGP globalement, ou pour un groupe ou un voisin. Les valeurs sont héritées par les groupes de la configuration globale et par les voisins de la configuration de groupe. L’attribut disable permet de remplacer la configuration héritée d’un niveau supérieur. Il ne désactive pas le mode récepteur LLGR ; vous devez désactiver explicitement le mode récepteur LLGR pour toutes les familles si nécessaire. Un attribut hidden enable peut être utilisé pour remplacer un attribut de désactivation hérité. La configuration d’un redémarrage gracieux et de longue durée au niveau du voisin (lorsqu’il n’est pas configuré au niveau du groupe conteneur ou globalement) entraîne la division d’un groupe interne. Lorsque le redémarrage LLGR est activé ou désactivé pour une famille ou que l’heure d’expiration est modifiée, la session est réinitialisée afin que la nouvelle fonctionnalité puisse être envoyée au voisin.

La plage de valeurs pour le temps d’immobilisation est de 1 à 16777215 (2^24 – 1) secondes. La valeur est un entier simple donnant le nombre de secondes par défaut, mais elle peut également être spécifiée à l’aide de la notation suivante :

[&lt;semaines>w] [&lt;jours>d] [&lt;heures>h] [&lt; minutes>h] [&lt;secondes>s] Par exemple, vous pouvez spécifier 27 jours comme 27j, 648h, 38880m ou 2332800s. 90 minutes peuvent être configurées comme 1h30m, 90m ou 5400s. Le nombre de jours spécifié est multiplié par 86400, le nombre d’heures par 3600 et le nombre de minutes par 60 ; Ceux-ci sont ajoutés aux secondes pour obtenir le total. Un format combiné de jours et d’heures, dans différentes unités de temps, telles que 1d36h est autorisé, tant que le total spécifié ne dépasse pas le temps périmé maximal.

De plus, les heures peuvent également être configurées à l’aide de la notation suivante : &lt;heures> :&lt;minutes> :&lt;secondes> Par exemple, 12 :00 :00 spécifie douze heures. Les heures et les minutes sont facultatives.

Les deux notations peuvent être combinées, par exemple, 2w1d 12 :00 :02 spécifie deux semaines, un jour, douze heures et deux secondes (1339202 secondes). (Notez que l’interface de ligne de commande exige des guillemets doubles autour d’une valeur comme celle-ci avec des espaces.) Exprimé dans cette notation, le temps périmé maximal est de 27w5d 04 :20 :15 (27 semaines, 5 jours, 4 heures, 20 minutes et 15 secondes). Alors que la commande show configuration affiche les valeurs réellement configurées, lorsque les temporisateurs associés sont affichés dans des commandes d’exécution show telles que show bgp neighbor, les valeurs sont normalisées, par exemple 1d36h devenant 2d 12 :00 :00. Les règles complètes d’affichage des heures LLGR normalisées dépendent de la configuration de la clear bgp neighbor neighbor-address gracefully commande.

Pour configurer les caractéristiques de redémarrage gracieux de longue durée BGP par famille d’adresses et par famille d’adresses suivantes au niveau global d’un système logique ou d’une instance de routage :

Configuration du redémarrage gracieux de longue durée BGP par famille d’adresses au niveau global pour les systèmes logiques

Configuration du redémarrage gracieux de longue durée BGP par famille d’adresses au niveau global pour les instances de routage

Pour configurer les caractéristiques de redémarrage gracieux de longue durée BGP par famille d’adresses et par famille d’adresses subséquente au niveau du groupe BGP pour un système logique ou une instance de routage :

Configuration du redémarrage gracieux de longue durée BGP par famille d’adresses au niveau du groupe BGP pour les systèmes logiques

Configuration du redémarrage gracieux de longue durée BGP par famille d’adresses au niveau du groupe BGP pour les instances de routage

Pour configurer les caractéristiques de redémarrage gracieux de longue durée BGP par famille d’adresses et par famille d’adresses ultérieures au niveau du groupe voisin BGP pour un système logique ou une instance de routage :

Configuration du redémarrage gracieux de longue durée BGP par famille d’adresses au niveau du groupe voisin BGP pour les systèmes logiques

Configuration du redémarrage gracieux de longue durée BGP par famille d’adresses au niveau du groupe voisin BGP pour les instances de routage

Informer le routeur d’assistance BGP ou l’homologue de la conservation des routes en configurant le bit d’état de transfert pour toutes les familles d’adresses et pour une famille d’adresses spécifique

Junos OS prend en charge le mécanisme permettant de conserver les détails du routage BGP pendant une période plus longue à partir d’un pair BGP défaillant que la durée pendant laquelle ces informations de routage sont conservées à l’aide de la fonctionnalité de redémarrage progressif BGP.

Après la défaillance d’une session BGP et avant que la session ne soit rétablie, les routes obsolètes peuvent être conservées pendant deux périodes consécutives maximum, contrôlées respectivement par les paramètres de temps de redémarrage et de temps périmé de longue durée. Au cours de la première période, les modifications de routage sont empêchées, mais avec un filtrage potentiellement nul du trafic. Au cours de la deuxième période, le filtrage éventuel du trafic via des routes nulles peut être réduit, mais les modifications de routage sont visibles sur l’ensemble du réseau. Dans votre environnement réseau, le réglage des paramètres pertinents pour une application particulière doit tenir compte des compromis, de la dynamique du réseau et des scénarios de défaillance potentiels. Si nécessaire, la première période peut être contournée soit par la configuration locale, soit en définissant le temps de redémarrage dans la fonctionnalité de redémarrage progressif sur zéro, sans répertorier les indicateurs de famille d’adresses (AFI) et les identificateurs de famille d’adresses suivants (SAFI) dans cette fonctionnalité.

Le réglage du bit F (et du bit « État de transfert » de la capacité GR qui l’accompagne) dépend en partie de considérations de déploiement. Le bit F peut être interprété comme indiquant que le routeur d’assistance doit vider les routes associées (si le bit est laissé libre). Un scénario important dans lequel LLGR est utilisé est pour les routes qui sont plus similaires à la configuration qu’au routage traditionnel (transfert saut par saut au lieu du routage basé sur un tunnel). Pour de telles routes, il peut être utile de toujours définir le bit F, indépendamment d’autres considérations. De même, pour les entités de plan de contrôle uniquement, telles que les réflecteurs de route dédiés, qui ne participent pas au plan de transfert, il est préférable que le bit F soit toujours défini. Dans l’ensemble, la ligne directrice à adopter est la suivante : si l’on peut raisonnablement s’attendre à ce que la perte d’état sur le routeur qui redémarre provoque une boucle de transfert ou une route nulle, le bit F doit être réglé judicieusement, selon que l’état a été conservé ou non. Vous pouvez déterminer si le bit F doit être défini ou non, en fonction de vos besoins de déploiement et des paramètres configurés. Il peut être nécessaire d’annoncer des routes obsolètes vers un CE dans certains déploiements VPN, même si le CE ne prend pas en charge cette spécification. Dans un tel scénario, l’opérateur de réseau qui configure son PE pour annoncer ces routes doit informer l’opérateur de la réception des routes par le CE et le CE doit être configuré pour déréférencer les routes. En règle générale, les implémentations BGP effectuent ce comportement en effectuant des correspondances sur la communauté LLGR_STALE et en définissant à zéro les LOCAL_PREF des routes correspondantes.

Vous pouvez spécifier le bit d’état de transfert, qui est une option de configuration BGP qui peut être définie aux niveaux global, de groupe et de voisinage, pour n’importe quel système logique ou instance de routage. Pour spécifier le bit d’état de transfert au niveau global, du groupe BGP ou du voisin BGP, incluez l’instruction forwarding-state-bit (as-rr-client | from-fib) au niveau [edit protocols bgp graceful-restart], [edit protocols bgp group-group-name graceful-restart]ou [edit protocols bgp group-group-name neighbor neighbor-address graceful-restart] hiérarchique. L’attribut forwarding-state-bit contrôle la façon dont le bit d’état de transfert est défini dans les annonces de fonctionnalité de redémarrage gracieux et de redémarrage gracieux de longue durée. Par défaut, la valeur varie selon que le voisin est un client de réflecteur de route. Si le voisin n’est pas un client de réflecteur de route, la valeur est définie en fonction de l’état de la FIB associée conformément à la RFC 4724. Si le voisin est un client de réflecteur de route, la valeur est définie sur 1 pour toutes les familles, à l’exception de inet unicast et inet6 unicast, qui utilisent l’état de la FIB associée. L’option as-rr-client définit le comportement de toutes les familles d’adresses pour qu’il soit identique à celui d’un client de réflecteur de route. L’option from-fib force le comportement de toutes les familles d’adresses à être le même qu’il le serait pour un client non-réflecteur de route.

Pour configurer la négociation de l’indicateur d’état de transfert au niveau global :

Pour configurer la négociation de l’indicateur d’état de transfert au niveau du groupe :

Pour configurer la négociation de l’indicateur d’état de transfert au niveau du voisin ou du groupe d’homologues, procédez comme suit :

En plus du paramètre global pour le bit d’état de transfert, le comportement du bit d’état de transfert peut être spécifié pour des familles individuelles. La modification du paramètre forwarding-state-bit n’a aucun effet sur les sessions existantes. Pour spécifier le bit d’état de transfert pour une famille d’adresses particulière, incluez l’instruction forwarding-state-bit (set | from-fib) au niveau [edit protocols bgp graceful-restart family address-family subsequent-address-family], [edit protocols bgp group-group-name graceful-restart family address-family subsequent-address-family]ou [edit protocols bgp group-group-name neighbor neighbor-address graceful-restart family address-family subsequent-address-family] hiérarchique sur un système logique et une instance de routage. Des options de configuration BGP par famille ont été ajoutées pour contrôler le bit d’état de transfert dans les annonces de capacité de redémarrage gracieux et de redémarrage gracieux de longue durée. Ils peuvent être spécifiés pour le système logique par défaut ou pour un système logique spécifique, ainsi que pour l’instance de routage principale ou une instance de routage spécifique. L’attribut per-family forwarding-state-bit remplace les règles par défaut ou la configuration globale pour définir le bit d’état de transfert. L’option set force le bit d’état de transfert à être défini sur 1. L’option from-fib permet de définir la valeur en fonction de l’état de la FIB associée. La modification du paramètre de bits d’état de transfert par famille n’a aucun effet sur les sessions existantes.

Voici les niveaux de hiérarchie de configuration complets auxquels vous pouvez inclure l’instruction pour configurer le bit d’état de transfert par famille d’adresses forwarding-state-bit (set | from-fib) :

Pour configurer le bit d’état de transfert pour le redémarrage gracieux de longue durée BGP par famille d’adresses et par famille d’adresses ultérieure au niveau global d’un système logique ou d’une instance de routage :

Configuration du bit d’état de transfert par famille d’adresses au niveau global pour les systèmes logiques

Configuration du bit d’état de transfert par famille d’adresses au niveau global pour les instances de routage

Pour configurer le bit d’état de transfert pour le redémarrage gracieux de longue durée BGP par famille d’adresses et par famille d’adresses ultérieure au niveau du groupe BGP pour un système logique ou une instance de routage :

Configuration du bit d’état de transfert par famille d’adresses au niveau du groupe BGP pour les systèmes logiques

Configuration du bit d’état de transfert par famille d’adresses au niveau du groupe BGP pour les instances de routage

Pour configurer le bit d’état de transfert pour le redémarrage gracieux de longue durée BGP par famille d’adresses et par famille d’adresses subséquente au niveau du groupe voisin BGP pour un système logique ou une instance de routage :

Configuration du bit d’état de transfert par famille d’adresses au niveau du groupe voisin BGP pour les systèmes logiques

Configuration du bit d’état de transfert par famille d’adresses au niveau du groupe voisin BGP pour les instances de routage

Exemple : Préserver les détails de route pour les homologues BGP lents et latents à l’aide du redémarrage progressif de longue durée BGP

Junos OS prend en charge le mécanisme permettant de conserver les détails du routage BGP pendant une période plus longue à partir d’un pair BGP défaillant que la durée pendant laquelle ces informations de routage sont conservées à l’aide de la fonctionnalité de redémarrage progressif BGP.

Historiquement, les protocoles de routage et BGP, en particulier, ont été conçus en mettant l’accent sur l’exactitude, où un aspect important de l'« exactitude » consiste à ce que l’état de transfert de chaque élément du réseau converge vers l’état actuel du réseau le plus rapidement possible. Pour cette raison, le protocole a été conçu pour supprimer l’état annoncé par les routeurs qui tombaient en panne (du point de vue du BGP) aussi rapidement que possible. En utilisant BGP Graceful Restart défini dans la RFC 4724, la fonctionnalité de convergence rapide a été une tentative de supprimer rapidement l’état « obsolète » du réseau.

Le redémarrage gracieux à longue durée de vie BGP (LLGR) permet à un opérateur réseau de choisir de conserver les informations de routage périmées d’un pair BGP défaillant beaucoup plus longtemps que la fonction de redémarrage gracieux BGP existante. Cette fonctionnalité permettant de maintenir les routes BGP pendant une période plus longue est conforme au projet de l’IETF, Support for Long-lived BGP Graceful Restart—draft-uttaro-idr-bgp-persistence-03. Selon ce projet, le redémarrage gracieux à longue durée de vie (LLGR) doit être explicitement configuré par NLRI, et il inclut des dispositions pour empêcher la propagation d’informations obsolètes à d’autres pairs qui ne reconnaissent pas et ne valident pas LLGR.

Cet exemple décrit comment configurer la fonctionnalité de redémarrage gracieux de longue durée BGP sur les routeurs MX Series et contient les sections suivantes :

Conditions préalables

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

  • Un routeur MX Series avec un MPC.

  • Junos OS version 15.1R1 ou ultérieure pour les routeurs MX Series

Avant de configurer le redémarrage progressif de longue durée BGP, assurez-vous de :

  1. Configurez les interfaces de l’appareil.

  2. Configurez BGP.

Présentation

Le redémarrage progressif permet à un périphérique de routage en cours de redémarrage d’informer ses voisins et homologues adjacents de son état. Lors d’un redémarrage progressif, l’équipement redémarré et ses voisins continuent de transférer des paquets sans affecter les performances du réseau. Étant donné que les périphériques voisins assistent au redémarrage (ces voisins sont appelés routeurs d’assistance), le périphérique qui redémarre peut rapidement reprendre son fonctionnement complet sans recalculer les algorithmes.

Le mode récepteur de redémarrage progressif de longue durée est activé par défaut, sauf si le mode de récepteur de redémarrage progressif ordinaire est désactivé. Pour activer la fonctionnalité de redémarrage gracieux de longue durée (LLGR) BGP, incluez l’instruction long-lived receiver enable au niveau de la [edit protocols bgp graceful-restart] hiérarchie. Outre l’activation de BGP LLGR au niveau global ou à l’échelle du système, vous pouvez également inclure l’instruction long-lived receiver enable au niveau de la hiérarchie pour configurer le LLGR pour un groupe BGP particulier et au niveau de la [edit protocols bgp group group-name graceful-restart][edit protocols bgp group group-name neighbor neighbor-address graceful-restart] hiérarchie pour configurer le LLGR pour un voisin BGP particulier. Pour désactiver le mécanisme BGP LLGR, incluez long-lived receiver disable l’option [edit protocols bgp graceful-restart],[edit protocols bgp group group-name graceful-restart] ou [edit protocols bgp group-name-name neighbor neighbor-address graceful-restart] niveau hiérarchique. La désactivation de LLGR désactive toutes les fonctionnalités LLGR (modes récepteur et redémarrage) pour toutes les familles NLRI. Cette propriété est héritée par les groupes de la configuration globale et par les voisins de la configuration de groupe.

Topologie

Considérons un exemple de scénario dans lequel vous souhaitez augmenter la période pendant laquelle les routes obsolètes sont gérées pour un pair BGP ou voisin avec l’adresse 1.2.3.4. En plus de spécifier la durée pendant laquelle les routes doivent être conservées pour les sessions obsolètes et lorsqu’un redémarrage progressif d’un homologue se produit, vous pouvez également configurer les routeurs BGP à partir de certains préfixes d’adresse afin qu’ils ne soient pas pris en compte lorsque vous définissez le mécanisme de redémarrage progressif à longue durée de vie. Vous pouvez définir une liste de préfixes d’adresses IPv4 ou IPv6 à utiliser dans une instruction de stratégie de routage et une communauté BGP à inclure dans la stratégie de routage. Si vous définissez le modificateur d’action pour rejeter les routes d’un préfixe particulier, ces routes BGP ne sont pas conservées pendant la période prolongée.

Vous pouvez également configurer le mécanisme de négociation du mode de redémarrage gracieux BGP de longue durée pour une famille d’adresses particulière au lieu de configurer cette fonctionnalité pour toutes les familles d’adresses d’un système, d’un système logique ou d’une instance de routage. Pour activer BGP LLGR pour une famille d’adresses spécifique, incluez l’instruction à l’un graceful-restart long-lived restarter stale-time interval des niveaux hiérarchiques suivants.

Chaque table de routage est identifiée par la famille de protocoles ou l’indicateur de famille d’adresses (AFI) et un identifiant de famille d’adresses ultérieur (SAFI). Le paramètre AFI peut être l’un des protocoles (l2vpn | inet | route-target) et le paramètre SAFI peut être l’un des protocoles (flow | labeled-unicast) de la famille inet et l’un des protocoles (auto-discovery-mspw | auto-discovery-only | signaling) de la famille L2VPN.

La configuration de LLGR ne nécessite pas que le redémarrage normal BGP soit également configuré. La section long-lived-graceful-restart n’est visible que pour les familles l2vpn, inet labeled-unicast, inet flow et route-target. Il est interdit pour inet-mvpn, inet6-mvpn et inet-mdt. Il est caché pour les autres familles.

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

Configuration de la liste de préfixes d’adresses, de la communauté BGP et de la stratégie de routage BGP

Configuration du groupe BGP, du NLRI et du redémarrage progressif de longue durée

Configuration du groupe de voisinage BGP

Configuration d’un redémarrage gracieux de longue durée pour le mode de redémarrage

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

  1. Configurez la liste des préfixes d’adresse, la communauté BGP, ainsi que la condition de correspondance et le modificateur d’action pour la stratégie de routage BGP.

  2. Configurez le groupe BGP, la famille d’adresses et la fonctionnalité de redémarrage progressif de longue durée pour le mode de redémarrage avec le temps périmé pour les flux.

  3. Configurez le groupe voisin BGP.

Résultats

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

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérification de l’activation de la fonctionnalité de redémarrage progressif de longue durée

But

Vérifiez la fonctionnalité de redémarrage gracieux de longue durée BGP configurée pour le niveau BGP voisin

Action

Lorsque le mode récepteur LLGR est actif (un homologue qui a négocié LLGR s’est déconnecté et n’est pas encore reconnecté), la sortie de la show bgp neighbor commande affiche le temps restant jusqu’à l’expiration du LLGR, le temps restant sur le temporisateur périmé GR et les détails du RIB :

Sens

La sortie affiche des informations sur les voisins BGP.