Solucionar problemas de intercluster de IM&P causados por erros de configuração de DNS

Introduction

Este documento descreve um cenário em que o erro "Não alcançável (Verifique se o endereço de peer é válido, se o AXL está sendo executado no peer e se as credenciais de nome de usuário/senha do AXL são válidas)" é recebido para o Teste de Conectividade de Peer no Servidor de Mensagens Instantâneas e Presença (IM&P) da Cisco em um cenário de peer intercluster.

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Serviço Cisco IM e Presence
• recurso de peering intercluster 

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

A imagem a seguir mostra o erro encontrado no Cisco Unified CM IM and Presence Administration > Presence > Inter-Clustering:

• O nome de usuário e a senha do AXL são válidos.
• O Cisco AXL Web Service está sendo executado no peer.
• Este erro entre clusters é causado por problemas com a configuração do DNS (Domain Name System); no entanto, os rastreamentos IM&P podem induzir em erro a triagem inicial, pois parecem indicar um possível atraso introduzido pela rede. A coleta simultânea de captura de pacotes de ambos os peers mostraria que não há nenhum atraso na rede.

Note: Geralmente, esse é um problema unidirecional, o que significa que o Cluster A do IM&P pode se comunicar com êxito com o Cluster B do IM&P, mas o Cluster B do IM&P lança o erro Não alcançável quando tenta se comunicar com o Cluster A do IM&P.

Troubleshoot

Etapa 1. Verifique se os nomes de usuário AXL, as senhas AXL e os endereços de mesmo nível estão corretos. Neste cenário, a conectividade não é um problema e os peers devem ser capazes de se comunicar de ambas as maneiras (eles não devem apenas ser acessíveis por ping, mas também por meio das portas AXL correspondentes: 8443).

Etapa 2. Colete pelo menos estes conjuntos de logs dos Clusters A e B do IM&P:

•  Serviço Web Cisco AXL
•  Agente de Sincronização Cisco Intercluster

Caution: Alguns rastreamentos de serviço precisam ser definidos como nível de depuração antes da execução do teste. Defina o nível de rastreamento para seu estado padrão depois que os testes forem executados para evitar qualquer impacto adicional no desempenho dos servidores.

Note: É importante coletar os logs dos dois clusters envolvidos.

O caminho para habilitar o nível de depuração para cada serviço é:

• Cisco Unified IM and Presence Serviceability > Rastrear > Configuração > Selecionar Servidor IM&P e clicar em Ir > Selecionar Serviços de Banco de Dados e Administração e clicar em Ir > Selecionar Cisco AXL Web Service e clicar em Ir
• Cisco Unified IM and Presence Serviceability > Rastrear > Configuração > Selecionar Servidor IM&P e clicar em Ir > Selecionar Serviços IM e Presence e clicar em Ir > Selecionar Cisco Intercluster Agent e clicar em Ir

Etapa 3. A análise de log mostra este fluxo de mensagens:

Nos logs do Agente de Sincronização Entre Clusters no Cluster B (o cluster que mostra o erro Não alcançável), você precisa identificar a solicitação AXL e a hora exata em que essa solicitação foi enviada. Parece com algo assim:

2019-07-14 06:00:07,842 DEBUG [Peer: node name in Cluster A] axl.AXLClientLogger - runSoapReq: The axl request is : 
     
     
     
      
       
       
        
        
          SELECT count(*) from processnode WHERE systemnode='f' and tknodeusage= 0 
         
        
       
     

Os mesmos logs do Agente de Sincronização Intercluster no Cluster B mostram que a resposta é recebida até dois minutos mais tarde, o que causa um timeout para a transação:

