07.12.2023

4030

Dhcp client erneuert nach vlan wechsel kein lease

Hallo zusammen,

ich habe seit kurzem aus ungeklärter Ursache das Phänomen das sich Windows 10 clients nach VLAN Wechsel am Switch (incl. on/off) kein neues Lease mehr am Dhcp Server holen und die alte Adresse behalten, natürlich dadurch keine Verbindung mehr bekommen.
Es handelt sich um einen DHCP Cluster (1x Server2022Std, 1x Server2016Std)
In den Serverprotkollen finde ich leider nichts.. (per Whireshark habe ich noch nicht mitgeschnitten)
Selbst nach einem Neustart vom Client kriege ich noch das alte lease

Jemand eine Idee welches Feature das kann?

Gruß

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 51192449088

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

Ausgedruckt am: 21.11.2024 um 19:11 Uhr

49 Kommentare

Neuester Kommentar

Ist denn der DHCP-Server per Ping vom Client erreichbar?

Jürgen

ja, beide.

Moin,

Ist das VLAN denn auch wirklich ein anderes und nicht im selben Netz?

Entweder mit wireshark mutsniffen oder mal per Stick booten (knoppix o.ä.) und schauen, ob das Problem immer noch besteht und dort per ~~snoop~~ tcpdump mitsniffen.

lks

Moin,

wurde denn im VLAN, in dem die DHCP-Server nicht sind, ein DHCP-Relay-Proxy eingerichtet?

Liebe Grüße

Erik

im VLAN, in dem die DHCP-Server nicht sind, ein DHCP-Relay-Proxy eingerichtet?

Wenn der DHCP Cluster zentral betrieben wird ist das zwingend.
Fragt sich WO der TO seine VLANs routet? Dazu macht er ja leider keinerlei Angaben und zwingt zum Kristallkugeln.

Zitat von @erikro:
Moin,

Moin,

wurde denn im VLAN, in dem die DHCP-Server nicht sind, ein DHCP-Relay-Proxy eingerichtet?

Dann hätte er doch aber nach dem Reboot des Clients eher eine APIPA bekommen!?

@to
Mach bitte mal ein ipconfig /all im funktionierenden als auch nach geändertem VLAN und poste die Ergebnisse hier (Firmennamen dürfen anonymisiert werden, IP-Adressen nicht, da ja eh alles im Bereich RFC1918 sein dürfte)

Und probiere auch mal ein ipconfig /release gefolgt von einem ipconfig /renew

nach dem Reboot des Clients eher eine APIPA bekommen!?

Er hat ja nach eigenen Angaben keinen Reboot gemacht sondern nur umgesteckt. Aber du hast dennoch Recht, auch mit Umstecken hat der Client nach ein paar Minuten eine APIPA Adresse bei ausbleibendem DHCP. Das Verhalten nach einem release/renew wäre dann in der Tat mal spannend.

Hätte der TO nur 3 Minuten in einen Wireshark Trace investiert wäre der Thread vermutlich obsolet gewesen...

Zitat von @aqui:

Hätte der TO nur 3 Minuten in einen Wireshark Trace investiert wäre der Thread vermutlich obsolet gewesen...

Oder einen reboot gemacht oder von Stick gebootet oder...

lks

das sich Windows 10 clients nach VLAN Wechsel am Switch (incl. on/off) kein neues Lease mehr am Dhcp Server holen und die alte Adresse behalten

Das ist doch ein normales Verhalten oder nicht? Ich kenne das nicht anders. Der Client merkt nicht, dass seine Ziele weg sind. Er macht ein DHCP Renew erst, wenn seine Lease Zeit abgelaufen sind. Deswegen habe ich bei VLAN Wechsel immer die Schnittstelle einmal deaktiviert und wieder aktiviert, egal auf welcher Seite (Switch oder Client), danach macht der Client ein DHCP Renew.

Zitat von @aqui:

nach dem Reboot des Clients eher eine APIPA bekommen!?

Er hat ja nach eigenen Angaben keinen Reboot gemacht sondern nur umgesteckt.

Doch, hat er:

