Ich habe erlebt, wie Netzwerke zusammenbrachen, weil 20 Monitore dasselbe zogen 4K-Stream1 über Unicast. Es ist schmerzhaft, teuer und 100% vermeidbar.
Ja, unsere industrietauglichen PTZ-Kameras unterstützen Multicast (IGMP v2/v3) vollständig. In einem großen LAN, in dem mehrere Clients gleichzeitig denselben H.265-Stream benötigen, sendet die Kamera nur eine Kopie des Videos. Die Netzwerk-Switches replizieren dann diesen einzelnen Stream an jeden Betrachter. Dies reduziert Ihre Backbone-Bandbreite von N × Bitrate auf 1 × Bitrate, unabhängig davon, wie viele Bildschirme zuschauen.

Im Folgenden gehe ich auf die häufigsten Fragen ein, die ich von Systemintegratoren und CTOs zur Multicast-Bereitstellung erhalte. Jede Antwort basiert auf realer Projekterfahrung, nicht auf einem Datenblatt-Copy-Paste. Wenn Sie eine Multi-Station-Überwachungslösung, ein werkweites Überwachungsnetzwerk oder ein projektübergreifendes VLAN-Projekt planen, lesen Sie weiter.
Inhaltsübersicht
Wie viele gleichzeitige Clients können einen einzelnen 4K-Stream über Multicast in meinem Netzwerk ansehen?
Jedes Mal, wenn ich “unbegrenzte Zuschauer, gleiche Bandbreite” zitiere, denken die Leute, ich übertreibe. Das tue ich nicht. Aber es gibt einen Haken, den die meisten Anbieter Ihnen nicht verraten werden.
Mit aktiviertem Multicast ist die Anzahl der gleichzeitigen Clients, die einen einzelnen 4K-Stream ansehen, nicht durch die Kamera begrenzt. Sie wird durch Ihre Switch-Fabric und die IGMP-Snooping-Kapazität begrenzt. In der Praxis kann ein korrekt konfigurierter Managed Switch 50, 100 oder sogar 200+ Endpunkte von einem 8-Mbit/s-Stream bedienen, ohne zusätzliche Last auf den Uplink-Port der Kamera zu legen.

Warum die Kamera nicht mehr der Flaschenhals ist
Bei einer Unicast3 Einrichtung muss die CPU und die Netzwerkschnittstelle der Kamera eine separate RTP-Sitzung8 für jeden einzelnen Betrachter generieren. Ich habe dies an vielen Kameras in unserem Labor getestet. Die meisten PTZ-Kameras beginnen nach 8–10 gleichzeitigen Unicast-Verbindungen, Frames zu verlieren. Einige billigere Modelle frieren bei 5 ein. Der Kamera geht einfach die Rechenleistung aus.
Mit Multicast erstellt die Kamera eins IGMP-Gruppenstream. Das ist alles. Ein Stream verlässt den Ethernet-Port der Kamera. Die Replikationsarbeit wird vollständig auf die Netzwerkinfrastruktur verlagert.
Wo die eigentliche Grenze liegt
Die tatsächliche Obergrenze hängt von drei Dingen in Ihrem Netzwerk ab:
| Faktor | Was es steuert | Typische Grenze |
|---|---|---|
| Switch-Backplane-Bandbreite | Gesamtdaten, die der Switch intern bewegen kann | 48–256 Gbit/s bei Enterprise-Switches |
| IGMP-Snooping-Tabellengröße | Wie viele Multicast-Gruppen und Mitglieder der Switch verfolgen kann | 1.000–8.000 Einträge bei Cisco Catalyst-Serien |
| Uplink-Port-Geschwindigkeit | Die Leitung zwischen Ihrem Access-Switch und Core-Switch | 1 Gbit/s oder 10 Gbit/s |
Wenn Ihr 4K H.265-Stream also mit 8 Mbit/s läuft und Ihr Uplink 1 Gbit/s beträgt, ist die Rechnung einfach. Der Uplink kann 125 Kopien dieses Streams tragen. Aber mit Multicast trägt er nur eins Kopie auf diesem Uplink. Der Access-Switch auf der Seite des Betrachters übernimmt die Replikation lokal.
Eine reale Zahl
In einem kürzlich durchgeführten Fabrikprojekt verband einer unserer Partner in Europa 64 Überwachungsarbeitsplätze mit einem einzigen 4K PTZ-Stream. Der Uplink-Port der Kamera blieb bei flachen 8 Mbit/s. Die CPU-Auslastung der Kamera blieb unter 30%. Keine Frame-Drops. Keine Latenzspitzen. Der Schlüssel war, dass bei jedem Switch im Pfad IGMP Snooping aktiviert war.
Was passiert ohne IGMP Snooping
Wenn Sie IGMP Snooping überspringen, behandelt der Switch den Multicast-Stream wie eine Broadcast-Übertragung. Jeder Port auf jedem Switch erhält die Videodaten. Ihre Drucker, Ihre VoIP-Telefone, Ihre Zugangskontrollpaneele – sie alle empfangen 8 Mbit/s Video, das sie nie angefordert haben. Ich habe gesehen, wie dies ein ganzes Büronetzwerk in weniger als 10 Minuten zum Absturz brachte. Die Antwort auf “wie viele Clients” lautet also eigentlich “so viele, wie Ihre Switches verarbeiten können”, aber nur, wenn Ihre Switches korrekt konfiguriert sind.
Hilft Multicast, Netzwerküberlastungen beim Streaming an mehrere Sicherheitsstationen zu verhindern?
Ich spreche jede Woche mit Integratoren, die der Kamera ruckelnde Videos vorwerfen. Neun von zehn Mal ist das Problem nicht die Kamera. Es ist die Netzwerkarchitektur.
Multicast ist die wirksamste Methode, um Netzwerküberlastungen zu vermeiden, wenn mehrere Sicherheitsstationen denselben Kamerastream anzeigen. Anstatt dass die Kamera Duplikatströme an jede Station sendet, sendet sie einen Stream, und das Netzwerk liefert ihn effizient. Dies eliminiert das multiplikative Bandbreitenproblem, das Überlastung, Paketverlust und eingefrorene Videos verursacht.

