Privatkunden
Geschäftskunden
t-entertain stottert seit ein paar wochen ab und zu trotz igmpv3
Seit ein paar Wochen stottert jeden Tag ein paar mal (oft nach dem Umschalten) T-Entertain.
Die verwendete Netzwerkhardware kann igmpv3 und ich sehe auf dem dlink Switch (siehe angehängte Zeichnung) an dem auch der mr400 hängt auch die multicast Gruppe.
Alle Geräte haben aktuelle Firmware. Der Router wurde schon getauscht, ebenso der Hauptswitch.
Phasenweise funktioniert das Stundenlang ohne jegliche Probleme, es kann also nichts prinzipielles sein.
Ich kann am dlink den Ablauf Umschalten-einige sekunden unicast-igmp Gruppeneintrag und Umschaltung auf Multicast wenn es läuft nachvollziehen.
Was mir aber auffällt wenn es nicht läuft:
Man schaltet um: gruppe wird am dlink entfernt (MR400 macht ja erst mal unicast).
Dann nach ein paar Sekunden fängt es an zu stottern (beim umschalten auf multicast). Zu diesem Zeitpunkt ist die Gruppe noch nicht am dlink zu sehen!
Es stottert dann mehrere zig Sekunden bis Minuten.
Macht man nichts kommt dann irgendwann die Gruppe am dlink an und dann geht es.
Interessanterweise werden die Multicasts NICHT geflutet (geprüft mit Wireshark). Ich vermute also da kommt gar nichts richtiges im LAN an?
An der 7590 sehe ich auch zu dem Zeitpunkt keine stabilen Video-Downstream. Wobei ich nicht weiss an was die 7590 das fest macht.
Das ganze setup lief bis vor (kann leider nicht genau sagen) rund ein paar Wochen ohne jegliche Probleme.
Ich kann leider auch nicht sagen ob da ein MR400 update dazwischen gemacht wurde.
Hat jemand noch einen Tipp wo das Problem liegen könnte?
Anbei die Zeichnung des Netzes.
Zum Störungszeitpunkt war nur der mr400 aktiv. Keine Aufnahmen.
Die Devolo Adapter machen kein wlan.
Die 7590 macht mesh via lan/powerlan mit dem repeater.
Die reinen LAN-verbindungen laufen stabil. (Netflix, PS4 etc).
Powerlan hat stabile gemessene 200-300mbit zwischen allen Adaptern.
DSL Fehler sind zwar zu sehen aber nur wenige (5 in 15 Minuten).
Störabstand ist etwas niedrig aber ok. Keine igmp/multicast Fehlermeldungen in der 7590.
Sollte ich selbst im Laufe der Diskussion den Fehler finden poste ich das natürlich hier.
Über Hinweise wo ich noch suchen kann wäre ich dankbar. Gerne auch technisch detailiert 
2 AKZEPTIERTE LÖSUNGEN
Inzwischen wurde der telekom switch durch einen zyxel 1900-8 ersetzt.
Dieser funktioniert auf anhieb perfekt.
Damit scheiden dlink und netgear für mich für weitere hardwarekäufe aus 
Warum die probleme erst nach dem sw update der fritzbox auftraten ist mir schleierhaft.
Irgendetwas muss vorher wohl anders gewesen sein, ist aber jetzt nicht mehr reproduzierbar.
Somit meine klare Empfehlung für managebare switches:
zyxel 1900
Also soviel mal vorweg, eine Lösung hab ich erstmal auch nicht
Aber ein paar Anmerkungen, die uns vielleicht dem Verursacher näher bringen.
Das Stottern nach dem Umschalten dürfte zu 99% an fehlendem Multicast liegen. Wenn man umschaltet, wird, wie du schon gesagt hast, erstmal per Unicast übertragen mit 130% der eigentlichen Streamgeschwindigkeit. Nach ein paar Sekunden drosselt der Server auf 30% und die STB muss den Multicast anfordern (zusammen dann wieder 130%). Sobald die STB Multicast empfängt, wird der Unicast abgestellt (die 30% sorgen dafür, dass der Übergang nahtlos ist).
Beim IGMP gibts glaub ich noch ein paar Missverständnisse. Es gibt einerseits die erwähnten Queries in regelmäßigen Abständen. Die sind aber nur dazu da zu erkennen, ob eine Multicastgruppe gar nicht mehr benötigt wird, ohne dass sie jemand abgemeldet hätte. Darüber sollte kein Join laufen!
Dafür gibt es extra IGMP Pakete, die jederzeit funktionieren müssen. Es ist also nicht richtig, dass der Multicast erst kommt, wenn die Fritzbox mal wieder danach gefragt hat!
Zu deiner Frage, bei einer neuen Gruppe wird kein Query geschickt. Wie gesagt, der Zweck der Query ist der umgekehrte Weg. Deshalb wird in der Regel bei einem Leave direkt ein Query geschickt (um sicherzugehen, dass kein anderer die Gruppe doch noch will).
Insofern ist imho das Verhalten des Switches nicht korrekt. Der Eintrag muss sofort erstellt werden, wenn ein IGMP Join empfangen wird (und gelöscht werden bei einem Leave oder einem Query Timeout).
Soweit zur Theorie, jetzt gilts rauszufinden, warum der Multicast wohl erst nach dem Query kommt.
Wenn ichs richtig verstanden habe, siehst du die Joins des MR400. Wo hast du die denn gesehen in deinem Netzbildchen? Zwischen MR und Switch oder zwischen Switch und Fritzbox? Wichtig wäre, dass sie bei der Fritzbox ankommen, sonst wird die keine Multicastgruppe anfordern
Also ich würde erstmal den Weg der IGMP Joins nachvollziehen vom MR bis ins Internet, also mal mitschnüffeln am Switch und an der Fritzbox, jeweils an beiden Seiten des Netzes, also Richtung MR bzw. FB und Richtung Switch bzw. DSL - dank Fritzbox ist das recht easy (http://fritz.box/support.lua Paketmitschnitte) und beim Switch kannst du bestimmt einen Monitoring Port einstellen, wenn der managebar ist. Ansonsten mal mit der Fritzbox anfangen, das gibt vielleicht auch schon Hinweise, wenn die Pakete dort nicht ankommen. Oder wenns irgendwie geht ein langes Kabel vom MR direkt an die FB, damit könnte man die Analysestrecke etwas verkürzen, wenn der Fehler damit auch aufrtitt.
Nachtrag, hier mal noch ein Bild aus meinem Archiv wie das für gewöhnlich abläuft (Unicast Anforderung, Antwort, Auftrag zum Multicast zu wechslen, IGMP Request, Multicast) jeweils im LAN und im WAN (wobei das noch nicht BNG ist, daher die Joins auf beiden VLANs):
danke erst mal für die ausführliche antwort
ich messe noch ein paar mal und melde mich dann zurück.
die igmp queries kommen an der fritzbox an, das sehe ich schon.
auch die überlappung habe ich gesehen.
ich muss noch ein paar messungen und tests machen. vor allem muss ich schauen ob die multicasts während der "transitionphase" wirklich am mr400 ankommen.
ich meinte nicht das die gruppenverwaltung per queries erfolgt, sondern andersrum:
wenn ein client einen join sendet sollte doch der multicast router mit einer group query reagieren, oder hab ich das falsch im kopf?
also nach weiterem trace:
die igmp joins werden vom switch ignoriert. interessanterweise auch beim netgear.
damit werden die multicasts geblock.
erst der igmpv3 report welcher vom router angefordert wird erzeugt die igmp gruppe in der snooping tabelle und forwarded damit die multicasts.
bleibt nur die frage was sich in dem ablauf die letzten wochen geändert hat bzw ob die fritzbox nicht auf den ersten join schon mit einer group query reagieren sollte auf die neu angeforderte gruppe.
btw:
ist die gruppe schon vorhanden wird vom switch der erste join bereits richtig mit einer ergänzung der gruppe um den neuen switchport quittiert.
da er richtigerweise die blocks ebenfalls ignoriert und die gruppe offen lässt funktioniert auch das innerhalb von ein paar minuten wieder zurückschalten auf einen sender problemlos.
ticket bei dlink ist eröffnet. bin mal gespannt auf die antwort.
ich halte euch hier auf dem laufenden
@m_h schrieb:
ich meinte nicht das die gruppenverwaltung per queries erfolgt, sondern andersrum:
wenn ein client einen join sendet sollte doch der multicast router mit einer group query reagieren, oder hab ich das falsch im kopf?
Also das wäre mir neu, wie gesagt, mein Stand ist:
@Grinch schrieb:Zu deiner Frage, bei einer neuen Gruppe wird kein Query geschickt. Wie gesagt, der Zweck der Query ist der umgekehrte Weg. Deshalb wird in der Regel bei einem Leave direkt ein Query geschickt (um sicherzugehen, dass kein anderer die Gruppe doch noch will).
Und so stehts auch in der RFC: https://tools.ietf.org/html/rfc3376#section-6.1
Multicast routers send General Queries periodically to request group membership information from an attached network. These queries are used to build and refresh the group membership state of systems on attached networks. Systems respond to these queries by reporting their group membership state (and their desired set of sources) with Current-State Group Records in IGMPv3 Membership Reports. As a member of a multicast group, a system may express interest in receiving or not receiving traffic from particular sources. As the desired reception state of a system changes, it reports these changes using Filter-Mode-Change Records or Source-List-Change Records. These records indicate an explicit state change in a group at a system in either the group record's source list or its filter-mode. When a group membership is terminated at a system or traffic from a particular source is no longer desired, a multicast router must query for other members of the group or listeners of the source before deleting the group (or source) and pruning its traffic. To enable all systems on a network to respond to changes in group membership, multicast routers send specific queries.
A Group- Specific Query is sent to verify there are no systems that desire reception of the specified group or to "rebuild" the desired reception state for a particular group. Group-Specific Queries are sent when a router receives a State-Change record indicating a system is leaving a group.
A Group-and-Source Specific Query is used to verify there are no systems on a network which desire to receive traffic from a set of sources. Group-and-Source Specific Queries list sources for a particular group which have been requested to no longer be forwarded. This query is sent by a multicast router to learn if any systems desire reception of packets to the specified group address from the specified source addresses. Group-and-Source Specific Queries are only sent in response to State-Change Records and never in response to Current-State Records. Section 4.1.11 describes each query in more detail.
Ich nehme mal an du hast das Switch schonmal einfach neugestartet, oder? Vielleicht hat sich da einfach was aufgehängt
Weil das Verhalten ist ja schon etwas ungewöhnlich.
Ja mir kommt das auch komisch vor.
Factory reset neustart und co alles durch.
Wie gesagt dlink sagt ja selbst das zzt keiner deren switches (ausser einem den es nur von der telekom gibt) kompatibel ist.
Komisch finde ich nur das das mal funktioniert hat.
Ich vermute das igmp verhalten der fritzbox hat sich evtl geändert und jetzt geht das nicht mehr.
Die vielen anleitungen bei dlink für entertain wurden ja sicher nicht aus spass erstellt.
Ich teste nachher mit dem telekom dlink. Leider ohne trace mangels management 
Gibt es eigentlich irgendeinen snmp und web managebaren switch mit 8-10 ports ohne poe der unter 100e liegt und mit entertain2 funktioniert?
Inzwischen wurde der telekom switch durch einen zyxel 1900-8 ersetzt.
Dieser funktioniert auf anhieb perfekt.
Damit scheiden dlink und netgear für mich für weitere hardwarekäufe aus
Warum die probleme erst nach dem sw update der fritzbox auftraten ist mir schleierhaft.
Irgendetwas muss vorher wohl anders gewesen sein, ist aber jetzt nicht mehr reproduzierbar.
Somit meine klare Empfehlung für managebare switches:
zyxel 1900
Kaufberatung anfragen
Zum Kontaktformular
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.
Angebote anzeigen
Zu den TV-Angeboten
Informieren Sie sich über unsere aktuellen TV-Angebote.
