Multicast bei IPv4: 224.0.0.0/4 erklärt

Multicast bei IPv4 ist eine effiziente Versandart für Daten, wenn viele Empfänger denselben Inhalt zur gleichen Zeit benötigen. Statt denselben Datenstrom mehrfach als Unicast an einzelne Ziele zu schicken oder das gesamte Netz per Broadcast zu belasten, sendet ein Sender einmal an eine Multicast-Gruppe – und nur Geräte, die diese Gruppe abonniert haben, erhalten die Pakete. Der zentrale Adressbereich dafür ist 224.0.0.0/4. Diese CIDR-Notation steht für den gesamten IPv4-Multicast-Block, also alle Adressen von 224.0.0.0 bis 239.255.255.255. In der Praxis begegnet dir dieser Bereich oft unbewusst: Routing-Protokolle wie OSPF nutzen Multicast-Adressen, mDNS arbeitet mit einer Multicast-Gruppe, und IPTV- oder Streaming-Systeme setzen Multicast ein, um Bandbreite zu sparen. Gleichzeitig ist Multicast für viele Einsteiger zunächst verwirrend: Welche Gruppen sind „lokal“, welche dürfen geroutet werden, was bedeutet 239/8, und warum tauchen bestimmte 224.0.0.x-Adressen überall auf? Dieser Artikel erklärt den Block 224.0.0.0/4 verständlich, ordnet die wichtigsten Teilbereiche ein, zeigt typische Anwendungsfälle und beschreibt, welche Protokolle und Netzwerkfunktionen du kennen solltest, damit Multicast bei IPv4 zuverlässig funktioniert.

Was bedeutet 224.0.0.0/4 genau?

Die Präfixlänge /4 bedeutet, dass die ersten 4 Bits den Netzanteil bestimmen. Im IPv4-Adressraum entspricht das dem Bereich, bei dem das erste Oktett zwischen 224 und 239 liegt. Anders formuliert: Alle Adressen, deren binärer Beginn mit 1110 startet, gehören zum Multicast-Bereich.

Wie groß ist dieser Block? Ein /4-Netz umfasst:

$\mathrm{Adressen}=2^{32-4}=2^{28}$

Das sind 268.435.456 mögliche Multicast-Adressen. Wichtig ist jedoch: Nicht jede Adresse ist „frei nutzbar“. Viele Bereiche sind für Protokolle, lokale Funktionen oder administrative Zwecke reserviert und werden in Standards und Registries verwaltet, etwa in den Zuordnungen der IANA-Multicast-Address-Registries sowie in der Übersicht zu IPv4-Multicast-Adresszuweisungen (z. B. RFC 5771).

Multicast vs. Broadcast vs. Unicast: Warum Multicast so nützlich ist

Um Multicast richtig einzuordnen, hilft ein kurzer Vergleich:

• Unicast: 1 Sender → 1 Empfänger. Für viele Empfänger muss der Sender denselben Stream mehrfach schicken.
• Broadcast: 1 Sender → alle Geräte im lokalen Netz. Das ist laut, ineffizient und wird von Routern in der Regel nicht weitergeleitet.
• Multicast: 1 Sender → viele Empfänger, aber nur die, die die Gruppe aktiv abonnieren.

Multicast ist besonders effektiv in Szenarien, in denen identische Daten an viele Empfänger gehen: IPTV, Live-Streaming in Unternehmensnetzen, Markt- oder Sensordaten, Discovery-Protokolle, verteilte Systeme oder Konferenz-/Push-Anwendungen. In gut geplanten Netzen reduziert Multicast die Bandbreite deutlich – vorausgesetzt, Switches und Router sind korrekt konfiguriert.

Die wichtigsten Teilbereiche innerhalb von 224.0.0.0/4

Der Multicast-Block ist nicht „ein Topf“. Er ist in Bereiche gegliedert, die unterschiedliche Reichweiten und Zwecke haben. Gerade diese Unterscheidung entscheidet darüber, ob Pakete geroutet werden dürfen oder bewusst lokal bleiben.

224.0.0.0/24: Link-Local Control – bleibt im lokalen Netz

Der Bereich 224.0.0.0 bis 224.0.0.255 ist für lokale Steuerungs- und Routingfunktionen gedacht. Ein zentraler Punkt: Diese Adressen sind typischerweise nicht routbar – sie bleiben auf dem lokalen Layer-2-Segment. Viele Router leiten diese Pakete nicht weiter, weil sie explizit für Link-Local-Verhalten gedacht sind.

Typische Beispiele aus 224.0.0.0/24:

• 224.0.0.1: All Hosts (alle Multicast-fähigen Hosts im Segment)
• 224.0.0.2: All Routers (alle Multicast-Router im Segment)
• 224.0.0.5 und 224.0.0.6: OSPF (AllSPFRouters, AllDRRouters)
• 224.0.0.9: RIPv2
• 224.0.0.10: EIGRP
• 224.0.0.18: VRRP
• 224.0.0.251: mDNS (Multicast DNS)
• 224.0.0.252: LLMNR

