Configuration du routage actif ininterrompu
Configurez le routage actif ininterrompu sur votre appareil en suivant les étapes et exemples suivants.
Activation du routage actif ininterrompu
NSR (NonStop active Routing) nécessite la configuration du basculement GRES (Graceful Moteur de routage Switchover). Pour permettre un basculement fluide du moteur de routage, incluez l’instruction suivante graceful-switchover au niveau de la [edit chassis redundancy] hiérarchie :
[edit chassis redundancy] graceful-switchover;
Par défaut, le routage actif ininterrompu est désactivé. Pour activer le routage actif ininterrompu, incluez l’instruction suivante nonstop-routing au niveau de la [edit routing-options] hiérarchie :
[edit routing-options] nonstop-routing;
Pour désactiver le routage actif ininterrompu, supprimez l’instruction nonstop-routing du niveau hiérarchique [edit routing-options] .
Lorsque vous activez le routage actif ininterrompu, vous ne pouvez pas activer les distingueurs de route automatiques pour les instances de routage VPN multicast. Les distingueurs de route automatiques sont activés en configurant l’instruction route-distinguisher-id au niveau de la [edit routing-instances instance-name] hiérarchie ; pour plus d’informations, reportez-vous à la bibliothèque de VPN Junos OS pour les périphériques de routage.
Si le processus de protocole de routage (rpd) du moteur de routage principal NSR se bloque, le moteur de routage principal redémarre simplement rpd (sans basculement du moteur de routage), ce qui a un impact sur les proximités et les voisins du protocole de routage et entraîne une perte de trafic. Pour éviter cet impact négatif sur le flux de trafic, configurez l’instruction switchover-on-routing-crash au niveau de la [edit system] hiérarchie. Cette configuration force un basculement du moteur de routage NSR si rpd du moteur de routage principal se bloque.
[edit system] user@host# set switchover-on-routing-crash
Pour permettre à la plate-forme de routage de basculer vers le moteur de routage de secours lorsque le processus du protocole de routage (rpd) échoue rapidement trois fois de suite, incluez l’instruction other-routing-engine au niveau de la [edit system processes routing failover] hiérarchie.
Pour plus d’informations sur l’instruction other-routing-engine , reportez-vous à la bibliothèque d’administration de Junos OS pour les périphériques de routage.
Synchronisation de la configuration du moteur de routage
Lorsque vous configurez un routage actif ininterrompu, vous devez également inclure l’instruction au niveau de la hiérarchie afin que les commit synchronize [edit system] modifications de configuration soient synchronisées sur les deux moteurs de routage :
[edit system]commit synchronize;
Si vous essayez de valider la configuration de routage actif ininterrompue sans inclure l’instruction commit synchronize , la validation échoue.
Si vous configurez l’instruction commit synchronize au niveau de la [edit system] hiérarchie et que vous émettez une validation dans le moteur de routage principal, la configuration principale est automatiquement synchronisée avec la sauvegarde.
Toutefois, si le moteur de routage de sauvegarde est indisponible lorsque vous émettez la validation, Junos OS affiche un avertissement et valide la configuration candidate dans le moteur de routage principal. Lorsque le moteur de routage de sauvegarde apparaît, sa configuration sera automatiquement synchronisée avec le principal.
Un moteur de routage de secours nouvellement inséré synchronise automatiquement sa configuration avec la configuration du moteur de routage principal.
Lorsque vous configurez un routage actif ininterrompu, vous pouvez mettre en ligne le moteur de routage de secours une fois que le moteur de routage principal est déjà en cours d’exécution. Il n’est pas nécessaire de démarrer les deux moteurs de routage simultanément.
Nous vous recommandons de ne pas redémarrer le processus de protocole de routage (rpd) sur le moteur de routage principal après avoir activé le routage actif ininterrompu, car cela perturbe les sessions d’adjacence/d’appairage du protocole, entraînant une perte de trafic.
Vérification d’un routage actif ininterrompu
Pour savoir si le routage actif ininterrompu est activé ou non, exécutez la show task replication commande. Pour le routage actif ininterrompu BGP, vous devez également exécuter la show bgp replication commande.
Si BGP est configuré, avant de tenter un basculement de routage actif ininterrompu, vérifiez la sortie de pour confirmer que la synchronisation de show bgp replication la table de routage BGP est terminée sur le moteur de routage de secours. L’état complete de la sortie de show task replication indique uniquement que la réplication du socket est terminée et que la synchronisation BGP est en cours. Pour déterminer si la synchronisation BGP est terminée, vous devez cocher les Protocol state champs et Synchronization state dans la sortie de show bgp replication sur le moteur de routage principal. Le Protocol state must be idle et le Synchronization state must be complete. Si vous effectuez un basculement NSR avant la fin de la synchronisation BGP, la session BGP peut être instable.
Lorsque vous activez le routage actif ininterrompu ou le basculement normal du moteur de routage et que vous émettez des commandes de mode opérationnel liées au routage sur le moteur de routage de secours (par exempleshow route, , show bgp neighborshow ospf database, , etc.), la sortie peut ne pas correspondre à la sortie des mêmes commandes émises sur le moteur de routage principal. Par exemple, il est normal que la table de routage du moteur de routage de sauvegarde contienne des routes fantômes persistantes qui ne sont pas présentes dans la table de routage du moteur de routage principal.
Pour afficher l’état de réplication de l’état BFD, exécutez la show bfd session commande. L’indicateur replicated apparaît dans la sortie de cette commande lorsqu’une session BFD a été répliquée sur le moteur de routage de sauvegarde.
Configuration d’un routage actif ininterrompu sur les commutateurs
Le NSR (NonStop active Routing) fournit un mécanisme permettant de basculer les moteurs de routage de manière transparente sans nécessiter le redémarrage des protocoles de routage pris en charge. Les deux moteurs de routage sont pleinement actifs dans le traitement des sessions de protocole, de sorte que chacun peut prendre le relais de l’autre. Le basculement est transparent pour les voisins.
Vous pouvez configurer NSR sur un commutateur Juniper Networks EX Series doté de plusieurs moteurs de routage ou sur un commutateur EX Series ou QFX Series dans une configuration Virtual Chassis ou Virtual Chassis Fabric.
Pour configurer un routage actif ininterrompu :
Il n’est pas nécessaire de démarrer les deux moteurs de routage simultanément. Si le moteur de routage de secours n’est pas activé lorsque vous exécutez la commit synchronize commande , la configuration candidate est validée dans le moteur de routage principal. Lorsque le moteur de routage de secours est inséré ou mis en ligne, sa configuration est automatiquement synchronisée avec celle du moteur principal.
Après un basculement normal du moteur de routage, nous vous recommandons d’exécuter la clear interface statistics (interface-name | all) commande pour réinitialiser les valeurs cumulées des statistiques locales sur le nouveau moteur de routage principal.
Pour désactiver le routage actif ininterrompu :
[edit routing-options] user@switch# delete nonstop-routing
Empêcher le rétablissement automatique des sessions BGP Peer après le basculement NSR
Il est utile d’empêcher le rétablissement automatique d’une session pair BGP après un basculement NSR (NonStop Active Routing) lorsque vous avez appliqué des stratégies de routage configurées dans la base de données dynamique. Lorsque NSR est activé, la base de données dynamique n’est pas synchronisée avec le moteur de routage de sauvegarde. Par conséquent, lorsqu’un basculement se produit, les stratégies d’importation et d’exportation configurées dans la base de données dynamique peuvent ne plus être disponibles. Pour plus d’informations sur la configuration de stratégies de routage dynamique, reportez-vous au Guide de l’utilisateur Stratégies de routage, filtres de pare-feu et mécanismes de contrôle du trafic.
Les temporisateurs établis par BGP ne sont pas maintenus entre les basculements.
Vous pouvez configurer le périphérique de routage pour qu’il ne rétablisse pas une session pair BGP après un basculement NSR, soit pendant une période spécifiée, soit jusqu’à ce que vous rétablissiez manuellement la session. Incluez l’instruction idle-after-switch-over au niveau de la [edit protocols bgp] hiérarchie :
idle-after-switch-over (forever | seconds);
Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez configurer cette instruction, reportez-vous au résumé de l’instruction de configuration de cette instruction.
Pour seconds, spécifiez une valeur comprise entre 1 et 4294967295. La session pair BGP n’est rétablie qu’après la période spécifiée. Si vous spécifiez l’option forever , la session pair BGP n’est pas rétablie tant que vous n’avez pas exécuté la clear bgp neighbor commande.
Exemple : Configuration d’un routage actif ininterrompu
L’exemple suivant permet le basculement gracieux du moteur de routage, le routage actif ininterrompu et les options de traçage de routage actif ininterrompu pour BGP, IS-IS et OSPF.
[edit]
system commit {
synchronize;
}
chassis {
redundancy {
graceful-switchover; # This enables graceful Routing Engine switchover on
# the routing platform.
}
}
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.0.1.1/30;
}
family iso;
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.1.1.1/30;
}
family iso;
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.2.1.1/30;
}
family iso;
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.3.1.1/30;
}
family iso;
}
}
lo0 {
unit 0 {
family inet {
address 192.168.2.1/32;
}
family iso {
address 49.0004.1921.6800.2001.00;
}
}
}
}
routing-options {
nonstop-routing; # This enables nonstop active routing on the routing platform.
router-id 192.168.2.1;
autonomous-system 65432;
}
protocols {
bgp {
traceoptions {
flag nsr-synchronization detail; # This logs nonstop active routing
# events for BGP.
}
advertise-from-main-vpn-tables;
local-address 192.168.2.1;
group external-group {
type external;
export BGP_export;
neighbor 192.168.1.1 {
family inet {
unicast;
}
peer-as 65103;
}
}
group internal-group {
type internal;
neighbor 192.168.10.1;
neighbor 192.168.11.1;
neighbor 192.168.12.1;
}
}
isis {
traceoptions {
flag nsr-synchronization detail; # This logs nonstop active routing events
# for IS-IS.
}
interface all;
interface fxp0.0 {
disable;
}
interface lo0.0 {
passive;
}
}
ospf {
traceoptions {
flag nsr-synchronization detail; # This logs nonstop active routing events
# for OSPF.
}
area 0.0.0.0 {
interface all;
interface fxp0.0 {
disable;
}
interface lo0.0 {
passive;
}
}
}
}
policy-options {
policy-statement BGP_export {
term direct {
from {
protocol direct;
}
then accept;
}
term final {
then reject;
}
}
}
Réinitialisation des statistiques locales
Après un basculement normal du moteur de routage, nous vous recommandons d’exécuter la clear interface statistics (interface-name | all) commande pour réinitialiser les valeurs cumulées des statistiques locales sur le nouveau moteur de routage principal.
Exemple : Configuration d’un routage actif ininterrompu sur des commutateurs
Le NSR (NonStop active Routing) assure une haute disponibilité des moteurs de routage en permettant une commutation transparente des moteurs de routage sans nécessiter le redémarrage des protocoles de routage pris en charge. Les deux moteurs de routage sont pleinement actifs dans le traitement des sessions de protocole, de sorte que chacun peut prendre le relais de l’autre. Le basculement est transparent pour les voisins.
Cet exemple décrit comment configurer un routage actif ininterrompu sur des commutateurs dotés de plusieurs moteurs de routage ou sur des commutateurs EX Series ou QFX Series dans une configuration Virtual Chassis ou Virtual Chassis Fabric.
Exigences
Cet exemple utilise les composants matériels et logiciels suivants :
Un EX Series avec plusieurs moteurs de routage ou sur un commutateur EX Series ou QFX Series dans une configuration Virtual Chassis ou Virtual Chassis Fabric
Junos OS version 10.4 ou ultérieure pour les commutateurs EX Series
Junos OS version 13.2X51-D20 ou ultérieure pour les commutateurs QFX Series
Vue d’ensemble et topologie
Configurez le routage actif ininterrompu sur n’importe quel commutateur EX Series doté de plusieurs moteurs de routage, ou sur un commutateur EX Series ou QFX Series dans une configuration Virtual Chassis ou Virtual Chassis Fabric. Le routage actif ininterrompu est avantageux dans les réseaux où les périphériques de routage voisins ne prennent pas en charge les extensions de protocole de redémarrage gracieux.
La topologie utilisée dans cet exemple se compose d’un commutateur EX8200 avec des moteurs de routage redondants connectés à des périphériques de routage voisins qui ne sont pas configurés pour prendre en charge le redémarrage normal des protocoles.
Configuration
Configuration rapide de la CLI
Pour configurer rapidement un routage actif ininterrompu, copiez les commandes suivantes et collez-les dans la fenêtre du terminal du commutateur :
[edit] set chassis redundancy graceful-switchover set routing-options nonstop-routing set system commit synchronize
Procédure
Procédure étape par étape
Pour configurer un routage actif ininterrompu sur un commutateur :
Activer le basculement GRES (Graceful Moteur de routage) :
[edit chassis redundancy] user@switch# set graceful-switchover
Activer le routage actif ininterrompu (par défaut, le routage actif ininterrompu est désactivé) :
[edit routing-options] user@switch# set nonstop-routing
Synchronisez les changements de configuration entre les moteurs de routage :
[edit system] user@switch# set commit synchronize
Si vous essayez de valider la configuration de routage actif ininterrompue sans inclure l’instruction
commit synchronize, la validation échoue.Note:Si le moteur de routage de secours est indisponible lorsque vous émettez la validation, un avertissement s’affiche et la configuration candidate est validée dans le moteur de routage principal. Lorsque le moteur de routage de secours est activé, sa configuration est automatiquement synchronisée avec celle du moteur principal. Si, par la suite, vous insérez ou affichez un moteur de routage de secours, il synchronise automatiquement sa configuration avec la configuration principale du moteur de routage.
Résultats
Vérifiez les résultats de la configuration :
[edit]
user@switch# show
chassis {
redundancy {
graceful-switchover;
}
routing-options {
nonstop-routing;
}
system {
commit synchronize;
}
Vérification
Pour vérifier que la configuration fonctionne correctement, effectuez les opérations suivantes :
Vérification du bon fonctionnement du routage actif ininterrompu sur le commutateur
But
Vérifiez que le routage actif ininterrompu est activé.
Action
Lancez la show task replication commande :
user@switch# show task replication
Stateful Replication: Enabled
RE mode: Master
Protocol Synchronization Status
OSPF Complete
RIP Complete
PIM Complete
RSVP Complete
Signification
Cette sortie indique que le routage actif ininterrompu (réplication dynamique) est activé sur le moteur de routage principal. Si le routage ininterrompu n’est pas activé, au lieu de la sortie indiquée ci-dessus :
Sur le moteur de routage de secours, le message d’erreur suivant s’affiche : «
error: the routing subsystem is not running. »Sur le moteur de routage principal, la sortie suivante s’affiche si le routage ininterrompu n’est pas activé :
Stateful Replication: Disabled RE mode: Master
Dépannage
Pour résoudre les problèmes liés au routage actif ininterrompu, effectuez les tâches suivantes :
Étude des problèmes de synchronisation des moteurs de routage lorsque NSR est activé
Problème
Un protocole perd sa connectivité avec ses voisins après qu’un basculement GRES (Graceful Moteur de routage) s’est produit alors que le routage actif ininterrompu (NSR) est activé.
Solution
Utilisez les options de suivi pour isoler le problème et collecter des informations de dépannage. À l’aide des informations recueillies à partir des options de suivi, vous pouvez confirmer ou éliminer la synchronisation des moteurs de routage comme cause de la perte de connectivité du protocole. Reportez-vous à la section Suivi d’événements de synchronisation de routage actif ininterrompu.