Risoluzione dei problemi relativi alle distribuzioni dei criteri di difesa dalle minacce Firepower
Sommario
Introduzione
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.
Prerequisiti
Requisiti
Cisco raccomanda la conoscenza dei seguenti argomenti:
Firewall Management Center (FMC)Firepower Threat Defense (FTD)
Componenti usati
Il documento può essere consultato per tutte le versioni software o hardware.
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.
Premesse
Con Cisco Firepower Threat Defense (FTD), le funzionalità tradizionali del firewall con stato offerte da Adaptive Security Appliances (ASA) e dalle funzionalità del Next-Gen firewall (alimentate da Snort ) sono ora combinate in un unico prodotto. A causa di questa modifica, Policy Deployment Infrastructure su FTD ora gestisce le modifiche della configurazione sia per il codice ASA (noto anche come LINA), sia Snort in un bundle.
Panoramica sulla distribuzione dei criteri
Cisco FTD utilizza Policy Deployments per gestire ed eseguire il push out delle configurazioni dei dispositivi registrati sul Firewall Management Center CCP stesso.
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 sistema deve affrontare.
In alcune situazioni, potrebbe trattarsi di un conflitto causato da configurazioni precedenti o da un errore causato da un Advanced Flex Configuration errore che può causare errori non risolti dal report del dispositivo.
Panoramica di esempio
Passaggio 1. Fare clic su Deployment, per specificare il dispositivo 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. Al momento della raccolta delle configurazioni, il CCP crea il pacchetto e lo invia al sensore tramite il meccanismo di comunicazione denominato SFTunnel.
Passaggio 4. Il CCP notifica al sensore di avviare il processo di installazione 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à della distribuzione è la Snort configurazione in cui la Snort configurazione viene testata localmente per garantirne la validità.
Snort. Quando la validità è dimostrata, la nuova configurazione viene spostata nella directory di produzione. Se la convalida ha esito negativo, in questo passaggio la distribuzione dei criteri ha esito negativo.
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 i pacchetti e LINA hanno esito positivo, il dispositivo gestito segnala Snort di riavviare o ricaricare 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 operazione riuscita e attende che venga riconosciuto dal centro di gestione.
Passaggio 8. Una volta ricevuto, il CCP contrassegna l'attività come riuscita e consente il completamento del pacchetto di criteri.
Risoluzione dei problemi
I problemi riscontrati durante il Policy Deployment processo possono essere dovuti, tra l'altro:
- Configurazione errata
- Comunicazione tra CCP e FTD
- Integrità del database e del sistema
- Difetti e avvertenze software
- Altre situazioni uniche
Alcuni di questi problemi possono essere risolti facilmente, mentre altri possono richiedere assistenza al Technical Assistance Center (TAC)Cisco.
L'obiettivo di questa sezione è quello di fornire tecniche per isolare il problema o determinare la causa principale.
Interfaccia grafica utente (GUI) di FMC
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.
Utilizzo delle trascrizioni di distribuzione
Passaggio 1. Estrarre l'Deploymentselenco nell'interfaccia utente Web di FMC.
Passaggio 2. Mentre la Deployments scheda è selezionata, fare clic su Show History.
Passaggio 3. All'interno della Deployment History confezione è possibile visualizzare tutte le precedenti distribuzioni 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 Transactiondatabase. 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 trascrizione per visualizzare la trascrizione della distribuzione individuale che può informare l'utente di errori e configurazioni inserite nei dispositivi gestiti.
Passaggio 6. Questa trascrizione può indicare alcune condizioni di errore e indicare un numero molto importante per il passaggio successivo: Transaction ID.
Passaggio 7. In un Firepower Deploymentelemento Transaction ID è possibile utilizzare per 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.
Risoluzione dei problemi relativi ai registri FMC
Anche se è opportuno incaricare Cisco TAC di analizzare i registri, una ricerca nei registri può contribuire all'isolamento iniziale del problema e a velocizzare la risoluzione. In FMC sono presenti più file di registro che rivelano i dettagli relativi al processo di distribuzione dei criteri.
I due registri 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 vengano eseguite solo read azioni. Per visualizzare tutti i file è necessario l'accesso alla directory principale.
/var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log
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.
Il transactionID valore incluso nella parte JSON del log può essere utilizzato per trovare le voci di log relative a un particolare tentativo di distribuzione.
10-May-2024 18:05:31.249,[INFO],(JsonRESTServerResource.java:111)
com.cisco.nm.vms.api.rest.DeploymentServerResource, ajp-nio-127.0.0.1-9009-exec-3
** REST Request [ DC ]
** ID : e45c6abd-0fff-4341-bdad-ddd5fee10034
** URL: POST https://localhost6/csm/api/deploy/GetTranscript
{
"data": {},
"deviceUUID": "49243dac-0ba7-11ef-af54-a592d78081a7",
"jobID": 34359753974,
"offset": {
"size": 20,
"start": 0
},
"requestID": "e3be908a0ef711ef9d519da21f9032fa",
"version": "7.2.5"
}
/var/log/sf/policy_deployment.log
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 CCP 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 linea con INFO start.
May 8 02:00:58 RTP-vFMC-Pod-09 ActionQueueScrape.pl[10413]: > SF::UMPD::CSMData::getPolicyRollbackInfo start (161.32M)
May 8 02:00:58 RTP-vFMC-Pod-09 ActionQueueScrape.pl[10413]: < SF::UMPD::CSMData::getPolicyRollbackInfo end (161.32M, 0.012(sec))
...
Risoluzione dei problemi dei dispositivi gestiti
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.
/ngfw/var/log/ngfwManager.log
In questo file di log vengono illustrate le procedure dettagliate adottate da Config Communication Manager e Config Dispatcher per comunicare con FMC, utilizzare il pacchetto di distribuzione e coordinare 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
/ngfw/var/log/sf/policy_deployment.log
Questo registro contiene i dettagli del criterio applicato a. Snort. Sebbene il contenuto del registro sia per lo più avanzato e richieda un'analisi TAC, è ancora 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)
Esempio
Passaggio 1. Una distribuzione non riesce.
Passaggio 2. Ottenere il Deploy Transcript e Transaction ID.
Passaggio 3. Inserire il supporto SSH nel Management Center computer e utilizzare l'utility Linux less per leggere il file come mostrato nel FMC:
Esempio: sudo less /var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log (la password sudo è la password utente per ssh).
Passaggio 4. Quando si less, utilizza la barra in avanti e si immette l'ID messaggio per cercare i log relativi all'ID transazione di distribuzione.
Esempio: /60129547881 (in usoless, n per passare al risultato successivo).
Esempio di messaggio in esecuzione
Esempio di messaggio di errore
5) Confrontare l'errore corretto con la tabella allegata dei messaggi di errore comuni.
ovvero, failed_to_retrieve_running_configuration si verifica durante errori di comunicazione tra i due dispositivi.
Messaggi di errore comuni
Si tratta dei messaggi di errore comuni che possono essere visualizzati sul front-end del Management Center Task router e del codice di errore che può essere visualizzato nel back-end.
Questi messaggi possono essere analizzati e confrontati con i motivi più comuni per possibili soluzioni. Nel caso in cui non vengano visualizzati o non risolvano la situazione, contattare TAC per assistenza.
—
| Codice di errore |
Messaggi di errore |
Motivo |
|
|
Errore di distribuzione - Il dispositivo ha cambiato 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, ciò viene impedito senza una 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 invia 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 dell'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 deve risolvere questo 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 devono 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. 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. In genere, ciò è dovuto alle seguenti possibilità: problemi di connettività o primario corrente non vengono aggiunti al cluster in FMC. È necessario risolverlo dopo la riattivazione della connettività o dopo l'aggiunta del database primario corrente al cluster FMC e il nuovo tentativo. È 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. |
Ciò può verificarsi se il dispositivo è in App Sync. Una volta completata la sincronizzazione dell'app, 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. Se dopo il timeout non è ancora possibile eseguire la distribuzione, contattare TAC. |
Informazioni correlate
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
4.0 |
02-Sep-2026
|
Nuova certificazione - Formattazione aggiornata |
3.0 |
13-May-2024
|
Certificazione |
2.0 |
23-Sep-2022
|
Release iniziale |
1.0 |
17-Feb-2020
|
Versione iniziale |
Feedback