Avec Cisco Firepower Threat Defense (FTD), les fonctionnalités de pare-feu avec état classiques offertes par Adaptive Security Appliances (ASA) et Next-Gen fonctionnalités de pare-feu (optimisées par Snort) sont désormais regroupés en un seul produit.

En raison de ce changement, Policy Deployment Infrastructure sur FTD gère désormais les modifications de configuration pour le code ASA (également appelé LINA) et Snort dans une offre groupée.

Conditions préalables

Cisco recommande de connaître ces produits :

Firepower Management Center (FMC)
Firepower Threat Defense (FTD)

Composants utilisés

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Présentation du déploiement des politiques

Utilisation de Cisco FTD Policy Deployments pour gérer et diffuser les configurations des périphériques enregistrés auprès de Firepower Management Center (FMC).

À l'intérieur du déploiement, une série d'étapes sont divisées en « phases ».

Les phases FMC peuvent être résumées dans cette liste.

Phase 0	Initialisation du déploiement
Phase 1	Database Object, collection
Phase 2	Collection Policy and Object
Phase 3	Génération de la configuration de ligne de commande NGFW
Phase 4	Génération de package de déploiement de périphérique
Phase 5	Envoi et réception du package de déploiement
Phase 6	Messages de déploiement, d'actions de déploiement et de réussite de déploiement en attente

La connaissance des phases et de l'emplacement des pannes dans le processus peut aider à dépanner les pannes qu'un Firepower faces du système.

Dans certaines situations, il peut s'agir d'un conflit dû à des configurations précédentes ou causé par un Advanced Flex Configuration qui ne contient pas de mot clé pouvant entraîner des défaillances auxquelles le rapport de périphérique ne répond pas.

Exemple de présentation

Étape 1. Cliquer Deployment, qui spécifie le périphérique à sélectionner.

Étape 2. Lorsque le déploiement d’un périphérique est validé, le FMC commence à collecter toutes les configurations pertinentes pour le périphérique.

Étape 3. Lorsque les configurations sont collectées, le FMC crée le package et l'envoie au capteur via son mécanisme de communication appelé SFTunnel.

Étape 4. Le FMC avertit le capteur qu'il doit démarrer le processus de déploiement avec la stratégie fournie pendant qu'il écoute les réponses individuelles.

Étape 5. Le périphérique géré déballe l'archive et commence à appliquer les configurations et packages individuels.

R. La première moitié du déploiement est la Snort où la configuration Snort La configuration est testée localement pour garantir sa validité.

Une fois la validité établie, la nouvelle configuration est déplacée vers le répertoire de production pour Snort. Si la validation échoue, le déploiement de la stratégie échoue à cette étape.

B. La seconde moitié de la charge du package de déploiement concerne la configuration LINA, où elle est appliquée directement au processus LINA par le processus ngfwManager.

En cas d'échec, les modifications sont annulées et un échec du déploiement de la stratégie se produit.

Étape 6. Si les deux Snort et les packages LINA sont réussis, les périphériques gérés signalent Snort pour redémarrer ou recharger afin de charger la nouvelle configuration et enregistrer toutes les configurations actuelles.

Étape 7. Si tous les messages aboutissent, le capteur envoie un message de réussite et attend qu'un accusé de réception soit envoyé par le centre de gestion.

Étape 8. Une fois reçu, le FMC marque la tâche comme un succès et permet à l'ensemble de politiques de se terminer.

Dépannage

Problèmes rencontrés pendant Policy Deployment peut être due, sans s'y limiter :

Mauvaise Configuration
Communication entre le CSP et le DFT
Intégrité de la base de données et du système
Défauts logiciels et avertissements
Autres situations uniques

Certains de ces problèmes peuvent être facilement résolus, tandis que d'autres peuvent nécessiter l'assistance de Cisco Technical Assistance Center (TAC).

L'objectif de cette section est de fournir des techniques permettant d'isoler le problème ou de déterminer la cause première.

Interface graphique utilisateur (GUI) FMC

Cisco recommande que chaque session de dépannage pour les échecs de déploiement démarre sur l'appliance FMC.

Dans la fenêtre de notification de panne, sur toutes les versions au-delà de 6.2.3, il y a des outils supplémentaires qui peuvent aider avec d'autres pannes possibles.

