Windows Server 2008 R2 IP-Adressenkonflikt

Hallo zusammen,

ich bin Systembetreuer an einer Schule und hab seit längerer Zeit mit einem Problem zu kämpfen, dass mein Wissen leider übersteigt. Vorneweg: Ich hab nicht wirklich viel Ahnung vom Konfigurieren und Einrichten eines Servers, das macht alles ein Systemhaus aus der Umgebung. Aber ein paar Dinge sind mir aus dem heimischen Netz bekannt.

Dennoch würde es mich interessieren, wo in unserem Netz der Wurm drinn ist.

Hauptsächlich sind beteiligt: Windows Server 2008 R2 und ein digitales schwarzes Brett (Fernseher per HDMI mit einem kleinen PC (win7 emb) huckepack verbunden; von Samsung).

Der Server (auch DHCP) hat die feste IP 192.x.0.10 und das DSBrett die 192.x.0.11. So läuft es auch die meiste Zeit problemlos.


Jetzt kommt es zu bestimmten Zeitpunkten vor, dass das Netzwerk plötzlich "verrückt" spielt. Das ist eigentlich immmer unmittelbar nach einem Microsoft Patch-Day vorgekommen, wenn Windows einen Neustart verlangen würde.

Der Server bekommt plötzlich eine IP-Adresse aus dem 169.x.x.x Bereich zugewiesen und auf der 192.x.0.10, der eigentlichen Serveradresse, befindet sich etwas vom DSBrett (irgendein Samsung-Gerät), ist aber auch weiterhin noch auf der 192.x.0.11. Das hat zur Folge, dass der Server nicht mehr ins Internet kann, manche PCs (im gleichen Netz) auf die Netzlaufwerke des Servers zugreifen können, andere wiederum nicht. Per TightVNC ist das DSBrett auch nach wie vor unter der 192.x.0.11 zu finden.
Gehe ich also her und will dem Server von Hand die 192.x.0.10 zurückgeben, meldet Windows einen IP-Adressenkonflikt.

Das kann ich dann nur dadurch lösen, indem ich vom DSBrett das Netzwerkkabel ziehe, dem Server dann die IP-Adresse zurückgebe und das DSBrett neustarte. Das Samsunggerät, dass vorhin die 192.x.0.10 des Servers blockiert hat, ist dann spurlos verschwunden, bis das Problem wieder auftritt.


Hat jemand vielleicht eine Idee, an was das liegen könnte? Dem Hersteller des DSBrett ist dieses Problem nicht bekannt und konnte mir leider nicht weiterhelfen. Mit meinen Heimnetzwerkkenntnissen bin ich ebenfalls mit meinem Latein am Ende und der Systemadministrator kommt vielleicht in 2-3 Wochen mal wieder vorbei.

Der Server und das DSBrett sind auch die einzigen PCs, die Nachts über durchlaufen ...

Für Hilfe oder Tipps wäre ich dankbar.

Schau dir bitte den DHCP an. Verteilt der zufällig IP Adressen auch ab unterhalb von 192.x.0.10? Dann würde er evtl. die IP des Servers nochmal verteilen.

Und wenn Du vor dem Server Neustart des Brett abschaltest dann klappts?

Kann es sein dass z.B. der Router fürs Internet vielleicht auch noch DHCP Server spielt und dort den Range 192.168.0.10 - xx vergibt? Wenn der Windows Server dann schnell weg ist wegem Neustart und ein neuer Client kommt und fragt im Netzwerk nach einer IP gibt statt dem Server der Router Antwort und erteilt ihm die nächste freie IP Adresse (in dem Fall die 0.10) und zack der Windows Server hat ein Problem sobald er wieder im Netz ist.
Vielleicht ist das auch so ein Management Interface vom Brett das eine fixe IP hat aber eine eingebaute Sicherheits-Routine schaltet das Interface nicht frei wenn ein Gerät mit derselben IP im Netzwerk gefunden wird.

Danke für die Antworten.
Wo es gerade erwähnt wird: Der DHCP Bereich vom Server geht von 100 - 199. Die unteren Bereiche wollten wir für Dinge wie Server, Drucker, Kopierer etc. frei halten.

