11.04.2023, aktualisiert am 15.04.2023

2719

Windows DHCP Clients verlieren kurz Netz

Hallo zusammen,

wir haben seit mehr als 6 Monaten das Problem dass Windows DHCP Clients gerne um xx:10 (also 10 Minuten nach der vollen Stunde) für ein paar Sekunden den Netzwerkzugriff verlieren. Seit ca. 5 Monaten haben wir dazu ein Ticket bei Microsoft offen aber bisher ohne Fortschritt daher wollte ich mal wissen ob das schon mal jemand gesehen hat.

Wir können leider nicht genau sagen seit wann das Problem so existiert (das passende Log im Ereignislog ist nur 1 MB groß und das DHCP Log serverseitig wird nur ein paar Wochen gespeichert) aber wir hatten zuerst Rückmeldungen der Benutzer dass RDP auf die Clients immer wieder mal abbricht (Autoreconnect funktioniert dann zwar aber trotzdem nervig). Nach vielem Hin und Her (RDP ist nur die Folge und nicht die Ursache) hatte ich das folgende Protokoll gefunden "Microsoft-Windows-NetworkProfile/Betriebsbereit" worin die Auswirkungen/Ereignisse beschrieben sind. Jetzt fehlt mir nur die Quelle bzw. der Auslöser.

Folgende, etwas spezielle, Client Gegebenheiten haben wir:

-3000+ Windows Clients (Domäne), ein paar Linux und MAC Clients (nicht Domäne) noch dazu, alle im selben VLAN

-DHCP/DNS werden unter Linux betrieben (ja die 4 DCs haben DNS am Laufen und die Windows Server nutzen auch Windows DNS, die Clients standardmäßig hingegen nicht)

-MAC Authentisierung

Die Probleme:

DHCP Clients verlieren regelmäßig aber bisher nicht manuell reproduzierbar für mehrere Sekunden Netzwerk. Geräte mit fixer IP haben das Problem nicht. Netzwerker sagen es gibt kein Problem auf deren Seite und da vertrau ich auch drauf.

Im Log sieht es dann so aus:

die Abfolge ist immer gleich, ich dokumentiere es mal chronologisch:

Die Zeiten in denen das passiert sind ziemlich willkürlich aber immer um 10 nach, es kann sein dass es mal 3 Tage nicht auftritt aber dann an 6 Stunden hintereinander, an einem anderen betroffenen Client aber nicht zu dieser Zeit. Das macht es für mich so willkürlich.

Das DHCP Log ist insofern auffällig dass es dazu passende Einträge für Windows Clients enthält (bei Linux/MAC Clients ist dem nicht so, IP Leasetime sind 10 Tage):

May 4 10:10:07 lxdns2 dhcpd[234064]: DHCPREQUEST for 192.168.89.113 from b8:ca:3a:73:4b:50 via eno1
May 4 10:10:07 lxdns2 dhcpd[234064]: DHCPACK on 192.168.89.113 to b8:ca:3a:73:4b:50 via eno1

Ich bin für jegliche Idee offen, sollte ich Infos vergessen habe dann bitte melden.

Danke

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 6724863880

Url: https://administrator.de/contentid/6724863880

Ausgedruckt am: 22.11.2024 um 01:11 Uhr

42 Kommentare

Neuester Kommentar

Haben die Clients Gemeinsamkeiten? Image? Treiber? Switch? Firmware?

Kannst du nicht einen Port spiegeln und zu 100% mitschneiden?

Switch Logs sagen was?

Wie sieht denn die LEASE Time aus ?
Hast du mal die Konfig des DHCP´s greifbar ?
Du schreibst das Ihr MAC- Auth benutzt. Wie ist das Implementiert? Verwendet Ihr den FreeRadius oder einen anderen Radius unter Linux ( Hier Linux Raduis Namen denken ) oder den Windows NPS ?
Betrifft das nur eine Art von Hardware wie z.B. nur Desktops oder nur Notebooks mit Docking ?
Was für Switches verwendet ihr bzw. wie sieht hier die Konfig für die MAC Auth aus ?
Sind es alle die selben Switches ?
Hast du schon mal getestet was Passiert wenn du die MAC Auth auf einem Switch/Port deaktivierst?
und eben das was @2423392070 schreibt wie Image/OS/Treiber etc....
Verwendet ihr Dyn. VLAN Zuweisung ?
Kann es sein das die Auth. Time etwa zu kurz eingestellt ist und der Switch dann erstmal wieder eine neue Auth gegen den Radius oder AD macht=? Kann ja sein das der Switch erstmal daher den Port dicht macht und dann anschließend die Auth. fährt und dann den Port wieder auf Active setzt wenn die Auth. erfolgreich war. Nur so eine Idee noch,

Wir hatten das mal mit dem Windows DHCP Server und dem NPS bzw. glaube sogar es war ne ISE aber ist ja auch egal.
Laaaaaaang ists her...... Wir hatten damals glaube ich die MAC Adressen falsch eingetragen für einige Geräte.
User Standard war glaube ich AB-CD-EF-11-22..... und einige Switches haben aber AB:CD:EF:11:22:33 gebraucht was
dann zu Fehlern geführt hat weil Fallback gedauert hatte aber du sagst ja das es IM Betrieb Probleme gibt daher ist es ggf. auch die Zeit wie lange die Auth des Switches / Radius gültig ist ?