Gerade dieser Block ist ein häufiger Grund, warum du Multicast auch ohne „IPTV-Projekt“ in Logs und Paketmitschnitten findest: Viele grundlegende Netzwerkfunktionen nutzen ihn automatisch.

224.0.1.0 bis 238.255.255.255: „Global“ bzw. allgemein routbare Gruppen

Vereinfacht gesprochen ist der Bereich außerhalb des Link-Local-Blocks für Anwendungen gedacht, die über Routergrenzen hinweg arbeiten können. Ob Multicast tatsächlich geroutet wird, hängt allerdings von der Netzarchitektur ab: Multicast-Routing ist nicht automatisch aktiv. Du brauchst dafür passende Protokolle und Konfigurationen (z. B. PIM) und in vielen Umgebungen auch explizite Freigaben in Firewalls und ACLs.

239.0.0.0/8: Administratively Scoped Multicast (privater Multicast-Bereich)

239.0.0.0/8 ist der „private“ Multicast-Bereich – vergleichbar mit RFC-1918-Adressbereichen bei Unicast. Er ist dafür gedacht, Multicast innerhalb einer Organisation zu nutzen, ohne mit globalen Zuweisungen zu kollidieren. In Enterprise-Netzen ist 239/8 deshalb oft der Standard für IPTV, interne Streams, Telemetrie oder Event-Verteilung.

Wenn du Multicast in einem Unternehmen planst, ist 239/8 meist der erste Bereich, in den du schaust – nicht zuletzt, weil er in Policies und Dokumentationen sauber segmentiert werden kann.

Wie Hosts Multicast „abonnieren“: IGMP verständlich erklärt

Auf Layer 3 muss das Netzwerk wissen, welche Geräte welche Multicast-Gruppen empfangen wollen. Dafür wird bei IPv4 in der Regel IGMP (Internet Group Management Protocol) eingesetzt. IGMP ist kein „Transport“ für Multicast-Daten, sondern ein Signalisierungsprotokoll zwischen Hosts und dem lokalen Router (oder dem Switch mit IGMP-Snooping), das sagt: „Ich möchte Gruppe X empfangen.“

• IGMPv2: verbreitet, solide für viele klassische Multicast-Szenarien.
• IGMPv3: wichtig für SSM und Source-Filterung (Empfang nur von bestimmten Quellen).

Für IGMPv3 ist eine etablierte Referenz RFC 3376. In der Praxis ist IGMP oft die erste Stellschraube bei Problemen: Wenn ein Client „kein Bild“ bekommt, liegt es häufig daran, dass IGMP-Reports nicht korrekt ankommen oder vom Netzwerk (Snooping/Querier) falsch verarbeitet werden.

Damit Switches nicht flooden: IGMP Snooping und der Querier

Ohne spezielle Mechanismen würden Switches Multicast-Pakete wie Broadcast behandeln und an viele Ports fluten. Das ist in kleinen Netzen manchmal tolerierbar, in größeren jedoch ein Performance- und Sicherheitsproblem. IGMP Snooping sorgt dafür, dass der Switch IGMP-Nachrichten „mithört“ und Multicast nur an die Ports weiterleitet, an denen sich interessierte Empfänger befinden.

Ein wichtiger Punkt dabei ist der IGMP Querier. In VLANs ohne Multicast-Router muss ein Querier vorhanden sein, der periodisch Abfragen sendet, damit Snooping-Tabellen aktuell bleiben. Fehlt der Querier, kann es zu scheinbar „zufälligen“ Ausfällen kommen, weil Einträge auslaufen und der Switch nicht mehr weiß, wohin er Multicast liefern soll.

Multicast über Router hinweg: PIM, ASM und SSM

Wenn Multicast nicht nur im lokalen VLAN funktionieren soll, brauchst du Multicast-Routing. In vielen Netzwerken ist dafür PIM (Protocol Independent Multicast) üblich. PIM ist „protocol independent“, weil es nicht von einem bestimmten Unicast-Routingprotokoll abhängt; es nutzt die existierende Unicast-Routingtabelle für RPF-Prüfungen (Reverse Path Forwarding).

ASM: Any-Source Multicast (klassischer Ansatz)

Bei ASM kann jede Quelle an eine Multicast-Gruppe senden, und Empfänger abonnieren die Gruppe unabhängig von der Quelle. Das ist flexibel, benötigt aber in vielen Designs einen Rendezvous Point (z. B. PIM-SM), was Planung und Betrieb komplexer macht.

SSM: Source-Specific Multicast (gezielter und oft einfacher)