Das mit dem Router als zweitem DHCP könnte sein. Da davor nur der Server 24h online war und jetzt das Brett dazu kam, könnte es sein, dass das halt bisher immer rein zufällig ging. Danke für den Tipp.
Gibt es eine Möglichkeit zu überprüfen (per Software/Befehl), ob mehr als ein DHCP im Netzwerk aktiv ist? Oder wär das dann gleich "Server runterfahren und schauen, ob jemand neue IP-Adressen vergibt"?

@Lawnmower: Ich war auch am Überlegen, ob das DSBrett irgendwas verbaut hat, das im Hintergrund arbeitet. Aber der Hersteller konnte mir in dieser Hinsicht nichts weiteres sagen und ich wär auch der einzige, der bisher so einem Problem hat.

dann deaktivier doch testweise den DHCP Service auf dem Windows Server (oder schalte den Server aus), häng irgendein Client ins Netz (so dass er sicher immer gleichen Netz / VLAN ist wie das Brett) und guck ob der eine IP kriegt - falls ja hast Du irgendwo einen 2. DHCP Server im Netzwerk. Falls nichts passiert dann boote das Brett neu und guck ob der sich erneut die 0.10 krallt - falls ja - "Brett Eigendynamik". Falls nein - mach doch mal ein Service/Port Scan auf die 0.10 und guck was da "angeboten" wird und ob sich das vom 0.11 unterscheidet. Weiterer Versuch: Die IP des Brett's ändern auf irgendwie 0.99 oder sowas und gucken ob die "Eigendynamik" weiterhin am 0.10 festhält oder sich dann z.B. den 0.98 holt.

Danke für die ganzen Tipps.
Den Server komplett abzuschalten hab ich bisher nicht gekonnt, da er gebraucht wurde. Aber da führt jetzt wohl kein Weg herum, den mal für die Testzeit herunterzufahren.

Was ich dir gleich beantworten kann: Egal welche IP das Brett hat, es landet immer auf der 0.10.
Zum Anfang es dynamisch eingebunden und dann auf der .0.199. Machte keine Unterschied.

woher bzw wie weisst Du eigentlich dass die 0.10 Adresse beim Brett landet?

Server abschalten reicht ggf den DHCP Service zu deaktivieren - wobei gestern gabs ja noch Windows Updates (Neustart sowiso erforderlich) - ggf kannst das gleich kombinieren.

Durch Stecker ziehen.
Als der Fehler das erste mal auftrat, sind wir alle ratlos dagesessen und haben nicht weiter gewusst. Ich konnte zwar den IP-Adressenkonflikt herausfinden, aber ich wusste nicht, wer den verursacht. Hab dann den Server auf ne andere IP gestellt, damit der wieder ins Internet konnte, dann konnte das Systemhaus per Fernwartung eine Diagnose laufen lassen und hat mir mitgeteilt, dass ein Samsunggerät auf der Server-IP sitzt. Das einzige Gerät von Samsung im Netzwerk war das Brett. Also hab ich das Brett auf eine feste IP-Adresse umgestellt (über Eigenschaften, bei IPv4, per ipconfig überprüft), Fehler blieb allerdings . Dann hab ich das ganze Haus nach weiteren Samsunggeräten durchsucht, bin aber nicht fündig geworden.

Also hab ich mich mit Laptop bewaffnet, an den nächst größeren Switch gesetzt, ein Netzwerkscanner laufen lassen und nach jedem Durchlauf ein anderes Netzwerkkabel abgezogen. Dadurch konnte ich dann das Brett als Schuldigen ausmachen und auch alle anderen Bereiche ausschließen.
Wenn mittlerweile der Fehler auftaucht, trenn ich das Brett vom Netzwerk, geb dem Server seine IP zurück, starte das Brett neu, steck's wieder an und alles läuft wieder wunderbar ... vermutlich bis zum nächsten großen MS Patchday.

Und ich hab gemerkt, dass das Problem immer dann auftauchte, wenn mein PC bei mir daheim (den ich als "Server" laufen lasse) am nächsten Morgen neu gestartet war wegen Winupdates. Deswegen vermute ich, dass es irgendwie damit was zu tun hat.

Lawnmower schrieb:

... - mach doch mal ein Service/Port Scan auf die 0.10 und guck was da "angeboten" wird und ob sich das vom 0.11 unterscheidet. ...

Zum Vergrößern anklicken....

