Conductor clustering and latency

[david.reid66]

Hi Guys,

The Conductor prerequisites for latency clustering (from the TelePresence-Conductor-Clustering-Cisco-VCS-B2BUA-Deployment-Guide-XC2-3.pdf) state “If peers are deployed on different LANs, there must be sufficient connectivity between the networks to ensure a low degree of latency between the peers - a maximum delay of 15ms one way, 30ms round-trip”.

If a customer has an average round trip delay of say 50ms how is this going to affect the operation of the clustered Conductors? I.e. how critical is the 30ms and what happens if this is exceeded?

Thanks,

David

[dpetrovi]

Hi David, 

I advise you to move this question to Telepresence community to get the answer. This community is observed by Cisco Unified MeetingPlace and Cisco WebEx Meetings server experts, and not TP experts.

I hope this helps.

Dejan

[david.reid66]

Hi Guys,

Further to the “latency question” that’s not been answered, I’ve got one Conductor working fine with a clustered pair of Media 320’s and an 8710 blade. I then added “Conductor_2” as per the “Conductor Clustering Cisco VCS B2BUA Deployment Guide” and it seemed to cluster fine (no warnings), both Conductors had green text next to the Peer1 ,2 addresses. However, when I tried to place a call it connected to the 320 and dropped within a second or two.

I didn’t have any time to trouble shoot this further at the time but do you know what might cause this problem as I’ll be back on-site tomorrow?

Could this be due to the ping round trip being 50ms as opposed to the maximum 30ms?

Also, how much configuration is required on “Conductor_2” as I followed the guide which states:

“The remaining TelePresence Conductor peers must be configured according to the tasks in section "Configuring the TelePresence Conductor" in the Cisco TelePresence Conductor with Cisco VCS (B2BUA) Deployment Guide.” So I went through all of the configuration steps (almost all of tasks 14 – 24).

I have a rendezvous IP address in the same subnet as the Conductor_2 IP address. i.e. Initial_Conductor is 10.80.120.10 with a Rendezvous address of10.80.120 .11 and Conductor_2 is 10.99.120.10 with a Rendezvous address of 10.99.120.11. I’ve used the same “Location” names (VCSLocation), do these need to be different?

Any pointers greatly appreciated.

David

[Wayne DeNardi]

Can you confirm the versions of software you're using on each of your components (you've said you're using the XC2.3 guide - are you using that version on your conductors?).  What version of software are you using on your VCSes?  Are there any CUCMs involved?  Are all the conductors running the same version?  A little more information on your environment and how it's all configured and connected may be helpful.

Given your RTT is 50ms, which is significant;y higher than the 30ms max in all the documentation, it's likely this will cause you some issues, and will not be a "supported" solution.

Wayne
--
Please remember to rate responses and to mark your question as answered if appropriate.

[david.reid66]

Hi Wayne,

The good news is that I went through the install again and this time it worked fine. I must've made a configuration error of some kind initially.

My original point about the RTT was what would happen with excessive delay, what should I look for in the logs? Someone has put the 30ms figure in the documentation and I assume this was based on actual tests so what were they looking at?

I guess there's some keep alive timer between the Conductors that shouldn't be exceeded and I was going to look through the logs for timeouts or any errors. Saying that "issues" will result doesn't really explain what to look for.

As I say, it "seems" to be working fine but I'd be interested to know what to look for in the logs... just in case:-)

PS: The customer is going to improve the RTT between the Conductors with a new network but until that is installed the question was whether to only run on one Conductor or use both. As both "seem" to be working I'm going to leave it as is.

Kit:

VCSc/e in UK X7.2.3

VCSc/e in Australia X7.2.3

2 x Conductors in UK (average 50ms rtd between them) XC2.3

2 x Clustered Media 320's in UK (4.0(2.8))

1 x TPS 8710 in MSE8000 chassis in Australia (4.0(2.8))

(Note: I'll be migrating then clustering their existing MCU 8510 to a TPS 8710 next week)

Thanks,

DR

[Jonathan Robb · Accepted solution]

Hi David,

The Clustering function and the hard requirements should be the same as for a VCS (same basic function under the hood of each as far as I know)

What I generally see when going over the hard limits here are cluster DB replication failures - especially when making configuration changes.  The example I see most is a loss of the cluster database, both units or just the master losing its configurations that are stored in the Database.

-Jonathan

[david.reid66]

Hi Jonathan,

Thanks for the feedback. I've left both Conductors running and it's been fine so far.

I've made a few changes to the master and it has replicated to the slave ok but I don't think the customer will be changing the config much now.

If the customer gets any problems I'll have a look at in the logs for DB replication errors as you suggest.

Thanks again,

DR