[Frage] FRITZ!Box: Mesh DHCP-Probleme i.V.m. Switches?

[jha4711]

Edit DM41: Abgtrennt aus FRITZ!Box 6591 Cable FRITZ!OS 7.22 vom 09.12.2020
Edit 2: "6591 Cable" aus dem Titel gestrichen.

Hast Du einen Switch zwischen den Geräten hängen?
Ich musste alle Mesh-Client-Boxen direkt per LAN mit der Mesh-Master-Box verbinden, damit die Übergabe ohne Verzögerung klappt.

Hallo in die Runde,

vielleicht erinnert sich der ein oder andere an meine diversen Posts hier im Forum, weil ich auch mir unerklärliche Probleme mit Mesh und einer gepatchten FRITZ!Box 6591 Cable VF-Edition hatte.
Meine "größte" Erkenntnis war ja z.B., dass diese Probleme (Der WLAN-Wechsel von einem AP zum anderen hat bei den WLAN-Clients zwar wunderbar geklappt, allerdings bekommt dieser Minutenlang keine IP-Adresse vom FRITZ!Box / Mesh-Master DHCP-Server) sich dadurch lösen lassen, dass man einen anderen DHCP-Server verwendet (in meinem Fall einen Windows Server 2019 DHCP-Server).

Daher finde ich diesen Post von @HW1002 mal EXTREM interessant, weil bei mir auch HP-Switches zwischen den beteiligten Boxen hängen, die sich über mehrere Stockwerke verteilen. Dann müssten die Switches ja den DHCP-Verkehr von einer FRITZ!Box "verschlucken", während der DHCP-Verkehr eines Windows-Servers durch geht.

Konkrete Frage in die Runde: Wenn Switches hier tatsächlich "bekannte" Probleme machen sollten - der Hinweis von HW1002 also tatsächlich reproduzierbare wäre - hat dann jemand hier aus der Runde diesbezüglich schon einmal weiter "geforscht"?
Sind das tatsächlich Fehler in den FRITZ!Boxen oder gibt es ggf. sogar konkrete Infos, was man z.B. bei den Einstellungen in den Switches beachten müsste, wenn man darüber ein MESH betreiben will. In den Switches gibt es ja diverse Möglichkeiten wie z.B. Loop-Protection, Spanning Tree etc, von denen ich aber bisher immer die Finger gelassen - also im Default belassen habe. Aber wer weiß - vielleicht liegts ja tatsächlich an so etwas? Da ich mit dem Durchsatz meines Netzes durchaus zufrieden bin, glaube ich nicht, dass hier etwas grundsätzlich falsch konfiguriert ist.

Wäre dankbar für eure Tipps. Merci

 

[hypnorex]

Ich habe mittlerweile einen Netgear Switch. Auch da funktioniert es nicht.

 

[Winnetwo]

Bei mir ist die Verkabelung ungefähr so:

6591------GBit-Lan-----Netgear Switch----2400. Anders kann ich auch garnicht verkabeln da ins Wohnzimmer nur 1 Netzwerkleitung geht.

Das kuriose ist aber, die Übergabe von der 6591 funktioniert. Nur zurück vom 2400er zur 6591 klappt nicht. Da sollte der Switch keine Rolle spielen.

Es ist auch völlig egal ob ich den DHCP Server der Fritzbox oder den meines Pi oder eines noch im Netzwerk vorhandenen Ubiquiti ER-X (im Switch Modus) nehme. Immer dasselbe Ergebnis. Ticket bei AVM läuft.

 

[feelfree]

Ich hatte einmal den DHCP Server des Raspi mit pihole aktiviert, statt des fritzbox 6591 internen dhcp Servers.
Damit hatte ich die von euch geschilderten Probleme. Zwischen Fritzbox, Raspi und den anderen Geräten, auch ein 2400er Repeater, ist ein Zyxel Switch.

[Edit Novize: Beiträge zusammen gefasst und überflüssiges Fullquote gelöscht - siehe Forumsregeln]

Wenn Switches hier tatsächlich "bekannte" Probleme machen sollten -

