La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.
Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).
Questo documento descrive una panoramica di alto livello del processo di distribuzione delle policy su FTD e le tecniche di risoluzione dei problemi di base.
Con Cisco Firepower Threat Defense
(FTD), funzionalità firewall stateful tradizionali offerte da Adaptive Security Appliances
(ASA) Next-Gen
funzionalità firewall (con tecnologia Snort
) vengono ora combinati in un unico prodotto.
A causa di questo cambiamento, Policy Deployment Infrastructure
su FTD gestisce ora le modifiche alla configurazione sia per il codice ASA (noto anche come LINA) che Snort
in un unico pacchetto.
Cisco consiglia la conoscenza dei seguenti prodotti:
Firepower Management Center (FMC)
Firepower Threat Defense (FTD)
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Cisco FTD utilizza Policy Deployments
per gestire ed eseguire il push delle configurazioni per i dispositivi registrati nel Firepower Management Center
(FMC).
All'interno dell'implementazione, sono presenti una serie di passaggi suddivisi in "Fasi".
Le fasi del CCP possono essere riassunte in questo elenco.
Fase 0 | Inizializzazione della distribuzione |
Fase 1 | Raccolta oggetti di database |
Fase 2 | Raccolta di oggetti e criteri |
Fase 3 | Generazione della configurazione dalla riga di comando NGFW |
Fase 4 | Generazione del pacchetto di distribuzione del dispositivo |
Fase 5 | Inviare e ricevere il pacchetto di distribuzione |
Fase 6 | Messaggi di distribuzione, azioni di distribuzione e completamento distribuzione in sospeso |
La conoscenza delle fasi e della posizione degli errori nel processo può aiutare a risolvere i problemi che un Firepower
facce di sistema.
In alcune situazioni potrebbe trattarsi di un conflitto causato da configurazioni precedenti o da un Advanced Flex Configuration
in cui manca una parola chiave che può causare errori non risolti dal report del dispositivo.
Passaggio 1. Fare clic su Deployment
, che specifica la periferica da selezionare.
Passaggio 2. Quando viene eseguito il commit della distribuzione di un dispositivo, il CCP inizia a raccogliere tutte le configurazioni relative al dispositivo.
Passaggio 3. Una volta raccolte le configurazioni, il FMC crea il pacchetto e lo invia al sensore tramite il proprio meccanismo di comunicazione denominato SFTunnel.
Passaggio 4. Il FMC notifica al sensore di avviare il processo di distribuzione con il criterio fornito durante l'ascolto delle singole risposte.
Passaggio 5. Il dispositivo gestito decomprime l'archivio e inizia ad applicare le singole configurazioni e pacchetti.
R. La prima metà dell’impiego è costituita Snort
configurazione in cui Snort
la configurazione viene testata localmente per verificarne la validità.
Quando la nuova configurazione è valida, viene spostata nella directory di produzione per Snort
. Se la convalida ha esito negativo, la distribuzione dei criteri non riesce in questa fase.
B. La seconda metà del carico del pacchetto di implementazione è per la configurazione LINA, dove viene applicata direttamente al processo LINA dal processo ngfwManager.
Se si verifica un errore, viene eseguito il rollback delle modifiche e si verifica un errore di distribuzione dei criteri.
Passaggio 6. Se entrambi Snort
e LINA hanno esito positivo, il dispositivo gestito segnala Snort
per riavviare o ricaricare il dispositivo per caricare la nuova configurazione e salvare tutte le configurazioni correnti.
Passaggio 7. Se tutti i messaggi hanno esito positivo, il sensore invia un messaggio di esito positivo e attende che venga riconosciuto dal centro di gestione.
Passaggio 8. Una volta ricevuto, il CCP contrassegna l'operazione come riuscita e consente il completamento del pacchetto di criteri.
Problemi riscontrati durante Policy Deployment
potrebbe essere dovuto, ma non limitato a:
Alcuni di questi problemi potrebbero essere facilmente risolti, mentre altri potrebbero richiedere assistenza al Cisco Technical Assistance Center (TAC)
.
L'obiettivo di questa sezione è quello di fornire tecniche per isolare il problema o determinare la causa principale.
Cisco consiglia di avviare ogni sessione di risoluzione dei problemi per gli errori di distribuzione sull'accessorio FMC.
Nella finestra di notifica degli errori, in tutte le versioni successive alla 6.2.3, sono disponibili strumenti aggiuntivi che possono essere di ausilio in caso di altri possibili errori.
Passaggio 1. Tirare su Deployments
nell'interfaccia utente Web del CCP.
Passaggio 2. Mentre il Deployments
, fare clic su Show History
.
Passaggio 3. All'interno del Deployment History
è possibile visualizzare tutte le distribuzioni precedenti dal CCP. Selezionare la distribuzione in cui si desidera visualizzare ulteriori dati.
Passaggio 4. Dopo aver selezionato un elemento di distribuzione, Deployment Details
viene visualizzato un elenco di tutti i dispositivi all'interno del Transaction
. Queste voci sono suddivise in queste colonne: Device Number, Device Name, Status,
e Transcript
.
Passaggio 5. Selezionare il dispositivo in questione e fare clic sull'opzione di trascrizione per visualizzare la trascrizione della distribuzione individuale che può informare l'utente di errori e configurazioni inserite sui dispositivi gestiti.
Passaggio 6. Questa trascrizione può indicare alcune condizioni di errore e indicare un numero molto importante per la fase successiva: Transaction ID
.
Passaggio 7. In un Firepower Deployment
,OSPF (Open Shortest Path First) Transaction ID
consente di tenere traccia di ogni singola sezione di una distribuzione di criteri. In questo modo, dalla riga di comando del dispositivo è possibile ottenere una versione più dettagliata di questi dati per la risoluzione dei problemi e l'analisi.
Suggerimento: nel caso in cui non sia possibile individuare l'ID della transazione o se si utilizza una versione precedente alla stampa, questo registro può comunque essere utile per individuare i singoli messaggi di errore.
Anche se è opportuno incaricare Cisco TAC di analizzare i registri, una ricerca nei registri potrebbe contribuire all'isolamento iniziale del problema e velocizzare la risoluzione. In FMC sono presenti più file di registro che rivelano i dettagli relativi al processo di distribuzione dei criteri.
I due log di riferimento più comuni sono policy_deployment.log
e usmsharedsvcs.log
.
Tutti i file menzionati in questo documento possono essere visualizzati con più comandi Linux, come more
, less
e vi
. Tuttavia, è molto importante garantire che solo read
vengono eseguite azioni su di esso. Per visualizzare tutti i file è necessario l'accesso alla directory principale.
Questo registro indica chiaramente l'inizio dell'attività di distribuzione dei criteri in FMC e il completamento di ogni fase, che consente di determinare la fase in cui la distribuzione è stata interrotta, insieme al codice di errore.
OSPF (Open Shortest Path First) transactionID
Il valore incluso nella parte JSON del log può essere utilizzato per trovare le voci di log relative a un particolare tentativo di distribuzione.
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" ] }
Sebbene questo file di log sia stato presente in tutte le versioni 6.x, che iniziano dalla versione 6.4, la sua copertura è stata ampliata.
Vengono ora descritte in dettaglio le misure adottate dal centro di gestione della macchina per creare i pacchetti di installazione, pertanto è consigliabile utilizzarlo per analizzare gli errori della fase 1 - 4.
L'inizio di ogni fase è contrassegnato da una riga con "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) ...
Esistono ulteriori fasi e sezioni che dipendono dal pacchetto del dispositivo, dalla configurazione dell'alta disponibilità e dal risultato delle fasi precedenti per ciascun dispositivo gestito.
Se un problema di distribuzione viene isolato a causa di un errore sul dispositivo gestito, è possibile eseguire ulteriori operazioni di risoluzione dei problemi sul dispositivo con due registri: policy_deployment.log e ngfwManager.log.
In questo file di log vengono indicate le operazioni dettagliate eseguite da Config Communication Manager
e Config Dispatcher
per comunicare con FMC, utilizzare il pacchetto di distribuzione e orchestrare la convalida e l'applicazione delle configurazioni Snort e LINA.
Di seguito sono riportati alcuni esempi di ngfwManager.log che rappresentano l'inizio delle fasi principali:
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
Questo registro contiene i dettagli del criterio applicato a Snort
. Sebbene il contenuto del registro sia per lo più avanzato e richieda un'analisi tramite TAC, è comunque possibile tracciare il processo con alcune voci chiave:
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)
Passaggio 1. Distribuzione non riuscita
Passaggio 2. Ottenere la Deploy Transcript
e Transaction ID
.
Passaggio 3. SSH nel tuo Management Center
e utilizzare l'utility Linux less
per leggere il file come indicato sul CCP:
Esempio:"sudo less /var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log" (la password sudo è la password utente per ssh)
Passaggio 4. Quando sei in less
, utilizzare la barra e immettere l'ID del messaggio per cercare i log relativi al transactionID di distribuzione.
Esempio:"/60129547881" (in less
, utilizzare n per passare al risultato successivo)
Esempio di messaggio in esecuzione:
Messaggio di errore:
5) Confrontare l'errore corretto con la tabella allegata dei messaggi di errore comuni.
Ad esempio, failed_to_retrieve_running_configuration si verifica durante errori di comunicazione tra i due dispositivi.
Si tratta di messaggi di errore comuni che possono essere visualizzati sul front-end del Management Center Task
nonché il codice di errore che può essere visualizzato nel back-end.
Questi messaggi possono essere analizzati e confrontati con le ragioni comuni per le possibili risoluzioni.
Nel caso in cui non vengano visualizzate, o non risolvano la situazione, contattare TAC per assistenza.
—
Codice di errore |
Messaggi di errore |
Motivo |
|
Errore di distribuzione - Il dispositivo ha modificato il dominio da {SRCDOMAIN} a {DESTINATIONDOMAIN}. Riprova più tardi. |
Questo errore si verifica in genere quando un dispositivo viene spostato o prelevato da un secondo dominio. Una ridistribuzione senza la presenza di informazioni tra domini in genere consente di risolvere questo problema. |
|
Distribuzione non riuscita a causa di un'altra distribuzione in corso per questo dispositivo. Riprova più tardi. |
Questo viene in genere segnalato quando la distribuzione viene attivata su un dispositivo nella distribuzione. In alcune versioni, questa operazione viene evitata senza notifica di errore, tuttavia questa fase esiste ancora per l'assistenza nella risoluzione dei problemi. |
|
Impossibile eseguire la distribuzione su un singolo dispositivo membro di un cluster. Riprovare a distribuire il cluster in un secondo momento. |
Questo messaggio è valido per FTD su dispositivi con Firepower eXtensible Operative System (FXOS) Chassis Manager. Questo messaggio viene visualizzato se il cluster è basato su FXOS, ma non su FMC. Creare il cluster sull'accessorio di Management Center prima di tentare la distribuzione. |
|
I criteri per uno o più dispositivi sono stati modificati dopo il {TIMESTAMP}. Riprovare la distribuzione. |
Questo errore viene visualizzato se un criterio o un oggetto viene modificato per un dispositivo nel processo di distribuzione dopo l'attivazione dell'utente e prima della creazione degli elementi CSM e degli snapshot del dominio. La ridistribuzione consente di risolvere il problema. Questa situazione può verificarsi quando molti utenti utilizzano lo stesso FMC per modificare e salvare oggetti durante la distribuzione. |
|
Il criterio {Policy Name} è stato modificato dopo il {Timestamp}. Riprovare la distribuzione. |
Questo errore viene visualizzato se un criterio o un oggetto viene modificato per il dispositivo interessato nel processo di distribuzione, dopo l'attivazione dell'utente e prima della creazione di snapshot di dominio e CSM. La ridistribuzione consente di risolvere il problema. |
|
Distribuzione non riuscita a causa di un errore nella raccolta di criteri e oggetti. Se il problema persiste dopo un ripetuto tentativo, contattare Cisco TAC. |
Se viene fornita un'importazione di criteri recente, attendere un'ora circa e tentare un'altra distribuzione. |
|
Distribuzione non riuscita a causa di un timeout nella raccolta di criteri e oggetti. Se il problema persiste dopo un altro tentativo, contattare Cisco TAC. |
Per impostazione predefinita, lo snapshot del dominio ha un timeout di 5 minuti. Se il sistema è sottoposto a un carico elevato o se l'hypervisor non funziona correttamente, possono verificarsi ritardi innaturali nella chiamata. Ciò può verificarsi se non viene fornita la quantità corretta di risorse di memoria anche al centro di gestione o al dispositivo. Se il problema persiste o non viene risolto in un secondo momento, contattare TAC. |
|
Distribuzione non riuscita nei criteri e nella raccolta di oggetti. Se il problema persiste dopo un altro tentativo, contattare Cisco TAC. |
Contatta TAC. È necessaria una risoluzione avanzata dei problemi. |
|
Distribuzione non riuscita a causa di un errore durante il recupero delle informazioni di configurazione di esecuzione dal dispositivo. Riprovare la distribuzione. |
Questo messaggio può essere visualizzato quando la connettività tra un sensore terminale e un CCP non funziona come previsto. Verificare lo stato del tunnel tra le unità e monitorare la connettività tra i due dispositivi. |
|
Distribuzione non riuscita. È possibile che il dispositivo esegua una distribuzione precedente o un riavvio. Se il problema persiste dopo un altro tentativo, contattare Cisco TAC. |
Questo messaggio viene visualizzato quando FMC tenta una distribuzione mentre è in corso una distribuzione precedente su FTD. Generalmente si verifica quando una distribuzione precedente non è completata su FTD e il FTD viene riavviato o il processo ngfwManager su FTD viene riavviato. Per risolvere il problema, riprovare dopo 20 minuti per consentire il timeout formale dei processi. Se dopo un ritardo o se il ritardo non è accettabile, contattare TAC. |
|
Distribuzione non riuscita a causa di problemi di connettività con il dispositivo o il dispositivo non risponde. Se il problema persiste dopo un altro tentativo, contattare Cisco TAC. |
FMC emette alcuni comandi LINA "show" per recuperare la configurazione in esecuzione per la generazione della configurazione. Questo può accadere quando ci sono problemi di connettività o problemi con il processo ngfwManager sul sensore terminale. Se non si verificano problemi di connettività tra le unità, contattare TAC. |
|
Distribuzione non riuscita a causa di un errore di comunicazione con il dispositivo. Se il problema persiste dopo un altro tentativo, contattare Cisco TAC. |
Generalmente si verifica con una latenza di rete elevata tra i dispositivi che causa un timeout dei criteri. Verificare la latenza di rete tra i dispositivi per verificare che corrisponda ai valori minimi per la versione indicata nel manuale dell'utente. |
|
Distribuzione non riuscita. Sincronizzazione della configurazione del cluster in corso. Riprovare la distribuzione. |
Questa opzione è applicabile solo per le impostazioni cluster FTD. Se si tenta una distribuzione in un cluster FTD mentre è in corso la sincronizzazione dell'app (sincronizzazione della configurazione), la stessa operazione viene rifiutata da FTD. Per risolvere il problema, riprovare dopo la sincronizzazione della configurazione. È possibile tenere traccia dello stato corrente del cluster con questo comando nel dispositivo gestito CLISH: > mostra informazioni sul cluster |
asa_configuration_generation_errors |
La distribuzione non è riuscita a generare la configurazione del dispositivo. Se il problema persiste dopo un altro tentativo, contattare Cisco TAC. |
Dopo aver esaminato i registri USMS menzionati in precedenza, è possibile verificare la configurazione che causa l'errore. Si tratta in genere di bug in cui è possibile esaminare i log tramite Cisco Bug Tool o contattare Cisco TAC per risolvere ulteriormente il problema. |
|
Distribuzione non riuscita perché le interfacce nel dispositivo non sono aggiornate. Salvare la configurazione nella pagina interfacce e riprovare. |
Questo si verifica sui modelli 4100 o 9300 se l'interfaccia non è associata al dispositivo durante o subito prima di un'installazione. Verificare che l'interfaccia sia completamente associata o non associata prima di tentare la distribuzione. |
|
Impossibile generare la configurazione per il dispositivo. Se il problema persiste dopo un altro tentativo, contattare Cisco TAC. |
Questo errore indica un errore durante la generazione della configurazione del dispositivo. Contatta TAC. |
|
Distribuzione non riuscita a causa di un timeout durante la generazione della configurazione. Se il problema persiste dopo un altro tentativo, contattare Cisco TAC. |
Questa condizione si può verificare se esiste una latenza tra i dispositivi oltre i limiti normali. Contattare TAC se dopo la normalizzazione della latenza il problema persiste. |
|
Distribuzione non riuscita a causa di un errore di comunicazione con il dispositivo. Verificare la connettività di rete e riprovare la distribuzione. |
Questo messaggio è il fallback per qualsiasi problema di comunicazione tra i dispositivi. A causa della sua natura vaga, è scritto come il fallback allo stato che si è verificato un errore di connettività sconosciuto. |
|
Errore di distribuzione dei criteri. Riprovare la distribuzione. |
Un altro tentativo dovrebbe risolvere il problema. Questo problema può verificarsi quando il FMC non è in grado di avviare la distribuzione a causa di un blocco temporaneo del database. |
|
Distribuzione al dispositivo non riuscita a causa del timeout. Riprovare la distribuzione. |
Questo è relativo alla distribuzione FTD. I processi con FTD attendono 30 minuti per il completamento dell'installazione della spedizione. In caso contrario, si verificherà un timeout. In questo caso, verificare la connettività tra i dispositivi e se la connettività è quella prevista, contattare TAC. |
|
Distribuzione non riuscita a causa del timeout di download della configurazione nel dispositivo. Se il problema persiste dopo un altro tentativo, contattare Cisco TAC. |
Questo è relativo alla distribuzione FTD. Impossibile scaricare tutti i file di configurazione del dispositivo durante la distribuzione a causa di problemi di connettività. Riprovare al termine della verifica della connettività di rete. Se la verifica è stata effettuata, contattare TAC. |
|
Distribuzione non riuscita a causa di un errore di configurazione. Se il problema persiste dopo un altro tentativo, contattare Cisco TAC. |
Eventuali errori nella configurazione generata da FMC per il dispositivo dovrebbero generare questo errore dopo l'applicazione. È necessario analizzarli nei log USMS per verificare quali problemi vengono rilevati e tentare di ripristinarli. Dopo aver riparato il bug, in genere è necessario l'intervento di TAC e la creazione di bug se sui log non è possibile trovare una corrispondenza con un difetto noto di Cisco Bug Search Tool. |
|
Distribuzione non riuscita a causa del timeout di comunicazione con il dispositivo. Se il problema persiste dopo un altro tentativo, contattare Cisco TAC. |
Questo timeout si verifica se il CCP non ha ricevuto risposta da un dispositivo dopo 45 minuti o meno. Errore di comunicazione. Verificare la comunicazione e, se verificato, contattare TAC. |
|
Distribuzione al cluster non riuscita. L'unità primaria è stata modificata. Riprovare la distribuzione. |
Per una distribuzione di installazione cluster FTD, questo errore viene indicato se il nodo primario passa quando la distribuzione è in corso nel dispositivo (post-notifica). Riprovare quando il nodo primario è stabile. È possibile tenere traccia dello stato corrente dei membri del cluster con questo comando nel dispositivo gestito CLISH: > mostra informazioni sul cluster |
|
Distribuzione al cluster non riuscita a causa di un errore di identificazione dell'unità primaria. Riprovare la distribuzione. |
Impossibile determinare il nodo primario corrente durante la distribuzione. Questo problema potrebbe essere dovuto in genere a un paio di possibilità: problemi di connettività o primario corrente non aggiunto al cluster su FMC. Il problema dovrebbe essere risolto dopo la riattivazione della connettività o dopo l'aggiunta del server primario corrente al cluster FMC e il tentativo verrà ripetuto. È possibile tenere traccia dello stato corrente del cluster con questo comando nel dispositivo gestito CLISH: > mostra informazioni sul cluster |
|
Distribuzione non riuscita. Sincronizzazione della configurazione del cluster in corso. Riprovare la distribuzione. |
Questo problema può verificarsi se il dispositivo è in App Sync. Al termine di App Sync, riprovare a eseguire la distribuzione. |
|
Distribuzione non riuscita a causa di un conflitto con la distribuzione precedente simultanea. Se il problema persiste dopo un altro tentativo, contattare Cisco TAC. |
Questo può verificarsi se una distribuzione è simultanea su un lato, ma non sull'altro. Queste cause sono in genere causate da problemi di comunicazione tra i dispositivi. Contattare TAC se, dopo il timeout, non è ancora possibile eseguire la distribuzione. |
Nel caso in cui le informazioni precedenti non consentano la distribuzione di una policy o se il problema non sembra essere relativo a un comportamento documentato pre-esistente, eseguire la procedura descritta nel collegamento successivo per generare un file per la risoluzione dei problemi e contattare TAC per l'analisi e la creazione di bug.
Revisione | Data di pubblicazione | Commenti |
---|---|---|
2.0 |
23-Sep-2022 |
Release iniziale |
1.0 |
17-Feb-2020 |
Versione iniziale |