Selbst nach einem Neustart vom Client kriege ich noch das alte lease <brace-sad" alt=

ace-sad">

Das ist korrekt, nach einem Schnittstellen off/on sollte das lease erneuert werden. Genau das macht der Client nicht.
Das Routing passiert auf dem CoreSwitch, hier ein auszug aus der config:

service dhcp
ip helper-address 192.168.XXXX
ip helper-address 192.168.XXXX
!
ip dhcp relay information option82

Ein CoreSwitch restart ist eher ungünstig

--_
Die Option "ip helper-address cycle-mode" ist eingeschaltet (sendet an alle angegebenen DHCP Server gleichzeitig=cluster)
Das Dhcp Relay muss doch nur am Routenden Switch aktiv sein ..

Ich habe einen Strohhalm, an einem DHCP Server (2016) selbst wird im Server Manager angezeigt das "Die DHCP Konfiguration abgeschlossen werden muss" (hatte den damals händisch autorisiert - siehe Screenshot)

Der zweite ist ein 2022er Server

Es läuft anscheinend trotzdem reibungslos (sync, failover klappt)

netsh dhcp show server liefert korrekte Werte

nach eine deauth/auth ist der pseudo Assi Fehler auch weg.

bpa ist sauber

Zitat von @em-pie:

Zitat von @aqui:

nach dem Reboot des Clients eher eine APIPA bekommen!?

nicht mal die kriegt er.. Der bleibt stehen und wenn man ansteckt will er mit der client ip aus dem alten netz mit dem neuen vlan verbinden was natürlich nicht möglich ist.

Was ist damit:

@to
Mach bitte mal ein ipconfig /all im funktionierenden als auch nach geändertem VLAN und poste die Ergebnisse hier (Firmennamen dürfen anonymisiert werden, IP-Adressen nicht, da ja eh alles im Bereich RFC1918 sein dürfte)

Und probiere auch mal ein ipconfig /release gefolgt von einem ipconfig /renew

Und arbeitest du mit SuperScopes?
Falls ja: schmeiß weg, wenn man nicht weiß, was die genau machen, hast du nur Probleme

Und mach mal nen Wireshark-Mitachnitt am Client, wenn er den DHCP-Prozess los tritt…

Das ist korrekt, nach einem Schnittstellen off/on sollte das lease erneuert werden. Genau das macht der Client nicht.

Das Phänomen hatte ich mal. Bei mir wollte der Client immer wieder die gleiche IP Adresse per DHCPOFFER haben, worauf immer ein DHCPNAK folgte. ich weiss gar nicht mehr wie ich das weg bekommen hatte, ich glaube das ging so:

Die Netzwerkkarte aus dem Gerätemanager löschen (auch in der versteckten Liste deaktivierter Geräte) und neu erkennen lassen.

Falls es nicht hilft, mach mal einen tcpdump (oder Wireshark) und poste mal das Protokoll.

Zitat von @NordicMike:

Das ist korrekt, nach einem Schnittstellen off/on sollte das lease erneuert werden. Genau das macht der Client nicht.

Genauso konnte ich auch ein neues lease bekommen aber das betrifft nicht nur einen client.. das ist ja das blöde.. Ich vermute irgendeine supersecure funktion am routing switch die das blockiert.

Zitat von @user217:

Zitat von @NordicMike:

Die Netzwerkkarte aus dem Gerätemanager löschen (auch in der versteckten Liste deaktivierter Geräte) und neu erkennen lassen.

Falls es nicht hilft, mach mal einen tcpdump (oder Wireshark) und poste mal das Protokoll.

Genauso konnte ich auch ein neues lease bekommen aber das betrifft nicht nur einen client.. das ist ja das blöde.. Ich vermute irgendeine supersecure funktion am routing switch die das blockiert.

Den wireshark-Mittschnitt hätte ich trotzdem gemacht. Dann hätte man ggf. die Ursache gefunden und nicht nur das Symptom beseitigt.

lks

Den wireshark-Mittschnitt hätte ich trotzdem gemacht.

Definitiv, dann sieht man genau nach welchem Detail man suchen muss.