Könnte es etwas in der Art sein:
- Client fragt (*über Repeater) nach einer IP-Adresse, bekommt sie auch vom DHCP-Server
- Switch hat MAC Adresse des Clients am Port des Repeaters gelernt
- Vor Ablauf des Ageing im Switch fragt der Client nun wieder nach einer IP-Adresse, diesmal aber z.B. von der Fritzbox aus
- Der DHCP-Server antwortet auch, aber der Switch hat die zuvor gelernte MAC-Adresse am Port des Repeaters NICHT gelöscht (sondern sie nur zusätzlich am Port der Fritzbox gelernt)
- Die Antwort des DHCP-Servers geht dann - je nach Algorithmus - nur an die erste gefundene MAC-Adresse, hier also den Repeater.

Nach Ablauf des Ageing, je nach Switch meist so 5 Minuten, wird die MAC Adresse ausgetragen und alles funktioniert wieder.

So ein Switch ist einfach nicht darauf ausgelegt, dass sich ein und derselbe Client in kurzer Zeit an verschiedenen Ports meldet.

Wobei ich die Implementierung des Ageing eigentlich eher so kenne, dass es *eine* Tabelle von gelernten MAC-Adressen gibt und in der zweiten Spalte steht dann, welchem Port diese zugeordnet ist.

In meinem Fall (DHCP Server der Fritzbox wird benutzt) geht's dann trotzdem, weil die Anfrage nach einer IP-Adresse die Fritzbox dann gar nicht mehr verlassen muss.

 

[jha4711]

So ein Switch ist einfach nicht darauf ausgelegt, dass sich ein und derselbe Client in kurzer Zeit an verschiedenen Ports meldet

Wow, das klingt irgendwie logisch! Muss ich demnächst mal prüfen, ob es in der Richtung (Ageing) irgend etwas im Switch zu konfigurieren gibt.

 

[HabNeFritzbox]

Es gibt in gemanagten Switch Funktionen zum DHCP filtern oder dass der sich IP, Mac und Port merkt. Muss man halt schauen was Switch kann.

 

[feelfree]

Bei meinem lässt sich das Ageing auf 10 Sekunden runterdrehen. Default ist 5 Minuten.
Bin gestern kurz 2 mal mit dem Handy hoch und runtergelaufen, der Port zur MAC des Handys wechselte jeweils sofort.
Muss mal bei Grlegenheot schauen wie das ist, wenn der DHCP Server wieder im Raspi aktiviert ist.

 

[hypnorex]

Sollte denn der Switch nicht anhand der MAC Adresse ein identisches Gerät erkennen?

 

[feelfree]

Sollte denn der Switch nicht anhand der MAC Adresse ein identisches Gerät erkennen?

Sollte. Wie gesagt, die mir bekannten Implementierungen machen das auch so, dass es nur eine Liste gibt und dort eingetragen ist, an welchem Port das Gerät hängt.

 

[jha4711]

Sollte denn der Switch nicht anhand der MAC Adresse ein identisches Gerät erkennen?

Ich könnte mir vorstellen, das Problem wird erst beim Einsatz von mehr als 1 Switch relevant...
... denn die sofortige Erkennung gilt vermutlich “nur“ für den Switch, an dem sich der „wandernde“ Client dann neu meldet. Aber der Switch, an dem der Client vorher angemeldet war, kennt dessen MAC noch an dem Port, an dem der Client jetzt nicht mehr erreichbar ist. Daher spielt das Aging hier ggf. doch eine entscheidende Rolle, da der „alte“ Switch die Pakete für den „wandernden“ Client ja an einen falschen Port weiterleiten würde. ABER: nur eine Vermutung ;-)

 

[Winnetwo]

Ich habe auch 2 Switche im Gesamtsystem. Wobei meiner Meinung nach nur einer in den Prozess eingebunden ist.

Wie gesagt ist der 2400er hinter einem Netgear Switch angeschlossen. Aber der Wechsel zurück zum WLAN der Fitz Box selber macht Probleme. Da sollte ja kein Switch mehr involviert sein.

Vor dem Fritz 2400 hatte ich 2 Ubiquiti APs laufen. Da gab es solche PRobleme mit ansonsten identischer Netzwerktopologie nicht. Also ich vermute den Fehler in der 6591.
Bei der Konstellation Fritz 7490 --- LAN zum Switch ---- LAN zum Fritz 2400 ---- WLAN zum 7362SL als Repeater wie es in der Verwandschaft läuft, gibt es diese Probleme nicht.

 