Die Überlastungsrechnung: Unicast vs. Multicast
Lassen Sie mich hier reale Zahlen nennen. Sagen wir, Sie haben einen Kontrollraum mit 16 Monitoren, und jeder Monitor zeigt eine andere Kamera. Aber 4 dieser Monitore zeigen die selbe PTZ-Kamera – vielleicht ein Torzugang oder eine kritische Perimeteransicht.
Unicast-Szenario:
- Kamera sendet 4 separate Streams mit jeweils 6 Mbps.
- Kamerauplink-Auslastung: 24 Mbit/s.
- Core-Switch muss 4 unabhängige Flows routen.
- Wenn 3 weitere Stationen in einem zweiten Gebäude diesen Stream ebenfalls wünschen, sendet die Kamera jetzt 42 MBit/s für eine einzige Ansicht.
Multicast-Szenario:
- Kamera sendet 1 Stream mit 6 Mbps.
- Jeder Switch entlang des Pfades trägt nur 6 Mbit/s für diese Kamera, unabhängig davon, wie viele Endpunkte abonnieren.
- Kamer-CPU bleibt untätig. Uplink bleibt sauber.
Die Staupunkte, die die meisten Leute übersehen
Netzwerküberlastung tritt nicht immer dort auf, wo Sie es erwarten. Hier sind die drei häufigsten Engpässe, die ich in großen Überwachungs-LANs sehe:
| Engpass | Warum es überlastet wird | Wie Multicast es behebt |
|---|---|---|
| Kamera-Uplink-Port | Mehrere Unicast-Sitzungen sättigen den 100-Mbit/s-Port | Nur ein Stream verlässt die Kamera |
| Core-Switch-Uplink | Aggregierter Datenverkehr von Dutzenden von Kameras überfordert den Trunk | Multicast-Verkehr wird am Edge repliziert, nicht am Core |
| Drahtlose Brückenverbindung | Begrenzte Durchsatzrate (oft 50–100 Mbit/s effektiv), die von allem Datenverkehr gemeinsam genutzt wird | Eine Kopie überquert die Brücke; lokaler Switch repliziert |
Besonderer Hinweis für Solar-4G-Off-Grid-Projekte
David, ich weiß, dass viele Ihrer Projekte unsere 4G-Solar-PTZ-Systeme in abgelegenen Gebieten einsetzen. Hier ist die ehrliche Wahrheit: Standard-4G/5G-öffentliche Netze unterstützen kein Multicast. Mobilfunkanbieter blockieren IGMP-Verkehr in ihrer Infrastruktur. Wenn Ihre Remote-Kamera also Video über 4G an ein Cloud-VMS sendet, hilft Multicast auf diesem WAN-Segment nicht.
Wenn Sie jedoch ein lokales drahtloses Brückennetzwerk zwischen mehreren Masten auf einer Baustelle einrichten – sagen wir eine Baustelle mit 5 Kameramasten und einem Baustellenbüro –, dann wird Multicast sehr nützlich. Drahtlose Brücke7 überträgt nur eine Kopie jedes Streams. Der Switch im Baubüro repliziert ihn auf den Laptop des Poliers, den Monitor des Sicherheitsbeauftragten und den NVR. Diese Konfiguration kann Ihre drahtlose Brückenlast um 60–70 % reduzieren.
IGMP Snooping: Die nicht verhandelbare Anforderung
Ich kann das nicht genug betonen. Ohne IGMP Snooping2 auf jedem Switch im Pfad aktiviert, flutet Multicast-Verkehr jeden Port. Dies ist schlimmer als Unicast, da nun jedes Gerät im VLAN den Videostream empfängt. Das Ergebnis ist ein Broadcast-Sturm. Ich sage unseren Partnern immer: Bevor Sie Multicast auf der Kamera aktivieren, stellen Sie sicher, dass IGMP Snooping auf Ihren Switches aktiv ist. Überprüfen Sie die Switch-Verwaltungsoberfläche. Suchen Sie nach dem IGMP Snooping-Status unter den VLAN-Einstellungen. Wenn dort “deaktiviert” steht, beheben Sie dies zuerst.
Ist die Multicast-Implementierung mit Standard Cisco oder Juniper Layer-3-Switches kompatibel?
Diese Frage stelle ich oft von nordamerikanischen Integratoren. Sie verwenden Cisco oder Juniper in jedem Rack und benötigen eine klare Antwort, bevor sie unsere Kameras in ein Angebot aufnehmen.
Unsere PTZ-Kameras verwenden Standard-IGMP-v2- und IGMP-v3-Protokolle für Multicast. Das bedeutet, dass sie vollständig kompatibel mit jedem verwalteten Switch sind, der IGMP Snooping unterstützt, einschließlich Cisco Catalyst, Cisco Nexus, Juniper EX-Serie, HPE Aruba und H3C. Es gibt kein proprietäres Protokoll. Wenn Ihr Switch IGMP spricht, funktioniert er mit unserer Kamera.