Mal so aus reiner Sicherheit:

Es handelt sich um einen DHCP Cluster (1x Server2022Std, 1x Server2016Std)

also es ist auch wirklich als FailoverCluster eingerichtet und nicht zwei autarke Server?

Es ist ein Failover Cluster mit Lastenausgleich.
Auf einer vm funktioniert der wechsel des vlans im millisekundenbereich..

Ich kann mich noch dunkel daran erinnern das ich mal daran geforscht habe wie man doppelte dns einträge vermeidet (z.b. Von Notebooks per wlan+docking etc) Evtl. habe ich mir vor langer zeit mal selbst ein feature reinkonfiguriert..

Checke mit einem Mirrorport auf der DHCP Serverseite am Switch und dem Kabelhai ob dort die Client Requests ankommen. Ist das der Fall und der Server antwortet nicht oder fehlerhaft hast du doch sofort den bösen Buhmann entlarvt.
Allein die Fehlermeldungen oben sollten bei dir schon die rote Lampe leuchten lassen. Mit dem 3 Minutentrace wäre es noch eindeutiger.

P.S.: Wenn man bei embeddeten Screenshots das "+" auch an der richtigen Stelle klickt erscheint das Bild auch korrekt im Threadkontext und nicht zusammenhangslos am Ende. FAQs lesen hilft...und der "Bearbeiten" Knopf kann es nachträglich korrigieren.

Zitat von @aqui:

Allein die Fehlermeldungen oben sollten bei dir schon die rote Lampe leuchten lassen. Mit dem 3 Minutentrace wäre es noch eindeutiger.

Hab doch geschrieben das ich den ASSI Fehler mit deauth und wiederholtem assi + reboot gefixt habe (Anzeigefehler im Servermanager woho). Der war doch eh schon authorisiert.

Na dann...auf zum Wireshark und Mirrorport...deine beiden Freunde!

Also Whireshark sagt das beim VLAN switchen (incl. port on/off) kein neuer Request vom client gesendet wird.
Jemand noch eine Idee?

Wäre es möglich das vom client ein weiteres relay angefragt wird welches gar nicht zuständig ist? hier.

Vorausgesetzt das wäre so bleibt, warum sendet der client keinen request per bootp?

Poste mal den Log.

Nein, der Client macht oder "fragt" kein Relay. Das ist allein Sache des L3 Switches und der dortigen Relay Funktion. Kannst du übrigens auch mit dem Wireshark selber sehen wobei wir dann wieder beim Thema sind...

Vorausgesetzt das wäre so bleibt

Bahnhof, Ägypten?? 🤔

Ein wenig korrektere Rechtschreibung (Groß- Klein) hilft hier allen! 🧐
Punkt 5 der Foren Netiquette

Zitat von @NordicMike:

Poste mal den Log.

das würde ich, ich starte Whireshark mit filter bootp. Dann ändere ich das vlan und schaltet anschließend den port ein und aus. Dannach ändere ich das vlan zurück damit ich wieder auf den client komme und sehe nichts.
Wenn ich händisch heinen ipconfig /renew mache habe ich sofort einen REQ/ACK

Mehrfach zwischen 2 VLANs umgesteckt resultiert dann bei einem Winblows Client auf der Clientseite in den erwartbaren Wireshark Trace:

(DHCP Capture Filter: port 67 or port 68)

Wechselt man in ein DHCP Relay Segment sieht man die Relay IP auch im Request:

Anhand der o.a. Mac Adressen und der korrespondierenden IPs sieht man das der Cisco L3 Switch hier den Request auf den DHCP Server (.222) forwardet. Cisco L3 Konfig dazu:

!
interface Vlan20
 description Segment ohne DHCP Server
 ip address 172.27.2.254 255.255.255.0
 ip helper-address 172.27.1.222
!
interface Vlan30
 description Segment mit zentralem DHCP Server
 ip address 172.27.1.254 255.255.255.0 

Wenn du bei dir nichts Ähnliches sehen solltest ist irgendetwas mit deinem DHCP Client im Argen oder dem DHCP Server fehlt eine Default Route oder Gateway!

Wie hoch ist die Lease Time beim Client? Vorher wird er selbstständig keine neue Anfragen raus schicken.

Guten Morgen,
die LeaseTime ist für eine Zonen auf 16 Tage und für die zweite auf 8 Stunden eingestellt. Das sollte jedoch unerheblich sein, der kann doch jederzeit in beiden Zonen eine Client IP erhalten. Ich könnte die Leasetime testweise runtersetzen..
Du sagst der Client wird vorher keine Anfrage rausschicken aber wenn sich das Netzwerk ändert sollte er doch genau das tun.
Fehler vielleicht das Bootstrap protokoll für das Dhcp scope?

aber wenn sich das Netzwerk ändert sollte er doch genau das tun

Hmmm... Ich überlege gerade, woran und wann erkennt der Client, dass sich das Netzwerk ändert bzw geändert hat? Seine gecachten IP Adressen wird er nach wie vor versuchen anzusprechen und sagen: Komisch, mein Fileserver unter der mir bekannten alten IP antwortet nicht mehr, er wird wohl down sein. Ist das schon ein Grund sich per DHCP eine neue Client IP zu holen?

Ich denke das Konzept mit der IP-"Änderung" im Switch-Over-Fall des Clusters sollte überdenkt werden. Im Idealfall sollte der Client beim Switch-Over gar keine neue IP ziehen müssen, sondern seine alte IP nahtlos behalten.

dass sich das Netzwerk ändert bzw geändert hat?

Der Client reagiert auf den Link Loss an der NIC und initiiert einen DHCP Renew. Damit bekommt er im neuen Netz einen neuen Offer. Siehe Wireshark Trace oben wo man das ja eindeutig sieht.

sollte überdenkt werden

Autsch. Auch wenns komisch klingt sollte das "überdacht" werden (Natürlich ohne Dachdecker... 😉)

Moin,

nach überdenken und nochmaligem Lesen des Threads fasse ich mal zusammen, ob ich das richtig verstanden habe:

Du änderst direkt am switch das VLAN
Du schaltest im switch den Port aus und dann wieder ein
Du machst nichts an den Kabeln
Es funktioniert, wenn Du den Treiber komplett rauswirfst und frisch installierst?

Ist das so richtig zusammengefaßt?

Wenn ja, würde ich prüfen, ob es wirklich derselbe Treiber ist oder eine andere version. Außerdem würde ich prüfen, wie die Einstellungen in der registry vor und nach dem neuinstallieren sind. ggf kann man da einfach passenden Werte eintragen.

lks

PS:Wie lange braucht das Windows um zu merken, daß Du den Port abgeschaltet hast? Merkt die Kiste das überhaupt? Eventuell schaltest Du zu schnell "aus und ein".

PPS: Wenn das ein failover sein soll, warum muß der Cleint in ein neues IP-Netz? Failover baut man normalerweise so, daß die Clients "nichts merken".

Der Client reagiert auf den Link Loss an der NIC

Eben, ich glaube nicht dass er jedes mal manuell den Port deaktiviert oder das Kabel zieht. Zum Testen ja, aber in seinen Versuchen hat er es nicht mehr erwähnt.

Ohne ein Link Loss Event hat der Client ja keine Chance eine Änderung zu merken. Dann behält er alles bis zum Ablauf des Leases oder einem evtl. Reboot.

Das ist meine Rede seit mehreren Beiträgen

Zitat von @aqui:

Ohne ein Link Loss Event hat der Client ja keine Chance eine Änderung zu merken. Dann behält er alles bis zum Ablauf des Leases oder einem evtl. Reboot.

Jupp. Und deswegen wäre es wichtig zu wissen, ob es wirklich zu einem Link-Loss kommt, wenn er die Ports "aus und einschaltet".

lks

Bei "Porst" ein- auschalten am Switch ala shutdown / disable etc. ja, aber nicht wenn er nur das VLAN umlegt auf ein anderes und der Link bestehen bleibt.

Zitat von @aqui:

Bei "Porst" ein- auschalten am Switch ala shutdown / disable etc. ja, aber nicht wenn er nur das VLAN umlegt auf ein anderes und der Link bestehen bleibt.

Deswegen habe ich ja das ein- und ausschalten in Gänsefüßchen gesetzt, weil nicht ganz klar ist, ob es ein echtes "aus/ein" ist oder der TO was anderes darunter versteht als wir.

Und vor allem wäre es interessant zu wissen, ob der Client auch der Meinung ist bzw. mitbekommen hat, daß die Ports aus waren,was ja augenscheinlich nicht der Fall ist.

lks

Ausgangssituation:
frisch installierte WIN10 Kiste in VLAN X mit DHCP Lease, DNS alles super.
Switch, Port=off >1min., Client sagt: Netzwerkkabel entfernt, Switch change VLAN=Y, switch change Port=on. geht und hat je VLAN einen Eintrag am DHCP Server Scope so wie es sein soll.

Mir dämmert langsam das die Reihenfolge entscheidend dabei ist, d.h. ich hab mich aus unwissenheit blöd angestellt.
Aber kann mir bitte jemand erklären was der Unterschied ist:

1. das VLAN einfach am Switch ändern und anschließend on/off
2. Port off , VLAN ändern, Port on.

Ich denke trotzdem du suchst in der falschen Ecke. Bei einem Switch-Over am DHCP Cluster sollte der Client nichts mitbekommen, kein neues VLAN und auch kein IP Wechsel.

Neue Erkenntnis:
Switch A (Hersteller X): Client X, off/vlanswitch/on = funktioniert
Switch B (Hersteller Y): Client X, off/vlanswitch/on = funktioniert nicht

Switch B hat keine besonderen Einstellungen gegenüber Switch A.
Kann es vielleicht sein das meine integrierte AD DHCP DB defekt ist..

PS: Der Client bekommt das on/off definitiv mit. Habs auch mit Kabel ab/an probiert.

Zitat von @NordicMike:

Ich denke trotzdem du suchst in der falschen Ecke. Bei einem Switch-Over am DHCP Cluster sollte der Client nichts mitbekommen, kein neues VLAN und auch kein IP Wechsel.

Eben. Der sinn und Zweck von solchen Konstruktionen ist es doch gerade, daß man "ohne Änderungen" weiterarbeiten. kann. Das höchste der Gefühle sollte sein, daß da Admin eine kurze Notiz bekommt, daß ein failover stattgefunden hat. aber sonstkeiner was merkt. Zumindest sind die Designs, die ich bisher gesehen habe, so aufgebaut.

lks

Zitat von @user217:

Neue Erkenntnis:
Switch A (Hersteller X): Client X, off/vlanswitch/on = funktioniert
Switch B (Hersteller Y): Client X, off/vlanswitch/on = funktioniert nicht

Dann würde ich den switch mal austauschen. Das erklärt aber nicht, warum es funktioniert, wenn Du den Treiber entfernst und wieder installierst.

PS: Der Client bekommt das on/off definitiv mit. Habs auch mit Kabel ab/an probiert.

Immerhin das ist sichergestellt. Jetzt solltest Du nur noch mit wireshark/tcpdump schauen, ob auch entsprechende hdcp-discover oder dhcp-request.Pakete über die Leitung gehen.

lks

PS. Ich würde mal Alternativ auch prüfen, ob das auch mit anderen OS als Windows passiert. (z.B. knoppix oder windows-to-go von Stick).

Interessant, dass sich ein Client bei zwei Switchen unterschiedlich verhält. Ich verstehe den "vlanswitch" noch nicht. Warum bleiben die Clients beim Switchover des Clusters nicht im selben VLAN?

Interessant, dass sich ein Client bei zwei Switchen unterschiedlich verhält.

Das ist in der Tat sehr ungewöhnlich. 🤔 Ganz besonders insofern es ja bei beiden einen Link Loss gibt wenn der Port de- und wieder aktiviert wird (off/on) was dann den DHCP Renew beim Client zwangsweise triggert.
Da wäre ein Wireshark Trace auf dem angeschlossenen Client wenn das passiert sehr interessant!