Comprendre le basculement de routage en douceur

Concepts de basculement du moteur de routage gracieux

La fonctionnalité GRES (Graceful Moteur de routage Switchover) de Junos OS et Junos OS Evolved permet à un équipement doté de moteurs de routage redondants de continuer à transférer des paquets même en cas de défaillance d’un moteur de routage. GRES préserve les informations de l’interface et du noyau, et le trafic n’est pas interrompu. Cependant, GRES ne conserve pas le plan de contrôle.

Les périphériques voisins détectent que l’équipement a connu un redémarrage et réagissent à l’événement d’une manière prescrite par les spécifications de chaque protocole de routage.

Pour conserver le routage lors d’un basculement, GRES doit être combiné avec :

• Extensions de protocole de redémarrage gracieux

• NSR (NonStop active Routing )

Toutes les mises à jour apportées au moteur de routage principal sont répliquées sur le moteur de routage de secours dès qu’elles se produisent.

Note:

En raison de ses exigences et de sa logique de synchronisation, les performances NSR/GRES sont limitées par le moteur de routage le plus lent du système.

Le rôle principal bascule vers le moteur de routage de secours si :

• Le noyau principal du moteur de routage cesse de fonctionner.

• Le moteur de routage principal subit une défaillance matérielle.

• L’administrateur lance un basculement manuel.

Note:

Pour restaurer ou préserver rapidement les informations d’état du protocole de routage lors d’un basculement, GRES doit être combiné avec le redémarrage gracieux ou le routage actif ininterrompu, respectivement. Pour plus d’informations sur le redémarrage gracieux, consultez Concepts de redémarrage gracieux. Pour plus d’informations sur le routage actif ininterrompu, reportez-vous à la section Concepts de routage actif ininterrompu.

Si le moteur de routage de secours ne reçoit pas de keepalive du moteur de routage principal après 2 secondes, il détermine que le moteur de routage principal a échoué ; et assume le rôle principal.

Le moteur de transfert de paquets :

• Se déconnecte de façon transparente de l’ancien moteur de routage principal

• Reconnecte au nouveau moteur de routage principal

• Ne redémarre pas

• N’interrompt pas le trafic

Le nouveau moteur de routage principal et le moteur de transfert de paquets se synchronisent alors. Si le nouveau moteur de routage principal détecte que l’état du moteur de transfert de paquets n’est pas à jour, il renvoie les messages de mise à jour de l’état.

Notez les comportements, recommandations ou exigences GRES suivants :

• À partir de la version 12.2 de Junos OS, si les contiguïtés entre le périphérique de redémarrage et les périphériques d'assistance homologues voisins expirent, les extensions du protocole de redémarrage gracieux ne peuvent pas avertir les périphériques d'assistance homologues du redémarrage imminent. Un redémarrage normal peut alors s’arrêter et provoquer des interruptions de trafic.

  Pour vous assurer que ces contiguïtés sont maintenues, définissez la hold-time valeur par défaut des protocoles IS-IS de 27 secondes à une valeur supérieure à 40 secondes.

• Les événements successifs de basculement du moteur de routage doivent être espacés d’au moins 240 secondes (4 minutes) après l’activation des deux moteurs de routage.

  Si l’appareil affiche un message d’avertissement semblable à :

  alors ne tentez pas de basculer. Si vous choisissez de procéder au basculement, l’appareil réinitialise uniquement les moteurs de transfert de paquets qui n’étaient pas prêts pour le basculement normal. Aucun des FPC ne doit redémarrer spontanément. Nous vous recommandons d’attendre que l’avertissement ne s’affiche plus, puis de procéder au basculement.

• Nous vous déconseillons :

  • Effectuer une opération de validation sur le moteur de routage de sauvegarde lorsque GRES est activé sur l’équipement.

  • Activation de GRES sur le moteur de routage de secours dans n’importe quel scénario.

La figure 1 illustre l’architecture du système de basculement du moteur de routage et le processus suivi par une plate-forme de routage pour se préparer à un basculement.

Note:

Vérifiez l’état de préparation du GRES en exécutant les deux éléments suivants :

• La request chassis routing-engine master switch check commande du moteur de routage principal

• La show system switchover commande du moteur de routage de sauvegarde

Le processus de préparation du basculement pour GRES est le suivant :

1. Le moteur de routage principal démarre.

2. Les processus de la plate-forme de routage (tels que le processus de châssis [chassisd]) démarrent.

3. Le moteur de transfert de paquets démarre et se connecte au moteur de routage principal.

4. Toutes les informations sur l’état sont mises à jour dans le système.

5. Le moteur de routage de sauvegarde démarre.

