Le module ASA FirePOWER n’a aucune route de gestion vers FMC

FMC affiche le module comme injoignable, l’enregistrement reste en attente et un ping depuis l’intérieur de l’ASA fonctionne parfaitement. Sur un déploiement ASA FirePOWER existant, cette combinaison est normale. Le module possède sa propre adresse de gestion, sa propre passerelle par défaut et ses propres décisions de routage, et le partage d’une connexion de gestion physique avec l’ASA sur certaines plateformes ne fusionne pas tout cela en une seule pile réseau. Deux appareils répondent selon deux points de vue différents sur le même câble.

Ce qui suit s’applique aux modules déjà en service. Identifiez le modèle de châssis, le type de module et la version logicielle prise en charge avant d’appliquer un schéma de ports tiré d’un guide.

Dessinez le module comme un hôte distinct

Commencez le schéma par l’adresse IP de gestion du module, le masque et la passerelle par défaut, le VLAN qui transporte réellement cette connexion et l’adresse FMC à joindre. Ensuite, dans un cadre séparé, écrivez les adresses d’interface de l’ASA et sa table de routage complète. Si les deux cadres finissent par partager un sous-réseau avec des adresses appartenant à des propriétaires différents, vous avez trouvé la partie intéressante du problème.

Le guide du module ASA FirePOWER montre comment les dispositions de ports varient selon les plateformes, y compris le câblage de gestion partagé où l’ASA et le module portent des adresses distinctes sur le même segment. Ce schéma matériel est une donnée d’entrée de la conception, pas une note de bas de page.

Trouvez où le chemin de retour se casse

Prenez une disposition routée par le cœur. Le module envoie le trafic destiné à FMC vers un cœur Layer 3, le cœur achemine la destination de gestion distante vers l’interface interne de l’ASA, et le VPN du site le transporte de l’autre côté. Le site distant a alors besoin d’une route de retour vers le sous-réseau de gestion du module. Chaque saut de cette chaîne peut être correct alors que cette dernière route manque, et c’est pourquoi la panne ressemble si souvent à un tunnel cassé.

Lisez la vision de l’ASA lui-même avant de modifier quoi que ce soit :

show interface ip brief
show route
show running-config interface

La troisième commande compte parce qu’une adresse d’interface oubliée est exactement ce qui fait atterrir le chemin de retour sur le mauvais appareil.

Vérifiez ce que l’ASA considère comme connecté

Si l’ASA détient une adresse sur le sous-réseau de gestion du module, sa route connectée possède ce préfixe. Une route statique vers le cœur ne déplace pas la propriété de la route connectée, donc le paquet revient vers l’ASA et s’y arrête. L’enregistrement échoue alors à un point qui n’a rien à voir avec les identifiants.

Ne concluez pas qu’un contrôle anti-usurpation précis a rejeté le paquet sans avoir devant vous les observations de l’appareil lui-même. Comparez plutôt l’interface d’entrée, la route de destination sélectionnée et la limite de transfert entre gestion et données prise en charge pour cette plateforme. Ces trois faits exposent généralement le conflit de topologie avant que quiconque commence à réinitialiser les clés d’enregistrement.

Choisissez une correction qui garde le module connecté

Retirer l’adresse de l’ASA de ce segment et désactiver physiquement un port partagé ne sont pas des actions équivalentes. Sur les plateformes où le module emprunte la même connexion de gestion physique, désactiver le port supprime le seul lien du module — vous aurez transformé un problème de routage en appareil mort. Préférez le changement qui réattribue la propriété du routage de gestion et préparez-le en présence du propriétaire du réseau.

Une seconde option prise en charge consiste à donner au chemin administratif de l’ASA son propre segment afin que le sous-réseau de gestion du module n’ait qu’un propriétaire. Cela coûte une adresse et un peu de documentation, et supprime définitivement l’ambiguïté. Quel que soit le chemin choisi, confirmez ensuite que le module peut toujours joindre à la fois FMC et ses sources DNS ou NTP.

N’enregistrez qu’une fois le chemin cohérent

Une fois le chemin de retour propre, planifiez la connectivité de gestion et les paramètres d’enregistrement à partir du guide de version correspondant de FMC et du module. Gardez les secrets d’enregistrement hors des notes et tickets partagés et résistez à la tentation de réenregistrer comme étape de diagnostic : une nouvelle clé sur un chemin cassé ne produit que la même panne avec un horodatage plus récent.

Acceptez le chemin depuis la pile de gestion du module elle-même plutôt que depuis un ping émis par l’ASA, car la source du test est précisément ce qui est suspect. Notez le prochain saut du module, la sélection VPN de l’ASA et la route de réponse de FMC, et conservez une méthode de récupération indépendante pour les deux rôles de gestion. C’est cette trace qui sépare un transport réparé d’un enregistrement réussi.

Lorsque le module apparaît enfin dans FMC, relancez les mêmes trois commandes et enregistrez la sortie à côté du schéma. La prochaine personne à toucher ce segment de gestion aura besoin exactement de cette comparaison.