目錄

簡介

必要條件

需求

採用元件

背景資訊

疑難排解

因應措施

驗證

簡介

本文描述在集群間對等場景中，Cisco Instant Messaging and Presence(IM&P)Server內的對等連線測試收到錯誤「無法訪問（檢查對等體地址有效，AXL在對等體上運行，AXL使用者名稱/密碼憑據有效）」的場景。

必要條件

需求

思科建議您瞭解以下主題：

- Cisco IM和狀態服務

- 集群間對等功能

採用元件

本文件所述內容不限於特定軟體和硬體版本。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

背景資訊

下一張圖顯示Cisco Unified CM IM and Presence Administration > Presence > Inter-Clustering中發現的錯誤：

- 管理XML Web服務(AXL)使用者名稱和AXL密碼均有效。

- Cisco AXL Web服務正在對等體上運行。

- 此群集間錯誤是由域名系統(DNS)配置的問題導致的；但是，IM&P跟蹤可能會誤導初始分類，因為它們似乎表示網路可能引入延遲。來自兩個對等體的同時資料包捕獲收集將顯示網路中沒有任何延遲。

附註：通常，這是一個單向問題，這意味著IM&P集群A能夠成功與IM&P集群B通訊，但IM&P集群B在嘗試與IM&P集群A通訊時引發Unreachable錯誤。

疑難排解

步驟1.檢驗AXL使用者名稱、AXL密碼和對等體地址是否全部正確。在此案例中，連線並不是問題，對等點必須能夠同時以兩種方式通訊(它們不僅必須能被ping通，而且可以通過對應的AXL連線埠連線：8443)。

步驟2.從IM&P集群A和B中至少收集以下一組日誌：

- Cisco AXL Web服務

- 思科叢集間同步代理

注意：在執行測試之前，某些服務跟蹤需要設定為調試級別。在執行測試之後將跟蹤級別設定為預設狀態，以避免對伺服器效能產生任何進一步的影響。

附註：從兩個相關的群集收集日誌非常重要。

為每個服務啟用調試級別的路徑為：

- Cisco Unified IM and Presence Serviceability > Trace > Configuration > Select IM&P Server 並按一下Go > Select Database and Admin Services，然後按一下Go > Select 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(顯示無法訪問錯誤的群集)中的群集間同步代理日誌中，您需要確定AXL請求以及傳送此類請求的確切時間。如下所示：

2019-07-14 06:00:07,842 DEBUG [Peer: node name in Cluster A] axl.AXLClientLogger - runSoapReq: The axl request is :

群集B中的同一群集間同步代理日誌顯示，在兩分鐘之後才收到響應，這將導致事務超時：

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 :

"node name in Cluster A" received AXL request at "2019-07-14 01:02:36"

這可能導致您懷疑網路中存在某種型別的資料包延遲。但是，響應正文本身表明群集A中的對等體在二分鐘後收到了AXL請求（如果群集位於不同的時區，則需要執行時區轉換）。

如果您在群集A中檢視AXL Web服務日誌，可以發現該請求在毫秒內即可處理：

2019-07-14 01:02:36,110 INFO  [http-bio-443-exec-742] servletRouters.AXLFilter - AXL REQUEST :

"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  :

來自兩個對等點的同步封包擷取顯示相同：實際延遲不在網路本身之內，但問題是群集B會在將資料包傳送到群集A之前延遲該資料包。群集A會處理該請求並在幾毫秒內如預期那樣做出響應。

對於群集B為何延遲AXL請求或此問題的確切原因的調查可能非常耗時。但是，有幾個驗證被確定為此場景的基本診斷步驟。

因應措施

在多種情況下，IM&P群集B中的延遲是由DNS問題引起的。您可以面對以下兩種情況中的任一種：

案例 1:

在群集B中，無法訪問主DNS伺服器。雖然可以訪問輔助DNS伺服器，但節點嘗試通過主DNS伺服器解析所有所需的FQDN時卻發生了嚴重的延遲。到它更改為輔助DNS伺服器時，已經存在2分鐘的延遲，因此請求超時。

您可以透過以下命令列介面(CLI)命令驗證這點：

發出show network eth0命令，列出配置為使用的DNS伺服器IM&P節點：

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> 命令ping主DNS伺服器：

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地址正確。然後，修復所有連線問題。一旦您能夠ping通主DNS伺服器和輔助DNS伺服器而沒有出現問題，也必須修復群集間錯誤。如果在執行這些操作後問題仍然存在，請執行場景2中的步驟。

案例 2:

在群集B中，可訪問/ping主和輔助DNS伺服器，但IM&P伺服器仍在CLI和網頁中顯示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顯示DNS解析問題，尤其是在validate_network模組中，這可能表示錯誤，例如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

此特定錯誤表示DNS伺服器出現問題，該伺服器無法將某些IP地址解析為完全限定域名(FQDN)。 您可以通過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

在此特定情況下，DNS伺服器不包含要從10.0.10.10 IP地址解析為IMPSUB.edgrodrilab.com FQDN的PTR記錄。

要修復DNS無法訪問警告和反向DNS查詢失敗錯誤，您需要在DNS伺服器中建立所需的A Host和PTR記錄，以便能夠解析正向和反向DNS查詢的所有CUCM和IM&P節點。

驗證

遇到完全相同的群集間問題並且錯誤簽名與日誌匹配時，需要檢查的基本設定之一是DNS伺服器狀態和配置。

主DNS伺服器和輔助DNS伺服器都需要可訪問/可執行ping操作，並且能夠解析集群內的所有CUCM和IM&P節點以進行正向和反向DNS查詢。

在對群集間錯誤進行故障排除之前，您需要清除所有DNS警告、錯誤或警報。您可以使用utils diagnose test 命令驗證DNS配置。