EDIT: Fragen hinzugefügt

3000+ Clients alle im selben VLAN sprich alle in einer einzigen Layer 2 Brodcast Domain ohne jegliche Segmentierung?? Nicht dein Ernst, oder??
Was meinst du mit Mac Authentisierung? MacBypass am Switch also Port Authentisierung auf Mac Basis mit Radius / NPS?

Moin,

einige grundsätzliche Fragen, zu dem was du da schreibst:

Zitat von @saxe1234:
Wir können leider nicht genau sagen seit wann das Problem so existiert (das passende Log im Ereignislog ist nur 1 MB groß und das DHCP Log serverseitig wird nur ein paar Wochen gespeichert) aber wir hatten zuerst Rückmeldungen der Benutzer dass RDP auf die Clients immer wieder mal abbricht (Autoreconnect funktioniert dann zwar aber trotzdem nervig). Nach vielem Hin und Her (RDP ist nur die Folge und nicht die Ursache) hatte ich das folgende Protokoll gefunden "Microsoft-Windows-NetworkProfile/Betriebsbereit" worin die Auswirkungen/Ereignisse beschrieben sind. Jetzt fehlt mir nur die Quelle bzw. der Auslöser.

Du schreibst doch, dass du das Problem seit 6 Monaten hast. Mittlerweile solltest du ja also 6 Monate Protokolle liegen haben. Das sollte als Datengrundlage reichen. Oder hast du die Protokollgröße/Aufbewahrungszeit nicht angepasst?

Folgende, etwas spezielle, Client Gegebenheiten haben wir:

-3000+ Windows Clients (Domäne), ein paar Linux und MAC Clients (nicht Domäne) noch dazu, alle im selben VLAN

Laut deiner Meldung, tritt das Problem ja nur an Windows Clients mit DHCP auf. Wie viele der 3000+ Clients haben denn eine feste IP-Adresse, wenn es da nicht auftritt. Wie viele dieser 3000+ Clients haben das Problem gemeldet? Kannst du bei den Clients irgendeine Gemeinsamkeit erkennen, wie: gleicher Switch?

-DHCP/DNS werden unter Linux betrieben (ja die 4 DCs haben DNS am Laufen und die Windows Server nutzen auch Windows DNS, die Clients standardmäßig hingegen nicht)

Wieso die Trennung in der DNS-Nutzung zwischen Clients und Server? Doppelte IP-Adressvergabe kannst du ausschließen?

Die Probleme:
DHCP Clients verlieren regelmäßig aber bisher nicht manuell reproduzierbar für mehrere Sekunden Netzwerk. Geräte mit fixer IP haben das Problem nicht. Netzwerker sagen es gibt kein Problem auf deren Seite und da vertrau ich auch drauf.

Vertraue nicht darauf was die Netzwerker sagen. Es gibt kein Problem ist eine Aussage, die man so nicht stehen lassen kann. Es gibt immer irgendwo ein Problem im Netzwerk. Wenn es also kein Problem gibt, dann sehen sie es einfach nicht

. Das ist bewusst etwas Provokant gesagt. Was ich meine: Du hast die Aufgabe das Problem zu lösen. Wenn du einen Verdacht hast, dann geh schildere den Verdacht den Netzwerkern und lasse den Verdacht explizit prüfen. Eine allgemeine Frage nach dem Motto "ist irgendwas?" hat selten Erfolg. Und dann sind wir wieder bei der klassischen Frage: Sind doppelt vergebende IP-Adressen (egal ob DHCP oder static) ein Problem der Netzwerker oder der Server-/Client-Admins? Solange du nicht weißt wo das Problem ist, kannst du nicht sagen, wessen BEreich es ist.

Nochmal die Frage ob es immer die gleichen Clients sind oder ob das auch willkürlich ist.

Das DHCP Log ist insofern auffällig dass es dazu passende Einträge für Windows Clients enthält (bei Linux/MAC Clients ist dem nicht so, IP Leasetime sind 10 Tage):

May 4 10:10:07 lxdns2 dhcpd[234064]: DHCPREQUEST for 192.168.89.113 from b8:ca:3a:73:4b:50 via eno1
May 4 10:10:07 lxdns2 dhcpd[234064]: DHCPACK on 192.168.89.113 to b8:ca:3a:73:4b:50 via eno1

Das irritiert mich jetzt. Du schreibst, zu Beginn, dass du das Problem seit mehr als 6 Monaten hast und seit 5 Monaten ein Ticket bei MS. Jetzt postest du aber hier einen Log-Auszug vom 04. Mai. Da wir aber heute den 11. April haben, ist der Log-Eintrag also 11 Monate alt. Wenn du das Problem also erst seit 6 Monaten hast dann ist der Log-Auszug irrelevant. Wenn der Log-Auszug zu dem Problem passt, dann weißt du jetzt schonmal, dass du das Problem schon seit 11 Monaten hast. Also musst du dich jetzt entscheiden.

