none
DHCP verteilt beim wechsel falsche IP RRS feed

  • Frage

  • Hallo zusammen,

    wir sind derzeit dabei unser Netzwerk in einzelne Subnetze zu unterteilen (mittels VLANs). Da sich in den einzelnen Netzen Computer aus dem AD befinden, haben wir auf einen Windows DHCP Server gesetzt. Alle VLANs enden an unserem Hauptrouter in dem ein DHCP Relay für jedes Netz auf unseren Windows 2016 DHCP Server zeigt. Auf dem DHCP Server sind dann die einzelnen Netze als Bereiche angelegt. Das funktioniert auch super. Ich holen einen neuen Client schließe in an und er bekommt seine IP Adresse, sagen wir mal aus 10.0.0.0/24. Problematisch wird es aber jetzt wenn ich den gleichen Client ausschalte und damit ein Gebäude weiter gehen, wo ein anderes Netz ist, zum Beispiel 10.0.1.0/24 . Der Client stellt wieder seine Anfrage nach einer IP und bekommt von dem gleichen DHCP Server die gleiche IP aus dem 10.0.0.0/24 er Netz. Obwohl er sich in dem VLAN befindet, in dem nur das 10.0.1.0/24er Netz aktiv ist. 

    Erst wenn ich auf dem Client ipconfig /release mache, dann auf dem DHCP Server den Lease Eintrag lösche, auf dem Client dann die Netzwerkkarte deaktiviere und wieder aktiviere, bekommt dieser Client eine neue IP aus dem richtigen Netz.

    Normal wandern Clients ja nicht oft, daher hat es auch gedauert bis es uns aufgefallen ist, aber wenn nun ein Mitarbeiter seinen Laptop aus der Dockingstation nimmt und im Besprechungszimmer ins WLAN geht, was zwei unterschiedliche Netze sind, die aber bei dem gleichen DHCP Server landen, ist das Problem schon da.

    Hab ich bei der Konfiguration etwas vergessen? Ist das einfach so? Muss ich die Lease Time womöglich in den Minuten Bereich runterschrauben? (aktuell habe ich Sie von 8 Tage auf 10 Stunden reduziert) ?

    Viele Grüße

    Freddy

    Freitag, 27. September 2019 08:46

Antworten

  • Ok nachdem ich auch über die Sophos (unser Router) Communtiy nichts bezüglich DHCP Relay agent finden konnte. Hab ich einen Mitschnitt gemacht. Der Client frägt im DHCP Request mit seiner alten IP an und der Server schickt ein ack. 

    Ich habe das Problem allerdings lösen können, weil ich in einem anderen Forum gelesen habe, dass die Bereichsgruppierung daran schuld ist. Wir haben die Bereiche, für eine bessere Übersicht in Bereichsgruppierungen sortiert. Das war der Fehler. Wenn die Bereiche so gruppiert sind, lehnt der DHCP diese alten IPs (die einen Bereich in der gleichen Bereichsgruppierung haben) nicht ab sondern bestätigt sie. 

    Nach dem ich die Gruppen aufgelöst habe, funktioniert es.

    Trotzdem vielen Dank für die Hilfe.

    Dienstag, 1. Oktober 2019 09:58

