排除DNS配置錯誤導致的IM&P群集間問題
簡介
本文描述在集群間對等場景中，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跟蹤可能會誤導初始分類，因為它們似乎表示網路可能引入延遲。來自兩個對等體的同時資料包捕獲收集將顯示網路中沒有任何延遲。
疑難排解
步驟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 :
SELECT count(*) from processnode WHERE systemnode='f' and tknodeusage= 0
群集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 :
2
"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 :
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
來自兩個對等點的同步封包擷取顯示相同：實際延遲不在網路本身之內，但問題是群集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配置。
修訂記錄
| 修訂 | 發佈日期 | 意見 |
|---|---|---|
1.0 |
03-Dec-2021 |
初始版本 |
意見