Basculement WAN DMVPN : politique de routage ou fermeture du tunnel ?

Un concentrateur DMVPN à double WAN bascule de l'une de deux manières, et la différence est plus grande qu'il n'y paraît. L'une change le saut suivant choisi par une politique de routage, de sorte que les paquets continuent de circuler et que seule leur sortie change. L'autre ferme administrativement le tunnel, ce qui entraîne avec lui tous les services de cette interface. Les deux peuvent être correctes, car elles répondent à des questions différentes.

La décision précède la configuration

Trois conditions tranchent pour vous. Autre chose dépend-il du fait que l'interface du tunnel soit active, comme un second profil DMVPN ou un moniteur qui lit son état ? Le trafic qui doit basculer porte-t-il sa propre politique, ou s'appuie-t-il sur la table de routage globale ? Et l'opérateur a-t-il besoin d'un changement d'état sans ambiguïté, ou un basculement de chemin silencieux est-il acceptable ? Répondez à ces trois questions et le choix se fait généralement tout seul.

Si une fermeture faisait tomber des services qui fonctionnaient, la politique de routage est l'action la plus petite. Si l'exigence est que le tunnel n'existe pas tant que le WAN principal est en panne, aucune entrée de politique ne peut l'exprimer.

Écrivez la réponse, car la configuration est la partie facile.

Ce que la politique de routage change réellement

Avec le routage basé sur des politiques, un objet suivi peut contrôler un saut suivant. L'entrée de la route-map nomme un saut suivant candidat et l'objet suivi qui doit être actif pour qu'il soit utilisé, et cet état de suivi provient d'une sonde IP SLA. Lorsque l'objet tombe, l'entrée cesse de correspondre et le paquet est évalué par l'entrée suivante ou par la table de routage ordinaire.

Ce dernier détail surprend : une politique qui cesse de choisir un saut suivant autorise généralement le routage normal plutôt que de bloquer le trafic. Si vous avez besoin de un trou noir en cas de panne, vous devez l'écrire.

La syntaxe diffère selon les plateformes et les versions, alors consultez le guide de la version que vous exécutez réellement.

Ce que la fermeture du tunnel change

Fermer une interface change l'état administratif. Chaque tunnel, route et session qui en dépend tombe d'un coup, ce qui est exactement ce que vous voulez si le tunnel est la chose qui doit disparaître. C'est aussi ainsi qu'un applet EEM transforme un problème WAN en panne qui inclut des services sans rapport.

Si vous prenez ce chemin, limitez l'applet à une interface et un déclencheur, enregistrez l'état administratif précédent, définissez l'action de rétablissement et assurez-vous que des basculements répétés ne peuvent pas l'entraîner dans une boucle.

Une commande de rétablissement codée en dur peut aussi annuler un arrêt de maintenance effectué par quelqu'un d'autre.

Faites voyager la sonde sur le chemin que vous croyez

Une sonde qui suit la meilleure route actuelle se déplace vers le WAN de secours avec tout le reste, puis déclare le primaire sain parce qu'elle ne l'utilise plus.

Épinglez la sonde à l'interface ou à l'adresse source du chemin que vous testez. Vérifiez aussi ce qu'elle cible, car atteindre le saut suivant du fournisseur prouve moins que d'atteindre le service pour lequel le tunnel existe. Réglez les délais de montée et de descente délibérément : un délai de descente court réagit vite et oscille, tandis qu'un long absorbe les micro-coupures et masque les vraies pannes. Le guide Cisco sur le suivi et le routage basé sur des politiques dans IOS XE documente les combinaisons prises en charge, et le jeu de fonctionnalités de votre plateforme décide lesquelles vous pouvez utiliser.

Notez les deux valeurs de délai à côté de l'objet suivi, sinon personne ne saura pourquoi il s'est comporté ainsi.

Décidez du rétablissement, puis vérifiez

Le rétablissement mérite sa propre décision. Un lien qui franchit sans cesse le seuil peut déplacer des sessions plus souvent qu'un lien clairement défaillant, et chaque déplacement coûte une renégociation des clés et des reprises de l'application. Choisissez une exigence de stabilité et laissez le délai l'exprimer. Vérifiez ensuite pendant une fenêtre de changement avec le chemin de la sonde visible : route sélectionnée, chemin du pair externe et ce que l'application a réellement fait.

Si le basculement fonctionne mais que l'application casse encore, le problème se situe au-dessus de la couche de routage et aucun suivi ne le corrigera.

Conservez les preuves de cette fenêtre, car le prochain changement sera comparé à elles.