This document explains how CNR detects LDAP request failures.
There are no specific requirements for this document.
The information in this document is based on all current versions of
The information in this document was created from the devices in a
specific lab environment. All of the devices used in this document started with
a cleared (default) configuration. If your network is live, make sure that you
understand the potential impact of any command.
For more information on document conventions, refer to the
Technical Tips Conventions.
The CNR LDAP facility is multithreaded. Each CNR LDAP object has a
configurable number of connections associated with it. CNR creates one thread
for each connection configured in a CNR LDAP object. Each thread can have a
maximum of max-requests LDAP requests associated with its request queue.
Each LDAP request is initiated synchronously, but the results come back
Thread A starts with zero items in its request
Thread A receives an LDAP request from the DHCP server, while it
processes DISCOVER, REQUEST, and so on.
Thread A initiates an LDAP query, update, or
The LDAP server sends a return code to indicate that it has accepted
the lookup request (the return code is not the actual query, update, or create
result). If CNR does not hear from the LDAP server, it marks the LDAP
connection as inactive, starts a timer to keep track of reactivate-interval,
and attempts to reconnect to LDAP at a later time.
Thread A puts the request and the return code into its request queue,
and marks the request as pending (that is, awaiting results from the LDAP
Thread A checks to see if there are any results from the LDAP
If there is a result, CNR removes the corresponding request from the
queue. CNR repeats this process for all available results from the LDAP
After CNR has processed all the available requests, if there are any
requests in the queue that are past the timeout period, it reschedules or drops
those LDAP requests. Whether CNR drops or reschedules an LDAP request depends
on the request type (LDAP query, update, or create) and whether there are any
other LDAP servers available, such as round robin or failover LDAP
Thread A waits for the threadwaittime interval
and repeats the process from Step 2.
If, at any time between Step 2 and Step 8, the LDAP server is declared
to be down, CNR flushes all of the queued requests associated with the LDAP
object threads. The LDAP object then waits for the reactivate-interval time
period to pass before it attempts to reestablish a connection with that LDAP
If the first LDAP server has been declared down, CNR checks to see if
there is a second LDAP server object that has been configured as an LDAP
failover server. If there is a second LDAP server object, CNR sends requests to
that LDAP server.
This table lists parameters relevant to the discussion above. For more
information about how to set these parameters, refer to the
Registrar 5.0 CLI Reference Guide.
CNR LDAP Object Property
The interval CNR waits before it attempts to reestablish a
connection with an LDAP server that is down.
The interval (in milliseconds) at which each LDAP client
connection polls for results, if it has outstanding queries or
The time an LDAP request remains on a connection queue before it
is declared stale and times out.