Risoluzione dei problemi di clustering di IM&P causati da una configurazione errata di DNS

Introduzione

In questo documento viene descritto uno scenario in cui viene visualizzato l'errore "Non raggiungibile (verificare che l'indirizzo del peer sia valido, che AXL sia in esecuzione sul peer e che le credenziali di nome utente e password AXL siano valide)" per il test di connettività peer all'interno del server Cisco Instant Messaging and Presence (IM&P) in uno scenario peer intercluster.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Cisco IM and Presence Service
• Funzionalità peer intercluster 

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

L'immagine seguente mostra l'errore rilevato in Cisco Unified CM IM e Presence Administration > Presence > Inter-Clustering:

• Il nome utente AXL (Administrative XML Web Service) e la password AXL sono validi.
• Il servizio Web Cisco AXL è in esecuzione sul peer.
• Questo errore tra cluster è causato da problemi nella configurazione del DNS (Domain Name System). tuttavia, le tracce di IM&P possono fuorviare la selezione iniziale, in quanto sembrano indicare un possibile ritardo introdotto dalla rete. La raccolta simultanea dell'acquisizione dei pacchetti da entrambi i peer mostrerebbe che non c'è alcun ritardo nella rete.

Nota: In genere si tratta di un problema unidirezionale, ovvero il cluster IM&P A è in grado di comunicare con il cluster IM&P B, ma il cluster IM&P B genera l'errore Non raggiungibile quando tenta di comunicare con il cluster IM&P A.

Risoluzione dei problemi

Passaggio 1. Verificare che i nomi utente AXL, le password AXL e gli indirizzi peer siano corretti. In questo scenario, la connettività non è un problema e i peer devono essere in grado di comunicare in entrambi i modi (non devono solo essere raggiungibili tramite ping, ma anche tramite le porte AXL corrispondenti: 8443).

Passaggio 2. Raccogliere almeno questi set di log dal cluster IM&P A e B:

•  Servizio Web Cisco AXL
•  Cisco Intercluster Sync Agent

Attenzione: Prima di eseguire il test, è necessario impostare alcune tracce del servizio sul livello di debug. Impostare il livello di traccia sullo stato predefinito dopo l'esecuzione dei test per evitare ulteriori ripercussioni sulle prestazioni dei server.

Nota: È importante raccogliere i registri da entrambi i cluster coinvolti.

Il percorso per abilitare il livello di debug per ogni servizio è:

• Cisco Unified IM and Presence Serviceability > Trace > Configuration > Select IM&P Server e fare clic su Go > Select Database and Admin Services e fare clic su Go > Select Cisco AXL Web Service e fare clic su Go
• Cisco Unified IM and Presence Serviceability > Trace > Configuration > Select IM&P Server e fare clic su Go > Select IM and Presence Services e fare clic su Go > Select Cisco Intercluster Sync Agent e fare clic su Go

Passaggio 3. L'analisi del log mostra questo flusso di messaggi:

Dai log dell'agente di sincronizzazione tra cluster nel cluster B (il cluster che mostra l'errore Non raggiungibile), è necessario identificare la richiesta AXL e l'ora esatta in cui è stata inviata. Ha il seguente aspetto:

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 
         
        
       
     

Gli stessi log dell'agente di sincronizzazione intercluster nel cluster B mostrano che la risposta viene ricevuta fino a due minuti dopo, causando un timeout per la transazione:

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"

Ciò potrebbe indurre a sospettare che ci sia una sorta di ritardo dei pacchetti all'interno della rete. Tuttavia, il corpo della risposta indica che il peer nel cluster A ha ricevuto una richiesta AXL due minuti dopo (è necessario eseguire la conversione del fuso orario se i cluster si trovano in fusi orari diversi).

Se si esaminano i registri del servizio Web AXL nel cluster A, è possibile verificare che la richiesta venga elaborata in pochi millisecondi:

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 
           
          
         
        
       
     