Nur weil die Uhrzeit passt, muss es nicht zu deinem Problem passen. Oder, wenn ich mir deine Screenshots ansehen, haben wir hier ein Problem mit dem Datumsformat in der Interpretation von 4/5/2023 ?

Allgemeine Frage. was sagt das Monitoring-Tool zu deiner Situation? Meldet es irgendetwas?

Gruß
Doskias

Danke für die vielen Antworten, bei uns sind die einzelnen IT-Themen in Gruppen unterteilt daher kann ich aus dem Stehgreif nicht alles beantworten aber ich habe die passenden Kollegen gebeten sich eure Fragen anzuschauen und mir zu antworten damit ich das hierher weiterleiten kann.

2 Dinge noch so nebenbei:

das Problem tritt meines Wissens nach nur im Firmen LAN auf, hab selber ein Notebook welches daheim benutzt wird und mit dem ich via VPN in die Firma verbunden bin, keine Probleme damit (und von den anderen 230 VPN Clients habe ich dazu auch noch nie etwas gehört)

stellen wir ein betroffenes Gerät von DHCP auf feste IP um dann ist das Problem weg

jetzt versuch ich mal auf all die Fragen einzugehen...

Zitat von @2423392070:

Haben die Clients Gemeinsamkeiten? Image? Treiber? Switch? Firmware?

komplett divers, ich habe 6 Testclient (2 unterschiedliche Dell PCs plus 4 virtuelle, alle sind betroffen)
Windows Installation wird via SCCM automatisiert daher schließe ich das mal als Problemquelle aus
zu Switches bzw. deren Firmware kann ich noch nichts sagen, muss ich noch Erkundigungen einholen
aber ich weiß vom "WOL Thema" (siehe anderer Post von mir) dass wir da keinen wirklich einheitlichen Stand haben

Kannst du nicht einen Port spiegeln und zu 100% mitschneiden?
Switch Logs sagen was?

Gebe ich mal an die Netzis weiter

Danke dir

Zitat von @Mr-Gustav:

Wie sieht denn die LEASE Time aus ?
Hast du mal die Konfig des DHCP´s greifbar ?
Du schreibst das Ihr MAC- Auth benutzt. Wie ist das Implementiert? Verwendet Ihr den FreeRadius oder einen anderen Radius unter Linux ( Hier Linux Raduis Namen denken ) oder den Windows NPS ?

Infos werde ich beschaffen und weitergeben

Betrifft das nur eine Art von Hardware wie z.B. nur Desktops oder nur Notebooks mit Docking ?

nein, egal ob physikalische Geräte (Notebooks, PCs) oder virtuelle Hyper-V Windows Clients, alle scheinen betroffen zu sein, ich hab bisher noch keinen DHCP Client gesehen der nicht betroffen wäre

Was für Switches verwendet ihr bzw. wie sieht hier die Konfig für die MAC Auth aus ?
Sind es alle die selben Switches ?
Hast du schon mal getestet was Passiert wenn du die MAC Auth auf einem Switch/Port deaktivierst?

Infos werde ich beschaffen und weitergeben

und eben das was @2423392070 schreibt wie Image/OS/Treiber etc....

darauf habe ich gerade geantwortet

Verwendet ihr Dyn. VLAN Zuweisung ?

nein

Kann es sein das die Auth. Time etwa zu kurz eingestellt ist und der Switch dann erstmal wieder eine neue Auth
gegen den Radius oder AD macht=? Kann ja sein das der Switch erstmal daher den Port dicht macht und dann
anschließend die Auth. fährt und dann den Port wieder auf Active setzt wenn die Auth. erfolgreich war. Nur so eine > Idee noch,

kann ich mir nicht vorstellen da MAC Auth ja unabhängig von DHCP/feste IP ist

Wir hatten das mal mit dem Windows DHCP Server und dem NPS bzw. glaube sogar es war ne ISE aber ist ja auch > egal.
Laaaaaaang ists her...... Wir hatten damals glaube ich die MAC Adressen falsch eingetragen für einige Geräte.
User Standard war glaube ich AB-CD-EF-11-22..... und einige Switches haben aber AB:CD:EF:11:22:33 gebraucht was
dann zu Fehlern geführt hat weil Fallback gedauert hatte aber du sagst ja das es IM Betrieb Probleme gibt daher ist > es ggf. auch die Zeit wie lange die Auth des Switches / Radius gültig ist ?

Infos werde ich beschaffen und weitergeben

Danke dir

Zitat von @aqui:

3000+ Clients alle im selben VLAN sprich alle in einer einzigen Layer 2 Brodcast Domain ohne jegliche Segmentierung?? Nicht dein Ernst, oder??

so ist es aber und so war es hier schon immer, Segmentierung ist schon vorhanden (es gibt sehr viele VLANs aber die Clients sind alle in einem, von ein paar Ausnahmen abgesehen) damit wir uns nicht falsch verstehen, Server, Drucker, usw. haben eigene VLANs

Was meinst du mit Mac Authentisierung? MacBypass am Switch also Port Authentisierung auf Mac Basis mit Radius / NPS?

Infos werde ich beschaffen und weitergeben

Danke dir

Was auch sehr helfen würde, was heißt: Verlieren kurz Netz

Was heißt das genau? Was passiert in den Moment auf Layer2?

Zitat von @Doskias:

