Bevor man sich mit Multicast beschäftigt, lohnt es sich, die drei grundlegenden Übertragungsmodelle in IP-Netzwerken zu verstehen und voneinander abzugrenzen. Die Wahl des richtigen Modells hat erhebliche Auswirkungen auf die Netzwerkauslastung, die Skalierbarkeit und die Effizienz einer Anwendung.
Bei Unicast wird ein Datenpaket von genau einem Sender an genau einen Empfänger geschickt. Das ist das häufigste Modell im Internet – HTTP, SSH und FTP funktionieren alle nach diesem Prinzip. Der Nachteil: Soll dieselbe Information an 100 Empfänger geliefert werden, muss der Sender 100 identische Pakete verschicken. Das skaliert schlecht und belastet sowohl den Sender als auch die Backbone-Verbindungen unnötig.
Broadcast löst dieses Problem teilweise: Ein Paket wird an alle Teilnehmer im selben Subnetz gesendet. Die Broadcast-Adresse lautet dabei immer die höchste Adresse im Subnetz (z. B. 192.168.1.255 für 192.168.1.0/24). Router leiten Broadcasts grundsätzlich nicht weiter, was den Einsatz auf das lokale Segment begrenzt. Außerdem empfangen alle Geräte das Paket, auch solche, die es gar nicht benötigen – das erzeugt unnötige CPU-Last auf allen Hosts im Segment.
Multicast ist der Mittelweg: Ein Sender adressiert eine Gruppe von Empfängern, die sich aktiv für den Datenstream angemeldet haben. Nur diese Empfänger erhalten die Pakete. Der Sender muss das Paket trotzdem nur einmal schicken – die Netzwerkinfrastruktur (Switches und Router) sorgt für die Verteilung an alle relevanten Ports und Interfaces. Das ist besonders dann sinnvoll, wenn:
viele Empfänger dieselben Daten benötigen (z. B. IPTV, Live-Streaming, Softwareverteilung),
die Bandbreite am Sender oder auf Backbones begrenzt ist,
Dienste im Netz sich gegenseitig entdecken sollen (mDNS, SSDP),
Routing-Protokolle Informationen an alle benachbarten Router senden müssen (OSPF Hello-Pakete gehen z. B. an 224.0.0.5).
1.1 Der Multicast-Adressraum
IPv4-Multicast-Adressen liegen im Bereich 224.0.0.0/4, also von 224.0.0.0 bis 239.255.255.255. Dieser Adressraum ist in mehrere Bereiche unterteilt:
224.0.0.0/24 – Link-Local-Bereich: Diese Pakete werden von Routern nicht weitergeleitet. Hierher gehören z. B. OSPF (224.0.0.5 und 224.0.0.6), RIP (224.0.0.9), IGMP-Queries an alle Hosts (224.0.0.1) und mDNS (224.0.0.251).
224.0.1.0 – 238.255.255.255 – Globally scoped Multicast: Kann über Router weitergeleitet werden, z. B. für IPTV oder unternehmensweite Video-Streams.
239.0.0.0/8 – Administratively scoped: Vergleichbar mit den privaten RFC-1918-Adressen für Unicast; diese Adressen sind nur für den internen Gebrauch bestimmt und werden nicht ins Internet weitergeleitet.
Auf Layer 2 werden IPv4-Multicast-Adressen auf spezielle MAC-Adressen abgebildet. Das OUI-Präfix lautet 01:00:5E, gefolgt von den unteren 23 Bit der Multicast-IP-Adresse. Für 224.0.0.251 (mDNS) ergibt das die MAC-Adresse 01:00:5E:00:00:FB. Da der Adressraum 28 Bit umfasst, aber nur 23 Bit in die MAC-Adresse einfließen, gibt es eine 32:1-Überlappung – 32 verschiedene IP-Multicast-Gruppen teilen sich jeweils dieselbe Layer-2-Adresse.
2. IGMP – Internet Group Management Protocol
IGMP ist das Protokoll, mit dem Hosts einem Router mitteilen, dass sie an einer bestimmten Multicast-Gruppe interessiert sind. Es läuft zwischen dem Endgerät und dem direkt angeschlossenen Router (dem sogenannten Querier). Ohne IGMP würde ein Multicast-fähiger Router nicht wissen, an welche Interfaces er Gruppen-Traffic weiterleiten soll, und würde ihn einfach verwerfen oder ungesteuert fluten.
2.1 IGMPv1, v2 und v3 im Vergleich
IGMPv1 (RFC 1112, 1989) ist die älteste Version. Hosts können einer Gruppe beitreten, indem sie einen Membership Report senden. Es gibt jedoch keine explizite Leave-Nachricht. Der Router wartet auf einen Timeout, bevor er die Gruppe aus seinem State entfernt. Das kann mehrere Minuten dauern und führt dazu, dass Traffic unnötig lange weitergeleitet wird, nachdem kein Empfänger mehr vorhanden ist.
IGMPv2 (RFC 2236, 1997) fügt die Leave-Nachricht hinzu. Verlässt ein Host eine Gruppe, sendet er eine Leave-Group-Nachricht an 224.0.0.2 (All-Routers). Der Router reagiert darauf mit einem Group-Specific Query, und wenn niemand antwortet, entfernt er den Eintrag aus seiner Tabelle. Das reduziert die Abmeldezeit von mehreren Minuten auf wenige Sekunden, was besonders beim Kanalwechsel beim IPTV spürbar ist.
IGMPv3 (RFC 3376, 2002) ist die aktuelle Version und unterstützt Source Filtering. Ein Host kann nicht nur einer Gruppe beitreten, sondern auch angeben, von welchen spezifischen Quellen er Traffic empfangen möchte (Include-Mode) oder welche er explizit ausschließen möchte (Exclude-Mode). Das ist die Grundvoraussetzung für Source-Specific Multicast (SSM) mit PIM-SSM, was die Effizienz und Sicherheit von Multicast-Deployments deutlich erhöht.
2.2 IGMP Join, Leave und Query
Der typische IGMP-Ablauf sieht folgendermaßen aus: Der Router sendet periodisch einen General Membership Query an 224.0.0.1 (All-Hosts). Alle Hosts, die einer Gruppe beigetreten sind, antworten mit einem Membership Report, wobei eine zufällige Verzögerung (Response Time) dafür sorgt, dass nicht alle Hosts gleichzeitig antworten. Beim Verlassen einer Gruppe (IGMPv2 und neuer) sendet der Host eine Leave-Group-Nachricht. Der Router antwortet mit einem Group-Specific Query und wartet kurz auf weitere Reports. Meldet sich kein Host mehr für die Gruppe, entfernt der Router den Eintrag.
2.3 IGMP Snooping auf Switches
Ein normaler Layer-2-Switch behandelt Multicast-Pakete wie Broadcasts und flutet sie auf alle Ports im VLAN. Das ist ineffizient, besonders bei IPTV mit mehreren HD-Streams, die je nach Auflösung 8 bis 20 Mbit/s belegen können. IGMP Snooping löst dieses Problem: Der Switch hört passiv den IGMP-Nachrichten zwischen Hosts und Routern zu und baut eine interne Tabelle auf, welcher Port welche Multicast-Gruppen abonniert hat. Multicast-Frames werden dann nur noch an die Ports gesendet, hinter denen sich interessierte Empfänger befinden.
IGMP Snooping ist auf den meisten verwalteten Switches standardmäßig aktiviert. Ein wichtiger Punkt: Es muss zwingend einen IGMP Querier im VLAN geben, entweder den Router oder den Switch selbst in seiner Funktion als IGMP-Snooping-Querier. Ohne einen aktiven Querier laufen die Membership-Einträge nach einiger Zeit ab und der Switch beginnt, den Multicast-Traffic wieder zu fluten oder vollständig zu unterdrücken.
# IGMP Snooping Multicast-Datenbank auf einem Linux Bridge Interface prüfen
bridge mdb show
# Alle aktuellen Multicast-Gruppen auf dem Interface anzeigen
ip maddr show dev eth0
# Beispielausgabe:
# 2: eth0
# link 01:00:5e:00:00:01 users 1
# link 01:00:5e:00:00:fb users 1
# inet 224.0.0.251
# inet 224.0.0.1
3. PIM – Protocol Independent Multicast
IGMP regelt die Kommunikation zwischen Host und dem direkt angeschlossenen Router. Sobald Multicast-Traffic über mehrere Router hinweg transportiert werden soll, braucht man ein Multicast-Routing-Protokoll. PIM (Protocol Independent Multicast) ist heute das de-facto-Standardprotokoll dafür. Der Name rührt daher, dass PIM auf dem bestehenden Unicast-Routing-Table aufbaut und kein eigenes, separates Routing-Protokoll benötigt. Es ist also unabhängig davon, ob OSPF, IS-IS, BGP oder statische Routen für das Unicast-Routing verwendet werden.
3.1 PIM-DM vs. PIM-SM
PIM-DM (Dense Mode) geht davon aus, dass die meisten Router im Netz Interesse an einer Multicast-Gruppe haben. Traffic wird zunächst an alle Router geflutet (Flood-and-Prune-Mechanismus). Router, die keinen interessierten Host hinter sich haben, senden eine Prune-Nachricht zurück. PIM-DM erzeugt viel initialen Traffic und skaliert schlecht in großen oder weitläufigen Netzen. Es ist heute weitgehend veraltet und wird kaum noch eingesetzt.
PIM-SM (Sparse Mode) ist das Gegenteil: Es wird angenommen, dass nur wenige Router an einer Gruppe interessiert sind. Traffic fließt ausschließlich auf explizite Anfrage. Hierfür gibt es einen zentralen Rendezvous Point (RP), der als Treffpunkt für Sender und Empfänger dient. PIM-SM ist das in modernen Netzwerken weitaus verbreitetere Modell.
3.2 Der Rendezvous Point (RP)
Der RP ist ein zentraler Router im Netz, dessen IP-Adresse allen anderen Routern bekannt gemacht wird. Das kann statisch konfiguriert oder dynamisch über Mechanismen wie Auto-RP (Cisco-proprietär) oder BSR (Bootstrap Router, RFC 5059) verteilt werden. Wenn ein Host einer Gruppe beitreten möchte, sendet sein Designated Router (DR) eine PIM Join-Nachricht in Richtung des RP. Wenn ein Sender zu streamen beginnt, registriert sein DR den Sender beim RP, indem er die ersten Datenpakete in PIM Register-Nachrichten einbettet und an den RP schickt.
3.3 (*,G) und (S,G) Einträge
Im Multicast-Routing-Table gibt es zwei grundlegende Typen von Einträgen:
(*,G) – Shared Tree Entry: Der Asterisk steht für "beliebige Quelle". Dieser Eintrag beschreibt den Pfad vom RP zur Gruppe G entlang des sogenannten Shared Tree (auch RPT, Rendezvous Point Tree). Alle Empfänger empfangen über diesen Baum, solange kein Switchover auf den Shortest Path Tree stattgefunden hat.
(S,G) – Source Tree Entry: Sobald der Traffic-Level einen konfigurierbaren Schwellenwert überschreitet oder der DR entscheidet, auf den kürzesten Pfad zu wechseln (SPT-Switchover), wird ein Shortest Path Tree (SPT) direkt von der Quelle S zur Gruppe G aufgebaut. Dieser Eintrag ist effizienter, da er den RP umgeht und die Latenz reduziert.
# Multicast Routing Table auf Linux anzeigen (benötigt pimd oder smcrouted)
ip mroute show
# Beispielausgabe mit (S,G)- und (*,G)-Einträgen:
# (10.0.1.100, 239.1.1.1) Iif: eth0 Oifs: eth1 eth2
# (*, 239.1.1.1) Iif: eth0 Oifs: eth1
# Anzahl der aktiven Multicast-Routen
ip mroute show | wc -l
4. Multicast im Heimnetz
Im Heimnetz begegnet einem Multicast häufiger, als man zunächst vermuten würde. Viele Dienste nutzen Multicast für die automatische Geräteerkennung und lokale Kommunikation, ohne dass der Benutzer davon etwas mitbekommt. Gleichzeitig entstehen durch VLANs im Heimlabor klassische Probleme, die eine gezielte Konfiguration erfordern.
4.1 mDNS – Multicast DNS
mDNS (RFC 6762) ermöglicht die lokale Namensauflösung ohne zentralen DNS-Server. Geräte senden DNS-Anfragen an die Multicast-Adresse 224.0.0.251 (Port 5353/UDP). Jedes Gerät im selben Link-Local-Segment, das den gesuchten Namen kennt, antwortet direkt auf die Anfrage. Apple nennt diese Technologie Bonjour, unter Linux ist Avahi die gebräuchlichste Implementierung.
Typische mDNS-Anwendungen im Heimnetz: AirPrint-Drucker werden von macOS-Geräten automatisch gefunden, Chromecast oder Apple TV tauchen in kompatiblen Apps auf, ein Raspberry Pi mit installiertem avahi-daemon ist über raspberrypi.local erreichbar, ohne dessen IP-Adresse zu kennen.
4.2 SSDP und DLNA/UPnP
SSDP (Simple Service Discovery Protocol) ist Teil des UPnP-Protokollstacks und nutzt die Adresse 239.255.255.250 (Port 1900/UDP). Geräte kündigen ihre Dienste mit einer NOTIFY-Nachricht an; andere Geräte können mit einer M-SEARCH-Nachricht aktiv nach Diensten suchen. DLNA-fähige Medienserver wie Plex, Jellyfin oder Kodi sowie Renderer (Smart-TV, Chromecast) nutzen SSDP für die gegenseitige Erkennung im lokalen Netz.
4.3 Probleme mit VLANs und Lösungsansätze
Das große Problem mit mDNS und SSDP im Heimlabor: Beide Protokolle nutzen Link-Local-Multicast-Adressen, die Router grundsätzlich nicht weiterleiten. Sobald man sein Netz mit VLANs segmentiert – was für ein ordentlich strukturiertes Heimnetz empfehlenswert ist (z. B. IoT-VLAN, Trusted-VLAN, Gäste-VLAN) – funktioniert die automatische Geräteerkennung über VLAN-Grenzen hinweg nicht mehr. Ein Drucker im IoT-VLAN ist vom Laptop im Trusted-VLAN schlicht nicht mehr sichtbar.
Es gibt zwei bewährte Lösungsansätze:
IGMP-Proxy leitet Multicast-Traffic zwischen Interfaces weiter. Auf Routern wie OPNsense oder pfSense lässt sich ein IGMP-Proxy konfigurieren, der z. B. IPTV-Multicast aus dem ISP-VLAN in das Heimnetz-VLAN transportiert (mehr dazu im Praxisbeispiel).
Avahi als mDNS-Repeater ist die elegante Lösung für mDNS über VLAN-Grenzen. Der avahi-daemon kann so konfiguriert werden, dass er mDNS-Anfragen und -Antworten zwischen mehreren Netzwerkinterfaces (VLANs) reflektiert. Damit kann ein Drucker im IoT-VLAN von einem Laptop im Trusted-VLAN gefunden werden, ohne dass die VLAN-Isolation aufgehoben wird. Der Avahi-Daemon fungiert dabei als transparenter Proxy auf Layer 3.
# /etc/avahi/avahi-daemon.conf – Ausschnitt für VLAN-übergreifendes mDNS
[server]
use-ipv4=yes
use-ipv6=yes
[publish]
disable-publishing=no
[reflector]
# mDNS-Traffic zwischen VLANs weiterleiten
enable-reflector=yes
reflect-ipv=no
# Avahi-Daemon nach Konfigurationsänderung neu starten
sudo systemctl restart avahi-daemon
# Status prüfen
sudo systemctl status avahi-daemon
# Alle annoncierte Dienste im lokalen Segment auflisten
avahi-browse -a -t
5. MLD – Multicast Listener Discovery für IPv6
MLD (Multicast Listener Discovery) ist das IPv6-Äquivalent zu IGMP. Es ist Bestandteil von ICMPv6 (RFC 2710 für MLDv1, RFC 3810 für MLDv2) und erfüllt dieselbe grundlegende Aufgabe wie IGMP: Hosts teilen ihrem direkt angeschlossenen Router mit, welche Multicast-Gruppen sie abonnieren möchten. MLD-Nachrichten haben einen Hop-Limit von 1, werden also nie über den lokalen Link hinaus weitergeleitet.
5.1 MLDv1 und MLDv2
MLDv1 entspricht funktional IGMPv2: Es gibt Membership Reports (Join), Done Messages (Leave) und Multicast Listener Queries. MLDv1 unterstützt kein Source Filtering. MLDv1-Nachrichten werden an die Link-Local-Multicast-Adressen ff02::1 (All-Nodes) oder ff02::2 (All-Routers) gesendet, je nach Nachrichtentyp.
MLDv2 entspricht IGMPv3 und unterstützt Source Filtering (Include/Exclude-Modus). Es ist die Voraussetzung für SSM über IPv6 und wird von allen modernen Betriebssystemen unterstützt.
Der IPv6-Multicast-Adressraum beginnt mit dem Präfix ff00::/8. Wichtige reservierte Adressen:
ff05::2 – All-Routers (Site-Local, routbar innerhalb einer Site)
Jedes IPv6-Interface tritt automatisch der zugehörigen Solicited-Node-Multicast-Gruppe bei. Diese Gruppen werden für die IPv6 Neighbor Discovery (NDP) benötigt, dem IPv6-Ersatz für ARP. Die Solicited-Node-Adresse berechnet sich aus den letzten 24 Bit der Interface-IPv6-Adresse mit dem Präfix ff02::1:ff00:0/104.
# IPv6 Multicast-Gruppen eines Interfaces anzeigen
ip -6 maddr show dev eth0
# MLD-Nachrichten mit tcpdump mitschneiden
# ICMPv6-Typ 130 = MLD Query, 131 = MLDv1 Report, 132 = MLD Done, 143 = MLDv2 Report
sudo tcpdump -i eth0 -n 'icmp6 and (ip6[40] == 130 or ip6[40] == 131 or ip6[40] == 132 or ip6[40] == 143)'
# Alle IPv6-Multicast-Gruppen im System
ip -6 maddr show
6. Praxisbeispiel: IPTV über VLAN mit IGMP-Proxy
Ein klassisches Heimlabor-Szenario: Der Internetanbieter liefert IPTV über einen dedizierten VLAN-Tag (z. B. VLAN 10). Der IPTV-Receiver (Set-Top-Box) hängt im Heimnetz-VLAN (z. B. VLAN 20). Der Router (hier OPNsense oder ein Linux-Router) sitzt zwischen beiden VLANs und muss den Multicast-Traffic vom ISP-VLAN ins Heimnetz-VLAN weiterleiten. Ohne IGMP-Proxy würde der Multicast-Traffic nie das ISP-VLAN verlassen, da der Router keine Veranlassung hätte, ihn weiterzuleiten.
6.1 Konfiguration IGMP-Proxy auf Linux
Auf einem Linux-System kann igmpproxy diese Aufgabe übernehmen. Es gibt ein Upstream-Interface (Richtung ISP, Multicast-Quelle) und ein oder mehrere Downstream-Interfaces (Richtung Clients). Der igmpproxy leitet IGMP-Nachrichten zwischen den Interfaces weiter und sorgt dafür, dass der Router den Multicast-Stream aus dem Upstream-VLAN in das Downstream-VLAN repliziert.
Die Option quickleave sorgt dafür, dass der Proxy sofort eine Leave-Nachricht nach upstream weiterleitet, ohne auf weitere Reports vom Downstream-Segment zu warten. Das verhindert kurze Bildaussetzer beim Kanalwechsel, da der Router nicht erst auf einen Timeout warten muss.
# igmpproxy starten und dauerhaft aktivieren
sudo systemctl enable igmpproxy
sudo systemctl start igmpproxy
sudo systemctl status igmpproxy
# IP-Forwarding für Multicast aktivieren (falls nicht bereits geschehen)
sudo sysctl -w net.ipv4.conf.all.mc_forwarding=1
# Routing-Tabelle für Multicast prüfen
ip mroute show
6.2 Konfiguration auf OPNsense
In OPNsense findet sich der IGMP-Proxy unter Services → IGMP Proxy. Dort werden ebenfalls ein Upstream-Interface (WAN-seitig, VLAN 10) und ein Downstream-Interface (LAN-seitig, VLAN 20) mit den jeweiligen erlaubten Netzwerken definiert. Zusätzlich muss unter Firewall → Rules eingehender Multicast-Traffic auf dem WAN-Interface erlaubt werden; als Zieladresse trägt man 224.0.0.0/4 ein, Protokoll UDP.
Wichtig ist außerdem, dass IGMP Snooping auf dem Downstream-Switch aktiviert ist und der OPNsense-Router als IGMP Querier für das Downstream-VLAN konfiguriert ist. Nur dann weiß der Switch, welche seiner Ports den IPTV-Stream erhalten sollen, und sendet ihn nicht unnötig auf alle Ports.
7. Troubleshooting
Bei Multicast-Problemen ist eine systematische Vorgehensweise entscheidend. Die folgenden Werkzeuge und Befehle helfen dabei, den Fehler Schicht für Schicht einzugrenzen – von Layer 2 (IGMP Snooping, MAC-Tabellen) über Layer 3 (Routing-Einträge, Firewall) bis hin zur Anwendungsebene.
7.1 ip mroute und ip maddr
# Multicast Routing Table anzeigen
ip mroute show
# Alle Multicast-Gruppen auf allen Interfaces
ip maddr show
# Nur ein bestimmtes Interface
ip maddr show dev eth0
# Multicast-Gruppen auf Bridge-Interfaces (IGMP Snooping)
bridge mdb show dev br0
In der Ausgabe von ip mroute show sind (S,G)- und (*,G)-Einträge sichtbar. Fehlt ein erwarteter Eintrag, hat sich entweder kein Client angemeldet (IGMP-Problem auf Layer 2/3) oder der Routing-Daemon hat den Eintrag nicht in die Kernel-Tabelle installiert (PIM- oder igmpproxy-Problem).
7.2 IGMP-Pakete mit tcpdump analysieren
# Alle IGMP-Pakete auf einem Interface mitschneiden
sudo tcpdump -i eth0 -n igmp
# Detaillierte Ausgabe mit Payload und Zeitstempel
sudo tcpdump -i eth0 -n -v -tttt igmp
# Nur Pakete für eine bestimmte Gruppe
sudo tcpdump -i eth0 -n "host 239.1.1.1"
# IGMP und UDP-Multicast zusammen beobachten
sudo tcpdump -i eth0 -n "(igmp or (udp and dst net 224.0.0.0/4))"
# Mitschnitt in Datei speichern und mit Wireshark analysieren
sudo tcpdump -i eth0 -w /tmp/multicast.pcap igmp
Typische Befunde bei der Paketanalyse: Ein Client sendet regelmäßig Membership Reports (IGMPv2 Report oder IGMPv3 Membership Report v3) an die Gruppenadresse. Der Router sendet periodische General Queries an 224.0.0.1. Bei einem IPTV-Kanalwechsel ist eine Leave-Nachricht an 224.0.0.2 zu sehen, gefolgt von einem Group-Specific Query des Routers und anschließend einem neuen Join für die neue Kanal-Gruppe.
7.3 Häufige Fehlerquellen und Lösungen
Kein Querier im VLAN: Die IGMP-Snooping-Einträge im Switch laufen ab, da kein Router periodische General Queries sendet. Der Switch beginnt daraufhin, den Multicast-Traffic entweder zu fluten oder komplett zu unterdrücken (je nach Hersteller und Konfiguration). Lösung: IGMP-Snooping-Querier auf dem Switch aktivieren oder sicherstellen, dass der Router aktiv Queries sendet.
Firewall blockiert Multicast: Multicast-Pakete haben als Zieladresse eine Gruppenadresse, keine individuelle Host-Adresse. Paketfilter, die nur explizit erlaubte Unicast-Ziele durchlassen, blockieren Multicast-Traffic stillschweigend. Firewall-Regeln müssen explizit den Bereich 224.0.0.0/4 (IPv4) bzw. ff00::/8 (IPv6) erlauben.
TTL zu niedrig: Multicast-Pakete aus IPTV-Quellen haben manchmal einen niedrigen TTL-Wert (z. B. 5 oder 10). Jeder Router auf dem Pfad dekrementiert den TTL-Wert. Fällt er auf 0, wird das Paket verworfen. Beim igmpproxy lässt sich der TTL-Threshold pro Interface konfigurieren, um sicherzustellen, dass Pakete mit niedrigem TTL trotzdem weitergeleitet werden.
mDNS funktioniert nicht über VLANs: Der Avahi-Daemon auf dem Router prüfen, ob enable-reflector=yes in der Konfiguration gesetzt ist und ob der Dienst tatsächlich läuft. Mit avahi-browse -a lassen sich alle annoncierte Dienste im lokalen Segment auflisten. Falls keine Dienste erscheinen, ist entweder Avahi nicht gestartet oder ein Firewall-Block auf Port 5353/UDP vorhanden.
# mDNS-Dienste im Netz entdecken
avahi-browse -a -t
# Speziell nach bestimmten Diensttypen suchen
avahi-browse -t _http._tcp
avahi-browse -t _ipp._tcp # Drucker (AirPrint)
avahi-browse -t _googlecast._tcp # Chromecast
# mDNS-Traffic live beobachten
sudo tcpdump -i eth0 -n "udp port 5353"
# SSDP-Discovery-Traffic beobachten
sudo tcpdump -i eth0 -n "udp port 1900"
Mit diesen Werkzeugen lässt sich nahezu jedes Multicast-Problem in einem Heimnetz oder Heimlabor eingrenzen und beheben. Der wichtigste Grundsatz bleibt dabei: von unten nach oben debuggen. Zuerst Layer 2 (IGMP Snooping, MAC-Tabellen, Querier-Status), dann Layer 3 (Routing-Einträge, Firewall-Regeln, IP-Forwarding), und zuletzt die Anwendungsschicht (Avahi, igmpproxy, DLNA-Server).