7
In Windows 2012-AD: eingeschränkte Netzwerkverbindung (bzw. kein Internetzugriff) einiger Clients trotz erfolgreichem DHCP.
Die Kopfnuss: Nahezu identische Clients bekommen von Windows Server2012-DHCP erfolgreich IP/DNS/Gateway, aber einige haben absolut reproduzierbar keine Zugriff auf das Internet (und andere Clients im gleichen Netz). Alles sind VMs auf dem gleichen ESXi-Host, physikalische Netzwerkkomponenten als Fehlerquelle können also ausgeschlossen werden.
Bei den Patienten: Gateway ist nicht pingbar, obwohl über DHCP erfolgreich eingetragen. Andere Clients sind nicht pingbar. Der Patient ist von gesunden Clients nicht pingbar. ABER: der Domänencontroller, der ja auch DHCP-Server ist, ist uneingeschränkt erreichbar (ping, logon, shares, etc.)
Es muss etwas mit dem jeweiligen Netzwerkadapter (MAC-Adresse) UND der IP zu tun haben. Denn es wird kurioser:
1. Vergebe ich manuell eine andere IP beim Patienten ist alles gut.
2. Vergebe ich manuell die gleiche IP, die der Patient auch via DHCP zugewiesen bekommt, beschriebene Problematik: Kein internet
3. Vergebe ich diese IP, mit der beim Patienten nichts geht, manuell an einen gesunden Client ist ebenfalls alles gut.
Ergo: Gewisse IP-Adressen weisen manuell und via DHCP in Kombination mit bestimmten Netzwerkadaptern oben beschriebene Probleme (eingeschränkte Netzwerkkonnektivität) auf.
Dies ist alles absolut reproduzierbar isoliert innerhalb einer virtualisierten Umgebung, aber unter dem Problem leiden auch alle physischen Clients unterschiedlichster Art: Macs mit OS X, iPhones, eine HP-Workstation mit Windows7 Pro...
Meine Fragen:
Ich glaube, dass es ein Windows Server Problem ist - DNS, DHCP, irgend ein Filter, der sagt, dass eine bestimmte MAC-Adresse mit einer bestimmten IP nicht mehr darf? Aber wo fange ich an zu suchen? Gibt es für so einen Fall ein nützliches Diagnose-Tool? Ein hilfreiches Serverlog, von dem ich nix weiß? Es kommt mir so vor, als ob es irgendwo im Netzwerk eine Instanz gibt, die sagt: "diese IP mit diesem Netzwerkadapter nicht mehr!" Wo merkt sich der DHCP-Server eigentlich, dass einer MAC-Adresse immer die gleiche IP zugewiesen wird, selbst wenn es dafür keine Reservierung gibt?
Zusatzinformationen: Das Gateway ist eine Fritz.Box, es gibt zwei Switche (D-Link DGS 1216T, Linksys SLM224G), Domänencontroller/DHCP/DNS-Server ist ein virtualisierter Windows Server 2012 Standard.
Bei den Patienten: Gateway ist nicht pingbar, obwohl über DHCP erfolgreich eingetragen. Andere Clients sind nicht pingbar. Der Patient ist von gesunden Clients nicht pingbar. ABER: der Domänencontroller, der ja auch DHCP-Server ist, ist uneingeschränkt erreichbar (ping, logon, shares, etc.)
Es muss etwas mit dem jeweiligen Netzwerkadapter (MAC-Adresse) UND der IP zu tun haben. Denn es wird kurioser:
1. Vergebe ich manuell eine andere IP beim Patienten ist alles gut.
2. Vergebe ich manuell die gleiche IP, die der Patient auch via DHCP zugewiesen bekommt, beschriebene Problematik: Kein internet
3. Vergebe ich diese IP, mit der beim Patienten nichts geht, manuell an einen gesunden Client ist ebenfalls alles gut.
Ergo: Gewisse IP-Adressen weisen manuell und via DHCP in Kombination mit bestimmten Netzwerkadaptern oben beschriebene Probleme (eingeschränkte Netzwerkkonnektivität) auf.
Dies ist alles absolut reproduzierbar isoliert innerhalb einer virtualisierten Umgebung, aber unter dem Problem leiden auch alle physischen Clients unterschiedlichster Art: Macs mit OS X, iPhones, eine HP-Workstation mit Windows7 Pro...
Meine Fragen:
Ich glaube, dass es ein Windows Server Problem ist - DNS, DHCP, irgend ein Filter, der sagt, dass eine bestimmte MAC-Adresse mit einer bestimmten IP nicht mehr darf? Aber wo fange ich an zu suchen? Gibt es für so einen Fall ein nützliches Diagnose-Tool? Ein hilfreiches Serverlog, von dem ich nix weiß? Es kommt mir so vor, als ob es irgendwo im Netzwerk eine Instanz gibt, die sagt: "diese IP mit diesem Netzwerkadapter nicht mehr!" Wo merkt sich der DHCP-Server eigentlich, dass einer MAC-Adresse immer die gleiche IP zugewiesen wird, selbst wenn es dafür keine Reservierung gibt?
Zusatzinformationen: Das Gateway ist eine Fritz.Box, es gibt zwei Switche (D-Link DGS 1216T, Linksys SLM224G), Domänencontroller/DHCP/DNS-Server ist ein virtualisierter Windows Server 2012 Standard.
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: 224765
Url: https://administrator.de/contentid/224765
Printed on: April 23, 2024 at 20:04 o'clock
7 Comments
Latest comment
Hallo,
Nicht wirklich
Schon mal den IPStack zurückgesetzt? Netsh IP Reset Logdatei
Gruß,
Peter
Nicht wirklich
Es muss etwas mit dem jeweiligen Netzwerkadapter (MAC-Adresse) UND der IP zu tun haben.
Ich würde jetzt als erstes mal darauf hinweissen das irgendein Client/Rechner/PC/Laptop/Drucker/Eierfon/Androider/Drucker/Playstation/XBox/Linux/Marsianer oder was auch immer diese IPS schon verwenden in deinem Netz (per Switch/VLAN/Router usw. erreichbar).2. Vergebe ich manuell die gleiche IP, die der Patient auch via DHCP zugewiesen bekommt, beschriebene Problematik: Kein internet
3. Vergebe ich diese IP, mit der beim Patienten nichts geht, manuell an einen gesunden Client ist ebenfalls alles gut.
Irgendwo dort ist aber etwas entscheidendes anders eingetagen oder eben nicht eingetragen.3. Vergebe ich diese IP, mit der beim Patienten nichts geht, manuell an einen gesunden Client ist ebenfalls alles gut.
Schon mal den IPStack zurückgesetzt? Netsh IP Reset Logdatei
Ich glaube,
Ist schon Freitag? Gibt es für so einen Fall ein nützliches Diagnose-Tool?
IPConfig /all, IFConfig, Ping, DHCP Log, DNS Log....Wo merkt sich der DHCP-Server eigentlich, dass einer MAC-Adresse immer die gleiche IP zugewiesen wird, selbst wenn es dafür keine Reservierung gibt?
Ohne eine gültige Reservierung kann ein DHCP das nicht.Gruß,
Peter
Danke Peter!
Der Teufel liegt im Detail (du siehst, ich muss katholisch sein).
Kopfnuss deshalb, weil der Vorgang ja normalerweise so simpel ist: IP frei -> wird über DHCP an Client vergeben -> client hat via DHCP IP, Gateway, DNS-Server erhalten -> alles gut.
Das Problem ist nicht auf eine Adresse beschränkt es geht um einige Clients, die dieses Problem plagt. Konflikte würde ich in der DHCP-Konsole auf dem Server ja sehen. Ich hab das alles am Wochenende mal durchgetestet wo die aktiven Geräte im Netzwerk extremste überschaubar ist. Insgesamt ist das Netzwerk nicht sonderlich komplex (keine vLANs etc.)
Mit Ping, IPconfig, DHCP Log etc. hab ich mich schon abgearbeitet. Tracert auch. Die Logs sind prinzipielle voller Erfolgsmeldungen. Nur wenn man anfängt zu Pingen geht halt nix.
Der Teufel liegt im Detail (du siehst, ich muss katholisch sein).
Kopfnuss deshalb, weil der Vorgang ja normalerweise so simpel ist: IP frei -> wird über DHCP an Client vergeben -> client hat via DHCP IP, Gateway, DNS-Server erhalten -> alles gut.
Das Problem ist nicht auf eine Adresse beschränkt es geht um einige Clients, die dieses Problem plagt. Konflikte würde ich in der DHCP-Konsole auf dem Server ja sehen. Ich hab das alles am Wochenende mal durchgetestet wo die aktiven Geräte im Netzwerk extremste überschaubar ist. Insgesamt ist das Netzwerk nicht sonderlich komplex (keine vLANs etc.)
Mit Ping, IPconfig, DHCP Log etc. hab ich mich schon abgearbeitet. Tracert auch. Die Logs sind prinzipielle voller Erfolgsmeldungen. Nur wenn man anfängt zu Pingen geht halt nix.
Zitat von @Pjordorf:
> Zitat von @mattes7777:
> Wo merkt sich der DHCP-Server eigentlich, dass einer MAC-Adresse immer die gleiche IP zugewiesen wird, selbst wenn es
dafür keine Reservierung gibt?
Ohne eine gültige Reservierung kann ein DHCP das nicht.
> Zitat von @mattes7777:
> Wo merkt sich der DHCP-Server eigentlich, dass einer MAC-Adresse immer die gleiche IP zugewiesen wird, selbst wenn es
dafür keine Reservierung gibt?
Ohne eine gültige Reservierung kann ein DHCP das nicht.
Dachte ich auch. Normalerweise kommt es ja vor, dass man nach de- und reaktivieren eines Netzwerkadapters - oder, wenn man so will - wenn man mal das Kabel aus der Buchse raus und wieder rein hat, vom DHCP mal ne andere Adresse zugewiesen bekommt. Passiert in meinem Netzwerk leider nicht.
Hallo,
Und wenn du diese von dir genannte Meldung bekommst
dann ist dir doch klar das die entsprechende Firewall das Öffentliche Profil zuordnet und du dann eben keine Antwort vom ICMP bekommst (je nach Einstellung deiner FW Profile kannst du auch gar kein ICMP senden) ....
Und da bei alle in einer VM laufen, hast du doch ein prima Testnetz was du doch ganz einfach durch deinen Virtuellen Switch vom Produktivnetz trennen kannst zwecks Fehlerforschung
Es hat schon Gründe warum immer Empfohlen wird eine Manuelle IP niemals aus einem Lease Bereich eines DHCP zu nehmen
Vergebe eine Manuelle IP ausserhalb des Lease Bereichs deines DHCP, ändere Schnittstelle auf DHCP um, ziehe Kabel, warte 15 Sekunden, Stecke Kabel bzw. RJ-45, mache erneut IPConfig und du wirst eine andere IP erhalten, sofern dein DHCP erreichbar und korrekt arbeitet. Ein Kabelhai oder auch Wireshark genannt hilft dir dies Festzustellen....
Gruß,
Peter
Und wenn du diese von dir genannte Meldung bekommst
eingeschränkte Netzwerkverbindung (bzw. kein Internetzugriff)
wenn man mal das Kabel aus der Buchse raus und wieder rein hat, vom DHCP mal ne andere Adresse zugewiesen bekommt. Passiert in meinem Netzwerk leider nicht.
Auch ein nachvollziehbares nicht Problem. Dein Client fragt ja nur dem DHCP Server ob er diese an seinen Adapter (noch gebundene und gefundene) gefunde IP weiterhin verwenden darf. Warum sollte der DHCP nein sagen, wenn es im korrekten IP Kreis, Lease etc enthalten ist und vor allem frei ist? Ein Lease Bereich im DHCP schreibt ja nicht zwingend vor welche IP du bekommst, nur in welchem Bereich diese liegen werden. Vergibst du Manuelle IPS aus deinem Lease Bereich, änderst die Einstellung anschließend auf DHCP ab, so wirst du weiterhin eine gültige IP haben, eben deine vorher Manuell zugeordnete, nur diesemal per DHCP Anfrage am DHCP und dessen bestätigung. Auch ein Windows merkt sich für eine kurze Zeit die erhaltenene (Eingestellte) IP und versucht diese wieder zu verwenden. IPConfig /release sowie ein IPConfif /flushdns /und eine ARP -d helfen da weiter. Oder ein Rechner neustart...Und da bei alle in einer VM laufen, hast du doch ein prima Testnetz was du doch ganz einfach durch deinen Virtuellen Switch vom Produktivnetz trennen kannst zwecks Fehlerforschung
Es hat schon Gründe warum immer Empfohlen wird eine Manuelle IP niemals aus einem Lease Bereich eines DHCP zu nehmen
Vergebe eine Manuelle IP ausserhalb des Lease Bereichs deines DHCP, ändere Schnittstelle auf DHCP um, ziehe Kabel, warte 15 Sekunden, Stecke Kabel bzw. RJ-45, mache erneut IPConfig und du wirst eine andere IP erhalten, sofern dein DHCP erreichbar und korrekt arbeitet. Ein Kabelhai oder auch Wireshark genannt hilft dir dies Festzustellen....
Gruß,
Peter
Lieber Peter,
ich finde es sehr verdienstvoll, dass du versuchst, ausführlich etwas zu meinem Problem zu sagen. Die Standard-Lösungen, die du vorschlägst, und die möglichen Fehlerquellen sind mir bekannt und ich habe bereits einiges an Tests hinter mir.
Es ändert nichts an daran, dass es ein Problem mit bestimmten IP-/MAC-Adressen-Kombinationen gibt. Es ist nun so, dass eine ganze Reihe von IP-Adressen, die einem bestimmten NIC via DHCP zugewiesen werden, dieses problematische Verhalten an den Tag legen:
(Ich habe dazu Serverseitig ein wenig nachgeholfen)
1. Die "nichtfunktionierende" IP-Adresse am DHCP-Server ausgeschlossen. Sagen wir, es war die 192.168.200.35
2. NIC am betroffenen Client deaktiviert, reaktiviert. Nun wurde dem Client eine neue IP zugewiesen: 192.168.200.49. Problem blieb.
3. Schritt 1 und 2 auch für 192.168.200.49 durchgeführt. Nun erhielt der Client 192.168.200.50. Problem blieb.
4. Ich wusste jetzt in diesem Fall, dass alles in Ordnung war, wenn ich dem Client manuell die 192.168.200.101 zugewiesen habe.
5. Also habe ich für die MAC-Adresse des NICs des Clients auf dem DHCP-Server eine Reservierung für die 192.168.200.101 angelegt.
6. NIC am Client deaktiviert/reaktiviert, vom DHCP-Server wird dem Client nun die reservierte IP zugewiesen --> alles in bester Ordnung.
Vielleicht ist es ein ganz, ganz schlichtes Problem, aber ich kapiere die Logik dahinter einfach nicht. Wieso hat ein NIC Probleme mit einer Reihe bestimmter IP-Adressen (die ihm ja sogar über DHCP zugewiesen werden) und ein anderer NIC nicht?
Danke!
ich finde es sehr verdienstvoll, dass du versuchst, ausführlich etwas zu meinem Problem zu sagen. Die Standard-Lösungen, die du vorschlägst, und die möglichen Fehlerquellen sind mir bekannt und ich habe bereits einiges an Tests hinter mir.
Es ändert nichts an daran, dass es ein Problem mit bestimmten IP-/MAC-Adressen-Kombinationen gibt. Es ist nun so, dass eine ganze Reihe von IP-Adressen, die einem bestimmten NIC via DHCP zugewiesen werden, dieses problematische Verhalten an den Tag legen:
(Ich habe dazu Serverseitig ein wenig nachgeholfen)
1. Die "nichtfunktionierende" IP-Adresse am DHCP-Server ausgeschlossen. Sagen wir, es war die 192.168.200.35
2. NIC am betroffenen Client deaktiviert, reaktiviert. Nun wurde dem Client eine neue IP zugewiesen: 192.168.200.49. Problem blieb.
3. Schritt 1 und 2 auch für 192.168.200.49 durchgeführt. Nun erhielt der Client 192.168.200.50. Problem blieb.
4. Ich wusste jetzt in diesem Fall, dass alles in Ordnung war, wenn ich dem Client manuell die 192.168.200.101 zugewiesen habe.
5. Also habe ich für die MAC-Adresse des NICs des Clients auf dem DHCP-Server eine Reservierung für die 192.168.200.101 angelegt.
6. NIC am Client deaktiviert/reaktiviert, vom DHCP-Server wird dem Client nun die reservierte IP zugewiesen --> alles in bester Ordnung.
Vielleicht ist es ein ganz, ganz schlichtes Problem, aber ich kapiere die Logik dahinter einfach nicht. Wieso hat ein NIC Probleme mit einer Reihe bestimmter IP-Adressen (die ihm ja sogar über DHCP zugewiesen werden) und ein anderer NIC nicht?
Danke!
hallo
habe jetzt das selbe phänomen
gab es zu diesem problem eine Lösung?
Danke im voraus für eine rückmeldung
habe jetzt das selbe phänomen
gab es zu diesem problem eine Lösung?
Danke im voraus für eine rückmeldung
Hallo,
Wirklich? das selbe? Mit genau der gleichen Konstellation von Hardware/Software/ESXi?
Mach bitte einen neuen Fred auf und beschreibe dein Problem/Fehler genau.
Gruß,
Peter
Wirklich? das selbe? Mit genau der gleichen Konstellation von Hardware/Software/ESXi?
gab es zu diesem problem eine Lösung?
Ich würd sagen: Nein.Mach bitte einen neuen Fred auf und beschreibe dein Problem/Fehler genau.
Gruß,
Peter
