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 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
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
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
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 81376886027
Url: https://administrator.de/contentid/81376886027
Ausgedruckt am: 16.12.2024 um 11:12 Uhr
8 Kommentare
Neuester Kommentar
Moin,
ihr arbeitet am Windows-DHCP-Server aber hoffentlich nicht mit SuperScopes, oder?
DHCP Superscope
ihr arbeitet am Windows-DHCP-Server aber hoffentlich nicht mit SuperScopes, oder?
DHCP Superscope
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
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
Dann war der Ansatz vom Kollegen @em-pie doch ein Volltreffer. Gib ihm das gelöst
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
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
Zitat von @commodity:
Dann war der Ansatz vom Kollegen @em-pie doch ein Volltreffer. Gib ihm das gelöst
In seinem obigen Link ist exakt angesprochen, warum das so ist.
Und genau das sieht man auch in seinem Screenshot 😩Dann war der Ansatz vom Kollegen @em-pie doch ein Volltreffer. Gib ihm das gelöst
In seinem obigen Link ist exakt angesprochen, warum das so ist.
Nur weil da nicht
Und danke fürs Feedback!
Ja. Das in jedem Fall! Danke.