Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Understanding Graceful Restart for BGP

Comprendre la fonctionnalité de redémarrage progressif BGP de longue durée

Junos OS prend en charge le mécanisme permettant de conserver les détails du routage BGP plus longtemps contre 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 avec un accent sur l’exactitude, où un aspect important de l'« exactitude » consiste à ce que l’état de transfert de chaque élément réseau converge vers l’état actuel du réseau aussi rapidement que possible. Pour cette raison, le protocole a été conçu pour supprimer l’état annoncé par les routeurs qui sont tombés en panne (du point de vue BGP) aussi rapidement que possible. Grâce au graceful restart BGP défini dans le document RFC 4724, la fonctionnalité de convergence rapide a été une tentative pour supprimer rapidement l’état « obsolète » du réseau.

Sur une certaine période, deux facteurs contributifs ont entraîné la modification et l’amélioration de cette méthode d’élimination rapide des états obsolètes. Le premier est l’adoption généralisée des infrastructures de transmission par tunnel, par exemple MPLS. Ces infrastructures éliminent le risque de certains types de boucles de transfert pouvant apparaître dans le transfert saut par saut, réduisant ainsi l’une des motivations pour une forte cohérence entre les éléments de transfert. La seconde est l’utilisation croissante de BGP en tant que transport de données moins étroitement associé au transfert de paquets qu’il ne l’était à l’origine. Citons par exemple 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 supposent une caractéristique qui n’est pas en phase avec le routage traditionnel.

