Der Experte von Amico würde mir wahrscheinlich mitteilen, dass der Centro Grande keinen IGMP Querier implementiert und daher das IGMP Snooping nicht richtig funktioniert.
Tatsächlich handelt es sich um einen Bug im Centro Grande (Pirelli), es gibt aber einen Workaround. Gerne würde ich Eure Meinung dazu hören.
Das IGMP Snooping soll ja unnötigen Datenverkehr im lokalen Netz vermeiden. Das ist im Prinzip auch gut, aber hier ist der Centro Grande etwas ZU optimal. Im RFC 4541 wird empfohlen, dass link-lokale Multicast-Adressen (224.0.0.X) unkonditionell auf alle Ports weitergeleitet werden müssen - quasi analog zu einem “dummen Switch”. Multicast DNS mit der Adresse 224.0.0.251 fällt beispielsweise in diese Kategorie. Viele Geräte machen bei link-lokalen Adressen kein richtiges Join/Leave. Hier der entsprechende Abschnitt (2.1.2 Data Forwarding Rules):
2) Packets with a destination IP (DIP) address in the 224.0.0.X range
which are not IGMP must be forwarded on all ports.
This recommendation is based on the fact that many host systems do
not send Join IP multicast addresses in this range before sending
or listening to IP multicast packets. Furthermore, since the
224.0.0.X address range is defined as link-local (not to be
routed), it seems unnecessary to keep the state for each address
in this range. Additionally, some routers operate in the
224.0.0.X address range without issuing IGMP Joins, and these
applications would break if the switch were to prune them due to
not having seen a Join Group message from the router.
Für eine korrekte Funktionsweise des IGMP Snoopings ist weiterhin ein IGMP Querier vonnöten. Marc Culler hat hier eine sehr detaillierte Analyse dazu gemacht. Der Text bezieht sich auf avahi, einer OpenSource-Implementierung der Protokolle, die für Apple Bonjour vonnöten sind (mDNS, DNS-SD). Im folgenden Text kann man also für besseres Verständnis gedanklich das Wort “avahi” durch “Bonjour” oder “AirPlay” ersetzen:
There are many reports of avahi failing with the symptom that advertised
services “disappear” after a short time. A typical example is bug #657553.
There is a simple reason for why this happens on many home networks. This
wishlist bug is a suggestion for how to fix it.
Here is the reason for the failure. The mDNS service uses multicast UDP
packets. The multicast protocol requires that one of the routers on a network
be elected as an IGMP querier. It should broadcast IGMP query packets at
regular intervals. The hosts which want to belong the mDNS multicast group
(namely any computer running avahi-daemon) would then respond with its address.
However, most home routers do not provide a multicast querier. On the other
hand, most home switches and wireless access points do support IGMP snooping.
The consequence of this is that the switch or WAP will unsubscribe hosts from
the mDNS multicast group if the switch does not hear any IGMP responses from
the host during that time. This causes the host to “disappear” as reported in
bug #657553.
Here is the simple fix. The avahi daemon should always start up as an IGMP
querier, sending IGMP query packets at a configurable regular interval. The
avahi daemon should also participate in the querier election process. That is,
if it hears a query packet from another device with a lower IP address, then it
should stop sending query packets. This way, if there is a true multicast
router on the network the avahi-daemon will behave as it now does. But if, as
is typical in home networks, there is no IGMP querier on the network then one
of the avahi-daemons will step in.
I have tested this on my home network by running a daemon on one of my linux
systems which sends and IGMP query packet every 60 seconds. If that daemon is
not running I see the same “disappearing addresses” as are reported in bug
#657553. However, with the daemon running I am able to use.local addresses
for all of my devices that support mDNS and service discovery for printers etc.
works reliably.
Der Workaround besteht darin, in regelmässigen Abständen (z.B. 60 Sekunden) ein IGMP Membership Query an die mDNS-Gruppe (224.0.0.251) zu senden. Das veranlasst alle Mitglieder dieser Gruppe zu antworten, was wiederum den Switch im Centro Grande dazu bringt seine Snooping-Tabellen aktuell zu halten. Dieses IGMP Membership Query kann man von einem beliebigen Computer im eigenen Netz erzeugen und versenden. Wichtig ist, dass es kontinuierlich gemacht wird. Man findet also idealerweise eine Maschine, die 24/7 läuft.
Marc Culler hat dazu mittels nemesis solche Pakete erzeugt und dies in einen Python-Daemon gepackt. Das einzige Gerät, dass bei mir zuhause 24/7 läuft ist meine Synology NAS, daher habe ich den Code in C neu geschrieben und in ein “Synology Paket” gepackt, dass man über die Web GUI installieren kann: https://github.com/dlorch/igmp-querier. Leider ist es erst für die Marvell Armada 370 verfügbar, ich habe noch nicht alle Cross-Compiler bei mir eingerichtet.
Ich habe weiterhin darauf geachtet, dass die IP-Quelladresse der IGMP Query auf “0.0.0.0” lautet. Dies verhindert, dass man als “IGMP querier” gewählt wird. Ich halte das Versenden von diesen Paketen im eigenen Netz als unbedenklich, würde aber gerne Eure Feedback dazu hören.
