Comprendre le redémarrage fluide pour BGP
Comprendre la fonctionnalité de redémarrage agréable de BGP à longue durée de vie
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 agréable de BGP.
Historiquement, les protocoles de routage et le BGP, en particulier, ont été conçus en mettant l’accent sur l’exactitude, où un aspect important de l'« exactitude » est 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 tombent en panne (du point de vue du BGP) le plus rapidement possible. À l’aide de la fonctionnalité de redémarrage agréable de BGP définie dans 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 ont contribué à modifier et à améliorer cette méthode d’élimination rapide des états périmés. La première est l’adoption généralisée des infrastructures de transfert tunnelisées, par exemple MPLS. De telles infrastructures éliminent le risque de certains types de boucles de transfert qui peuvent survenir dans le transfert saut par saut, et réduisent ainsi l’une des motivations pour une forte cohérence entre les éléments de transfert. Le second est l’utilisation croissante de BGP comme moyen de transport de données moins étroitement associé au transfert de paquets que ce n’était le cas à l’origine. Par exemple, l’utilisation de BGP pour la découverte automatique (VPLS [RFC4761]) et la programmation de filtres (FLOWSPEC [RFC5575]). Dans ces cas, les données BGP prennent une caractéristique qui n’est pas conforme au routage traditionnel.
Il était important d’offrir aux opérateurs réseau la possibilité de choisir de conserver les données BGP pendant une période plus longue lorsque le plan de contrôle BGP tombe en panne pour une raison quelconque. Bien que les propriétés de BGP Graceful Redémarrage soient proches de cette exigence souhaitée pour préserver les informations BGP pendant une plus longue durée, il existe plusieurs lacunes, notamment en ce qui concerne le temps maximum pendant lequel les informations « obsolètes » peuvent être conservées : le redémarrage progressif impose une limite supérieure de 4095 secondes. Junos OS prend en charge une capacité BGP appelée capacité 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 périmées doivent être traitées comme des informations de moindre préférence, et leur publicité limitée aux haut-parleurs BGP qui prennent en charge la nouvelle capacité.
Le redémarrage gracieux à longue durée de vie (LLGR) de BGP permet à un opérateur de réseau de choisir de conserver les informations de routage obsolètes d’un pair BGP défaillant beaucoup plus longtemps que la fonction de redémarrage rapide de BGP existante. Cette fonctionnalité permettant de maintenir les routes BGP pendant une période plus longue est conforme au projet de l’IETF, Prise en charge d’un redémarrage fluide de BGP à longue durée de vie - draft-uttaro-idr-bgp-persistence-03. Selon ce projet, le redémarrage gracieux de longue durée (LLGR) doit être explicitement configuré par NLRI, et il comprend 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 les 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 de quelques jours).
-
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, s’il est effectif, la période après laquelle il expire.
-
Les routes obsolètes conservées par LLGR sont explicitement marquées dans la sortie de la
show bgp neighborcommande. -
Les routes obsolètes apprises d’autres voisins sont explicitement marquées dans la sortie de la
show bgp neighborcommande (à l’aide 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 saillant de cette fonctionnalité. Dans un scénario dans lequel 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’intégralité du RIB puisse être transmise, 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 prévoit qu’un temps de redémarrage typique de longue durée est 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 rétrocompatibilité avec les fonctionnalités Junos OS existantes dans les versions antérieures à la version 15.1, en particulier le redémarrage fluide et le routage non-stop (NSR), est prise en charge. Lorsque LLGR est configuré, le redémarrage progressif fonctionne de la manière existante, sauf comme explicitement illustré dans le projet Internet. Vous pouvez également configurer LLGR et NSR en même temps, et obtenir la fonctionnalité complète de LLGR. La prise en charge du brouillon de l’IETF, de la prise en charge du message de notification pour le redémarrage harmonieux de BGP—draft-ietf- idr-bgp-gr-notification-01 est implémentée. Ce projet étend le comportement des RG ordinaires pour leur permettre de se protéger contre les interruptions de communication et les erreurs de protocole.
Voir aussi
Comprendre la configuration de la période maximale pour la génération automatique de keepalives BGP par les minuteurs du noyau après le basculement
En Junos OS, le routage actif non-stop (NSR) utilise la même infrastructure que le basculement GRES (Graceful moteur de routage switchover) pour préserver les informations de l’interface et du noyau. Toutefois, NSR enregistre également les informations du 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) d’aide 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 un redémarrage élégant.
La fusion automatique de routage actif non-stop est l’un des composants du noyau de la réplication de socket. Lors du basculement, ce composant fusionne automatiquement les paires de sockets du moteur de routage de secours vers le moteur de routage principal. Le basculement NSR de la sauvegarde vers le principal se produit lorsque rpd émet un appel de fusion pour chaque paire de sockets secondaires afin de les fusionner en un seul socket, ce qui peut entraîner un retard. Pour éviter ce délai, un module de fusion automatique dans le noyau dissocie la fusion de sockets secondaires de rpd et fusionne automatiquement les sockets secondaires lors du basculement afin que le thread 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’inscrit pas au service de génération keepalive automatique fourni par le noyau juste après l’événement de basculement de la sauvegarde vers le serveur principal. Pour cela, vous devez activer l’instruction au niveau de la hiérarchie [edit routing-options] et configurer les nonstop-routing-options minuteries de précision dans BGP. La configuration de minuteries de précision dans BGP permet à BGP d’enregistrer toutes ses sessions avec le service de génération automatique de keepalive fourni par le noyau. Une fois inscrit, le noyau génère automatiquement des keepalives à l’aide de ses minuteries pour le compte de BGP pour ses sessions de contrôle juste après l’événement de basculement de la sauvegarde vers la solution principale. Cela permet de générer des keepalives plus fiables pour les sessions de contrôle avec des minuteries très petites pendant l’événement de basculement.
Voir aussi
interopérabilité des fonctionnalités avec redémarrage fluide de longue durée de BGP
Cette rubrique contient les sections suivantes qui décrivent le comportement de fonctionnement de différentes fonctionnalités avec le redémarrage fluide de longue durée de BGP et les diverses conditions du système :
À partir de la version 15.1 de Junos OS, 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 de BGP.
- Limitations des NLRI prises en charge
- Mode de redémarrage LLGR sous NSR
- Capacité LLGR au niveau mondial, du groupe BGP et des voisins BGP
Limitations des NLRI prises en charge
La configuration LLGR et la négociation de capacité sont prises en charge pour les familles d’informations d’accessibilité de la couche réseau (NLRI) BGP suivantes :
-
L2VPN
-
Inet labellisé-unicast
-
flux inet
-
route-cible
-
unicast inet-vpn
-
flux inet-vpn
-
Inet6-VPN unicast
Les configurations LLGR et les négociations de capacités sont empêchées dans les familles suivantes :
-
inet-mvpn
-
inet6-mvpn
-
inet-mdt
Pour les familles NLRI pour lesquelles la capacité 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 négociation de la configuration et des capacités LLGR est autorisée, mais cachée, 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 obsolète de longue durée pour déclencher le mode récepteur LLGR chez ses pairs. Cependant, la fonctionnalité complète de redémarrage de LLGR (retarder la transmission des marqueurs End of RIB jusqu’à ce que les EoR soient reçues de tous les pairs) ne fonctionne pas sous NSR. Lors d’un redémarrage complet du système (les deux moteurs de routage), le Routing Protocol Daemon (rpd) n’attend pas les EoR d’autres pairs avant d’envoyer sa propre EoR. Il transmet l’EoR dès qu’il a transmis le contenu actuel du RIB. Cette condition peut provoquer des pannes transitoires lorsque le réseau converge à nouveau. Le NSR est considéré comme adéquat pour gérer tous les scénarios de redémarrage à un seul moteur de routage. La restriction du mode redémarrage affecte uniquement les scénarios dans lesquels les deux moteurs de routage (ou les deux copies de rpd) redémarrent simultanément. La configuration en mode 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 mondial, du groupe BGP et des voisins BGP
Le mode récepteur de redémarrage gracieux de longue durée est activé par défaut, sauf si le mode récepteur de redémarrage gracieux ordinaire est désactivé. Pour activer la fonctionnalité de redémarrage gracieux à longue durée de vie (LLGR) de 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 d’activation du récepteur à longue durée de vie 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 pour configurer LLGR pour un voisin BGP particulier. Pour désactiver le mécanisme BGP LLGR, incluez l’option long-lived receiver disable de [edit protocols bgp graceful-restart]niveau hiérarchique , [edit protocols bgp group group-name graceful-restart]ou [edit protocols bgp group-group-name neighbor neighbor-address graceful-restart]. La désactivation de LLGR désactive toutes les capacités LLGR (à la fois les 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.
Voir aussi
Surveillance et administration de BGP Long Lived Graceful Redémarrage rapide
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 fluide de longue durée de BGP. Vous pouvez analyser les compteurs statistiques et les mesures liées à 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 la gestion du trafic.
Entraîne clear bgp neighbor neighbor-address stale-routes toutes les routes obsolètes actuellement maintenues pour le voisin spécifié en raison d’opérations en mode récepteur de redémarrage gracieux (GR) ou de redémarrage gracieux de longue durée (LLGR). 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 Réinitialisation matérielle sur les messages Notifier et Cesser qui sont envoyés. Cela permet au voisin de passer en mode d’aide 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 masquée clear est disponible, ajoutée pour la fonctionnalité de redémarrage gracieux 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 connexion rompue. 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 entreront en mode d’assistance GR ou LLGR, si elles sont négociées, 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 agréable de longue durée
-
Les paramètres LLGR que l’homologue a négociés
-
Paramètres LLGR négociés par le routeur de redémarrage
-
Les heures sont affichées au format %#0T du démon du 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 :
user@router> show bgp neighbor
Peer: 10.6.128.225+45824 AS 100 Local: 10.255.255.14+44542 AS 100
Type: Internal State: Established Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Options: <Preference LocalAddress AddressFamily Rib-group Refresh>
Options: <LLGRHelperDisabled> {The LLGRHelperDisabled value for the Options field denotes that long-lived BGP graceful restart is completely disabled for a neighbor}
Si un voisin ne prend pas entièrement en charge LLGR, ce qui suit s’affiche :
user@router> show bgp neighbor
...
Peer does not support LLGR Restarter or Receiver functionality {BGP neighor or peer does not support long-lived BGP graceful restart restarter or receiver
functionality}
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 minuteur GR périmé et les détails du RIB :
user@router> show bgp neighbor
Peer: 10.4.12.11 AS 100 Local: 10.6.128.225 AS 100
Type: Internal State: Active Flags: <>
Last State: Idle Last Event: Start
Last Error: None
Export: [ foo ]
Options: <Preference LocalAddress Refresh GracefulRestart>
Options: <LLGR>
Local Address: 10.6.128.225 Holdtime: 90 Preference: 170
Number of flaps: 3
Last flap event: Restart
Error: 'Cease' Sent: 0 Recv: 1
Time until long-lived stale routes deleted: inet-vpn-unicast 10:00:22 route-target 10:00:22
Table bgp.l3vpn.0
RIB State: BGP restart is complete
RIB State: VPN restart is complete
Send state: not advertising
Active prefixes: 0
Received prefixes: 7
Accepted prefixes: 7
Suppressed due to damping: 0
Table foo.inet.0 Bit: 30000
RIB State: BGP restart is complete
RIB State: VPN restart is complete
Send state: not in sync
Active prefixes: 0
Received prefixes: 7
Accepted prefixes: 7
Suppressed due to damping: 0
Lorsque le mode récepteur de redémarrage agréable 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 NLRI pour lesquels les routes obsolètes sont conservées (NLRI, nous conservons des routes obsolètes pour le champ), le temps restant sur le temporisateur de redémarrage (temps jusqu’à ce que les routes obsolètes soient supprimées ou deviennent des champs périmés de longue durée), le temps restant sur le minuteur obsolète (le temps jusqu’à la fin de la nervure est supposé pour les routes obsolètes) et les détails du RIB. L’heure est affichée au format du temps universel coordonné (UTC) (AAAA-MM-JJ-HH :MM :SS). Notez que l’affichage de la minuterie obsolète ('Time until end-of-rib is assumed') est également présent lorsqu’une session est active, mais le voisin n’a pas encore envoyé toutes les indications de fin de nervure.
Lorsque le mode graceful restart ou LLGR helper est actif, les informations RIB sont maintenant affichées par la show bgp summary commande. Si une session BGP est établie sur le périphérique de routage principal, le champ indique le nombre de routes actives, reçues, acceptées et amorties reçues d’un voisin et apparaissant 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 d’un pair BGP apparaissent dans la table de routage inet.0.
-
2 routes actives, 4 routes reçues, 4 routes acceptées et aucune route amortie d’un pair BGP n’apparaissent dans la table de routage inet.2.
La show route detail commande (avec et sans l’option receive-protocol bgp ) est améliorée pour identifier les routes qui sont maintenues dans l’état obsolète 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 comme LLGR-périmée lorsqu’elle a été reçue d’un homologue ou par une stratégie d’importation. L’un de ces drapeaux ou les deux peuvent être affichés pour un itinéraire. Aucun de ces drapeaux ne sera affiché en même temps que le drapeau Stale (GR ordinaire périmé). Lorsqu’un itinéraire est défavorisé parce qu’il est périmé de longue durée, le champ Raison inactive de la sortie de la commande Afficher les détails de l’itinéraire affiche LLGR périmé. Le nouveau motif d’inactivité périmé LLGR s’intègre dans la hiérarchie de sélection de route entre Préférence et Préférence locale.
user@router> show route receive-protocol bgp 10.4.12.11 detail
bgp.l2vpn.0: 38 destinations, 39 routes (37 active, 0 holddown, 1 hidden)
* 1.1.1.4:100:1.1.1.4/96 AD (1 entry, 1 announced)
Accepted LongLivedStale LongLivedStaleImport
Nexthop: 10.4.12.11
Localpref: 100
AS path: I
Selon le Centre d’assistance technique de Juniper (JTAC), une commande utile pour aider à résoudre les problèmes liés au redémarrage fluide de longue durée de BGP est la show route table bgp.l2vpn.0 detail hidden commande. 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 qui expliquent pourquoi les itinéraires sont masqués. D’autres indices qui 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 des routes cachées apparaissant dans la sortie de la show bgp summary commande.
Voir aussi
Augmentation de la durée de conservation des routes BGP entre des homologues qui redémarrent lentement grâce au redémarrage progressif de longue durée de BGP
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 agréable de BGP.
Le mode récepteur de redémarrage gracieux de longue durée est activé par défaut, sauf si le mode récepteur de redémarrage gracieux ordinaire est désactivé. Pour activer la fonctionnalité de redémarrage gracieux à longue durée de vie (LLGR) de 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 d’activation du récepteur à longue durée de vie 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 pour configurer LLGR pour un voisin BGP particulier. Pour désactiver le mécanisme BGP LLGR, incluez l’option long-lived receiver disable de [edit protocols bgp graceful-restart]niveau hiérarchique , [edit protocols bgp group group-name graceful-restart]ou [edit protocols bgp group-group-name neighbor neighbor-address graceful-restart]. La désactivation de LLGR désactive toutes les capacités LLGR (à la fois les 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 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 gracieux de longue durée pour toutes les familles : le mode de redémarrage doit être configuré explicitement pour chaque famille.
Pour permettre aux routes LLGR-stale d’être annoncées aux voisins qui n’annoncent pas la capacité LLGR, incluez l’instruction advertise-to-non-llgr-neighbor au niveau , ou [edit protocols bgp group group-name neighbor neighbor-address graceful-restart long-lived] hiérarchie[edit protocols bgp graceful-restart long-lived][edit protocols bgp group group-name graceful-restart long-lived]. Ce paramètre s’applique à la fois aux 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 devraient prendre 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 d’annoncer des routes obsolètes aux voisins qui n’ont pas annoncé la fonctionnalité de redémarrage agréable 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 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 sur zéro pour toutes les routes LLGR dans le 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) contre 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 routage peut être importante pour éviter les boucles de transfert, cette dernière considération des routeurs qui ne prennent pas en charge cette spécification prévaut.
Pour éviter que la communauté BGP sans exportation ne soit automatiquement ajoutée aux routes annoncées aux 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] 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 nécessaire de prendre en charge l’interopérabilité avec des CE 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 « obsolètes » ne fuient 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 des informations de routage « obsolètes » est la raison pour les empêcher de se propager sans limite une fois qu’elles ont quitté la limite 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, lorsqu’elle est explicitement configurée. Dans un tel scénario, l’implémentation doit rattacher 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. Dans certains déploiements VPN, il peut s’avérer nécessaire d’annoncer des routes obsolètes vers un CE, même si le CE ne prend pas en charge cette spécification. Dans ce cas, si vous configurez les routeurs PE pour annoncer ces routes, vous devez en informer l’opérateur de la CE qui reçoit les routes, et le CE doit être configuré pour dépreference les routes. Les implémentations BGP classiques effectuent cette opération en faisant correspondre la communauté LLGR_STALE et en définissant le LOCAL_PREF de correspondance des routes 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 capacité 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 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 aux routes obsolètes LLGR d’être annoncées à nouveau 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 agréable longue durée de BGP au niveau système ou global et configurer ses propriétés :
[edit]
protocols {
bgp {
graceful-restart {
long-lived {
receiver {
enable:
disable;
}
advertise-to-non-llgr-neighbor {
omit-no-export;
}
}
}
}
}
Pour activer la fonctionnalité de redémarrage fluide de longue durée de BGP au niveau du groupe BGP et configurer ses propriétés :
[edit]
protocols {
bgp {
group group-name {
graceful-restart {
long-lived {
receiver {
enable:
disable;
}
advertise-to-non-llgr-neighbor {
omit-no-export;
}
}
}
}
}
}
Pour activer la fonctionnalité de redémarrage agréable longue durée de BGP au niveau du voisin ou du groupe de pairs et configurer ses propriétés :
[edit]
protocols {
bgp {
group group-name {
neighbor neighbor-address {
graceful-restart {
long-lived {
receiver {
enable:
disable;
}
advertise-to-non-llgr-neighbor {
omit-no-export;
}
}
}
}
}
}
}
Voir aussi
Configuration des communautés de redémarrage agréable à longue durée de vie de BGP dans les stratégies de routage
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 agréable de 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 en tant que autres communautés symboliques connues (telles que no-advertise, no-export et no-export-subconfed) dans l’attribut community des définitions de routes statiques ou dans une définition de communauté d’options de stratégie. Les deux nouvelles communautés sont les suivantes :
-
llgr-stale: ajoute une communauté à une route obsolète de longue durée lorsqu’elle est republiée. -
no-llgr: marque les routes qu’un interlocuteur BGP ne souhaite pas conserver par LLGR. La fonctionnalité de message de notification n’a aucun paramètre de configuration associé.
Vous pouvez inclure les options et no-llgr avec l’instruction community name members pour associer les informations de llgr-stale la communauté BGP à une route statique, agrégée ou générée aux niveaux hiérarchiques suivants :
[edit dynamic policy-options], [edit logical-systems logical-system-name policy-options], [edit policy-options]
Pour configurer les communautés de redémarrage agréable à longue durée de vie de BGP pour une utilisation dans une condition de correspondance de politique de routage :
[edit policy-options]
community name {
members [ llgr-stale | nollgr];
}
La configuration de LLGR ne nécessite pas que le redémarrage progressif de 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 qui correspond à l’état d’une route pour un redémarrage fluide de longue durée de BGP. Vous pouvez associer la communauté que vous avez définie précédemment et une liste de préfixes d’adresses dans une politique de routage pour accepter ou rejeter sélectivement les routes pour un redémarrage gracieux de longue durée pour les préfixes spécifiés, comme suit :
policy-options {
prefix-list name;
community name members [ llgr-stale | nollgr];
policy-statement name{
from {
prefix-list name;
community name;
}
then {
(accept | reject)
}
}
}
Deux instructions de configuration masquées sont ajoutées sous le niveau de hiérarchie ] 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] 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 , ou [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] hiérarchie [edit protocols bgp graceful-restart][edit protocols bgp group group-name graceful-restart]désactive également la transmission de l’indicateur N dans la négociation de la capacité de redémarrage gracieux, mais en outre, elle désactive les nouvelles règles d’appel du mode récepteur de redémarrage gracieux comme spécifié dans le brouillon de notification bgp-gr-notification de l’IETF, et désactive la transmission du sous-code 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 d’arrêt.
Pour désactiver la transmission de N indicateurs et les règles de déclenchement d’un redémarrage progressif au niveau global ou à l’échelle du système :
[edit]
protocols {
bgp {
graceful-restart {
disable-notification-flag;
disable-notification-extensions;
}
}
}
Pour désactiver la transmission de N indicateurs et désactiver les règles de déclenchement d’un redémarrage progressif au niveau du groupe :
[edit]
protocols {
bgp {
group group-name {
graceful-restart {
disable-notification-flag;
disable-notification-extensions;
}
}
}
}
Pour désactiver la transmission de N indicateurs et les règles de déclenchement d’un redémarrage progressif au niveau du voisin ou de l’homologue :
[edit]
protocols {
bgp {
group group-name {
graceful-restart {
disable-notification-flag;
disable-notification-extensions;
}
}
}
}
Voir aussi
Configuration de la négociation en mode de redémarrage gracieux 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 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 agréable de BGP.
Vous pouvez également configurer le mécanisme de négociation en mode de redémarrage gracieux à longue durée de vie de BGP pour une famille d’adresses particulière au lieu de configurer cette capacité 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 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 famille d’adresses (AFI) et un identifiant de famille d’adresses (SAFI) ultérieur. 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 protcols de la (auto-discovery-mspw | auto-discovery-only | signaling) famille L2VPN.
La configuration de LLGR ne nécessite pas que le redémarrage progressif de 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.
[edit logical-systems logical-system-name protocols bgp family inet (labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name protocols bgp group group-name family inet (labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address family inet (labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family inet (labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name family inet (labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address family inet (labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp family inet (labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp group group-name family inet (labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address family inet (labeled-unicast | unicast | multicast)] [edit routing-instances routing-instance-name protocols bgp family inet (labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp group group-name family inet (labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address family inet (labeled-unicast | unicast | multicast)],
Les strophes de la section de configuration de redémarrage à longue durée de vie 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 les groupes de la configuration globale et par les voisins de la configuration de groupe. L’attribut disable est utilisé pour 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 masqué enable peut être utilisé pour remplacer un attribut disable hérité. La configuration du redémarrage de longue durée à redémarrage progressif 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 de 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 le temps de périphérie 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 :
[<semaines>w][<jours>d][< heures>h][< minutes>m][<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 maximum périmé.
En outre, les heures peuvent également être configurées à l’aide de la notation suivante : <heures> :<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 guillemets doubles autour d’une valeur comme celle-ci avec des espaces.) Exprimée dans cette notation, la durée d’épuisement maximale 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 minuteries associées sont affichées dans les commandes show au moment de l’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 normalisés dépendent de la configuration de la clear bgp neighbor neighbor-address gracefully commande.
Pour configurer la famille d’adresses et la famille d’adresses suivantes du redémarrage progressif de longue durée de BGP par famille d’adresses et par famille d’adresses ultérieure au niveau global pour un système logique ou une instance de routage :
Configuration de la famille de redémarrages progressifs longue durée de BGP par adresse au niveau global pour les systèmes logiques
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
graceful-restart {
long-lived {
restarter {
disable;
stale-time interval;
}
}
}
}
}
Configuration du redémarrage fluide longue durée de longue durée de BGP par famille d’adresses au niveau mondial pour les instances de routage
[edit routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
graceful-restart {
long-lived {
restarter {
disable;
stale-time interval;
}
}
}
}
}
Pour configurer les caractéristiques de redémarrage agréable à longue durée de vie de BGP par famille d’adresses et par famille d’adresses ultérieures au niveau du groupe BGP pour un système logique ou une instance de routage :
Configuration du redémarrage fluide longue durée de BGP par famille d’adresses au niveau du groupe BGP pour les systèmes logiques
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
group group-name {
graceful-restart {
long-lived {
restarter {
disable;
stale-time interval;
}
}
}
}
}
}
Configuration du redémarrage fluide longue durée de BGP par famille d’adresses au niveau du groupe BGP pour les instances de routage
[edit routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
group group-name {
graceful-restart {
long-lived {
restarter {
disable;
stale-time interval;
}
}
}
}
}
}
Pour configurer les caractéristiques de redémarrage gracieux de longue durée de BGP 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 du redémarrage fluide longue durée de BGP par famille d’adresses au niveau du groupe de voisins BGP pour les systèmes logiques
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
group group-name {
neighbor neighbor-address {
graceful-restart {
long-lived {
restarter {
disable;
stale-time interval;
}
}
}
}
}
}
}
Configuration du redémarrage fluide longue durée de BGP par famille d’adresses au niveau du groupe de voisins BGP pour les instances de routage
[edit routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
group group-name {
neighbor neighbor-address {
graceful-restart {
long-lived {
restarter {
disable;
stale-time interval;
}
}
}
}
}
}
}
Voir aussi
Informer le routeur d’assistance ou l’homologue BGP 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 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 agréable de BGP.
Après l’arrêt d’une session BGP et avant son rétablissement, les routes obsolètes peuvent être conservées pendant deux périodes consécutives, contrôlées respectivement par les paramètres de temps de redémarrage et de temps d’épuisement à longue durée de vie. Au cours de la première période, les modifications de routage sont empêchées, mais le trafic peut être filtré par une route nulle. Au cours de la deuxième période, le filtrage du trafic par voie nulle peut être réduit, mais les changements 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 potentielle. Si nécessaire, la première période peut être contournée soit par une 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 (SAFI) ultérieurs 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é concerne les routes qui ressemblent davantage à une configuration qu’à un routage traditionnel (transfert saut par saut au lieu d’un 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 qu’une perte d’état sur le routeur qui redémarre provoque une boucle de transfert ou une route nulle, le bit F doit être défini 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. Dans certains déploiements VPN, il peut s’avérer nécessaire d’annoncer des routes obsolètes vers un CE, 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 CE qui reçoit les routes, et le CE doit être configuré pour dépreference les routes. En règle générale, les implémentations BGP adoptent ce comportement en faisant correspondre la communauté LLGR_STALE et en définissant la LOCAL_PREF de correspondance des routes sur zéro.
Vous pouvez spécifier le bit d’état de transfert, qui est une option de configuration BGP pouvant être définie au niveau global, du groupe et du 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 voisinage BGP, incluez l’instruction forwarding-state-bit (as-rr-client | from-fib) au niveau de la hiérarchie ou [edit protocols bgp group-group-name neighbor neighbor-address graceful-restart] .[edit protocols bgp graceful-restart][edit protocols bgp group-group-name graceful-restart] L’attribut forwarding-state-bit contrôle la façon dont le bit d’état de transfert est défini dans les annonces de capacité de redémarrage gracieux et de redémarrage gracieux de longue durée. Par défaut, la valeur varie selon que le voisin est ou non un client réflecteur de route. Si le voisin n’est pas un client 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 réflecteur de route, la valeur est définie sur 1 pour toutes les familles, à l’exception des unicast inet unicast et inet6, 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 le même que 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 sans réflecteur de route.
Pour configurer la négociation de l’indicateur d’état de transfert au niveau global :
[edit]
protocols {
bgp {
graceful-restart {
forwarding-state-bit (as-rr-client | from-fib);
}
}
}
Pour configurer la négociation de l’indicateur d’état de transfert au niveau du groupe :
[edit]
protocols {
bgp {
group group-name {
graceful-restart {
forwarding-state-bit (as-rr-client | from-fib);
}
}
}
}
Pour configurer la négociation de l’indicateur d’état de transfert au niveau du voisin ou du groupe de pairs :
[edit]
protocols {
bgp {
group group-name {
neighbor neighbor-address {
graceful-restart {
forwarding-state-bit (as-rr-client | from-fib);
}
}
}
}
}
Outre le paramètre global pour le bit d’état de transfert, le comportement de 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 , ou [edit protocols bgp group-group-name neighbor neighbor-address graceful-restart family address-family subsequent-address-family] hiérarchie [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]sur un système logique et une instance de routage. Des options de configuration BGP par famille sont 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, 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 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 complets de la hiérarchie de configuration auxquels vous pouvez inclure l’instruction forwarding-state-bit (set | from-fib) permettant de configurer le bit d’état de transfert par famille d’adresses :
[edit logical-systems logical-system-name protocols bgp family inet (labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name protocols bgp group group-name family inet (labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address family inet (labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family inet (labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name family inet (labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address family inet (labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp family inet (labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp group group-name family inet (labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address family inet (labeled-unicast | unicast | multicast)] [edit routing-instances routing-instance-name protocols bgp family inet (labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp group group-name family inet (labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address family inet (labeled-unicast | unicast | multicast)],
Pour configurer le bit d’état de transfert pour la famille d’adresses de redémarrage gracieux longue durée de BGP et la famille d’adresses par suite au niveau global pour un système logique ou une instance de routage :
Configuration de la famille d’états de transfert bit par adresse au niveau global pour les systèmes logiques
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
graceful-restart {
forwarding-state-bit (set | from-fib);
}
}
}
Configurer la famille d’états de transfert bit par adresse au niveau global pour les instances de routage
[edit routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
graceful-restart {
forwarding-state-bit (set | from-fib);
}
}
}
Pour configurer le bit d’état de transfert pour la famille d’adresses de redémarrage gracieux longue durée de BGP et la famille d’adresses par suite au niveau du groupe BGP pour un système logique ou une instance de routage :
Configuration de la famille d’état de transfert bit par adresse au niveau du groupe BGP pour les systèmes logiques
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
group group-name {
graceful-restart {
forwarding-state-bit (set | from-fib);
}
}
}
}
Configuration de la famille de bits d’état de transfert par adresse au niveau du groupe BGP pour les instances de routage
[edit routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
group group-name {
graceful-restart {
forwarding-state-bit (set | from-fib);
}
}
}
}
Pour configurer le bit d’état de transfert pour la famille de redémarrage gracieux longue durée de BGP et la famille d’adresses par suite au niveau du groupe de voisins BGP pour un système logique ou une instance de routage :
Configuration de la famille d’état de transfert bit par adresse au niveau du groupe de voisins BGP pour les systèmes logiques
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
group group-name {
neighbor neighbor-address {
graceful-restart {
forwarding-state-bit (set | from-fib);
}
}
}
}
}
Configuration de la famille d’état de transfert bit par adresse au niveau du groupe de voisins BGP pour les instances de routage
[edit routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
group group-name {
neighbor neighbor-address {
graceful-restart {
forwarding-state-bit (set | from-fib);
}
}
}
}
}
Voir aussi
Exemple : Préservation des détails de route pour les homologues BGP lents et latents à l’aide du redémarrage progressif longue durée de BGP
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 agréable de BGP.
Historiquement, les protocoles de routage et le BGP, en particulier, ont été conçus en mettant l’accent sur l’exactitude, où un aspect important de l'« exactitude » est 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 tombent en panne (du point de vue du BGP) le plus rapidement possible. À l’aide de la fonctionnalité de redémarrage agréable de BGP définie dans 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 (LLGR) de BGP permet à un opérateur de réseau de choisir de conserver les informations de routage obsolètes d’un pair BGP défaillant beaucoup plus longtemps que la fonction de redémarrage rapide de BGP existante. Cette fonctionnalité permettant de maintenir les routes BGP pendant une période plus longue est conforme au projet de l’IETF, Prise en charge d’un redémarrage fluide de BGP à longue durée de vie - draft-uttaro-idr-bgp-persistence-03. Selon ce projet, le redémarrage gracieux de longue durée (LLGR) doit être explicitement configuré par NLRI, et il comprend 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 progressif longue durée de BGP sur les routeurs MX Series et contient les sections suivantes :
Exigences
Cet exemple utilise les composants matériels et logiciels suivants :
-
Un routeur MX Series avec une MPC.
-
Junos OS version 15.1R1 ou ultérieure pour les routeurs MX Series
Avant de configurer le redémarrage fluide longue durée de BGP, assurez-vous de :
-
Configurez les interfaces des appareils.
-
Configurez BGP.
Vue d’ensemble
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 en douceur, l’appareil qui redémarre et ses voisins continuent de transférer des paquets sans perturber les performances du réseau. Étant donné que les appareils voisins aident au redémarrage (ces voisins sont appelés routeurs d’assistance), l’appareil qui redémarre peut rapidement reprendre son fonctionnement complet sans avoir à recalculer les algorithmes.
Le mode récepteur de redémarrage gracieux de longue durée est activé par défaut, sauf si le mode récepteur de redémarrage gracieux ordinaire est désactivé. Pour activer la fonctionnalité de redémarrage gracieux à longue durée de vie (LLGR) de 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 d’activation du récepteur à longue durée de vie 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 pour configurer LLGR pour un voisin BGP particulier. Pour désactiver le mécanisme BGP LLGR, incluez l’option long-lived receiver disable de [edit protocols bgp graceful-restart]niveau hiérarchique , [edit protocols bgp group group-name graceful-restart]ou [edit protocols bgp group-group-name neighbor neighbor-address graceful-restart]. La désactivation de LLGR désactive toutes les capacités LLGR (à la fois les 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 maintenues pour un pair BGP ou un 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 de longue durée. Vous pouvez définir une liste de préfixes d’adresses IPv4 ou IPv6 à utiliser dans une instruction de politique de routage et une communauté BGP à inclure dans la politique 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 en mode de redémarrage gracieux à longue durée de vie de BGP pour une famille d’adresses particulière au lieu de configurer cette capacité 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 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 famille d’adresses (AFI) et un identifiant de famille d’adresses (SAFI) ultérieur. 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 protcols de la (auto-discovery-mspw | auto-discovery-only | signaling) famille L2VPN.
La configuration de LLGR ne nécessite pas que le redémarrage progressif de 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.
La configuration
- Configuration rapide de la CLI
- Configuration du redémarrage fluide de longue durée pour le mode redémarrage
- Résultats
Configuration rapide de la CLI
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à votre configuration réseau, copiez et collez les commandes dans la CLI au niveau de la [edit] hiérarchie, puis entrez commit en mode configuration.
Configuration de la liste des préfixes d’adresse, de la communauté BGP et de la stratégie de routage BGP
set policy-options prefix-list special 44.44.44.44/32 set policy-options community llgr-community llgr-stale set policy-options policy-statement llgr-import from prefix-list special set policy-options policy-statement llgr-import from community llgr-community set policy-options policy-statement llgr-import then reject
Configuration du groupe BGP, de la NLRI et du redémarrage progressif de longue durée
set protocols bgp group ibgp-group type internal set protocols bgp group ibgp-group import llgr-import set protocols bgp group ibgp-group family inet unicast set protocols bgp group ibgp-group family inet unicast graceful-restart long-lived restarter stale-time 12h
Configuration du groupe de voisins BGP
set protocols bgp group ibgp-group neighbor 1.2.3.4
Configuration du redémarrage fluide de longue durée pour le mode 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 la CLI, consultez Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur de la CLI.
-
Configurez la liste des préfixes d’adresse, la communauté BGP, ainsi que la condition de correspondance et le modificateur d’action pour la politique de routage BGP.
[edit] user@ host# set policy-options prefix-list special 44.44.44.44/32 user@ host# set policy-options community llgr-community llgr-stale user@ host# set policy-options policy-statement llgr-import from prefix-list special user@ host# set policy-options policy-statement llgr-import from community llgr-community user@ host# set policy-options policy-statement llgr-import then reject
-
Configurez le groupe BGP, la famille d’adresses et la fonctionnalité de redémarrage progressif à longue durée pour le mode redémarrage avec le temps obsolète pour les flux.
[edit] user@ host# set protocols bgp group ibgp-group type internal user@ host# set protocols bgp group ibgp-group import llgr-import user@ host# set protocols bgp group ibgp-group family inet unicast user@ host# set protocols bgp group ibgp-group family inet unicast graceful-restart long-lived restarter stale-time 12h
-
Configurez le groupe de voisins BGP.
[edit] user@ host# set protocols bgp group ibgp-group neighbor 1.2.3.4
Résultats
En mode configuration, confirmez votre configuration en entrant les show policy-options commandes and show protocols . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
[edit]
user@host# show policy-options
policy-options {
prefix-list special 44.44.44.44/32;
community llgr-community llgr-stale;
policy-statement llgr-import {
from {
prefix-list special;
community llgr-community;
}
then {
reject;
}
}
}
user@host# show protocols
protocols {
bgp {
group ibgp-group {
type internal;
import llgr-import;
family inet unicast {
graceful-restart {
long-lived {
restarter {
stale-time 12h;
}
}
}
}
neighbor 1.2.3.4;
}
}
}
Vérification
Vérifiez que la configuration fonctionne correctement.
Vérification de l’activation de la fonctionnalité de redémarrage agréable de longue durée
Objet
Vérifiez la fonctionnalité de redémarrage progressif longue durée de BGP configurée pour le niveau de voisinage BGP
Mesures à prendre
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 minuteur GR périmé et les détails du RIB :
user@router> show bgp neighbor
Peer: 10.4.12.11 AS 100 Local: 10.6.128.225 AS 100
Type: Internal State: Active Flags: <>
Last State: Idle Last Event: Start
Last Error: None
Export: [ foo ]
Options: <Preference LocalAddress Refresh GracefulRestart>
Options: <LLGR>
Local Address: 10.6.128.225 Holdtime: 90 Preference: 170
Number of flaps: 3
Last flap event: Restart
Error: 'Cease' Sent: 0 Recv: 1
Time until long-lived stale routes deleted: inet-vpn-unicast 10:00:22 route-target 10:00:22
Table bgp.l3vpn.0
RIB State: BGP restart is complete
RIB State: VPN restart is complete
Send state: not advertising
Active prefixes: 0
Received prefixes: 7
Accepted prefixes: 7
Suppressed due to damping: 0
Table foo.inet.0 Bit: 30000
RIB State: BGP restart is complete
RIB State: VPN restart is complete
Send state: not in sync
Active prefixes: 0
Received prefixes: 7
Accepted prefixes: 7
Suppressed due to damping: 0
Signification
La sortie affiche des informations sur les voisins BGP.