Dépannage des problèmes de mise en grappe inter-IM&P causés par une mauvaise configuration DNS

Introduction

Ce document décrit un scénario dans lequel l'erreur « Not reachable (Check peer address is valid, AXL is running on peer and AXL username/password credentials are valid) » est reçue pour le test de connectivité homologue au sein du serveur Cisco Instant Messaging and Presence (IM&P) dans un scénario d'homologue intercluster.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Service de messagerie instantanée et de présence Cisco
• Fonction d’appairage intercluster 

Components Used

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

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 votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

L'image suivante montre l'erreur trouvée dans Cisco Unified CM IM and Presence Administration > Presence > Inter-Clustering :

• Le nom d'utilisateur et le mot de passe du service Web XML d'administration (AXL) sont valides.
• Le service Web Cisco AXL s'exécute sur l'homologue.
• Cette erreur Inter-Clustering est due à des problèmes de configuration DNS (Domain Name System) ; cependant, les traces IM&P peuvent induire en erreur le triage initial, car elles semblent indiquer un éventuel retard introduit par le réseau. La collecte simultanée des paquets des deux homologues montrerait alors qu’il n’y a aucun retard dans le réseau.

Note: En général, il s'agit d'un problème à sens unique, ce qui signifie que le cluster A de GI&P est en mesure de communiquer avec le cluster B de GI&P, mais le cluster B de GI&P renvoie l'erreur Not reachable lorsqu'il tente de communiquer avec le cluster A de GI&P.

Dépannage

Étape 1 : vérification des noms d’utilisateur, mots de passe et adresses homologues AXL Dans ce scénario, la connectivité n'est pas un problème et les homologues doivent pouvoir communiquer des deux manières (ils doivent non seulement pouvoir recevoir des requêtes ping, mais également être accessibles via les ports AXL correspondants : 8443).

Étape 2. Collectez au moins ces ensembles de journaux à partir des clusters A et B de GI&P :

•  Service Web Cisco AXL
•  Agent Cisco Intercluster Sync

Attention : Certaines traces de service doivent être définies au niveau de débogage avant que le test ne soit effectué. Définissez le niveau de trace sur son état par défaut après l'exécution des tests pour éviter tout impact supplémentaire sur les performances des serveurs.

Note: Il est important de collecter les journaux des deux clusters concernés.

Le chemin pour activer le niveau de débogage pour chaque service est :

• Cisco Unified IM and Presence Serviceability > Trace > Configuration > Select IM&P Server and click Go > Select Database and Admin Services and click Go > Select Cisco AXL Web Service and click Go
• Cisco Unified IM and Presence Serviceability > Trace > Configuration > Select IM&P Server et cliquez sur Go > Select IM and Presence Services et cliquez sur Go > Select Cisco Intercluster Sync Agent et cliquez sur Go

Étape 3. L’analyse du journal affiche le flux de messages suivant :

À partir des journaux de l'agent de synchronisation intercluster dans le cluster B (le cluster qui affiche l'erreur Not reachable), vous devez identifier la demande AXL et l'heure exacte à laquelle cette demande a été envoyée. Il ressemble à ceci :

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 
         
        
       
     

Les mêmes journaux de l'agent de synchronisation intercluster dans le cluster B indiquent que la réponse est reçue deux minutes plus tard, ce qui entraîne un délai d'attente pour la transaction :

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"

Cela peut vous amener à penser qu’il existe une sorte de délai de transmission de paquets sur le réseau. Cependant, le corps de la réponse lui-même indique que l'homologue du cluster A a reçu une requête AXL deux minutes plus tard (vous devez effectuer la conversion de fuseau horaire si les clusters sont situés dans des fuseaux horaires différents).

Si vous examinez les journaux du service Web AXL dans le cluster A, vous pouvez constater que la demande est traitée en quelques millisecondes :

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 
           
          
         
        
       
     