Warum Standards wichtiger sind als Markennamen
Einige Kamerahersteller verwenden proprietäre Streaming-Methoden, die nur mit ihren eigenen NVRs oder ihrer eigenen Software funktionieren. Das bindet Sie an ein einziges Ökosystem. Unsere Kameras folgen ONVIF Profil T4, das genau definiert, wie Multicast konfiguriert und erkannt werden soll. Jedes ONVIF-konforme VMS – Milestone, Genetec, Blue Iris, Digifort – kann die Multicast-Gruppenadresse automatisch erkennen und den Stream empfangen.
IGMP-Versionskompatibilität
Es gibt zwei IGMP-Versionen, die in der Praxis wichtig sind:
- IGMP v2: Die am weitesten verbreitete Version. Unterstützt grundlegende Join- und Leave-Nachrichten. Funktioniert mit fast jedem verwalteten Switch, der in den letzten 15 Jahren hergestellt wurde.
- IGMP v3: Fügt Source-Specific Multicast (SSM) hinzu. Dies ermöglicht es dem Switch, den Datenverkehr nicht nur nach Gruppenadresse, sondern auch nach Quell-IP zu filtern. Nützlich in sehr großen Netzwerken, in denen mehrere Kameras denselben Gruppenadressbereich verwenden könnten.
Unsere Kameras unterstützen beides. Die Kamera verwendet standardmäßig IGMP v2 für maximale Kompatibilität. Sie können in der Weboberfläche auf v3 umschalten, falls Ihr Netzwerk dies erfordert.
Getestete Switch-Plattformen
Ich möchte hier spezifisch sein, da vage Kompatibilitätsaussagen die Zeit aller verschwenden. Unser Ingenieurteam hat Multicast-Streaming auf den folgenden Plattformen getestet:
| Switch-Plattform | IGMP Snooping | Multicast-Routing | Testergebnis |
|---|---|---|---|
| Cisco Catalyst 2960/3560/3850 | Unterstützt | Unterstützt (L3-Modelle) | ✅ Volle Kompatibilität |
| Cisco Nexus 3000/5000 | Unterstützt | Unterstützt | ✅ Volle Kompatibilität |
| Juniper EX2300/EX3400 | Unterstützt | Unterstützt | ✅ Volle Kompatibilität |
| HPE Aruba 2530/2930 | Unterstützt | Unterstützt (2930) | ✅ Volle Kompatibilität |
| H3C S5130/S5560 | Unterstützt | Unterstützt | ✅ Volle Kompatibilität |
| TP-Link TL-SG3428 | Unterstützt | Eingeschränkt | ✅ Funktioniert für einzelne VLANs |
Was ist mit Unmanaged Switches?
Unmanaged Switches unterstützen kein IGMP Snooping. Wenn Sie unsere Kamera an einen günstigen Unmanaged Switch anschließen und Multicast aktivieren, wird der Switch den Stream an alle Ports fluten. Das vereitelt den gesamten Zweck. Für jedes Projekt, bei dem Multicast wichtig ist, benötigen Sie Managed Switches. Dies ist keine Einschränkung der Kamera. Es ist eine grundlegende Netzwerkanforderung.
Herstellerübergreifende Interoperabilität in der Praxis
Einer unserer Partner im Nahen Osten betreibt ein gemischtes Netzwerk: Cisco Core-Switches, H3C Distribution-Switches und TP-Link Access-Switches. Sie aktivierten Multicast auf 24 unserer PTZ-Kameras. Jeder Switch verarbeitete die IGMP-Joins korrekt. Das Video wurde auf allen über 40 Arbeitsplätzen reibungslos abgespielt. Das einzige Problem, auf das sie stießen, war ein TP-Link-Switch, bei dem IGMP Snooping standardmäßig deaktiviert war. Sobald sie es einschalteten, funktionierte alles. Die Lektion: Überprüfen Sie jeden Switch im Pfad, nicht nur den Core.
Kann ich eine eindeutige Multicast-Gruppen-IP und TTL (Time to Live) für mein projektübergreifendes VLAN festlegen?
Cross-VLAN-Multicast ist der Punkt, an dem die meisten Projekte kompliziert werden. Ich habe Dutzenden von Integratoren geholfen, dieses genaue Szenario zu beheben, und die Antwort beginnt mit der richtigen Konfiguration auf der Kameraseite.
Ja, Sie können eine benutzerdefinierte Multicast-Gruppen-IP-Adresse und einen TTL-Wert direkt in der Weboberfläche der Kamera konfigurieren. Die Gruppen-IP kann jede gültige Klasse-D-Adresse zwischen 224.0.0.0 und 239.255.255.255 sein. Die TTL kann von 1 bis 255 eingestellt werden und steuert, wie viele Router-Hops der Stream durchlaufen kann. Für Cross-VLAN-Bereitstellungen stellen Sie die TTL auf mindestens 16 ein, um sicherzustellen, dass der Stream Ihre Layer-3-Routing-Grenzen durchläuft.

