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

Aussage dlink:

Alle(!) dlink switches sind entgegen den Aussagen der Webpage nicht mit t entertain kompatibel ausser dem nur von der telekom selbst vertriebenen 1008‘er. 

Ich hol den jetzt um zu sehen ob es daran liegt. 

m_h

 

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

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.