Mailing List Archive

Jabber connecting to global catalog servers across slow wan links
Observed with Jabber 12.5 and 12.6.1 (Windows, on Prem IM&P 12.5)

I have a customer with a large WAN with many sites and data centers. We're
using the default auto-discovery for Windows clients to allow a Jabber on a
Domain-joined Windows workstation to find and select a global catalog
server.

Not using UDS on the service profile. Jabber 12.5 and 12.6 GSSAPI
auto-discovery LDAP.

Jabber clients that are configured for the default Cisco Directory
Integration (CDI) and using the autodiscovery process are performing a
lookup for *_gc._tcp.domain.com <http://tcp.domain.com>* .

What we're seeing is that DNS SRV replies for *_gc._tcp.domain.com
<http://tcp.domain.com>* . return a list of many servers with equal weight
and priority. (17 at current count) Some of the servers have 150-300 ms
ping times based on where the Jabber client is.

It's not feasible to adjust these weighs since you'd want Jabber clients in
a remote site to use a "close" GC server. Adjusting priority on DNS SRV
records is not granular enough as it doesn’t account for the location of
the client making the request.

I spoke to the customer about this and he informed that a native Windows
process running on workstation (Like a Windows Login) doesn't do simple SRV
lookup, but makes an API call to something called "*DC Locator*" This will
return a list to the Windows client based on the AD Sites and Network
topology. It's supposed to return the "closest" resource to the client
based on its current network subnet. A simple DNS SRV request won't do
this. Basically a SRV lookup is performed but adding in the <site> string
into the FQDN. Getting that Site returned is the key part to find the
"closest" GC servers to the client. (See the links below for some
background)

*Cisco should be utilizing this on Windows*. Implementing the
*DsGetDcName* call API from the MS Locator function to find the best GC
server to connect to .

I know I could utilize a *jabber-config.xml* file option to specify
*PrimaryServerName* and *SecondaryServerName.* But these values can't be
correct for all users at all sites, and there is only a primary and
secondary. This is why good AD design calls for placing Domain Controllers
/ LDAP / GC across the WAN sites close to the users.

Below are a few links on the subject. Some are quite old but this
function hadn't really changed much in 15+ years.

Cisco should be utilizing this on Windows. Implementing the *DsGetDcName* call
API from the DC Locator function to find the best GC server to connect to .

If this function doesn’t return anything , then perform what it's doing
today.

Not sure if it’s a windows only thing. I doubt MAC implements it but you
never know.

Has anyone else run into this issue ?

https://searchwindowsserver.techtarget.com/tip/How-the-DC-locator-works-in-Active-Directory

http://adcoding.com/using-dsgetdcname-in-c-sample/


https://ldapwiki.com/wiki/How%20Domain%20Controllers%20Are%20Located%20in%20Windows