Configuration d’une connexion Heartbeat Virtual Chassis

Avantages de la configuration d’une connexion Heartbeat Virtual Chassis

La configuration d’une connexion de pulsation Virtual Chassis offre les avantages suivants pour un Virtual Chassis :

• Résilience améliorée en cas de défaillance

  La configuration de la connexion par pulsation améliore la résilience de Virtual Chassis en cas de rupture ou de scission causée par une défaillance des interfaces de port Virtual Chassis, ou lorsque l’un des routeurs membres tombe en panne. Si la connexion Heartbeat détecte que le routeur principal Virtual Chassis (VC-P) fonctionne toujours et est capable de répondre pendant un fractionnement, le logiciel conserve le rôle principal sur le VC-P existant, isole le routeur de sauvegarde Virtual Chassis (VC-B) jusqu’à ce que le Virtual Chassis récupère et reprend le rôle de sauvegarde sur le VC-B lorsque le Virtual Chassis se reforme. Par conséquent, la connexion par pulsation empêche les routeurs membres de modifier inutilement les rôles principaux, ce qui consomme des ressources système et provoque des résultats inattendus et indésirables.

  Lorsque le VC-B est isolé pendant une interruption, le logiciel redémarre immédiatement toutes les cartes d’interface et éteint tous les ports réseau jusqu’à ce que l’interruption soit résolue et que le Virtual Chassis se forme à nouveau. Ce comportement prend en charge les applications réseau avec des équipements externes qui nécessitent une condition physique de liaison descendante pour basculer les chemins de trafic vers d’autres connexions.

• Amélioration du processus électoral des primaires

  Le protocole VCCP (Virtual Chassis Control Protocol) contrôle l’élection du rôle principal dans un Virtual Chassis. Lorsque vous configurez la connexion de pulsation dans un Virtual Chassis, le logiciel VCCP évalue les informations d’intégrité collectées à partir de la connexion de pulsation pour déterminer quel routeur membre doit devenir le principal global (VC-P) en cas de perturbation ou de scission par adjacence. Lorsque la connexion Heartbeat détecte que le routeur membre pair est réactif, le logiciel VCCP supprime les modifications inutiles dans les rôles principaux.

  En revanche, lorsque la connexion de pulsation n’est pas configurée, le logiciel VCCP ne dispose pas de ces informations d’intégrité supplémentaires pour déterminer les rôles principaux appropriés après une interruption ou une scission.

• Possibilité de visualiser et d’effacer facilement les statistiques liées à la connexion des pulsations

  Les commandes opérationnelles de Virtual Chassis vous permettent d’afficher l’état de la connexion de pulsation, d’examiner les statistiques détaillées et les mesures de latence liées à la connexion de pulsation, et d’effacer les compteurs de statistiques et les champs d’horodatage liés à la pulsation pour un ou les deux routeurs membres.

Configuration requise pour la connexion Heartbeat

Pour établir une connexion de pulsation pour un Virtual Chassis, vous devez configurer une route sécurisée et fiable entre le routeur principal et le routeur de secours pour l’échange de paquets de pulsation TCP/IP. Plus précisément, vous devez vous assurer que le moteur de routage principal du routeur de secours Virtual Chassis (VC-Bp) peut établir une connexion TCP/IP à l’adresse master-only IP du moteur de routage principal du routeur principal Virtual Chassis (VC-Pp).

Les exigences supplémentaires suivantes s’appliquent lorsque vous configurez la connexion de pulsation :

• Configurez la connexion de pulsation uniquement entre les routeurs membres de Virtual Chassis éligibles pour devenir le routeur principal de Virtual Chassis, également appelé protocole principal ou primaire global.

  Dans une configuration Virtual Chassis à deux membres, vous attribuez le routing-engine rôle à chaque routeur dans le cadre de la configuration préprovisionnée. Ce routing-engine rôle permet au routeur de fonctionner comme routeur principal ou comme routeur de secours du Virtual Chassis, selon les besoins. Par conséquent, vous pouvez configurer la connexion de pulsation entre les deux routeurs membres dans une configuration Virtual Chassis à deux membres.