Moin,

einige grundsätzliche Fragen, zu dem was du da schreibst:

hab ich clientseitig tatsächlich noch nicht gemacht (System und Security haben wir angepasst), hab gerade mal geschaut, per GPO kann ich die max. Loggröße für "Microsoft-Windows-NetworkProfile" anscheinend nicht direkt vorgeben, passenden Registrywert habe ich auf die schnelle nicht gefunden

zu den DHCP Logs muss ich mal den Kollegen fragen ob die Logs mittlerweile länger vorgehalten bzw. gebackup werden, da hatten wir schon mal drüber gesprochen

Folgende, etwas spezielle, Client Gegebenheiten haben wir:

-3000+ Windows Clients (Domäne), ein paar Linux und MAC Clients (nicht Domäne) noch dazu, alle im selben VLAN

ich sehe keine passenden Gemeinsamkeit außer Windows. Gemeldet haben sich ca. 10 Benutzer, nach Recherche it intern kamen nochmal so viele dazu. Aber es betrifft jeden Client den ich bisher geprüft habe. Wir haben von 3000+ Clients 3 (drei) mit fester IP, nachdem ich das als kurzfristigen Workaround entdeckt hatte kamen dann nochmal ca. 35 Clients mit fester IP dazu weil diese kritisch für den Betrieb sind und auf Netzwerkunterbrechungen empfindlich reagieren (also empfindlicher als eh schon

)

-DHCP/DNS werden unter Linux betrieben (ja die 4 DCs haben DNS am Laufen und die Windows Server nutzen auch Windows DNS, die Clients standardmäßig hingegen nicht)

Wieso die Trennung in der DNS-Nutzung zwischen Clients und Server? Doppelte IP-Adressvergabe kannst du ausschließen?

Trennung ist historisch begründet, wurde hier schon immer so gemacht, ja ich weiß, hört man öfter und ist keine tolle Aussage aber so ist, ich bin alleine auch nicht in der Lage das zu ändern aber, ich bin seit 10 Jahren hier und dieses Problem hatten wir so vorher noch nie

IP Doppelung ist ausgeschlossen

danke, die ersten 4 Sätze haben im internen Chat schon für Erheiterung gesorgt und du hast mit Sicherheit Recht

Nochmal die Frage ob es immer die gleichen Clients sind oder ob das auch willkürlich ist.

alle Clients die ich bisher untersucht habe und die DHCP nutzen sind betroffen

Das irritiert mich jetzt. Du schreibst, zu Beginn, dass du das Problem seit mehr als 6 Monaten hast und seit 5 >Monaten ein Ticket bei MS. Jetzt postest du aber hier einen Log-Auszug vom 04. Mai. Da wir aber heute den 11. >April haben, ist der Log-Eintrag also 11 Monate alt. Wenn du das Problem also erst seit 6 Monaten hast dann ist der >Log-Auszug irrelevant. Wenn der Log-Auszug zu dem Problem passt, dann weißt du jetzt schonmal, dass du das >Problem schon seit 11 Monaten hast. Also musst du dich jetzt entscheiden.

Nur weil die Uhrzeit passt, muss es >nicht zu deinem Problem passen. Oder, wenn ich mir deine Screenshots ansehen, haben wir hier ein Problem mit >dem Datumsformat in der Interpretation von 4/5/2023 ?

ja sorry, manueller Eingriff und die frühe Uhrzeit haben für die Tag / Monat Drehung gesorgt, es sollte also 5. April heißen

Allgemeine Frage. was sagt das Monitoring-Tool zu deiner Situation? Meldet es irgendetwas?

das waren die 10 User und die haben ein Ticket aufgemacht da sie Probleme bei RDP Verbindungen auf Clients sehen. Sorry für die läppische Beantwortung der Frage aber ich wüßte nicht wo das bei uns gemonitort werden könnte

Gruß
Doskias

Danke dir

Zitat von @2423392070:

Was auch sehr helfen würde, was heißt: Verlieren kurz Netz

Was heißt das genau? Was passiert in den Moment auf Layer2?

Muss ich herausfinden lasse

Info: die IP-Zuweisung per DHCP ist statisch, d.h. jeder MAC wird immer die gleiche eindeutige IP zugewiesen. Damit sind doppelte IP-Vergabe eher auszuschließen.

Mein Bauchgefühl, ich bin seit über 25 Jahren dabei, sagt mir das DHCP was deine Aufmerksamkeit erhält ist lediglich ein Symptom und der Fokus darauf vernebelt den Blick auf die Ursachen.

Wir warten daher auf Feedback was in dem Moment wirklich passiert.

Zitat von @saxe1234:

Zitat von @Doskias:

Ok gefunden:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-NetworkProfile/Operational

MaxSize auf 100MB gesetzt

Zitat von @2423392070:

Mein Bauchgefühl, ich bin seit über 25 Jahren dabei, sagt mir das DHCP was deine Aufmerksamkeit erhält ist lediglich ein Symptom und der Fokus darauf vernebelt den Blick auf die Ursachen.

ist definitiv möglich und würde mich jetzt auch nicht komplett zum Staunen bringen

Wir warten daher auf Feedback was in dem Moment wirklich passiert.

jepp

