DNSの誤設定が原因で発生するIM&Pのクラスタ間問題のトラブルシューティング

はじめに

このドキュメントでは、クラスタ間ピアシナリオにおいて、Cisco Instant Messaging and Presence(IM&P)Server内のピア接続テストで「Not reachable (Check peer address is valid, AXL is running on peer and AXL username/password credentials are valid)」エラーが表示されるシナリオについて説明します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

• Cisco IM and Presenceサービス
• クラスタ間ピアリング機能 

使用するコンポーネント

このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

次の図は、Cisco Unified CM IM and Presence Administration > Presence > Inter-Clusteringで見つかったエラーを示しています。

• Administrative XML Web Service(AXL)ユーザ名とAXLパスワードは両方とも有効です。
• Cisco AXL Webサービスがピアで実行されている。
• このクラスタ間エラーは、ドメインネームシステム(DNS)の設定の問題によって発生します。ただし、IM&Pトレースは、ネットワークによって生じる可能性のある遅延を示すように見えるため、初期トリアージを誤って導く可能性があります。両方のピアから同時にパケットキャプチャを収集すると、ネットワークに遅延が発生していないことがわかります。

注：通常、これは単方向の問題であり、IM&PクラスタAはIM&PクラスタBと正常に通信できるものの、IM&PクラスタBがIM&PクラスタAと通信しようとすると「Not reachable」エラーがスローされます。

トラブルシュート

ステップ 1：AXLユーザ名、AXLパスワード、およびピアアドレスがすべて正しいことを確認します。このシナリオでは、接続は問題ではなく、ピアは両方の方法で通信できる必要があります（pingが可能なだけでなく、対応するAXLポートを介して到達可能である必要があります：8443）。

ステップ 2：IM&PクラスタAおよびBの両方から、少なくとも次の一連のログを収集します。

•  Cisco AXL Web Service
•  Cisco Intercluster Sync Agent（ベータ版）

注意：一部のサービストレースは、テストを実行する前にデバッグレベルに設定する必要があります。サーバのパフォーマンスにこれ以上の影響を与えないように、テストの実行後にトレースレベルをデフォルト状態に設定します。

注：関係する両方のクラスタからログを収集することが重要です。

各サービスのデバッグレベルを有効にするパスは次のとおりです。

• Cisco Unified IM and Presence Serviceability > Trace > Configuration > Select IM&P Server と> Select Database and Admin Services の順にクリックし、Go > Cisco AXL Web Serviceを選択してGoをクリックします。
• Cisco Unified IM and Presence Serviceability > Trace > Configuration > Select IM&P Server と> Go > Select IM and Presence Servicesの順にクリックし、Go > Select Cisco Intercluster Sync Agentの順にクリックしてGoをクリックします。

ステップ 3：ログ分析は、次のメッセージフローを示します。

クラスタB(到達不能エラーを示すクラスタ)のIntercluster Sync Agent(ICA)ログから、AXL要求と、そのような要求が送信された正確な時刻を特定する必要があります。これは次のようになります。

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

クラスタBの同じIntercluster Sync Agent(ICD)ログに、応答が2分後まで受信され、その結果トランザクションのタイムアウトが発生したことが示されています。

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"

このため、ネットワーク内に何らかのパケット遅延が発生していると考えられる可能性があります。ただし、応答の本体自体は、クラスタAのピアが2分後にAXL要求を受信したことを示しています（クラスタが異なるタイムゾーンに配置されている場合は、タイムゾーンの変換を実行する必要があります）。

クラスタAのAXL Webサービスのログを調べると、要求がミリ秒単位で処理されていることがわかります。

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

両方のピアからの同時パケットキャプチャは同じことを示しています。実際の遅延はネットワーク自体の中にはありませんが、問題は、パケットがクラスタAに送信される前にクラスタBがパケットを遅延させることです。クラスタAは要求を処理し、予期したとおりに数ミリ秒で応答します。

クラスタBがAXL要求を遅延させる理由や、この問題の正確な原因を調査するには、非常に時間がかかる可能性があります。ただし、このシナリオの基本的な診断手順として特定された検証がいくつかあります。

回避策

IM&PクラスタBでこの遅延が発生する原因は、DNSの問題が複数あります。次の2つのシナリオのいずれかが考えられます。

シナリオ 1：

クラスタBでは、プライマリDNSサーバに到達できません。セカンダリDNSサーバは到達可能ですが、ノードがプライマリDNSサーバを介して必要なすべてのFQDNを解決しようとするときに大幅な遅延が発生しています。セカンダリDNSサーバに変更されるまでに、2分間の遅延がすでに発生しているため、要求がタイムアウトします。

これを検証するには、次のコマンドラインインターフェイス(CLI)コマンドを使用します。

show network eth0コマンドを発行して、IM&Pノードが使用するように設定されているDNSサーバをリストします。

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

次に、utils network ping <Primary DNS server's IP Address> コマンドを使用して、プライマリDNSサーバにpingを実行します。

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

プライマリDNSサーバに到達できない場合は、そのサーバに設定されているIPアドレスが正しいことを確認します。次に、すべての接続の問題を修正します。プライマリとセカンダリの両方のDNSサーバに対して問題なくpingを実行できるようになったら、クラスタ間エラーも修正する必要があります。これらのアクションを実行した後も問題が解決しない場合は、シナリオ2の手順を実行します。

シナリオ 2：

クラスタBでは、プライマリとセカンダリの両方のDNSサーバが到達可能またはping可能ですが、IM&PサーバのCLIとWebページには依然としてDNS到達不能の警告が表示されます。

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

また、CLIコマンドutils diagnose testは、特にvalidate_networkモジュール内のDNS解決の問題を示し、Reverse DNS lookup failedなどのエラーを示す可能性があります。

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

このエラーは、一部のIPアドレスを完全修飾ドメイン名(FQDN)に解決できないDNSサーバの問題を示します。 CLIコマンドshow network clusterを使用して、この問題をさらに切り分けることができます。このコマンドは、そのクラスタの一部であるエントリ（すべてのCUCMおよびIM&Pサーバ）のリストを表示します。

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

これらすべてのエントリに対して、正引きおよび逆引きDNSルックアップを実行できる必要があります。

有効なDNS解決の例：

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.

機能しないDNS解決の例：

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

この特定のケースでは、10.0.10.10 IPアドレスからIMPSUB.edgrodrilab.com FQDNに解決されるPTRレコードがDNSサーバに含まれていません。

DNS到達不能の警告とDNS逆引き参照の失敗エラーを修正するには、正引きおよび逆引き両方のDNSルックアップですべてのCUCMおよびIM&Pノードを解決できるようにするために、必要なAホストレコードとPTRレコードをDNSサーバに作成する必要があります。

確認

まったく同じクラスタ間の問題が発生し、エラーのシグネチャがログと一致する場合、確認すべき基本設定の1つはDNSサーバのステータスと設定です。

プライマリとセカンダリの両方のDNSサーバが到達可能/ping可能であり、クラスタ内のすべてのCUCMおよびIM&Pノードを解決してDNSの正引きおよび逆引きルックアップを実行できる必要があります。

クラスタ間エラーのトラブルシューティングを行う前に、DNSの警告、エラー、またはアラートをすべてクリアする必要があります。utils diagnose testコマンドを使用して、DNS設定を検証できます。