6. Le système détermine si GRES a été activé.

7. Le processus de synchronisation du noyau (ksyncd) synchronise le moteur de routage de sauvegarde avec le moteur de routage principal.

8. Une fois que ksyncd a terminé la synchronisation, toutes les informations d’état et la table de transfert sont mises à jour.

La figure 2 montre les effets d’un basculement sur la plate-forme de routage (ou de commutation).

Un processus de basculement comprend les étapes suivantes :

1. Lorsque des keepalives du moteur de routage principal sont perdus, le système bascule gracieusement vers le moteur de routage de secours.

2. Le moteur de transfert de paquets se connecte au moteur de routage de secours, qui devient le nouveau moteur principal.

3. Les processus de la plate-forme de routage qui ne font pas partie de GRES (tels que le processus rpd du protocole de routage) redémarrent.

4. Les informations d’état apprises au moment du basculement sont mises à jour dans le système.

5. Si elles sont configurées, les extensions de protocole de redémarrage en douceur collectent et rétablissent les informations de routage à partir des périphériques d’assistance homologues voisins.

Utilisez l’explorateur de fonctionnalités pour confirmer la prise en charge de fonctionnalités spécifiques par la plate-forme et la version.

Consultez la section Comportement GRES spécifique à la plate-forme pour obtenir des remarques relatives à votre plate-forme.

Effets d’un basculement de moteur de routage

Le Tableau 1 décrit les effets d’un basculement vers le moteur de routage lorsque différentes fonctionnalités sont activées :

• Pas de fonctionnalités de haute disponibilité

• Basculement vers le moteur de routage Graceful

• Redémarrage en douceur

• Routage actif ininterrompu

Tableau 1 : Effets d’un basculement vers un moteur de routage

Caractéristique	Avantages	Considérations
Deux moteurs de routage uniquement (aucune fonctionnalité activée)	Lorsque le basculement vers le nouveau moteur de routage principal est terminé, la convergence du routage a lieu et le trafic reprend.	Toutes les interfaces physiques sont mises hors ligne. Les moteurs de transfert de paquets redémarrent. Le moteur de routage de sauvegarde redémarre le processus de protocole de routage (rpd). Tout le matériel et les interfaces sont découverts par le nouveau moteur de routage principal. Le basculement prend plusieurs minutes. Toutes les proximités de l'appareil sont conscientes des changements physiques (alarmes d'interface) et de routage (topologie).
GRES activé	Lors du basculement, les informations relatives à l’interface et au noyau sont conservées. Le basculement est plus rapide car les moteurs de transfert de paquets ne sont pas redémarrés.	Le nouveau moteur de routage principal redémarre le processus de protocole de routage (rpd). Tout le matériel et les interfaces sont acquis par un processus similaire à un redémarrage à chaud. Toutes les proximités sont conscientes du changement d'état de l'équipement.
Compatible GRES et NSR	Le trafic n’est pas interrompu pendant le basculement. Les informations sur l’interface et le noyau sont conservées.	Les protocoles non pris en charge doivent être actualisés à l’aide des mécanismes de récupération normaux inhérents à chaque protocole.
GRES et redémarrage gracieux activés	Le trafic n’est pas interrompu pendant le basculement. Les informations sur l’interface et le noyau sont conservées. Les extensions de protocole de redémarrage élégantes collectent et rétablissent rapidement les informations de routage à partir des périphériques voisins.	Les voisins sont tenus de prendre en charge le redémarrage gracieux et un intervalle d’attente est requis. Le processus de protocole de routage (rpd) redémarre. Pour certains protocoles, une modification importante du réseau peut entraîner l’arrêt du redémarrage normal. À partir de la version 12.2 de Junos OS, si les contiguïtés entre le périphérique de redémarrage et les périphériques homologues voisins expirent, le redémarrage normal peut s'arrêter et provoquer des interruptions du trafic.

Commutation fluide du moteur de routage sur les interfaces de services agrégées

Si une commande GRES (Graceful Moteur de routage Switchover) est déclenchée par une commande en mode opérationnel, l’équipement ne conserve pas l’état des interfaces de services agrégées (ASI). Par exemple:

Toutefois, si GRES est déclenché par un commit CLI ou un redémarrage ou un plantage FPC, le moteur de routage de sauvegarde met à jour l’état ASI. Par exemple:

Ou:

Assistance pour la plate-forme de basculement du moteur de routage gracieux

Pour permettre un basculement fluide du moteur de routage, votre système doit répondre aux exigences minimales suivantes :

• Routeur MX960 : Junos OS version 8.3 ou ultérieure

