Netzwerk: TCP/IP

Multicast: Gruppenübertragung richtig aufsetzen

Multicast ist die Übertragung von einem Sender an eine Gruppe von Empfängern – in einem einzigen Datenstrom, der sich im Netz erst dort teilt, wo Wege auseinandergehen. Das ist der entscheidende Vorteil gegenüber Unicast (eine Kopie je Empfänger) und Broadcast (alle, ob sie wollen oder nicht).

\n

Die drei Übertragungsarten

\n
Unicast    1 Sender -> 1 Empfaenger\n           100 Empfaenger = 100 Datenstroeme vom Sender\n           Belastet den Sender und die erste Strecke linear.\n\nBroadcast  1 Sender -> alle im gleichen Segment\n           Alle muessen die Pakete verarbeiten, auch wenn\n           sie nicht interessiert sind. Nicht routbar.\n\nMulticast  1 Sender -> eine Gruppe\n           Der Sender sendet EINMAL. Router duplizieren\n           erst dort, wo sich Wege trennen.\n           100 Empfaenger bei einem Senderaufwand von 1.\n           Nur in Netzen mit Multicast-Routing sinnvoll.\n\nAnycast    1 Sender -> der naechstgelegene aus einer Gruppe\n           Mehrere Server mit derselben Adresse; das Netz\n           liefert an den naechsten. Genutzt fuer DNS-Root,\n           CDN, moderne Lastverteilung.
\n

Multicast-Adressen

\n
IPv4: 224.0.0.0/4 (224.0.0.0 bis 239.255.255.255)\n\n  224.0.0.0/24      Link-lokal, kein Routing!\n    224.0.0.1       alle Hosts im Segment\n    224.0.0.2       alle Router\n    224.0.0.5/6     OSPF\n    224.0.0.9       RIPv2\n    224.0.0.251/252 mDNS (Bonjour/Avahi) / LLMNR\n  232.0.0.0/8       SSM (Source-Specific Multicast)\n  233.0.0.0/8       GLOP (nach AS-Nummer zugeteilt)\n  239.0.0.0/8       Administrativ - FREI VERWENDBAR\n                    -> fuer eigene Anwendungen die richtige Wahl\n\n  224.0.1.0/24      weltweit bekannte Dienste\n    224.0.1.1       Network Time Protocol\n    224.0.1.60      Hewlett-Packard (Drucker)\n\nIPv6: ff00::/8\n  ff02::1    alle Knoten im Link\n  ff02::2    alle Router im Link\n  ff05::1:3  alle DHCP-Server im Standort\n  ff3e::     Beispiel fuer administration-scoped\n\nMAC-Ebene (IPv4): 01:00:5e:0b:00:01 fuer 224.0.0.1\n   -> Die unteren 23 Bit der Gruppenadresse werden uebernommen.\n   Deshalb teilen sich mehrere Gruppen eine MAC-Adresse -\n   die Filterung auf IP-Ebene ist trotzdem korrekt.
\n

Wie Empfänger beitreten

\n

Ein Empfänger tritt einer Gruppe bei (IGMP für IPv4, MLD für IPv6). Der Router fragt regelmäßig ab, wer noch interessiert ist, und leitet nur dorthin weiter, wo Interesse besteht.

\n
# Einer Gruppe beitreten (Linux)\nip maddr show\nip maddr add 239.10.10.10 dev eth0\nip maddr del 239.10.10.10 dev eth0\n\n# IGMP-Version und Status auf einem Switch\nshow ip igmp snooping\nshow ip igmp snooping groups\nshow ip igmp snooping groups vlan 10\n\n# IGMP-Versionen\n#   IGMPv2  Standard, Gruppenbeitritt/-austritt\n#   IGMPv3  mit Quellenauswahl (SSM) - empfehlenswert\n# Router: ip igmp snooping vlan 10\n#         ip igmp version 3\n\n# Ohne IGMP-Snooping auf dem Switch wird Multicast wie Broadcast\n# behandelt - es flutet das ganze VLAN und belastet alle Ports.\n# Snooping ist deshalb auf Switches PFLICHT.
\n

Multicast-Routing

\n

Multicast über Netzgrenzen hinweg ist erheblich komplexer als Unicast, weil Router eine Verteilung ohne Schleifen erst aufbauen müssen.