Alle Antworten

  • Der Grund ist die Leasetime.

    Wenn der Rechner eine DHCP Konfig mit einer gültigen Lease hat, wird er in dem neuen Netz erst gar keinen DHCP REQUEST starten, solange er mit der bestehenden Config schon kommunizieren kann.

    Aber das Problem liegt eher im Netzwerk, eigentlich willst du ja nicht, das ein Client mit einer IP aus Netz1/VLAN1 an einem Port kommunizieren kann, der in Netz2/VLAN2 hängt.

    Wie sind denn die Switche/Netze ans Corenetz angebunden, über einen Trunkport mit tagged VLANs oder untagged?

    Übrigens solltest du keine Probleme haben, wenn ein Notebook von der Dockingstation (LAN) auf Mobilbetrieb (WLAN wechselt), weil sich Interfaces keine DHCP Konfig teilen.

    Gruß


    Freitag, 27. September 2019 10:10
  • Hallo und danke für deine Antwort. Ja das Beispiel mit dem LAN / WLAN war bescheuert. Uns ist es aufgefallen nach dem wir Rechner in Netz A installiert haben und bei den Leuten in Netz B aufgebaut haben. 

    Die Switches sind wie der Router per tagged Trunkport an den Coreswitch angebunden. 

    Wenn aber der Client die falsche IP hat, kann er überhaupt nicht kommunizieren. Er erreicht ja dann seinen Standardgateway nicht. 

    Ich dachte mir schon das es mit der Leasetime zu tun hat. 

    Freitag, 27. September 2019 15:44
  • Das hat nichts mit der Lease Time zu tun. Denn:

    "...Wenn ein DHCP-Client, der vorher eine von DHCP zugewiesene Adresse hatte, neu gestartet wird, gelangt dieser Client in den Status INIT-REBOOT. Der Client wird dann prüfen, ob er noch immer dieselbe Adresse verwenden kann, indem er ein DHCPREQUEST-Paket versendet, wobei er die bisherige IP-Adresse in das DHCP-Optionsfeld "DHCP-Adresse" einträgt.

    Falls der DHCP-Server darauf nicht reagiert, geht der Client davon aus, dass die vorherige Adresse noch gültig ist und benutzt sie daher weiterhin. Sendet der DHCP ein NACK-Paket als Antwort auf das DHCPREQUEST-Paket, geht der Client in den Discover-Zyklus; er verlangt in dem DHCPDISCOVER-Paket auch die zuvor zugewiesene Adresse. ..."

    Quelle MS.

    Dass bedeutet im Umkehrschluss, dass der DHCP Server auf diesen Request nicht reagiert. Ergo würde ich das Augenmerk auf den DHCP Relay legen. Kann mich auch nicht daran erinnern, je solche Probleme mit MS DHCP gehabt zu haben.

    VG
    Matthias

    Freitag, 27. September 2019 17:24
  • Ja ich meinte auch die ganze Zeit mich erinnern zu können mal so etwas gelernt zu haben... :) Leider bietet der DHCP Relay Agent von der Sophos XG nicht wirklich irgendwelche Optionen zur Einstellung. Ich werde dort mal in der Community fragen, ob jemand ähnliches festgestellt hat.

    Danke dir Matthias

    Samstag, 28. September 2019 21:42
  • Keine Ursache. Btw: DHCP Traffic lässt sich übrigens hervorragend durch Netzwerktools mitschneiden und lesen. Manchmal hilft es sich die Anfragen und Antworten von DHCP Client bzw. Server anzusehen, um dem Problem auf die Schliche zu kommen.

    Evtl. auch für dich interessant: https://docs.microsoft.com/en-us/windows-server/networking/technologies/dhcp/dhcp-subnet-options.

    Viel Erfolg
    Matthias


    Montag, 30. September 2019 21:18
  • Ok nachdem ich auch über die Sophos (unser Router) Communtiy nichts bezüglich DHCP Relay agent finden konnte. Hab ich einen Mitschnitt gemacht. Der Client frägt im DHCP Request mit seiner alten IP an und der Server schickt ein ack. 

    Ich habe das Problem allerdings lösen können, weil ich in einem anderen Forum gelesen habe, dass die Bereichsgruppierung daran schuld ist. Wir haben die Bereiche, für eine bessere Übersicht in Bereichsgruppierungen sortiert. Das war der Fehler. Wenn die Bereiche so gruppiert sind, lehnt der DHCP diese alten IPs (die einen Bereich in der gleichen Bereichsgruppierung haben) nicht ab sondern bestätigt sie. 

    Nach dem ich die Gruppen aufgelöst habe, funktioniert es.

    Trotzdem vielen Dank für die Hilfe.

    Dienstag, 1. Oktober 2019 09:58