LDAP requests MaxPoolThreads
The problem that can arise from this can be explained as follows.
If the DC receives a name resolution request, it will take time to answer it, clearly.
A client can get up to 6 IP addresses with an activated IPv3 protocol. An IPv6 private (link-local), an IPv6 public and an IPv4 address.
If the client now makes a request to the DC, the DC (Netlogon) tries to assign the client to a subnet / site mapping first, this happens with the LDAP ping and the transmitted IP address of the client.
Netlogon is designed in such a way that if the subnet / site mapping cannot be determined using the LDAP ping, the client tries again with the NetBios name of the client. If a response comes back and the client's IP address could be assigned to a subnet / site mapping, everything is fine.
If this behavior occurs at peak times, other important LDAP requests will be answered with a delay. The whole thing is delayed because the pool (MaxPoolThreads) of LDAP requests is limited. And if Netlogon starts another attempt via the client's NetBios name, a thread from the limited LDAP pool is blocked until it is answered. Inquiries are piling up!
One solution would be to switch off NetBios over TCP / IP on the client's network card in order to avoid unnecessary traffic.
The real cause and solution is:
The trigger is that an IP segment has not been assigned to an Active Directory site. The solution to the problem now arises automatically.