Le acquisizioni simultanee di pacchetti da entrambi i peer dimostrano lo stesso: il ritardo effettivo non è all'interno della rete stessa, ma il problema è che il cluster B ritarda il pacchetto prima che venga inviato al cluster A. Il cluster A elabora la richiesta e risponde alla richiesta in pochi millisecondi, come previsto.

L'analisi del motivo per cui il cluster B ritarda la richiesta AXL o della causa esatta di questo problema potrebbe richiedere molto tempo. Tuttavia, esistono un paio di convalide che sono state identificate come fasi diagnostiche di base per questo scenario.

Soluzione alternativa

In più casi questo ritardo all'interno del cluster B di IM&P è stato causato da un problema con il DNS. È possibile che si verifichi uno di questi due scenari:

Scenario 1:

Nel cluster B il server DNS primario non è raggiungibile. Sebbene il server DNS secondario sia raggiungibile, il nodo ha impiegato un ritardo significativo nel tentativo di risolvere tutti i nomi di dominio completi richiesti tramite il server DNS primario. Quando si passa al server DNS secondario, è già presente un ritardo di 2 minuti e, di conseguenza, la richiesta scade.

Per convalidare questa condizione, usare i seguenti comandi dell'interfaccia della riga di comando (CLI):

Eseguire il comando show network eth0 per visualizzare un elenco dei server DNS per i quali il nodo IM&P è configurato:

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

Quindi, provare a eseguire il ping del server DNS primario tramite il comando ping <Indirizzo IP server DNS primario> della rete utils:

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 il server DNS primario non è raggiungibile, verificare che l'indirizzo IP configurato per il server sia corretto. Risolvere quindi tutti i problemi di connettività. Se è possibile eseguire il ping dei server DNS primario e secondario senza problemi, è necessario correggere anche l'errore Inter-Clustering. Se il problema persiste dopo queste azioni, eseguire i passaggi dello scenario 2.

Scenario 2:

Nel cluster B, sia il server DNS primario che quello secondario sono raggiungibili/eseguibili tramite ping, ma nel server IM&P viene ancora visualizzato un avviso DNS non raggiungibile nella CLI e nella pagina 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

Inoltre, il comando CLI utilizza il test Diagnose per visualizzare un problema relativo alla risoluzione DNS, in particolare all'interno del modulo validate_network, che potrebbe indicare un errore quale la ricerca DNS inversa non riuscita:

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

Questo errore indica un problema del server DNS, che non è in grado di risolvere alcuni indirizzi IP in nomi di dominio completi (FQDN). Per isolare ulteriormente il problema, usare il comando show network cluster della CLI. Con questo comando viene visualizzato l'elenco delle voci (tutti i server CUCM e IM&P) che fanno parte del 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

È necessario essere in grado di eseguire ricerche DNS dirette e inverse in tutte queste voci.

Esempio di risoluzione DNS funzionante:

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.

Esempio di risoluzione DNS non funzionante:

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

In questo caso specifico, il server DNS non contiene il record PTR da risolvere dall'indirizzo IP 10.0.10.10 all'FQDN IMPSUB.edgrodrilab.com.

Per correggere l'avviso DNS irraggiungibile e l'errore Ricerca DNS inversa non riuscita, è necessario creare i record A Host e PTR necessari nel server DNS per poter risolvere tutti i nodi CUCM e IM&P per la ricerca DNS sia diretta che inversa.

Verifica

Se si verifica esattamente lo stesso problema di interclustering e la firma dell'errore corrisponde ai registri, una delle impostazioni di base da verificare è lo stato e la configurazione del server DNS.

I server DNS primario e secondario devono essere entrambi raggiungibili/eseguibili tramite ping e in grado di risolvere tutti i nodi CUCM e IM&P all'interno del cluster per la ricerca DNS diretta e inversa.

È necessario cancellare tutti gli avvisi, gli errori o gli avvisi DNS prima di risolvere gli errori tra cluster. È possibile utilizzare il comando utils diagnostse test per convalidare la configurazione DNS.