kurze Rückmeldung da sich einer unserer Netzwerker zum Support bereit erklärt hat

Switch? Firmware?

Brocade/Ruckus ICX6xxx, 7xxx mit unterschiedlichen Firmware Versionen

Switch Logs sagen was?

man sieht hier weder Netzwerkunterbrechungen noch Re-Authentifizierungen

Verwendet ihr Dyn. VLAN Zuweisung ?
Kann es sein das die Auth. Time etwa zu kurz eingestellt ist und der Switch dann erstmal wieder eine neue Auth >gegen den Radius oder AD macht=? Kann ja sein das der Switch erstmal daher den Port dicht macht und dann >anschließend die Auth. fährt und dann den Port wieder auf Active setzt wenn die Auth. erfolgreich war.

Ja, wir verwenden Dyn. VLAN Zuweisung. Die Aging ist aber für authentifizierten MACs ausgeschaltet, deswegen erzwingt der Switch keine Re-Authentifizierung.

wir testen jetzt noch ein paar Dinge und dann melde ich mich erneut

zum Thema DHCP habe ich folgende Infos bekommen:

Version: isc-dhcp-server 4.3.5-3+deb9u3

Konfiguration (Namen und IPs geändert)

subnet x.x.0.0 (muss ich maskieren weil hier kein privater Adressbereich genutzt wird) netmask 255.255.0.0 {
option subnet-mask 255.255.0.0;
option routers x.x.96.1;
option domain-name-servers x1.y.de, x2.y.de;
option domain-name "y.de";
option ntp-servers timeserver.y.de;
option netbios-name-servers dc01.y.de, dc02.y.de, dc03.y.de, dc04.y.de;
option netbios-node-type 8;
option tftp-server-name "tftp.y.de";
option bootfile-name "pxelinux.0";
option smtp-server smtp.y.de;
option pxelinux.configfile "pxelinux.cfg/default";
next-server tftp.y.de;
}

Leasetime:

lease times

default-lease-time 259200; # 3d
max-lease-time 604800; # 7d

Das Einfachste wird wirklich der Mitschnitt am Clientport sein, der betroffen ist.

Kann der Client in dem Moment sich selbst pingen?

Zitat von @2423392070:

Das Einfachste wird wirklich der Mitschnitt am Clientport sein, der betroffen ist.

Kann der Client in dem Moment sich selbst pingen?

das müsste man testen, da es ja auch nicht jede Stunde auftritt sondern sporadisch und auch nur ein paar Sekunden anhält ist nicht so einfach auszuprobieren

Kannst du nicht auf diverse Clients ein Ping machen der mindestens alle 500ms sich selbst pingt und ein Log mit Zeitstempel schreibt?

Wenn der DHCP die IP´s anhand einer Statischen Liste ( MAC ::::1 = IP 1 / ::::2 = IP 2 usw.... ) verteilt und die Lease Time so hoch ist dann würde ich wie @2423392070 schon schreibt, eher auf einen Fehler im LAN Tippen und nicht auf dem DHCP Server.

Wie siehts denn mit STP / RSTP / MSVTP aus ? Da das regelmäßig vorkommt könnte es auch hier ein Problem geben.
Was sagt die Switch Konfig. Nicht das jemand einen Loop gesteckt hat.
Gut das mit dem an / Link auf der Karte hat der Kollege schon gefragt. Aber was anderes:
Wenn das Problem auftritt ist dann das Symbol in der Taskleiste die Weltkugel oder das Klasiche PC mit Kabelabbildung ?
Weil wenn die Verbindung komplett abreißt dann würde das ja auf den Switch bzw. die Strecke Switch PC / Switch deuten. Die Temeraturen in den NW Schränken passen auch alle ? Problem hatte ich mal. Switch überhitzt und dann Rebootet die Kiste sporadisch. Das kann je nach dem auch eine STP Neuberechnung bedeuten usw....

Zitat von @2423392070:

Kannst du nicht auf diverse Clients ein Ping machen der mindestens alle 500ms sich selbst pingt und ein Log mit Zeitstempel schreibt?

das hatte ich schon mal gemacht, hier ein Auszug aus dem Log:

192.168.89.113 - 28.11.2022-23:10:08,52 - JA - 1ms
192.168.89.113 - 28.11.2022-23:10:08,62 - JA - 1ms
192.168.89.113 - 28.11.2022-23:10:08,72 - JA - 1ms
192.168.89.113 - 28.11.2022-23:10:08,81 - JA - 1ms
192.168.89.113 - 28.11.2022-23:10:08,93 - NEIN
192.168.89.113 - 28.11.2022-23:10:09,01 - NEIN
192.168.89.113 - 28.11.2022-23:10:09,21 - NEIN
192.168.89.113 - 28.11.2022-23:10:09,31 - NEIN
192.168.89.113 - 28.11.2022-23:10:09,40 - NEIN
192.168.89.113 - 28.11.2022-23:10:09,46 - NEIN
192.168.89.113 - 28.11.2022-23:10:09,52 - NEIN
192.168.89.113 - 28.11.2022-23:10:09,58 - NEIN
192.168.89.113 - 28.11.2022-23:10:09,64 - NEIN
192.168.89.113 - 28.11.2022-23:10:09,71 - NEIN
192.168.89.113 - 28.11.2022-23:10:09,76 - NEIN
192.168.89.113 - 28.11.2022-23:10:09,83 - NEIN
192.168.89.113 - 28.11.2022-23:10:09,91 - NEIN
192.168.89.113 - 28.11.2022-23:10:09,98 - JA - 1ms
192.168.89.113 - 28.11.2022-23:10:10,05 - JA - 1ms
192.168.89.113 - 28.11.2022-23:10:10,11 - JA - 1ms
192.168.89.113 - 28.11.2022-23:10:10,17 - JA - 1ms
192.168.89.113 - 28.11.2022-23:10:10,23 - JA - 1ms

JA im Sinne von Ping OK, Nein im Sinne von Ping NotOK

und so sieht das dann immer aus wenn der Problemfall eintritt

es sind immer so 1-5 Sekunden Ausfall, je nach Client mal etwas schneller, mal was langsamer

Zitat von @Mr-Gustav:

Wenn der DHCP die IP´s anhand einer Statischen Liste ( MAC ::::1 = IP 1 / ::::2 = IP 2 usw.... ) verteilt und die Lease Time so hoch ist dann würde ich wie @2423392070 schon schreibt, eher auf einen Fehler im LAN Tippen und nicht auf dem DHCP Server.

das ist durchaus möglich, ich hab halt aktuell für mich nur den Ansatz bezüglich DHCP weil ich selbst an meiner Adminkiste nie einen Ausfall hatte aber die ist auch einer der wenigen die eine feste IP hat (und die Server natürlich auch daher hatten die auch nie ein Problem)

Wie siehts denn mit STP / RSTP / MSVTP aus ? Da das regelmäßig vorkommt könnte es auch hier ein Problem geben.
Was sagt die Switch Konfig. Nicht das jemand einen Loop gesteckt hat.
Gut das mit dem an / Link auf der Karte hat der Kollege schon gefragt. Aber was anderes:
Wenn das Problem auftritt ist dann das Symbol in der Taskleiste die Weltkugel oder das Klasiche PC mit Kabelabbildung ?
Weil wenn die Verbindung komplett abreißt dann würde das ja auf den Switch bzw. die Strecke Switch PC / Switch deuten. Die Temeraturen in den NW Schränken passen auch alle ? Problem hatte ich mal. Switch überhitzt und dann Rebootet die Kiste sporadisch. Das kann je nach dem auch eine STP Neuberechnung bedeuten usw....

Wenn es etwas an den Switchen wäre, dann würde es aber nicht erklären warum die DHCP Clients einen Ausfall haben, die mit fester IP aber nicht denn die hätten ja dann zu dem Zeitpunkt ja auch kein Netz

Die Netzwerker wollen als nächstes einen Port spiegeln und dann mal schauen, da habe ich nur keine Aktien dran und kann nur auf die Ergebnisse warten und laut deren Aussage haben sie bisher an den Ports zum Endgerät hin keine Probleme sehen können

Und es wäre halt auch höchst merkwürdig wenn die Probleme im Netz immer wieder um 10 Minuten nach der vollen Stunde (aber leider nicht immer zu jeder Stunde) auftreten

Ich hatte anfangs auch mal einen wildgewordenen Client im Verdacht und da wird @aqui, wie ich auch schon, wahrscheinlich die Hände überm Kopf zusammenschlagen, wir haben in unserem Client VLAN so einen Wildwuchs (zentral verwaltete Geräte neben nicht zentral verwalteten) dass es einem die Haare bei ausfallen aber wir haben mindestens ein VLAN (in dem stecken besondere und nur zentral verwaltete Clients und Server) in dem das Problem auch auftritt.

Das ist doch schon mal was.
Es ist in Beispiel für die IP weg und das DHCP wird dann wohl zurecht befragt und liefert.

Auch wenn es sehr schnell geht. Es ist wirklich kein RSTP Problem im Netz, dass zu diesem Zeitpunkt, durch irgendwas getriggert den Baum schüttelt? Das könnte nämlich sein.
Sind die Ports der Clients zufällig nicht auf "Portfast"?

Zitat von @2423392070:

Das ist doch schon mal was.
Es ist in Beispiel für die IP weg und das DHCP wird dann wohl zurecht befragt und liefert.

Auch wenn es sehr schnell geht. Es ist wirklich kein RSTP Problem im Netz, dass zu diesem Zeitpunkt, durch irgendwas getriggert den Baum schüttelt? Das könnte nämlich sein.
Sind die Ports der Clients zufällig nicht auf "Portfast"?

ich zitiere mal den Netzwerker

"ich glaube nicht daran, dass Spanning Tree hier der Auslöser wäre.

Wir verwenden RSTP auf per VLAN Basis. Jedes VLAN hat seine eigene RSTP Instance.
Im Core-Bereich auf unseren Backbone haben wir gar kein Spanning Tree.
Die Switche im Distribution-Layer sind immer die Root Bridge in ihrem Bereich und diese Bereiche haben ihre eigene, autarke Spanning Trees.
Allein in Gebäude XYZ haben wir 5-6 autarke Spanning Tree
Ich halte das für unmöglich, dass mehrere unabhängige Bereiche gleichzeitig gestört wären. Und warum nur um xx:10.

