mreini
Goto Top

DHCP-Server auf Windows Server 2022 gibt gleiche IP obwohl Client im anderen Subnetz ist

Moin moin,

Wir betreiben 2 DHCP-Server im Lastenausgleichsmodus auf Windows Server 2022. Nun haben wir mehrere Standorte welche über VPN am Rechenzentrum angeschlossen sind. Diese haben einen zentralen IP-Bereich, welcher auf mehrere VLAN's mit unterschiedlichen Subnetzen aufgeteilt ist.
Beispiel:
VLAN1: 10.2.100.0/26 GW 10.2.100.1
VLAN2: 10.2.100.64/26 GW: 10.2.100.65
VLAN3: 10.2.100.128/26 GW: 10.2.100.129
usw.


In dem Beispiel oben hab ich mal mich auf 2 VLANs beschränkt der Ablauf ist aber bei allen VLANs der gleiche.
Das DHCP-Relay ist immer das GW des Subnetzes.

NB01 steckt sich zum ersten mal ans VLAN 1 an -> Bekommt IP-Adresse aus dem Subnetz Bereich
NB02 steckt sich zum ersten mal ans VLAN 2 an -> Bekommt IP-Adresse aus dem Subnetz Bereich
NB02 steckt sich nun ans VLAN 1 an -> Bekommt seine 1. IP-Adresse aus dem VLAN2 Subnetz Bereich

Mit Wireshark hab ich mir die DHCP-Request angesehen. Im Request sehe ich das korrekte DHCP-Relay (Beispiel von NB02 an VLAN1 DHCP-Relay 10.2.100.1). Was jedoch auffällig ist, das die DCHP-Option 50 gesetzt ist und der Client seine erste IP-Adresse anfordert.
Selbst ein Neustart des Rechners oder der Befehl
ipconfig /renew
führt nicht zum Erfolg. In den Log-Dateien des DHCP-Servers wird auch protokolliert, das ein Renew der IP-Adresse von dem Client stattgefunden hat und er seine alte IP-Adresse bekommt

Ich muss noch dazu sagen, das dieser Aufbau bereits funktioniert hatte. Beim ersten mal waren die DHCP-Server in einem /24 Subnetz untergebracht. Dieses Subnetz wurde auf ein /28 Netz verkleinert. Die IP-Adressen der Server sind jedoch gleich geblieben.

Ich hab noch versucht explizit eine Richtlinie für die Subnetz Bereiche anzulegen, in der ich die Informationen vom Relay abfrage. Dies hat auch nicht funktioniert.

Kann mir da jemand weiter helfen?

Danke und Grüße
network

Content-ID: 81376886027

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

Ausgedruckt am: 16.12.2024 um 11:12 Uhr

em-pie
Lösung em-pie 21.03.2024 um 08:57:12 Uhr
Goto Top
Moin,

ihr arbeitet am Windows-DHCP-Server aber hoffentlich nicht mit SuperScopes, oder?


DHCP Superscope
mreini
mreini 21.03.2024 um 09:06:41 Uhr
Goto Top
Moin,

ne alles schön in eigene Bereiche gepackt
network02
commodity
Lösung commodity 21.03.2024 um 10:38:57 Uhr
Goto Top
You're not alone.
Das hier
https://learn.microsoft.com/en-us/answers/questions/432543/dhcp-server-i ...
klingt für mich nach einem (offenbar behebbaren) Bug/Feature des Windows-DHCP.

Viele Grüße, commodity
mreini
mreini 21.03.2024 um 13:38:40 Uhr
Goto Top
Getestet, aber auch ohne Erfolg.
mreini
mreini 21.03.2024 um 16:50:47 Uhr
Goto Top
War nicht ganz die Lösung aber ging in die Richtung. Es lag an der Bereichsgruppierung. Als die Entfernt wurde hat er wieder die Leases korrekt vergeben
commodity
commodity 21.03.2024 aktualisiert um 23:38:56 Uhr
Goto Top
Dann war der Ansatz vom Kollegen @em-pie doch ein Volltreffer. Gib ihm das gelöst face-smile
In seinem obigen Link ist exakt angesprochen, warum das so ist.
Und danke fürs Feedback!

Wer noch drüber stolpert und mehr wissen will, hier die Links zu MS:
https://learn.microsoft.com/de-de/windows-server/networking/technologies ...
https://learn.microsoft.com/de-de/openspecs/windows_protocols/ms-dhcpm/4 ...

Viele Grüße, commodity
em-pie
em-pie 21.03.2024 um 23:56:53 Uhr
Goto Top
Zitat von @commodity:
Dann war der Ansatz vom Kollegen @em-pie doch ein Volltreffer. Gib ihm das gelöst face-smile
In seinem obigen Link ist exakt angesprochen, warum das so ist.
Und genau das sieht man auch in seinem Screenshot 😩
Nur weil da nicht Nutella SuperScope dran stand, heißt es nicht, dass da nicht doch Nutella SuperScopes drin stecken….
Und danke fürs Feedback!
Ja. Das in jedem Fall! Danke.
mreini
mreini 22.03.2024 um 07:42:21 Uhr
Goto Top
Das ist gerade das verwirrende finde ich. Auch in der MS Knowledge Base finde ich ist dies nicht gut beschrieben.
Danke euch beiden

Gruß