Un second tunnel monte, la table de routage n’affiche toujours qu’un chemin, et la conclusion évidente est que le protocole ne l’a pas remarqué. En général, il l’a remarqué et l’a refusé. EIGRP n’installe une sauvegarde que lorsqu’elle passe un test précis sans boucle, et le fait qu’un tunnel soit actif ne dit rien sur la question de savoir si la distance annoncée du voisin passe ce test. Cette distinction est toute la réponse, et c’est de l’arithmétique, pas une minuterie.

La condition, énoncée exactement

RFC 7868 définit la condition de faisabilité comme une vérification suffisante du chemin sans boucle d’un voisin : la distance annoncée par le voisin pour une destination doit être strictement inférieure à la distance réalisable locale. Strictement. Pas inférieure ou égale.

Cette seule inégalité est ce qui fait d’une alternative un successeur réalisable. Tout le reste ici n’est que comptabilité autour d’elle.

Deux distances aux rôles différents

La distance annoncée est ce que le voisin annonce pour la destination. La distance réalisable est un relevé de la plus petite métrique totale connue depuis la dernière transition ACTIVE–PASSIVE, ce qui explique pourquoi elle peut différer de la métrique du meilleur chemin actuel. Confondre les deux produit des conclusions fausses et assurées.

Dans un affichage opérationnel, plusieurs colonnes qui ressemblent à des distances se côtoient. Lisez l’en-tête de la colonne que vous utilisez et rappelez-vous que la métrique complète calculée du chemin d’un voisin n’est pas la même grandeur que la distance qu’il vous a annoncée.

Une comparaison travaillée

Prenez un exemple déclaré avec une distance réalisable de 1000. Un voisin qui annonce 900 passe le test et peut devenir un successeur réalisable. Un voisin qui annonce 1000 échoue, car la condition est une inégalité stricte et l’égalité ne suffit pas.

Ces nombres sont de l’arithmétique, pas des vitesses de liaison. Ne les lisez pas comme une prédiction sur un routeur particulier ni comme une métrique recommandée.

Détecter n’est pas être éligible

Un mécanisme peut remarquer rapidement un pair mort alors qu’EIGRP n’a toujours aucun remplacement éligible. Remarquer est une étape ; le calcul coordonné de route en est une autre, et il ne commence que lorsqu’aucun successeur réalisable n’existe. Échouer à la condition ne prouve pas que l’alternative boucle physiquement. Cela signifie que le test local de raccourci n’a pas établi la garantie, donc le calcul doit gérer le résultat.

Raccourcir une minuterie de vivacité ne peut pas créer une joignabilité qui n’a jamais existé, et modifier une bande passante ou une valeur de délai configurée n’est pas une mesure de capacité.

Lisez les champs, puis testez l’application

Relevez la destination, le successeur actuel, le voisin candidat, sa distance annoncée, la distance réalisable et l’état de route résultant. show ip eigrp topology 10.10.10.0/24 vous en donne la majeure partie pour un seul préfixe. Reliez ensuite la décision au chemin de tunnel qui porte réellement le saut suivant, car la table de routage et la table des tunnels peuvent ne pas s’accorder sur l’interface utilisée.

Sous une observation approuvée, suivez trois choses séparément : la détection, la sélection de route et la reprise propre à l’application. Cette séquence vous dit si la pièce manquante est une sauvegarde éligible, le chemin VPN en dessous ou la charge de travail qui se reconnecte, au lieu de supposer que chaque reprise lente exige une minuterie de plus.

L’habitude utile est de vérifier l’inégalité avant de toucher à quoi que ce soit d’autre. Une seule commande suffit et elle tranche le débat.

Articles similaires