VCS clusters and SRV records

We currently have 2 x VCS control that we wish to make into a cluster. One is at our primary location and the other is at a remote backup site. We want all endpoints to use the primary VCS when possible and only use the backup when the primary isn't availible. This is due to higher latency and lower bandwidth at our backup site and the fact that we have plenty of capacity on our primary VCS and don't need to load share.

The VCS cluster creation and maintenance states:

"Option 1 – DNS SRV (preferred)

To use this option, there must be a DNS SRV record available for the DNS name of the Cisco VCS cluster that defines an equal weighting and priority for each cluster peer. "

From what I gather, this would distribute registrations between the VCS peers rather than using one VCS over the other. If I give the primary VCS a better priority and weight, will this achieve my desired outcome of always using the primary VCS where possible?

One other question - as this is an existing set up that I wish to turn into a cluster, do I just need to point the endpoints to a DNS server and change the gatekeeper/SIP server entry to the new shared hostname rather than the single IP address that it's using at the moment?

VCS clusters and SRV records

Hi Nick,

yes in the case where you want to force all registrations onto the preferred VCS, you should create the SRV records so that one VCS has a better (numeric lower) priority than the other.

Please note however that DNS SRV is not necessarily implemented identically in all types of endpoints/softclients from various vendors, meaning that while some respect both priority and weight, others might not, so I would suggest that you lab this before you implement it in a production environment. There are also endpoints which do not support DNS SRV at all, and for these you will most likely have to force the registration onto the preferred VCS.

When transitioning from the standalone VCS to the cluster, the only thing you should have to do is to change the H323 gatekeeper/SIP server address and point these to the new cluster FQDN for which you have created these SRV records.

VCS clusters and SRV records

Hi Nick,

yes in the case where you want to force all registrations onto the preferred VCS, you should create the SRV records so that one VCS has a better (numeric lower) priority than the other.

Please note however that DNS SRV is not necessarily implemented identically in all types of endpoints/softclients from various vendors, meaning that while some respect both priority and weight, others might not, so I would suggest that you lab this before you implement it in a production environment. There are also endpoints which do not support DNS SRV at all, and for these you will most likely have to force the registration onto the preferred VCS.

When transitioning from the standalone VCS to the cluster, the only thing you should have to do is to change the H323 gatekeeper/SIP server address and point these to the new cluster FQDN for which you have created these SRV records.

VCS clusters and SRV records

Steven,

this can be achieved in multiple ways.

You could either have split DNS for these three sites, meaning you could deploy separate DNS servers in each site, replying with DNS responses which are tailored for each site, or you could use a DNS implementation which allows the DNS server to base its responses on the origin of the DNS request - for example using BIND's view clause, which is described here:

There may also be other DNS implementations which allows for similar functionality.

You could also create subdomains in DNS and tailor your SRV records that way, for instance creating the subdomains denver.xyz.gov, nc.xyz.gov, dc.xyz.gov, where the H323/SIP SRV records for the denver subdomain have one prioritized/weighted list with your preferred order, while the nc subdomain has a list where the order is different.

Once you have created these subdomains and associated SRV records, you could configure the west coast endpoints with a gatekeeper/sip proxy address of 'denver.xyz.gov' and these will then locate VCS's based on the SRV records for this subdomain and so forth.

SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
view more

Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
view more

CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...
view more