A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Com defesa da ameaça de Cisco FirePOWER (FTD), as características tradicionais do firewall stateful oferecidas pelos recursos de firewall adaptáveis das ferramentas de segurança (ASA) e do Next Gen (postos pelo Snort) são combinadas agora em um produto. Devido a isto a mudança, infraestrutura da distribuição de política em FTD segura agora alterações de configuração para o código ASA (igualmente referido como LINA) e o Snort em um pacote. Este original fornece uma visão geral de alto nível do processo da distribuição de política em FTD e assim como em técnicas do Troubleshooting básico.
Cisco recomenda que você tem o conhecimento do seguinte Produtos:
aviso: As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.
Cisco FTD utiliza distribuições de política para controlar e eliminar configurações para os dispositivos que são registrados ao centro de gerenciamento de FirePOWER (FMC) próprio. Dentro do desenvolvimento, há umas séries de etapas que se quebram em “fases”.
As fases FMC podem ser resumidas na seguinte lista.
Fase 0 | Iniciação do desenvolvimento |
Fase 1 | Coleção do objeto de base de dados |
Fase 2 | Política e coleção do objeto |
Fase 3 | Geração do comando line configuration NGFW |
Fase 4 | Geração do pacote do desenvolvimento do dispositivo |
Fase 5 | Enviando e recebendo o pacote do desenvolvimento |
Fase 6 | Durante o desenvolvimento, as ações do desenvolvimento, e as mensagens de sucesso de distribuição |
Compreender as fases, e saber onde a falha é ficada situada no processo, podem ajudar em pesquisar defeitos as falhas as caras de um esse sistema de FirePOWER. Em algumas situações, pode ser um conflito devido às configurações precedente ou causado por uma palavra-chave faltante da configuração avançada do cabo flexível que possa causar falhas que os relatórios do dispositivo não são explícitos aproximadamente.
Etapa1. O usuário clica o botão do “desenvolvimento”, especificando que dispositivo o usuário gostaria de selecionar.
Etapa 2. O desenvolvimento para um dispositivo é comprometido uma vez, o FMC começa a recolher todas as configurações relevantes ao dispositivo.
Etapa 3. Uma vez que as configurações são recolhidas, o FMC cria o pacote e envia-o sobre ao sensor sobre seu mecanismo de uma comunicação chamado SFTunnel.
Etapa 4. O FMC notifica então o sensor para começar o processo de desenvolvimento usando a política fornecida, ao escutar as respostas individuais.
Etapa 5. O dispositivo gerenciado desembala o arquivo e começa-o aplicar as configurações e os pacotes individuais.
A. A primeira metade do desenvolvimento é a configuração do Snort onde a configuração do Snort é testada localmente para assegurar sua validez. Provado uma vez ser válido a configuração nova é movido para o diretório da produção para o Snort. Se a validação falha, a distribuição de política falha nesta etapa.
B. A segunda metade da carga do pacote do desenvolvimento é para a configuração de LINA onde é aplicada diretamente ao processo de LINA pelo processo do ngfwManager. Se uma falha ocorre, as mudanças estão roladas para trás e uma falha da distribuição de política ocorre.
Etapa 6. Se o Snort e os pacotes de LINA são bem sucedidos, os sinais do dispositivo gerenciado roncam para reiniciar ou recarregar a fim carregar a configuração nova e salvar todas as configurações atual.
Passo 7. Se todas as mensagens são bem sucedidas, o sensor envia um mensagem de sucesso e uma espera para que esteja reconhecido pelo centro de gerenciamento.
Etapa 8. Uma vez que recebido, o FMC marca a tarefa como um sucesso e permite que o pacote da política termine.
Os problemas encontrados durante a distribuição de política podem ser devidos mas não limitados às seguintes razões:
Algumas destas edições podem facilmente ser fixadas, quando outro puderem exigir o auxílio do centro de assistência técnica da Cisco (TAC).
O objetivo desta seção é fornecer ferramentas de Troubleshooting e técnicas para isolar a edição ou para determinar a causa de raiz.
Cisco recomenda cada sessão de Troubleshooting para que as falhas do desenvolvimento comecem no dispositivo FMC.
No indicador da notificação de falha, em todas as versões além de 6.2.3, há as ferramentas do Troubleshooting adicional que podem ajudar com as falhas que você pode enfrentar.
Etapa 1. Levante as disposições alistam na Web UI FMC.
Etapa 2. Quando a aba das disposições for selecionada, selecione da “a opção da história mostra”.
Etapa 3. Dentro da caixa da história do desenvolvimento, você pode ver todas as disposições precedentes de seu FMC. Selecione o desenvolvimento em que você gostaria de ver mais dados.
Etapa 4. Uma vez que um elemento do desenvolvimento é selecionado, você está tomado à seleção dos detalhes do desenvolvimento que mostra uma lista de todos os dispositivos dentro da transação. Estas entradas são divididas nas seguintes colunas: Número do dispositivo, nome de dispositivo, estado, e transcrito.
Etapa 5. Você pode selecionar o dispositivo na pergunta e clicar sobre a opção do transcrito para ver o transcrito individual do desenvolvimento que pode o informar das falhas assim como das configurações que são colocadas nos dispositivos gerenciado.
Etapa 6. Este transcrito pode designar determinadas condições de falha assim como indicar um número muito importante para a próxima etapa: ID de transação.
Passo 7. Em um desenvolvimento de FirePOWER, o ID de transação é o que pode ser usado para seguir cada seção individual de uma distribuição de política. Com isto, nos dados da linha de comando do dispositivo, você pode obter uma versão mais detalhada destes dados para a pesquisa de defeitos e a análise.
Dica: Caso você for incapaz de encontrar o ID de transação ou se você está em uma versão antes que este estiver imprimido, o log acima pode ainda ser do uso para encontrar mensagens de falha individuais.
Embora é apropriado contratar o tac Cisco analisar os logs, olhar através dos logs pode ajudar com isolamento de problema inicial e expedir a definição. Há uns arquivos de registro múltiplos em FMC que revelam os detalhes sobre o processo da distribuição de política. Os dois logs o mais geralmente providos são policy_deployment.log e usmsharedsvcs.log.
Todos os arquivos mencionados neste original podem ser vistos com os comandos linux múltiplos tais como mais, menos e vi. Contudo, é muito importante assegurar-se de que somente as ações lidas lhe estejam executadas. Todos os arquivos exigem o acesso raiz poder os ver.
Este log marca claramente o começo da tarefa da distribuição de política em FMC e a conclusão de cada fase, que ajuda a determinar a fase aonde o desenvolvimento foi executado em uma falha, junto com o código de falha. O valor do “transactionID” incluído na parcela JSON do log pode ser usado para encontrar entradas de registro relativas a uma tentativa particular do desenvolvimento.
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" ] }
Quando este arquivo de registro existir durante todo as liberações 6.x, partindo de 6.4, sua cobertura esteve expandida. Descreve agora as etapas detalhadas tomadas em FMC para construir os pacotes do desenvolvimento, consequentemente é usada melhor analisando falhas da fase 1 - 4. O começo de cada fase é marcado por uma linha com a “INFORMAÇÃO que começa o 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) ...
Há umas fases e umas seções adicionais segundo o pacote do dispositivo, a Alta disponibilidade da configuração, e o resultado de fases prévias para cada dispositivo gerenciado. Se um problema de desenvolvimento é isolado a uma falha no dispositivo gerenciado, um Troubleshooting mais adicional pode ser executado no dispositivo que usa dois entra o dispositivo: policy_deployment.log e ngfwManager.log.
Este arquivo de registro fornece as etapas detalhadas tomadas pelo gerente de uma comunicação da configuração e pelo expedidor da configuração para comunicar-se com o FMC, trabalho o pacote do desenvolvimento, e orquestra a validação e o aplicativo do Snort e das configurações de LINA. Estes são alguns exemplos de ngfwManager.log que representam o começo de fases principais:
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
Este log contém os detalhes da política aplicada para roncar. O índice do log na maior parte é avançado embora e exige a análise pelo TAC, ele é ainda possível para seguir o processo usando algumas entradas chaves:
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)
Etapa1. Um desenvolvimento falha
Etapa 2. Obtenha o transcrito e o ID de transação da distribuição.
Etapa 3. O SSH em seu centro de gerenciamento e utiliza a utilidade de Linux menos para ler o arquivo como segue em seu FMC:
Exemplo: “sudo menos /var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log” (a senha do sudo é sua senha de usuários para o ssh)
Etapa 4. Uma vez que você é dentro menos, use a barra e entre-a no ID de mensagem para procurar pelos logs relativos ao transactionID do desenvolvimento.
Exemplo: "/60129547881" {quando dentro menos, uso n navegar ao resultado seguinte}
Exemplo de executar a mensagem:
Exemplo do mensagem de falha:
5) Compare a falha apropriada à tabela anexada de mensagens da falha comum.
Isto é o failed_to_retrieve_running_configuration ocorre durante falhas de comunicação entre os dois dispositivos.
Falham abaixo as mensagens da falha comum que podem ser consideradas na parte frontal da tarefa do centro de gerenciamento assim como do código de erro que podem ser considerados na parte posterior. Estas mensagens podem ser analisadas e comparado com os motivos comuns para resoluções possíveis.
Caso estes não forem vistos, nem não resolverem sua situação que está ocorrendo, contacte por favor o TAC para o auxílio.
Código de erro |
Mensagens de Erro |
Razão |
device_has_changed_domain |
Falha do desenvolvimento - O dispositivo mudou o domínio de {SRCDOMAIN} a {DESTINATIONDOMAIN}. Try again later. |
Este erro tipicamente ocorre quando um dispositivo se está movendo ou é em processo da tomada de um segundo domínio. Desmover quando nenhuma informação do domínio cruzado ocorrer altera geralmente esta edição. |
device_currently_under_deployment |
O desenvolvimento falhou devido a um outro desenvolvimento em andamento para este dispositivo. Try again later. |
Isto é relatado tipicamente quando o desenvolvimento é provocado em um dispositivo que se submete ao desenvolvimento. Em algumas versões isto é impedido sem uma notificação de falha; contudo, esta fase ainda existe para a assistência paraTroubleshooting. |
device_not_member_of_container |
O desenvolvimento não pode ser executado em um dispositivo individual que seja um membro de um conjunto. Tentativa outra vez mais tarde, distribuindo o conjunto. |
Esta mensagem é aplicável para FTD em dispositivos com o gerente operativo elástico do chassi do sistema de FirePOWER (FXO). Se o conjunto é construído em FXO, mas não no FMC, esta mensagem está mostrada. Crie por favor o conjunto no dispositivo do centro de gerenciamento primeiramente antes de tentar distribuir. |
policy_altered_after_timestamp_for_other_devices_in_job_error |
As políticas para uns ou vários dispositivos foram alteradas desde {TIMESTAMP}. Desenvolvimento da nova tentativa. |
Este erro está mostrado se alguns política/objeto está alterada para qualquer dispositivo no trabalho do desenvolvimento depois que os disparadores do usuário distribuem e antes dos elementos CS e dos instantâneos do domínio estão criados. Desmover fixa esta edição. Isto pode ocorrer quando muitos usuários usarem os mesmos objetos e economia da edição FMC o quando que bate a distribuição. |
policy_altered_after_timestamp_error |
A política {nome da política} foi alterada desde {Timestamp}. Desenvolvimento da nova tentativa. |
Este erro está mostrado se alguns política/objeto está alterada para o dispositivo interessado no trabalho do desenvolvimento, depois que os disparadores do usuário distribuem e antes dos instantâneos CS e de domínio estão criados. Desmover fixa esta edição. |
csm_snapshot_error |
O desenvolvimento falhou devido à falha que recolhe políticas e objetos. Se o problema persiste após experimentar de novo, contacte o tac Cisco. |
Se uma importação recente da política é fornecida, espere uma hora ou assim e tente outra distribuem. |
domain_snapshot_timeout |
O desenvolvimento falhou devido ao intervalo que recolhe políticas e objetos. Se o problema persiste após experimentar de novo, contacte o tac Cisco. |
O instantâneo do domínio tem um intervalo dos minutos 5 à revelia. Se o sistema está sob a carga elevada, ou o hypervisor está funcionando mal ou sob a carga para um virtual, este pode causar atrasos não naturais no atendimento. Isto pode ocorrer se o centro de gerenciamento ou o dispositivo não são fornecidos a quantidade de memória apropriada dos recursos também. Se isto acontece sem carga, ou não continua mais tarde, contacte o TAC. |
domain_snapshot_errors |
Desenvolvimento falhado na política e na coleção do objeto. Se o problema persiste após experimentar de novo, contacte o tac Cisco. |
Contacte o TAC. O Troubleshooting avançado é exigido. |
failed_to_retrieve_running_configuration |
O desenvolvimento falhou devido à falha que recupera informação de configuração running do dispositivo. Desenvolvimento da nova tentativa. |
Esta mensagem pode ocorrer quando a Conectividade entre um sensor da extremidade e um FMC não está trabalhando como esperado. Verifique a saúde do túnel entre as unidades e monitore a Conectividade entre os dois dispositivos. |
device_is_busy |
O desenvolvimento falhado como o dispositivo pode executar um desenvolvimento ou um reinício precedente. Se o problema persiste após experimentar de novo mais tarde, contacte o tac Cisco. |
Esta mensagem está mostrada, quando FMC tenta uma distribuição, quando um desenvolvimento precedente for em andamento em FTD. Acontece tipicamente quando um desenvolvimento precedente é inacabado em FTD e o FTD recarregado ou o processo do ngfwManager em FTD reiniciado. Uma nova tentativa após 20 minutos para permitir processos formalmente ao intervalo deve resolver esta edição. Se após o atraso ou se o atraso não é aceitável, contacte o TAC. |
no_response_for_show_cmd |
O desenvolvimento falhou devido aos problemas de conectividade com o dispositivo ou o dispositivo não está respondendo. Se o problema persiste após experimentar de novo mais tarde, contacte o tac Cisco. |
FMC emite determinados comandos " show " de LINA buscar a configuração running para a geração da configuração. Isto pode acontecer quando há uns problemas de conectividade ou umas edições com o processo do ngfwManager no sensor da extremidade. Caso você não estiver enfrentando problemas de conectividade entre suas unidades, contacte o TAC. |
network_latency_or_device_not_reachable |
O desenvolvimento falhou devido à falha de comunicações com dispositivo. Se o problema persiste após experimentar de novo mais tarde, contacte o tac Cisco. |
Ocorre geralmente com latência da rede alta entre os dispositivos para causar um intervalo da política. Verifique que a latência da rede entre os dispositivos para o verificar combina os mínimos para a versão mencionada no Guia do Usuário. |
slave_app_sync |
O desenvolvimento falhado como a sincronização da configuração de grânulos é em andamento. Desenvolvimento da nova tentativa. |
Isto é aplicável somente para instalações do conjunto FTD. Se um desenvolvimento está tentado em um conjunto FTD quando a sincronização do app (sincronização de configuração) for em andamento, o mesmo está rejeitado por FTD. Uma nova tentativa após a sincronização de configuração deve resolver esta edição. O estado atual do conjunto pode ser seguido usando este comando no dispositivo gerenciado CLISH: > mostre a informação de cluster |
asa_configuration_generation_errors |
O desenvolvimento falhou devido à falha em gerar a configuração de dispositivo. Se o problema persiste após experimentar de novo, contacte o tac Cisco. |
Após ir sobre os logs US mencionados acima, você pode poder ver que configuração está causando o erro. Estes são geralmente os erros em que os logs podem ser consultados através da ferramenta do Bug da Cisco ou tac Cisco do contato para pesquisar defeitos mais. |
interface_out_of_date |
O desenvolvimento falhou porque as relações no dispositivo são expirado. Salvar a configuração nas relações página e nova tentativa. |
Isto ocorre nos modelos 4100's ou 9300's se a relação é não-associada do dispositivo durante ou mesmo antes de uma distribuição. Verifique que a relação é inteiramente associada ou não-associada antes de tentar a distribuição. |
device_package_error |
O desenvolvimento falhou devido à falha em gerar a configuração para o dispositivo. Se o problema persiste após experimentar de novo, contacte o tac Cisco. |
Este é o erro que indica a falha gerar a configuração de dispositivo para o dispositivo. Contacte o TAC. |
device_package_timeout |
O desenvolvimento falhou devido ao intervalo durante a geração da configuração. Se o problema persiste após experimentar de novo, contacte o tac Cisco. |
Isto pode acontecer se a latência existe entre os dispositivos além dos intervalos normais. Contacte o TAC se depois que a latência é normalizada, esta edição ainda ocorre. |
device_communication_errors |
O desenvolvimento falhou devido à falha que comunica-se com o dispositivo. Verifique a conectividade de rede e experimente de novo o desenvolvimento. |
Esta mensagem é a reserva para todos os problemas de comunicação entre os dispositivos. Devido a sua natureza vaga, escreve-se como a reserva para indicar que um erro de conectividade desconhecido ocorreu. |
unable_to_initiate_deployment_dc |
O desenvolvimento falhou devido à política de distribuição da falha ao dispositivo. Desenvolvimento da nova tentativa. |
Uma nova tentativa deve resolver esta edição. Isto pode ocorrer quando o FMC é incapaz de começar o desenvolvimento devido a um fechamento provisório no base de dados. |
device_failure_timeout |
Desenvolvimento a falhado dispositivo devido ao intervalo. Desenvolvimento da nova tentativa. |
Isto é relacionado ao desenvolvimento FTD. Os processos em FTD esperam 30 minutos pela expedição para terminar o desenvolvimento. Se não, cronometra para fora. Se isto ocorre, verifique a Conectividade do inter-dispositivo e se a Conectividade é como esperado, contacte o TAC. |
device_failure_download_timeout |
O desenvolvimento falhou devido à configuração do fazendo download do intervalo ao dispositivo. Se o problema persiste após experimentar de novo, contacte o tac Cisco. |
Isto é relacionado ao desenvolvimento FTD. O FTD é incapaz de transferir todos os arquivos de configuração de dispositivo durante distribui devido aos problemas de conectividade. Experimente de novo por favor depois que a conectividade de rede foi verificada. Se isto foi verificado, contacte o TAC. |
device_failure_configuration |
Falhado desenvolvimento devido ao erro de configuração. Se o problema persiste após experimentar de novo, contacte o tac Cisco. |
Todos os erros na configuração gerada por FMC para o dispositivo devem conduzir a este cargo do erro aplicam-se. Isto precisa de ser analisado nos logs US para verificar que edições são consideradas e para tentar rolá-los para trás. Uma vez que reparado, isto exige geralmente a intervenção TAC e a criação do erro se os logs não podem ser combinados com um defeito conhecido na ferramenta de pesquisa do Bug da Cisco. |
deployment_timeout_no_response_from_device |
O desenvolvimento falhou devido ao intervalo que comunica-se com o dispositivo. Se o problema persiste após experimentar de novo, contacte o tac Cisco. |
Este intervalo ocorre se o FMC não se ouviu para trás de um dispositivo após 45 minutos ou mais logo segundo a versão. Este é um erro de comunicação. Verifique uma comunicação e se verificado, o contato TAC. |
device_failure_change_master |
O desenvolvimento a aglomerar-se falhado como a unidade mestra mudou. Desenvolvimento da nova tentativa. |
Para um desenvolvimento da instalação do conjunto FTD, se o nó mestre comuta quando o desenvolvimento é em andamento no dispositivo (notificação do cargo), este erro é indicado. Experimente de novo uma vez que o nó mestre é estável. O estado atual do membro de grânulos pode ser seguido usando este comando no dispositivo gerenciado CLISH: > mostre a informação de cluster |
device_failure_unknown_master |
Desenvolvimento para aglomerar falhado devido à falha que identifica a unidade mestra. Desenvolvimento da nova tentativa. |
FMC foi incapaz de determinar o nó mestre atual durante distribui. Isto podia ser tipicamente devido a um par possibilidades: Problemas de conectividade ou mestre atual que não está sendo adicionado ao conjunto em FMC. Deve obter resolved depois que a Conectividade está ressegurada ou após ter adicionado o mestre atual ao conjunto FMC e a uma nova tentativa está feito. O estado atual do conjunto pode ser seguido usando este comando no dispositivo gerenciado CLISH: > mostre a informação de cluster |
cd_deploy_app_sync |
O desenvolvimento falhado como a sincronização da configuração de grânulos é em andamento. Desenvolvimento da nova tentativa. |
Isto pode ocorrer se o dispositivo está na sincronização do App, uma vez que a sincronização do App está completa, experimenta de novo por favor o desenvolvimento uma vez mais. |
cd_existing_deployment | O desenvolvimento falhou devido opor ao desenvolvimento precedente em curso. Se o problema persiste após experimentar de novo, contacte o tac Cisco. |
Isto pode ocorrer se um desenvolvimento ainda está indo em um lado, mas não o outro. Estes são causados geralmente por problemas de comunicação entre os dispositivos. Contacte o TAC se depois que o intervalo ocorre, você é ainda incapaz de distribuir. |
Caso a informação acima não permitir uma distribuição de política continuar, ou se a edição parece não ser relacionada a um comportamento documentado PRE-existente, use por favor as etapas fornecidas na relação seguinte para gerar um arquivo da pesquisa de defeitos e para alcançá-lo para fora ao TAC para a criação da análise e do erro.