10-27-2011 12:09 AM - edited 03-17-2019 10:34 PM
Hi,
I have created a DNS SRV for configure in the FQDN of the VCS Cluster.
The problem is when the Devices try to register to the VCS Cluster; I put in the endpoints, in the part of Gatekeeper Registration the DNS or the IP of the DNS SRV but the always the endpoints never reach the VCS CLuster.
I check the logs in DNS SRV and I don't see any request from devices.
I think that I have to create a virtual IP address with DNS with Load balancer, I mean: IP/DNS(FQDN) for Cluster with load balance and when the devices trying to connect to IP/DNS of the cluster this send the request to one IP or hostname of the one peer of the cluster.
DNS CLuster
23.1.0.201 (vcs.xxx)
Peer of the cluster:
23.1.0.32 (vcscontroltc.xxx) Master
23.1.0.33(vcscontrolvag.xxx) Slave
xxx--> domain
Is it correct?
Thanks in advance.
Best regards.
Solved! Go to Solution.
10-31-2011 07:16 AM
Hi,
so 23.1.0.201 is the IP address of your DNS server?
The way you should set this up is:
Cluster FQDN: vcscluster.domain.local
VCS peer A: vcscontroltc.domain.local
VCS peer B: vcscontrolvag.domain.local
With the above assumptions, this is what you create in DNS:
- For the cluster FQDN, create two A-records for vcscluster.domain.local, one pointing to 23.1.0.32 and one pointing to 23.1.0.33. With this I recommend you enable round robin on your DNS server.
- For each peer, create an A-record, so vcscontroltc.domain.local points to 23.1.0.32 and vcscontrolvag.domain.local points to 23.0.1.33.
- Create SIP and H323 SRV records for vcscluster.domain.local. With this I recommend that you create two SRV records for each service, one pointing to peer A and one pointing to peer B, with equal priority and weight. For example:
_sips._tcp.vcscluster.domain.local -> vcscontroltc.domain.local, priority 1, weight 50
_sips._tcp.vcscluster.domain.local -> vcscontrolvag.domain.local, priority 1, weight 50
If you follow the advise above, you should be able to configure all of your internal SIP and H323 endpoints with an H323 gatekeeper address/SIP proxy address of vcscluster.domain.local and the endpoints should register to one of the peers, regardless of whether the endpoints supports DNS SRV or not.
If the domain you are using is public, you also want to add SRV records directly for this domain name. These SRV records should point to your VCS Expressway, to ensure that inbound URI calls are working as they should. For example:
_sips._tcp.domain.local -> vcse.domain.local, priority 1, weight 100
If you have multiple VCS-E's you need to adjust the SRV records accordingly.
Hope this helps,
Andreas
10-27-2011 11:50 PM
Here you can see the DNS lookup in VCS control:
And from my computer all the servicer are active but the DNS doesn't receive any erquest:
Thanks.
Best regards.
10-28-2011 01:15 PM
To be honest I do not really understand your question (especially the virtual IP and the "DNS Cluster", but here some remarks:
* you did not mention what kind of endpoint is used. The way on how it uses SRV might even be dependnet on the software version. If you use the latest software on a Cisco TP (SW: MXP, TC, TE) endpoint you shall be fine
* you resolv _h323rs, but AFAIK this is not used by MXP, TC, TE systems, but If I understood it you tested the other services like _h323cs as well, that would be ok
* the dns request will most likely be cached, this can happen on the device but also on the DNS server, so you might not see an ip
* to see clear, I would flush the dns cache or reboot the system and do a network trace + analyzing the logs of the device.
What I would set up:
If you specified vcs-cluster.domain.example as the cluster name
and your VCSs are 198.51.100.11 and 198.51.100.12 :
A Records (RR) for vcsc-cluster.domain.example pointing to 198.51.100.11 and 198.51.100.12
an A Record for vcsc1.domain.example pointing to 198.51.100.11 and
an A Record for vcsc2.domain.example pointing to 198.51.100.12
SRV records (_h323ls._udp, _h323cs._tcp, _sips._tcp _sip._tcp (and if you need it for specific devices _sip._udp and _h323rs._udp, ...) for vcs-cluster.domain.example pointing to vcsc1.domain.example and vcsc2.domain.example most likeley with the same priority and weight.
If some 3rd party devices have trouble with the mix of RR-A and SRV records you can also add additional ones
like: vcsc-cluster-a.domain.example with just RR-A and vcsc-cluster-srv.domain.example just with the SRV records. In addition I would add SRV records to domian.example as well.
If these devices do not like a cluster at all you can also point them to the IP, the vcs1/2 A record or create what ever it needs.
Cisco TP endpoints (MXP/TC/TE/Movi) shall work fine with vcs-cluster.domain.example as the sip proxy,
h323 gk, vcs, ...
Good luck,
Martin
Please vote the replies and set the message to answered if it is.
Please remember to rate helpful responses and identify
10-29-2011 03:06 PM
Matrin is spot on here (+5 M.). You definitely want both the SRV and RR records, particularly if you are using endpoints from various vendors. I attempted to capture an example of this here:
http://www.netcraftsmen.net/resources/technical-articles/953-registrationvcsclustering.html
HTH.
Regards,
Bill
Please remember to rate helpful responses and identify
10-31-2011 03:49 AM
I mean,
I created a DNS SRV and DNS with load balancing.
The devices which are goint to use are: Polycom HDX, VSX, PVX, Viewstation, Cisco C20, MXP,...of multiples vendor.
The others services of DNS SRV are working fine.
The Tandberg C20 with the DNS of gatekeeper is working fine and registered with one of the VCS Control.
With PVX and Polycom HDX, I am having issues with the registration, never they reach the Gatekeeper. What can I do?
I capture the packets with Wireshark and I could see that the H225.0 packets go out to reach the Gatekeeper address but the Gatekeeper never answer.
I am not using this SRV:
323be | Border Element | H.323 entity supporting communications as defined in Annex G/ H.225.0 |
Have I to configure it?
Thanks in advance.
10-31-2011 05:26 AM
Hi,
could you explain why the cluster FQDN points to 23.1.0.201, while the peer addresses are 23.1.0.32 and .33? What device exactly is assigned with the IP address 23.1.0.201? Is this a hardware load balancer?
The cluster FQDN should consist of multiple DNS A-records, each pointing to a peer in your cluster, but here you seem to bring a third address into the mix (.201), which is confusing.
Regards
Andreas
10-31-2011 07:02 AM
Hi,
The DNS is vcs.xxx with IP address 23.1.0.201 and the peers are 23.1.0.32 and 33.
In a first step I created a DNS (vcs.xxx) for IP address 23.1.0.201 and I configured the SRVs for this DNS.
The second step was create a Load Balancer for this DNS point to 23.1.0.32 and 33.
Do you say to create a FQDN point to 23.1.0.32 and 33 without IP address 23.1.0.201?
I created this to configure in Endpoints the DNS or the IP address either.
10-31-2011 07:16 AM
Hi,
so 23.1.0.201 is the IP address of your DNS server?
The way you should set this up is:
Cluster FQDN: vcscluster.domain.local
VCS peer A: vcscontroltc.domain.local
VCS peer B: vcscontrolvag.domain.local
With the above assumptions, this is what you create in DNS:
- For the cluster FQDN, create two A-records for vcscluster.domain.local, one pointing to 23.1.0.32 and one pointing to 23.1.0.33. With this I recommend you enable round robin on your DNS server.
- For each peer, create an A-record, so vcscontroltc.domain.local points to 23.1.0.32 and vcscontrolvag.domain.local points to 23.0.1.33.
- Create SIP and H323 SRV records for vcscluster.domain.local. With this I recommend that you create two SRV records for each service, one pointing to peer A and one pointing to peer B, with equal priority and weight. For example:
_sips._tcp.vcscluster.domain.local -> vcscontroltc.domain.local, priority 1, weight 50
_sips._tcp.vcscluster.domain.local -> vcscontrolvag.domain.local, priority 1, weight 50
If you follow the advise above, you should be able to configure all of your internal SIP and H323 endpoints with an H323 gatekeeper address/SIP proxy address of vcscluster.domain.local and the endpoints should register to one of the peers, regardless of whether the endpoints supports DNS SRV or not.
If the domain you are using is public, you also want to add SRV records directly for this domain name. These SRV records should point to your VCS Expressway, to ensure that inbound URI calls are working as they should. For example:
_sips._tcp.domain.local -> vcse.domain.local, priority 1, weight 100
If you have multiple VCS-E's you need to adjust the SRV records accordingly.
Hope this helps,
Andreas
10-31-2011 07:25 AM
OK. Thanks you very much.
I will try this.
I will advice you with the results.
Best regards.
11-02-2011 03:48 AM
Hola Miguel, soy Elter. ¿Que tal?
Si quieres podemos ayudarte en las configuraciones del Cluster.
Cuidado que el retraso entre los peers debe de ser bajo (<15ms one-way) y el registro apunta al nombre del cluster.
Este nombre de Cluster no debe tener una IP, el haz un balanceo basado en SRV Records (o sea, no tiene una IP) o round robin por A Record.
Para que la redundancia sea automatica, en H.323 los endpoints deben soportar Alternate GK y en SIP deben soportar Outbound.
Hay zonas especiales para cluster y algunos comportamientos/licencias cambian.
Saludos
El mensaje fue editado por: Elter Picolo
11-02-2011 04:30 AM
Hola Elter,
¿qué tal?
No te preocupes ya lo tengo configurado y está en producción ahora mismo. Ayer estuve realizando numerosas pruebas y ya está todo ok.
El problema lo tenía con el DNS pero ya está también configurado y funcionando perfectamente. ya puedo registrar todos los Endpoints con el DNS del Cluster, tanto los Cisco, Tandberg, Polycom,...
Gracias.
Un saludo.
11-02-2011 04:34 AM
Hi Andreas,
The DNS department has configured the CLuster FQDN correctly and now I can register third party Endpoints in the VCS Cluster.
The cluster is configured correctly and working fine.
Thanks.
Best regards.
04-17-2012 02:46 PM
Hi,
I'm configuring a 2 server VCS cluster for the first time and have a doubt:
I think I understand the configuration for the Cluster, but wanted to double check anyway.
Also, do I need to configure SRV records for the Peers as well or just A records?
This is my config:
Cluster name: vcsc.video.company com
Peers: vcsc1.video.company.com
vcsc2.video.company.com
Cluster SRV records:
_h323cs._tcp.vcsc.video.company.com
_H323ls._udp.vcsc.video.company.com
__H323rs._udp.vcsc.video.company.com
_sip._tcp.vcsc.video.company.com
_sips._tcp.vcsc.video.company.com
_sips._tls.vcsc.video.company.com
with target: vcsc1.video.company.com
and another similar set with target: vcsc2.video.company.com
Do this looks ok. so far?
For each of the Peers, do I need something like this?:
_h323cs._tcp.vcsc.video.company.com
or perhaps:
_h323cs._tcp.video.company.com
or no need for this type of records?
Thanks in advance
04-17-2012 03:22 PM
That looks pretty close. Some thoughts:
_sips._tls.
Anyway, I am thinking you can ditch the _sips._tls.
I am not sure I follow your line of questioning that starts: "For each of the Peers, do I need something like this?"
On a related topic, the SRV records you have provided would be used for registration. Endpoints that supported SRV can be provisioned with a gatekeeper (h323) or SIP proxy (SIP) of vcsc.video.company.com and be in business. Thus allowing your DNS infrastructure provide fault tolerance, load balancing, etc.
You still need to account for URI dialing to your domain, which may be a different set of SRV records. So, if you had SIP endpoints registering as myendpoint.movi@video.company.com and you wanted external entities to be able to establish a video call to this alias, you would need an SRV record like:
_sips._tls.video.company.com. -> vcsc1.video.company.com
_sips._tls.video.company.com. -> vcsc2.video.company.com
You may also need NAPTR records, depending on the capabilities of endpoints trying to contact you. Though, I don't think this is required. The VCS, for example, will try to use NAPTR records when resolving an unknown URI suffix but will fallback to SRV smoothly.
For H.323, URI dialing requires that the calling endpoint support H.323v5 Annex O. You would also need the _h323ls._udp.
HTH.
Regards,
Bill
Please remember to rate helpful responses and identify
04-18-2012 06:22 AM
Hi Bill,
Thanks for your response.
I'm running VCS version 7.0.3 and my endpoints are mainly C-Series and MXP6000, but there are still some older SetTops, Classic and MX units.
In regards to my question:
"For each of the Peers, do I need something like this?:
_h323cs._tcp.vcsc.video.company.com
or perhaps:
_h323cs._tcp.video.company.com
or no need for this type of records?"
I'm trying to determine:
1) if I need to configure SRV records for the individual VCS servers (Master and Peer). In this thread is mentioned that these would need A records but no mention to SRV records.
2) if yes 1) to make sure I request correctly the configuration of those SRV recs. to my DNS group.
I think you answered yes to 1) when you say:
" You still need to account for URI dialing to your domain, which may be a different set of SRV records. So, if you had SIP endpoints registering asmyendpoint.movi@video.company.com and you wanted external entities to be able to establish a video call to this alias, you would need an SRV record like:
_sips._tls.video.company.com. -> vcsc1.video.company.com
_sips._tls.video.company.com. -> vcsc2.video.company.com "
I do have Movi users registering as you indicate above, but the examples you give for the SRV records, are those for the individual VCS (master and Peer) ? and , is that the way I should request to be configured from my DNS people?
Thanks again
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide