Problemen met IM&P Inter-Clustering oplossen die worden veroorzaakt door DNS-verkeerde configuratie

Inleiding

Dit document beschrijft een scenario waarin "Niet bereikbaar (Controleer het peer-adres geldig is, AXL actief is op de peer en AXL gebruikersnaam/wachtwoord referenties geldig zijn)" fout wordt ontvangen voor de Peer Connectivity Test binnen Cisco Instant Messaging and Presence (IM&P) Server in een intercluster peer scenario.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• Cisco IM- en Presence-service
• Functie voor intercluster peering 

Gebruikte componenten

Dit document is niet beperkt tot specifieke software- en hardware-versies.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Achtergrondinformatie

De volgende afbeelding toont de fout in Cisco Unified CM IM en Presence Management > Presence > Inter-Clustering:

• Zowel de Admin XML Web Service (AXL) Gebruikersnaam als het AXL-wachtwoord zijn geldig.
• Cisco XL Web Service is actief op de peer.
• Deze Inter-Clustering fout wordt veroorzaakt door problemen met de Domain Name System (DNS)-configuratie; de traces van IM&P kunnen de eerste triage echter misleiden, aangezien zij wijzen op een mogelijke vertraging die door het netwerk wordt geïntroduceerd. De gelijktijdige inzameling van de pakketopname van beide peers zou dan tonen dat er geen vertraging in het netwerk om het even welke is.

Opmerking: Meestal is dit een eenrichtingsprobleem, wat betekent dat IM&P Cluster A met succes kan communiceren met IM&P Cluster B, maar IM&P Cluster B werpt de Niet bereikbare fout wanneer het probeert te communiceren met IM&P Cluster A.

Problemen oplossen

Stap 1. Controleer dat de AXL-gebruikersnamen, AXL-wachtwoorden en peer-adressen allemaal correct zijn. In dit scenario is connectiviteit geen probleem en moeten peers op beide manieren kunnen communiceren (ze moeten niet alleen pingable zijn, maar ook bereikbaar via de bijbehorende AXL poorten: 843).

Stap 2. Verzamel ten minste deze set logboeken van zowel IM&P Cluster A als B:

•  Cisco XL webservice
•  Cisco Intercluster Sync Agent

Voorzichtig: Sommige servicetrajecten moeten worden ingesteld om het debug-niveau te bereiken voordat de test wordt uitgevoerd. Stel het traceerniveau in op de standaardstatus nadat de tests zijn uitgevoerd om verdere gevolgen voor de prestaties van de servers te voorkomen.

Opmerking: Het is belangrijk om de logboeken van beide betrokken clusters te verzamelen.

Het pad voor het inschakelen van het debugniveau voor elke service is:

• Cisco Unified IM en Presence Servicability > Trace > Configuration > Selecteer IM&P Server en klik op Go > Selecteer Database en Admin Services en klik op Go > Selecteer Cisco XL Web Service en klik op Go
• Cisco Unified IM en Presence Servicability > Trace > Configuration > Selecteer IM&P Server en klik op Go > Selecteer IM en Presence Services en klik op Go > Selecteer Cisco Intercluster Sync Agent en klik op Go

Stap 3. De loganalyse toont deze berichtstroom:

Van de Intercluster Sync Agent logt in Cluster B (het cluster dat de niet bereikbare fout toont), moet u het AXL-verzoek en de exacte tijd identificeren waarop een dergelijk verzoek werd verzonden. Het ziet er zo uit:

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 
         
        
       
     

Dezelfde Intercluster Sync Agent logt in de Cluster B toont aan dat de respons wordt ontvangen tot twee minuten later, wat een time-out veroorzaakt voor de transactie:

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"

Dit kan leiden tot het vermoeden dat er een soort pakketvertraging is in het netwerk. Echter, het lichaam van de reactie zelf geeft aan dat de peer in Cluster A twee minuten later een AXL verzoek heeft ontvangen (u moet de tijdzoneconversie uitvoeren als de clusters zich in verschillende tijdzones bevinden).

Als u kijkt naar AXL Web Service logt in Cluster A, kunt u vinden dat het verzoek in een kwestie van milliseconden wordt verwerkt:

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 
           
          
         
        
       
     

