Comprendre la redondance des moteurs de routage

Présentation de la redondance du moteur de routage

Les moteurs de routage redondants sont deux moteurs de routage installés sur la même plate-forme de routage. L’un fonctionne comme le principal, tandis que l’autre est de secours en cas d’échec du moteur de routage principal. Sur les plates-formes de routage dotées de deux moteurs de routage, la reconvergence du réseau s’effectue plus rapidement que sur les plates-formes de routage avec un seul moteur de routage.

Lorsqu’un moteur de routage est configuré en tant que moteur principal, il dispose de toutes les fonctionnalités. Il reçoit et transmet des informations de routage, construit et gère des tables de routage, communique avec les interfaces et les composants du moteur de transfert de paquets, et a un contrôle total sur le châssis. Lorsqu’un moteur de routage est configuré pour être la sauvegarde, il ne communique pas avec le moteur de transfert de paquets ou les composants du châssis.

Note:

Sur les équipements exécutant Junos OS version 8.4 ou ultérieure, les deux moteurs de routage ne peuvent pas être configurés pour être primaires en même temps. Cette configuration entraîne l’échec de la vérification de validation.

Un basculement du moteur de routage principal vers le moteur de routage de secours se produit automatiquement lorsque le moteur de routage principal rencontre une défaillance matérielle ou que vous avez configuré le logiciel pour prendre en charge une modification du rôle principal en fonction de conditions spécifiques. Vous pouvez également basculer manuellement le rôle principal du moteur de routage en émettant l’une request chassis routing-engine des commandes. Dans cette rubrique, le terme basculement fait référence à un événement automatique, tandis que le basculement fait référence à un événement automatique ou manuel.

En cas de basculement ou de basculement, le moteur de routage de secours prend le contrôle du système en tant que nouveau moteur de routage principal.

• Si le basculement du moteur de routage n’est pas configuré, lorsque le moteur de routage de secours devient principal, il réinitialise le plan de commutation et télécharge sa propre version du microkernel sur les composants du moteur de transfert de paquets. Le trafic est interrompu pendant que le moteur de transfert de paquets est réinitialisé. Tous les processus de noyau et de transfert sont redémarrés.

• Si le basculement du moteur de routage est configuré, les informations sur l’interface et le noyau sont préservé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). Tous les matériels et interfaces sont acquis par un processus similaire à un redémarrage à chaud.

• Si le basculement du moteur de routage sans interruption et le routage actif sans interruption (NSR) sont configurés, le trafic n’est pas interrompu pendant le basculement. Les informations sur l’interface, le noyau et le protocole de routage sont préservées.

• Si le basculement et le redémarrage progressif du moteur de routage sont configurés, le trafic n’est pas interrompu pendant le basculement. Les informations sur l’interface et le noyau sont préservées. Les extensions de protocole graceful restart collectent et restaurent rapidement les informations de routage des routeurs voisins.

Conditions qui déclenchent le basculement d’un moteur de routage

Les événements suivants peuvent entraîner une modification automatique du rôle principal du moteur de routage, en fonction de votre configuration :

• La plate-forme de routage subit une défaillance matérielle. Un changement dans le rôle principal du moteur de routage se produit si le moteur de routage ou le module ou le sous-système hôte associé est soudainement hors tension. Vous pouvez également configurer le moteur de routage de secours pour qu’il prenne le rôle principal s’il détecte une erreur de disque dur sur le moteur de routage principal. Pour activer cette fonctionnalité, incluez l’instruction failover on-disk-failure au niveau de la [edit chassis redundancy] hiérarchie.

• La plate-forme de routage subit une défaillance logicielle, telle qu’un plantage du noyau ou un verrouillage du processeur. Vous devez configurer le moteur de routage de secours pour qu’il joue le rôle principal lorsqu’il détecte une perte de signal de maintien. Pour activer cette méthode de basculement, incluez l’instruction failover on-loss-of-keepalives au niveau de la [edit chassis redundancy] hiérarchie.