• Routeur MX480 : Junos OS version 8.4 ou ultérieure (8.4R2 recommandé)

• Routeur MX240 : Junos OS version 9.0 ou ultérieure

• Routeur PTX5000 : Junos OS version 12.1X48 ou ultérieure

• Commutateurs EX Series avec deux moteurs de routage ou dans un Virtual Chassis — Junos OS version 9.2 ou ultérieure pour les commutateurs EX Series

• Commutateurs QFX Series dans un Virtual Chassis : Junos OS version 13.2 ou ultérieure pour QFX Series

• Commutateurs EX Series ou QFX Series dans une Virtual Chassis Fabric : Junos OS version 13.2X51-D20 ou ultérieure pour les commutateurs EX Series et QFX Series

Pour plus d’informations sur la prise en charge du basculement du moteur de routage normal, consultez les sections suivantes.

Prise en charge des fonctionnalités de basculement du moteur de routage gracieux

Le basculement du moteur de routage gracieux prend en charge la plupart des fonctionnalités de Junos OS à partir de la version 5.7. Certaines fonctionnalités de Junos OS nécessitent des versions spécifiques de Junos OS. Voir le tableau 2.

Tableau 2 : prise en charge des fonctionnalités de basculement vers le moteur de routage gracieux

Application	Version de Junos OS
Interfaces Ethernet agrégées avec protocole LACP (Link Aggregation Control Protocol) et interfaces SONET agrégées	6.2
ATM (Asynchronous Transfer Mode) circuits virtuels (VC)	6.2
Systèmes logiques Note: Dans Junos OS version 9.3 et ultérieure, la fonctionnalité de routeur logique est renommée Système logique.	6.3
Multidiffusion	6.4 (7.0 pour le routeur TX Matrix)
MLPPP (Multilink Point-to-Point Protocol) et MLFR (Multilink Frame Relay)	7.0
Commutation de protection automatique (APS) : l’interface active actuelle (soit l’interface de travail désignée, soit l’interface de protection désignée) reste l’interface active pendant un basculement du moteur de routage.	7.4
Commutation d’étiquettes multiprotocole point à multipoint LSP MPLS (transit uniquement)	7.4
Protocole de transport en temps réel compressé (CRTP)	7.6
Service de réseau local privé virtuel (VPLS)	8.2
Opération, administration et gestion (OAM) Ethernet tel que défini par IEEE 802.3ah	8.5
Agent de relais DHCP étendu	8.5
OAM Ethernet tel que défini par IEEE 802.1ag	9.0
Processus PGCP (Packet Gateway Control Protocol) sur les PIC Multiservices 500 sur les routeurs T640.	9.0
Accès abonné	9.4
Circuit de couche 2 et configuration redondante de pseudowire VPLS basé sur LDP	9.6

Les contraintes suivantes s’appliquent à la prise en charge des fonctionnalités de basculement du moteur de routage :

• Lorsque le basculement du moteur de routage et les interfaces Ethernet agrégées sont configurés dans le même système, les interfaces Ethernet agrégées ne doivent pas être configurées pour l’interrogation rapide LACP. Lorsque l’interrogation rapide est configurée, le délai d’interrogation LACP expire à l’extrémité distante pendant le basculement du rôle principal du moteur de routage. Lorsque l’interrogation LACP expire, la liaison agrégée et l’interface sont désactivées. Le changement du rôle principal du moteur de routage est suffisamment rapide pour que l’interrogation LACP standard et lente n’expire pas pendant la procédure.

  Note:

  Les sessions MACSec s’interrompent lors du basculement du moteur de routage gracieux.

  À partir de la version 13.2 de Junos OS, lorsqu’un basculement du moteur de routage se produit sans problème, l’état VRRP ne change pas. VRRP est pris en charge par le basculement gracieux du moteur de routage uniquement dans le cas où la délégation PPM est activée (ce qui est le cas par défaut).

Commutation et accès abonné grâce au moteur de routage

Le basculement du moteur de routage gracieux prend actuellement en charge la plupart des fonctionnalités directement associées à l’accès DHCP dynamique et PPPoE dynamique des abonnés. Le basculement du moteur de routage gracieux prend également en charge la mise à niveau logicielle en service unifié (ISSU) pour le modèle d’accès DHCP et le modèle d’accès PPPoE utilisé pour l’accès abonné.

Note:

Lorsque le basculement du moteur de routage est activé pour la gestion des abonnés, tous les moteurs de routage du routeur doivent disposer de la même quantité de DRAM pour un fonctionnement stable.

Commutation du moteur de routage gracieux Prise en charge du PIC