Hab jetzt grad verstanden, was du damit meintest. Ja, es wird etwas anderes Angeboten. Unter 0.11 wird das Brett angezeigt, wie es sein sollte. Wenn ich mich jetzt richtig erinnere, dann wurde unter 0.10 zwar ein Gerät angezeigt, aber mein Netzwerkscanner hat mir keine weiteren Informationen geliefert, wer das ist. Deswegen kann ich immer nur von "irgendeinem Samsunggerät" sprechen, weil das Systemhaus mir das mitgeteilt hat.

Netzwerkscanner: SoftPerfect Network Scanner

sprich es müsste nicht zwingend das Brett sein, es besteht also die Möglichkeit dass sonst irgendein "Samsung" Gerät noch rumsteht auch wenn es Dir nicht bekannt ist (manchmal muss man das Unmöglich annehmen).
So Geräte wie Drucker (gibts ja auch von Samsung), TVs mit LAN Anschluss, DVD/Blueray Player, Beamer, Samsung Smartphone per WLAN - das ist nicht möglich?

Aber interessant bleibts: Wiso bekommt das Teil ne IP und von wem wird die vergeben? Hast Du das mal geprüft ob ein normaler Client (Laptop/PC) auch eine IP Adresse zugewiesen bekommt wenn der Server nicht läuft?

Andere Idee: Wenn das Brett die 0.10 krallt und Du es von einem Client anpingst - bekommst Du ja u.a. die MAC Adresse raus. Anhand derer lässt sich der Typ oft eingrenzen, vermutlich hat das Systemhaus daraufhin ein Samsung Gerät erkannt. Am besten prüfst Du das ebenfalls mal nach. Das geht wenn Du die IP anpingst und dann mit arp -a den Arp Cache anzeigen lässt (kommt ne Liste, da müsste auch die 0.10 dabei sein).

Doch, das Brett hängt da mit drinn, da das Samsunggerät erst dann aus dem Netzwerk verschwindet, wenn ich den Netzwerkstecker vom Brettt ziehe (also wenn ich direkt am PC des Bretts das Kabel abziehe). Alle anderen Netzwerkkabel zu anderen Clienten haben keinen Effekt.

Leider kann ich erst nächste Woche die Sachen überprüfen. Da ich ohne Anwesenheit der Chefetage den Server nicht runterfahren darf, diese aber heute verhindert ist, kann ich frühestens Montag mit dem Test beginnen.

Momentan kann ich den Fehler noch nicht reproduzieren, deswegen muss ich warten, bis das Problem wieder auftritt. Dann probier ich das mal mit dem arp -a.


Danke soweit für deine Hilfe. Immerhin hab ich jetzt ein paar neue Anhaltspunkte, die ich überprüfen kann

Ansonsten falls nix dabei rauskommt, als permanente Lösung einfach dem Server in Zukunft eine andere IP geben (oder spricht da was dagegen?)

So. Ich hab jetzt 2 Stunden lang mit rumtesten verbracht und bin jetzt immerhin in der Lage den Fehler zu reproduzieren.

Vielleicht noch Folgendes zur Ergänzung:
192.x.0.1 -> Server
192.x.0.10 -> Virtueller Server
192.x.0.11 -> DSBrett

Wenn ich den Server komplett runterfahre hat es zwar eine Zeit lang gedauert, aber nach gefühlt 1 h hab ich als IP nur noch die 169.254.x.x erhalten. Von soher denke ich mal, dass kein zweiter DHCP aktiv ist.

Wenn Server und Brett laufen kann man Folgendes feststellen:
Wird das Brett neugestartet, passiert gar nichts.
Starte ich den Server neu und das Brett ist dabei aus, passiert nichts.
Starte ich den Server neu und das Brett ist an, erscheint der IP-Adressenkonflikt und zwar so lange, bis ich das Brett neu gestartet habe. Es erscheint dann ein nicht beschriebenes Gerät, dass sich auf der 0.10 anpingen lässt und auch Rückmeldung gibt. Ein Host-Name besitzt dieses Gerät nicht, aber die ersten vier Blöcke der Mac-Adresse sind identisch mit dem Brett (das auf 0.11 zu finden ist).

Server -> feste IP
Brett -> feste IP

DHCP -> beide Reserverierungen eintragen
DNS -> prüfen, ggf. bereinigen und die neuen Namen bekannt geben (Foward & Reverse Lookup Zone)