• Utilisez l’interface de gestion Ethernet du routeur (fxp0) comme chemin de pulsation.

  L’interface de gestion est généralement disponible plus tôt que les interfaces de carte de ligne et est généralement connectée à un réseau plus sécurisé que les autres interfaces.

• Configurez une master-only adresse IP pour l’interface fxp0 de gestion afin de garantir un accès cohérent au VC-PP, quel que soit le moteur de routage actuellement actif.

  L’adresse master-only n’est active que sur l’interface de gestion du VC-Pp. Lors d’un basculement, l’adresse master-only est déplacée vers le nouveau moteur de routage qui fonctionne actuellement sous le nom de VC-PP.

• Assurez-vous de la connectivité TCP entre les routeurs membres VC-Pp et VC-Bp

  La connexion de pulsation de Virtual Chassis ouvre un port TCP propriétaire numéroté 33087 sur le VC-PP pour écouter les messages de pulsation. Si la conception de votre réseau comprend des pare-feu ou des filtres, assurez-vous que le réseau autorise le trafic entre le port TCP 33087 du VC-PP et le port TCP attribué dynamiquement sur le VC-Bp.

• Lorsque vous utilisez une connexion par pulsation, ne configurez pas l’instruction dans le no-split-detection cadre de la configuration préprovisionnée de Virtual Chassis.

  L’instruction no-split-detection supprime toute action lorsqu’un fractionnement est détecté dans le Virtual Chassis. L’utilisation de l’instruction no-split-detection est interdite lorsque vous configurez une connexion de pulsation, et le logiciel vous empêche de configurer les no-split-detection instructions et heartbeat-address en même temps. Si vous tentez de le faire, le logiciel affiche un message d’erreur et entraîne l’échec de l’opération de validation.

Dans un Virtual Chassis à deux membres, vous pouvez configurer une connexion de pulsation avec les deux routeurs membres du même sous-réseau ou avec chaque routeur membre dans un sous-réseau différent. Le Tableau 1 résume les différences importantes entre les procédures de configuration des routeurs membres dans le même sous-réseau et les routeurs membres dans différents sous-réseaux.

Tableau 1 : comparaison des tâches de configuration de connexion Heartbeat pour les routeurs membres du même sous-réseau et les routeurs membres dans différents sous-réseaux

Tâche	Connexion par pulsation pour les routeurs membres d’un même sous-réseau	Connexion par pulsation pour les routeurs membres de différents sous-réseaux
Configurez l’adresse IP de fxp0 l’interface master-only de gestion.	Configurez la même fxp0 master-only adresse IP pour les quatre moteurs de routage membres.	Configurez deux adresses IP différentes master-only pour l’interface fxp0 de gestion : une adresse pour le sous-réseau dans lequel réside le routeur principal Virtual Chassis et une pour le sous-réseau dans lequel réside le routeur de secours.
Configurez un chemin d’accès réseau pour la connexion de pulsation.	Fournissez un chemin permettant aux routeurs membres de se joindre les uns aux autres au moyen d’une connexion TCP/IP. Par exemple, dans un Virtual Chassis avec des routeurs membres dans le même sous-réseau, vous pouvez utiliser la passerelle par défaut du routeur. Vous pouvez également créer une route statique globale comme décrit dans Exemple : Détermination de l’intégrité des membres à l’aide d’une connexion Heartbeat MX Series Virtual Chassis avec des routeurs membres dans le même sous-réseau.	Fournissez un chemin permettant aux routeurs membres de se joindre les uns aux autres au moyen d’une connexion TCP/IP. Dans un Virtual Chassis avec des routeurs membres dans différents sous-réseaux, vous devez vous assurer que les deux routeurs membres peuvent atteindre le réseau de l’autre. Par exemple, vous pouvez créer des routes statiques vers les deux sous-réseaux de chaque moteur de routage membre, comme décrit dans Exemple : Détermination de l’intégrité des membres à l’aide d’une connexion Heartbeat MX Series Virtual Chassis avec des routeurs membres dans différents sous-réseaux.
Configurez l’adresse de pulsation pour établir la connexion de pulsation.	Configurez une adresse IP unique (globale) master-only pour l’interface fxp0 de gestion comme adresse de pulsation pour établir la connexion.	Configurez une adresse de pulsation pour chaque moteur de routage membre afin de se connecter de manière croisée à l’adresse master-only IP du moteur de routage correspondant dans l’autre sous-réseau. Par exemple, supposons que member0-re0 et member0-re1 résident dans le sous-réseau 10.4.0.0, et member1-re0 et et member1-re1 résident dans le sous-réseau 10.5.0.0. Dans cette configuration, vous devez définir l’adresse de pulsation pour member0-re0 l’adresse master-only IP pour member1-re0 la connexion member0-re0 croisée et member1-re0. Vous vous connecteriez member0-re1 member1-re1 et de la même manière.

