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

概要

このドキュメントでは、クラスタ間ピアシナリオで、Cisco Instant Messaging and Presence(IM&P)サーバ内のピア接続テストで「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) Username]と[AXL Password]はどちらも有効です。
• 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] > [IM&P Server] を選択し、[Go] > [Select Database and Admin Services] をクリックし、[Go] > [Select Cisco AXL Web Service] をクリックして、[Go] をクリックします
• [Cisco Unified IM and Presence Serviceability] > [Trace] > [Configuration] > [IM&P Server] を選択し、[Go] > [Select IM and Presence Services] をクリックし、[Go] > [Select Cisco Intercluster Sync Agent] をクリックして、[Go] をクリックします

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

クラスタB(Not reachableエラーを示すクラスタ)のIntercluster Sync Agent(ICD)ログから、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サーバに作成する必要があります。

確認

まったく同じクラスタ間の問題が発生し、エラーシグニチャがログと一致する場合は、DNSサーバのステータスと設定を確認する必要があります。

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

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