019-07-14 06:02:36,176 DEBUG [AXL Runner for parent thread ID:4741 (Peer: node name in Cluster A] axl.AXLClientLogger - AXLClientBase - sendSOAPRequest received : 
     
     
     
      
       
        
         
          
          
            2 
           
          
         
        
       
     
"node name in Cluster A" received AXL request at "2019-07-14 01:02:36"

Isso pode fazer com que você suspeite que há algum tipo de atraso de pacote na rede. No entanto, o próprio corpo da resposta indica que o peer no Cluster A recebeu uma solicitação AXL dois minutos depois (você precisará efetuar a conversão de fuso horário se os clusters estiverem localizados em fusos horários diferentes).

Se você procurar nos logs do AXL Web Service no Cluster A, poderá descobrir que a solicitação é processada em questão de milissegundos:

2019-07-14 01:02:36,110 INFO  [http-bio-443-exec-742] servletRouters.AXLFilter - AXL REQUEST : 

     
      
       
       
        
        
          SELECT count(*) from processnode WHERE systemnode='f' and tknodeusage= 0 
         
        
       
     
"node name in Cluster A" sent response at "2019-07-14 01:02:36"

2019-07-14 01:02:36,131 DEBUG [http-bio-443-exec-742] servletRouters.AXLFilter - Final response String  : 
     
     
     
      
       
        
         
          
          
            2 
           
          
         
        
       
     

As capturas simultâneas de pacotes de ambos os peers demonstram o mesmo: o atraso real não está dentro da própria rede, mas o problema é que o Cluster B atrasa o pacote antes que ele seja enviado para o Cluster A. O Cluster A processa a solicitação e responde a ela em alguns milissegundos, como esperado.

A investigação do motivo pelo qual o cluster B atrasa a solicitação AXL ou qual é a causa exata desse problema pode ser muito demorada. No entanto, há algumas validações que foram identificadas como etapas básicas de diagnóstico para esse cenário.

Solução

Houve vários casos em que esse atraso no Cluster B do IM&P é causado por um problema com o DNS. Você pode enfrentar um destes dois cenários:

Cenário 1:

No Cluster B, o servidor DNS primário não está acessível. Embora o servidor DNS secundário seja acessível, o nó sofreu um atraso significativo ao tentar resolver todos os FQDNs necessários por meio do servidor DNS primário. Quando ele muda para o servidor DNS secundário, já há um atraso de 2 minutos e, portanto, a solicitação expira.

A maneira como você pode validar isso é por meio desses comandos da Interface de Linha de Comando (CLI) :

Emita o comando show network eth0 para listar os servidores DNS que o nó IM&P está configurado para usar:

admin:show network eth0
Ethernet 0
DHCP         : disabled           Status     : up
IP Address   : 10.0.10.10         IP Mask    : 255.255.255.000
Link Detected: yes                Mode       : Auto disabled, Full, 10000 Mbits/s
Duplicate IP : no

DNS
Primary      : 10.0.10.31         Secondary  : 10.0.10.32

Em seguida, tente fazer ping no servidor DNS primário através do comando utils network ping <Primary DNS server's IP Address> :

admin:utils network ping 10.0.10.31
PING 10.0.10.31 (10.0.10.31) 56(84) bytes of data.
From 10.0.10.10 icmp_seq=2 Destination Host Unreachable
From 10.0.10.10 icmp_seq=3 Destination Host Unreachable
From 10.0.10.10 icmp_seq=4 Destination Host Unreachable

Se o servidor DNS primário não estiver acessível, verifique se o endereço IP configurado para ele está correto. Em seguida, corrija todos os problemas de conectividade. Depois que você conseguir fazer ping nos servidores DNS primário e secundário sem problemas, o erro entre clusters também deverá ser corrigido. Caso o problema persista após essas ações, siga as etapas do Cenário 2.

Cenário 2:

No Cluster B, os servidores DNS primário e secundário podem ser acessados/submetidos a ping, mas o servidor IM&P ainda mostra um aviso de DNS inacessível na CLI e na página da Web:

Command Line Interface is starting up, please wait ...

   Welcome to the Platform Command Line Interface

VMware Installation:
        128 vCPU: Intel(R) Xeon(R) CPU E5-2699A v4 @ 2.40GHz
        Disk 1: 80GB, Partitions aligned
        4096 Mbytes RAM
        WARNING: DNS unreachable

Além disso, o comando CLI utils diagnose test mostra um problema com a resolução DNS, especificamente dentro do módulo validate_network, que pode indicar um erro como Reverse DNS lookup failed:

admin:utils diagnose test
Log file: platform/log/diag4.log

Starting diagnostic test(s)
===========================
test - disk_space          : Passed (available: 6938 MB, used: 11852 MB)
skip - disk_files          : This module must be run directly and off hours
test - service_manager     : Passed
test - tomcat              : Passed
test - tomcat_deadlocks    : Passed
test - tomcat_keystore     : Passed
test - tomcat_connectors   : Passed
test - tomcat_threads      : Passed
test - tomcat_memory       : Passed
test - tomcat_sessions     : Passed
skip - tomcat_heapdump     : This module must be run directly and off hours
test - validate_network    : Reverse DNS lookup failed
test - raid                : Passed

Esse erro específico indica um problema com o servidor DNS, que não pode resolver alguns endereços IP para nomes de domínio totalmente qualificados (FQDNs). Você pode isolar ainda mais esse problema por meio do comando CLI show network cluster. Esse comando exibe a lista de entradas (Todos os servidores CUCM e IM&P) que fazem parte desse cluster:

admin:show network cluster
10.3.74.13 IMPPUB.edgrodrilab.com IMPPUB Subscriber cups DBPub authenticated
10.3.74.14 IMPSUB.edgrodrilab.com IMPSUB Subscriber cups DBSub authenticated using TCP since Fri Oct 15 10:22:20 2021
10.3.74.12 CUCMSUB.edgrodrilab.com CUCMSUB Subscriber callmanager DBSub authenticated using TCP since Thu Oct 28 11:24:16 2021
10.3.74.11 CUCMPUB.edgrodrilab.com CUCMPUB Publisher callmanager DBPub authenticated using TCP since Thu Oct 28 11:27:36 2021

Você deve ser capaz de encaminhar e reverter a pesquisa de DNS em todas essas entradas.

Exemplo de uma resolução DNS em funcionamento:

admin:utils network host IMPPUB
Local Resolution:
IMPPUB.edgrodrilab.com resolves locally to 10.0.10.10

External Resolution:
IMPPUB.edgrodrilab.com has address 10.0.10.10

admin:utils network host 10.0.10.10
Local Resolution:
10.0.10.10 resolves locally to IMPPUB.edgrodrilab.com

External Resolution:
10.10.0.10.in-addr.arpa domain name pointer imppub.edgrodrilab.com.

Exemplo de uma resolução DNS não funcional:

admin:utils network host IMPSUB
Local Resolution:
IMPSUB.edgrodrilab.com resolves locally to 10.0.10.10

External Resolution:
IMPSUB.edgrodrilab.com has address 10.0.10.10

admin:utils network host 10.0.10.10
Local Resolution:
10.0.10.10 resolves locally to IMPSUB.edgrodrilab.com

External Resolution:
No external servers found

Nesse caso específico, o servidor DNS não contém o registro PTR para resolver do endereço IP 10.0.10.10 para o FQDN IMPSUB.edgrodrilab.com.

Para corrigir o aviso de DNS inalcançável e o erro Reverse DNS lookup failed, você precisa criar os registros A Host e PTR necessários no servidor DNS para poder resolver todos os nós CUCM e IM&P para pesquisa de DNS direta e reversa.

Verificar

Quando ocorre exatamente o mesmo problema entre clusters e a assinatura de erro corresponde aos logs, uma das configurações básicas a serem verificadas é o status e a configuração do servidor DNS.

Os servidores DNS primário e secundário precisam estar acessíveis/com acesso a ping e ser capazes de resolver todos os nós CUCM e IM&P dentro do cluster para pesquisa de DNS reverso e de encaminhamento.

Você precisa limpar todos os avisos, erros ou alertas de DNS antes de solucionar os erros entre clusters. Você pode usar o comando utils diagnose test para validar a configuração DNS.