[HW1002]

Ich habe übrigens eine 6660, wo der Fehler auch auftritt.

 

[jha4711]

Ich habe jetzt mal auf die Switches (Firma HP, diverse ProCurves aus der 18er Reihe) geschaut und kann dort nichts bzgl. Aging konfigurieren. Anschließend habe ich dann auch noch einen Test gemacht und bin mit dem WLAN-Client im Haus rumgelaufen und habe mir dabei zeitgleich die MAC-Tabellen der beiden betroffenen Switche angeschaut. Also die MAC-Adresse des WLAN-Clients wurde auch SOFORT den richtigen Ports zugeordnet - ohne bemerkenswerte zeitliche Verzögerung. Also trifft zumindest bei meinem Setup zu, was @hypnorex geschrieben hat und die MAC-Adresse wurde ohne Verzögerung von beiden Switches wieder den richtigen Ports (also da, wo eben der jeweilige WLAN-AP bzw. die jeweilige FRITZ!Box dran hängt) zugeordnet.

Fazit: Mit dem aging hat es bei meinem Netz / Setup anscheinend nichts zu tun. Die Suche nach der Ursache geht also wieder eine Runde weiter.
Wenn ich mal ganz viel Zeit habe, hänge ich auch alle FRITZ!Boxen in Reihe - ohne über die Switches zu gehen - um "wenigstens" für mich herauszufinden, ob es tatsächlich an den Switches liegt (oder nicht doch an einer irgendwie "kranken" - gepatchtend FRITZ!Box).

In jedem Fall Danke an all eure Beiträge!

 

[DeadlyLeberwurst]

Ich habe übrigens eine 6660, wo der Fehler auch auftritt.

Kann ich bestätigen, habe den Fehler auch mit der 6660. Man was ich alles 'rumprobiert habe, bis ich das lokalisieren konnte. Für die 6660 hilft es übrigens, die Mesh-Repeater in den 2.5 Gbit Port (LAN1) zu stecken. Dort existiert der Fehler wohl nicht.

Schätze mal, dass die Fritzbox 6660 auf den Port Lan 2 bis 5 irgendwie den ARP cache für die WLAN Clients nicht richtig leert.

[Edit Novize: Beiträge zusammen gefasst - siehe Forumsregeln]

Und dazu kommt noch, dass der 2.5 Gbit Port buggy ist und z.B. mit einem Netgear Switch unregelmäßig packet loss erzeugt. Habe als Workaround eine alte Fritzbox 7490 dazwischen kaskadiert. Die hat wohl Intel Ports, die keine Probleme machen.

Echt eine ausgereifte Box, die 6660 - NICHT....

 

[HW1002]

Für die 6660 hilft es übrigens, die Mesh-Repeater in den 2.5 Gbit Port (LAN1) zu stecken. Dort existiert der Fehler wohl nicht.

Dem ist leider nicht so, das habe ich ausprobiert. Dafür hatte ich dann Lags beim Internetzugriff.
Den Verdacht mit dem ARP-Cache habe ich allerdings auch.

 

[disorganizer]

Zur damit ihr wisst wie die mac tabellen in switches funktionieren:
Die Switches schauen auf die absender-mac-adresse von paketen.
Ist die Adresse noch nicht in der Mac Tabelle wird sie dort eingetragen.
Kommt sie schon mal vor wird der Eintrag komplett gelöscht (beim nächsten Paket neu gelernt).

Beim Verteilen von Paketen wird auf die ziel-mac-adresse geschaut.
Kommt sie in der Tabelle vor wird das Paket auf den hinterlegten Port ausgegeben.
Wenn nicht wird das Paket geflutet auf alle Ports.
(hier kann man an switches teilweise einstellen das die Pakete verworfen werden. das kann aber zu problemen führen und man sollte das nur machen wenn man weiss was man tut).

Fazit:
Das herumspielen an den Aging timern sollte man sein lassen. 5 Minuten ist Standard und gut.
5 Sekunden zu kurz, da die mac quasi nie wirklich in der Tabelle ist wenn Pakete für das Gerät ankommen.
Länger als 5 Minuten je nachdem in grossen Netzen teilweise nötig, aber meist in Heimnetzwerken nicht wirklich sinnvoll.

 

[feelfree]

