Oh boy oh boy oh boy.

Ich habe schon einige merkwürdige Netzwerkprobleme im meiner Zeit beim VOC gesehen und behoben, aber heute habe ich was gesehen, das ich so noch nicht kannte.

Die Problem-Meldung des Bekannten lautete "Lange Zeit bis DHCP Konfiguration, manchmal Timeout". Das Netz dort hat 5 unabhängige Zonen, die alle symmetrisch konfiguriert sind: Management, Work, Home, Shared, Guest.

Im Log sieht man solche Einträge: Ein REQUEST auf das Management-Netz, ein ACK – dann ein zweiter REQUEST von derselben MAC-Adresse auf das Work-Netz und ein dazugehöriger NACK aufgrund von wrong server-ID.

Das Muster wiederholt sich ein paar mal, bis entweder der Client aufgibt oder der NACK mal vor dem ACK ankommt und so der ACK gewinnt. Okay, das klingt nach dem beschriebenen Problem. Auf dem Router schlagen die Netze als VLANs aufund sind dann in Bridges gekapselt. Erste Erkenntnis: Alle Bridges und alle VLAN Interfaces haben dieselbe MAC-Adresse. That would do it. Also alle einmal manuell geändert – doch das Problem persistiert.

Also weitergehende Ursachenforschung: Ist das ein Problem im Router, dass der dhcpd auf die falschen Interfaces lauscht? Oder ein Problem mit der Switch-Config, der irgendwie die VLANs nicht korrekt trennt? Also mit tcpdump auf die Bridges drauf:

DHCP Anfragen auf dem Home- und dem Guest-Netz eind nur auf den jeweiligen bridges sichtbar – DHCP-Anfragen aus dem Management und dem Work-Netz tauchen jedoch absolut zeitgleich auf beiden Interfaces auf. Das gleiche Ergebnis wenn man direkt auf die VLAN-Interfaces schaut – und noch erstaunlicher – wenn ich mich ebenfalls an das Tagged Netz stecke, sehe ich im Wireshark auch 2 DHCP Requests auf beiden VLANs (sind ja Broadcasts).

Das lässt ein Problem im Switch … oder irgendwo anders im Netz. Da der Switch aber auch nach eingehender Analyse der Konfiguration für alle VLANS absolut symmetrisch konfiguriert ist, würde das nicht erklären, warum nur Management und Work betroffen sind und eben nicht Home, Guest oder Shared. Außerdem … würde es dann nicht einen kompletten L2 Loop geben und alle Ports wären total am Limit? Den würde dann doch STP bzw. die Loop Detection erkennen und unterbinden. Warum nur DHCP?

Um mal ein paar Variablen ausschließen zu können, fange ich nach Absprache an, Geräte aus dem Work-Netz abzustecken und – nach 15 Geräten oder so – ist das Problem weg. DHCP ist Schnell und kommt nur auf einem Interface an. Whoaaaaa.

Aber wir kann das sein? Die Ports sind alle als Access-Ports konfiguriert, die haben einen Ingress-Filter und lehnen Tagged VLAN-Pakete ab. Mir fällt auch kein Gerät ein, das zwei Ports hätte die in unterschiedlichen Netzen stecken. Gut, aber die Spur ist jetzt heiß – wir stecken die abgesteckten Geräte eins nach dem anderen wieder rein und schauen, wann das Problem wieder kommt. Schnell haben wir 2 Kandidaten eingekreist und dann auf einen eingeschränkt. Und was steckt an der Dose?

Eine noch aus dem anderen Haus umgezogene aber noch nicht eingerichtete Sonos-Box. Aber wie… Ich erinnere mich, dass im Wohngebäude im Badezimmer eine zweite Sonos-Box hängt und - sure enough - diese hängt (aus Gründen) im Management-Netz. Per WLAN und per LAN. Die hiesige Box hängt per LAN im Work-Netz. Aber wie sollen die … nein. Die machen doch nicht wirklich zusätzlich noch ein Mesh, oder? Das kann doch nicht sein. Oder doch?

Wir knipsen bei der Sonos-Box im Bad das WLAN aus … und das Problem verschwindet. WTF? Soweit ich das verstanden habe, stellt die eine Sonos fest, dass sie die andere nicht übers LAN sehen kann und auch nicht übers WLAN (weil diese noch nicht eingerichtet ist) und macht dann selbstständig ein Mesh auf, über das sie DHCP Pakete vom LAN der einen Box in das LAN der Box und zurück leaked. Unglaublich.

Wir haben die Büro-Box zurückgesetzt und auch bei ihr das WLAN ausgeschaltet. Jetzt gehen beide aus den jeweiligen Netzen und es gibt keine Probleme mehr.

Und die Moral von der Geschicht'? Home-IoT-Stuff verträgt sich mit professionellen Setups nicht.