\n
Verfahren:\n  PIM-SM (Sparse Mode)   Der Standard. Baut Verteilbaeume erst\n                         auf, wenn Interesse besteht (Join).\n                         Zweige mit kurzer Lebensdauer brechen ab\n                         (Prune). Skaliert gut.\n  PIM-DM (Dense Mode)    Flutet erst alles, schneidet dann ab.\n                         Nur fuer kleine, dichte Netze.\n  PIM-SSM (Source-Specific)\n                         Empfaenger gibt Quelle UND Gruppe an.\n                         Kein Rendezvous-Punkt noetig - einfachste\n                         und sicherste Variante. Fuer eigene\n                         Anwendungen die erste Wahl.\n\nSchluesselbegriffe:\n  Rendezvous-Punkt (RP)  Treffpunkt, an dem sich Quellen und\n                         Empfaenger im Sparse Mode zuerst finden.\n  (*,G)  Baum            von allen Quellen zu einer Gruppe\n  (S,G)  Baum            von einer konkreten Quelle\n\nCisco-Beispiel (PIM-SSM fuer den eigenen Bereich)\n  ip multicast-routing\n  ip pim ssm range 232.0.0.0/8\n  interface Vlan10\n   ip pim sparse-mode\n   ip igmp version 3\n\n  ! Fuer Sparse Mode zusaetzlich:\n  ip pim rp-address 10.0.0.5\n\n  ! Der Rueckweg muss stimmen!\n  ! RPF (Reverse Path Forwarding): Das Paket muss ueber\n  ! die Schnittstelle kommen, ueber die die QUELLE erreichbar\n  ! waere. Falsches Routing zur Quelle = kein Multicast.\n\n  show ip mroute\n  show ip mroute 239.10.10.10\n  show ip pim neighbor\n  show ip rpf 192.0.2.10
\n

Wo Multicast eingesetzt wird

\n
    \n
  • Fernsehen und Radio über IP (IPTV): Der klassische Massenanwendungsfall. Ein Sender, viele Empfänger.
    • \n
  • Marktdaten und Börsenfeeds: Viele Abnehmer, strikte Latenzanforderungen.
    • \n
  • Routing-Protokolle: OSPF, RIPv2 nutzen Multicast für Nachrichten an alle Nachbarn.
    • \n
  • Diensterkennung im lokalen Netz: mDNS (Avahi, Bonjour), SSDP (UPnP), LLMNR.
    • \n
  • Softwareverteilung und Betriebssysteminstallation: Ein Abbild an hunderte Rechner gleichzeitig.
    • \n
  • Sensordaten und Steuerungstechnik: Viele kleine Meldungen, feste Empfängergruppen.
    • \n
\n

Prüfliste

\n
    \n
  1. Ist IGMP-Snooping auf allen betroffenen Switches aktiv?
    2. \n
  2. Wird ein Bereich aus 239.0.0.0/8 verwendet (nicht 224.0.0.0/24)?
    3. \n
  3. Ist die IGMP-Version auf Empfängern, Switches und Routern abgestimmt?
    4. \n
  4. Stimmt das Routing in Richtung der Quelle (RPF-Prüfung mit show ip rpf)?
    5. \n
  5. Ist PIM auf allen betroffenen Schnittstellen aktiv, auch auf dem Rückweg?
    6. \n
  6. Gibt es eine TTL-Begrenzung, damit Multicast nicht ungewollt weit läuft?\n
    # TTL-Schwelle: Pakete darunter werden nicht weitergeleitet\nip multicast boundary 1\n# oder je Schnittstelle eine Mindest-TTL erzwingen\ninterface Vlan10\n ip multicast ttl-threshold 2\n#   Verhindert, dass ein Teststrom das ganze Netz flutet.
    7. \n
  7. Ist die Last begrenzt? ip multicast rate-limit auf Zugangsports verhindert, dass ein fehlerhaftes Gerät das Netz überflutet.
    8. \n
\n

Häufige Fehler

\n
    \n
  1. Kein IGMP-Snooping. Multicast wird wie Broadcast im gesamten VLAN verteilt – alle Ports und Endgeräte belastet.
    2. \n
  2. Adressen aus 224.0.0.0/24 verwendet. Nicht routbar, für eigene Anwendungen ungeeignet.
    3. \n
  3. RPF-Fehler. Der häufigste Grund, warum Multicast „nicht ankommt“: Pakete werden wegen fehlgeschlagener Rückwegprüfung verworfen. show ip mroute zeigt RPF-Fehler in der Spalte RPF-fail.
    4. \n
  4. Firewall blockiert. Multicast braucht UDP-Regeln und die Protokolle IGMP (IP-Protokoll 2) und PIM (103). Ein „alles verbieten“-Ansatz bricht Multicast vollständig.
    5. \n
  5. PIM auf dem Rückweg vergessen. Interessiert man sich für einen Strom, muss auch die Schnittstelle in Richtung der Quelle PIM haben.
    6. \n
  6. Ein Empfänger mit einem Nicht-Multicast-fähigen Betriebssystem. Manche Systeme ignorieren Gruppenbeitritte unter bestimmten Bedingungen – die Anwendung muss explizit beitreten, nicht nur binden.
    7. \n
  7. Test ohne Last. Multicast funktioniert meist auch mit einem Strom. Vor dem Regelbetrieb mit voller Kanalzahl und gleichzeitigen Empfängern prüfen.
    8. \n
  8. Keine Überwachung des Stromes. Ein fehlender Multicast-Strom ist ein stiller Ausfall. Die Gruppenmitgliedschaft auf dem Router (show ip igmp groups) zeigt, ob überhaupt jemand Interesse anmeldet.
    9. \n
\n

Verwandte Grundlagen: Multicast, Load-Balancing-Verfahren, Switch-Arten.