Resolución de Problemas de IM&P Inter-Clustering Causados por la Mala Configuración de DNS

Introducción

Este documento describe un escenario donde se recibe el error "No alcanzable (Comprobar dirección de peer es válida, AXL se está ejecutando en peer y las credenciales de nombre de usuario/contraseña de AXL son válidas)" para la Prueba de conectividad de peer dentro del servidor de Mensajería Instantánea y Presencia de Cisco (IM&P) en un escenario de peer entre clústeres.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Servicio Cisco IM and Presence
• función de peering entre clústers 

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

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. Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

La siguiente imagen muestra el error encontrado en Administración de IM and Presence de Cisco Unified CM > Presencia > Interagrupación en clústeres:

• Tanto el nombre de usuario del servicio Web XML administrativo (AXL) como la contraseña de AXL son válidos.
• El servicio web Cisco AXL se está ejecutando en el par.
• Este error entre clústeres se debe a problemas con la configuración del Sistema de nombres de dominio (DNS); sin embargo, los seguimientos de IM&P pueden confundir el triaje inicial, ya que parecen indicar un posible retraso introducido por la red. La recopilación simultánea de captura de paquetes de ambos pares mostraría que no hay ningún retraso en la red.

Nota: Normalmente, se trata de un problema unidireccional, lo que significa que el clúster A de IM&P puede comunicarse correctamente con el clúster B de IM&P, pero el clúster B de IM&P arroja el error Not Reachable cuando intenta comunicarse con el clúster A de IM&P.

Troubleshoot

Paso 1. Verifique que los nombres de usuario, las contraseñas y las direcciones de pares de AXL sean correctos. En este escenario, la conectividad no es un problema y los peers deben poder comunicarse de ambas maneras (no solo deben ser localizables sino también alcanzables a través de los puertos AXL correspondientes: 8443).

Paso 2. Recopile al menos este conjunto de registros del clúster A y B de IM&P:

•  Servicio web Cisco AXL
•  Cisco Intercluster Sync Agent

Precaución: Algunos seguimientos de servicio deben configurarse en el nivel de depuración antes de realizar la prueba. Establezca el nivel de seguimiento en su estado predeterminado después de realizar las pruebas para evitar cualquier impacto adicional en el rendimiento de los servidores.

Nota: Es importante recopilar los registros de ambos clústeres implicados.

La ruta para habilitar el nivel de depuración para cada servicio es:

• Serviciabilidad de Cisco Unified IM and Presence > Seguimiento > Configuración > Seleccione el servidor de IM&P y haga clic en Ir > Seleccione la base de datos y los servicios de administración y haga clic en Ir > Seleccionar servicio web Cisco AXL y haga clic en Ir
• Serviciabilidad de Cisco Unified IM and Presence > Seguimiento > Configuración > Seleccione el servidor de IM&P y haga clic en Ir > Seleccione IM and Presence Services y haga clic en Ir > Seleccionar Cisco Intercluster Sync Agent y haga clic en Ir

Paso 3. El análisis del registro muestra este flujo de mensajes:

Desde los registros del Agente de sincronización de interclúster en el clúster B (el clúster que muestra el error Not Reachable), debe identificar la solicitud AXL y la hora exacta en la que se envió dicha solicitud. Se parece a esto:

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 
         
        
       
     

Los mismos registros del Agente de sincronización entre clústeres en el clúster B muestran que la respuesta se recibe hasta dos minutos después, lo que provoca un tiempo de espera para la transacción:

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"

Esto podría llevarlo a sospechar que hay algún tipo de retraso de paquetes dentro de la red. Sin embargo, el propio cuerpo de la respuesta indica que el par del Clúster A recibió una solicitud AXL dos minutos después (debe realizar la conversión de zona horaria si los clústeres están ubicados en diferentes zonas horarias).

Si busca en los registros del servicio web AXL en el clúster A, puede encontrar que la solicitud se procesa en cuestión de milisegundos:

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 
           
          
         
        
       
     

Las capturas simultáneas de paquetes de ambos pares demuestran lo mismo: la demora real no está dentro de la red misma, pero el problema es que el clúster B demora el paquete antes de enviarlo al clúster A. El clúster A procesa la solicitud y responde a ella en unos milisegundos, como se esperaba.

La investigación de por qué el clúster B retrasa la solicitud AXL o cuál es la causa exacta de este problema podría llevar mucho tiempo. Sin embargo, hay un par de validaciones que se han identificado como pasos de diagnóstico básicos para este escenario.

Solución Aternativa

Ha habido varios casos en los que este retraso dentro del Clúster B de IM&P es causado por un problema con el DNS. Puede enfrentarse a cualquiera de estos dos escenarios:

Escenario 1:

En el Clúster B, el servidor DNS primario no es accesible. Aunque el servidor DNS secundario es accesible, el nodo ha tardado bastante en resolver todos los FQDN necesarios a través del servidor DNS principal. Cuando cambia al servidor DNS secundario, ya hay un retraso de 2 minutos y, por lo tanto, la solicitud agota el tiempo de espera.

La forma de validarlo es a través de estos comandos de la interfaz de línea de comandos (CLI):

Ejecute el comando show network eth0 para enumerar los servidores DNS que el nodo IM&P está configurado para utilizar:

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

Luego, intente hacer ping al servidor DNS primario a través del 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

Si el servidor DNS primario no es accesible, asegúrese de que la dirección IP que fue configurada para él sea correcta. A continuación, solucione todos los problemas de conectividad. Una vez que pueda hacer ping a los servidores DNS primario y secundario sin problemas, también debe corregirse el error entre clústeres. En caso de que el problema persista después de estas acciones, siga los pasos de la situación 2.

Escenario 2:

En el Clúster B, los servidores DNS primario y secundario son accesibles/a los que se puede hacer ping, pero el servidor IM&P todavía muestra una advertencia de DNS inalcanzable en la CLI y la página 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

Además, el comando CLI utils diagnose test muestra un problema con la resolución de DNS, específicamente dentro del módulo validate_network, que podría indicar un error 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

Este error en particular indica un problema con el servidor DNS, que no puede resolver algunas direcciones IP en nombres de dominio completos (FQDN). Puede aislar aún más este problema a través del comando CLI show network cluster. Este comando muestra la lista de entradas (todos los servidores CUCM e IM&P) que forman parte de ese clúster:

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

Debe poder realizar búsquedas de DNS inversas y directas en todas esas entradas.

Ejemplo de una resolución DNS en funcionamiento:

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.

Ejemplo de una resolución DNS que no funciona:

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

En este caso específico, el servidor DNS no contiene el registro PTR para resolver la dirección IP 10.0.10.10 en el FQDN IMPSUB.edgrodrilab.com.

Para corregir la advertencia de DNS inalcanzable y el error Reverse DNS lookup failed, debe crear los registros A Host y PTR requeridos en el servidor DNS para poder resolver todos los nodos de CUCM e IM&P para la búsqueda de DNS directa e inversa.

Verificación

Cuando se experimenta exactamente el mismo problema entre clústeres y la firma de error coincide con los registros, una de las opciones básicas que se deben comprobar es el estado y la configuración del servidor DNS.

Los servidores DNS primario y secundario deben ser accesibles/sondeables y capaces de resolver todos los nodos CUCM e IM&P del clúster para la búsqueda de DNS directo e inverso.

Debe borrar todas las advertencias, errores o alertas de DNS antes de resolver los errores entre clústeres. Puede utilizar el comando utils diagnose test para validar la configuración de DNS.