Speedport Pro Mesh - Ethernet Backhaul Probleme

Hi,

 

ich nutze den Speedport Pro (Firmware 120133.2.5.035.0 / Stand 05/2020) und einen Speed Home Wifi (Firmware 010138.2.0.005.0 / Stand 01/2020).

 

Der Speedport Pro ist der Mesh-Master. Per Wifi-Backhaul sah alles wie zu erwarten aus. Wenn ich den Speed Home Wifi per Ethernet Backhaul verbinde, wird mir im Speedport Pro der Status der Meshkonfiguration nicht mehr richtig angezeigt.

 

Fehler auf dem Speedport Pro:

  1. Es fehlt zum einen die korrekte Darstellung, dass ein Ethernet Backhaul aktiv ist.
  2. Aktive Clients werden auf dem Speed Home Wifi nicht angezeigt. Ich sehe immer 0 Geräte. Auf dem Speed Home Wifi selbst wird alles korrekt dargestellt (siehe Screenshot).

Der Speedport Pro wurde nach dem Update auf die Version 120133.2.5.035.0 auf Werkseinstellungen zurückgesetzt. Der Speed Home Wifi wurde ebenfalls auf Werkseinstellungen zurückgesetzt. Das Mesh wurde ordnungsgemäß per WPS Taste (ohne gestecktes Ethernet Kabel) hergestellt. Erst nach erfolgreicher Mesh-Einrichtung habe ich auf Ethernet Backhaul umgestellt.

 

Screenshot 2020-05-26 at 14.49.55.png

@Arclight 

die SHW machen m.W. auch STP. Zumindestens meine ich das in einem Capture gesehen zu haben.

@Arclight 

mein Switch geht, siehe Signatur.

 

Ob bei Deinen nur eine Einstellung falsch ist, weiß ich nicht.

Den Gedanken hatte ich auch eben. 😊 Siehe mein Beitrag 24 in diesem Thread mit dem Ergebnis.

 


@kurz59  schrieb:

PS: Oder wenn möglich Reihenfolge ändern: Pro > SHW > Switch.


 

@kurz59 Hatte deinen Switch in der Signatur auch schon entdeckt und mir die Spezifikationen angeschaut. 😊 Was ins Auge sticht, aber eben unbestätigt ist, dein Switch kann IGMPv3. Meine Switches können wohl nur IGMPv2.

 

Nach meiner Recherche ist IGMPv3 aber nur ausschlaggebend bei Entertain Geräten die Multicast benötigen. Quelle: https://telekomhilft.telekom.de/t5/Geraete-Zubehoer/Speedport-Home-Wifi-als-Lan-Bruecke-an-Speedport...

 

Da meine Switches auch Dynamic Link Aggregation nutzen, ist ein Austausch auf Verdacht auch nicht günstig. Da brauch ich dann tatsächlich die Sicherheit, welche Voraussetzungen der SHW wirklich hat.

@Nanor Das ist nicht verwunderlich. Ein unmanaged Switch leitet alles „unbesehen“ weiter, auch Multicast Traffic. Dadurch werden alle Ports mit Multicast Traffic geflutet. Die Endgeräte müssen dann solche Datenpakete selbst aussortieren, statt dass der Switch sie gar nicht erst durchreicht, wenn das Endgerät sich nicht für den Multicast angemeldet hat.

@viper.de Das ist interessant. Wie hast du die SHW Pakete im Speziellen protokolliert? An dem Punkt fehlt mir teils das Wissen, wie ich die Pakete für den SHW per Ethernet ausleite. Mit dem Cisco Switch sollte das gehen, aber der stellt ja bereits das Problem dar.

 

Aus dem Capture die IGMP Version zu ermitteln sollte dann ja leicht sein: https://wiki.wireshark.org/IGMP

 

OT: Hatte mir mit Wireshark mal den WLAN Traffic des SHW / SPP angeschaut, um zu prüfen ob tatsächlich 802.11k, 802.11v und 802.11r für Wireless Roaming unterstützt werden. Ja, tun sie. War mir wichtig, da die WLAN Call Funktion bei den Smartphones sonst Probleme macht.

 


@viper.de  schrieb:

@Arclight 

die SHW machen m.W. auch STP. Zumindestens meine ich das in einem Capture gesehen zu haben.


 


@Arclight  schrieb:

Den Gedanken hatte ich auch eben. 😊 Siehe mein Beitrag 22 in diesem Thread mit dem Ergebnis.

 


@kurz59  schrieb:

PS: Oder wenn möglich Reihenfolge ändern: Pro > SHW > Switch.


 


@Arclight 

also die Reihenfolge geht mit Sicherheit, das weiß ich.

 

Beitrag 22 ist von Nanor, daher weiß ich jetzt Dein Ergebnis nicht.

@kurz59 Entschuldige, Beitrag 24 meinte ich. 😅

 

SPP > SHW > Switch geht bei mir allerdings nicht, weil ich den SHW in einem anderen Zimmer letztlich benötige und dort steht er dann hinter 2 Switches.

@Arclight 

Die Capture-Funktion des Pro ist eher suboptimal.

Dort wirst du keine Spanning Tree for bridges Pakete sehen.

 

@Arclight 

mit IGMP hat das jetzt gar nichts zu tun.  Konzentriere Dich mal auf STP.

