Problemen met IM&P-interclustering oplossen als gevolg van verkeerde configuratie van DNS

Inleiding

Dit document beschrijft een scenario waarin de fout "Niet bereikbaar (Controleer of het peer-adres geldig is, AXL wordt uitgevoerd op peer en AXL-gebruikersnaam/wachtwoordreferenties geldig zijn)" is ontvangen voor de peer-connectiviteitstest 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 aanwezigheidsservice
• Intercluster-peering-functie 

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 die is gevonden in Cisco Unified CM IM en Presence Administration > Presence > Inter-Clustering:

• Zowel de Administrative XML Web Service (AXL)-gebruikersnaam als het AXL-wachtwoord zijn geldig.
• Cisco AXL Web Service wordt uitgevoerd op de peer.
• Deze interclusterfout wordt veroorzaakt door problemen met de configuratie van het Domain Name System (DNS); de IM&P-sporen kunnen echter de eerste triage misleiden, omdat ze lijken te wijzen op een mogelijke vertraging die door het netwerk is geïntroduceerd. Gelijktijdig verzamelen van pakketten van beide peers zou dan aantonen dat er geen enkele vertraging in het netwerk is.

Opmerking: Meestal is dit een eenrichtingsprobleem, wat betekent dat de IM&P Cluster A in staat is om succesvol te communiceren met de IM&P Cluster B, maar de IM&P Cluster B gooit de Niet bereikbare fout wanneer het probeert te communiceren met IM&P Cluster A.

Problemen oplossen

Stap 1. Controleer of 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 pingbaar zijn, maar ook bereikbaar via de bijbehorende AXL-poorten: 8443).

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

•  Cisco AXL Web Service
•  Cisco Intercluster Sync Agent

Let op: Sommige servicetraces moeten op foutopsporingsniveau worden ingesteld voordat de test wordt uitgevoerd. Stel het traceringsniveau 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 logs van beide betrokken clusters te verzamelen.

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

• Cisco Unified IM and Presence Serviceability > Trace > Configuration > Select IM&P Server en klik op Go > Select Database and Admin Services en klik op Go > Select Cisco AXL Web Service en klik Go
• Cisco Unified IM and Presence Serviceability > Trace > Configuration > Select IM&P Server en klik op Go > Select IM and Presence Services en klik op Go > Select Cisco Intercluster Sync Agent en klik Go

Stap 3. De logboekanalyse toont deze berichtenstroom:

Vanuit de logbestanden van de Intercluster Sync Agent in Cluster B (het cluster dat de fout Niet bereikbaar weergeeft) moet u het AXL-verzoek en het exacte tijdstip waarop een dergelijk verzoek is verzonden, identificeren. Het ziet er ongeveer 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 logboeken van de Intercluster Sync Agent in Cluster B laten zien dat het antwoord tot twee minuten later wordt ontvangen, waardoor een time-out voor de transactie ontstaat:

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 ertoe leiden dat u vermoedt dat er een soort pakketvertraging is binnen het netwerk. Het lichaam van het antwoord zelf geeft echter 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-logs in Cluster A, kunt u zien 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 pakketopnames van beide peers laten hetzelfde zien: de werkelijke vertraging bevindt zich niet binnen het netwerk zelf, maar het probleem is dat Cluster B het pakket vertraagt voordat het wordt verzonden naar Cluster A. Cluster A verwerkt het verzoek en beantwoordt het in een paar milliseconden, zoals verwacht.

Het onderzoek naar de reden waarom cluster B het AXL-verzoek vertraagt of wat de precieze oorzaak van dit probleem is, kan zeer tijdrovend zijn. Er zijn echter een paar validaties die zijn geïdentificeerd als basisdiagnostische stappen voor dit scenario.

Tijdelijke oplossing

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

Scenario 1:

In cluster B is de primaire DNS-server niet bereikbaar. Hoewel de secundaire DNS-server bereikbaar is, heeft de node een aanzienlijke vertraging opgelopen bij het oplossen van alle vereiste FQDN's via de primaire DNS-server. Tegen de tijd dat het verandert naar de Secundaire DNS-server, is er al een vertraging van 2 minuten en daarom is de aanvraag time-out.

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

Geef de opdracht show network eth0 op om de DNS-servers weer te geven waarvoor de IM&P-node is geconfigureerd:

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 de opdracht ping <IP-adres primaire DNS-server> van het netwerk:

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, controleert u of het IP-adres dat hiervoor is geconfigureerd, juist is. Los vervolgens alle verbindingsproblemen op. Zodra u zonder problemen zowel primaire als secundaire DNS-servers kunt pingen, moet de interclusterfout ook worden opgelost. Als het probleem na deze acties blijft bestaan, doorloopt u de stappen uit Scenario 2.

Scenario 2:

In cluster B zijn zowel primaire als secundaire DNS-servers bereikbaar/pingbaar, maar de IM&P-server geeft nog steeds een DNS-onbereikbare waarschuwing in de CLI en 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 de CLI-opdracht Hulpmiddelen diagnose test toont een probleem met DNS-resolutie, met name binnen de validate_network module, die een fout zoals Reverse DNS lookup mislukt kan aangeven:

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 sommige IP-adressen niet kan oplossen in volledig gekwalificeerde domeinnamen (FQDN's). U kunt dit probleem verder isoleren via de CLI-opdracht netwerkcluster weergeven. Met deze opdracht wordt de lijst weergegeven met items (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 in staat zijn om vooruit te doen en DNS omkeren opzoeken op al deze ingangen.

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 dat moet worden opgelost vanaf 10.0.10.10 IP-adres naar IMPSUB.edgrodrilab.com FQDN.

Om de onbereikbare waarschuwing van DNS en de fout bij het zoeken naar omgekeerde DNS te verhelpen, 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-zoekopdrachten te kunnen oplossen.

Verifiëren

Wanneer exact hetzelfde probleem met interclustering wordt ondervonden en de fouthandtekening overeenkomt met de logs, is een van de basisinstellingen om te controleren de DNS-serverstatus en -configuratie.

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

U moet alle DNS-waarschuwingen, fouten of waarschuwingen wissen voordat u de interclusterfouten oplost. U kunt de opdracht Diagnosetest gebruiken om de DNS-configuratie te valideren.