Les captures de paquets simultanées des deux homologues montrent la même chose : le délai réel n'est pas dans le réseau lui-même, mais le problème est que le cluster B retarde le paquet avant qu'il ne soit envoyé au cluster A. Le cluster A traite la demande et y répond en quelques millisecondes, comme prévu.

L'enquête visant à déterminer pourquoi le cluster B retarde la demande AXL ou quelle est la cause exacte de ce problème peut prendre beaucoup de temps. Cependant, quelques validations ont été identifiées comme des étapes de diagnostic de base pour ce scénario.

Solution de contournement

Il y a eu plusieurs cas où ce retard dans le groupe B IM&P est causé par un problème avec le DNS. Vous pourriez être confronté à l'un de ces deux scénarios :

Scénario 1 :

Dans le cluster B, le serveur DNS principal n'est pas accessible. Bien que le serveur DNS secondaire soit accessible, le noeud a pris un délai important lorsqu'il a tenté de résoudre tous les noms de domaine complets requis via le serveur DNS principal. Au moment où il passe au serveur DNS secondaire, il y a déjà un délai de 2 minutes et, par conséquent, la requête expire.

Vous pouvez le valider à l'aide des commandes CLI (Command Line Interface) suivantes :

Exécutez la commande show network eth0 pour répertorier les serveurs DNS que le noeud IM&P est configuré pour utiliser :

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

Ensuite, essayez d'envoyer une requête ping au serveur DNS principal via la commande utils network ping <Adresse IP du serveur DNS principal> :

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 le serveur DNS principal n'est pas accessible, assurez-vous que l'adresse IP configurée pour ce serveur est correcte. Corrigez ensuite tous les problèmes de connectivité. Une fois que vous pouvez envoyer une requête ping aux serveurs DNS principal et secondaire sans problème, l'erreur Inter-Clustering doit également être corrigée. Si le problème persiste après ces actions, suivez les étapes du scénario 2.

Scénario 2 :

Dans le cluster B, les serveurs DNS principal et secondaire sont accessibles/peuvent envoyer des requêtes ping, mais le serveur IM&P affiche toujours un avertissement DNS inaccessible dans la CLI et la page 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

En outre, la commande CLI utils diagnostic test montre un problème avec la résolution DNS, en particulier dans le module validate_network, qui pourrait indiquer une erreur telle que l'échec de la recherche DNS inverse :

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

Cette erreur particulière indique un problème avec le serveur DNS, qui ne parvient pas à résoudre certaines adresses IP en noms de domaine complets (FQDN). Vous pouvez isoler davantage ce problème via la commande CLI show network cluster. Cette commande affiche la liste des entrées (Tous les serveurs CUCM et IM&P) qui font partie de ce 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

Vous devez pouvoir effectuer une recherche DNS directe et inversée sur toutes ces entrées.

Exemple de résolution DNS opérationnelle :

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.

Exemple de résolution DNS incorrecte :

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

Dans ce cas spécifique, le serveur DNS ne contient pas l'enregistrement PTR à convertir de l'adresse IP 10.0.10.10 en IMPSUB.edgrodrilab.com FQDN.

Pour corriger l'avertissement DNS inaccessible et l'erreur Échec de la recherche DNS inverse, vous devez créer les enregistrements A Host et PTR requis dans le serveur DNS afin de pouvoir résoudre tous les noeuds CUCM et IM&P pour la recherche DNS directe et inverse.

Vérification

Lorsque le même problème de mise en grappe inter-serveurs est rencontré et que la signature d'erreur correspond aux journaux, l'un des paramètres de base à vérifier est l'état et la configuration du serveur DNS.

Les serveurs DNS principal et secondaire doivent être accessibles/pingables et capables de résoudre tous les noeuds CUCM et IM&P dans le cluster pour la recherche DNS directe et inversée.

Vous devez effacer tous les avertissements, erreurs ou alertes DNS avant de dépanner les erreurs de clustering. Vous pouvez utiliser la commande utils diagnose test pour valider la configuration DNS.