Du kannst auf dem Switch einen Mirrorport konfigurieren und dann dort direkt mit wireshark tracen.

@viper.de Mir ist noch nicht ganz klar was die These ist. Nach welcher Information soll ich suchen?

 

Ich kann die STP Konfiguration in beiden Switches direkt einsehen. Die Aushandlung des Root Switch ist erfolgreich und es gibt keine Loops.

@Arclight 

die These ist, das wie bereits anfangs erwähnt die Mesh Konponenten ebenfalls STP aktiv nutzen und das mit Deinen Switches kollidiert. Wobei mir unklar ist, wozu Du das in Deiner Umgebung überhaupt brauchst, aber das wirst Du schon wissen.

Um die Sache zum Abschluss zu bringen. Da ich keine offizielle Antwort von der Telekom erhalten habe, was die genauen Anforderungen des Speed Home Wifi an Switches sind, habe ich mich entschlossen mein Netzwerk zu erneuern und zwei neue Switches bestellt.

 

Vielen Dank an alle, die mich hier bei der Fehlersuche unterstützt haben!

Telekom hilft Team
Hallo @Arclight,

wir fragen bei unseren Produktbetreuern an, ob sie hierzu Informationen haben.


Grüße Detlev K.

@Detlev K. Danke, würde mich da über eine genaue Aussage freuen. Es ist sehr wichtig weil die billigeren beziehungsweise älteren Switches offensichtlich nicht alle Protokolle für eine erfolgreiche Verkabelung mitbringen. Die meisten Leute wissen nur, sie brauchen einen Gigabit-Switch. Die gibt es ab gerne auch ab 12 EUR. Switches die IGMPv3 (IPv4) und auch MLDv2 (IPv6) für Multicast unterstützen gehen aber erst ab 55 EUR los. Ohne die nötigen technischen Spezifikationen von Seiten der Telekom für den SHW und Speedport Pro tappt man hier im Dunkeln.

 

Als kurzer Zwischenstand, ich habe heute einen ersten Test mit zwei neuen Switches (Netgear MS510TX) gemacht.

 

Der Speed Home Wifi ist jetzt per Ethernet verkabelt. Speed Home Wifi -> Netgear MS510TX (1) -> Netgear MS510TX (2) ->Speedport Pro. IGMPv3 und MLDv2 Snooping ist auf beiden Switches aktiv.

 

Herzlichen Dank hier an @viper.de @wari1957 @kurz59 @Nanor für eure Hinweise!

 

Die Belohnung ist folgendes Bild im Speedport Pro. Nach allen Infos, aus dem Thread hier, bedeutet das Bild, dass der SHW auch per Ethernet Teil des vorhanden Mesh ist, statt selbst den Mesh Master zu machen. Ob es stabil läuft, abwarten. Zuvor hatte ich mindestens einmal pro Woche noch Abstürze des Speedport Pro. Interessanterweise passierte dies auch gerne bei längeren Microsoft Teams Videokonferenzen. An gefluteten Ports kann es jetzt hoffentlich nicht mehr liegen.

 

Screenshot 2020-06-18 at 16.13.43.png

 

Telekom hilft Team
Hallo @Arclight,

bislang habe ich noch keine Rückmeldung erhalten.
Ich hake nun noch einmal nach und melde mich hier sobald ich eine Antwort habe.


Grüße Detlev K.

Vermutlich hätte es auch gereicht die Spanning Tree Funktionialität in den Cisco Switches abzustellen. War mir sowieso irgendwie unklar wozu das in dem Szenario gut sein soll, solange da nicht irgendwelche Kabel/Switch Redundanzen verdrahtet sind. Mesh Komponenten brauchen das, damit keine Loops entstehen.

@viper.de Zählen da zwei Link Aggregations nicht als relevant rein?

Telekom hilft Team
Hallo @Arclight,

leider hat unsere Anfrage keine weiteren Erkenntnisse gebracht, außer dass ein Switch zu Problemen führen kann und hier eine direkte LAN-Verkabelung vorzuziehen ist.


Grüße Detlev K.

@Detlev K. Schade, ohne genaue technische Spezifikationen ist es natürlich.

 

Ein bisschen ironisch ist es mit der LAN-Verkabelung jetzt aber schon, schließlich sind da meistens Switches involviert und ich nutze hier keine Billig-Switches sondern professionelle Hardware (Netgear MS510TX https://www.netgear.de/business/products/switches/smart/MS510TX.aspx).


@Arclight  schrieb:

@viper.de Zählen da zwei Link Aggregations nicht als relevant rein?


Ist STP für LAG zwingend notwendig? Ich frage nur, weil ich mich mehr daran erinnere, ist schon ein wenig her, dass ich das gemacht habe.

@viper.de Ich kann es dir nicht mit Sicherheit sagen. Mittlerweile bin ich auch auf eine einzelne 10 Gbit Ethernet Verbindung zwischen den zwei Switches umgestiegen.

 

Ich weiß nicht, wie der Speedport Pro arbeitet, aber eine parallele LAN und WLAN Verbindung von einem Gerät sollte durch STP ja auch abgefangen werden.

 

Allerdings sehe ich auch prinzipiell nicht den Nachteil RSTP (in meinem Fall) aktiv zu haben.