Fehlerbehebung bei Problemen mit IM&P Inter-Clustering, die durch eine falsche DNS-Konfiguration verursacht werden

Einleitung

In diesem Dokument wird ein Szenario beschrieben, in dem für den Peer-Verbindungstest im Cisco Instant Messaging and Presence (IM&P)-Server in einem clusterübergreifenden Peer-Szenario der Fehler "Nicht erreichbar" (Peer-Adresse überprüfen ist gültig, AXL wird auf dem Peer ausgeführt, und die Anmeldeinformationen für AXL Benutzername/Kennwort sind gültig) empfangen wird.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Cisco IM und Presence-Service
• Intercluster-Peering-Funktion 

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle verstehen.

Hintergrundinformationen

Die nächste Abbildung zeigt den in Cisco Unified CM IM und Presence Administration > Presence > Inter-Clustering gefundenen Fehler:

• Der Benutzername und das Kennwort für den AXL-Webdienst sind gültig.
• Cisco AXL Web Service wird auf dem Peer ausgeführt.
• Dieser Inter-Clustering-Fehler wird durch Probleme mit der DNS-Konfiguration verursacht. Die IM&P-Ablaufverfolgungen können jedoch die erste Auswahl irreführen, da sie auf eine mögliche Verzögerung durch das Netzwerk hinweisen. Eine gleichzeitige Paketerfassung von beiden Peers würde dann zeigen, dass keinerlei Verzögerung im Netzwerk auftritt.

Anmerkung: In der Regel handelt es sich hierbei um ein unidirektionales Problem, d. h., dass der IM&P-Cluster A erfolgreich mit dem IM&P-Cluster B kommunizieren kann. Der IM&P-Cluster B löst jedoch den Fehler Nicht erreichbar aus, wenn er versucht, mit dem IM&P-Cluster A zu kommunizieren.

Fehlerbehebung

Schritt 1: Überprüfen der AXL-Benutzernamen, AXL-Passwörter und Peer-Adressen In diesem Szenario stellt die Konnektivität kein Problem dar, und Peers müssen in beiden Richtungen kommunizieren können (sie müssen nicht nur pingfähig, sondern auch über die entsprechenden AXL-Ports erreichbar sein: 8443).

Schritt 2: Sammeln Sie mindestens diese Protokollsätze aus den Instant Messaging- und IP-Clustern A und B:

•  Cisco AXL-Webservice
•  Cisco Intercluster Sync Agent

Vorsicht: Einige Service-Ablaufverfolgungen müssen auf den Debuglevel festgelegt werden, bevor der Test ausgeführt wird. Setzen Sie die Ablaufverfolgungsebene auf den Standardzustand, nachdem die Tests durchgeführt wurden, um weitere Auswirkungen auf die Leistung der Server zu vermeiden.

Anmerkung: Es ist wichtig, die Protokolle von beiden beteiligten Clustern zu erfassen.

Der Pfad zum Aktivieren der Debug-Ebene für die einzelnen Dienste lautet:

• 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 and click Go > Select IM and Presence Services and click Go > Select Cisco Intercluster Sync Agent and Click Go

Schritt 3: Die Protokollanalyse zeigt diesen Meldungsablauf an:

Wenn sich der Intercluster-Synchronisierungsagent in Cluster B (dem Cluster, in dem der Fehler Nicht erreichbar angezeigt wird) anmeldet, müssen Sie die AXL-Anforderung und den genauen Zeitpunkt, zu dem diese Anforderung gesendet wurde, identifizieren. Es sieht ungefähr so aus:

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 
         
        
       
     

Dieselben Intercluster-Synchronisierungsagentenprotokolle in Cluster B zeigen, dass die Antwort bis zwei Minuten später empfangen wird, was ein Timeout für die Transaktion verursacht:

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"

Dies könnte Sie zu der Vermutung verleiten, dass es im Netzwerk eine Art Paketverzögerung gibt. Der Text der Antwort selbst gibt jedoch an, dass der Peer in Cluster A zwei Minuten später eine AXL-Anforderung erhalten hat (Sie müssen die Zeitzonenumwandlung vornehmen, wenn sich die Cluster in verschiedenen Zeitzonen befinden).

Wenn Sie sich die AXL-Webdienstprotokolle in Cluster A ansehen, können Sie feststellen, dass die Anforderung in Millisekunden verarbeitet wird:

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 
           
          
         
        
       
     

Die gleichzeitige Paketerfassung von beiden Peers weist das gleiche Ergebnis auf: Die tatsächliche Verzögerung liegt nicht im Netzwerk selbst, aber das Problem ist, dass Cluster B das Paket verzögert, bevor es an Cluster A gesendet wird. Cluster A verarbeitet die Anforderung und beantwortet sie erwartungsgemäß in einigen Millisekunden.

Die Untersuchung, warum Cluster B die AXL-Anforderung verzögert oder was die genaue Ursache für dieses Problem ist, kann sehr zeitaufwendig sein. Es gibt jedoch eine Reihe von Validierungen, die als grundlegende Diagnoseschritte für dieses Szenario identifiziert wurden.

Problemumgehung

Es gab mehrere Fälle, in denen diese Verzögerung im IM&P-Cluster B durch ein DNS-Problem verursacht wurde. Es gibt zwei Szenarien:

Szenario 1:

In Cluster B ist der primäre DNS-Server nicht erreichbar. Obwohl der sekundäre DNS-Server erreichbar ist, hat der Knoten beim Versuch, alle erforderlichen FQDNs über den primären DNS-Server aufzulösen, eine erhebliche Verzögerung verzeichnet. Bei einem Wechsel auf den sekundären DNS-Server treten bereits 2 Minuten Verzögerung und damit eine Zeitüberschreitung der Anforderung auf.

Sie können dies mithilfe der folgenden CLI-Befehle überprüfen:

Führen Sie den Befehl show network eth0 aus, um aufzulisten, für welche DNS-Server der IM&P-Knoten konfiguriert ist:

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

Versuchen Sie dann, den primären DNS-Server über den Befehl utils network ping <IP-Adresse des primären DNS-Servers> zu pingen:

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

Wenn der primäre DNS-Server nicht erreichbar ist, stellen Sie sicher, dass die für ihn konfigurierte IP-Adresse korrekt ist. Beheben Sie dann alle Verbindungsprobleme. Sobald Sie problemlos sowohl den primären als auch den sekundären DNS-Server pingen können, muss auch der Inter-Clustering-Fehler behoben werden. Sollte das Problem nach diesen Aktionen weiterhin bestehen, gehen Sie wie in Szenario 2 beschrieben vor.

Szenario 2:

In Cluster B sind sowohl der primäre als auch der sekundäre DNS-Server erreichbar/pingbar, aber der IM&P-Server zeigt in der CLI und auf der Webseite weiterhin eine Warnung vor nicht erreichbarem DNS an:

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

Außerdem zeigt der CLI-Befehl utils diagnose test ein Problem mit der DNS-Auflösung an, insbesondere im validate_network-Modul, was auf einen Fehler hinweisen kann, z. B. Reverse DNS lookup fehlgeschlagen:

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

Dieser spezielle Fehler weist auf ein Problem mit dem DNS-Server hin, der einige IP-Adressen nicht in vollqualifizierte Domänennamen (FQDNs) auflösen kann. Sie können dieses Problem mithilfe des CLI-Befehls show network cluster weiter isolieren. Mit diesem Befehl wird die Liste der Einträge (alle CUCM- und IM&P-Server) angezeigt, die zu diesem Cluster gehören:

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

Sie müssen in der Lage sein, für alle diese Einträge eine DNS-Vorwärts- und -Rückwärtssuche durchzuführen.

Beispiel einer funktionierenden DNS-Auflösung:

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.

Beispiel einer nicht funktionierenden DNS-Auflösung:

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 diesem speziellen Fall enthält der DNS-Server nicht den PTR-Eintrag, der von der IP-Adresse 10.0.10.10 in IMPSUB.edgrodrilab.com FQDN aufgelöst werden soll.

Um die Warnung DNS unreachable (Nicht erreichbar) zu beheben und den Fehler Reverse DNS lookup failed (Umgekehrte DNS-Suche) zu beheben, müssen Sie die erforderlichen A Host- und PTR-Einträge im DNS-Server erstellen, um alle CUCM- und IM&P-Knoten für die Vorwärts- und Umkehrsuche auflösen zu können.

Überprüfung

Wenn das gleiche Inter-Clustering-Problem auftritt und die Fehlersignatur mit den Protokollen übereinstimmt, ist eine der zu überprüfenden Grundeinstellungen der Status und die Konfiguration des DNS-Servers.

Sowohl der primäre als auch der sekundäre DNS-Server müssen erreichbar/pingfähig sein und in der Lage sein, alle CUCM- und IM&P-Knoten im Cluster für eine Vorwärts- und Rückwärts-DNS-Suche aufzulösen.

Sie müssen alle DNS-Warnungen, -Fehler oder -Warnungen löschen, bevor Sie die Inter-Clustering-Fehler beheben können. Mit dem Befehl utils diagnose test können Sie die DNS-Konfiguration validieren.