15
2008R2 DHCP Clients bekommen keine IP
Hallo,
ich habe seit Tagen ein riesen Problem im LAN und komme nichjt mehr weiter. Nach vielen Recherchen Installationen, Deinstallationen, Neukonfigurieren geht mir langsam die Luft aus. Hier im Forum gabs das Thema auch schon mehrfach, half mir aber nicht weiter.
Die Rahmenparameter
LAN mit ca 30 Clients, WIN 7, Android, SONOS u.v.m
Fritzbox 7390 mit deaktiviertem DHCP als WAN-Gateway
Server 2008R2 mit AD, DNS, DHCP, IIS, HyperV (aktuell ohne aktivem Gast), PRTG Network Monitor, 3 NIC's (davon 2 aktuell deaktiviert)
zentraler Switch Netgear GS716T
Die Vorgeschichte
Vor einer Woche lief alles problemlos. Auf Grund eines Provider-Wechsels kam eine Fritzbox ins LAN. 3 Tage später habe ich testweise die Subnetzmaske von 255.255.255.0 auf dem 2008R2 auf 255.255.0.0 geändert, um den erreichbaren Adressbereich zu erweitern.
Anfangs funktionierte alles, einige Stunden später haben sich einige Dienste auf dem Server zerlegt, ich kam auch nicht mehr Remote auf den Server drauf.
Bin dann direkt an den Server, hab einen Restart gemacht. Dienste liefen alle wieder.
Allerdings hatte ich da schon Probleme, interne Clients vom Server aus zu erreichen. Was es genau war, vermag ich nicht mehr zu sagen. Ich habe dann die Subnetzmaske wieder auf 255.255.255.0 zurück geändert (auf der Server-NIC).
Seit dem kann ich meine SONOS-Clients nicht mehr erreichen. Offensichtlich liegt der Grund darin, dass die Clients keine DHCP-Adressen mehr bekommen. Das Problem lässt sich mit Android- und WIN7-Clients nachstellen. Vergebe ich feste Adressen auf den Clients (bei SONOS geht das nicht), läuft alles wunderbar.
Ich habe dann den DHCP-Server deinstalliert, dessen Config (/system32/dhcp) gelöscht, neu Installiert, autorisiert - keine fehler lt. Ereignisprotkoll. Noch immer keine IP-Vergabe via DHCP.
Zwischendurch mal den zentralen LAN-Switch auf Werkseinstellungen zurück gesetzt, stromlos gemacht - keine Änderung
Dann den DHCP-Server nochmal deinstalliert, Konfig gelöscht, HyperV deinstalliert, DHCP neu installiert, konfiguriert, autorisiert - keine Besserung.
Aktueller Stand
Ich habe dann per NetMon den DHCP-Verkehr auf der Server-NIC mitgeschnitten. Wenn ich das mit meinem Halbwissen richtig interpretiere, sendet der Client via Broadcastadresse einen korrekten DHCPDISCOVER an den Server, der antwortet auch mit einem DHCPOFFER. Das geht alle paar sekunden so. Sieht aber so aus, als redeten Server und Client aneinander vorbei, ich kann auf dem Sever kein DHCPREQUEST vom Client finden (siehe Bilder im Anhang).
Mir ist vollkommen klar, das meine Infos oben nur rudimentär sind. Ich denke aber, damit kann man starten. Bei Bedarf liefere ich gern gezielt Infos nach.
Ich würde mich freuen, wenn mir jemand Tipps zum Eingrenzen/Beheben der Ursache geben kann.
ich habe seit Tagen ein riesen Problem im LAN und komme nichjt mehr weiter. Nach vielen Recherchen Installationen, Deinstallationen, Neukonfigurieren geht mir langsam die Luft aus. Hier im Forum gabs das Thema auch schon mehrfach, half mir aber nicht weiter.
Die Rahmenparameter
LAN mit ca 30 Clients, WIN 7, Android, SONOS u.v.m
Fritzbox 7390 mit deaktiviertem DHCP als WAN-Gateway
Server 2008R2 mit AD, DNS, DHCP, IIS, HyperV (aktuell ohne aktivem Gast), PRTG Network Monitor, 3 NIC's (davon 2 aktuell deaktiviert)
zentraler Switch Netgear GS716T
Die Vorgeschichte
Vor einer Woche lief alles problemlos. Auf Grund eines Provider-Wechsels kam eine Fritzbox ins LAN. 3 Tage später habe ich testweise die Subnetzmaske von 255.255.255.0 auf dem 2008R2 auf 255.255.0.0 geändert, um den erreichbaren Adressbereich zu erweitern.
Anfangs funktionierte alles, einige Stunden später haben sich einige Dienste auf dem Server zerlegt, ich kam auch nicht mehr Remote auf den Server drauf.
Bin dann direkt an den Server, hab einen Restart gemacht. Dienste liefen alle wieder.
Allerdings hatte ich da schon Probleme, interne Clients vom Server aus zu erreichen. Was es genau war, vermag ich nicht mehr zu sagen. Ich habe dann die Subnetzmaske wieder auf 255.255.255.0 zurück geändert (auf der Server-NIC).
Seit dem kann ich meine SONOS-Clients nicht mehr erreichen. Offensichtlich liegt der Grund darin, dass die Clients keine DHCP-Adressen mehr bekommen. Das Problem lässt sich mit Android- und WIN7-Clients nachstellen. Vergebe ich feste Adressen auf den Clients (bei SONOS geht das nicht), läuft alles wunderbar.
Ich habe dann den DHCP-Server deinstalliert, dessen Config (/system32/dhcp) gelöscht, neu Installiert, autorisiert - keine fehler lt. Ereignisprotkoll. Noch immer keine IP-Vergabe via DHCP.
Zwischendurch mal den zentralen LAN-Switch auf Werkseinstellungen zurück gesetzt, stromlos gemacht - keine Änderung
Dann den DHCP-Server nochmal deinstalliert, Konfig gelöscht, HyperV deinstalliert, DHCP neu installiert, konfiguriert, autorisiert - keine Besserung.
Aktueller Stand
Ich habe dann per NetMon den DHCP-Verkehr auf der Server-NIC mitgeschnitten. Wenn ich das mit meinem Halbwissen richtig interpretiere, sendet der Client via Broadcastadresse einen korrekten DHCPDISCOVER an den Server, der antwortet auch mit einem DHCPOFFER. Das geht alle paar sekunden so. Sieht aber so aus, als redeten Server und Client aneinander vorbei, ich kann auf dem Sever kein DHCPREQUEST vom Client finden (siehe Bilder im Anhang).
Mir ist vollkommen klar, das meine Infos oben nur rudimentär sind. Ich denke aber, damit kann man starten. Bei Bedarf liefere ich gern gezielt Infos nach.
Ich würde mich freuen, wenn mir jemand Tipps zum Eingrenzen/Beheben der Ursache geben kann.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 221578
Url: https://administrator.de/contentid/221578
Printed on: April 19, 2024 at 14:04 o'clock
15 Comments
Latest comment
Eine Frage vorweg: Als was fungierst du in diesem Netzwerk und was für eine Art Netzwerk ist es?
Hi certifiedit,
es handelt ich um mein privates LAN, ich bin der Admin (ich hoffe, ich hab die Frage richtig verstanden)
es handelt ich um mein privates LAN, ich bin der Admin (ich hoffe, ich hab die Frage richtig verstanden)
Hi!
kannst du einen Client direkt mit einem kleinen Switch an den 2008R2 hängen?
Dann weißt du zumindest mal, dass dir kein Switch, Client oder Fritzbox dazwischen funkt.
sg Dirm
kannst du einen Client direkt mit einem kleinen Switch an den 2008R2 hängen?
Dann weißt du zumindest mal, dass dir kein Switch, Client oder Fritzbox dazwischen funkt.
sg Dirm
guter Punkt. Ich hab eben testweise einen GS105 rausgekramt, den direkt mit der NIC des Servers verbunden und bin mit einem WIN7-Client direkt an den GS105.
Ergebnis: die NIC des WIN7-Clients bekommt vom WIN7 eine Adresse verpasst (192.168.254.x), nicht vom Server.
Ergebnis: die NIC des WIN7-Clients bekommt vom WIN7 eine Adresse verpasst (192.168.254.x), nicht vom Server.
Zitat von @Raketenschnecke:
guter Punkt. Ich hab eben testweise einen GS105 rausgekramt, den direkt mit der NIC des Servers verbunden und bin mit einem
WIN7-Client direkt an den GS105.
Ergebnis: die NIC des WIN7-Clients bekommt vom WIN7 eine Adresse verpasst (192.168.254.x), nicht vom Server.
guter Punkt. Ich hab eben testweise einen GS105 rausgekramt, den direkt mit der NIC des Servers verbunden und bin mit einem
WIN7-Client direkt an den GS105.
Ergebnis: die NIC des WIN7-Clients bekommt vom WIN7 eine Adresse verpasst (192.168.254.x), nicht vom Server.
Das ist keine Adresse, die verpasst wird, das ist eine Adresse, die als Failover genutzt wird, wenn sonst kein DHCP vorhanden ist. Daher: DHCP reparieren oder von jemanden reparieren lassen.
Abgesehen davon ein 16er ? Netz macht keinen Sinn. Nirgends.
deswegen bin ich hier
War ein fehler, der bereits schwer bestraft wurde. Deswegen bin ich aktuell wieder bei /24
Das ist keine Adresse, die verpasst wird, das ist eine Adresse, die als Failover genutzt wird, wenn sonst kein DHCP vorhanden ist.
probier mal:
ipconfig /release
ipconfig /renew
am Client und dann schau in die Logs auf Server und Client.
Versuch dich mal zu erinnern was du noch alles verändert hast.
Passen die statischen IP-Einstellungen am Server?
Ist der DHCP auf der richtigen NIC? (oder geht das eh nicht wenn die anderen deaktiviert sind k.A.)
sorry, ja: 169.254.x.x
IPconfig /release hatte ich 2 mal ausgeführt, ohne Erfolg (bzw. mit dem Ergebnis 169.254)
Logs hab ich mir nicht angeschaut, ich mach gleich nochmal einen Lauf.
Mit dem Erinnern sieht schlecht aus: ich hab jetzt 2 tage recherchiert, ausprobiert, installiert, deinstalliert, gebootet - sorry, ich hab echt die Orientierung verloren ;-(
die IP-Einstellungen der NIC sind statisch (die .70.240 der obigen Bilder ist der Server):
IP-Adresse .70.240,
Subnetzmaske 255.255.255.0,
Gateway: 70.254,
DNS-Server: .70.240 (quasi die eigene Adresse)
Der DHCP-Server ist nur an die .240 gebunden (keine IPV6 Bindung), ebenso der DNS-Server
IPconfig /release hatte ich 2 mal ausgeführt, ohne Erfolg (bzw. mit dem Ergebnis 169.254)
Logs hab ich mir nicht angeschaut, ich mach gleich nochmal einen Lauf.
Mit dem Erinnern sieht schlecht aus: ich hab jetzt 2 tage recherchiert, ausprobiert, installiert, deinstalliert, gebootet - sorry, ich hab echt die Orientierung verloren ;-(
die IP-Einstellungen der NIC sind statisch (die .70.240 der obigen Bilder ist der Server):
IP-Adresse .70.240,
Subnetzmaske 255.255.255.0,
Gateway: 70.254,
DNS-Server: .70.240 (quasi die eigene Adresse)
Der DHCP-Server ist nur an die .240 gebunden (keine IPV6 Bindung), ebenso der DNS-Server
Vielleicht noch ein Nachtrag: der BestPractice-Analyzer im Rollenmanager bringt ausschließlich positive Ergebnisse. Der findet das Problem also auch nicht.
ich hab mal die Windows-Systemlog Einträge rausgekramt:
1. Verbindung mit LAN-NIC:
Intel(R) 82579LM Gigabit Network Connection
Die Netzwerkverbindung wurde mit 1 Gbit/s Vollduplex hergestellt.
2. Warnung:
Zeitüberschreitung bei der Namensauflösung für den Namen dsn15.d.skype.net, nachdem keiner der konfigurierten DNS-Server geantwortet hat.
3. Info
Der Suchdienst hat eine Wahl auf dem Netzwerk "\Device\NetBT_Tcpip_{DAD883B3-4609-4B0F-8E02-F9FEADB37539}" erzwungen, da der Hauptsuchdienst beendet wurde.
4. Info (ich hatte auch die Diagnose gestartet)
Die Reparaturphase des Vorgangs wurde abgeschlossen. Die folgende Reparaturoption bzw. der folgende Workaround wurde ausgeführt:
Hilfsklassenname: AddressAcquisition
Reparaturoption: "LAN-Verbindung" zurücksetzen
Manchmal können hierdurch Unterbrechungen behoben werden.
Reparatur-GUID: {07d37f7b-fa5e-4443-bda7-ab107b29afb9}
Das diagnostizierte Problem wurde durch die Reparaturoption scheinbar erfolgreich behoben. NDF hat jedoch andere Netzwerkprobleme erkannt. NDF sollte erneut ausgeführt werden, um diese Probleme zu diagnostizieren.
5. Info
Details zu Netzwerkadapter Diagnose:
Treiberinformationen für Netzwerkadapter LAN-Verbindung:
Beschreibung . . . . . . . . . . : Intel(R) 82579LM Gigabit Network Connection
Hersteller . . . . . . . . . : Intel
Anbieter . . . . . . . . . . . : Intel
Version . . . . . . . . . . . : 11.15.16.0
INF-Dateiname . . . . . . . . . : C:\Windows\INF\oem53.inf
INF-Dateidatum . . . . . . . . . : Dienstag, 24. Januar 2012 07:25:12
Abschnittsname . . . . . . . . . : E1502.6.1.1
Hardware-ID . . . . . . . . . . : pci\ven_8086&dev_1502
Instanzstatusflags . . . . . : 0x180200a
Geräte-Manager-Statuscode . . : 0
Schnittstellentyp . . . . . . . . . . . . : 6
Typ des physikalischen Mediums . . . . . . : 14
6. Info
Die Diagnosephase des Vorgangs wurde abgeschlossen. Die folgende Reparaturoption wurde angeboten:
Hilfsklassenname: AddressAcquisition
Zugrunde liegende Ursache: Das Standardgateway ist nicht verfügbar.
Das Standardgateway ist ein Gerät zum Herstellen der Verbindung zwischen einem lokalen Netzwerk oder Computer und dem Internet. In der Regel wird ein Breitbandmodem oder Router als Standardgateway verwendet.
GUID der zugrunde liegenden Ursache: {aa537141-c1af-4bf0-b8a3-fcf94c877aef}
Reparaturoption: Router- oder Breitbandmodemprobleme untersuchen
Wenden Sie sich an den Netzwerkadministrator, wenn Sie mit einem Hotspot oder Domänennetzwerk verbunden sind. Andernfalls:
1. Entfernen Sie das Gerät bzw. schalten Sie es aus.
2. Warten Sie 10 Sekunden, nachem die Lampen des Geräts aus sind.
3. Schalten Sie das Gerät ein bzw. schließen Sie es an die Steckdose an.
Zum Neustarten eines Routers oder Modems mit integriertem Akku drücken Sie kurz die Rücksetztaste.
Reparatur-GUID: {9513cc1c-4a26-4cb8-bf89-0a82129bd105}
Erforderliche Zeit für die Reparatur in Sekunden: 63
Für die Reparatur erforderlicher Sicherheitskontext: 0
7. Info
Die Diagnosephase des Vorgangs wurde abgeschlossen. Die folgende Reparaturoption wurde angeboten:
Hilfsklassenname: AddressAcquisition
Zugrunde liegende Ursache: Das Standardgateway ist nicht verfügbar.
Das Standardgateway ist ein Gerät zum Herstellen der Verbindung zwischen einem lokalen Netzwerk oder Computer und dem Internet. In der Regel wird ein Breitbandmodem oder Router als Standardgateway verwendet.
GUID der zugrunde liegenden Ursache: {aa537141-c1af-4bf0-b8a3-fcf94c877aef}
Reparaturoption: "LAN-Verbindung" zurücksetzen
Manchmal können hierdurch Unterbrechungen behoben werden.
Reparatur-GUID: {07d37f7b-fa5e-4443-bda7-ab107b29afb9}
Was mich irritiert, ist das fehlende Standard-Gateway. Das wird doch im DHCPOFFER (siehe Bild Post 1) übergeben?!
1. Verbindung mit LAN-NIC:
Intel(R) 82579LM Gigabit Network Connection
Die Netzwerkverbindung wurde mit 1 Gbit/s Vollduplex hergestellt.
2. Warnung:
Zeitüberschreitung bei der Namensauflösung für den Namen dsn15.d.skype.net, nachdem keiner der konfigurierten DNS-Server geantwortet hat.
3. Info
Der Suchdienst hat eine Wahl auf dem Netzwerk "\Device\NetBT_Tcpip_{DAD883B3-4609-4B0F-8E02-F9FEADB37539}" erzwungen, da der Hauptsuchdienst beendet wurde.
4. Info (ich hatte auch die Diagnose gestartet)
Die Reparaturphase des Vorgangs wurde abgeschlossen. Die folgende Reparaturoption bzw. der folgende Workaround wurde ausgeführt:
Hilfsklassenname: AddressAcquisition
Reparaturoption: "LAN-Verbindung" zurücksetzen
Manchmal können hierdurch Unterbrechungen behoben werden.
Reparatur-GUID: {07d37f7b-fa5e-4443-bda7-ab107b29afb9}
Das diagnostizierte Problem wurde durch die Reparaturoption scheinbar erfolgreich behoben. NDF hat jedoch andere Netzwerkprobleme erkannt. NDF sollte erneut ausgeführt werden, um diese Probleme zu diagnostizieren.
5. Info
Details zu Netzwerkadapter Diagnose:
Treiberinformationen für Netzwerkadapter LAN-Verbindung:
Beschreibung . . . . . . . . . . : Intel(R) 82579LM Gigabit Network Connection
Hersteller . . . . . . . . . : Intel
Anbieter . . . . . . . . . . . : Intel
Version . . . . . . . . . . . : 11.15.16.0
INF-Dateiname . . . . . . . . . : C:\Windows\INF\oem53.inf
INF-Dateidatum . . . . . . . . . : Dienstag, 24. Januar 2012 07:25:12
Abschnittsname . . . . . . . . . : E1502.6.1.1
Hardware-ID . . . . . . . . . . : pci\ven_8086&dev_1502
Instanzstatusflags . . . . . : 0x180200a
Geräte-Manager-Statuscode . . : 0
Schnittstellentyp . . . . . . . . . . . . : 6
Typ des physikalischen Mediums . . . . . . : 14
6. Info
Die Diagnosephase des Vorgangs wurde abgeschlossen. Die folgende Reparaturoption wurde angeboten:
Hilfsklassenname: AddressAcquisition
Zugrunde liegende Ursache: Das Standardgateway ist nicht verfügbar.
Das Standardgateway ist ein Gerät zum Herstellen der Verbindung zwischen einem lokalen Netzwerk oder Computer und dem Internet. In der Regel wird ein Breitbandmodem oder Router als Standardgateway verwendet.
GUID der zugrunde liegenden Ursache: {aa537141-c1af-4bf0-b8a3-fcf94c877aef}
Reparaturoption: Router- oder Breitbandmodemprobleme untersuchen
Wenden Sie sich an den Netzwerkadministrator, wenn Sie mit einem Hotspot oder Domänennetzwerk verbunden sind. Andernfalls:
1. Entfernen Sie das Gerät bzw. schalten Sie es aus.
2. Warten Sie 10 Sekunden, nachem die Lampen des Geräts aus sind.
3. Schalten Sie das Gerät ein bzw. schließen Sie es an die Steckdose an.
Zum Neustarten eines Routers oder Modems mit integriertem Akku drücken Sie kurz die Rücksetztaste.
Reparatur-GUID: {9513cc1c-4a26-4cb8-bf89-0a82129bd105}
Erforderliche Zeit für die Reparatur in Sekunden: 63
Für die Reparatur erforderlicher Sicherheitskontext: 0
7. Info
Die Diagnosephase des Vorgangs wurde abgeschlossen. Die folgende Reparaturoption wurde angeboten:
Hilfsklassenname: AddressAcquisition
Zugrunde liegende Ursache: Das Standardgateway ist nicht verfügbar.
Das Standardgateway ist ein Gerät zum Herstellen der Verbindung zwischen einem lokalen Netzwerk oder Computer und dem Internet. In der Regel wird ein Breitbandmodem oder Router als Standardgateway verwendet.
GUID der zugrunde liegenden Ursache: {aa537141-c1af-4bf0-b8a3-fcf94c877aef}
Reparaturoption: "LAN-Verbindung" zurücksetzen
Manchmal können hierdurch Unterbrechungen behoben werden.
Reparatur-GUID: {07d37f7b-fa5e-4443-bda7-ab107b29afb9}
Was mich irritiert, ist das fehlende Standard-Gateway. Das wird doch im DHCPOFFER (siehe Bild Post 1) übergeben?!
Was mich irritiert, ist das fehlende Standard-Gateway. Das wird doch im DHCPOFFER (siehe Bild Post 1) übergeben?!
fehlt das am Server oder am Client? Woher sind diese Logs?falls die Logs von dem Test sind, als nur der eine Client am Switch hing, dann ist's ja wohl klar...
Schau noch einmal in Ruhe alle Einstellungen im DHCP durch. Außerdem: Sind sicher keine Adressen ausm DHCP-Bereich fix vergeben, Zeigt der DHCP Server den Lease an, ...
Wenn du da nichts findest deaktivieren ihn und wirf, den in der FB an. (Kannst du auch mal testweise machen ob irgendwas "anderes" deinen DHCP-Verkehr stört - Server weg vom Switch -> Client testen, dann mal mit dem Server.)
Wenn das auch nichts hilft - mach den Server neu
ich hab jetzt 2 tage recherchiert, ausprobiert, installiert, deinstalliert, gebootet - sorry, ich hab echt die Orientierung verloren ;-(
kein Problem - DU musst den Server neu aufsetzen man kann dir halt schwer helfen, weil hier weiß noch weniger jemand, welche Dateien du zufällig gelöscht hast oder wo du herum gestellt hast...
sg Dirm
fehlt das am Server oder am Client? Woher sind diese Logs?
falls die Logs von dem Test sind, als nur der eine Client am Switch hing, dann ist's ja wohl klar...
falls die Logs von dem Test sind, als nur der eine Client am Switch hing, dann ist's ja wohl klar...
ups, vergessen, ja: , das sind die Logs vom Test (Clientseitig)
Schau noch einmal in Ruhe alle Einstellungen im DHCP durch. Außerdem: Sind sicher keine Adressen ausm DHCP-Bereich fix
vergeben, Zeigt der DHCP Server den Lease an, ...
der DHCP Server zeigt keine Leases anvergeben, Zeigt der DHCP Server den Lease an, ...
Wenn du da nichts findest deaktivieren ihn und wirf, den in der FB an. (Kannst du auch mal testweise machen ob irgendwas
"anderes" deinen DHCP-Verkehr stört - Server weg vom Switch -> Client testen, dann mal mit dem Server.)
ich hatte den DHCP-Server schon mal deaktiviert und den in der FB aktiviert. Gleiches Ergebnis. Allerdings war der Server noch im LAN. vielleicht prisch ich mich mal ran, in dem ich es direkt an der FB und stand alone (also ohne LAN) versuche und dann Stück für Stück weiter...."anderes" deinen DHCP-Verkehr stört - Server weg vom Switch -> Client testen, dann mal mit dem Server.)
Wenn das auch nichts hilft - mach den Server neu
große Bauchschmerzen!> ich hab jetzt 2 tage recherchiert, ausprobiert, installiert, deinstalliert, gebootet - sorry, ich hab echt die Orientierung
verloren ;-(
verloren ;-(
man kann dir halt schwer helfen, weil hier weiß noch weniger jemand, welche Dateien du zufällig gelöscht hast oder
wo du herum gestellt hast...
wo du herum gestellt hast...
ja, dessen bin ich mir bewusst. Dateien gelöscht habe ich aber - ganz sicher - nur die DHCP-Config, nicht mehr. Ich hatte gehofft, über das Mitsniffen des DHCP-Verkehrs hier entscheidende Hinweise zu bekommen
Nachtrag: ich habe im LAN auch regelmäßig nach DHCP-Servern gescannt - es gab immer nur diesen einen, der auch als AD-autorisiert angezeigt wurde.
Nur am Anfang der probleme wurden mehrere DHCP-Server angezeigt (im Nachinein glaube ich, da war der von der HyperV-Installation dabei)
Hallo Jobiwan,
um die Ecke gedacht (also ohne fern-diagnostisch unscharfe Konfiguration des Win DHCP-Servers) würde ich es mal mit folgendem Workaround versuchen, wenigstens zur Fehlereingrenzung: Deaktiviere den Win-DHCP-Server und aktiviere stattdessen den in der FritzBox. Auch der lässt andere Subnetzmasken als die 3 x 255 zu. Sollte das funktionieren hättest wenigsten weniger Druck bei der weiteren Fehlersuche, zu der ich folgende Frage habe: Wie reagiert der Win-DHCP denn, wenn alle drei Server-NICs aktiviert sind?
Schöne Grüße
um die Ecke gedacht (also ohne fern-diagnostisch unscharfe Konfiguration des Win DHCP-Servers) würde ich es mal mit folgendem Workaround versuchen, wenigstens zur Fehlereingrenzung: Deaktiviere den Win-DHCP-Server und aktiviere stattdessen den in der FritzBox. Auch der lässt andere Subnetzmasken als die 3 x 255 zu. Sollte das funktionieren hättest wenigsten weniger Druck bei der weiteren Fehlersuche, zu der ich folgende Frage habe: Wie reagiert der Win-DHCP denn, wenn alle drei Server-NICs aktiviert sind?
Schöne Grüße
Hi spinnifex,
ich bin noch immer mitten in der fehlersuche. Mittlerweile den 3. tag. Gestern Abend habe ich meine komplette LAN-Verkabelung auseinander genommen und dabei einen Verkabelungsfehler gefunden. Der hat zwar Probleme gemacht, war aber nicht die Ursache.
Aktue3ll bin ich soweit, dass ich die FB als DHCP-Server im LAN habe.
Das Kuriose:
wenn ich den WNDR3700 WLAN-AP direkt an die FB klemme und mir über ihn die IP von der FB hole, klappt es problemlos. Gehe ich aber mit der FB zunächst an den zentralen Switch (NG GS716T), dann an den WNDR3700, bekommen dieClients (egal ob Android oder WIN7) keine IP. Hä?
Der zentrale Swicht ist bereits auf Werkseinstellungen resettet, ebenso wie der WNDR3700. Aktuell habe ich keinerlei weitere Geräte am Switch, nur die FB und den WNDR. AM WNDR 1-2 Clients. Verkabelung am Switch abgeklemmt. Ich versteh's nicht.
ich bin noch immer mitten in der fehlersuche. Mittlerweile den 3. tag. Gestern Abend habe ich meine komplette LAN-Verkabelung auseinander genommen und dabei einen Verkabelungsfehler gefunden. Der hat zwar Probleme gemacht, war aber nicht die Ursache.
Aktue3ll bin ich soweit, dass ich die FB als DHCP-Server im LAN habe.
Das Kuriose:
wenn ich den WNDR3700 WLAN-AP direkt an die FB klemme und mir über ihn die IP von der FB hole, klappt es problemlos. Gehe ich aber mit der FB zunächst an den zentralen Switch (NG GS716T), dann an den WNDR3700, bekommen dieClients (egal ob Android oder WIN7) keine IP. Hä?
Der zentrale Swicht ist bereits auf Werkseinstellungen resettet, ebenso wie der WNDR3700. Aktuell habe ich keinerlei weitere Geräte am Switch, nur die FB und den WNDR. AM WNDR 1-2 Clients. Verkabelung am Switch abgeklemmt. Ich versteh's nicht.
Hallo in die Runde,
ich habe gestern nach ca 30 Stunden Fehlersuche den Fehler eingegrenzt und die Ursache behoben. Jetzt läuft wieder (fast) alles wie vorher. Es war nicht der DCHP-Server, keine störende FB7390, kein Konfigurationsproblem auf dem Server - es war schlicht und einfach der zentrale Switch (Netgear GS716T).
Ich hatte vor einer Woche ein Firmwareupdate gemacht (auf 5.4.2.9). Die Eingangs beschrieben Fehler traten jedoch erst 3 Tage später (Nachts) auf, so dass ich gar nicht auf die Idee kam, das damit in Verbindung zu bringen (vermutlich war das die Lease Time für die IP-Adressen, die abgelaufen war). Weiterhin hatte ich zwischenzeitlich an einigen Stellen im LAN und am Server rumgeschraubt - so dass ich damit alle Spuren erfolgreich verwischt hatte.
Ich hatte zwar den Switch zwischendruch mehrfach ressettet, stromlos gemacht etc....aber diesen als eigentliche Störquelle nie wirklich in Verdacht gehabt.
Erst nachdem ich gestern wirklich alle Komponenten aus dem LAN entfernt habe und das LAN dann Stück für Stück physisch neu aufgebaut habe, dämmerte mir: da steckt bestimmt der Switch dahinter!
Allen, die sich hier Gedanken zur Lösungsfindung gemacht haben - herzlichen Dank! Der Beistand hier hat sehr geholfen, mich immer wieder neu zu motivieren.
ich habe gestern nach ca 30 Stunden Fehlersuche den Fehler eingegrenzt und die Ursache behoben. Jetzt läuft wieder (fast) alles wie vorher. Es war nicht der DCHP-Server, keine störende FB7390, kein Konfigurationsproblem auf dem Server - es war schlicht und einfach der zentrale Switch (Netgear GS716T).
Ich hatte vor einer Woche ein Firmwareupdate gemacht (auf 5.4.2.9). Die Eingangs beschrieben Fehler traten jedoch erst 3 Tage später (Nachts) auf, so dass ich gar nicht auf die Idee kam, das damit in Verbindung zu bringen (vermutlich war das die Lease Time für die IP-Adressen, die abgelaufen war). Weiterhin hatte ich zwischenzeitlich an einigen Stellen im LAN und am Server rumgeschraubt - so dass ich damit alle Spuren erfolgreich verwischt hatte.
Ich hatte zwar den Switch zwischendruch mehrfach ressettet, stromlos gemacht etc....aber diesen als eigentliche Störquelle nie wirklich in Verdacht gehabt.
Erst nachdem ich gestern wirklich alle Komponenten aus dem LAN entfernt habe und das LAN dann Stück für Stück physisch neu aufgebaut habe, dämmerte mir: da steckt bestimmt der Switch dahinter!
Allen, die sich hier Gedanken zur Lösungsfindung gemacht haben - herzlichen Dank! Der Beistand hier hat sehr geholfen, mich immer wieder neu zu motivieren.
