12-17-2013 05:36 AM - edited 03-17-2019 03:48 PM
All,
Imagine a scenario, where company xyz is having 3 seperate local CUCM clusters for each of their 3 sites, and each have its own unique CUPS cluster. But they have a single AD domain xyz.com.
Presence users in all 3 clusters use the same xyz.com domain. Now they want their users to be able to log in from public internet, using Jabber Windows, and want to guide the signalling to the right CUCM-IMP cluster using DNS/SRV. Please suggest a plan for this. Im unsure if they are using 8.x or 9.x cluster, but I assume it would be 9.x. Also J4W would be 9.2.6. Please provide your ideas to design this.
Thanks in advance.
12-17-2013 07:13 PM
There are two pieces to this: inter-cluster peering and collaboration edge.
Inter-Cluster Peering is used to mesh the three clusters into one logical solution. Lucky for you, the major prerequisite of all clusters being in the same presence domain has already done.
Then there is how to get Jabber to work from outside the firewall. Exposing the IM&P cluster to the Internet is not recommended for a few reasons: 1) the BU didn't intend the cluster to be hardened for direct exposure to the Internet; and, 2) it doesn't support NAT between the client and the server; and, 3) there are a lot of ports used by the client, requiring a lot of exposure on the firewall. In other words, the cluster must be on the inside trusted network. You have two options:
Please remember to rate helpful responses and identify helpful or correct answers.
12-17-2013 07:13 PM
I guess the requirement that significantly complicates things is, the use of DNS/SRV records.
without it, the jabber clients can log into any of 3 presence clusters manually (or packaging the jabber client software), and from there would get the CUCM it was to use.
To be honest, I am not aware of a way to use SRV records and still have clients automatically log onto potentially 3 different CUPS clusters, with any other form of disctinction.
Log in from the internet; use Collaboration edge; Cisco's-cure-all with no release date
=============================
Please remember to rate useful posts, by clicking on the stars below.
=============================
12-17-2013 07:25 PM
I guess the requirement that significantly complicates things is, the use of DNS/SRV records.
This isn't a problem. The SRV record is just an auto-discovery record. The client is redirected to it's home cluster and assigned node after doing the lookup. This assignment is stored in the local cache so you don't have to rely on this every time every a user starts the application either.
I typically recommend customers use a priority and/or weighting similar to how they setup MX records. Perhaps the biggest cluster with geographic redundancy is priority 10 with each of the other clusters being at priority 20 just in case the WAN is segmented. If you have a good DNS server (read: not Microsoft) or global load balancer it might even be able to shape the SRV query results based on the specific DNS server queried or source IP address of the query.
Here's an example:
_cuplogin._tcp.example.com. 86400 IN SRV 10 50 8443 clusterA-pub.example.com.
_cuplogin._tcp.example.com. 86400 IN SRV 10 50 8443 clusterA-sub.example.com.
_cuplogin._tcp.example.com. 86400 IN SRV 20 25 8443 clusterB-pub.example.com.
_cuplogin._tcp.example.com. 86400 IN SRV 20 25 8443 clusterB-sub.example.com.
_cuplogin._tcp.example.com. 86400 IN SRV 20 25 8443 clusterC-pub.example.com.
_cuplogin._tcp.example.com. 86400 IN SRV 20 25 8443 clusterC-sub.example.com.
http://en.wikipedia.org/wiki/SRV_record
Please remember to rate helpful responses and identify helpful or correct answers.
12-19-2013 08:05 PM
Jonathan/Dennis,
Thank you so much for the inputs. I will go through them, and provide you a summary on this issue once i fix it
04-06-2014 11:30 AM
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