Spanning Tree bei uns bedeutet nicht nur einen Baum, sondern einen ganzen Wald...
Ich sehe nicht, was hier der Wind sein könnte, der alle Bäume gleichzeitig schütteln kann.

Und ja, wir benutzen irgendeine Art von Portfast.

Die Netzwerk Loops können wir auch ausschließen
a: das stecken unsere Benutzer nicht immer um xx:10
b: gegen Loops schützen wir unsere Switche mit BPDU-Guard"

Rückmeldung von MS Support bekommen, Supporter hat gewechselt und nächste Woche sollen die Tracinglogs ausgewertet sein (dann sind wir bei fast 2 Monaten, die letzten waren mit Hauptaugenmerk auf DHCP)

Das mit eurer RSTP Konfig habe ich jetzt nicht verstanden, aber das würde auch in den Switch-Logs zu sehen sein.

Was ich sagen wollte ist: RSTP kann den Baum in der kurzen Zeit schütteln und beruhigen. Das würde aber nicht erklären, dass es Windows Clients sind, die die IP noch Mal holen.

Es sollte also weiter nach Gemeinsamkeiten der Betroffenen gesucht werden.

Wir verwenden RSTP auf per VLAN Basis. Jedes VLAN hat seine eigene RSTP Instance.

Welches denn? PVRSTP oder PVRSTP+ ??
Letzteres ist Cisco PVRSTP was proprietäre BPDU Mac Adressen nutzt und nicht kompatibel ist zu anderen PVRSTP oder Standard RSTP Verfahren was die Standard RSTP BPDU Mac Adressen nutzt. Das solltest du immer auf dem Radar haben!
Man darf also keinesfalls beide STP Varianten mischen, das kann zu solchem Verhalten wie deines führen. Würde aber, wie oben schon gesagt, dann alle Endgeräte betreffen und nicht nur solche mit einem bestimmten OS.

Zitat von @saxe1234:

Moin,

Was mich an den beiden Bildern stört...im ersten Screenshot sagt er "Category: Public", im zweiten Screenshot dann wieder "Category: Domain Authenticated", da spinnt die NLA doch etwas rum. Das Phänomen selbst kenn ich nur von W7 und dazu gabs damals einen Patch. Brachte aber auch abbrechende RDP Sessions (und sonstige Netzwerkzugriffe) mit sich.

Wie man die NLA dann soweit verbiegt, dass sie noch halbwegs funktioniert (d.h. nicht über secpol mehr oder weniger abschalten), aber trotzdem den Fehler nicht bringt ist natürlich dann die andere Sache.

Grüße

Mhhh dann würde der Client sich aber eigentlich keine neue IP holen denn das wäre ja theoretisch kontraproduktiv weil dann muss die NSI ja noch mal von vorne anfangen.
Der Schritt / Ablauf ist ja eigentlich folgender;:
Stecker rein / PC an
IP Adresse hohlen / zugeteilt bekommen
und dann versucht die NSI zu erkennen ob Sie den DC oder was auch immer erreicht
und dann wäre ja die Sache erledigt weil Dom.Auth. Netzwerk erkannt.
Wenn die NSI da spinnt warum soll da die IP gewechselt werden ? bzw. erst
zurückgegeben und dann wieder neu zugeteilt werden ?

Kannst du auf dem Server des DHCP im Log sehen das die Clients ihre IP "zurück" geben weil die
Software / IPStack meint er will eine neue IP haben ? oder geht da einfach das klassische D - O- R- A
vom DCHP/Client wieder los ?

Die NLA Spur ist mindestens heiß.
Das könnte der gemeinsame Nenner sein.

Moin,

erstmal vielen Dank weiterhin für die vielen Kommentare. Die NLASVC Spur gefällt mir auch

Ich habe mir mal folgenden Link angeschaut:

https://www.msxfaq.de/netzwerk/grundlagen/network_location_awareness.htm

Seltsamerweise ist an einem der beiden Testgeräte (beide sind betroffen) das NLASvc\Operation Log komplett leer (Log ist aber aktiv) und an dem anderen stehen da zwar ein paar Einträge drin aber die sind noch vom letzten Jahr (in der ersten Zeile die ersten beiden Stellen der IP x.x.78.252 geändert, 192.168.56.1 ist die VirtualBox NIC):

TimeCreated Id LevelDisplayName Message

-- ---------------- -------
26.11.2022 18:10:40 4343 Fehler Folgender Fehler bei der LDAP-Authentifizierung an der Schnittstelle {9CC2A929-0DC7-4231-8747-8CFF812E2DDD} (192.168.78.252): 0x51.
03.08.2022 18:42:39 4343 Fehler Folgender Fehler bei der LDAP-Authentifizierung an der Schnittstelle {DEE8749A-CA80-4C70-9C15-6F8350AAE0CD} (192.168.56.1): 0x51.
03.08.2022 18:42:39 4343 Fehler Folgender Fehler bei der LDAP-Authentifizierung an der Schnittstelle {DEE8749A-CA80-4C70-9C15-6F8350AAE0CD} (192.168.56.1): 0x51.
03.08.2022 10:10:09 4343 Fehler Folgender Fehler bei der LDAP-Authentifizierung an der Schnittstelle {DEE8749A-CA80-4C70-9C15-6F8350AAE0CD} (192.168.56.1): 0x51.
03.08.2022 10:10:09 4343 Fehler Folgender Fehler bei der LDAP-Authentifizierung an der Schnittstelle {DEE8749A-CA80-4C70-9C15-6F8350AAE0CD} (192.168.56.1): 0x51.

