11
Verständnisfrage Multicast-Livestream in andere Netze
Moin werte Community,
um das kurz Vorweg zu nehmen: Es geht darum einen Multicast-Livestream auch in andere Netze zu bringen. Ich scheitere an der Konfiguration und eventuell auch am Verständnis von Multicast.
Stand der Dinge:
Wir wollen in unserem Unternehmen einen Livestream einer Extron-Konferenzanlage allen Mitarbeitern zur Verfügung stellen.
Diese Anlage bzw. der Stream wurde anfangs auf PULL/Unicast konfiguriert und dann via RTP-Protokoll und VLC-Media Player aufgerufen.
Da sich jeder Client den Videostream ziehen musste ist die Bandbreite schnell in die Knie gegangen. Mehr als 15 Personen waren nicht möglich.
Lösung? Multicast. Dachten wir uns so einfach...
Den Stream haben wir prompt auf PUSH umgestellt und eine x-beliebige Multicast IP gesetzt. Auf den Switchen wurde IGMP-Snooping aktiviert.
Diese Multicastadresse ist seitdem auch im LAN (10.99.X.X.) mit VLC erreichbar.
Es funktioniert super und mehr als 15 Personen können schauen. Rein theoretisch ja so viele wie das Subnetz hergibt?
Wir wollen diesen Multicast-Stream aber nicht nur über das LAN erreichen, indem auch die Anlage sitzt, sondern der WLAN-Range und VPN-Range soll ebenfalls zuschauen können.
Hier kommen wir nicht mehr weiter. Das Verständnis für Multicast fehlt hier auch ganz eventuell.
Wir haben auf der Firewall eine Regel erstellt ... 239.255.255.250 (gesetzte MC-IP) darf ins 10.100.X.X. (WLAN) und 10.101.X.X. (VPN) sprechen und andersherum.
Auf der Firewall ist beim aktiven Stream nichts zu sehen. Es kommt nichts an. Auch wenn ein Client die 239... anspricht, kommt nichts auf der FW an.
Das verstehe ich eigentlich auch, weil der Stream ja selbstständig gar nicht versucht in andere Netze zu gelangen. Und der Client, wieso fragt er nicht sein Gateway nach der Adresse?
Es müsste eher ein Routing stattfinden, dass den Multicast-Stream entgegen nimmt und in andere Netze weitergibt, oder?
Wie wird sowas realisiert? Liege ich in der Annahme richtig?
Ich freue mich auf geballtes Fachwissen ;)
um das kurz Vorweg zu nehmen: Es geht darum einen Multicast-Livestream auch in andere Netze zu bringen. Ich scheitere an der Konfiguration und eventuell auch am Verständnis von Multicast.
Stand der Dinge:
Wir wollen in unserem Unternehmen einen Livestream einer Extron-Konferenzanlage allen Mitarbeitern zur Verfügung stellen.
Diese Anlage bzw. der Stream wurde anfangs auf PULL/Unicast konfiguriert und dann via RTP-Protokoll und VLC-Media Player aufgerufen.
Da sich jeder Client den Videostream ziehen musste ist die Bandbreite schnell in die Knie gegangen. Mehr als 15 Personen waren nicht möglich.
Lösung? Multicast. Dachten wir uns so einfach...
Den Stream haben wir prompt auf PUSH umgestellt und eine x-beliebige Multicast IP gesetzt. Auf den Switchen wurde IGMP-Snooping aktiviert.
Diese Multicastadresse ist seitdem auch im LAN (10.99.X.X.) mit VLC erreichbar.
Es funktioniert super und mehr als 15 Personen können schauen. Rein theoretisch ja so viele wie das Subnetz hergibt?
Wir wollen diesen Multicast-Stream aber nicht nur über das LAN erreichen, indem auch die Anlage sitzt, sondern der WLAN-Range und VPN-Range soll ebenfalls zuschauen können.
Hier kommen wir nicht mehr weiter. Das Verständnis für Multicast fehlt hier auch ganz eventuell.
Wir haben auf der Firewall eine Regel erstellt ... 239.255.255.250 (gesetzte MC-IP) darf ins 10.100.X.X. (WLAN) und 10.101.X.X. (VPN) sprechen und andersherum.
Auf der Firewall ist beim aktiven Stream nichts zu sehen. Es kommt nichts an. Auch wenn ein Client die 239... anspricht, kommt nichts auf der FW an.
Das verstehe ich eigentlich auch, weil der Stream ja selbstständig gar nicht versucht in andere Netze zu gelangen. Und der Client, wieso fragt er nicht sein Gateway nach der Adresse?
Es müsste eher ein Routing stattfinden, dass den Multicast-Stream entgegen nimmt und in andere Netze weitergibt, oder?
Wie wird sowas realisiert? Liege ich in der Annahme richtig?
Ich freue mich auf geballtes Fachwissen ;)
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 561376
Url: https://administrator.de/contentid/561376
Printed on: April 25, 2024 at 04:04 o'clock
11 Comments
Latest comment
Moin,
das Gateway, also deine Firewall so wie sich das ließt, muss einen IGMP-Proxy bereit stellen um den Stream wenn nötig in die anderen Netze zu tragen. Von Haus aus hört Multicast am GW/Broadcast Domain auf.
Damit solltest du es ans laufen bringen können.
Führ nähere Hilfe sind definitiv mehr Infos zur eingesetzten HW nötig.
Gruß
Spirit
das Gateway, also deine Firewall so wie sich das ließt, muss einen IGMP-Proxy bereit stellen um den Stream wenn nötig in die anderen Netze zu tragen. Von Haus aus hört Multicast am GW/Broadcast Domain auf.
Damit solltest du es ans laufen bringen können.
Führ nähere Hilfe sind definitiv mehr Infos zur eingesetzten HW nötig.
Gruß
Spirit
Führ nähere Hilfe sind definitiv mehr Infos zur eingesetzten HW nötig.
Richtig !Es geht darum einen Multicast-Livestream auch in andere Netze zu bringen.
OK, ist kein Problem macht man mit PIM Multicast Routing über den Router.Da sich jeder Client den Videostream ziehen musste ist die Bandbreite schnell in die Knie gegangen.
War klar und weiss man auch als Netzwerker. 
Lösung? Multicast. Dachten wir uns so einfach...
Ist auch nicht ganz falsch gedacht !und eine x-beliebige Multicast IP gesetzt.
Uuuhhh böses Faul ! Nicht gut...X-beliebig klingt recht dillettantisch so als ob du nicht wirklich weisst was du da tust.
Man kann nicht jede Adresse nehmen, denn eine ganze Menge davon sind reserviert und viele sind gar nicht routebar. Sog. Link Local Multicasts !
Also besser mal VORHER nachdenken !
Der Multicast Adress Block 239.0.0.0 bis 239.255.255.255 und speziell 239.255.0.0 /16 ist für lokale IP Netze dafür definiert. Das ist quasi das RFC1918 der Multicast Welt und man tut gut daran sich danach zu richten !
sondern der WLAN-Range und VPN-Range soll ebenfalls zuschauen können.
Ist kein Problem !Auch wenn ein Client die 239... anspricht, kommt nichts auf der FW an.
Kein Wunder wenn du dort kein PIM Sparse Routing definierst und die entsprechenden Firewall Regeln auf die Interfaces legst um den Traffic passieren zu lassen !Man muss es eben richtig machen damit es klappt !
weil der Stream ja selbstständig gar nicht versucht in andere Netze zu gelangen.
Richtig !Und der Client, wieso fragt er nicht sein Gateway nach der Adresse?
Das zeigt leider das du MC noch nicht wirklich durchdrungen hast. Das rennt alles über das IGMP Protokoll.Wie wird sowas realisiert?
Eigentlich ganz einfach. Simple 3 Schritte:- Auf den beteiligten L2 Switches IGMP Snooping aktivieren
- Rendezvous Point IP auf einem der beteiligten Router festlegen
- IP PIM Sparse Routing aktivieren auf allen Router Interfaces die IP Netze bedienen in denen sich Multicast Nutzer und Quellen befinden.
- Fertisch !
UPNP mit Mikrotik Routerboard hEX PoE und D-Link DGS-1210-24 Switch
Auf einem Cisco z.B. so:
!
ip multicast routing
!
interface Loopback 1
ip address 10.9.9.9 /32
ip pim-sparse
!
interface Ethernet 0/1
description LAN 1
ip address 10.1.1.1/24
ip pim-sparse
!
interface Ethernet 0/2
description LAN 2
ip address 10.2.2.1/24
ip pim-sparse
!
ip pim rp-address 10.9.9.9
!
Im Grunde kein Hexenwerk und in 10 Minuten aufgesetzt bei richtiger Hardware.
Hier hast du mal einen Tipp wie man sowas lokal mit dem Klassiker VLC einfach und effizient testen kann:
Fehlersuche im lokalem Netzwerk (RSTP, MRP, Multicast)
Eine weiteres sinnvolles Test Tool ist der "MC-Hammer"
https://multicast-hammer.software.informer.com/2.1/
Alt, aber rennt fehlerlos auf Win 10.
Besser da realistischer ist aber der VLC Film Test.
Deine Annahmen sind soweit nicht verkehrt - aber ich hoffe dir ist bewusst das du ausserhalb deines Netzwerkes trotzdem die entsprechende Bandbreite brauchst? Bei VPN-Anmeldungen muss das Datenpaket ja trotzdem zu jedem Client hin -> und damit über deine Bandbreite die du am Router hast. Wenn du 10 Clients hast brauchst du eben auch 10x die Bandbreite des Kanals. EIGENTLICH selbsterklärend - aber da ich schon zu oft gehört habe das Leute verwundert sind warum die denn Multicast haben und trotzdem soviel Bandbreite nötig ist lieber noch mal dazu gesagt....
Wenn du 10 Clients hast brauchst du eben auch 10x die Bandbreite des Kanals.
Das gilt aber rein nur für ein externes Client VPN. Im lokalen LAN oder bei einer Site to Site Kopplung per VPN ist das natürlich nicht so. Da ist MC erheblich effizienter. Nicht umsonst nutzen die Provider für IPTV immer Multicast. Mit Unicast wäre sowas wegen der sehr limitierten Skalierbarkeit technisch unmöglich zu bewerkstelligen.Der TO ist hier also mit dem Multicast Ansatz im lokalen LAN auf dem richtigen Weg !
Man muss es nur richtig machen !
Auch im internen Netz kommt es drauf an wo man den Multicast-Router setzt... Nehmen wir an du hast Core - Distri - Access als switches, dein Multicast-Routing is aufm Core. Dann muss auf die Leitung vom Core bis hin zum Endgerät natürlich auch die Bandbreite pro Client genommen werden. Was nur idR. keine Rolle spielt da man dort eben 100MBit, GBit oder sogar 10GBE hat. Der Vorteil von MC ist nicht der Empfänger, der Vorteil ist das der SENDER eben nicht n mal die Bandbreite braucht. Ohne MC müsste der Sender ja für jedes Gerät den Stream erzeugen -> und dann wirds Eng sowohl von der Bandbreite als auch von der CPU-Last... Mit MC sendet der halt genau einmal den Stream raus - und hat entsprechend die Resourcen frei....
Dann muss auf die Leitung vom Core bis hin zum Endgerät natürlich auch die Bandbreite pro Client genommen werden.
Nein, das ist grundfalsch !Hier machst du einen fatalen Denkfehler vermutlich aus Unkenntniss des IGMP Protokolls.
Gehen wir mal davon aus das der MC Server am Core Switch angeschlossen ist. Z.B. ein RasPi mit VLC der per Multicast zwei Filme streamed wie HIER beschrieben. Film 1 = 239.255.1.1 und Film 2 = 239.255.1.2.
Sofern du das MC Streaming startest passiert erstmal gar nichts im Netz.
Jetzt startest du einen Client mit VLC im Access an einem Access Switch Port 10 mit aktiviertem IGMP Snooping.
Wenn du jetzt dort Öffne Netzwerkstream klickst und rtp:@239.255.1.1 eingibst, dann sendet der VLC Client einen IGMP Join Request für die MC Gruppe 239.255.1.1 an den Access Switch. Damit "bucht" dieser dann diese Multicast Adresse und der RTP Flow startet und wird vom Access Switch nur an den Switch Port des Client-1 (10) gesendet.
Der Switch"merkt"sich diese MC Gruppe.
Kommt jetzt ein 2ter Client z.B. am Switchport 20 dazuweiss// der Switch ja schon das er aktiv MC Gruppe 239.255.1.1 anliegen hat und forwardet den Flow dann zusätzlich nur auf Port 20 OHNE das ein weiterer Flow zum Core Switch etabliert würde.
Das wäre ja auch ziemlicher Blödsinn aus technischer Sicht denn warum sollte man es mehrmals machen ? Wäre ja sinnfrei.
Kommen jetzt 10 weitere Clients für die Gruppe 239.255.1.1 dazu werden nur die entsprechenden Access Ports geöffnet aber eben NICHT zusätzliche Flows über den Core-Distribution Baum.
Kommen dann noch weitere 10 Clients dazu für Film 2 dazu dann hast du über den Core-Distribution Baum nur 2 ! Flows statt 20 !
Kommen am Access Switch 2 dann noch weitere 20 Clients dazu werden lediglich nur 2 weitere Flows auf dem Uplink vom Distribution zum Access Switch 2 geöffnet NICHT aber weitere im Core-Distribution Baum !
Eben DAS ist ja der gravierende Vorteil und tiefere Sinn von Multicast das du erheblich skalierbar über die Bandbreite Audio und Video oder andere Daten an eine Vielzahl von Clients verteilen kannst.
Fazit:
Nimm dir einen Raspberry Pi lade dir den Film und VLC runter wie oben beschrieben, bewaffne dich mit dem Wireshark und sieh dir an wie Multicast wirklich funktioniert !
Zumindest aber ziehe dir die Multicast Lernfilme von Anthony rein:
https://www.youtube.com/watch?v=AvbSMBKBZgY
Also immer vorher nachdenken. Nicht das du die Administrator Gemeinde hier noch mit völlig falschem Netzwerk KnowHow verwirrst !!
Ein Bild sagt mehr als 1000 Worte...:
Der Client schickt ein IGMP Join Request an 224.0.0.2 (v2) bzw. bei v3 dann 224.0.0.22 und der Dienst startet dann mit der entsprechend customizten Multicast Adresse. (Hier 239.255.1.2, .150 ist ein Server der ein Video mit Ton ins Netz streamt per RTP)
Works as designed !
Ok - an der stelle bin ich jetzt raus... sorry, aber ich weiss nicht ob es wirklich deine Art ist so überheblich tun zu müssen aber ganz ehrlich, auf dem Level diskutiere ich nicht.. Mag durchaus sein das ich hier einen Denkfehler gemacht habe - will ich nicht mal abstreiten. Aber die Oberlehrer-Art muss ich mir für Diskussionen auch nicht wirklich antun.
Sorry, verstehe ich jetzt nicht, denn es ist doch rein technisch und emotionslos erklärt !
Du solltest hier auch mal die Kirche im Dorf lassen, denn wenn man jetzt böse argumentiert (was hier keiner macht) dann hast du in einem Administrator Forum eine technisch und auch sachlich völlig falsche Erklärung abgeliefert. Das ist so als wenn einer einem im KFZ Forum erklärt das man Wasser statt Benzin tanken kann.
Den Fragesteller also, obwohl er genau auf dem richtigen Weg war, damit überflüssigerweise in eine vollkommen falsche Richtung gelenkt mit einer Äußerung die eigentlich aus gefährlichem Halbwissen resultiert. Wenn du hier mal wirklich fair bist, fasst du dich also mal an die eigene Nase und fragst nach dem Warum.
Die obige Erklärung war niemals böse oder abwertend gemeint und auch der Schlusssatz eher mit einem zwinkernden Auge und dem Appell selber Erfahrungen dazu zu sammeln.
Warum gerade du als jemand der hier ja auch seit langem sehr fundierte und fachlich gute Beiträge und Hilfestellung leistet das jetzt so in den völlig falschen Hals bekommt ist nicht wirklich nachvollziehbar. Zumal der Grund fehlt. Aber nundenn....
Wenn du es möchtest lösche ich gerne den kompletten Beitrag von oben ?!
Du solltest hier auch mal die Kirche im Dorf lassen, denn wenn man jetzt böse argumentiert (was hier keiner macht) dann hast du in einem Administrator Forum eine technisch und auch sachlich völlig falsche Erklärung abgeliefert. Das ist so als wenn einer einem im KFZ Forum erklärt das man Wasser statt Benzin tanken kann.
Den Fragesteller also, obwohl er genau auf dem richtigen Weg war, damit überflüssigerweise in eine vollkommen falsche Richtung gelenkt mit einer Äußerung die eigentlich aus gefährlichem Halbwissen resultiert. Wenn du hier mal wirklich fair bist, fasst du dich also mal an die eigene Nase und fragst nach dem Warum.
Die obige Erklärung war niemals böse oder abwertend gemeint und auch der Schlusssatz eher mit einem zwinkernden Auge und dem Appell selber Erfahrungen dazu zu sammeln.
Warum gerade du als jemand der hier ja auch seit langem sehr fundierte und fachlich gute Beiträge und Hilfestellung leistet das jetzt so in den völlig falschen Hals bekommt ist nicht wirklich nachvollziehbar. Zumal der Grund fehlt. Aber nundenn....
Wenn du es möchtest lösche ich gerne den kompletten Beitrag von oben ?!
..its...
Entspann dich mal. Man kann nicht alles immer sofort ausgiebig testen!
maretz hat schon Recht, deine Art ist besonders...
maretz hat schon Recht, deine Art ist besonders...
Immer tief entspannt...
Was aber nun "besonders" ist schafft keiner konkret zu benennen.
Nichts anderes als eine sachliche Beschreibung des Protokolls...aber egal, ist ja alles zu dem Thema gesagt. Ich bin dann auch raus !
Was aber nun "besonders" ist schafft keiner konkret zu benennen.
Nichts anderes als eine sachliche Beschreibung des Protokolls...aber egal, ist ja alles zu dem Thema gesagt. Ich bin dann auch raus !