Verstehen der Multicast-Adresse und warum sie wichtig ist
Eine Multicast-Gruppen-IP ist keine normale IP-Adresse. Sie gehört keinem einzelnen Gerät. Sie ist ein “Kanal”, den jedes Gerät abonnieren kann. Stellen Sie es sich wie eine Radiofrequenz vor. Die Kamera sendet auf einem bestimmten Kanal, und jeder Client, der einschaltet, empfängt den Stream.
Unsere Kameras ermöglichen die Konfiguration separater Multicast-Adressen und Ports für drei Datentypen:
- Videostream: Der Haupt-H.265- oder H.264-Videofeed.
- Audiostream: Zwei-Wege- oder Ein-Weg-Audio, falls Ihr Projekt dies erfordert.
- Metadatenstrom: KI-Analyseergebnisse, wie z. B. Bounding Boxes für menschliche Erkennung, Nummernschilddaten oder Auslöser für Bewegungsereignisse.
Diese Trennung ist wichtig. Einige VMS-Plattformen abonnieren nur die Video-Multicast-Gruppe. Andere benötigen die Metadatengruppe, um KI-Overlays anzuzeigen. Durch die Zuweisung unterschiedlicher Gruppenadressen halten Sie den Datenverkehr organisiert und geben Ihrem VMS eine granulare Kontrolle darüber, was es empfängt.
TTL: Der Schlüssel für Cross-VLAN
TTL steht für Time to Live. Jedes Mal, wenn ein Multicast-Paket eine Layer-3-Grenze (einen Router oder einen Layer-3-Switch, der Inter-VLAN-Routing durchführt) überschreitet, verringert sich die TTL um 1. Wenn sie 0 erreicht, wird das Paket verworfen.
- TTL = 1: Der Stream bleibt im lokalen Subnetz. Er überschreitet keinen Router. Gut für Single-VLAN-Setups.
- TTL = 16: Der Stream kann bis zu 16 Routing-Hops überqueren. Das ist für die meisten Campus-Netzwerke mit mehreren VLANs ausreichend.
- TTL = 32: Sicher für sehr große Unternehmensnetzwerke mit komplexen Routing-Topologien.
- TTL = 128 oder 255: Nur für Multi-Site-WAN-Multicast erforderlich, was bei Überwachung selten vorkommt.
Ich empfehle normalerweise TTL = 32 als sicheren Standard für VLAN-übergreifende Projekte. Dies bietet genügend Spielraum, ohne unnötigen Traffic in entfernte Netzwerksegmente zu lecken.
VLAN-übergreifendes Multicast: Die Netzwerkseite
Das Einstellen der TTL an der Kamera ist nur die halbe Miete. Ihr Netzwerk muss auch so konfiguriert sein, dass Multicast-Traffic zwischen VLANs geroutet wird. Dies erfordert:
- PIM (Protocol Independent Multicast)5: Muss auf den Layer-3-Schnittstellen Ihres Core-Switches oder Routers aktiviert sein. PIM-SM (Sparse Mode) ist die gängigste Wahl.
- Rendezvous Point (RP)6: In PIM-SM müssen Sie einen Router als RP festlegen. Dies ist der Treffpunkt, an dem sich Quellen und Empfänger finden.
- IGMP auf jeder VLAN-Schnittstelle: Der Layer-3-Switch muss IGMP auf jedem VLAN SVI (Switched Virtual Interface) ausführen, auf dem Kameras oder Viewer vorhanden sind.
Konfigurationspfad an der Kamera
Die Einrichtung ist unkompliziert. Melden Sie sich in der Weboberfläche der Kamera an. Navigieren Sie zu:
Netzwerk > Erweiterte Einstellungen > Multicast
Von dort aus können Sie Folgendes einstellen:
- Multicast-Gruppen-IP-Adresse (z. B. 239.1.1.10)
- Multicast-Port (z. B. 8600 für Video, 8602 für Audio, 8604 für Metadaten)
- TTL-Wert (z. B. 32)
- Multicast pro Stream aktivieren oder deaktivieren (Hauptstream, Substream)
Nach dem Speichern beginnt die Kamera sofort mit dem Senden von IGMP-Mitgliedschaftsberichten. Jeder IGMP-fähige Switch im Netzwerk erkennt die neue Multicast-Quelle und beginnt, den Stream an abonnierte Clients weiterzuleiten.
Ein praktischer Tipp für große Projekte
Wenn Sie 50 oder mehr Kameras einsetzen, planen Sie Ihre Multicast-Gruppenadressen sorgfältig. Ich empfehle die Verwendung des 239.x.x.x Bereichs (administrativ definierte Adressen) und die Zuweisung einer eindeutigen Gruppen-IP an jede Kamera. Zum Beispiel:
- Kamera 01: 239.1.1.1
- Kamera 02: 239.1.1.2
- Kamera 50: 239.1.1.50
Dies erleichtert die Fehlerbehebung erheblich. Wenn ein bestimmter Stream Probleme aufweist, können Sie in Wireshark nach Gruppen-IP filtern und das Problem in Sekundenschnelle isolieren.
Schlussfolgerung
Unsere PTZ-Kameras unterstützen Multicast vollständig mit IGMP v2/v3, benutzerdefinierten Gruppen-IPs und einstellbarer TTL. Kombinieren Sie sie mit verwalteten Switches, und Ihr großes LAN bleibt sauber, schnell und skalierbar.
1. Details zur 4K-Auflösung und ihren Bandbreitenanforderungen. ︎↩︎ 2. Cisco-Dokumentation zu IGMP Snooping zur Steuerung des Multicast-Datenverkehrs auf Switch-Ebene. ︎↩︎ 3. Verständnis von Unicast vs. Multicast für Video-Streaming. ︎↩︎ 4. Offizielles ONVIF-Profil für erweiterte PTZ- und Multicast-Streaming-Funktionen. ︎↩︎ 5. Erfahren Sie mehr über das PIM-Routing-Protokoll für Multicast über Netzwerksegmente hinweg. ︎↩︎ 6. Cisco Whitepaper über Rendezvous Point im PIM-SM Multicast-Routing. ︎↩︎ 7. Erklärung der drahtlosen Brücke zur Erweiterung von Netzwerkverbindungen. ︎↩︎ 8. Erfahren Sie mehr über RTP für die Echtzeit-Audio- und Videoübertragung. ︎↩︎