VCS Cluster - FQDN and SRV Records

[Patrick Sparkman]

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
Where:
FQDN of VCS Expressway peer 1: vcse1.company.com
FQDN of VCS Expressway peer 2: vcse2.company.com
FQDN of VCS Expressway cluster: 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:

• FQDN for registrations and/or calls (video.domain.com)
  • _sips._tcp.video.domain.com. 86400 IN SRV 1 1 5061 vcsgw.domain.com.
• VCS Cluster FQDN (vcsgw.domain.com)
  • _sips._tcp.vcsgw.domain.com. 86400 IN SRV 1 1 5061 vcs-c1.domain.com. (VCS Peer1)
  • _sips._tcp.vcsgw.domain.com. 86400 IN SRV 1 1 5061 vcs-c1.domain.com. (VCS Peer2)

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.

Thanks!

[Zac Colton]

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

[Patrick Sparkman]

Zac -

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.

• In that case, would my example in the orginal post be somewhat correct, if our SIP domain is to be the same as our organization domain (seperate from the VCS-E FQDN)?  In that case it can't exactly resolve directly to the VCS-E cluster, instead the SIP domain would point to the cluster FQDN, and then from there resolve to the cluster peers.
• Or would the SIP domain point to the peers instead of the cluster FQDN?

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.

[Zac Colton]

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

[Patrick Sparkman]

Thanks Zac!

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!

[KY_]

Hi Everyone,

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 ?

Thanks

[Patrick Sparkman]

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:

• _sips._tcp.example.com. 86400 IN SRV 1 1 5061 expe1.example.com.
• _sips._tcp.example.com. 86400 IN SRV 1 1 5061 expe2.example.com.

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.

[KY_]

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:

https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/expressway/config_guide/X8-10/Cisco-Expressway-Cluster-Creation-and-Maintenance-Deployment-Guide-X8-10.pdf

Thanks

[Patrick Sparkman]

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.

[KY_]

 Patrik

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 ?

Thanks

[petark]

Hi Patrick,

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.

For:

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?

Thanks,

[Patrick Sparkman]

You could do it a few different ways.

Option 1: Rely on SRV priority and weight to distribute calls to your VCS cluster.

• _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
• vcse1.company.com pointing to vcse1 IP address
• vcse2.company.com pointing to vcse2 IP address

Option 2: Rely on DNS Round Robin to distribute calls to your VCS cluster.

• _sips._tcp.company.com 86400 IN SRV 10 10 5061 video.company.com
• video.company.com pointing to vcse1 IP address
• video.company.com pointing to vcse2 IP address

[petark]

What about cluster FQDN in option 1?
i.e. if DNS round robin is not an option.

What happens if someone dials video.company.com?

[Patrick Sparkman]

Whatever domain your endpoint is registered with (ie: petark@company.com), is the domain your SRV records should use.

If your endpoints are registered as petark@company.com, and someone dials petark@video.company.com, 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.

[Nick Halbert-Lillyman]

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).