Guest

Cisco Network Registrar

Cisco Network Registrar (CNR) Failure Detection Using Lightweight Directory Access Protocol (LDAP)

Document ID: 13393

Updated: Oct 26, 2005

   Print

Introduction

This document explains how CNR detects LDAP request failures.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

The information in this document is based on all current versions of CNR.

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.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Background Information

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.

The Failure Detection Process

Each LDAP request is initiated synchronously, but the results come back asynchronously.

For example:

  1. Thread A starts with zero items in its request queue.

  2. Thread A receives an LDAP request from the DHCP server, while it processes DISCOVER, REQUEST, and so on.

  3. Thread A initiates an LDAP query, update, or create.

  4. 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.

  5. 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 server).

  6. Thread A checks to see if there are any results from the LDAP server.

  7. If there is a result, CNR removes the corresponding request from the queue. CNR repeats this process for all available results from the LDAP server.

  8. 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 servers.

  9. 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 server.

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.

Related Parameters

This table lists parameters relevant to the discussion above. For more information about how to set these parameters, refer to the Network Registrar 5.0 CLI Reference Guide.

CNR LDAP Object Property Description
reactivate-interval The interval CNR waits before it attempts to reestablish a connection with an LDAP server that is down.
threadwaittime The interval (in milliseconds) at which each LDAP client connection polls for results, if it has outstanding queries or updates.
timeout The time an LDAP request remains on a connection queue before it is declared stale and times out.

Related Information

Updated: Oct 26, 2005
Document ID: 13393