<div dir="ltr">Something small to note for you layer 4 geeks out there.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 4, 2016 at 12:59 PM, Anthony Holloway <span dir="ltr"><<a href="mailto:avholloway+cisco-voip@gmail.com" target="_blank">avholloway+cisco-voip@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">All,<div><br></div><div>I'm working on an issue where my CUCM 11.0 system is configured with 3 LDAP servers under LDAP Authentication AND LDAP Directory.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>The SRND is no help with only the following passage:</div><div><br></div><div><div><i><b>High Availability</b></i></div><div><i>Unified CM LDAP Synchronization allows for the configuration of up to three redundant LDAP servers for each directory synchronization agreement. <span style="background-color:rgb(255,242,204)">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></div></div><div><i><br></i></div><div>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></div><div><br></div><div>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?</div><div><br></div><div>I did search the bug toolkit and didn't see any defects matching this scenario.</div><div><br></div><div>Thanks.</div></div>
</blockquote></div><br></div>