LDAP Timeout / Disconnect from UCM

Unanswered Question
Jun 25th, 2008

Has anyone had an instance where CallManager (ver. 6.1) has aborted an LDAP sync and erased all the LDAP users from its database?

During the latest sync, our LDAP server had this error in its logs:

"Server failed to flush BER data back to client -"

And in doing research the server will display this error if the client closes the connection before the server is done sending data to it. As a result, this seemingly caused the sync to abort and all the LDAP End Users to be unavailable from CallManager. I had to perform a re-sync for them to appear again (without device associations, RDPs, etc. -- which I had to redo b/c of an unknowing backup that had failed).

This is the first time this has occurred and seems to be the result of the a massive purge of nearly 10,000 accounts in LDAP. Is there any configurable setting that I can change within CallManager to increase the timeout value? I'm hoping I won't get burned by this the next time we have a purge.

Thanks.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
gogasca Wed, 06/25/2008 - 20:40

Hi Craig,

What is the exact CCM version and LDAP server (AD, Iplanet..etc) ?

Could you please upload the dirsyn logs

This seems to be very critical

craig.pollitt Tue, 07/01/2008 - 09:24

I used the RTMT and fumbled my way around until I think I have what you are looking for. Take a look at the attached file, I've bolded where I believe the issue first started to appear.

Let me know what you think.

Thanks,

Craig L. Pollitt

rtmt

ldap

error

Attachment: 
gogasca Tue, 07/01/2008 - 10:10

Hi Craig,

2008-06-22 22:00:20,111 ERROR [DSLDAPSyncImpl(879a6223-bb24-cf76-1cc9-5c2c2134335b)] ldapplugable.DSLDAPSyncImpl (DSLDAPSyncImpl.java:343) - LDAPSync(879a6223-bb24-cf76-1cc9-5c2c2134335b)[Run] SizeLimit configured in directory is less than the number of \

results retrieved. Cannot continue.\

2008-06-22 22:00:20,113 INFO [DSLDAPSyncImpl(879a6223-bb24-cf76-1cc9-5c2c2134335b)] ldapplugable.DSLDAPSyncImpl \

(DSLDAPSyncImpl.java:852) - LDAPSync(879a6223-bb24-cf76-1cc9-5c2c2134335b)[LDAPFullSync] Caught SizeLimitExceededException\

2008-06-22 22:00:20,110 ERROR

This seems to be a problem related to the sizelimit in LDAP server

Looks similar to CSCsk09658

Could you please confirm that you are using Netscape Directory.

To check the size limit for ND,

1.Goto ND console page click the Directory Button.

2.Select config ,right click, advance properties.

3.In properties set the nssldap Sizelimit.

This value needs to be larger than number if users retrieved in LDAP synch/search

Found also

172.30.22.26:389 is not reachable

2008-06-23 02:00:03,204 ERROR [DSLDAPSyncImpl(bd510e3f-52fe-cbe6-78ab-46c79522e029)] ldapplugable.DSLDAPSyncImpl \

(DSLDAPSyncImpl.java:799) - LDAPSync(bd510e3f-52fe-cbe6-78ab-46c79522e029)[makeConnection] Failed LDAP connection to : ldap://172.30.22.26:389

Also found CSCsm87556 /CSCsh68147 which may be related if LDAP search is set to root

craig.pollitt Tue, 07/01/2008 - 10:42

I was unable to view CSCsk09658...only Cisco employees allowed. But we are using a Sun One directory server. I will run that setting by our LDAP admin to see what it's currently set for and if it needs changed.

The other two bugs you have listed do not pertain to our setup since we're using a specific OU to sync up with, not the root directory.

The question I have is why did it all the sudden error out when it had been performing syncs for the last few weeks without a problem? And when it did error out, why did it wipe out all the LDAP accounts within UCM (not to mention all their device associations, permissions, etc)?

Thanks again for your help.

craig.pollitt Wed, 07/02/2008 - 04:49

We were wondering if it was possible to customize the search filter, not the search base? It would be better if we didn't have to sync the entire directory every time, but only active users.

Also, the problem also may be attributed to hitting another server we had in our LDAP list, one that is configured to have a limit. I have since removed it from the list entirely since we will never use it for this purpose, but I can't see anything in the dirsync logs that would verify this.

Actions

This Discussion