I have a few questions regarding clustering over the WAN.
1. We are having a lot of slow type responses from CM (logging into CM/making outbound calls) during this time I notice this error on the publisher Event Type: Error
Event Source: Cisco CallManager
Event Category: None
Event ID: 3
Time: 2:24:58 PM
Error: SDLLinkOOS - SDL link to remote application out of service.
Local node ID: 3
Local Application ID.: 100
Remote IP address of remote application: 10.XX.XX.4
Remote application ID.: 100
Unique Link ID.: 3:100:2:100
App ID: Cisco CallManager
Cluster ID: UK_CCM
Node ID: 10.XX.XX.4
from what I have read a lot of the communication between the CM's is via SDL? Right, if that is the case is SDL traffic marked with "DSCP EF"?
2. Does anyone have a good way of measuring the latency experienced between the CM's, again I believe this shouldn't exceed 40ms. Ideas or suggestions are much appreciated.
CallManager signaling such as Intra-Cluster Communication Signaling (ICCS) traffic between nodes will be marked with either DSCP 24 or CS3.
It is very important that you consider the bandwidth constraints when deploying or initially choosing your CallManager design, Centralised or Distributed?
For example, the mimimum bandwidth requirement for ICSS and database traffic is 1.544Mb/T1.
However if you have two remote servers in a different location to that of the Publisher, then you will have to double the bandwidth.
This is not including any media bandwidth for call across the WAN this would be additional.
The maximum round-trip time between any two servers must not exceed 40 msec or 80 msec for Unified CM 6.1 and later releases.
This time limit must include all delays in the transmission path between the two servers.
Verifying the round trip delay using the ping utility on the Unified CM server will not provide an accurate result. The ping is sent as a best-effort tagged packet and is not transported using the same QoS-enabled path as the ICCS traffic.
Therefore, Cisco recommends that you verify the delay by using the closest network device to the Unified CM servers, ideally the access switch to which the server is attached.
Cisco IOS provides a extended ping capable to set the Layer 3 type of service (ToS) bits to make sure the ping packet is sent on the same QoS-enabled path that the ICCS traffic will traverse. The time recorded by the extended ping is the round-trip time (RTT), or the time it takes to traverse the communications path and return.
The following example shows a Cisco IOS extended ping with the ToS bit (IP Precedence) set to 3:
Target IP address: 10.10.10.10
Repeat count :
Datagram size :
Timeout in seconds :
Extended commands [n]: y
Source address or interface:
Type of service : 3
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
This information can be found in the SRND under WAN Considerations. See the following link: