I'm having trouble understanding the VCS Cluster's FQDN and associated SRV records for incoming calls and registrations.
According to the VCS Cluster Deployment Guide:
Example: DNS SRV records for 2 peers of a VCS Expressway cluster for company.com
_sips._tcp.company.com. 86400 IN SRV 1 1 5061 vcse1.company.com.
_sips._tcp.company.com. 86400 IN SRV 1 1 5061 vcse2.company.com.
Where does the Cluster's FQDN play a part in the SRV records, and also the cluster peers. It's my understanding that in the above SRV records, company.com would be the SIP domain, not the cluster FQDN. I understand SRV records, as we have 1 VCS, adding a second to be clustered, so the cluster FQDN is throwing me for a loop. I've been reading over all the guides and posts here in the forums, but I just can't wrap my head around it.
Would the following be correct, looking from the outside going in at the DNS records:
I also understand that A records need to be in place for the Cluster FQDN to point to each cluster peer, however they are not shown in this example.
Regarding the example, it is that of the Expressway. In most cases I've seen, the SIP domain is used as the cluster FQDN. For an Expressway, this design is preferred for simplicity. Regarding a VCS Control cluster, there are other things to consider. For example, if Provisioning is enabled on the cluster, do not change the cluster name after enabling Provisioning. The FQDN of the cluster would also be used for load balancing device registration. Normally you would not use the SIP domain as the Control cluster FQDN, as this will already resolve to the Expressway. Once again, a common FQDN for the Control cluster would be vcs.domain.com for simplicity. What you decide to use is really up to you, and how you want things resolved.
Sent from Cisco Technical Support iPhone App
The example is just that, an example, it wasn't directed toward the control or expressway in particular. Just trying to get an understanding of the cluster FQDN, associated peers, and how they fit in the order of DNS.
Currently our SIP domain resolves to our single VCS-C, we're working on adding a second C and two VCS-Es, both sets of VCSs will be clustered of course. In the future after the implentation at a later date, our SIP domain will change to match our organizations domain.
Once I figure out how the order of SRV records go in relation to SIP Domain, Cluster FQDN, Cluster Peers, etc for the Expressway. Then I'll look at that and include the Control, one thing at a time though. Like I said, its the inclusion of the cluster FQDN that is messing up in understanding this.
The SRV records for the SIP domain should point to each peer:
_sips._tcp.video.domain.com >>> vcs-c1.domain.com
_sips._tcp.video.domain.com >>> vcs-c2.domain.com
The inclusion of the cluster FQDN makes things confusing me.
One thing I'm considering is having the E records be the same as the C, of course the addresses would differ. As you'd go to the VCS that best suites where you're located, being either in the network or outside. I noticed that was mentioned in the VCS-C/E deployment guide, using internal and external DNS.
So, to clear up my confusion one last time I think, would the cluster FQDN be used anywhere in the DNS records? Also where and in what cases, would it be used to point devices to? It's my understanding that the cluster FQDN would need each peer listed as A records for whatever purpose?
In my case, until we change our SIP domain to match our organization's domain, I would have a DNS record point it to the cluster FQDN for simplicity.
Thanks for all the help!
Do i need to create expressway-E and Expressway-C server Host A record before upgrading 8.8 later ?
I know that i need to create host A record dedicated dns for expressway-E server (That is suggested by TAC)
I want to know that do i need to create same host A record for expressway-C ?
Talk about digging up an old thread, almost 5 years old.
Usually you only need to do this for the Expressway-E, because external endpoints that try and call you will utilize DNS to lookup SRV records that point to the Expressway cluster, for example:
Don't really need to this for the Expressway-C, because anything internal will be registered to CUCM, or the Expressway-C itself. You could use the cluster FQDN though as the endpoint's SIP Proxy if registering to the Expressway-C, utilizing Round Robin DNS for failover, but the endpoint software allow for multiple SIP Proxies so there isn't really a need to do this.
My Exp cluster is working fine now im planning upgrade it 8.10.4
I understand that i dont need to define expc host record own dns record. I will create dedicated dns server for expressway-E resolving clsutering ip /fqdn resolotion. that is suggested by tac.
I will also change tls verfication mode: permissive to enforce.
Do i need to map fqdn to ipusing with Cluster address mapping:enabled parameters : I thing is not mandotary.
On this page 20:
Cluster address mapping is only needed if for some reason the Expressway cannot access or lookup fails for any of the cluster peers when using FQDN.
I sopke with tac they suggested specify dns server for expressway-e server for cluster enviroment for host a record. I mean that I need to use dedicated dns server needed for expressway-e.
I will configure host a record on expc dns server.
I will also create new dns server then i will configure host a record each of expe server after that i will add this dns ip on expe right ?
I have the same doubt about VCSe cluster FQDN DNS records, as you did.
Maybe you can help clarify since the documentation is not really clear about cluster FQDN DNS A records.
FQDN of VCS Expressway peer 1: vcse1.company.com
FQDN of VCS Expressway peer 2: vcse2.company.com
FQDN of VCS Expressway cluster: video.company.com
We have the following SRV records:
_sips._tcp.company.com 86400 IN SRV 10 10 5061 vcse1.company.com
_sips._tcp.company.com 86400 IN SRV 10 10 5061 vcse2.company.com
_sips._tcp.company.com 86400 IN SRV 10 10 5061 video.company.com
_sip._tcp.company.com 86400 IN SRV 10 10 5060 vcse1.company.com.
_sip._tcp.company.com 86400 IN SRV 10 10 5060 vcse2.company.com.
_sip._tcp.company.com 86400 IN SRV 10 10 5060 video.company.com
_h323ls._udp.company.com 86400 IN SRV 10 10 1719 vcse1.company.com _h323ls._udp.company.com 86400 IN SRV 10 10 1719 vcse2.company.com
_h323ls._udp.company.com 86400 IN SRV 10 10 1719 video.company.com
_h323cs._tcp.company.com 86400 IN SRV 10 10 1720 vcse1.company.com
_h323cs._tcp.company.com 86400 IN SRV 10 10 1720 vcse2.company.com
I assume we need "_h323cs._tcp.company.com 86400 IN SRV 10 10 1720 video.company.com" as well?
DNS A records:
vcse1.company.com pointing to vcse1 IP address
vcse2.company.com pointing to vcse2 IP address
video.company.com pointing to vcse1 IP address
I assume we need another DNS A record for "video.company.com", pointing to vcse2 IP address?
Is there anything else missing?
You could do it a few different ways.
Option 1: Rely on SRV priority and weight to distribute calls to your VCS cluster.
Option 2: Rely on DNS Round Robin to distribute calls to your VCS cluster.
Whatever domain your endpoint is registered with (ie: firstname.lastname@example.org), is the domain your SRV records should use.
If your endpoints are registered as email@example.com, and someone dials firstname.lastname@example.org, the call will fail, even if you did have SRV records in place for video.company.com. This is because the domain the endpoint is registered to your VCS with is company.com and not video.company.com.
Further to what Patrick has said, your best bet is to either use a subdomain for everything - e.g. SRVs and SIP registrations for video.company.com, or use your root domain for everything - e.g. SIP registrations and SRVs for company.com.
Remember - your cluster FQDN can be company.com even if the 'A' record for company.com points to something completely different. You just need SRVs for company.com pointing to your different services (SIP etc).