Comment fonctionne la connexion Heartbeat

Lorsque le Virtual Chassis fonctionne correctement, la connexion de pulsation envoie périodiquement des paquets de pulsation sur le chemin TCP/IP entre le moteur de routage principal du routeur principal du Virtual Chassis et le moteur de routage principal du routeur de secours Virtual Chassis.

Lorsqu’une interruption ou un fractionnement d’adjacence est détecté dans le Virtual Chassis, chaque routeur membre envoie un dernier message de pulsation pour déterminer si l’autre membre est en mesure de répondre, et cesse d’envoyer des messages périodiques supplémentaires jusqu’à ce que le Virtual Chassis se forme à nouveau. L’autre membre doit répondre au message de pulsation dans le délai d’expiration par défaut (2 secondes) ou dans un délai d’expiration configuré compris entre 1 et 60 secondes. Pour déterminer le délai qui s’écoule sur votre réseau entre l’envoi d’un message de demande de pulsation et la réception d’un message de réponse de pulsation, vous pouvez lancer la show virtual-chassis heartbeat detail commande pour afficher le nombre de secondes indiqué dans les Maximum latency champs et Minimum latency .

Bonne pratique :

Si votre réseau est encombré ou présente une latence aller-retour supérieure à 2 secondes, nous vous recommandons d’augmenter la valeur du délai d’expiration des pulsations pour tenir compte de ce retard lors d’une interruption ou d’un fractionnement de l’adjacence Virtual Chassis.

Conditions de défaillance de la connexion Heartbeat et du Virtual Chassis

La configuration de la connexion de pulsation empêche les changements de rôle principal inutiles entre les routeurs membres de Virtual Chassis lorsqu’une interruption ou une scission d’adjacence se produit. Le Tableau 2 décrit les effets sur le rôle principal des conditions de défaillance courantes lorsque vous activez la connexion de pulsation dans un Virtual Chassis à deux membres.

Tableau 2 : effet de la connexion Heartbeat sur les conditions de défaillance courantes du Virtual Chassis

Condition de défaillance	Résultat sur le routeur principal Virtual Chassis (VC-P)	Résultat sur le routeur de sauvegarde Virtual Chassis (VC-B)
Les interfaces de port Virtual Chassis tombent en panne.	Conserve le rôle de VC-P.	Si le VC-P est en service mais que les interfaces de port Virtual Chassis sont hors service, le VC-B est hors ligne après l’expiration du délai d’expiration du pulsation, car l’état du moteur de routage n’est pas valide.
Le châssis VC-P tombe en panne.	Hors service.	Devient VC-P.
Le châssis VC-B tombe en panne.	Conserve le rôle de VC-P.	Hors service.
Échec de la connexion Heartbeat.	Conserve le rôle de VC-P.	Conserve le rôle de VC-B.