NCSI ist per GPO nicht konfiguriert also Standard aktiv.

Hier mal der Regauszug zu NLAsvc von einem der beiden Testclients:

Auf den festen Clients mal folgende Keys importieren und neu starten

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters
Name: NegativeCachePeriod
Type: REG_DWORD
Value Data: 0

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
Name: MaxNegativeCacheTtl
Type: REG_DWORD
Value Data: 0

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters
Name: AlwaysExpectDomainController
Type: REG_DWORD
Value Data: 1

3000+ Clients in einem VLAN

Broadcast storm ala bonheur... Da kann man nur sagen, hausgemachtes Problem ....
Du doktorst nur an den Symptomen, nicht an der Ursache des Übels.

Da kann man nur sagen, hausgemachtes Problem ....

Vermutlich ein Bastelfrickler der das Design gemacht hat obwohl das Wort "Design" hier ganz sicher unangebracht ist. Ein Netzwerker mit Fachkenntissen kennt die goldene Regel Nie mehr als 150 Clients plus/minus in einer Layer 2 Broadcast Domain!
Da ist dann wahrlich alles hausgemacht! Ohne Worte...

Zitat von @12168552861:

Auf den festen Clients mal folgende Keys importieren und neu starten

die Regkeys hatte ich schon mal gefunden und probiert, half leider nix

3000+ Clients in einem VLAN

Broadcast storm ala bonheur... Da kann man nur sagen, hausgemachtes Problem ....
Du doktorst nur an den Symptomen, nicht an der Ursache des Übels.

Da kann man nur sagen, hausgemachtes Problem ....

ich hab es in Richtung Netzwerk weitergegeben - es ist noch wesentlich mehr in dem VLAN los aber darauf gehe ich hier mal nicht ein

Dankeschön auf jeden Fall

hab nochmal nachgeprüft, ja wir haben ein sehr großes VLAN aber auch zwei kleinere mit 130 bzw. 500 registrierten Geräten (wieviele davon dann auch online sind, kann ich nicht sagen) und da tritt das Problem ebenfalls auf

es ist noch wesentlich mehr in dem VLAN los aber darauf gehe ich hier mal nicht ein

Nee, ist auch besser wir erfahren von diesem Elend auch nix. Sauberes Netzwerk Design sieht in der Tat anders aus.
Mehr als 3000+ Clients in einer Layer 2 Broadcast Domain ist völliger Overkill und ein absolutes NoGo wenn man als guter Netzwerker weiss das bei 150 bis max. 250 Schluss sein sollte. Da muss einen dann in der Tat gar nichts mehr wundern wenn es in so einem Gruselkonstrukt zu permanenten Problemen kommt.
Hier ist eine Netzwerk Segmentierung (VLANs etc.) zwingend überfällig!!

und da tritt das Problem ebenfalls auf

Wenn der DHCP Server im 3000+ VLAN liegt muss einen das auch nicht wundern... Sollte das der Fall sein gehört der DHCP Server auf alle Fälle zwingend in ein deutlich weniger Broad- und Multicast belastetes Segment!! Das dürfte dann auch alle Probleme sehr wahrscheinlich lösen.

Hier ist eine Netzwerk Segmentierung (VLANs etc.) zwingend überfällig!!

da kann ich nur voll und ganz zustimmen, liegt aber nicht in meiner Hand, dafür mache ich mich aber schon eine ganze Weile stark

Wenn es das denn nun war bitte nicht vergessen deinen Thread dann auch als erledigt zu markieren!
Wie kann ich einen Beitrag als gelöst markieren?

ist leider noch nicht gelöst aber ich bleibe dran

Problem gelöst, wir hatten eine geplante Aufgabe per GPO verteilt die stündlich um 10 Minuten nach der vollen Stunde die lokale Applockerpolicies resettet und dies scheint bei vielen Geräten zu diesem Problem geführt zu haben. Ich verstehe zwar noch nicht warum aber nach dem die Aufgabe gelöscht wurde, tritt das Problem nicht mehr auf.

Das war der Task:

Program/script C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Arguments Set-AppLockerPolicy -XmlPolicy 'C:\Windows\CentralFiles\Applocker\emptyrules.xml'

gelöst Frage Windows 10

Mehr von saxe1234

Windows Event Collector - "Domain Servers" includedsaxe1234 - 7 Kommentare

GPO Frage - GPO soll nur gelten wenn Gerät in 2 Gruppen Mitglied istsaxe1234 - 18 Kommentare

Kacheln im Startmenü (servergespeichertes Profil OK, bei lokaler Kopie NotOK)saxe1234 - 1 Kommentar

Wake On LAN Probleme im Firmenumfeld mit MAC Authentifizierungsaxe1234 - 19 Kommentare

Heiß diskutiert