Utiliser Les Transcriptions De Déploiement

Étape 1. Relevez le Deployments dans l'interface utilisateur Web de FMC.

Étape 2. Alors que la Deployments est sélectionné, cliquez sur Show History.

FMCHistory

Étape 3. À l'intérieur Deployment History , vous pouvez voir tous les déploiements précédents de votre FMC. Sélectionnez le déploiement dans lequel vous souhaitez afficher plus de données.

Étape 4. Une fois un élément de déploiement sélectionné, la Deployment Details La sélection affiche la liste de tous les périphériques du Transaction. Ces entrées sont réparties dans les colonnes suivantes : Device Number, Device Name, Status,et Transcript.

DeploymentHist1

Étape 5. Sélectionnez le périphérique en question et cliquez sur l'option de transcription pour afficher la transcription de déploiement individuelle qui peut vous informer des défaillances ainsi que des configurations qui sont placées sur les périphériques gérés.

DeployTranscript1

Étape 6. Cette transcription peut indiquer certaines conditions d'échec ainsi qu'un nombre très important pour l'étape suivante : Transaction ID.

DeployTransactionID

Étape 7. Dans un Firepower Deployment,les Transaction ID est ce qui peut être utilisé pour suivre chaque section individuelle d'un déploiement de stratégie. Grâce à cela, sur la ligne de commande du périphérique, vous pouvez obtenir une version plus approfondie de ces données pour la correction et l'analyse.

Conseil : si vous ne parvenez pas à localiser l'ID de transaction ou si vous disposez d'une version antérieure à l'impression, ce journal peut toujours être utilisé pour localiser les messages d'échec individuels.

Dépannage avec les journaux FMC

Bien qu'il soit approprié de faire appel au centre d'assistance technique Cisco pour analyser les journaux, une recherche dans les journaux peut vous aider à identifier le problème initial et à accélérer sa résolution. Il existe plusieurs fichiers journaux sur FMC qui révèlent les détails du processus de déploiement de la stratégie.

Les deux journaux les plus souvent référencés sont : policy_deployment.log et usmsharedsvcs.log.

Tous les fichiers mentionnés dans ce document peuvent être visualisés avec plusieurs commandes Linux telles que more, less et vi. Toutefois, il est très important de veiller à ce que read des actions lui sont appliquées. Tous les fichiers nécessitent un accès racine pour pouvoir les afficher.

/var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log

Ce journal marque clairement le début de la tâche de déploiement de stratégie sur FMC et la fin de chaque phase, ce qui permet de déterminer la phase où le déploiement a rencontré une défaillance, ainsi que le code de défaillance.

Les transactionID La valeur incluse dans la partie JSON du journal peut être utilisée pour rechercher des entrées de journal associées à une tentative de déploiement particulière.

22-Nov-2019 01:28:52.844,[INFO],(DefenseCenterServiceImpl.java:1372)
com.cisco.nm.vms.api.dc.DefenseCenterServiceImpl, ajp-nio-127.0.0.1-9009-exec-4
** REST Request [ CSM ]
** ID : e1c84364-0966-42eb-9356-d2914be2b4a3
** URL: Broadcast message.send.deployment
{
  "body" : {
    "property" : "deployment:deployment_initiated_for_the_device",
    "argumentList" : [ {
      "key" : "PHASE",
      "value" : "Phase-0"
    } ]
  },
  "user" : "68d03c42-d9bd-11dc-89f2-b7961d42c462",
  "type" : "deployment",
  "status" : "running",
  "progress" : 5,
  "silent" : true,
  "restart" : true,
  "transactionId" : 12884916552,
  "devices" : [ "93a2089a-fa82-11e9-8219-e1abeec81dc9" ]
}

/var/log/sf/policy_deployment.log

Bien que ce fichier journal ait existé dans toutes les versions 6.x, qui commencent à la version 6.4, sa couverture a été étendue.

Il décrit maintenant les étapes détaillées effectuées sur FMC pour créer les packages de déploiement. Il est donc préférable de l'utiliser pour analyser les échecs des phases 1 à 4.

Le début de chaque phase est marqué par une ligne avec "INFO start. ":