• La plate-forme de routage rencontre une défaillance d’interface em0 sur le moteur de routage principal. Vous devez configurer le moteur de routage de secours pour qu’il joue le rôle principal lorsqu’il détecte la défaillance de l’interface em0. Pour activer cette méthode de basculement, incluez l’instruction on-re-to-fpc-stale au niveau de la [edit chassis redundancy failover] hiérarchie.

• Un processus logiciel spécifique échoue. Vous pouvez configurer le moteur de routage de secours pour qu’il prenne le rôle principal lorsqu’un ou plusieurs processus spécifiés échouent au moins quatre fois dans les 30 secondes. Incluez l’instruction failover other-routing-engine au niveau de la [edit system processes process-name] hiérarchie.

Si l’une de ces conditions est remplie, un message est enregistré et le moteur de routage de secours tente de jouer un rôle principal. Par défaut, une alarme est générée lorsque le moteur de routage de secours devient actif. Une fois que le moteur de routage de secours a joué le rôle principal, il continue de fonctionner en tant que moteur de routage principal même après que le moteur de routage principal configuré à l’origine a repris son fonctionnement avec succès. Vous devez le restaurer manuellement à son statut de sauvegarde précédent. (Toutefois, si à tout moment l’un des moteurs de routage n’est pas présent, l’autre moteur de routage devient automatiquement principal, quelle que soit la configuration de la redondance.)

Comportement de redondance du moteur de routage par défaut

Par défaut, Junos OS utilise re0 comme moteur de routage principal et re1 comme moteur de routage de secours. Sauf indication contraire dans la configuration, re0 devient toujours primaire lorsque le moteur de routage principal est redémarré.

Note:

Un seul moteur de routage dans le châssis devient toujours le moteur de routage principal, même s’il était auparavant le moteur de routage de secours.

Suivez les étapes suivantes pour voir comment fonctionne le paramètre de redondance du moteur de routage par défaut :

1. Assurez-vous que re0 est le moteur de routage principal.

2. Changez manuellement l’état du rôle principal du moteur de routage en émettant la request chassis routing-engine master switch commande du moteur de routage principal. re0 est désormais le moteur de routage de secours et re1 est le moteur de routage principal.

   Note:

   Lors du prochain redémarrage du moteur de routage principal, Junos OS renvoie le routeur à l’état par défaut, car vous n’avez pas configuré les moteurs de routage pour maintenir cet état après un redémarrage.

3. Redémarrez le moteur de routage principal re1.

   Le moteur de routage démarre et lit la configuration. Comme vous n’avez pas spécifié dans la configuration quel moteur de routage est le moteur de routage principal, re1 utilise la configuration par défaut comme sauvegarde. Aujourd’hui, les deux re0 et re1 sont dans un état de secours. Junos OS détecte ce conflit et, pour éviter un état non primaire, revient à la configuration par défaut pour diriger re0 à devenir primaire.

Redondance du moteur de routage sur un routeur TX Matrix

Dans une matrice de routage, tous les moteurs de routage principaux du routeur TX Matrix et les routeurs T640 connectés doivent exécuter la même version Junos OS. De même, tous les moteurs de routage de secours d’une matrice de routage doivent exécuter la même version Junos OS. Lorsque vous exécutez la même version Junos OS sur tous les moteurs de routage primaires et de secours dans une matrice de routage, une modification du rôle principal par un moteur de routage de secours dans la matrice de routage n’entraîne pas de modification du rôle principal dans un autre châssis de la matrice de routage.

ATTENTION:

(Matrice de routage basée sur la matrice TX ou les routeurs TX Matrix Plus uniquement) Dans la matrice de routage, nous recommandons que tous les moteurs de routage exécutent la même version Junos OS. Si vous exécutez différentes versions sur les moteurs de routage et qu’un changement de rôle principal survient sur un moteur de routage de secours dans la matrice de routage basée sur le routeur TX Matrix ou le routeur TX Matrix Plus, un ou tous les routeurs peuvent être logiquement déconnectés du routeur TX Matrix ou du routeur TX Matrix Plus et entraîner une perte de données.

