TL;DR
In diesem Beitrag beschreibe ich, weshalb ein Windows-Rechner trotz korrektem DHCP DORA-Dialog die zugewiesene IP-Adresse nicht unbedingt auch verwendet, sondern am Ende doch bei einer APIPA-Adresse landet.
Kürzlich wurde ich zu einem Troubleshooting hinzugezogen, bei dem es zu klären galt, warum ein Rechner keine IP-Adresse per DHCP erhielt. Wobei das nicht ganz stimmt… Über den Onboard Adapter erhielt der Laptop eine Adresse, nur über die Docking Station eben nicht. Nun kann man lang über mögliche Ursachen nachgrübeln oder aber man macht einfach einen Paketmitschnitt und schaut sich an, wo genau es hakt. Wir haben uns für letzteres entschieden.
Sicher wäre Wireshark hier eine Möglichkeit gewesen. Wer sich aber schon mal tiefer mit Packet Captures beschäftigt hat wird wissen, dass es einige Nachteile mit sich bringt, wenn man direkt auf dem Endgerät mitschneidet, das man untersuchen möchte. Aus diesem Grund arbeiten wir gern mit dem Allegro Network Multimeter – man sieht, was tatsächlich auf dem Kabel los ist. Das soll hier kein Werbebeitrag werden, aber die Allegro ist wirklich „Packet Analysis on Steroids“. Bestimmt wird sie noch in dem einen oder anderen Beitrag Erwähnung finden. Aber zurück zum Thema… Das Ergebnis des Mitschnitts hätte langweiliger nicht aussehen können. Ein normaler DORA Dialog:
Und trotzdem hat der Rechner ausschließlich eine APIPA-Adresse aus 169.254.0.0/16 – Warum!? Ein möglicher Grund wäre ein Adresskonflikt, weil die vergebene IP bereits (statisch) auf einem anderen System konfiguriert ist. Das bekommt der DHCP-Client über einen ARP Probe heraus, analog zur Duplicate Address Detection in IPv6. Im konkreten Fall gab es dafür aber keinen Anhaltspunkt. Es musste also etwas anderes sein. Das kuriose daran: Steckt man das LAN-Kabel direkt in den Onboard Adapter, funktioniert DHCP tadellos.
An dieser Stelle blieb eigentlich nur noch ein Blick in das Eventlog des Windows Clients. Und dort war dann tatsächlich auch etwas Interessantes zu finden:
Eine Google Suche nach „Windows Event 50068“ brachte des Rätsels Lösung gleich an erster Stelle. Der Fragesteller in diesem Beitrag hatte exakt das gleiche Problem mit seiner Docking Station. Die Ursache war eine BIOS-Einstellung namens MAC Address Pass-Through, welche auch bei uns aktiv war. Dabei wird die MAC-Adresse des Onboard Adapters an die Docking Station durchgereicht. Das vereinfacht Adress-Reservierungen im DHCP, da ein Client immer die gleiche MAC-Adresse hat, egal über welche Docking Station er arbeitet. Andererseits führt es eben auch dazu, dass Docking Station und Onboard Adapter zwangsläufig immer die gleiche IP-Adresse zugewiesen bekommen. Das schmeckt Windows offenbar gar nicht: Besteht eine noch gültige Lease für eine feste IP auf Netzwerkadapter A, wird die gleiche IP-Adresse auf einem anderen Adapter B nicht konfiguriert. Das beschreibt die obige Fehlermeldung.
Das Ganze konnte man dann auch nochmal anschaulich nachstellen: Anstecken des Onboard Adapters, Ausführen eines ipconfig /release. Jetzt umstecken und siehe da: Nun bekommt die Docking Station eine IP-Adresse. Steckt man jetzt auf den Onboard Adapter zurück, hat dieser die Probleme. Eine Einstellung, dieses Verhalten von Windows zu ändern, haben wir auf die Schnelle nicht gefunden, aber dann auch keine weitere Zeit für ausführlichere Recherchen verschwendet.
Mal wieder ein interessantes Beispiel dafür, wie zwei an sich clevere Automatiken sich gegenseitig behindern können.