Unsolved
This post is more than 5 years old
2 Intern
•
178 Posts
0
4260
Isilon - LDAP error LDAP servers in primary are offline. Authentication services may be interrupted.
We are frequently getting following LDAP error on all of our Isilon clusters.
[lsass] LDAP server (primary) does not support paged results. One FS requires one of the following server side controls: 1.2.840.113556.1.4.319 - LDAP simple paged results control, or 2.16.840.1.113730.3.4.9 - Virtual list view control 1.2.840.113556.1.4.47 - Server side sorting control. Enumerating Users and groups may not work as expected.
Any one experienced same issues ? Please suggest to get out of the issue.
markfoster1
22 Posts
0
September 10th, 2014 13:00
Other than observation of the error message, is there an actual problem?
Could you provide the OneFS version and LDAP server details (software, version, platform). I know Isilon made a recent change to how VLV is handled and they tested against numerous LDAP servers all of which supported either VLV or SSS.
Anonymous User
170 Posts
0
September 11th, 2014 09:00
One of common issues with LDAP has a root cause in DNS. Make sure that *every* node in your cluster can reach the DNS and LDAP servers. If you have 1 bad NIC in a single node and it can't reach the LDAP servers, it's enough to make bad things happen.
khkris
2 Intern
2 Intern
•
178 Posts
0
November 13th, 2014 09:00
Currently we are on version 7.1.0.5. We are getting these alerts accross all clusters we are using. Some trigger around 15 to 20 alerts every day.
LDAP server is Open LDAP TDS.
Verified Connection to LDAP and DNS is active from all nodes.
Peter_Sero
1.2K Posts
1
November 13th, 2014 21:00
Sometimes Isilon nodes perform a large number of LDAP queries within a few seconds,
with chances of maxing out the TCP connection limit on the LDAP server side....
Use "netstat" to check TCP connections periodically on both sides.
What has helped us here was configuring the LDAP server to drop idle
connections after a short time (60s or so), which drastically reduced
the number of established connections (from all clients, not only Isilon)
at any given point in time.
hth
-- Peter
khkris
2 Intern
2 Intern
•
178 Posts
0
November 14th, 2014 09:00
Thank you.
Verified with LDAP team and they confirmed, connections are not maxing out. They are not seeing issues on any of the other components, except Isilon so far.
In on of connection failure scenario, Isilon hits LDAP server on ports 2389 & 53228 on one of the session, where Prior to socket being setup from, from Isilon cluster there was another connection to the same LDAP VDS server on the same ports. wait for the connection, and getting timed off.
Not sure why duplicate ports are being used by LDAP clients?
Peter_Sero
1.2K Posts
0
November 14th, 2014 12:00
Have you traced it down at packet level (tcpdump)?
khkris
2 Intern
2 Intern
•
178 Posts
0
November 14th, 2014 13:00
Yes, We did packet trace and network team analyzed from Wireshark
Peter_Sero
1.2K Posts
1
November 17th, 2014 00:00
53228 looks more like an outgoing port (randomly chosen).
If you see 53228 on the LDAP = destination side,
better share the packet trace with Isilon support...
-- Peter