Dans tous les cas, sauf en cas de défaillance du châssis VC-P, le rôle principal du Virtual Chassis est conservé sur le VC-Pp existant si la connexion Heartbeat détecte que le VC-P fonctionne toujours et est capable de répondre pendant un fractionnement. Éviter un changement de rôle inutile minimise la charge système causée par un changement de rôle principal de protocole et réduit la probabilité de résultats imprévisibles.

L’absence de connexion Virtual Chassis Heartbeat et la perte d’adjacence VCP sont des conditions de double défaillance qui reviennent effectivement au comportement de « non-split-detection ». Les deux membres ne sont pas en mesure de vérifier l’état de leur routeur membre pair. Virtual Chassis Heartbeat utilise les réactions de « no-split-detection », qui obligent VC-P à rester dans le rôle de maître de protocole et VC-B à VC-P. Cette condition de « maître fractionné » n’est pas idéale pour les protocoles de routage et autres mécanismes de gestion de la topologie. Dans ce scénario, la condition maître fractionné est préférable au fonctionnement sans aucun membre maître de protocole.

Virtual Chassis communication Heartbeat n’est active que lorsque le Virtual Chassis est correctement formé et que les rôles de châssis des membres VC-P et VC-B sont élus. Les rôles déterminés lors d’une perte d’adjacence VCP sont conservés jusqu’à ce que le Virtual Chassis soit correctement formé. Perturbation de Virtual Chassis connectivité Heartbeat n’a pas d’impact sur les rôles de protocole dans le Virtual Chassis pendant la durée des conditions de « fractionnement ».

Connexion par pulsation comparée à la détection fractionnée

Dans certaines conditions de défaillance de Virtual Chassis, le paramètre de détection de fractionnement (activé par défaut ou explicitement désactivé) peut entraîner des résultats imprévisibles et indésirables, tels qu’un Virtual Chassis avec deux routeurs principaux ou un Virtual Chassis sans routeur principal.

Bonne pratique :

Il est obligatoire d’utiliser la connexion Heartbeat au lieu de la fonctionnalité de détection de fractionnement dans un Virtual Chassis pour éviter les changements inutiles de rôle principal lors d’une interruption ou d’un fractionnement par adjacence, et pour fournir des informations supplémentaires sur l’intégrité des membres pour le processus de sélection du rôle principal.

Le Tableau 3 compare les effets de la détection fractionnée et de la connexion de pulsation pour deux conditions de défaillance courantes : la défaillance des interfaces de port Virtual Chassis et la défaillance du châssis VC-B.

Tableau 3 : comparaison de la connexion Heartbeat et de la détection fractionnée pour les conditions de défaillance de Virtual Chassis

Condition de défaillance	Résultats avec la connexion Heartbeat	Résultats avec la détection de fractionnement
Les interfaces de port Virtual Chassis tombent en panne.	Le châssis VC-P conserve le rôle VC-P. Si le châssis VC-P est en service mais que les interfaces de port Virtual Chassis sont hors service, le châssis VC-B est hors ligne après l’expiration du délai d’expiration du pulse, car l’état du moteur de routage n’est pas valide.	Lorsque la détection de fractionnement est désactivée : Le châssis VC-P conserve le rôle VC-P. Le châssis VC-B joue également le rôle de VC-P. Virtual Chassis possède deux routeurs principaux, chacun conservant des informations sur l’état de l’abonné. L’effet sur les abonnés, les schémas de trafic, le comportement des applications externes et les opérations de connexion et de déconnexion des abonnés est imprévisible lorsque les interfaces de port Virtual Chassis sont déconnectées.
Le châssis VC-B tombe en panne.	Le châssis VC-P conserve le rôle VC-P. Le châssis VC-B est hors service.	Lorsque la détection de fractionnement est activée : Le châssis VC-P joue le rôle de carte de ligne (VC-L), ce qui l’isole et le supprime du Virtual Chassis jusqu’à ce que la connectivité soit rétablie. Le châssis VC-B est hors service. Virtual Chassis n’a pas de routeur principal. Cet état arrête le routage interchâssis et désactive effectivement la configuration Virtual Chassis.