Dépannage de l'échec du couplage haute disponibilité sur FDM

Problème

L'appariement haute disponibilité (HA) entre deux appliances Cisco Firepower 1120 exécutant FTD 7.4.2.4 échoue lors de la synchronisation des applications avec le noeud secondaire qui passe systématiquement à l'état Failed en raison d'une non-concordance du mode d'enregistrement de licence. Le message d'erreur spécifique rencontré est le suivant :

CD App Sync error FDM validation failure License registration mode mismatch between Primary and Secondary Node Check appsynchistory CLI for details

La commande show app-sync-history révèle des échecs répétés avec des messages tels que :

App Sync Status: FAILURE
Failed Reason: FDM validation failure - License agent compliance mismatch between Primary and Secondary Node

Ce problème est survenu après la réinitialisation des deux pare-feu, la restauration des configurations à partir de la sauvegarde, la mise à jour du logiciel vers la version FTD 7.4.2.4, la mise à jour des versions VDB et Snort et la réapplication des licences avec de nouveaux jetons. Le pare-feu secondaire reste à l'état Échec, ce qui empêche la haute disponibilité et affecte la redondance du pare-feu.

Environnement

• Appareils de pare-feu de nouvelle génération Cisco Firepower 1120 configurés pour la haute disponibilité

• Firepower Threat Defense (FTD) version 7.4.2.4-9

• Moteur d'inspection Snort : 3.1.53.2003 - 175

• VDB : 425.0

• Base de données de géolocalisation : 2026-03-07-053

• Périphériques convertis du mode Smart Licensing au mode PLR (Permanent License Reservation)

• Périphérique principal essayant une connectivité cloud après la conversion PLR

• Les deux périphériques restaurés à partir de la sauvegarde

Résolution

La résolution implique l'identification et la correction de la non-concordance du mode d'enregistrement de licence entre les périphériques principal et secondaire, l'exécution d'une annulation d'enregistrement dans le cloud et l'achèvement d'un déploiement complet.

Étape 1: Identifier la non-concordance du mode d'enregistrement de licence

Vérifiez le mode d'enregistrement de licence sur les deux périphériques en recherchant dans l'historique de synchronisation des applications les raisons spécifiques de l'échec :

show app-sync-history

Le résultat affiche les échecs indiquant :

FDM validation failure – License registration mode mismatch between Primary and Secondary node

Étape 2: Effectuer la désinscription du cloud

Étant donné que le périphérique principal tentait toujours de se connecter au cloud après la conversion de Smart Licensing en mode PLR, l'annulation de l'inscription au cloud est requise.

Configurez un proxy temporaire dans l'interface utilisateur de FDM (si aucun proxy n'est configuré) :

Accédez à Paramètres système > Voir plus > onglet Proxy HTTP et configurez temporairement un proxy factice [cela peut être supprimé ultérieurement].

Installez SSH dans le périphérique FTD et exécutez le script du connecteur :

ssh admin@<device-ip>
expert
sudo su
/ngfw/var/sf/bin/connector.sh

Étape 3: Résolution du conflit du port 8989

Si le script du connecteur échoue avec cette erreur :

Error: listen tcp :8989: bind: address already in use

Identifiez et terminez le processus à l'aide du port 8989 (généralement Cisco Success Network) :

netstat -tulpn | grep 8989
kill <pid>

Étape 4: Désinscription complète du cloud

Exécutez à nouveau le script de connecteur après avoir résolu le conflit de port :

/ngfw/var/sf/bin/connector.sh

L'exécution réussie doit afficher un résultat similaire à :

Starting connector
INFO[0000] [firepower][functions.go:162 common:LogEnv] Environment variable: https_proxy=http://1xx.xx.xx.xx:80
INFO[0000] [firepower][functions.go:162 common:LogEnv] Environment variable: http_proxy=http://1xx.xx.xx.xx:80

Accédez à FDM GUI, System Settings > Cloud Services > Cloud Services et cliquez sur unregister option. Vérifiez que le périphérique n'est pas enregistré auprès des services cloud.

Étape 5: Déploiement complet et reprise de la haute disponibilité

Après la désinscription du cloud, si le jumelage HA échoue toujours avec la même erreur de non-correspondance de licence, effectuez un déploiement complet sur l'unité active via l'interface FDM.

Accédez à Déployer > Déployer maintenant et terminez le processus de déploiement.

Une fois le déploiement terminé, recommencez la formation de la haute disponibilité. Les périphériques doivent former une paire HA active-veille avec des interfaces connectées et à l'état prêt.

Étape 6: Vérifier l'état HA

Confirmer la réussite de la formation HA :

show failover

Le résultat doit indiquer que les deux unités sont dans un état de haute disponibilité correct et que la synchronisation a réussi.

Motif

La cause principale était une non-concordance du mode d'enregistrement de licence entre les périphériques Firepower 1120 principal et secondaire. Les périphériques ont été convertis du mode Smart Licensing au mode PLR (Permanent License Reservation) ; cependant, le périphérique principal a continué à tenter une connectivité cloud, ce qui a entraîné une incohérence dans l'état de conformité agent de licence/exportation lors de la validation HA. Cela a entraîné des échecs répétés de validation FDM/FIM lors de la synchronisation des applications. En outre, la désinscription du cloud a été initialement bloquée par un conflit de port 8989 lié à Cisco Success Network, qui a nécessité une résolution avant que la désinscription puisse se poursuivre.

Autres informations utiles

• Application de licences permanentes dans les réseaux à interconnexion d'air

• Réinstaller un pare-feu sécurisé contre les menaces

• Assistance technique de Cisco et téléchargements

Historique de révision

Révision	Date de publication	Commentaires
1.0	16-Oct-2026	Première publication