Re: Clustering Call Mangers in Wan

Pabloduarte · ‎12-13-2002

Is anyone Clustering Call Managers across a Wan Network.

By this I mean Call Manger Primary is on Site A and Subscriber is on Site B.

If so what is the bandwidht ?

What Call Manager Version?

Any Problems ?

Thank you for all and any feed back

Pablo

trailman73 · ‎12-13-2002

I read that in 3.3 it is a physical disatance issue. e.g. 1000 miles for TAC support, but I have not tested it. I wouldn't put it on anything less than a dedicated T1.

Geoff

david.lawrence · ‎12-17-2002

We are not doing this at the moment, but are planning this. We are currently running 3.1.3a. We have been advised that if we are splitting the cluster between sites then CM requires at least 100Mb connection between CM servers.

HTH

marinaibm · ‎12-18-2002

Every 10,000 busy hour call attempts (BHCA) in the cluster requires 900 kbps of bandwidth for Intra-Cluster Communication Signaling (ICCS). This is a minimum bandwidth requirement, and bandwidth is allocated in multiples of 900 kbps.

In addition to the real-time ICCS bandwidth, intra-cluster bandwidth is required for the SQL, CTI Manager, and LDAP traffic. The amount of additional bandwidth is dependant on the use of the system.

Signalling or Control Plane traffic requires additional bandwidth as well.

A maximum Round Trip Time (RTT) of 40 ms is allowed between any two servers in the Cisco CallManager cluster. This time equates to a 20 ms maximum one-way delay, or a transmission distance of approximately 3000 km under ideal conditions.

chadwick · ‎12-20-2002

from everything i have read and from seeing the amount of data passed between throughout my callmanager cluster (all in same location on 100mbit lan) I would not recommend it. the sql table updates require lots of bandwidth. now, if you have oc links between sites, then you probably have enough bandwidth to try it, but it cant be done over a t1 level circuit.

dgoodwin · ‎12-23-2002

The SQL replication updates for individual transactions are not very time-sensitive at all (except for the initial snapshot), since they would only come into play if the publisher becomes unavailable to one or more of the subscribers.

What is most important is the delay between each CallManager server. It should be no more than 40ms RTT between any 2 nodes in the cluster. By "node" I am referring to any box running CallManager and/or CTIManager.

walid_fahmy · ‎01-04-2003

This is a very interesting topic, I have the same challenge.

My customer has a CCM Cluster already in main branch, with 4 phones in 30 branches = 120 phones.

At a new site we want to throw away the PBX and put 130 phones connected to the same cluster above.

We shall put one CCM in that new site and make it subscriber to the main site.

Is this feasible considering 512 kbps between main site and new site.

Please advise.

marinaibm · ‎01-04-2003

No, 512 isn't enough. You would probably need something like 8-10MB i think. The best thing you could do is SRST on the router so in case the WAN fails your phones will keep working. SRST on 3725 can support up to 144 phones.

http://www.cisco.com/en/US/partner/products/sw/voicesw/ps2169/products_data_sheet09186a00800888ac.html

chris · ‎01-26-2003

Can anyone explain what the practical impact of the one way delay exceeding 20ms is? If you in in a 200ms delay environment to an international site, what will happen?

It certainly is desirable to run remote callmanagers in the same cluster to simplify administration as well as get the most rohbust feature set for the customer.

marinaibm · ‎01-26-2003

Hi,

I don't think it's desirable to run remote callmanagers. To simplify administration you would like to have them centralized . The only advantage i can see in doing so is redundancy . SRST can't support all the features so in the case of IP WAN failure you will loose some of them. You might have a big remote site and callmanager on site would do local call processing/music on hold/... as well.

Regarding the 20 ms..

>>The maximum Round Trip Time (RTT) between any two servers must not exceed 40 ms at any time. 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 Cisco CallManager 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 Cisco CallManager 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 maximum RTT between any two Cisco CallManager servers is 40 ms, and therefore the maximum one-way delay would be 20 ms. This delay is critical to the performance of the call processing capabilities of the Cisco CallManager cluster and must be strictly enforced.

The following is an example of 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

>>As the delay increases between the Cisco CallManager servers, the bandwidth information shared between the servers for call admission control will also be delayed, possibly allowing additional calls to be set up until the ICCS bandwidth message arrives. This situation is a small risk because, even at full capacity, only a few additional calls might be set up before the bandwidth information arrives. To provide for this situation, Cisco recommends that you over-provision the priority queue for voice traffic by a few extra calls.

You might like to read IPT design guide for more information ...

http://www.cisco.com/en/US/netsol/ns110/ns163/ns165/ns268/networking_solutions_design_guidances_list.html

chris · ‎01-28-2003

Yea, I am starting to come around to the idea that a remote callmanager is a bad idea. But to satisfy my curiosity, I am wondering what the practical impact of the > 40ms delay is. Any ideas beyond it is bad? The design guide is silent on that other then minor call adminission issues as you quoted.