Das kuriose ist aber, die Übergabe von der 6591 funktioniert. Nur zurück vom 2400er zur 6591 klappt nicht. Da sollte der Switch keine Rolle spielen.

So ist es bei mir auch.

Es ist auch völlig egal ob ich den DHCP Server der Fritzbox oder den meines Pi nehme. Immer dasselbe Ergebnis.

Bei mir nicht. Mit aktiviertem DHCP-Server in der Fritzbox bemerke ich keine Probleme (DNS ist aber auf dem Pi, falls das eine Rolle spielt). Wenn ich stattdessen den DHCP-Server vom Pi nehme, habe ich genau den Effekt. Im Wireshark sehe ich dann zigfach unbeantwortete ARP-Requests.

 

[jha4711]

tl;dr:
Ich melde mich mal wieder seit langem hier im Thread, weil ich vollkommen überrascht bin.

Hintergrund: Ich hatte ja gefühlte zigtausend Stunden damit verbracht diese hier im Thread angesprochenen DHCP Probleme irgendwie zu lösen. Meine zwei Mesh-Clients ( 1 x gebrauchte 7530 7590, 1 x gebrauchte und gepatchte 6591 - jeweils aktuellste Firmware - Labor oder Release, was es halt gerade gab) hatten mit den (Labor)versionen 7.2x immer massive Probleme WLAN-Clients mit einer IP-Adresse zu versorgen, bis ich (aus Frust) dort das WLAN einfach ausgeschaltet hatte, um diese Probleme zu vermeiden. Zu dieser Zeit lief auf dem Mesh-Master (Unmodifizierte 6591 Providerbox) 7.13 oder früher. Auf der gepatchten 6591 war mir das DVB-C aber wichtiger als WLAN, also hatte ich mich dort für die 7.2x ohne WLAN mit DVB-C anstatt 7.13 mit WLAN aber ohne DVB-C entschieden. Die gepatchte 6591 wurde nämlich „nur“ wegen DVB-C angeschafft, weil die Providerbox das ja sooooo lange nicht angeboten hatte.

Zum Wesentlichen .....

Seit mein Mesh-Master - die Original 6591 Providerbox von VF/Unitymedia in BW - vor wenigen Tagen mit der 7.22 versorgt wurde, sind alle DHCP Probleme wie vom Erdboden verschwunden.
WLAN-Clients hinter der 7530 7590 und der gepatchten 6591 funktionieren auf einmal EINWANDFREI. Als sei da doch noch „IRGENDETWAS“ in der 7.22 VF-Edition gefixed worden. Anders kann ich mir das nicht erklären. Oder war hier doch „Harry Potter“ im Spiel und hat in meinem Netzwerk rumgezaubert - ich weiss es wirklich nicht. Ist mir aktuell aber auch egal, solange alles endlich wieder läuft wie erwartet .....

Ich kann mir vorstellen, dass dieser Post jetzt nicht so vielen von euch etwas nützt - ABER vielleicht kommt ja doch mal zufällig ein Leser mit ähnlichen Problemen hier vorbei und kann dann, ggf. nach einem Update seines Mesh-Masters ähnlich positives beobachten.

 

[HW1002]

Ich habe jetzt auch mal wieder alles umgesteckt und kann ebenfalls bestätigen, dass die Probleme verschwunden sind.
Die MESH-Repeater-Boxen hängen jetzt wieder am Switch und nicht an der 6660 direkt, und die Übergaben funktionieren einwandfrei.
Irgendwas ist dann doch noch korrigiert worden. Daumen hoch!

 

[felixsmile]

Von allem, was ich bisher im Netz zu meinem aktuellen Problem gefunden habe, kommt dieser Thread hier am nächsten. Vielen Dank für die Infos! Wenn jemand das hier liest und bei der Frage hier helfen könnte, wäre ich sehr dankbar:

[Problem] - Kein DHCP an Repeater im Mesh mit LAN-Brücke

Liebes Forum, In meinem Mesh habe ich seit einiger Zeit Probleme mit manchen Repeatern. Das Setup (siehe auch das Bild weiter unten) FritzBox 7590 - Gigabit-Switch - Gigabit-Switch - Fritz Repeater 1200 AX Auch an anderen Stellen hängen noch andere Repeater, die aber bis jetzt keine größeren...

www.ip-phone-forum.de