Resolver problemas las implementaciones de la política en materia de defensa de la amenaza de FirePOWER
Contenido
Introducción
Con la defensa de la amenaza de Cisco FirePOWER (FTD), las características tradicionales del escudo de protección con estado ofrecidas por las características del Firewall adaptante de los dispositivos de seguridad (ASA) y de Next Gen (accionadas por el Snort) ahora se combinan en un producto. Debido a esto el cambio, infraestructura de la implementación de política en FTD ahora maneja los cambios de configuración para el código ASA (también designado LINA) y el Snort en un manojo. Este documento proporciona a una descripción general de alto nivel del proceso de la implementación de política en FTD y así como las técnicas de Troubleshooting básicas.
Prerrequisitos
Cisco recomienda que usted tiene conocimiento de los Productos siguientes:
- Centro de administración de FirePOWER (FMC)
- Defensa de la amenaza de FirePOWER (FTD)
Descripción de la implementación de política
Cisco FTD utiliza las implementaciones de política para manejar y para eliminar las configuraciones de dispositivos que se registran al centro de administración de FirePOWER (FMC) sí mismo. Dentro del despliegue, hay series de pasos que estén rotos en las “fases”.
Las fases FMC se pueden resumir en la lista siguiente.
| Fase 0 | Inicialización del despliegue |
| Fase 1 | Colección del objeto de base de datos |
| Fase 2 | Directiva y colección del objeto |
| Fase 3 | Generación del comando line configuration NGFW |
| Fase 4 | Generación del paquete del despliegue del dispositivo |
| Fase 5 | Enviando y recibiendo el paquete del despliegue |
| Fase 6 | Hasta que finalicen el despliegue, las acciones del despliegue, y los mensajes de éxito en el despliegue |
La comprensión de las fases, y saber dónde el error está situado en el proceso, pueden ayudar a resolver problemas los errores las caras de un ese sistema de FirePOWER. En algunas situaciones, puede ser un conflicto debido a las configuraciones previas o causado por una palabra clave que falta de la configuración avanzada de la flexión que pueda causar los errores que el informe del dispositivo no es explícito alrededor.
Descripción del ejemplo
Paso 1. El usuario hace clic el botón del “despliegue”, especificando qué dispositivo quisiera el usuario seleccionar.
Paso 2. El despliegue para un dispositivo está confiado una vez, el FMC comienza a recoger todas las configuraciones relevantes al dispositivo.
Paso 3. Una vez que se recogen las configuraciones, el FMC crea el paquete y lo envía al sensor sobre su mecanismo de la comunicación llamado SFTunnel.
Paso 4. El FMC entonces notifica el sensor para comenzar el proceso de instrumentación usando la directiva proporcionada, mientras que está atentas las respuestas individuales.
Paso 5. El dispositivo administrado desempaqueta el archivo y comienza a aplicar las configuraciones y los paquetes individuales.
A. La primera mitad del despliegue es la configuración del Snort donde la configuración del Snort se prueba localmente para asegurar su validez. Demostrado una vez ser válido la nueva configuración se mueve al directorio de la producción para el Snort. Si la validación falla, la implementación de política falla en este paso.
B. La segunda mitad del cargamento del paquete del despliegue es para la configuración de LINA donde es aplicada directamente al proceso de LINA por el proceso del ngfwManager. Si ocurre un error, los cambios se ruedan detrás y un error de la implementación de política ocurre.
Paso 6. Si el Snort y los paquetes de LINA son acertados, las señales del dispositivo administrado resoplan para recomenzar o para recargar para cargar la nueva configuración y salvar todas las configuraciones actuales.
Paso 7. Si todos los mensajes son acertados, el sensor envía un Mensaje de éxito y una espera para que sea reconocido por el centro de administración.
Paso 8. Una vez que está recibido, el FMC marca la tarea como éxito y permite que el manojo de la directiva acabe.
Resolución de problemas
Los problemas encontrados durante la implementación de política pueden ser debidos pero no limitados a las razones siguientes:
- Misconfiguration
- Comunicación entre FMC y FTD
- Base de datos y Estados generales del sistema
- Defectos del software y advertencias
- Otras situaciones únicas
Algunos de estos problemas pueden ser fijados fácilmente, mientras que otros pueden requerir la ayuda del centro de la asistencia técnica de Cisco (TAC).
La meta de esta sección es proporcionar a las herramientas y a las técnicas del troubleshooting para aislar el problema o para determinar la causa raíz.
El resolver problemas del Interfaz gráfica del usuario (GUI) FMC
Cisco recomienda cada sesión del troubleshooting para que los errores del despliegue comiencen en el dispositivo FMC.
En la ventana de la notificación de fallas, en todas las versiones más allá de 6.2.3, hay las herramientas adicionales del troubleshooting que pueden ayudar con los errores a que usted puede hacer frente.
Utilizar las transcripciones del despliegue
Paso 1. Levante las implementaciones enumeran en la red UI FMC.
Paso 2. Mientras que se selecciona la tabulación de las implementaciones, seleccione “la opción del historial de la demostración”.
Paso 3. Dentro del cuadro del historial de instalación, usted puede ver todas las implementaciones anteriores de su FMC. Seleccione el despliegue en el cual usted quisiera ver más datos.
Paso 4. Una vez que se selecciona un elemento del despliegue, le llevan a la selección de los detalles del despliegue que muestra una lista de todos los dispositivos dentro de la transacción. Estas entradas se analizan en las columnas siguientes: Número del dispositivo, Nombre del dispositivo, estatus, y transcripción.
Paso 5. Usted puede seleccionar el dispositivo en la pregunta y hacer clic en la opción de la transcripción para ver la transcripción individual del despliegue que puede informarle los errores así como las configuraciones que se ponen en los dispositivos administrados.
Paso 6. Esta transcripción puede señalar ciertas condiciones del error e indicar un número muy importante para el siguiente paso: ID de transacción.
Paso 7. En un despliegue de FirePOWER, el ID de transacción es qué se puede utilizar para seguir cada sección individual de una implementación de política. Con esto, en la línea de comando del dispositivo, usted puede obtener una versión más profundizada de estos datos para resolver problemas y el análisis.
Troubleshooting usando los registros FMC
Aunque es apropiado dedicar el TAC de Cisco analizar los registros, la mirada a través de los registros puede ayudar con el aislamiento del problema inicial y apresurar la resolución. Hay archivos del registro múltiples en FMC que revelen los detalles sobre el proceso de la implementación de política. Los dos registros lo más comúnmente posible referidos son policy_deployment.log y usmsharedsvcs.log.
Todos los ficheros mencionados en este documento se pueden ver con los comandos linux múltiples tales como más, menos y vi. Sin embargo, es muy importante asegurarse de que solamente las acciones leídas están realizadas a él. Todos los ficheros requieren el acceso a raíz poder verlas.
/var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log
Este registro marca claramente el principio de la tarea de la implementación de política en FMC y la realización de cada fase, que ayuda a determinar la fase adonde el despliegue se ejecutó en un error, junto con el código de falla. El valor del “transactionID” incluido en la porción JSON del registro se puede utilizar para encontrar las entradas de registro relacionadas con una tentativa determinada del despliegue.
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
Mientras que este archivo del registro ha existido en 6.x release/versión, a partir de 6.4, su cobertura fue ampliado. Ahora describe los pasos detallados tomados en FMC para construir los paquetes del despliegue, por lo tanto se utiliza mejor para analizar los errores a partir de la fase 1 - 4. El principio de cada fase es marcado por una línea con la “INFORMACIÓN que comienza XYZ”:
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) ...
El resolver problemas del dispositivo administrado
Hay fases y secciones adicionales dependiendo del paquete del dispositivo, de configuración de alta disponibilidad, y del resultado de las fases anteriores para cada dispositivo administrado. Si un problema de instrumentación se aísla a un error en el dispositivo administrado, el troubleshooting adicional se puede realizar en el dispositivo usando dos abre una sesión el dispositivo: policy_deployment.log y ngfwManager.log.
/ngfw/var/log/ngfwManager.log
Este archivo del registro provee de los pasos detallados tomados por el encargado de la comunicación de los Config y el repartidor de los Config para comunicar con FMC, trabajo el paquete del despliegue, y orquestra la validación y la aplicación del Snort y de las configuraciones de LINA. Éstos son algunos ejemplos de ngfwManager.log que representan el principio de las fases importantes:
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
Este registro contiene los detalles de la directiva aplicada para resoplar. El contenido del registro se avanza sin embargo y requiere sobre todo el análisis por TAC, él es todavía posible rastrear el proceso usando algunas entradas dominantes:
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)
Ejemplo:
Paso 1. Un despliegue falla
Paso 2. Obtenga la transcripción y el ID de transacción del desplegar.
Paso 3. SSH en su centro de administración y utiliza la utilidad de Linux menos para leer el fichero como sigue en su FMC:
Ejemplo: “sudo menos /var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log” (la contraseña del sudo es su contraseña de usuarios para el ssh)
Paso 4. Una vez que usted es adentro menos, utilice la barra diagonal y ingrese en el ID del mensaje para buscar para los registros relacionados con el transactionID del despliegue.
Ejemplo: El "/60129547881" {mientras que adentro menos, uso n de navegar al resultado siguiente}
Ejemplo de funcionar con el mensaje:
Ejemplo del mensaje del error:
5) Compare el error apropiado a la tabla asociada de mensajes de la falla común.
Es decir el failed_to_retrieve_running_configuration ocurre durante los errores de comunicación entre los dos dispositivos.
Mensajes de la falla común
Abajo son averiados los mensajes de la falla común que se pueden considerar en la parte frontal de la tarea del centro de administración así como del código de error que se pueden considerar en la parte. Estos mensajes se pueden analizar y comparar con las razones comunes para las soluciones posibles.
En caso que éstos no se vean, ni resuelvan su situación que esté ocurriendo, entre en contacto con por favor TAC para la ayuda.
| Código de error |
Mensajes de error |
Motivo |
| device_has_changed_domain |
Error del despliegue - El dispositivo ha cambiado el dominio de {SRCDOMAIN} a {DESTINATIONDOMAIN}. Inténtelo de nuevo más tarde |
Este error ocurre cuando un dispositivo se está moviendo o está típicamente en curso de ser tomado de un segundo dominio. Un cambiar de frente mientras que está ocurriendo ninguna información del cruz-dominio enmienda generalmente este problema. |
| device_currently_under_deployment |
El despliegue falló debido a otro despliegue en curso para este dispositivo. Inténtelo de nuevo más tarde |
Esto está señalada típicamente cuando el despliegue se acciona en un dispositivo que experimenta el despliegue. En algunas versiones esto se previene sin una notificación de fallas; sin embargo, esta fase todavía existe para resolver problemas la ayuda. |
| device_not_member_of_container |
El despliegue no se puede realizar en un dispositivo individual que sea un miembro de un racimo. Intento otra vez más adelante, desplegando el racimo. |
Este mensaje es aplicable para FTD en los dispositivos con el encargado del chasis del sistema operativo extensible de FirePOWER (FXOS). Si el racimo se emplea en FXOS, pero no el FMC, se muestra este mensaje. Cree por favor el racimo en el dispositivo del centro de administración primero antes de intentar desplegar. |
| policy_altered_after_timestamp_for_other_devices_in_job_error |
Las directivas para uno o más dispositivos se han alterado desde {GRUPO FECHA/HORA}. Despliegue de la recomprobación. |
Se muestra este error si alguna directiva/objeto se altera para cualquier dispositivo en el trabajo del despliegue después de que los activadores del usuario desplieguen y antes de los elementos CSM y de las fotos del dominio se crean. Un cambiar de frente fija este problema. Esto puede ocurrir cuando muchos usuarios están utilizando el mismo FMC que corrigen los objetos y que guardan el rato que golpea el desplegar. |
| policy_altered_after_timestamp_error |
La directiva {nombre de la directiva} se ha alterado desde {grupo fecha/hora}. Despliegue de la recomprobación. |
Se muestra este error si alguna directiva/objeto se altera para el dispositivo en cuestión en el trabajo del despliegue, después de que los activadores del usuario desplieguen y antes de las fotos CSM y del dominio se crean. Un cambiar de frente fija este problema. |
| csm_snapshot_error |
El despliegue falló debido al error que recogía las directivas y los objetos. Si el problema persiste después de revisar, entre en contacto con el TAC de Cisco. |
Si se proporciona una importación reciente de la directiva, espere una hora o tan e intente otra despliegan. |
| domain_snapshot_timeout |
El despliegue falló debido al descanso que recogía las directivas y los objetos. Si el problema persiste después de revisar, entre en contacto con el TAC de Cisco. |
La foto del dominio tiene un descanso de 5 minutos por abandono. Si el sistema está bajo mucha carga, o el hipervisor está funcionando incorrectamente o bajo carga para un virtual, éste puede causar los retrasos artificiales en la llamada. Esto puede ocurrir si el centro de administración o el dispositivo no se proporciona la cantidad apropiada de recursos de memoria también. Si esto sucede sin la carga, o no procede en otro momento, entre en contacto con TAC. |
| domain_snapshot_errors |
Despliegue fallado en la directiva y la colección del objeto. Si el problema persiste después de revisar, entre en contacto con el TAC de Cisco. |
Entre en contacto con TAC. Se requiere el troubleshooting avanzado. |
| failed_to_retrieve_running_configuration |
El despliegue falló debido al error que extraía la información de la configuración corriente del dispositivo. Despliegue de la recomprobación. |
Este mensaje puede ocurrir cuando la Conectividad entre un sensor del extremo y un FMC no está trabajando como se esperaba. Verifique la salud del túnel entre las unidades y vigile la Conectividad entre los dos dispositivos. |
| device_is_busy |
El despliegue fallado como dispositivo puede ejecutar un despliegue o un recomienzo anterior. Si el problema persiste después de revisar más adelante, entre en contacto con el TAC de Cisco. |
Se muestra este mensaje, cuando FMC intenta un desplegar, mientras que un despliegue anterior está en curso en FTD. Sucede típicamente cuando un despliegue anterior es inacabado en FTD y el FTD reiniciado o el proceso del ngfwManager en FTD recomenzado. Una recomprobación después de 20 minutos para permitir los procesos al descanso debe resolver formalmente este problema. Si después de retrasar o si el retraso no es aceptable, entre en contacto con TAC. |
| no_response_for_show_cmd |
El despliegue falló debido a los problemas de la Conectividad con el dispositivo o el dispositivo no está respondiendo. Si el problema persiste después de revisar más adelante, entre en contacto con el TAC de Cisco. |
FMC publica ciertos comandos " show " de LINA de traer la configuración corriente para la generación de la configuración. Esto puede suceder cuando hay problemas de conectividad o cuestiones con el proceso del ngfwManager en el sensor del extremo. En caso que usted no esté haciendo frente la Conectividad publica entre sus unidades, entra en contacto con TAC. |
| network_latency_or_device_not_reachable |
Fallada despliegue debido a las fallas en la comunicación con el dispositivo. Si el problema persiste después de revisar más adelante, entre en contacto con el TAC de Cisco. |
Ocurre generalmente con la alta latencia de red entre los dispositivos para causar un descanso de la directiva. Verifique que la latencia de red entre los dispositivos para verificarlo haga juego los mínimos para la versión mencionada en la guía de usuario. |
| slave_app_sync |
El despliegue fallado como sincronización de la configuración del racimo está en curso. Despliegue de la recomprobación. |
Esto es aplicable solamente para las disposiciones del racimo FTD. Si un despliegue se intenta en un racimo FTD mientras que la sincronización del app (sincronización de la configuración) está en curso, lo mismo es rechazada por FTD. Una recomprobación después de la sincronización de la configuración debe solucionar este problema. El estatus actual del racimo se puede seguir usando este comando en el dispositivo administrado CLISH: > muestre la información del clúster |
| asa_configuration_generation_errors |
El despliegue falló debido al error en la generación de la configuración del dispositivo. Si el problema persiste después de revisar, entre en contacto con el TAC de Cisco. |
Después de pasar los registros USMS mencionados anteriormente, usted puede poder ver qué configuración está causando el error. Éstos son generalmente los bug en los cuales los registros se pueden hojear a través de la herramienta del bug de Cisco o TAC de Cisco el entrar en contacto con para resolver problemas más lejos. |
| interface_out_of_date |
El despliegue falló porque los interfaces en el dispositivo son anticuados. Salve la configuración en los interfaces página y recomprobación. |
Esto ocurre en los modelos 4100's o 9300's si el interfaz es no afiliado del dispositivo durante o justo antes de un desplegar. Verifique que el interfaz sea completamente asociado o no afiliado antes de intentar el desplegar. |
| device_package_error |
El despliegue falló debido al error en la generación de la configuración para el dispositivo. Si el problema persiste después de revisar, entre en contacto con el TAC de Cisco. |
Éste es el error que indica el error generar la configuración del dispositivo para el dispositivo. Entre en contacto con TAC. |
| device_package_timeout |
El despliegue falló debido al descanso durante la generación de la configuración. Si el problema persiste después de revisar, entre en contacto con el TAC de Cisco. |
Esto puede suceder si el tiempo de espera existe entre dispositivos más allá los iIntervalos normales. Entre en contacto con TAC si después de que el tiempo de espera sea normalizado, todavía ocurre este problema. |
| device_communication_errors |
El despliegue falló debido al error que comunicaba con el dispositivo. Controle la conectividad de red y revise el despliegue. |
Este mensaje es el retraso por cualquier problema de comunicación entre los dispositivos. Debido a su naturaleza vaga, se escribe como el retraso para estado que ha ocurrido un error de conectividad desconocido. |
| unable_to_initiate_deployment_dc |
El despliegue falló debido a la directiva que desplegaba del error al dispositivo. Despliegue de la recomprobación. |
Una recomprobación debe solucionar este problema. Esto puede ocurrir cuando el FMC no puede comenzar el despliegue debido a un bloqueo temporal en la base de datos. |
| device_failure_timeout |
Despliegue a fallada dispositivo debido al descanso. Despliegue de la recomprobación. |
Esto se relaciona con el despliegue FTD. Los procesos en FTD esperan 30 minutos el envío para completar el despliegue. Si no, mide el tiempo hacia fuera. Si ocurre esto, verifique la Conectividad del inter-dispositivo y si la Conectividad está como se esperaba, entre en contacto con TAC. |
| device_failure_download_timeout |
El despliegue falló debido a la configuración de la transferencia del descanso al dispositivo. Si el problema persiste después de revisar, entre en contacto con el TAC de Cisco. |
Esto se relaciona con el despliegue FTD. El FTD no puede descargar todos los archivos de configuración del dispositivo durante despliega debido a los problemas de la Conectividad. Revise por favor después de que se haya verificado la conectividad de red. Si se ha verificado esto, entre en contacto con TAC. |
| device_failure_configuration |
Fallada despliegue debido al Error de configuración. Si el problema persiste después de revisar, entre en contacto con el TAC de Cisco. |
Cualquier error en la configuración generada por FMC para el dispositivo debe dar lugar a este poste del error se aplica. Esto necesita ser analizada en los registros USMS para verificar se consideran qué problemas y para intentar rodarlos detrás. Una vez que está reparada, esto requiere generalmente la intervención de TAC y la creación del bug si los registros no se pueden corresponder con con un defecto conocido en la Herramienta de búsqueda del bug de Cisco. |
| deployment_timeout_no_response_from_device |
El despliegue falló debido al descanso que comunicaba con el dispositivo. Si el problema persiste después de revisar, entre en contacto con el TAC de Cisco. |
Este descanso ocurre si el FMC no ha oído detrás de un dispositivo después de 45 minutos o más pronto dependiendo de la versión. Esto es un error de comunicación. Verifique la comunicación y si está verificado, contacto TAC. |
| device_failure_change_master |
El despliegue a agruparse fallado como unidad principal ha cambiado. Despliegue de la recomprobación. |
Para un despliegue de la disposición del racimo FTD, si el nodo maestro cambia cuando el despliegue está en curso en el dispositivo (notificación del poste), se indica este error. Revise una vez que el nodo maestro es estable. El estado del miembro actual del racimo puede ser seguido usando este comando en el dispositivo administrado CLISH: > muestre la información del clúster |
| device_failure_unknown_master |
Despliegue para agrupar fallada debido al error que identifica la unidad principal. Despliegue de la recomprobación. |
FMC ha no podido determinar el nodo maestro actual durante despliega. Esto podía ser típicamente debido a un par de posibilidades: Problemas de la Conectividad o master de la corriente que no es agregado al racimo en FMC. Debe conseguir resuelto después de que se reasegure la Conectividad o después de agregar al master actual al racimo FMC y a una recomprobación se hace. El estatus actual del racimo se puede seguir usando este comando en el dispositivo administrado CLISH: > muestre la información del clúster |
| cd_deploy_app_sync |
El despliegue fallado como sincronización de la configuración del racimo está en curso. Despliegue de la recomprobación. |
Esto puede ocurrir si el dispositivo está en la sincronización del App, una vez que la sincronización del App es completa, revisa por favor el despliegue una vez más. |
| cd_existing_deployment | El despliegue falló debido estar en conflicto con el despliegue anterior en curso. Si el problema persiste después de revisar, entre en contacto con el TAC de Cisco. |
Esto puede ocurrir si un despliegue todavía va en un lado, pero no el otro. Éstos son causados generalmente por los problemas de comunicación entre los dispositivos. Entre en contacto con TAC si después de que ocurra el descanso, usted no puede todavía desplegar. |
Entre en contacto con TAC para la ayuda
En caso que la información antedicha no permita para que proceda una implementación de política, o si el problema aparece no ser relacionado con un comportamiento documentado preexistente, para utilizar por favor los pasos proporcionados en el link siguiente para generar un fichero del Troubleshooting y para alcanzar hacia fuera a TAC para el análisis y para introducir errores de funcionamiento la creación.
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)