Si la même version junos OS n’est pas exécutée sur tous les moteurs de routage primaires et de secours dans la matrice de routage, les conséquences suivantes se produisent lorsque l’instruction failover on-loss-of-keepalives is incluse au niveau de la [edit chassis redundancy] hiérarchie :

• Lorsque l’instruction failover on-loss-of-keepalives est incluse au niveau de la [edit chassis redundancy] hiérarchie et que vous ou un sous-système hôte initiez une modification du rôle principal du moteur de routage de secours dans le routeur TX Matrix, les moteurs de routage principaux des routeurs T640 détectent une incompatibilité de version logicielle avec le nouveau moteur de routage principal dans le routeur TX Matrix et remplacent le rôle principal vers leurs moteurs de routage de secours.

• Lorsque vous remplacez manuellement le rôle principal par un moteur de routage de secours dans un routeur T640 à l’aide de la request chassis routing-engine master commande, le nouveau moteur de routage principal du routeur T640 détecte une incompatibilité de version logicielle avec le moteur de routage principal du routeur TX Matrix et abandonne le rôle principal au moteur de routage principal d’origine. (Le rôle principal du moteur de routage dans le routeur TX Matrix ne change pas dans ce cas.)

• Lorsqu’un sous-système hôte initie un changement de rôle principal vers un moteur de routage de secours dans un routeur T640 en raison de l’échec du moteur de routage principal, le routeur T640 est logiquement déconnecté du routeur TX Matrix. Pour reconnecter le routeur T640, initiez une modification du rôle principal au moteur de routage de secours dans le routeur TX Matrix, ou remplacez le moteur de routage défaillant dans le routeur T640 et remplacez-lui le rôle principal. Le moteur de routage de remplacement doit exécuter la même version logicielle que le moteur de routage principal dans le routeur TX Matrix.

Si la même version junos OS n’est pas exécutée sur tous les moteurs de routage primaires et de secours dans la matrice de routage, les conséquences suivantes se produisent lorsque l’instruction failover on-loss-of-keepalives is not incluse au niveau de la [edit chassis redundancy] hiérarchie :

• Si vous modifiez le rôle principal du moteur de routage de secours dans le routeur TX Matrix, tous les routeurs T640 sont logiquement déconnectés du routeur TX Matrix. Pour reconnecter les routeurs T640, changez le rôle principal de tous les moteurs de routage principaux des routeurs T640 vers leurs moteurs de routage de secours.

• Si vous initiez une modification du rôle principal à un moteur de routage de secours dans un routeur T640, le routeur T640 est logiquement déconnecté du routeur TX Matrix. Pour reconnecter le routeur T640, changez le rôle principal du nouveau moteur de routage principal du routeur T640 vers le moteur de routage principal d’origine.

Redondance du moteur de routage sur un routeur TX Matrix Plus

Dans une matrice de routage, tous les moteurs de routage principaux du routeur TX Matrix Plus et le LCC connecté doivent exécuter la même version Junos OS. De même, tous les moteurs de routage de secours d’une matrice de routage doivent exécuter la même version Junos OS. Lorsque vous exécutez la même version Junos OS sur tous les moteurs de routage principal et de secours dans la matrice de routage, une modification du rôle principal par un moteur de routage de secours dans la matrice de routage n’entraîne pas de changement du rôle principal dans un autre châssis de la matrice de routage.

ATTENTION:

(Matrice de routage basée sur la matrice TX ou les routeurs TX Matrix Plus uniquement) Dans la matrice de routage, nous recommandons que tous les moteurs de routage exécutent la même version Junos OS. Si vous exécutez différentes versions sur les moteurs de routage et qu’un changement de rôle principal survient sur un moteur de routage de secours dans la matrice de routage basée sur un routeur TX Matrix ou un routeur TX Matrix Plus, un ou tous les routeurs peuvent être logiquement déconnectés du routeur TX Matrix ou du routeur TX Matrix Plus et entraîner une perte de données.

Si la même version Junos OS ne s’exécute pas sur tous les moteurs de routage primaires et de secours dans la matrice de routage, les scénarios suivants se produisent lorsque l’instruction failover on-loss-of-keepalives is incluse au niveau de la [edit chassis redundancy] hiérarchie :