Il était important d’offrir aux opérateurs réseau la possibilité de conserver les données BGP pour une période plus longue, lorsque le plan de contrôle BGP échoue pour une raison quelconque. Bien que les propriétés du graceful restart BGP soient proches de cette exigence de conservation des informations BGP pour une durée plus longue, plusieurs lacunes existent, notamment dans le temps maximum pour lequel les informations « obsolètes » peuvent être conservées : le redémarrage progressif impose une limitation de 4 095 secondes en liaison supérieure. Junos OS prend en charge une fonctionnalité BGP appelée fonctionnalité de redémarrage progressif de longue durée, de sorte que les informations obsolètes peuvent être conservées plus longtemps au cours d’une réinitialisation de session. Il prend également en charge une nouvelle communauté BGP, « LLGR_STALE », pour marquer ces informations. Ces informations obsolètes doivent être traitées comme les moins privilégiées, et sa publicité se limite aux haut-parleurs BGP qui prennent en charge la nouvelle fonctionnalité.

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

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

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

  • Vous pouvez voir si le LLGR est actuellement en vigueur pour un pair et s’il est efficace, la période après laquelle il expire.

  • Les routes obsolètes retenues par LLGR sont explicitement marquées dans la sortie de la show bgp neighbor commande.

  • Les routes obsolètes apprises par les autres voisins sont explicitement marquées dans la sortie de la commande (à l’aide show bgp neighbor de 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 survient, y compris une connectivité intermittente pouvant entraîner la réinitialisation d’une connexion avant que l’ensemble du RIB puisse être transmis, une telle défaillance ne provoque pas de redémarrage. En outre, un tel phénomène n’implique pas qu’un problème de connectivité entre les clients et les sauts suivant annoncés par le réflecteur de route existe. On prévoit qu’un temps typique de redémarrage long est de l’ordre de 12 heures.

Tous les conseils comportementaux et les points opérationnels décrits dans le projet de l’IETF, draft-uttaro-idr-bgp-persistence-03, pour le LLGR sont pris en charge. En outre, la rétrocompatibilité avec les fonctionnalités de Junos OS existantes dans les versions antérieures à la version 15.1, en particulier le redémarrage progressif et le routage ininterrompu (NSR), est prise en charge. Lorsque llgr est configuré, le redémarrage progressif fonctionne de la manière existante, sauf comme illustré dans le projet Internet. Vous pouvez également configurer à la fois LLGR et NSR et obtenir la fonctionnalité LLGR complète. Comme pré-requis pour llgr, la prise en charge du projet IETF, la prise en charge des messages de notification pour BGP Graceful Restart (draft-ietf- idr-bgp-gr-notification-01) est implémentée. Ce projet étend le comportement des RESSOURCES ordinaires pour lui permettre de se prémunir contre les interruptions de communications et les erreurs de protocole.

Comprendre la configuration pendant une période maximale pour la génération automatique de keepalives BGP par horités de noyau après le basculement

Dans Junos OS, le routage actif ininterrompu (NSR) utilise la même infrastructure que le basculement GRES (Graceful Routing Engine Switchover) pour préserver les informations de l’interface et du noyau. Toutefois, le NSR enregistre également les informations sur le protocole de routage en exécutant le processus de protocole de routage (rpd) sur le moteur de routage de secours. En sauvegardant ces informations supplémentaires, le NSR est autonome et ne s’appuie pas sur des routeurs (ou commutateurs) d’assistance pour aider la plate-forme de routage à restaurer les informations du protocole de routage. Le NSR est avantageux dans les réseaux où les routeurs (ou commutateurs) voisins ne prennent pas en charge les extensions de protocole de redémarrage progressif. Grâce à cette fonctionnalité améliorée, le NSR remplace naturellement le redémarrage progressif.

La réplication de connecteurs repose sur la fonction de routage actif ininterrompu à semi-automatique. Au basculement, ce composant fusionne automatiquement les paires de connecteurs de la sauvegarde au moteur de routage principal. Le basculement NSR de la sauvegarde au principal se produit lorsque le rpd émet un appel de fusion pour que chaque paire de connecteurs secondaires les fusionne à une seule prise, ce qui risque de retarder. Pour éviter ce délai, un module d’automergement dans le noyau dissocie la prise secondaire du rpd et fusionne automatiquement les connecteurs secondaires sur le basculement afin que le thread rpd hautement prioritaire en tire parti et génère une keepalive plus rapide afin de maintenir les connexions TCP au basculement.

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

Interopérabilité des fonctionnalités avec BGP Graceful Restart de longue durée

Cette rubrique contient les sections suivantes décrivant le comportement de fonctionnement des différentes fonctionnalités grâce au redémarrage progressif de longue durée BGP et aux diverses 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 de 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.

Limites des NLRIs prises en charge

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

  • L2vpn

  • inet labellisé unicast

  • flux d’inet

  • cible de routage

  • unicast inet-vpn

  • flux inet-vpn

  • unicast inet6-vpn

Les familles suivantes empêchent la configuration LLGR et la négociation des capacités :

  • inet-mvpn

  • inet6-mvpn

  • inet-mdt

Pour les familles NLRI pour lesquelles la capacité LLGR est empêchée, il indique qu’une tentative de validation d’une configuration incluant une configuration LLGR pour ces familles est rejetée et que ces paramètres ne sont pas enregistrés. Les NLRIs associés à ces familles ne sont pas inclus dans une publicité de fonctionnalités LLGR, et sont ignorés dans une publicité de fonctionnalité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 régulièrement la fonctionnalité LLGR, y compris un délai d’inaltérabilité long pour déclencher le mode récepteur LLGR dans ses pairs. Cependant, la fonctionnalité de redémarrage LLGR complet (retardant la transmission des marqueurs de fin de rib jusqu’à ce que les end-of-end 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 rpd (Routing Protocol Daemon) n’attend pas les moteurs d’arrêt d’autres pairs avant d’envoyer ses propres moteurs de routage. Il transmet l’EEOR dès qu’il a transmis le contenu RIB actuel. Cette condition peut provoquer des pannes transitoires lorsque le réseau est reconvergé. Le NSR est considéré comme approprié pour gérer tous les scénarios de redémarrage du moteur de routage unique. Seuls les scénarios de restriction du mode de redémarrage permettent de redémarrer simultanément les moteurs de routage (ou les deux copies du rpd). La configuration du mode de redémarrage ordinaire n’est pas activée avec le NSR.

La configuration en mode normal de redémarrage progressif n’est toujours pas prise en charge par le NSR.

Capacité LLGR aux niveaux global, BGP Group et des voisins BGP

Le mode récepteur de redémarrage progressif de longue durée est activé par défaut, sauf si le mode du récepteur de redémarrage progressif ordinaire est désactivé. Pour activer la fonctionnalité LLGR (Graceful Restart) BGP de longue durée, 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 d’activation du récepteur de longue durée au niveau de la [edit protocols bgp group group-name graceful- restart] hiérarchie pour configurer LLGR pour un groupe BGP particulier et au niveau de la [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] hiérarchie afin de configurer LLGR pour un voisin BGP particulier. Pour désactiver le mécanisme LLGR BGP, incluez l’option long-lived receiver disable , ou [modifier les [edit protocols bgp graceful-restart][edit protocols bgp group group-name graceful-restart]protocoles bgp group-group-name neighbor-address graceful-restart] niveau de hiérarchie. Désactiver 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 des groupes de la configuration globale et par des 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 progressif 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 d’affichage aident à diagnostiquer et déboguer les problèmes d’efficacité liés aux performances réseau et à la gestion du trafic.

Les clear bgp neighbor neighbor-address stale-routes routes obsolètes sont actuellement conservées pour le voisin spécifié en raison des opérations du mode de redémarrage progressif (GR) ou du mode de réception LLGR (Graceful Restart) de longue durée. 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 Reset (Réinitialisation matérielle) des messages Notify et Cease envoyés. En cas de négociation, le voisin peut entrer dans le mode d’assistance GR ou LLGR. La session est toujours effacée sur ce routeur, et ce routeur n’entre pas en mode d’assistance GR ou LLGR.

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

clear bgp neighbor neighbor-address socket.

Cette commande casse la connexion TCP pour une session d’appairage établie. C’est la seule implication directe du commandement et toutes les autres implications sont les effets secondaires de la connexion rompue. En conséquence, (sauf si les extensions de notification GR ont été désactivées), les deux côtés de la connexion passent en mode d’assistance GR ou LLGR si elles sont négociées et la connexion TCP est 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 de longue durée

  • Les paramètres LLGR négociés par l’appairage

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

  • Les heures sont affichées à l’aide du daemon du protocole de routage (rpd) %#0T format :

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

    Par exemple, on omet de ne pas inclure d’éléments de pointe, une valeur inférieure à une semaine n’inclut pas les semaines.

Si le redémarrage progressif de longue durée est totalement désactivé pour un voisin, les éléments suivants s’affichent :

Si un voisin ne prend pas entièrement en charge le protocole LLGR, les éléments suivants s’affichent :

Alors que le mode récepteur LLGR est actif (un pair qui a négocié le protocole LLGR s’est déconnecté et n’a pas encore été reconnecté), le résultat de la show bgp neighbor commande affiche le temps restant jusqu’à l’expiration du LLGR, le temps restant sur le compteur d’horloge GR et les détails RIB :

Lorsque le mode récepteur de redémarrage progressif BGP est actif pour un voisin, des informations supplémentaires sont affichées dans la sortie de la show bgp neighbor commande. Ces détails incluent la liste des NLRIs pour lequel les routes obsolètes sont conservées (NLRI, nous avons des routes obsolètes pour le champ), le temps restant sur le timer de redémarrage (le temps jusqu’à ce que les routes obsolètes soient supprimées ou deviennent un champ obsolète de longue durée), le temps restant sur le timer obsolète (Le temps jusqu’à la fin de la côte est supposé pour les routes obsolètes), et les détails RIB. L’heure est affichée au format UTC (YYYY-MM-DD-HH:MM:SS). Notez que l’affichage du compteur obsolète ('Time until end-of-rib is assume') est également présent lorsqu’une session est active, mais que le voisin n’a pas encore envoyé toutes les indications de fin de la côte.

Lorsque le redémarrage progressif ou le mode d’assistance LLGR sont actifs, les informations RIB sont maintenant affichées par la show bgp summary commande. Si une session BGP est établie sur l’équipement de routage principal, le champ affiche le nombre de routes actives, reçues, acceptées et amorties reçues par un voisin et apparaissent dans les tables de routage inet.0 (principale) 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 d’un pair BGP apparaissent dans la table de routage inet.0.

  • 2 routes actives, 4 routes reçues, 4 routes acceptées et aucun routage amorti d’un pair BGP n’apparaît dans la table de routage inet.2.

La show route detail commande (avec et sans l’option receive-protocol bgp ) est améliorée afin d’identifier les routes conservées dans l’état obsolète de longue date. 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 lors de sa réception par un pair, ou par une stratégie d’importation. Un ou les deux indicateurs peuvent être affichés pour une route. Aucun de ces drapeaux ne sera affiché en même temps que le drapeau Stale (ordinaire) GR. Lorsqu’un routage est de préférence parce qu’il est obsolète depuis longtemps, le champ Motif inactif dans la sortie de la commande show route detail affiche LLGR stale. Le nouveau motif d’inactivité LLGR s’inscrit dans la hiérarchie de sélection de route entre préférence et préférence locale.

Conseil :

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

Augmentation de la durée de conservation des routes BGP sur les pairs à redémarrage lent par BGP Graceful Restart

Junos OS prend en charge le mécanisme permettant de conserver les détails du routage BGP plus longtemps contre 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 du récepteur de redémarrage progressif ordinaire est désactivé. Pour activer la fonctionnalité LLGR (Graceful Restart) BGP de longue durée, 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 d’activation du récepteur de longue durée au niveau de la [edit protocols bgp group group-name graceful-restart] hiérarchie pour configurer LLGR pour un groupe BGP particulier et au niveau de la [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] hiérarchie afin de configurer LLGR pour un voisin BGP particulier. Pour désactiver le mécanisme LLGR BGP, incluez l’option long-lived receiver disable , ou [modifier les [edit protocols bgp graceful-restart][edit protocols bgp group group-name graceful-restart]protocoles bgp group-group-name neighbor-address graceful-restart] niveau de hiérarchie. Désactiver 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 des groupes de la configuration globale et par des 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]— Configuration du système logique et de l’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.

Elle long-lived receiver enable remplace une option de désactivation héritée d’un niveau supérieur de 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 que les routes LLGR obsolètes soient annoncées aux voisins qui ne font pas la promotion de la fonctionnalité LLGR, incluez l’instruction advertise-to-non-llgr-neighbor au niveau , [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 [edit protocols bgp graceful-restart long-lived]hiérarchie. Ce paramètre s’applique aux deux routes marquées LLGR-stale par ce routeur, et aux routes LLGR-stale reçues des voisins. Dans l’idéal, tous les routeurs d’un système autonome prennent en charge le projet de spécification de l’IETF avant son activation. Toutefois, pour faciliter le déploiement incrémentiel, il peut être nécessaire de faire la publicité de routes obsolètes aux voisins qui n’ont pas annoncé la fonctionnalité de redémarrage progressif de longue date dans les conditions suivantes : Les voisins doivent être des voisins internes (IBGP ou Confédération). La communauté NO_EXPORT doit être reliée aux routes obsolètes. L’attribut de LOCAL_PREF des routes obsolètes doit être défini sur zéro. Si cette technique de déploiement partiel est utilisée, vous devez définir LOCAL_PREF à zéro pour tous les routes LLGR sur l’ensemble du système autonome. Cette configuration permet de réduire légèrement la flexibilité (il est possible que la commande ne soit pas conservée entre les routes LLGR concurrentes) pour assurer la cohérence entre les routeurs qui prennent en charge cette spécification. Étant donné que la cohérence de la sélection de route peut être importante pour empêcher les boucles de transfert, cette dernière considération des routeurs qui ne prennent pas en charge cette spécification précède.

Pour éviter que la communauté BGP non exportatrice ne soit automatiquement ajoutée aux routes annoncées pour les voisins BGP externes (présumés être des routeurs CE), incluez l’instruction omit- no-export au niveau , [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 [edit protocols bgp graceful-restart long-lived]hiérarchie. Dans les déploiements VPN, par exemple, BGP est souvent utilisé comme protocole PE-CE. Dans de tels déploiements, il peut être pratiquement nécessaire de prendre en charge l’interopérabilité avec des CE qui ne peuvent pas être facilement mises à niveau pour prendre en charge des spécifications telles que celle-ci. Cette exigence pose problème tout en s’assurant que les informations de routage « obsolètes » ne fuient pas au-delà du périmètre des routeurs qui prennent en charge ces procédures où 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 de la limitation de la propagation des informations de routage « obsolètes » est la raison pour laquelle elles ne se propagent pas sans limite une fois qu’elles sont sorties des limites de la confédération BGP. Les déploiements 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, une fois configurée explicitement. Dans un tel scénario, l’implémentation doit joindre la communauté NO_EXPORT aux routes en question par défaut, afin de fournir 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 accueillir des cas exceptionnels. Il peut être nécessaire de présenter des routes obsolètes à 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 faire la promotion de ces routes, vous devez en informer l’opérateur du CE qui reçoit les routes, et le CE doit être configuré pour déprécier les routes. Les implémentations BGP typiques effectuent cette opération en faisant correspondance sur la communauté LLGR_STALE et en définissant le LOCAL_PREF pour les routes équivalentes à 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 advertise-to-non-llgr-neighbor est activée ou désactivée, la stratégie d’exportation est réévaluée et les routes LLGR obsolètes peuvent être annoncées ou retirées. Lorsque l’option omit-no-export est ajoutée ou supprimée, la session est réinitialisée. Ce reste d’une session permet de faire la promotion de routes LLGR obsolètes avec ou sans la communauté non export (ajoutée en dehors de la stratégie d’exportation).

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

Pour activer la fonctionnalité de redémarrage progressif de longue durée BGP au niveau du groupe BGP et configurer ses propriétés :

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

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

Junos OS prend en charge le mécanisme permettant de conserver les détails du routage BGP plus longtemps contre 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 dans n’importe quel niveau de hiérarchie de configuration comme d’autres communautés emblématiques connues (telles que « no-advertise », « no-export » et « no-export-subconfed ») dans l’attribut communautaire des définitions de route statiques ou dans une définition communautaire d’options de stratégie. Les deux nouvelles communautés sont les suivantes :

  • llgr-stale— Ajoute une communauté à une route obsolète de longue date lorsqu’elle est annoncée à nouveau.

  • no-llgr: indique les routes qu’un haut-parleur BGP ne souhaite pas conserver par LLGR. La fonctionnalité de message de notification ne comporte aucun paramètre de configuration associé.

Vous pouvez inclure l’instruction et no-llgr les llgr-stale options community name members permettant d’associer les informations de la communauté BGP à un routage statique, agrégé ou généré aux niveaux hiérarchiques suivants :

Pour configurer les communautés de redémarrage progressif de longue durée BGP pour une utilisation dans une condition de correspondance de stratégie de routage :

La configuration du protocole LLGR ne nécessite pas que le redémarrage progressif BGP soit également configuré. Les valeurs des communautés connues de llgr-stale et de 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 est visible uniquement pour les familles l2vpn, inet labeled-unicast, inet flow and 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 progressif BGP de longue durée. Vous pouvez associer la communauté que vous avez précédemment définie et une liste de préfixes d’adresse dans une stratégie de routage afin d’accepter ou de rejeter les routes pour un redémarrage progressif de longue durée pour les préfixes spécifiés, comme suit :

Deux instructions de configuration cachées sont ajoutées sous le niveau de hiérarchie ] pour la [edit protocols bgp graceful-restartconfiguration globale, de niveau groupe et de niveau de groupe de voisins.

L’instruction disable-notification-flag au [edit protocols bgp graceful-restart]niveau , [edit protocols bgp group group-name graceful-restart]ou [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] hiérarchique, désactive la transmission du drapeau N dans la négociation de la capacité de redémarrage progressif. L’instruction disable-notification-extensions au [edit protocols bgp graceful-restart]niveau , [edit protocols bgp group group-name graceful-restart]ou [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] hiérarchique, désactive également la transmission du N flag dans la négociation de la fonctionnalité de redémarrage progressif, mais en outre, elle désactive les nouvelles règles pour invoquer le mode récepteur de redémarrage progressif tel que spécifié dans le projet de notification IETF bgp-gr, et désactive l’transmission du sous-code De réinitialisation matérielle. Le sous-code Reset (Réinitialisation matérielle) est continuellement observé lors de la réception d’un message Notify ou Cease.

Pour désactiver la transmission des indicateurs N 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 des indicateurs N et pour désactiver les règles de déclenchement du redémarrage progressif au niveau du groupe :

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

Configuration du mode graceful restarter de longue durée Négociation 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 plus longtemps contre 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 graceful restarter BGP qui dure depuis longtemps 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 le protocole LLGR BGP pour une famille d’adresses spécifique, incluez l’instruction graceful-restart long-lived restarter stale-time interval à l’un des niveaux hiérarchiques suivants.

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

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

Les aubaines de la section de configuration du redémarrage progressif par famille permettent de négocier le mode de redémarrage LLGR pour BGP globalement, ou pour un groupe ou un voisin. Les valeurs sont héritées par groupes de la configuration globale et par les voisins de la configuration de groupe. L’attribut de désactivation 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 caché enable peut être utilisé pour remplacer un attribut de désactivation hérité. La configuration du redémarrage progressif redémarrage long au niveau des voisins (lorsqu’il n’est pas configuré au niveau du groupe contenant ou globalement) provoque la division d’un groupe interne. Lorsque le redémarrage LLGR est activé ou désactivé pour une famille ou que l’heure d’arrêt 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 l’intervalle est de 1 à 16777215 (2^24 – 1) secondes. La valeur est un entier simple donnant le nombre de secondes par défaut, mais il peut également être spécifié à l’aide de la notation suivante :

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

En outre, les délais peuvent également être configurés à l’aide de la notation suivante : <hours>:<minutes>:<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 la CLI nécessite des citations doubles autour d’une valeur comme celle-ci avec des espaces.) Dans cette notation, le temps d’insis 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 timers associés sont affichés dans des commandes d’affichage d’exécution telles que show bgp neighbor, les valeurs sont normalisées, telles que 1d36h devenant 2d 12:00:00. Les règles complètes d’affichage des temps LLGR standardisés dépendent de la configuration des clear bgp neighbor neighbor-address gracefully commandes.

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

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

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

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

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

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

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

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

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

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

Junos OS prend en charge le mécanisme permettant de conserver les détails du routage BGP plus longtemps contre 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.

Une fois la session BGP diminuée et avant que la session ne soit rétablie, les routes obsolètes peuvent être conservées pour une durée allant jusqu’à deux périodes consécutives, contrôlées respectivement par le temps de redémarrage et les paramètres de temps obsolètes de longue durée. Au cours de la première période, les modifications de routage sont empêchées, mais avec un filtrage potentiel de la route NULL du trafic. Au cours de la seconde période, il est possible de réduire le filtrage de route NULLE du trafic, mais les modifications de routage sont visibles sur l’ensemble du réseau. Dans votre environnement réseau, la définition 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 une configuration locale, soit par la définition du temps de redémarrage dans la fonction de redémarrage progressif sur zéro, sans énumérer les indicateurs de la famille d’adresses (AFI) et les identifiants de la famille d’adresses (SAFI) suivants dans cette fonctionnalité.

La définition du F bit (et de l'« état de transfert » de la capacité GR associée) dépend en partie des considérations de déploiement. Le F bit peut être interprété pour indiquer que le routeur d’assistance doit rougir les routes associées (si le bit reste clair). Un scénario important dans lequel LLGR est utilisé concerne des routes qui sont plus semblables à la configuration qu’au routage traditionnel (transfert saut par saut au lieu de routage basé sur un tunnel). Pour ces routes, il peut être utile de toujours définir le F bit, indépendamment des autres considérations. De même, pour les entités du 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 F bit soit toujours défini. Dans l’ensemble, les directives à adopter sont que si la perte d’état sur le routeur de redémarrage peut raisonnablement être susceptible d’entraîner une boucle de transfert ou une route nulle, le bit F doit être paramétré judicieusement, selon l’état retenu ou non. Vous pouvez déterminer si le F bit 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 de présenter des routes obsolètes à 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 réseau qui configure son pe pour promouvoir ces routes doit informer l’opérateur du CE qui reçoit les routes, et le CE doit être configuré pour déprécier les routes. En règle générale, les implémentations BGP exécutent ce comportement en faisant correspondance sur la communauté LLGR_STALE et en définissant le LOCAL_PREF pour les routes équivalentes à zéro.

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 voisin, pour n’importe quel système logique ou instance de routage. Pour spécifier l’é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 group-group-name graceful-restart]ou [edit protocols bgp group-group-name neighbor neighbor-address graceful-restart] de la [edit protocols bgp graceful-restart]hiérarchie. L’attribut forwarding-state-bit contrôle la façon dont le bit d’état de transfert est configuré à la fois dans le redémarrage progressif et dans les annonces de capacité de redémarrage progressif de longue durée. Par défaut, la valeur dépend du client de réflecteur de route du voisin. 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, sauf unicast inet et unicast inet6, qui utilisent l’état de la FIB associée. Cette as-rr-client option définit le comportement de toutes les familles d’adresses comme la fonctionnalité d’un client de réflecteur de route. Cette from-fib option force toutes les familles d’adresses à se comporter comme s’il s’agirait d’un client ne contenant pas de réflecteur de route.

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

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

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

Outre la définition globale du bit d’état de transfert, le comportement des bits d’état de transfert peut être spécifié pour les familles individuelles. La modification du paramètre d’état-bit de transfert n’a aucun effet sur les sessions existantes. Pour spécifier l’état de transfert pour une famille d’adresses particulière, incluez l’instruction forwarding-state-bit (set | from-fib) au niveau , [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] de la [edit protocols bgp graceful-restart family address-family subsequent-address-family]hiérarchie, sur un système logique et une instance de routage. Des options de configuration BGP par famille sont ajoutées pour contrôler l’état de transfert dans le redémarrage progressif et les annonces de capacité de redémarrage progressif 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, et 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 l’état de transfert bit. L’option set force le bit d’état de transfert à être défini sur 1. Cette from-fib option permet de définir la valeur en fonction de l’état de la FIB associée. La modification du paramètre d’état de transfert par famille n’a aucun effet sur les sessions existantes.

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

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

Configuration de la famille d’états de transfert bit par adresse au niveau mondial pour les systèmes logiques

Configuration de la famille d’états de transfert bit par adresse au niveau mondial pour les instances de routage

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

Configuration de la famille d’états de transfert Bit par adresse au niveau du groupe BGP pour les systèmes logiques

Configuration de la famille d’états de transfert Bit par adresse au niveau du groupe BGP pour les instances de routage

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

Configuration de la famille d’états de transfert Bit par adresse au niveau du groupe de voisins BGP pour les systèmes logiques

Configuration de la famille d’états de transfert Bit par adresse au niveau du groupe de voisins BGP pour les instances de routage

Exemple : Conservation des détails de route pour les pairs 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 plus longtemps contre 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 avec un accent sur l’exactitude, où un aspect important de l'« exactitude » consiste à ce que l’état de transfert de chaque élément réseau converge vers l’état actuel du réseau aussi rapidement que possible. Pour cette raison, le protocole a été conçu pour supprimer l’état annoncé par les routeurs qui sont tombés en panne (du point de vue BGP) aussi rapidement que possible. Grâce au graceful restart BGP défini dans le document RFC 4724, la fonctionnalité de convergence rapide a été une tentative pour supprimer rapidement l’état « obsolète » du réseau.

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

Cet exemple décrit comment configurer la fonctionnalité de redémarrage progressif BGP de longue durée 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 MPC.

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

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

  1. Configurez les interfaces de l’équipement.

  2. Configurer BGP.

Présentation

Le redémarrage progressif permet à un équipement de routage en cours de redémarrage d’informer ses voisins et pairs adjacents de son état. Lors d’un redémarrage progressif, l’équipement de redémarrage et ses voisins continuent de transférer les paquets sans perturber les performances du réseau. Parce que les équipements voisins aident au redémarrage (ces voisins sont appelés routeurs d’assistance), l’équipement de redémarrage peut rapidement reprendre le plein fonctionnement 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 du récepteur de redémarrage progressif ordinaire est désactivé. Pour activer la fonctionnalité LLGR (Graceful Restart) BGP de longue durée, 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 d’activation du récepteur de longue durée au niveau de la [edit protocols bgp group group-name graceful-restart] hiérarchie pour configurer LLGR pour un groupe BGP particulier et au niveau de la [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] hiérarchie afin de configurer LLGR pour un voisin BGP particulier. Pour désactiver le mécanisme LLGR BGP, incluez l’option long-lived receiver disable , ou [modifier les [edit protocols bgp graceful-restart][edit protocols bgp group group-name graceful-restart]protocoles bgp group-group-name neighbor-address graceful-restart] niveau de hiérarchie. Désactiver 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 des groupes de la configuration globale et par des voisins de la configuration de groupe.

Topologie

Prenons un exemple de scénario dans lequel vous souhaitez augmenter la période pendant laquelle les routes obsolètes sont maintenues pour un pair ou un voisin BGP avec l’adresse 1.2.3.4. En plus de spécifier la durée de conservation des routes pour les sessions obsolètes et le redémarrage progressif d’un pair, vous pouvez également configurer des routeurs BGP à partir de certains préfixes d’adresse à ignorer lorsque vous définissez le mécanisme de redémarrage progressif de longue durée. Vous pouvez définir une liste de préfixes d’adresse IPv4 ou IPv6 à utiliser dans une déclaration 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 maintenues pendant la période plus longue.

Vous pouvez également configurer le mécanisme de négociation du mode graceful restarter BGP qui dure depuis longtemps 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 le protocole LLGR BGP pour une famille d’adresses spécifique, incluez l’instruction graceful-restart long-lived restarter stale-time interval à l’un des niveaux hiérarchiques suivants.

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

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

Configuration

Configuration rapide CLI

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

Configuration de la liste des préfixes d’adresse, 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 voisins BGP

Configuration du redémarrage progressif de longue durée pour le mode restarter

Procédure étape par étape

L’exemple suivant nécessite de naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, reportez-vous à Using the CLI Editor in Configuration Mode dans le CLI User Guide.

  1. Configurez la liste des préfixes d’adresse, la communauté BGP, ainsi que la condition de correspondance et le modifier 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 délai d’arrêt des flux.

  3. Configurez le groupe de voisins BGP.

Résultats

Depuis le mode configuration, confirmez votre configuration en entrant les show policy-optionsshow protocols commandes. 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érifier la fonctionnalité de graceful restart BGP de longue durée configurée pour le niveau de voisin BGP

Action

Alors que le mode récepteur LLGR est actif (un pair qui a négocié le protocole LLGR s’est déconnecté et n’a pas encore été reconnecté), le résultat de la show bgp neighbor commande affiche le temps restant jusqu’à l’expiration du LLGR, le temps restant sur le compteur d’horloge GR et les détails RIB :

Sens

La sortie affiche les informations sur les voisins BGP.