Le basculement du moteur de routage gracieux est pris en charge sur la plupart des PIC, à l’exception des PIC de services répertoriés dans cette section. Le PIC doit se trouver sur une plate-forme de routage prise en charge exécutant la version appropriée de Junos OS. Pour plus d’informations sur les types de FPC, la compatibilité FPC/PIC et la version initiale de Junos OS dans laquelle un FPC prenait en charge un PIC particulier, reportez-vous au guide PIC de votre plate-forme de routeur.

Les contraintes suivantes s’appliquent à la prise en charge du basculement du moteur de routage pour les PIC de services :

• Vous pouvez inclure l’instruction graceful-switchover au niveau de la [edit chassis redundancy] hiérarchie sur un routeur sur lequel des PIC Adaptive Services, Multiservices et Services de tunnel sont configurés et valider la configuration. Toutefois, tous les services de ces PIC, à l’exception des packages de services de couche 2 et des applications du fournisseur d’extensions et du SDK sur les PIC multiservices, sont réinitialisés lors d’un basculement.

• Le basculement du moteur de routage gracieux n’est pas pris en charge sur les PIC des services de surveillance ni sur les PIC des services multiliaisons. Si vous incluez l’instruction graceful-switchover au niveau de la [edit chassis redundancy] hiérarchie sur un routeur sur lequel l’un de ces types de PIC est configuré et que vous émettez la commit commande, la validation échoue.

• Le basculement du moteur de routage gracieux n’est pas pris en charge sur les PIC Multiservices 400 configurés pour surveiller les applications de services. Si vous incluez l’instruction graceful-switchover , la validation échoue.

Note:

Lorsqu’un PIC non pris en charge est en ligne, vous ne pouvez pas activer le basculement du moteur de routage normal. Si le basculement du moteur de routage est déjà activé, un PIC non pris en charge ne peut pas être activé.

Utilisez l’explorateur de fonctionnalités pour confirmer la prise en charge de fonctionnalités spécifiques par la plate-forme et la version.

Utilisez le tableau suivant pour passer en revue les comportements spécifiques à votre plateforme :

La différence de	la plate-forme
MX Series	Lorsque vous effectuez GRES sur des routeurs MX Series, vous devez exécuter la commande en clear synchronous-ethernet wait-to-restore mode opérationnel sur le nouveau moteur de routage principal pour effacer le minuteur d’attente de restauration sur celui-ci. En effet, la clear synchronous-ethernet wait-to-restore commande du mode opérationnel efface le minuteur d’attente de restauration uniquement sur le moteur de routage local. Pour les routeurs MX Series utilisant une gestion améliorée des abonnés, le nouveau moteur de routage de secours (l’ancien moteur de routage principal) redémarre lorsqu’un basculement du moteur de routage normal est effectué. Ce redémarrage à froid resynchronise l’état du moteur de routage de sauvegarde avec celui du nouveau moteur de routage principal, évitant ainsi les divergences d’état qui auraient pu se produire lors du basculement. Les routeurs MX Series sur lesquels la gestion distribuée de paquets périodique (PPM) est activée peuvent configurer le basculement du moteur de routage intelligent et disposent d’interfaces Ethernet agrégées configurées pour l’interrogation rapide LACP sur le même équipement. Le basculement du moteur de routage Graceful prend en charge tous les concentrateurs de ports denses (DPC) sur les plates-formes de routage universelles 5G MX Series exécutant la version appropriée de Junos OS, comme indiqué dans Comportement GRES spécifique à la plate-forme.
PTX Series	Sur les appareils PTX10004, PTX10008 et PTX10016 exécutant Junos OS Evolved, GRES est activé par défaut et ne peut pas être désactivé.
QFX Series	Lorsque vous activez le routage ininterrompu avec GRES sur des commutateurs de la gamme QFX10000 dotés de moteurs de routage redondants, nous vous recommandons vivement de configurer l’instruction nsr-phantom-holdtime seconds au niveau de la [edit routing-options] hiérarchie. Cela permet d’éviter les pertes de trafic lors d’un basculement. Si vous configurez cette instruction, les adresses IP fantômes restent dans le noyau pendant le basculement jusqu’à l’expiration de l’intervalle de temps d’attente spécifié. Une fois l’intervalle expiré, l’équipement ajoute les routes correspondantes aux tables de routage appropriées. Dans un environnement VPN Ethernet (EVPN)-VXLAN, nous vous recommandons de spécifier une valeur de temps d’attente de 300 secondes (5 minutes). Cette option ne s'applique pas aux commutateurs QFX10002, qui n'ont pas de moteurs de routage redondants et ne prennent pas en charge GRES.