O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
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.
Este documento inclui perguntas frequentes e cenários de solução de problemas que os usuários podem encontrar ao trabalhar com o CX Cloud Agent.
A. Sim, para alguns cenários de implantação específicos, o redirecionamento para cloudfront.net é esperado. Oo acesso não associado deve ser permitido com o redirecionamento habilitado na porta 443 para esses FQDNs.
A. Sim
A. OVA e VHD
A. Para os ÓVULOS
Para VHD
R. Sim, a atribuição de endereço IP durante a configuração IP é detectada. No entanto, a alteração de endereço IP esperada para o CX Cloud Agent no futuro não é suportada. Recomenda-se que os clientes reservem o IP para o CX Cloud Agent em seu ambiente DHCP.
R. Não, somente o IPV4 é suportado.
R. Sim, a sintaxe do endereço IP e a atribuição de endereço IP duplicado são validadas.
R.A implantação do OVA depende da velocidade da rede que copia os dados. A configuração IP leva aproximadamente de 8 a 10 minutos, incluindo Kubernetes e criações de contêineres.
R. A máquina host na qual o OVA é implantado deve atender aos requisitos fornecidos como parte da configuração do portal do CX. O CX Cloud Agent é testado com a caixa VMware/Virtual em execução em um hardware com processadores Intel Xeon E5 com a proporção de vCPU/CPU definida como 2:1. Se for usada uma CPU de processador menos potente ou uma proporção maior, o desempenho poderá ser prejudicado.
R. Não, o código de emparelhamento só pode ser gerado quando o CX Cloud Agent não está registrado.
R.A largura de banda não é uma restrição quando o CX Cloud Agent e o Cisco DNA Center estão na mesma rede LAN/WAN no ambiente do cliente. A largura de banda de rede mínima necessária é de 2,7 Mbit/s para coletas de inventário de 5.000 dispositivos +13000 pontos de acesso para uma conexão de agente com o Cisco DNA Center. Se syslogs forem coletados para insights de Nível 2, a largura de banda mínima necessária será de 3,5 Mbits/s para coberturas de 5.000 dispositivos +13000 Pontos de acesso para inventário, 5.000 dispositivos syslogs e 2.000 dispositivos para varreduras - todos executados em paralelo do CX Cloud Agent.
R. Os Syslogs para a VM do agente podem ser acessados a partir do login da VM local usando os dois caminhos a seguir:
/var/log/syslog.1 (acessado via logons cxcadmin e cxcroot)
/var/log/syslog (acessado usando a raiz)
R. Aqui é mostrado o conjunto das versões lançadas do CX Cloud Agent que estão listadas:
em que A é uma versão de longo prazo distribuída por 3-5 anos.
R. Faça login no portal CX Cloud. Navegue até Configurações do administrador > Fontes de dados. Clique em View Update e siga as instruções na tela.
A. cxcadmin
R. As senhas são definidas durante a configuração da rede.
R. Nenhuma opção específica é fornecida pelo CX Cloud Agent para redefinir a senha, mas você pode usar os comandos do Linux para redefinir a senha para cxcadmin.
R. As políticas de senha são:
R. Para confirmar a alcançabilidade SSH:
Iptables -A OUTPUT -p tcp -m tcp —dport 22 -j ACCEPT
Para desativar as portas SSH ativadas acima no CX Cloud Agent:
iptables -L OUTPUT —line-number | grep dpt | grep ssh | awk '{print $1}'
iptables -L OUTPUT <Número da linha>
R. Para confirmar a acessibilidade do SNMP:
iptables -A OUTPUT -p udp -m udp —dport 161 -j ACCEPT
iptables -A OUTPUT -p udp -m udp —dport 161 -j ACCEPT
snmpwalk -v2c -c IPADDRESS cisco
Para desativar as portas SNMP ativadas acima no CX Cloud Agent:
iptables -L OUTPUT —line-number | grep dpt | grep ssh | awk '{print $1}'
iptables -L OUTPUT <Número da linha2 Número>
iptables -L OUTPUT <Número da linha1 Número>
R. Para definir a senha do Grub:
R. A senha expira em 90 dias.
R. Sim, a conta é desativada após cinco (5) tentativas consecutivas malsucedidas. O período de bloqueio é de 30 minutos.
R. Para gerar uma senha:
R. Sim, mas para usar o nome de host, o usuário deve fornecer o IP do Servidor de Nomes de Domínio (DNS) durante a configuração da rede.
R. São suportadas as seguintes cifras:
A. Para fazer login:
R. Sim, eles são registrados como parte do arquivo "var/logs/audit/audit.log".
R. O tempo limite da sessão SSH ocorre se o CX Cloud Agent estiver ocioso por cinco (5) minutos.
R. As seguintes portas estão disponíveis:
AMÉRICAS |
EMEA (Europa, Oriente Médio e África) |
APJC |
cloudsso.cisco.com |
cloudsso.cisco.com |
cloudsso.cisco.com |
api-cx.cisco.com |
api-cx.cisco.com |
api-cx.cisco.com |
agent.us.csco.cloud |
agent.emea.cisco.cloud |
agent.apjc.cisco.cloud |
ng.acs.agent.us.csco.cloud |
ng.acs.agent.emea.cisco.cloud |
ng.acs.agent.apjc.cisco.cloud |
Observação: além dos domínios listados, quando os clientes da EMEA ou da APJC reinstalarem o CX Cloud Agent, o domínio agent.us.csco.cloud deverá ser permitido no firewall do cliente.
O domínio agent.us.csco.cloud não é mais necessário após uma reinstalação bem-sucedida.
Observação: certifique-se de que o tráfego de retorno deve ser permitido na porta 443.
Inbound port
: Para o gerenciamento local do CX Cloud Agent, o 514(Syslog) e o 22 (ssh) devem estar acessíveis. Os clientes devem permitir que a porta 443 em seu firewall receba dados do CX Cloud.R. O Cisco DNA Center é o agente de nuvem que gerencia os dispositivos de rede nas instalações do cliente. O CX Cloud Agent coleta informações de inventário de dispositivos do Cisco DNA Center configurado e carrega as informações de inventário disponíveis na Visualização de ativos do CX Cloud.
R. Durante o dia 0 - configuração do CX Cloud Agent, os usuários podem adicionar os detalhes do Cisco DNA Center no portal CX Cloud. Durante as operações do Dia N, os usuários podem adicionar outros Cisco DNA Centers a partir de Admin Settings > Data Source
.
R. É possível adicionar dez (10) clusters do Cisco DNA Center ou 20 clusters não-clusters do Cisco DNA Center.
R. Para remover um Cisco DNA Center conectado do CX Cloud Agent, entre em contato com o Technical Assistance Center (TAC) para abrir um caso de suporte no portal CX Cloud.
R. A função de usuário pode ser admin ou observer.
R. Execute o comando cxcli agent modifyController no console do CX Cloud Agent:
Entre em contato com o suporte em caso de problemas durante a atualização de credenciais do Cisco DNA Center.
R. Todos os dados, incluindo credenciais de controladores conectados ao CX Cloud Agent (por exemplo, Cisco DNA Center) e ativos diretamente conectados (por exemplo, via arquivo semente, intervalo de IP), são criptografados usando AES-256 e armazenados no banco de dados do CX Cloud Agent, que é protegido com uma ID de usuário e senha seguras.
R. O HTTPS sobre TLS 1.2 é usado para a comunicação entre o Cisco DNA Center e o CX Cloud Agent.
R. O CX Cloud Agent coleta dados do Cisco DNA Center sobre dispositivos de rede e usa a interface de execução de comandos do Cisco DNA Center para conversar com dispositivos finais e executar comandos CLI (comando show). Os comandos de alteração de configuração não são executados.
A.
R. Consulte este documento para obter mais informações.
R. O CX Cloud Agent carrega os dados de inventário através do protocolo TLS 1.2 para o servidor back-end da Cisco.
R. A coleta é acionada conforme a programação definida pelo usuário e é carregada no back-end da Cisco.
R. Sim, há uma opção disponível em Configurações do administrador > Fontes de dados para modificar as informações de agendamento.
R. Os intervalos são categorizados da seguinte forma:
R. Os comandos que precisam ser executados no dispositivo para a verificação são determinados dinamicamente durante o processo de verificação. O conjunto de comandos pode mudar ao longo do tempo, mesmo para o mesmo dispositivo (e não no controle de Diagnostic Scan).
R. Os resultados verificados são armazenados e perfilados no back-end da Cisco.
R. Não, as duplicatas são filtradas de forma que apenas os dispositivos exclusivos sejam extraídos.
R. A varredura do dispositivo é interrompida completamente e marcada como malsucedida.
R. Registros de aplicativos, status do Pod, detalhes do Cisco DNA Center, registros de auditoria, detalhes do sistema e detalhes do hardware.
A. Exemplo de saída:
system_details":{
"os_details":{
"VersãoTempoExecuçãoContêiner":"docker://19.3.12",
"kernelVersion":"5.4.0-47-generic",
"kubeProxyVersion":"v1.15.12",
"kubeletVersion":"v1.15.12",
"machineID":"81edd7df1c1145e7bcc1ab4fe778615f",
"sistema operacional":"linux",
"osImage":"Ubuntu 20.04.1 LTS",
"UUID do sistema":"42002151-4131-2ad8-4443-8682911bdadb"
},
"detalhes_do_hardware":{
"total_cpu":"8",
"utilização da cpu":"12,5%",
"memória_total":"16007 MB",
"memória_livre":"994 MB",
"hdd_size":"214G",
"tamanho_hdd_livre":"202G"
}
}
}
R. Com o CX Cloud Agent, o serviço de saúde (manutenção) transmite os dados para o back-end da Cisco.
R. A política de retenção do registro de dados de integridade do CX Cloud Agent no back-end é de 120 dias.
A.
Problema: Não é possível acessar o IP configurado.
Solução: execute ssh usando o IP configurado. Se o tempo limite da conexão for excedido, o possível motivo será a configuração incorreta do IP. Nesse caso, reinstale configurando um IP válido. Isso pode ser feito por meio do portal com a opção de reinstalação fornecida no Admin Settings
Problema: Como verifico se os serviços estão funcionando após o registro?
Solução: siga as etapas abaixo para confirmar se os pods estão em execução:
Os pods podem estar em qualquer estado (Executando, Inicializando ou Criando contêiner). Após 20 minutos, os pods devem estar no estado Em execução.
Se o estado não estiver em execução ou se Pod Inicializando, verifique a descrição do pod com o comando kubectl describe pod <podname> .
A saída terá informações sobre o status do pod.
Problema: Como verificar se o Interceptor SSL está desabilitado no Proxy do cliente?
Solução: execute o comando curl mostrado aqui para verificar a seção de certificado do servidor. A resposta tem os detalhes do certificado do servidor consoweb.
curl -v —header 'Authorization: Basic xxxxxx' https://concsoweb-prd.cisco.com/
* Certificado do servidor:
* assunto: C=US; ST=Califórnia; L=San Jose; O=Cisco Systems, Inc.; CN=concsoweb-prd.cisco.com
* data de início: 16 de fevereiro 11:55:11 2021 GMT
* data de expiração: Feb 16 12:05:00 2022 GMT
* subjectAltName: o host "concsoweb-prd.cisco.com" corresponde ao "concsoweb-prd.cisco.com" do cert
* emitente: C=US; O=HydrantID (Avalanche Cloud Corporation); CN=HydrantID SSL CA G3
* Verificação de certificado SSL ok.
> GET / HTTP/1.1
Problema: os comandos kubectl falharam e mostram o erro como "A conexão ao servidor X.X.X.X:6443 foi recusada - você especificou o host ou a porta correta"
Solução:
Problema: Como obter os detalhes da falha de coleta para um comando/dispositivo?
Solução:
kubectl get pods
e obtenha o nome do pod de coleta.kubectl logs
para obter os detalhes específicos do comando/dispositivo.Problema: o comando kubectl não está funcionando com o erro "[authentication.go:64] Não foi possível autenticar a solicitação devido a um erro: [x509: o certificado expirou ou ainda não é válido, x509: o certificado expirou ou ainda não é válido]"
Solução:execute os comandos mostrados aqui como cxcroot user
rm /var/lib/rancher/k3s/server/tls/dynamic-cert.json
systemctl restart k3s
kubectl — insecure- skip- tls- verify=true delete secret - n kube- system k3s- servindo
systemctl restart k3s
A causa da falha de coleta pode ser qualquer restrição ou problema observado no controlador adicionado ou nos dispositivos presentes no controlador.
A tabela mostrada aqui tem o trecho de erro para casos de uso vistos no microsserviço de Coleta durante o processo de coleta.
Caso de uso |
Snippet de registro no microsserviço de coleta |
Se o dispositivo solicitado não for encontrado no Cisco DNA Center |
{ |
Se o dispositivo solicitado não estiver acessível no Cisco DNA Center |
{ |
Se o dispositivo solicitado não estiver acessível no Cisco DNA Center |
{ |
Se o comando solicitado não estiver disponível no dispositivo |
{ |
Se o dispositivo solicitado não tiver SSHv2 e o Cisco DNA Center tentar conectar o dispositivo com SSHv2 |
{ |
Se o comando estiver desativado no microsserviço de coleta |
{ |
Se a tarefa do executor de comandos falhou e o URL da tarefa não foi retornado pelo Cisco DNA Center |
{ |
Se a tarefa do executor de comandos não foi criada no Cisco DNA Center |
{ |
Se o microsserviço de coleta não estiver recebendo uma resposta para uma solicitação do executor de comandos do Cisco DNA Center |
{ |
Se o Cisco DNA Center não conclui a tarefa no tempo limite configurado (5 minutos por comando no microsserviço de coleta) |
{ |
Se a tarefa do executor de comandos falhou e o ID do arquivo está vazio para a tarefa enviada pelo Cisco DNA Center |
{ |
Se a tarefa do executor de comandos falhou e a marca da ID do arquivo não for retornada pelo Cisco DNA Center |
{ |
Se o dispositivo não estiver qualificado para a ação do executor de comandos |
{ |
Se o executor de comandos está desativado para o usuário |
{ |
Falhas de verificação e as causas podem ser de qualquer um dos componentes listados.
Quando os usuários iniciam uma verificação no portal, ocasionalmente ela resulta em "falha: erro interno do servidor".
A causa do problema é um dos componentes listados
Para ver os logs:
kubectl get pods
.kubectl logs
kubectl logs
kubectl logs
A tabela abaixo exibe o snippet de erro visto nos logs de microsserviço de coleção e microsserviço de manutenção que ocorrem devido aos problemas/restrições com os componentes.
Caso de uso |
Snippet de registro no microsserviço de coleta |
O dispositivo pode ser acessado e suportado, mas os comandos a serem executados nesse dispositivo estão listados em bloco no microsserviço de coleta |
{ |
Se o dispositivo para uma varredura não estiver disponível. Ocorre em um cenário, quando há um problema de sincronização entre os componentes, como portal, verificação de diagnóstico, componente CX e o Cisco DNA Center |
Nenhum dispositivo encontrado com a id 02eb08be-b13f-4d25-9d63-eaf4e882f71a |
Se o dispositivo em que você tentou fazer a verificação estiver ocupado, (em um cenário) em que o mesmo dispositivo fez parte de outro trabalho e nenhuma solicitação paralela será resolvida no Cisco DNA Center para o dispositivo |
Todos os dispositivos solicitados já estão sendo consultados pela execução do comando em outra sessão. Tente outros dispositivos |
Se o dispositivo não for compatível para verificação |
Os dispositivos solicitados não estão no inventário, tente com outros dispositivos disponíveis no inventário |
Se o dispositivo que tentou fazer a varredura estiver inacessível |
"Erro ao executar o comando: show udi\nErro ao conectar ao dispositivo [Host: x.x.x.x:22] Nenhuma rota para o host: Nenhuma rota para o host |
Se o Cisco DNA Center não estiver acessível no Cloud Agent ou se o microsserviço de coleta do Cloud Agent não recebe a resposta de uma solicitação do executor de comandos do Cisco DNA Center |
{ |
Caso de uso |
Snippet de registro no microsserviço do agente de ponto de controle |
Se os detalhes do agendamento da solicitação de verificação estiverem ausentes |
Não foi possível executar a solicitação. |
Se os detalhes do dispositivo da solicitação de verificação estiverem ausentes |
Falha ao criar política de verificação. Não há dispositivos válidos na solicitação |
Se a conexão entre o CPA e a conectividade estiver inativa |
Não foi possível executar a solicitação. |
Se o dispositivo solicitado para verificação não estiver disponível em Verificações de diagnóstico |
Falha ao enviar a solicitação para verificação. Motivo = {\"message\":\"O dispositivo com nome de host=x.x.x.x' não foi encontrado\"} |
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
31-Oct-2022 |
Versão inicial |