OSPF ou EIGRP sur un VTI d’ASA : lequel votre version prend-elle en charge

La plupart des débats OSPF contre EIGRP supposent que le tunnel peut déjà transporter le protocole, et sur un ASA c’est précisément cette hypothèse qu’il faut vérifier en premier. La comparaison ne devient intéressante qu’une fois l’image, le type de VTI et le chemin multicast confirmés. Se tromper dans cet ordre, c’est passer un après-midi à régler des temporisateurs sur un tunnel qui ne formera jamais d’adjacence. Je commence chacun de ces projets par les notes de version et la configuration en cours, pas par la préférence de protocole.

La version décide avant le protocole

Le guide VTI de Cisco pour l’ASA 9.24 est une base documentaire exploitable : il décrit les VTI statiques et dynamiques et liste le routage statique, BGP, OSPF et EIGRP. Son historique de fonctionnalités place la prise en charge d’OSPFv2 et d’EIGRP sur VTI à la 9.19(1). Tout ce qui est plus ancien est une autre conversation.

Les deux premières questions sont donc ennuyeuses et décisives :

L’affirmation qu’un ASA ne peut pas utiliser de VTI, ou ne peut pas transporter un IGP, était vraie pour certaines images anciennes et ne constitue pas une matrice de prise en charge actuelle. De même, le guide 9.24 n’est pas une consigne de mise à niveau de chaque équipement. Il indique ce que cette version prend en charge, et votre version déployée doit répondre pour elle-même.

Le passage de l’unicast ne signifie pas que l’IGP se formera

Le même guide note que l’unicast passe par défaut et que le multicast doit être activé pour OSPFv2 ou EIGRP sur le VTI, avec des limites documentées sur les groupes multicast. Cette seule phrase explique la plupart des adjacences ratées que j’ai vues sur ce type de projet. Un ping qui fonctionne à travers le tunnel, ou un statut IPsec au vert, ne prouve que le chemin unicast. La découverte du protocole a besoin du chemin multicast, et les deux se configurent séparément.

Vérifiez la présence de ce réglage multicast dans la configuration de l’interface tunnel avant de toucher aux temporisateurs hello ou hold. Si le réglage est absent, l’adjacence n’est pas lente, elle est impossible.

OSPF et EIGRP côte à côte sur le même tunnel

Sur le tunnel lui-même, les deux protocoles ressemblent à ce qu’ils sont ailleurs. OSPF exige un type de réseau correspondant, une zone, une authentification et des paramètres de voisin ; EIGRP a besoin de son numéro d’AS et des réglages au niveau de l’interface qui vont avec.

Le piège est de recopier des instructions de voisin d’un autre modèle de tunnel. Les conseils sur les voisins statiques dans une conception sans VTI existaient pour éviter le multicast, et ils ne se transposent pas à un VTI censé transporter le protocole nativement. Configurez le comportement d’interface pris en charge, puis laissez le protocole former sa propre adjacence.

Comparez ensuite sur les axes qui diffèrent réellement pour votre topologie : l’interopérabilité avec l’autre côté, le comportement de convergence que vous pouvez tester et la connaissance opérationnelle de votre équipe. Une anecdote historique selon laquelle un protocole serait plus rapide ou plus léger n’est pas une mesure de votre réseau.

Les voisins ne valent pas les routes installées

Une fois l’adjacence établie, distinguez ce qui est originaire de ce qui est accepté. Regardez quels préfixes de branche chaque côté annonce, lesquels sont reçus, lesquels sont sélectionnés et lesquels atteignent réellement la table de routage. La portée de l’import, de l’export et de la redistribution doit être délibérée plutôt qu’une annonce générale de tout ce que l’équipement connaît.

show ospf neighbor et show eigrp neighbors vous indiquent que la session est active. show route vous indique si le préfixe de la branche est arrivé, et ce sont des questions différentes.

Le chemin applicatif est encore une troisième question. Une relation de voisinage distribue l’accessibilité ; elle n’accorde pas d’autorisation à travers le pare-feu et ne prouve pas que les sélecteurs de trafic et les règles de filtrage s’accordent. Vérifiez le flux autorisé et son chemin de retour par un test approuvé plutôt que de supposer que la route implique la politique.

Ce que la comparaison terminée doit consigner

Notez l’interface tunnel, la version qui la prend en charge, l’échange de contrôle que vous avez vérifié et la politique de routes que vous avez bornée. Ajoutez le réglage multicast, car c’est le détail qui décide silencieusement si le reste fonctionne. Conservez cette trace à côté de la version déployée afin qu’un changement de fonctionnalité ultérieur puisse être examiné sans repartir d’une hypothèse depuis lors expirée.

S’il manque l’un de ces quatre éléments, vous avez une préférence et non une conception. Corrigez d’abord le fait manquant ; le choix du protocole est la partie facile.