• Lorsque l’instruction failover on-loss-of-keepalives est incluse au niveau de la [edit chassis redundancy] hiérarchie et que vous ou un sous-système hôte initiez une modification du rôle principal du moteur de routage de secours dans le routeur TX Matrix Plus, les moteurs de routage primaires de la LCC connectée détectent une incompatibilité de version logicielle avec le nouveau moteur de routage principal dans le routeur TX Matrix Plus et commutateurnt le rôle principal de leurs moteurs de routage de secours.

• Lorsque vous remplacez manuellement le rôle principal par un moteur de routage de secours dans une LCC connectée à l’aide de la request chassis routing-engine master commande, le nouveau moteur de routage principal de la LCC connectée détecte une incompatibilité entre une version logicielle et le moteur de routage principal du routeur TX Matrix Plus et abandonne le rôle principal au moteur de routage principal d’origine. (Le rôle principal du moteur de routage dans le routeur TX Matrix Plus ne change pas dans ce cas.)

• Lorsqu’un sous-système hôte initie un changement de rôle principal dans un moteur de routage de secours dans une LCC connectée en raison de l’échec du moteur de routage principal, le LCC connecté est logiquement déconnecté du routeur TX Matrix Plus. Pour reconnecter le LCC connecté, initiez une modification du rôle principal du moteur de routage de secours dans le routeur TX Matrix Plus, ou remplacez le moteur de routage défaillant dans le LCC connecté et remplacez-lui le rôle principal. Le moteur de routage de remplacement doit exécuter la même version logicielle que le moteur de routage principal du routeur TX Matrix Plus.

Si la même version Junos OS ne s’exécute pas sur tous les moteurs de routage primaires et de secours dans la matrice de routage, les scénarios suivants se produisent lorsque l’instruction failover on-loss-of-keepalives is not incluse au niveau de la [edit chassis redundancy] hiérarchie :

• Si vous modifiez le rôle principal du moteur de routage de secours dans le routeur TX Matrix Plus, tous les LPC connectés sont logiquement déconnectés du routeur TX Matrix Plus. Pour reconnecter les LCC connectés, changez le rôle principal de tous les moteurs de routage principaux de la LCC connectée à leurs moteurs de routage de secours.

• Si vous modifiez le rôle principal d’un moteur de routage de secours dans une LCC connectée, le LCC connecté est logiquement déconnecté du routeur TX Matrix Plus. Pour reconnecter le LCC connecté, changez le rôle principal du nouveau moteur de routage principal dans le LCC connecté au moteur de routage principal d’origine.

Situations nécessitant l’arrêt des moteurs de routage

Avant d’éteindre l’alimentation d’une plate-forme de routage qui dispose de deux moteurs de routage ou avant de supprimer le moteur de routage principal, vous devez d’abord arrêter le moteur de routage de secours, puis le moteur de routage principal. Sinon, vous devrez peut-être réinstaller Junos OS. Vous pouvez utiliser la request system halt both-routing-engines commande sur le moteur de routage principal, qui arrête d’abord le moteur de routage principal, puis le moteur de routage de secours. Pour arrêter uniquement le moteur de routage de secours, émettez la request system halt commande sur le moteur de routage de secours.

Si vous arrêtez le moteur de routage principal et ne le débranchez pas ou ne le retirez pas, le moteur de routage de secours reste inactif à moins que vous ne l’ayez configuré pour qu’il devienne le principal lorsqu’il détecte une perte de signal de maintien du moteur de routage principal.

Note:

Pour redémarrer le routeur, vous devez vous connecter au port console (plutôt qu’au port de gestion Ethernet) du moteur de routage. Lorsque vous vous connectez au port de console du moteur de routage principal, le système redémarre automatiquement. Une fois que vous vous êtes connecté au port de console du moteur de routage de secours, appuyez sur Entrée pour le redémarrer.

Note:

Si vous avez mis à niveau le moteur de routage de secours, redémarrez-le d’abord, puis redémarrez le moteur de routage principal.