Question over VCS-E clustering and traversal zone with VCS-C +

[Chris Swinney]

Hi All,

We are just testing out the clustering of some VCS-E's which seems to have gone well. The addition of DNS SRV records into the cluster zone PLUS additional A records pointing to the individual peers, has allowed us to register and failover a variety of endpoints. Oddly, the Polycom HDX did not seem like using the just SRV records, although I seemed to have read somewhere that someone managed to get an HDX to register using just SRV. We had to add the A records with round robin in order to get this device to register.

One other pointer is that the "Cisco VCS Deployment Guide: Cluster creation and maintenance (Cisco VCS X7.2)" Appendix 8 outlines the endpoints that support SIP DNS SRV, but not H.323 DNS SRV. It would be nice to see at least what Cisco endpoint support H.323 DNS SRV lookup.

Still, the main question is:

With a cluster of VCS-E's, why can't we use the DNS name of the cluster for the traversal zone? Why do we need to specify the individual peers in the clusters? Surely this is the whole point of DNS? The only benefit I can see in adding the individual peers to the traversal zone is if the cluster is actually geographically dispersed, which means you can specify the order of which peer you which to connect with - obviously DNS round robin simply offer the next peer IP for each query, so in a geographically dispersed cluster, you may not necessarily connect with the best peer for that zone in the first instance.

Edit - it seems that if we add in the 'A' records to the cluster zone (e.g. cluster0.domain.com) which point to the individual peers, then we add the cluster FQDN into the traversal zone, we do actually get an active zone.However, failover of calls is a LOT quicker when multiple peers are

Many thanks

Chris

[Martin Koch]

Its more that its listed what supports sip rather than whats not supporting h323 srv records.

At least for us with recent TC and MXP software versions, SRV records for sip AND h323 work fine.

Yes, I remarked that before as well, it would e handy if the vcs traversal or neighbor zones could

be pointed to just one address and the peers would be auto populated by the given SRV records

which could also include weighted load balancing in between the peers, ...

File a feature request, thats seems to be the best way to go.

For the neigbor zone you should add specific A records for each cluster peer.

Like vcsc1.cluster-a.com, vcsc2....

Regards the issues with the 3rd party, I have seen many bad SRV implementations

you should take it with them.

[Chris Swinney]

Thanks Martin - again! I will certainly file another feature request - they are going to dislike m

To complete the picture, am I correct in thinking that its down to the endpoint/device to request a specific service (SRV) record from a DNS server for a given domain lookup - The DNS server will simply return what it has been asked for? These SRV records are returned to the endpoint in one query, essentially returning a list of potential peers for the endpoint to register with. Unlike a round robin lookup where the DNS server will return only one IP address to the endpoint during a query, which if found to be unreachable, the endpoint should then perform another query and receive the next peer IP. However, its's not the SRV records that allow the endpoint to "see" other potential peers, but the first gatekeeper the endpoint registers with provides a list of "alternative gatekeepers" - this is part of the H.323 specification.

As you can see, I'm just trying to get my head around what is happening.

Indeed, not only could the transversal/neighbour zones use the SRV records to populate a list of peers, but surely they could also use the "alternative gatekeeper" list provided by the peer to which the zone first attaches to.

I'm not sure what would be the best method, but it seems that the DNS SRV records are quite powerful.

However, and like I mentioned, if you have a geographically dispersed cluster, actually listing peers per zone might be of benefit as you can prioritise which peers a traversal zone may connect with in the first instance - which can be different for each zone. For example, we have several points of presence containing a VCS-E around a relatively small geographical location (physically a radius or around 250 miles). These are conected by a very good backbone and each peer is within a 7ms round trip time of each other peer. Each PoP may support 20 or so VCS-C, but we could carve up the VCS-E into 2 clusters (a 3 and a 4). Listing the peers per traversal zone means that we "could" direct the VCS-C to the nearest peer (as they are at the moment) but also benefit from some resilience (this would be complex to achieve in the DNS SRV as the weighting would be different within the same cluster depending on the location of the VCS-C. We could even set each other cluster as a lower priority in a DNS SRV meaning that we can have full geographical and technical failover.

The other possibility is to pull two sets of three into two central PoPs, then have a spare. Just musings really.