SSM reduziert Komplexität, weil Empfänger nicht nur eine Gruppe abonnieren, sondern eine Kombination aus Quelle und Gruppe. Dadurch entfällt in typischen SSM-Designs die Notwendigkeit eines Rendezvous Point. Ein häufig genutzter IPv4-Block für SSM ist 232.0.0.0/8. Eine hilfreiche Referenz für SSM-Grundlagen ist RFC 4607.

Multicast und MAC-Adressen: Warum Multicast auch Layer-2 betrifft

Bei Ethernet wird IPv4-Multicast auf spezielle Multicast-MAC-Adressen gemappt. Das ist ein Grund, warum Multicast ohne Snooping schnell „laut“ werden kann. Die typische MAC-Präfix-Zuordnung für IPv4-Multicast lautet 01:00:5e, wobei nur 23 Bits der IPv4-Multicast-Adresse in die MAC abgebildet werden. Das führt dazu, dass mehrere IPv4-Multicast-Gruppen auf dieselbe MAC-Adresse fallen können. In der Praxis bedeutet das: Selbst mit sauberer Layer-2-Behandlung kann Multicast in bestimmten Fällen mehr Ports erreichen als gedacht, wenn die Switch-Logik oder die Endgeräte-Filterung nicht sauber greifen.

TTL, Scope und „Wie weit reicht das?“

Ob Multicast-Pakete das lokale Netz verlassen, hängt nicht nur vom Adressbereich, sondern auch vom TTL-Wert (Time To Live) und von Router-Konfigurationen ab. Link-Local-Gruppen (224.0.0.0/24) sind konzeptionell lokal; in vielen Implementierungen werden sie nicht geroutet. Für andere Gruppen kann TTL als zusätzliche Begrenzung dienen. In Enterprise-Designs wird Scope häufig kombiniert:

• Adresswahl: 239/8 für interne Nutzung, 224.0.0.0/24 nur für lokale Steuerung
• Routing-Policy: Multicast nur in bestimmten VRFs oder zwischen definierten Segmenten
• TTL-Design: Begrenzung der Reichweite bei bestimmten Anwendungen

Typische Anwendungsfälle in Unternehmen und Netzbetrieb

• IPTV und Live-Streams: Ein Stream, viele Empfänger; Bandbreitenersparnis gegenüber Unicast.
• Konferenz- und Push-Systeme: Gruppenkommunikation, wenn Architektur und Netzwerk es unterstützen.
• Routing-Protokolle: OSPF, EIGRP und andere nutzen Multicast für Control-Plane-Kommunikation.
• Service Discovery: mDNS und ähnliche Mechanismen setzen Multicast ein (häufig bewusst auf lokales Segment begrenzt).
• Industrie-/IoT-Szenarien: Telemetrie-Streams oder Status-Updates, wenn viele Konsumenten existieren.

Multicast-Sicherheit: Warum „einfach einschalten“ selten eine gute Idee ist

Multicast kann Bandbreite sparen, aber es kann auch neue Angriffs- und Fehlkonfigurationsflächen öffnen. Häufige Risiken sind unkontrolliertes Flooding, unerwünschte Gruppenmitgliedschaften oder zu weit geroutete Multicast-Domänen.

• Segmentierung: Multicast nur dort erlauben, wo es wirklich gebraucht wird (z. B. separates VLAN/VRF für IPTV).
• ACLs und Policies: Multicast-Gruppenbereiche (z. B. 239/8) bewusst freigeben oder begrenzen.
• IGMP-Filter: Zulässige Gruppen einschränken, wenn Clients nur definierte Streams bekommen sollen.
• Monitoring: Multicast-Traffic und Gruppenmitgliedschaften sichtbar machen, um Fehlverhalten schnell zu erkennen.

Fehlersuche in der Praxis: Checkliste für typische Multicast-Probleme

• Empfänger bekommt nichts: Prüfen, ob der Client die Gruppe per IGMP joint (IGMP-Report sichtbar?).
• Multicast flutet ein VLAN: IGMP Snooping aktiv? Gibt es einen IGMP Querier? Ist Snooping korrekt pro VLAN?
• Funktioniert nur lokal, nicht standortübergreifend: Multicast-Routing aktiv (z. B. PIM)? RPF-Checks erfolgreich? Policies/ACLs erlauben Multicast?
• SSM-Stream funktioniert nicht: IGMPv3 auf Client und Infrastruktur? SSM-Bereich (z. B. 232/8) korrekt genutzt?
• Unerwartete Gruppen: Sind lokale Protokolle wie mDNS/LLMNR aktiv? Werden sie bewusst begrenzt?

Outbound-Links für Standards und verlässliche Nachschlagewerke

• RFC 1112: Grundlagen zu IP Multicast (Host Extensions)
• RFC 5771: IPv4 Multicast Address Assignments
• RFC 3376: IGMPv3 (Group Management und Source-Filterung)
• RFC 4607: Source-Specific Multicast (SSM) für IPv4/IPv6
• IANA: Registry der Multicast-Adresszuweisungen

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.