Jul 18 17:20:03 firepower ActionQueueScrape.pl[17287]: INFO starting populateGlobalSnapshot - sqlite = /var/cisco/umpd/8589938337/DC_policy_deployment.db, transaction = 8589938337, time = 1563470402, running as (memory = 56.35 MB) (Framework 3950<196 <- CSMTasks 223<10 <- SF::ActionQueue 2457)
Jul 18 17:20:03 firepower ActionQueueScrape.pl[17287]: INFO deployment threading: disabled (Framework 198 <- CSMTasks 223<10 <- SF::ActionQueue 2457)
Jul 18 17:20:03 firepower ActionQueueScrape.pl[17287]: INFO -> calling SF::UMPD::Plugins::Correlation::Manager::getPluginDependencies (Plugin 298<90 <- Framework 3579<3566<216 <- CSMTasks 223)
...

Dépannage des périphériques gérés

D'autres phases et sections dépendent du package de périphériques, de la configuration de la haute disponibilité et du résultat des phases précédentes pour chaque périphérique géré.

Si un problème de déploiement est isolé en raison d'une défaillance sur le périphérique géré, un dépannage supplémentaire peut être effectué sur le périphérique avec deux journaux sur le périphérique : policy_deployment.log et ngfwManager.log.

/ngfw/var/log/ngfwManager.log

Ce fichier journal décrit en détail les étapes suivies par Config Communication Manager et Config Dispatcher pour communiquer avec FMC, travailler avec le package de déploiement et orchestrer la validation et l'application des configurations Snort et LINA.

Voici quelques exemples de ngfwManager.log qui représentent le début des phases principales :

FTD receives FMC's request for running configuration:

May 30 16:37:10 ccm[4293] Thread-10: INFO  com.cisco.ccm.ConfigCommunicationManager- Passing CD-Message-Request to Config Dispatcher...
May 30 16:37:10 ccm[4293] Thread-10: DEBUG com.cisco.ccm.ConfigCommunicationManager- <?xml version="1.0" encoding="UTF-8"?><cdMessagesList><timeStamp>1559234230012</timeStamp><cdMessage><name>LinaShowCommand</name><messageId>-753133537443151390</messageId><contentType>XML</contentType><msgContent><![CDATA[<?xml version="1.0" encoding="UTF-8"?><message><name>LinaShowCommand</name>...



FTD receives FMC's request to download the deployment package:

May 30 16:37:18 ccm[4293] Thread-9: INFO  com.cisco.ccm.ConfigCommunicationManager- Downloading database (transaction 8589938211, version 1559234236)
May 30 16:37:18 ccm[4293] Thread-9: DEBUG com.cisco.ccm.DownloadManager- handle record: 8589938211, status = PENDING
May 30 16:37:18 ccm[4293] Thread-9: DEBUG com.cisco.ccm.DownloadManager- begin downloading database



FTD begins the deployment of policy changes:

May 30 16:37:21 ccm[4293] Thread-9: INFO  com.cisco.ccm.ConfigCommunicationManager- Starting deployment
May 30 16:37:21 ccm[4293] Thread-11: INFO  com.cisco.ccm.ConfigCommunicationManager- Sending message: DEPLOYMENT_STATUS_CCM to Manager



FTD begins LINA deployment:

May 30 16:37:42 ccm[4293] Thread-19: DEBUG com.cisco.ngfw.configdispatcher.communicators.LinaCommunicatorImpl- Trying to send Start-Config-Sequencerequest to lina



FTD begins finalizing the deployment:

May 30 16:38:48 ccm[4293] Thread-19: DEBUG com.cisco.ngfw.configdispatcher.communicators.LinaCommunicatorImpl- Clustering Message sent out of ConfigDispatcher:
Name:Cluster-App-Conf-Finalize-Request

/ngfw/var/log/sf/policy_deployment.log

Ce journal contient les détails de la stratégie appliquée à Snort. Bien que le contenu du journal soit principalement avancé et nécessite une analyse par le TAC, il est toujours possible de tracer le processus avec quelques entrées clés :

Config Dispatcher begins extracting the packaged policies for validation:

Jul 18 17:20:57 firepower policy_apply.pl[25122]: INFO  -> calling SF::UMPD::Plugins::NGFWPolicy::Device::exportDeviceSnapshotToSandbox  (Plugin 230 <- Framework 611 <- Transaction 1085)
Jul 18 17:20:57 firepower policy_apply.pl[25122]: INFO  found NGFWPolicy =>   (NGFWPolicy::Util 32 <- NGFWPolicy::Device 43 <- Plugin 235)
...
Jul 18 17:20:57 firepower policy_apply.pl[25122]: INFO export FTD platform settings... (PlatformSettings::FTD::Device 29 <- Plugin 235<339 <- PlatformSettings::Device 13)



Config validation begins:

Jul 18 17:21:37 firepower policy_apply.pl[25122]: INFO  starting validateExportedFiles - sqlite = /var/cisco/deploy/sandbox/policy_deployment.db, sandbox = /var/cisco/deploy/sandbox/exported-files (memory = 229.99 MB)  (Framework 3950<687 <- Transaction 1101 <- main 194)



Validation has completed successfully:

Jul 18 17:21:49 firepower policy_apply.pl[25122]: INFO validateExportedFiles - sqlite = /var/cisco/deploy/sandbox/policy_deployment.db, sandbox = /var/cisco/deploy/sandbox/exported-files took 12 (memory = 238.50 MB, change = 8.51 MB) (Framework 3976<724 <- Transaction 1101 <- main 194) 



Config Dispatcher begins moving the validated configuration to the Snort directories in production:

Jul 18 17:21:54 firepower policy_apply.pl[26571]: INFO  -> calling SF::UMPD::Plugins::NGFWPolicy::Device::publishExportedFiles  (Plugin 230 <- Framework 822 <- Transaction 1662)



Snort processes will reload to apply the new configurations:

Jul 18 17:22:02 firepower policy_apply.pl[26571]: INFO  Reconfiguring DE a3bcd340-992f-11e9-a1f1-ac829f31a4f9...  (Snort::SnortNotifications 292<154 <- Snort::Device 343 <- Plugin 235)
Jul 18 17:22:02 firepower policy_apply.pl[26571]: INFO  sending SnortReload to a3bcd340-992f-11e9-a1f1-ac829f31a4f9  (Snort::SnortNotifications 298<154 <- Snort::Device 343 <- Plugin 235)



Snort reload has completed successfully:

Jul 18 17:22:14 firepower policy_apply.pl[26571]: INFO notifyProcesses - sandbox = /var/cisco/deploy/sandbox/exported-files took 16 (memory = 169.52 MB, change = 16.95 MB) (Framework 3976<964 <- Transaction 1680 <- main 200)



After LINA config apply finishes, Snort deployment is finalized:

Jul 18 17:23:32 firepower policy_apply.pl[26913]: INFO  starting finalizeDeviceDeployment - sandbox = /var/cisco/deploy/sandbox (memory = 101.14 MB)  (Framework 3950<980 <- Transaction 1740 <- main 206)

Exemple

Étape 1. Un déploiement échoue

Étape 2. Obtenir le Deploy Transcript et Transaction ID.

Étape 3. SSH dans votre Management Center et utiliser l'utilitaire Linux less pour lire le fichier comme indiqué sur votre FMC :

Exemple :"sudo less /var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log" (Le sudo password est le mot de passe de vos utilisateurs pour ssh)

tz7

Étape 4. Lorsque vous êtes dans less, utilisez la barre oblique et entrez l'ID du message pour rechercher les journaux associés à l'ID de transaction du déploiement.

Exemple : "/60129547881" (en cours less, utilisez n pour passer au résultat suivant)

Exemple de message en cours d'exécution :

tz3

Exemple de message d'échec :

tz6

5) Comparez la défaillance appropriée à la table jointe des messages de défaillance courants.

C'est-à-dire failed_to_recover_running_configuration se produit lors d'échecs de communication entre les deux périphériques.

Messages d'échec courants

Il s'agit de messages d'échec courants, visibles à l'avant du Management Center Task ainsi que le code d'erreur qui peut être vu dans le back-end.

Ces messages peuvent être analysés et comparés avec les raisons communes des résolutions possibles.

Si vous ne les voyez pas ou si elles ne résolvent pas votre situation, veuillez contacter le TAC pour obtenir de l'aide.

----------------------------------------------------------------------------------------

« Error Code	Messages d'erreur	Motif
`device_has_changed_domain`	Échec du déploiement - Le périphérique a changé le domaine de {SRCDOMAIN} en {DESTINATIONDOMAIN}. Réessayez plus tard.	Cette erreur se produit généralement lorsqu'un périphérique a été déplacé ou est pris à partir d'un second domaine. Un redéploiement alors qu'aucune information interdomaine ne se produit corrige généralement ce problème.
`device_currently_under_deployment`	Échec du déploiement en raison d'un autre déploiement en cours pour ce périphérique. Réessayez plus tard.	Ceci est généralement signalé lorsque le déploiement est déclenché sur un périphérique en cours de déploiement. Dans certaines versions, cela est impossible sans notification d'échec ; cependant, cette phase existe toujours pour l'assistance au dépannage.
`device_not_member_of_container`	Le déploiement ne peut pas être effectué sur un périphérique individuel qui est membre d'un cluster. Réessayez de déployer le cluster ultérieurement.	Ce message s'applique au FTD sur les périphériques équipés du gestionnaire de châssis FXOS (Firepower eXtensible Operative System). Si le cluster est construit sur FXOS, mais pas sur le FMC, ce message s'affiche. Créez le cluster sur l'appliance Management Center avant de tenter le déploiement.
`policy_altered_after_timestamp_for_other_devices_in_job_error`	Les stratégies d'un ou de plusieurs périphériques ont été modifiées depuis {TIMESTAMP}. Recommencez le déploiement.	Cette erreur s'affiche si une stratégie/un objet est modifié pour un périphérique dans le travail de déploiement après le déploiement des déclencheurs utilisateur et avant la création des éléments CSM et des instantanés de domaine. Un redéploiement corrige ce problème. Cela peut se produire lorsque de nombreux utilisateurs utilisent le même FMC pour modifier et enregistrer des objets pendant leur déploiement.
`policy_altered_after_timestamp_error`	La stratégie {Policy Name} a été modifiée depuis {Timestamp}. Recommencez le déploiement.	Cette erreur s'affiche si une stratégie/un objet est modifié pour le périphérique concerné dans le travail de déploiement, après le déploiement des déclencheurs utilisateur et avant la création des snapshots CSM et de domaine. Un redéploiement corrige ce problème.
`csm_snapshot_error`	Échec du déploiement en raison de l'échec de la collecte des stratégies et des objets. Si le problème persiste après une tentative répétée, contactez le TAC Cisco.	Si une importation de stratégie récente est fournie, attendez environ une heure et essayez un autre déploiement. Si cela ne vous permet pas de poursuivre, contactez le TAC car il s'agit d'un message lié à la base de données.
`domain_snapshot_timeout`	Échec du déploiement en raison du délai d'attente pour la collecte des stratégies et des objets. Si le problème persiste après une nouvelle tentative, contactez le TAC Cisco.	Par défaut, le délai d'attente de l'instantané de domaine est de 5 minutes. Si la charge du système est élevée ou si l'hyperviseur ne fonctionne pas correctement, cela peut entraîner des retards non naturels dans l'appel. Cela peut se produire si le centre de gestion ou le périphérique ne dispose pas de la quantité de ressources mémoire appropriée. Si cela se produit sans charge ou si vous ne continuez pas ultérieurement, contactez le TAC.
`domain_snapshot_errors`	Échec du déploiement dans la stratégie et la collection d'objets. Si le problème persiste après une nouvelle tentative, contactez le TAC Cisco.	Contactez le TAC. Un dépannage avancé est requis.
`failed_to_retrieve_running_configuration`	Échec du déploiement en raison de l'échec de la récupération des informations de configuration d'exécution du périphérique. Recommencez le déploiement.	Ce message peut s'afficher lorsque la connectivité entre un capteur d'extrémité et un FMC ne fonctionne pas comme prévu. Vérifiez l'intégrité du tunnel entre les unités et surveillez la connectivité entre les deux périphériques. Si le tunnel fonctionne comme prévu et que les périphériques peuvent communiquer, contactez le TAC.
`device_is_busy`	Le déploiement a échoué car le périphérique exécute peut-être un déploiement précédent ou un redémarrage. Si le problème persiste après une nouvelle tentative, contactez le TAC Cisco.	Ce message s'affiche lorsque FMC tente un déploiement alors qu'un déploiement précédent est en cours sur FTD. Généralement, cela se produit lorsqu'un déploiement précédent est inachevé sur FTD et que le FTD a redémarré ou que le processus ngfwManager sur FTD a redémarré. Une nouvelle tentative après 20 minutes pour permettre aux processus d'expirer officiellement devrait résoudre ce problème. Si vous êtes en retard ou si le retard n'est pas acceptable, contactez le TAC.
`no_response_for_show_cmd`	Échec du déploiement en raison de problèmes de connectivité avec le périphérique ou le périphérique ne répond pas. Si le problème persiste après une nouvelle tentative, contactez le TAC Cisco.	FMC émet certaines commandes « show » LINA pour récupérer la configuration en cours pour la génération de la configuration. Cela peut se produire en cas de problèmes de connectivité ou de processus ngfwManager sur le capteur final. Si vous ne rencontrez pas de problèmes de connectivité entre vos unités, contactez le TAC.
`network_latency_or_device_not_reachable`	Échec du déploiement en raison d'un échec des communications avec le périphérique. Si le problème persiste après une nouvelle tentative, contactez le TAC Cisco.	Se produit généralement avec une latence réseau élevée entre les périphériques pour provoquer un dépassement du délai d'attente de la stratégie. Vérifiez la latence du réseau entre les périphériques pour vérifier qu'elle correspond aux valeurs minimales pour la version mentionnée dans le guide de l'utilisateur.
`slave_app_sync`	Échec du déploiement car la synchronisation de la configuration du cluster est en cours. Recommencez le déploiement.	Ceci s'applique uniquement aux configurations de cluster FTD. Si un déploiement est tenté sur un cluster FTD alors que la synchronisation d'application (synchronisation de configuration) est en cours, la même tentative est rejetée par FTD. Une nouvelle tentative après la synchronisation de la configuration devrait résoudre ce problème. L'état actuel du cluster peut être suivi à l'aide de cette commande dans le périphérique géré CLISH : > show cluster info
asa_configuration_generation_errors	Le déploiement n'a pas pu générer la configuration du périphérique. Si le problème persiste après une nouvelle tentative, contactez le TAC Cisco.	Après avoir examiné les journaux USMS mentionnés précédemment, vous pourrez peut-être voir quelle configuration est à l'origine de l'erreur. Il s'agit généralement de bogues dans lesquels les journaux peuvent être consultés via l'outil de bogue Cisco ou contactez le TAC Cisco pour un dépannage plus approfondi.
`interface_out_of_date`	Le déploiement a échoué car les interfaces sur le périphérique sont obsolètes. Enregistrez la configuration sur la page des interfaces et réessayez.	Cela se produit sur les modèles 4100 ou 9300 si l'interface n'est pas associée au périphérique pendant ou juste avant un déploiement. Vérifiez que l'interface est entièrement associée ou non associée avant de tenter le déploiement.
`device_package_error`	Le déploiement n'a pas pu générer de configuration pour le périphérique. Si le problème persiste après une nouvelle tentative, contactez le TAC Cisco.	Cette erreur indique l'échec de la génération de la configuration du périphérique pour le périphérique. Contactez le TAC.
`device_package_timeout`	Échec du déploiement en raison du délai d'attente pendant la génération de la configuration. Si le problème persiste après une nouvelle tentative, contactez le TAC Cisco.	Cela peut se produire si la latence existe entre les périphériques au-delà des plages normales. Contactez le TAC si ce problème persiste après la normalisation de la latence.
`device_communication_errors`	Échec du déploiement en raison d'un échec de communication du périphérique. Vérifiez la connectivité réseau et recommencez le déploiement.	Ce message est le secours pour tout problème de communication entre les périphériques. En raison de sa nature Vague, il est écrit comme le fallback à l'état qu'une erreur de connectivité inconnue s'est produite.
`unable_to_initiate_deployment_dc`	Échec du déploiement de la stratégie. Recommencez le déploiement.	Une autre tentative devrait résoudre ce problème. Cela peut se produire lorsque le FMC ne peut pas démarrer le déploiement en raison d'un verrouillage temporaire de la base de données.
`device_failure_timeout`	Échec du déploiement sur le périphérique en raison du dépassement du délai d'attente. Recommencez le déploiement.	Ceci est lié au déploiement FTD. Les processus sur FTD attendent 30 minutes que la répartition soit terminée. Sinon, il expire. Dans ce cas, vérifiez la connectivité entre les périphériques et, si la connectivité est correcte, contactez le TAC.
`device_failure_download_timeout`	Échec du déploiement en raison du délai de téléchargement de la configuration vers le périphérique. Si le problème persiste après une nouvelle tentative, contactez le TAC Cisco.	Ceci est lié au déploiement FTD. Le FTD ne peut pas télécharger tous les fichiers de configuration des périphériques pendant le déploiement en raison de problèmes de connectivité. Veuillez réessayer une fois la connectivité réseau vérifiée. Si cela a été vérifié, contactez le TAC.
`device_failure_configuration`	Échec du déploiement en raison d'une erreur de configuration. Si le problème persiste après une nouvelle tentative, contactez le TAC Cisco.	Toute erreur dans la configuration générée par FMC pour le périphérique devrait entraîner cette erreur post apply. Cela doit être analysé dans les journaux USMS pour vérifier quels problèmes sont détectés et tenter de les restaurer. Une fois réparé, cela nécessite généralement une intervention du TAC et la création d'un bogue si les journaux ne peuvent pas être associés à un défaut connu dans l'outil de recherche de bogues Cisco.
`deployment_timeout_no_response_from_device`	Échec du déploiement en raison du délai de communication avec le périphérique. Si le problème persiste après une nouvelle tentative, contactez le TAC Cisco.	Ce délai d’attente se produit si le FMC n’a pas reçu de réponse d’un périphérique après 45 minutes ou moins. Il s'agit d'une erreur de communication. Vérifiez la communication et, si elle est vérifiée, contactez le TAC.
`device_failure_change_master`	Le déploiement vers le cluster a échoué car l'unité principale a changé. Recommencez le déploiement.	Pour un déploiement de configuration de cluster FTD, si le noeud principal bascule lorsque le déploiement est en cours sur le périphérique (post-notification), cette erreur est indiquée. Réessayez une fois que le noeud principal est stable. L'état actuel des membres du cluster peut être suivi à l'aide de cette commande dans le périphérique géré CLISH: > show cluster info
`device_failure_unknown_master`	Échec du déploiement vers le cluster en raison d'un échec d'identification de l'unité principale. Recommencez le déploiement.	FMC n'a pas pu déterminer le noeud principal actuel pendant le déploiement. Cela peut être généralement dû à deux possibilités : soit des problèmes de connectivité, soit le principal actuel n'a pas été ajouté au cluster sur FMC. Il doit être résolu après le rétablissement de la connectivité ou après l’ajout du principal actuel au cluster FMC et une nouvelle tentative. L'état actuel du cluster peut être suivi à l'aide de cette commande dans le périphérique géré CLISH : > show cluster info
`cd_deploy_app_sync`	Échec du déploiement car la synchronisation de la configuration du cluster est en cours. Recommencez le déploiement.	Cela peut se produire si le périphérique est dans App Sync, une fois que App Sync est terminé, veuillez réessayer le déploiement une fois de plus.
`cd_existing_deployment`	Échec du déploiement en raison d'un conflit avec le déploiement précédent simultané. Si le problème persiste après une nouvelle tentative, contactez le TAC Cisco.	Cela peut se produire si un déploiement est simultané d'un côté, mais pas de l'autre. Ces problèmes sont généralement dus à des problèmes de communication entre les périphériques. Contactez le TAC si, après l'expiration du délai d'attente, vous ne parvenez toujours pas à effectuer le déploiement.

Contactez le TAC pour obtenir de l'aide

Si les informations précédentes ne permettent pas le déploiement d'une stratégie, ou si le problème ne semble pas être lié à un comportement documenté préexistant, veuillez suivre les étapes fournies dans le lien suivant pour générer un fichier de dépannage et contacter le TAC pour une analyse et la création de bogues.

https://www.cisco.com/c/en/us/support/docs/security/sourcefire-defense-center/117663-technote-SourceFire-00.html