Event Warnung Netlogon 5807 fuer viele Clients hat seit W2k8 deutliche Auswirkungen
UPDATE 06.06.2014
Zu dieser Thematik gibt es für Windows Server 2008 R2 nun (also zweieinhalb Jahre später) ein Update der Netlogon.dll, mit dem man über eine DC Policy das Verhalten beeinflussen bzw. abstellen kann!
2922852 Update resolves a problem in which LDAP, Kerberos and DC locator responses are slow or time out with Windows
https://support.microsoft.com/kb/2922852/EN-US
Hallo, hier wieder einmal Rol mit einem Erfahrungsbericht aus einer Krise von letzter Woche.
Die Symptome waren hier unterschiedlichster Natur, Hänger in Outlook aber auch in der MMC “Active Directory Users and Computers” waren nur einige davon. Das Verhalten trat nur in der Hauptanmeldezeit zwischen 8:30 und 10:30 Uhr auf, verschwand dann auch wieder von selbst. Netzwerk Traces zeigten verlangsamte Ldap und Kerberos Antworten; die TCP Anfragen wurden zunächst von den DCs mit einem TCP Ack bestätigt, aber erst 3-5 Sekunden später wirklich beantwortet. Die UDP Ldap “Pings” der Clients, um einen Netlogon Anmeldeserver zu finden (DC Locator, siehe auch “Types of Locators - Microsoft TechNet: Resources for IT Professionals, https://technet.microsoft.com/en-us/library/cc978019.aspx), wurden einfach nur verzögert beantwortet. Anderer Protokollverkehr wie MSRPC, wurde hingegen sehr schnell abgearbeitet. Gleichzeitig zeigten die DC keine offensichtlichen Überlastungswerte, wie hohe LSASS CPU Werte oder hohe Ldap Search Response Werte.
Bei dem betroffenen Kunden wird ein Cross-Forest Trust eingesetzt, bei dem alle Clients aus einem Account-Forest auf (primär Exchange) Dienste in einem Ressource-Forest zugreifen. Da die Client IP Adressen und Subnetze nicht im Ressource-Forest erfaßt und Sites zugeordnet waren, wurde alle 4 Stunden die entsprechende Warnung Netlogon 5807 am Ressource-Forest DC ausgegeben. Interessant ist natürlich die enorme Anzahl von Verbindungen die hier angezeigt werden:
Event Type: Warning
Event Source: NETLOGON
Event Category: None
Event ID: 5807 User: N/A
Computer: <MyW2k8R2DC1>
Description:
During the past 4.23 hours there have been 123450 connections to this Domain Controller from client machines whose IP addresses don't map to any of the existing sites in the enterprise. Those clients, therefore, have undefined sites and may connect to any Domain Controller including those that are in far distant locations from the clients. A client's site is determined by the mapping of its subnet to one of the existing sites. To move the above clients to one of the sites, please consider creating subnet object(s) covering the above IP addresses with mapping to one of the existing sites. The names and IP addresses of the clients in question have been logged on this computer in the following log file '%SystemRoot%\debug\netlogon.log' and, potentially, in the log file '%SystemRoot%\debug\netlogon.bak' created if the former log becomes full. The log(s) may contain additional unrelated debugging information. To filter out the needed information, please search for lines which contain text 'NO_CLIENT_SITE:' . The first word after this string is the client name and the second word is the client IP address. The maximum size of the log(s) is controlled by the following registry DWORD value 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\LogFileMaxSize'; the default is 20000000 bytes. The current maximum size is 20000000 bytes. To set a different maximum size, create the above registry value and set the desired maximum size in bytes.
Vor nicht all zu langer Zeit hatte der Kunde von W2k3 auf W2k8R2 “upgegraded”. Unter W2k3 hatte er auch obige Events 5807, ober ohne jede Auswirkung.
Neues Verhalten von Netlogon seit W2k8:
Mit der Einführung von IPv6 kann ein Client drei IP Adressen haben, eine IPv4, eine IPv6 Private (Link-Local) und eine IPv6 Public Adresse. Das Verhalten von Netlogon wurde mit W2k8 so verändert, daß der DC, wenn er zunächst beim Ldap Ping für die IP Adresse des Clients keine Subnet/Site-Mapping hat, nochmals Namensauflösung mit dem Netbios Namen des Clients vornimmt. Kommt dabei dann eine Adresse heraus, für die doch ein Subnet Zuordnung vorliegt, gibt er dem Client den entsprechenden Sitenamen zurück. Das Verhalten ist per default aktiv und kann nicht abgestellt werden.
Warum kann das jetzt zu einem Problem werden?
Das Problem ergibt sich aus dem Zusammenhang, daß der DC für die Namenauflösung Zeit benötigt. Beim Kunden waren die DCs als Node-Type “Hybrid” konfiguriert, machen also zunächst DNS-, dann WINS- und sogar noch NBT Broadcast Namensauflösung bis zum Ablaufen eines Timeouts. In dieser Zeitspanne belegt der Ldap Ping einen Thread, jedoch aus einem begrenzten Pool, der auch normale Ldap und Kerberos Anfragen bedienen muß. Der wird zum Engpass, wenn viele Clients genau das gleiche Verhalten auslösen. Das Client Retry-Verhalten, nach 0,5sec den Ldap Ping zu wiederholen und nach 1sec alle von DNS erhaltenen Ldap Server anzupingen, verschlimmert das ganze und macht es zu einem flächendeckenden Verzögerungs-Problem. Viele Applikationen kommen dann mit den verzögerten Ldap und Kerberos Antwort nicht zurecht und zeigen dann unterschiedlichste Fehlerbilder, die leider nur schwer Rückschlüsse auf die Ursache zulassen.
Eine der möglichen Auswirkungen schildert Kollege Steve Patrick sehr gut in seinem Blog,https://blogs.msdn.com/b/spatdsg/archive/2011/06/24/dc-fails-logons-or-experiences-ldap-timeouts.aspx, allerdings sind bei unserem betroffenen Kunden die Exchange Server in einer Child Domäne und die Root Domänen DCs hatten den Engpass, so daß die Exchange Server selbst keine entsprechenden Fehler zeigten.
Wie kann man den Fehler vermeiden?
Es ergeben sich nun genau drei Ansätze das Problem zu vermeiden. Diese lassen sich auch gut kombinieren und sollten helfen entsprechende Probleme komplett zu vermeiden.
- Zuordnung von Client IP Segmenten zu Subnet/Site Definitionen im Active Directory
- Erhöhung des Thread Pools für Ldap und Kerberos Anfragen
- Optimierung der DC Namensauflösung
Nun zu den Ansätzen im Detail:
1) Zuordnung von Client IP Segmenten zu Subnet/Site Definitionen im Active Directory
Wenn der mit dem Ldap Ping befragte W2k8/R2 DC auf Anhieb eine Zuordnung findet, ist er mindestens so schnell wie sein W2k3 Vorgänger und das Problem entsteht erst gar nicht. Das Event 5807 gibt schon sehr gut an, wie man seine IP Kandidaten ermitteln kann – indem man das Netlogon Log nach Einträgen mit “NO_CLIENT_SITE” durchsucht. Eine passende Subnet/Site Zuordnung für Clients wird seit Windows 2000 empfohlen und wird auch bei Qualitätsprüfungen durch Microsoft, Premier Kunden kennen das als ADRAP (Active Directory Risk Assessment Program), entsprechend angemahnt.
2) Erhöhung des Thread Pools für Ldap und Kerberos Anfragen
Der Thread Pool, der in obigen Scenario zum Engpass wurde, ist konfigurierbar und zwar als Ldap Policy “MaxPoolThreads” im AD, siehe “315071 How to view and set LDAP policy in Active Directory by using Ntdsutil.exe”, https://support.microsoft.com/default.aspx?scid=kb;EN-US;315071
Der angegebene Wert gilt pro CPU Core, ergibt also default MaxPoolThreads=4 und einem 8 Core DC einen Pool von 32, wie z.B. bei unserem betroffenen Kunden.
Für den Pool gibt es auch ATQ (Active Thread Queue) Performance Counter, die wie folgt in Relation zueinander stehen müssen, um ein Problem abzubilden.
Aus “Monitoring Your Branch Office Environment”, https://technet.microsoft.com/en-us/library/dd736504(WS.10).aspx
| NTDS\ATQ Threads LDAP | Indicates the number of threads that are being used by the directory service. |
If values for this counter and the NTDS\ATQ Threads Total counter are equal, a queue is likely building on the LDAP port, which will result in long response times. If the two counters are always equal, use Server Performance Advisor to troubleshoot the problem. |
NTDS\ATQ Threads Total |
Indicates the number of threads that are being used by the directory service. |
If values for this counter and NTDS\ATQ Threads LDAP counter are equal, a queue is likely building on the LDAP port, which will result in long response times. If the two counters are always equal, use Server Performance Advisor to troubleshoot the problem. |
Wenn wir mit dem nun gewonnenen Wissen die “Active Directory Diagnostics” SPA Werte (siehe https://blogs.technet.com/b/deds/archive/2009/09/28/ja-wo-ist-er-denn-der-spa-unter-windows-server-2008-und-r2.aspx) vom Schlechtfall ansehen, wird der Zusammenhang klarer:
|
|||||||||||||||||||||||||||||||||||
|
Im Fehlerfall lagen bereits die Minimal-Werte “ATQ Threads LDAP“ und “ATQ Threads Total“ am Maximalwert, durch MaxPoolThreads default 4 pro Core, bei 8 Cores also 32.
Einen weiteren Zusammenhang kann man aus dem Durchsatz der Ldap pings und der verbrauchten Zeit gewinnen:
|
||||||||||||||||||||||||||||||
|
Das Rechenexempel LDAPPing/sec (von 13,4) mal dem Delay (hier 2,372 sec) zeigt Gültigkeit und ergibt 31,7848 Anfragen mit Delay, was ebenfalls dem per Default eingestellten Maximalwert von 32 Pool Threads entspricht. Damit blockieren die Ldap pings den kompletten Pool und die Verzögerungen schlagen auch für normale Ldap Anfragen und Kerberos durch.
Eine Erhöhung von MaxPoolThreads auf 10 (interne Empfehlung) und damit ein ATQ Pool von 80 war vollkommen ausreichend, um beim Kunden die noch nicht erfassten Client IP Segmente abzufangen.
Für das weitere Monitoring der Performance Counter haben wir dann folgende Bewertung vorgeschlagen (Sicherheitspuffer 20%, also 80% vom Maximalwert):
- “ATQ Threads Total“ < 80% MaxPoolThreads x Anzahl Cores
Bsp: “ATQ Threads Total” < 0,80 x 10 x 8 = 64 - “ATQ Threads LDAP“ < „ATQ Threads Total“
Werden die Schwellwerte überschritten, empfiehlt es sich über den SPA ”LDAPPing, Requests/sec” in Relation zu "LDAPPing, Response Time (ms)" zu bewerten. Leider gibt es beides nicht direkt als NTDS Perfmon Counter. Sollten zudem die ATQ Counter im Perfmon keine zuverlässigen Werte liefern, so ist der SPA von grundauf der richtige Ansatz.
3) Optimierung der DC Namensauflösung
Je schneller der DC selbst mit der Namensauflösung für ungemappte Clients fertig ist, desto schneller kann er den Thread aus dem ATQ Pool freigeben. Damit sinkt auch die Wahrscheinlichkeit überhaupt in den Engpass zu laufen. Meistens machen NBT Broadcasts DC seitig wenig Sinn, und wenn Netbios für WINS noch benötigt werden sollten, dann bitte nur als P-Node, also ohne Broadcasts im Nachgang; siehe auch “Chapter 11 - NetBIOS over TCP/IP - Microsoft TechNet: Resources”, https://technet.microsoft.com/en-us/library/bb727013.aspx
| Table 11-4 NetBIOS node types | |
Node type |
Description |
B-node (broadcast) |
Uses broadcasts for name registration and resolution. Because routers typically do not forward NetBT broadcasts, NetBIOS resources that are located on remote subnets cannot be resolved. |
P-node (peer-peer) |
Uses an NBNS such as WINS to resolve NetBIOS names. P-node does not use broadcasts but queries the NBNS directly. Because broadcasts are not used, NetBIOS resources located on remote subnets can be resolved. However, if the NBNS becomes unavailable, NetBIOS name resolution fails for all NetBIOS names, even for NetBIOS applications that are located on the local subnet. |
M-node (mixed) |
A combination of B-node and P-node. By default, an M-node functions as a B-node. If the broadcast name query is unsuccessful, NetBT uses an NBNS. |
H-node (hybrid) |
A combination of P-node and B-node. By default, an H-node functions as a P-node. If the unicast name query to the NBNS is unsuccessful, NetBT uses a broadcast. |
Fazit: Bitte prüfen, ob sich Netlogon mit Event 5807 beschwert. Bei einer Vielzahl von Client Verbindungen kann es damit zu Problemen kommen, die noch unter W2k3 nicht aufgetreten sind. Damit sollte man der Empfehlung von Microsoft, für Clients ein passendes Subnet/Site Mapping einzurichten, und die es seit Windows 2000 gibt, unter Windows Server 2008/R2 mit wesentlich höherer Priorität nachkommen. Das kann helfen, Probleme zu vermeiden…
Damit viel Erfolg beim Kontrollieren und Einstellen von Client Subnet- und Site-Definitionen.
Euer Rol
Comments
- Anonymous
January 01, 2003
Much informative & Thanks!