Buy or Renew
Buy or Renew
Cisco + Splunk: It’s a new day for your data. Learn more.
 
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
903
Views
0
Helpful
3
Replies

CM Cluster over WAN

Go to solution
dvanzee
Level 2
Level 2

‎10-02-2008 05:35 AM - edited ‎03-15-2019 01:41 PM

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

Date: 9/30/2008

Time: 2:24:58 PM

User: N/A

Computer: UK-CALL-3

Description:

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

RemoteNodeID: 2

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.

CM 4.2.3

Labels:
0 Helpful
1 Accepted Solution

Accepted Solutions

Go to solution
allan.thomas
Level 8
Level 8
In response to

‎10-08-2008 04:15 PM

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.

Delay Testing

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:

Access_SW#ping

Protocol [ip]:

Target IP address: 10.10.10.10

Repeat count [5]:

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface:

Type of service [0]: 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:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/4x/42models.html#wp1045871

Rgds

Allan.

View solution in original post

0 Helpful
3 Replies 3

Go to solution
Not applicable

‎10-08-2008 03:40 PM

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 Date: 9/30/2008 Time: 2:24:58 PM User: N/A Computer: UK-CALL-3 Description: 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 RemoteNodeID: 2 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. CM 4.2.3

0 Helpful

Go to solution
allan.thomas
Level 8
Level 8
In response to

‎10-08-2008 04:15 PM

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.

Delay Testing

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:

Access_SW#ping

Protocol [ip]:

Target IP address: 10.10.10.10

Repeat count [5]:

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface:

Type of service [0]: 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:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/4x/42models.html#wp1045871

Rgds

Allan.

0 Helpful

Go to solution
dvanzee
Level 2
Level 2
In response to allan.thomas

‎10-09-2008 05:24 AM

Thanks!

0 Helpful
Customers Also Viewed These Support Documents