Gelijktijdige pakketopnamen van beide peers tonen hetzelfde aan: de werkelijke vertraging is niet binnen het netwerk zelf, maar het probleem is dat Cluster B het pakket vertraagt voordat het naar Cluster A wordt gestuurd. Cluster A verwerkt het verzoek en beantwoordt het binnen een paar milliseconden, zoals verwacht.

Het onderzoek naar de reden waarom Cluster B het AXL-verzoek vertraagt of wat de precieze oorzaak van deze kwestie is, kan zeer tijdrovend zijn. Er zijn echter een aantal validaties die zijn geïdentificeerd als fundamentele diagnostische stappen voor dit scenario.

Tijdelijke oplossing

Er zijn meerdere gevallen geweest waarin deze vertraging binnen IM&P Cluster B wordt veroorzaakt door een probleem met DNS. U kunt met een van deze twee scenario's worden geconfronteerd:

Scenario 1:

In Cluster B is de primaire DNS-server niet bereikbaar. Hoewel de secundaire DNS-server bereikbaar is, heeft de knooppunt een aanzienlijke vertraging opgelopen toen het probeerde alle vereiste FQDN’s via de primaire DNS-server op te lossen. Tegen de tijd dat het verandert in de secundaire DNS-server, is er al een vertraging van 2 minuten en daarom de aanvraagtijden uit.

De manier waarop u dit kunt valideren is via deze opdrachten van de Command Line Interface (CLI):

Geef de opdracht eth0 van het shownetwerk uit om een lijst te maken van de DNS servers IM&P-knooppunt is ingesteld op gebruik:

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

Probeer vervolgens de primaire DNS-server te pingen via het utils-netwerk en ping <Primary DNS server's IP Address> opdracht:

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

Als de primaire DNS-server niet bereikbaar is, moet u ervoor zorgen dat het IP-adres dat hiervoor is geconfigureerd, correct is. Los vervolgens alle connectiviteitsproblemen op. Zodra u in staat bent om zowel primaire als secundaire DNS servers zonder problemen te pingen, moet de Inter-Clustering fout ook worden hersteld. Als de kwestie na deze acties voortduurt, ga dan door de stappen van scenario 2.

Scenario 2:

In Cluster B zijn zowel primaire als secundaire DNS-servers bereikbaar/pingable, maar de IM&P-server toont nog steeds een DNS onbereikbare waarschuwing in de CLI en de webpagina:

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

Ook toont de CLI-opdrachttools diagnostische test een probleem met DNS-resolutie, specifiek binnen de validate_network-module, die kan wijzen op een fout zoals omgekeerde DNS-lookup is mislukt:

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

Deze specifieke fout duidt op een probleem met de DNS-server, die bepaalde IP-adressen niet kan oplossen naar volledig gekwalificeerde domeinnamen (FQDN’s). U kunt dit probleem verder isoleren via de CLI-opdracht toont netwerkcluster. Deze opdracht geeft de lijst weer van vermeldingen (Alle CUCM- en IM&P-servers) die deel uitmaken van dat 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

U moet voorwaarts kunnen doen en DNS raadpleging over al die ingangen omkeren.

Voorbeeld van een werkende DNS-resolutie:

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.

Voorbeeld van een niet-werkende DNS-resolutie:

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 dit specifieke geval bevat de DNS-server niet het PTR-record om van 10.0.10.10 IP-adres naar IMPSUB.edgrodrilab.com FQDN op te lossen.

Om de DNS onbereikbare waarschuwing en de omgekeerde DNS raadpleging mislukte fout te repareren, moet u de vereiste A Host en PTR records in de DNS server maken om alle CUCM en IM&P knooppunten voor zowel voorwaartse als omgekeerde DNS raadpleging te kunnen oplossen.

Verifiëren

Wanneer exact dezelfde Inter-Clustering kwestie wordt ervaren en de fouthandtekening overeenkomt met de logbestanden, is een van de basisinstellingen die moeten worden gecontroleerd de DNS-serverstatus en -configuratie.

Zowel primaire als secundaire DNS-servers moeten bereikbaar/pingable zijn en in staat om alle CUCM- en IM&P-knooppunten binnen het cluster op te lossen voor voorwaartse en omgekeerde DNS-lookup.

U moet alle DNS-waarschuwingen, fouten of waarschuwingen verwijderen voordat u problemen oplost met de Inter-Clustering-fouten. U kunt de hulpprogramma's diagnostiseren test opdracht om DNS configuratie te valideren.