Lorsque vous exécutez le Hot Standby Router Protocol (HSRP) entre deux routeurs connectés au moyen d'un commutateur de réseau local, vous pourrez constater une instabilité du HRSP. Celle-ci se produit souvent lors d'une interruption du réseau ou d'une transition vers un routeur actif tel qu'un routeur HSRP prioritaire et configuré pour la prévention que l'on ajoute au réseau local. Ce document explique pourquoi cette instabilité se produit et décrit les façons de l'éviter.
Aucune spécification déterminée n'est requise pour ce document.
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
Pour plus d'informations sur les conventions des documents, référez-vous aux Conventions utilisées pour les conseils techniques de Cisco.
Cette section vous fournit des informations pour configurer les fonctionnalités décrites dans ce document.
Remarque : Pour en savoir plus sur les commandes utilisées dans le présent document, utilisez l’outil de recherche de commandes (clients inscrits seulement).
Ce document utilise la configuration réseau indiquée dans le diagramme suivant :
Ce document utilise les configurations suivantes :
Router A |
---|
interface FastEthernet1/0 ip address 10.144.220.3 255.255.252.0 standby priority 120 standby preempt standby ip 10.144.220.1 |
Router B |
---|
interface FastEthernet3/0 ip address 10.144.220.2 255.255.252.0 standby priority 110 standby preempt standby ip 10.144.220.1 |
Aucune procédure de vérification n'est disponible pour cette configuration.
Cette section fournit des informations que vous pouvez utiliser pour dépanner votre configuration.
Certaines commandes show sont prises en charge par l'Output Interpreter Tool (clients enregistrés uniquement), qui vous permet de voir une analyse de la sortie de la commande show.
Remarque : Avant d'utiliser les commandes debug, reportez-vous à Informations importantes sur les commandes de débogage.
debug standby
Dans le schéma ci-dessus, lorsque le routeur A est ajouté au réseau, vous pouvez observer l'état HSRP du routeur B basculer d'actif en veille. L'exécution de la commande debug standby sur le routeur B génère le résultat suivant :
RouterB# debug standby *Mar 1 02:55:56: SB0:FastEthernet3/0 Hello out 10.144.220.2 Active pri 110 hel 3 hol 10 ip 10.144.220.1 *Mar 1 02:56:08: SB0:FastEthernet3/0 Hello in 10.144.220.3 Active pri 120 hel 3 hol 10 ip 10.144.220.1 *Mar 1 02:56:08: SB0: FastEthernet3/0 state Active -> Speak *Mar 1 02:56:08: SB0:FastEthernet3/0 Resign out 10.144.220.2 Speak pri 110 hel 3 hol 10 ip 10.144.220.1 *Mar 1 02:56:08: SB0:FastEthernet3/0 Hello out 10.144.220.2 Speak pri 110 hel 3 hol 10 ip 10.144.220.1 *Mar 1 02:56:09: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet3/0, changed state to down *Mar 1 02:56:11: SB0: FastEthernet3/0 state Speak -> Init *Mar 1 02:56:13: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet3/0, changed state to up *Mar 1 02:56:13: SB0: FastEthernet3/0 state Init -> Listen *Mar 1 02:56:14: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet3/0, changed state to down *Mar 1 02:56:14: SB0: FastEthernet3/0 state Listen -> Init *Mar 1 02:56:20: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet3/0, changed state to up *Mar 1 02:56:20: SB0: FastEthernet3/0 state Init -> Listen *Mar 1 02:56:30: SB0: FastEthernet3/0 state Listen -> Speak *Mar 1 02:56:40: SB0: FastEthernet3/0 state Speak -> Standby *Mar 1 02:56:41: SB0: FastEthernet3/0 state Standby -> Active *Mar 1 02:56:41: SB: FastEthernet3/0 Adding 0000.0c07.ac00 to address filter *Mar 1 02:56:41: SB0:FastEthernet3/0 Hello out 10.144.220.2 Active pri 110 hel 3 hol 10 ip 10.144.220.1 *Mar 1 02:56:44: SB0:FastEthernet3/0 Hello in 10.144.220.3 Active pri 120 hel 3 hol 10 ip 10.144.220.1 *Mar 1 02:56:44: SB0: FastEthernet3/0 state Active -> Speak
D'après le résultat ci-dessus, il est clair que l'état HSRP du routeur B change continuellement d'Actif à Parler en Veille à Actif, etc.
Le processus HSRP utilise l'adresse de multidiffusion 224.0.0.2 pour communiquer des paquets Hello avec les autres routeurs HSRP. Si la connectivité est perdue ou si un routeur HSRP avec une priorité plus élevée est ajouté à un réseau, les états HSRP peuvent commencer à clignoter comme indiqué ci-dessus. Lors de l'exécution de HSRP sur certaines plates-formes de routeur (voir Note ci-dessous) et l'ajout d'un routeur de priorité supérieure au réseau, l'état HSRP du routeur de priorité inférieure passe d'Actif à Parler et un changement d'état de liaison se produit. Le port du commutateur détecte cette modification d’état des liaisons et une transition de protocole Spanning Tree a lieu. Le port prend environ 30 secondes pour passer par les étapes d’écoute, d’apprentissage et de transmission. Cette période dépasse les délais d'attente par défaut des processus Hello HSRP, de sorte que le routeur de priorité inférieure, après avoir atteint l'état Veille, devient Actif car aucun paquet Hello n'a été reçu du routeur Actif.
Puisque les routeurs ne voient pas les paquets Hello HSRP de l'autre, ils deviennent tous deux actifs. Lorsque les ports du commutateur passent à l’état Apprentissage, il est possible que le commutateur voit la même adresse MAC virtuelle sur deux ports différents.
Remarque : Les modifications d'état des liaisons physiques provoquées par les changements d'état HSRP se produisent spécifiquement sur les interfaces NM-FE (Network Module-Fast Ethernet) des routeurs des gammes Cisco 2600, Cisco 3600 et Cisco 7200. Ce comportement ne se produit plus dans le logiciel Cisco IOS® version 12.1(3) et ultérieure.
Pour plus d'informations, consultez l'ID de bogue Cisco CSCdr02376 (clients enregistrés uniquement).
Effectuez l'une des tâches suivantes afin de résoudre le problème décrit ci-dessus.
Configurez le commutateur avec la commande set spantree portfast enable, qui permet au commutateur de contourner les états spantree et de passer directement à l'état Forwarding.
Si le routeur est configuré pour relier des paquets sur cette interface/port, cette solution de contournement ne peut pas être utilisée, car le transfert immédiat sur une telle liaison peut rendre le réseau sujet à une panne de boucle de transfert.
Remarque : Cette restriction s'applique également aux ports de commutateur connectés à d'autres commutateurs ou ponts.
Modifiez les temporisateurs HSRP de sorte que le délai de transmission du Spanning Tree (par défaut de 15 secondes) soit inférieur à la moitié du temps de retenue du HSRP (par défaut de 10 secondes).
Nous suggérons un temps de retenue HSRP de 40 secondes.
Remarque : l'augmentation du temps de maintien de HSRP rend HSRP plus lent dans la détection de l'arrêt du routeur actif et la mise en veille du routeur.
Assurez-vous qu'il n'y a pas de tempêtes de paquets sur le réseau (IPX est sujet aux tempêtes de paquets).
Configurez la commande standby use-bia, qui force le routeur actif HSRP à utiliser l'adresse de gravure.
Cela accomplit deux choses. Puisque HSRP n'a plus besoin de modifier (ou d'ajouter) une adresse MAC de monodiffusion à la liste de filtrage des adresses MAC, l'interface Ethernet n'est pas réinitialisée. Il empêche également le commutateur d’apprendre la même adresse sur deux ports différents. Référez-vous à Qu'est-ce que la commande standby use-bia et Comment fonctionne-t-elle ? pour plus d'informations.
Remarque : L'utilisation de la commande standby use-bia présente les inconvénients suivants :
Quand un routeur devient actif, l'adresse IP virtuelle est déplacée vers une adresse MAC différente. Le nouveau routeur actif envoie une réponse gratuite du protocole de résolution d'adresse (ARP) mais toutes les implémentations d'hôte ne gèrent pas correctement l'ARP gratuit.
Le proxy ARP se brise lorsque standby use-bia est configuré. Un routeur de secours ne peut pas couvrir la base de données ARP de proxy perdue du routeur défaillant.
En raison de limitations internes, la commande standby use-bia n'est pas prise en charge sur la carte MSFC2 (Multilayer Switch Feature Card 2). Pour plus d'informations, reportez-vous à la section Configuration Guidelines and Restrictions de Configuration de la commutation de couche 3 monodiffusion IP sur Supervisor Engine 2.
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
02-Jun-2008 |
Première publication |