<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#404040;
font-weight:normal;
font-style:normal;
text-decoration:none none;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#404040">Nice find, Anthony, and a good read.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#404040"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#404040">A while back I worked a case where LDAP synchronizations would not complete when the synchronize button was pressed by the customer. While looking into it, I
found it interesting that CUCM would attempt A-record resolution on *<b>all</b>* FQDN server entries before starting the sync task (scheduled and forced), and now it makes even more sense if you’re seeing a three-way TCP handshake and bind request across the
board. Seems like CUCM is using the same entry-by-entry verification steps built into a simple click of “Save” during every directory sync job.<o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black"><o:p> </o:p></span></b></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#404040"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> cisco-voip [mailto:cisco-voip-bounces@puck.nether.net]
<b>On Behalf Of </b>Anthony Holloway<br>
<b>Sent:</b> Friday, August 05, 2016 9:51 AM<br>
<b>To:</b> Cisco VoIP Group <cisco-voip@puck.nether.net><br>
<b>Subject:</b> Re: [cisco-voip] CUCM LDAP Authentication Redundancy<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">I'll also add that a "show open ports" on the publisher CLI does show the TCP socket switching to a new port every so often, so my theory as to why it was hanging on to this server is squashed. I should have thought about the life span
of a TCP session, before making that hypothesis.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Fri, Aug 5, 2016 at 8:34 AM, Anthony Holloway <<a href="mailto:avholloway+cisco-voip@gmail.com" target="_blank">avholloway+cisco-voip@gmail.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">Something small to note for you layer 4 geeks out there.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">When CUCM initiates a Directory Sync, a packet capture shows the pub going through a TCP three-way handshake with each of the LDAP servers, in order I might add, and also initiating a simple bind request to each one, finally settling on
performing the search request on the first LDAP server.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">When CUCM initiates an Authentication, a packet capture shows the pub not going through a TCP three-way handshake, but instead, using an already open TCP connection. Perhaps the CUCM Auth code is written this way because authentication
requests are more frequent than dir sync, and so it saves on overhead to reuse a connection rather than setup/teardown connections for each request. That might explain why she's stuck using that one server, but of course it doesn't explain why it started
using that one server to begin with.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Thu, Aug 4, 2016 at 12:59 PM, Anthony Holloway <<a href="mailto:avholloway+cisco-voip@gmail.com" target="_blank">avholloway+cisco-voip@gmail.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">All,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I'm working on an issue where my CUCM 11.0 system is configured with 3 LDAP servers under LDAP Authentication AND LDAP Directory.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">What I'm see is, for packet captures of CUCM when a login attempt is made, the CUCM server sends the BIND request to the last server in the list of three servers. However, when performing a directory sync, CUCM server sends the requests
to the first server in the list.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I'm trying to read up on what the expected behavior is, as I've always thought of it as top = primary; middle = secondary; bottom = tertiary. In fact, a few years ago there was an issue with CAD logins, when the primary server was unreachable
and CAD would timeout before CUCM tried the secondary server.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The SRND is no help with only the following passage:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><b><i>High Availability</i></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><i>Unified CM LDAP Synchronization allows for the configuration of up to three redundant LDAP servers for each directory synchronization agreement.
<span style="background:#FFF2CC">Unified CM LDAP Authentication allows for the configuration of up to three redundant LDAP servers for a single authentication agreement.</span> You should configure a minimum of two LDAP servers for redundancy. The LDAP servers
can be configured with IP addresses instead of host names to eliminate dependencies on Domain Name System (DNS) availability.</i><o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Source: <a href="http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab11/collab11/directry.html?bookSearch=true#pgfId-1085451" target="_blank">
CUCM 11.0 SRND</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">So, what do you know, or what can you share, that states one way or the other, why CUCM might use a server in the listing, other than the first one, assuming the first server is healthy and accessible?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I did search the bug toolkit and didn't see any defects matching this scenario.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks.<o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>