40
Mikrotik - Telekom Magenta TV - IPTV - Tutorial
Inhaltsverzeichnis
Einleitung
Um Mikrotik in Verbindung mit IPTV / Magenta TV verwenden zu können, benötigt Ihr neben ein paar Einstellungen, auch die richtige Firmware ist zu beachten
Ich habe es nun längere Zeit mit allen Firmware - Versionen ausprobiert, derzeit bleibt nur eine Firmware Version mit der die IGMP Proxy Funktion in Verbindung mit IP-TV stabil funktioniert, siehe Topic: Die richtige Firmware.
Denkt auch daran, das Ihr euren Switch (falls eine Switching Funktion vorhanden ist) entsprechend mit IGMP Snooping richtig konfiguriert.
Die richtige Firmware ist wichtig
Nach längeren Test stellt sich die Firmware : 6.48.1 als stabil heraus (Stand: Juni 2021)
Bei der Vorversion (<6.48.0) gibt es häufige Aussetzer, ebenso wie in der 6.48.2.
Diese sind zwar geringer aber vorhanden.
Package List
Das MultiCast Packet findet Ihr passend zu eurem Router auf der Download-Seite von Mikrotik LINK
all_packages-XYZ-6.48.1.zip !!! (XYZ = Hier das Packet für euren Router verwenden z.B. all_packages-arm-6.48.1.zip)
IGMP-Proxy - WinBox
Nach der Installation vom MultiCast Package muss man zum IGMP Proxy (ev. Router - Neustarten)
Settings
Hier folgen die Einstellungen, welche über z.B. die Winbox getätigt werden müssen.
IGMP-Proxy Menü
Öffne den IGMP-Proxy um die nächsten Einstellungen zu erstellen. Klicke in dieser Übersicht auf "+"
Interface der Internet-Verbindung
Erstelle die Einstellung zum MultiCast Netzwerk.
Diese Anleitung umfasst ausschließlich eine Mikrotik geroutete Verbindung.
Hier ist es der Router, der die Einwahl direkt über PPPOE macht,
Alternativ kann der Weg über das Eth gehen, welches euch das Internet für den Mikrotik Router bereitstellt. (Das habe ich aber nicht getestet.)
WICHTIG !!! Auf das Upstream-Häkchen achten !!!
Interface - VLAN für IPTV im Netzwerk
Erstelle die im Anschluss die Einstellungen für das Empfangs-Netzwerk (Hier VLAN 70)
Firewall
Einstellungen in der Firewall
Adresses List
Wechsel zu IP / Firewall und dann weiter zu "Adresses Lists" und erstellt dort die Einträge mit "+".
Filter Rules
Nun brauchen wir noch die Filter-Rules für den Empfang des MultiCast Streams. Erstelle die folgenden Einträge:
Bridge-Settings
Als letztes noch die Bridge - Settings:
Bandbreitenanpassung
Wenn die Bandbreite Probleme macht, dann kann man auch noch über Queues die Prioritäten anpassen.
Dafür habe ich auch schon die Verbindungen markiert.
Schaue die Queues Einstellungen unter den weiterführende Links an.
Weiterführende Links
Mikrotik - Queues
Mikrotik: Begrenzung der Bandbreite über "Queue" und "MAC-Adresse"
VLAN Tutorial Mikrotik
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 667348
Url: https://administrator.de/tutorial/mikrotik-telekom-magenta-tv-iptv-tutorial-667348.html
Ausgedruckt am: 26.12.2024 um 13:12 Uhr
40 Kommentare
Neuester Kommentar
Hi und danke erstmal für deine Anleitung.
Leider geht das bei mir nicht wirklich. Habe alles so eingestellt wie bei dir allerdings die 6.48.2
Kannst du mir sagen wie man Fehler sucht? Nach meinem Verständnis sollte alles so passen.
ich habe erstmal kein eigenes VLAN erstellt für TV. Sollte aber nicht das Problem sein oder doch?
Danke
Leider geht das bei mir nicht wirklich. Habe alles so eingestellt wie bei dir allerdings die 6.48.2
Kannst du mir sagen wie man Fehler sucht? Nach meinem Verständnis sollte alles so passen.
ich habe erstmal kein eigenes VLAN erstellt für TV. Sollte aber nicht das Problem sein oder doch?
Danke
Moin,
ich habe auch mit der 6.48.2 Probleme gehabt.
Du musst es einem VLAN zuordnen im IGMP Proxy.
Und wenn du einen Switch hast, dann bitte den auch auf IPTV konfigurieren.
Wie sieht denn deine Übersicht im IGMP Proxy aus?
Und wie die Optionen darin?
MFG Freak
ich habe auch mit der 6.48.2 Probleme gehabt.
Du musst es einem VLAN zuordnen im IGMP Proxy.
Und wenn du einen Switch hast, dann bitte den auch auf IPTV konfigurieren.
Wie sieht denn deine Übersicht im IGMP Proxy aus?
Und wie die Optionen darin?
MFG Freak
Moin,
ich habe es dem native Vlan zugewiesen. Sieht genauso aus wie bei dir aber wenig traffic .. input Firewall 864 B , Forward 0
Im IGMP Proxy 0 Rx 0 Tx
Hm.. ich dokter schon ne Weile rum ..vielleicht auch was verstellt .. ich schau nochmal i nder config
greets
ich habe es dem native Vlan zugewiesen. Sieht genauso aus wie bei dir aber wenig traffic .. input Firewall 864 B , Forward 0
Im IGMP Proxy 0 Rx 0 Tx
Hm.. ich dokter schon ne Weile rum ..vielleicht auch was verstellt .. ich schau nochmal i nder config
greets
Und wenn du einen Switch hast, dann bitte den auch auf IPTV konfigurieren.
Nennt sich IGMP Snooping. 
Hier sollte man darauf achten das der Switch in dem Downstream Segment (VLAN) des Mikrotik Proxys bei aktivem IGMP Snooping kein Querrier ist, denn das sollte immer der Mikrotik Proxy sein. (Siehe oben beim Haken "Querrier" im Downstraem Interface.
Es schadet zwar nicht wenn beide Querrier sind aber es kommt dann zu einer Race Condition weil der IGMP Standard nur einen Querrier in der L2 Domain vorsieht. Das führt dann dazu das das Gerät mit der niedrigsten Mac Adresse den Querrier Tie Break gewinnt, was dann der Switch statt Mikrotik sein kann. Der Verlierer bleibt dann so lange stumm bis der Gewinner ausfällt oder vom Netz genommen wird.
Hi ,
ich habe es mit Switch
als auch schon direkt mit dem Mikrotik verbunden ..nix..
Entweder es liegt wohl tatsächlich an der version oder aber ggfs habe ich noch den Fritzbox als Client in dem Vlan .. die trällert da auch munter drauf los..
Ich mach mal eigenes Vlan nur für den TV und häng den direkt an den MT.. dann sehe ich vielleicht was
Update -- so eigenes VLAN gemacht . Bekommt IP und TV geht auch für die ca 10-15 sek bis es auf MC umschaltet.
bei der FW bleibt forward auf 0 stehen. Input zählt Packetweise 1 hoch.
update2 -- im log steht igmp-proxy, debug immer was mit ignoring request from unknown adress -" alternative-subnets" configuration may be required :
greets
ich habe es mit Switch
Global IGMP Snooping configuration:
-------------------------------------------
IGMP snooping : Enabled
IGMPv3 snooping (minimal) : Enabled
Report suppression : Enabled
TCN solicit query : Disabled
TCN flood query count : 2
Robustness variable : 2
Last member query count : 2
Last member query interval : 1000
Vlan 1:
--------
IGMP snooping : Enabled
CAPWAP enabled : Disabled
IGMPv2 immediate leave : Disabled
Multicast router learning mode : pim-dvmrp
CGMP interoperability mode : IGMP_ONLY
Robustness variable : 2
Last member query count : 2
Last member query interval : 1000als auch schon direkt mit dem Mikrotik verbunden ..nix..
Entweder es liegt wohl tatsächlich an der version oder aber ggfs habe ich noch den Fritzbox als Client in dem Vlan .. die trällert da auch munter drauf los..
Ich mach mal eigenes Vlan nur für den TV und häng den direkt an den MT.. dann sehe ich vielleicht was
Update -- so eigenes VLAN gemacht . Bekommt IP und TV geht auch für die ca 10-15 sek bis es auf MC umschaltet.
bei der FW bleibt forward auf 0 stehen. Input zählt Packetweise 1 hoch.
update2 -- im log steht igmp-proxy, debug immer was mit ignoring request from unknown adress -" alternative-subnets" configuration may be required :
greets
Versuch mal ein downgrade auf die 6.48.1
Ist auch das richtige In Interface ausgewählt? Also pppoe, es darf nicht die eth sein wenn du eine direkte Verbindung über Modem machst.
Wie ist denn dein Hardware Setup?
Gruß Freak
Ist auch das richtige In Interface ausgewählt? Also pppoe, es darf nicht die eth sein wenn du eine direkte Verbindung über Modem machst.
Wie ist denn dein Hardware Setup?
Gruß Freak
Hi,
ja werd ich mal machen müssen dann.
Ja das ppoE ist ausgewält.. er zählt ja auch hoch beim IGMP Proxy ..
pppoe-out mit upstream und AS 87.141.215.251 Empängt RX
vlan x transmitted denselben Wert dazu.
Im Moment ist das Setup ganz simple - der MT hinter einem Vigor Modem und an dem MT hängt direkt dann der Media Receiver mit eigenem VLAN- Bild kommt ja auch von daher scheint mir das zu stimmen.
greets
Cyb
ja werd ich mal machen müssen dann.
Ja das ppoE ist ausgewält.. er zählt ja auch hoch beim IGMP Proxy ..
pppoe-out mit upstream und AS 87.141.215.251 Empängt RX
vlan x transmitted denselben Wert dazu.
Im Moment ist das Setup ganz simple - der MT hinter einem Vigor Modem und an dem MT hängt direkt dann der Media Receiver mit eigenem VLAN- Bild kommt ja auch von daher scheint mir das zu stimmen.
greets
Cyb
Hallo,
wie sieht das mit RouterOS 7.2.2 aus. Weiß jemand ob sich da was geändert hat oder ob alles beim alten ist wie oben beschrieben?
Danke für kurze Rückmeldung
LG
wie sieht das mit RouterOS 7.2.2 aus. Weiß jemand ob sich da was geändert hat oder ob alles beim alten ist wie oben beschrieben?
Danke für kurze Rückmeldung
LG
wie sieht das mit RouterOS 7.2.2 aus.
Nicht so besonders rosig: Mikrotik RouterOS 7.2.2 - Bug mit Package "wifiwave2"Hat aber erstmal nichts mit Multicast zu tun und das müsste man explizit mal testen.
UPNP mit Mikrotik Routerboard hEX PoE und D-Link DGS-1210-24 Switch
Fehlersuche im lokalem Netzwerk (RSTP, MRP, Multicast)
Hallo,
habe nach obiger Anleitung die Einstellungen bei mir gemacht - leider mit dem Phänomen, dass das Bild beim IPTV nach wenigen Sekunden stockt, dann einfriert und der MediaReceiver MR401 sich über die unzureichende Qualität der Netzwerkverbindung beschwert.
Mein Setup bisher
Neu
Unterschiede zur o.g. Anleitung
Auffällig ist, dass ich im Downstream des ETH4 den Haken bei Querier nicht setzen kann (ausgeraut)
evtl. ist das das Problem
PS: ist mein erster Post in diesem Form. Man möge mir evtl. Anfängerfehler beim Posten verzeihen.
Danke
habe nach obiger Anleitung die Einstellungen bei mir gemacht - leider mit dem Phänomen, dass das Bild beim IPTV nach wenigen Sekunden stockt, dann einfriert und der MediaReceiver MR401 sich über die unzureichende Qualität der Netzwerkverbindung beschwert.
Mein Setup bisher
- DSL -> Fritzbox -> Ethernetkabel -> MR401 => alles ok
Neu
- DSL -> Draytek Vigor 167 -> MT-Router (ax2) -> Ethernetkabel -> MR401 => Bild friert ein
Unterschiede zur o.g. Anleitung
- Router OS 7.11.2
- FW aus der Grundkonfiguration des Routers + o.g. FW-Einstellungen eingereht in die jeweiligen Chains
- Kein VLAN
- Downstream direkt auf ETH4 des Routers
Auffällig ist, dass ich im Downstream des ETH4 den Haken bei Querier nicht setzen kann (ausgeraut)
evtl. ist das das Problem
PS: ist mein erster Post in diesem Form. Man möge mir evtl. Anfängerfehler beim Posten verzeihen.
Danke
Arbeitest du mit PIM Routing oder mit IGMP Proxy Konfig auf dem MT?
WinBox Screenshot wäre hilfreich.
Hier kommt es nicht einmal zu einem Bild, weder Proxy noch PIM Routing. (CRS305, mit 7.11er)
Möglich das das im Default aktiviert ist. MRouter sind eigentlich immer aktiv auch Querrier.
Hast du das mal mit einem Wireshark probiert ob du Queries vom MT sehen kannst??
Ansonsten wenn du einen IGMP Snooping fähigen Switch dran hast den mal auf aktiven Querrier setzen. Es kann mehrere geben aktiv ist dann immer der mit der niedrigsten IP Source Adresse der der gewinnt.
WinBox Screenshot wäre hilfreich.
Hier kommt es nicht einmal zu einem Bild, weder Proxy noch PIM Routing. (CRS305, mit 7.11er)
Auffällig ist, dass ich im Downstream des ETH4 den Haken bei Querier nicht setzen kann
Ist hier auch so. Möglich das das im Default aktiviert ist. MRouter sind eigentlich immer aktiv auch Querrier.Hast du das mal mit einem Wireshark probiert ob du Queries vom MT sehen kannst??
Ansonsten wenn du einen IGMP Snooping fähigen Switch dran hast den mal auf aktiven Querrier setzen. Es kann mehrere geben aktiv ist dann immer der mit der niedrigsten IP Source Adresse der der gewinnt.
Ich arbeite mit IGMP Proxy.
Mit Wireshark muss ich das noch testen.
Einen IGMP-fähigen Switch kann ich dazwischen schalten.
Mein erster Ansatz war, erst mal so wenig als möglich Zusatz-HW in der Strecke Router <-> Receiver zu haben, um Fehlerquellen auszuschließen.
Danke für deine Hinweise
Mit Wireshark muss ich das noch testen.
Einen IGMP-fähigen Switch kann ich dazwischen schalten.
Mein erster Ansatz war, erst mal so wenig als möglich Zusatz-HW in der Strecke Router <-> Receiver zu haben, um Fehlerquellen auszuschließen.
Danke für deine Hinweise
erst mal so wenig als möglich Zusatz-HW in der Strecke Router <-> Receiver zu haben, um Fehlerquellen auszuschließen.
Absolut richtig! 👍Gut, viele Optionen gibt es beim Proxy Setup ja nicht. Upstream, Downstream und das wars schon fast. Machst du das über 2 geroutete Interface oder über ein Bridge Interface bzw. Local LAN auf einer Bridge?
Vorab erstmal sorry für evtl. Missdeutungen von Begrifflichkeiten - bin erst neu in die MT-Welt eingestiegen...
Upstream hängt bei mir an ETH1, welcher als PPPoe-Client definiert ist und nicht Teil der Bridge ist
Downstream ist ETH4, welcher Teil der Bridge ist.
die Übersicht der Interfaces (ISP = ETH1)
IGMP-Proxy
Bridge & Interfaces
IGMP-Snooping der Bridge
Viele Bilder, welche evtl. weiterhelfen
Upstream hängt bei mir an ETH1, welcher als PPPoe-Client definiert ist und nicht Teil der Bridge ist
Downstream ist ETH4, welcher Teil der Bridge ist.
die Übersicht der Interfaces (ISP = ETH1)
IGMP-Proxy
Bridge & Interfaces
IGMP-Snooping der Bridge
Viele Bilder, welche evtl. weiterhelfen
Danke für die hilfreichen Screenshots! 👍
2 Dinge die in deinem Setup etwas merkwürdig sind ist einmal die Angabe einer Hostadresse bei "Alternative Subnets"?! 🤔
Damit sind laut MT Doku immer lokale Downstream Netze gemeint die nicht direkt am MT angeschlossen sind so das er auch Multicast Frames mit diesen Absender IPs über den Proxy schickt. Eine öffentliche IP kann hier eigentlich sich aus 2 Gründen nicht richtig sein:
Der zweite Punkt ist die Angabe eines Bridge Memberports im Downstream Teil. (ether 4)
Auch das kann laut Doku eigentlich nicht richtig sein, denn wie du selber schreibst benutzt du eine Bridge die ja einige Memberport zusammenfasst.
Das relevante Router IP Interface liegt dann bei MT üblicherweise auf der Bridge bzw. dem Bridge Interface selber (oder bei VLANs auf einem VLAN IP Interface) aber niemals auf einem einzelnen Memberport dieser Bridge, der ja selber gar keine IP hat. Nur die Bridge bzw. das Bridge Interface hält die Router IP. Das solltest du auch so in deiner IP Adress Übersicht (IP --> Address) sehen.
Multicast ist aber eine IP Funktion (Layer 3) und kann immer nur auf dem Interface funktionieren was eine IP hält.
Ggf. änderst du das mal auf die korrekten Einstellungen und checkst das Verhalten nochmal
Achte dabei auch darauf auf dem Bridge Interface IGMP Ver.3 anzuhaken, da IP-TV SSM Multicast v3 erzwingt!
2 Dinge die in deinem Setup etwas merkwürdig sind ist einmal die Angabe einer Hostadresse bei "Alternative Subnets"?! 🤔
Damit sind laut MT Doku immer lokale Downstream Netze gemeint die nicht direkt am MT angeschlossen sind so das er auch Multicast Frames mit diesen Absender IPs über den Proxy schickt. Eine öffentliche IP kann hier eigentlich sich aus 2 Gründen nicht richtig sein:
- Es ist keine Netzwerk Adresse (alle Hostbits 0) sondern eine Hostadresse
- Es ist keine lokale Netzwerk IP Adresse da öffentlich und keine RFC1918 IP
Der zweite Punkt ist die Angabe eines Bridge Memberports im Downstream Teil. (ether 4)
Auch das kann laut Doku eigentlich nicht richtig sein, denn wie du selber schreibst benutzt du eine Bridge die ja einige Memberport zusammenfasst.
Das relevante Router IP Interface liegt dann bei MT üblicherweise auf der Bridge bzw. dem Bridge Interface selber (oder bei VLANs auf einem VLAN IP Interface) aber niemals auf einem einzelnen Memberport dieser Bridge, der ja selber gar keine IP hat. Nur die Bridge bzw. das Bridge Interface hält die Router IP. Das solltest du auch so in deiner IP Adress Übersicht (IP --> Address) sehen.
Multicast ist aber eine IP Funktion (Layer 3) und kann immer nur auf dem Interface funktionieren was eine IP hält.
Ggf. änderst du das mal auf die korrekten Einstellungen und checkst das Verhalten nochmal
Achte dabei auch darauf auf dem Bridge Interface IGMP Ver.3 anzuhaken, da IP-TV SSM Multicast v3 erzwingt!
Danke für deine weiteren Hinweise.
Da das ganze bei mir später mit Vlans laufen soll, werde ich mich erst mit der grundlegenden MT-Konfiguration für Vlans befassen und anschließend IGMP aufsetzen.
Deine Vlan-Anleitung dafür wird mir sicherlich helfen.
Zumindest weiß ich schon mal, dass meine beiden Switches IGMP-Snooping können und im „bisherigen“ Netz mit Fritzbox funktionieren.
Meine Erkenntnisse werde ich dann hier einbringen.
Da das ganze bei mir später mit Vlans laufen soll, werde ich mich erst mit der grundlegenden MT-Konfiguration für Vlans befassen und anschließend IGMP aufsetzen.
Deine Vlan-Anleitung dafür wird mir sicherlich helfen.
Zumindest weiß ich schon mal, dass meine beiden Switches IGMP-Snooping können und im „bisherigen“ Netz mit Fritzbox funktionieren.
Meine Erkenntnisse werde ich dann hier einbringen.
werde ich mich erst mit der grundlegenden MT-Konfiguration für Vlans befassen und anschließend IGMP aufsetzen.
Sehr vernünftig und der richtige Weg! 👍Deine Vlan-Anleitung dafür wird mir sicherlich helfen.
Hopefully?! 😉Meine Erkenntnisse werde ich dann hier einbringen.
Das wäre sehr nett und hilfreich! 👍
Nach verschiedenen, leider nicht erfolgreichen Konfigurationen melde ich mich weiterhin Hilfe suchend zurück.
Nochmals meine aktuelle Hardware-Konfiguration
DSL -> Fritzbox -> MT Router (hAP ax2 / OS:7.11.2) -> MR401 (Receiver)
Direkte Kabelverbindung
Am Router:
ETH1: Internet-Verbindung über FB und DHCP
ETH4: Verbindung zum MR401
Firewall deaktiviert
vlan-Bridge mit ETH3 (PVID1), ETH4 (PVID10), ETH5 (Trunk)
Konfiguration (s.u.)
1.) IGMP-Proxy
2.) PIM
Bei beiden Konfigurationen das identische Verhalten
In der anschließenden Diagnose-Meldung am MR401 bekam ich 2 unterschiedliche Meldungen
1.) alles ok, nur die Netzqualität sei "Mittel"
2.) es gäbe ein nicht IGMPv3 Gerät im Netzwerk
leider weiss ich nicht mehr, wann was kam.
Wie schon erwähnt läuft der MR401 direkt angeschlossen an der Fritzbox ohne Probleme
Nachfolgend meine Konfigurationen
1.) VLAN (identisch bei IGMP und PIM)
2.) IGMP
Ob das "alternative subnets" stimmt, weiß ich leider nicht. @aqui hatte dieses ja bereits schon erwähnt.
3.) PIM
bei dieser Konfig wurde IGMP Proxy deaktiviert. Man kann / soll hier ggf einen RP angeben, er möchte hier jedoch irgendwelche Eingabe, mit denen ich leider nichts anfangen kann.
wie gesagt: bei allen war die Firewall deaktiviert
Wenn ich so in diversen Foren lese, tritt dieses Phänomen öfters auf - die angegeben Lösungen waren jedoch leider nicht erfolgreich.
Wenn ich den Meldungen seitens der Telekom richtig verstehe, ist IPTV und Multicast in Sterben und würde durch das neue System (kein Multicast) abgelöst -> Magenta-Stick...
Ich bin mir nicht sicher, ob ich weiterhin Zeit, Energie und FRUST investieren soll, oder einfach gleich auf das neue System umsteigen soll, auch wenn es ein paar € im Monat mehr kosten.
Vielleicht hat doch noch jemand einen Tipp für mich.
PS: falls noch Infos zu meiner Konfiguration fehlen sollte, diese reiche ich gerne nach.
Danke vorab
Nochmals meine aktuelle Hardware-Konfiguration
DSL -> Fritzbox -> MT Router (hAP ax2 / OS:7.11.2) -> MR401 (Receiver)
Direkte Kabelverbindung
Am Router:
ETH1: Internet-Verbindung über FB und DHCP
ETH4: Verbindung zum MR401
Firewall deaktiviert
vlan-Bridge mit ETH3 (PVID1), ETH4 (PVID10), ETH5 (Trunk)
Konfiguration (s.u.)
1.) IGMP-Proxy
2.) PIM
Bei beiden Konfigurationen das identische Verhalten
- MR401 startet sauber auf und bezieht die IP aus dem VLAN10-Adressbereich
- entgegen dem bisherigen direkten Betrieb des MR401 an der Fritzbox kommt ein Bild + Ton erst nach einem ersten Umschalten mit der Fernbedienung auf einen anderen Kanal
- TV Sender läuft ca. 5-10 Sekunden, stockt dann und friert ein
- Wechselt man auf einen anderen Kanal, so wiederholt sich das Spiel (5-10 Sekunden, dann Stop)
In der anschließenden Diagnose-Meldung am MR401 bekam ich 2 unterschiedliche Meldungen
1.) alles ok, nur die Netzqualität sei "Mittel"
2.) es gäbe ein nicht IGMPv3 Gerät im Netzwerk
leider weiss ich nicht mehr, wann was kam.
Wie schon erwähnt läuft der MR401 direkt angeschlossen an der Fritzbox ohne Probleme
Nachfolgend meine Konfigurationen
1.) VLAN (identisch bei IGMP und PIM)
2.) IGMP
3.) PIM
wie gesagt: bei allen war die Firewall deaktiviert
Wenn ich so in diversen Foren lese, tritt dieses Phänomen öfters auf - die angegeben Lösungen waren jedoch leider nicht erfolgreich.
Wenn ich den Meldungen seitens der Telekom richtig verstehe, ist IPTV und Multicast in Sterben und würde durch das neue System (kein Multicast) abgelöst -> Magenta-Stick...
Ich bin mir nicht sicher, ob ich weiterhin Zeit, Energie und FRUST investieren soll, oder einfach gleich auf das neue System umsteigen soll, auch wenn es ein paar € im Monat mehr kosten.
Vielleicht hat doch noch jemand einen Tipp für mich.
PS: falls noch Infos zu meiner Konfiguration fehlen sollte, diese reiche ich gerne nach.
Danke vorab
Verhalten hier bei gleichem Setup allerdings einem VLC Client statt MR401 zeigt identisches Verhalten.
Eine VLC Client hat den Vorteil das man die IGMP Kommunikation genau ansehen kann. Bei PIM scheitert ein IGMP Join. Sehr wahrscheinlich weil das PIM Routing auf dem MT aktuell kein PIM im SSM Mode supportet was für Magenta TV zwingend erforderlich ist.
SSM erzingt auch immer IGMPv3. In einem PIM Netzwerk ohne SSM funktioniert SSM Multicast nicht.
Leider war nirgendwo in der Mikrotik Doku zu erfahren ob SSM supportet ist oder nicht. Da die erforderlichen SSM Setup Kommandos fehlen kann man davon ausgehen das es nicht supportet ist und damit scheidet dann die PIM Option mit Routing von vorn herein aus.
Bleibt also einzig nur die Proxy Variante. Diese scheint aber nicht mit IGMPv3 zurechtzukommen und forwardet den Join request vermutlich nicht. Der geht zwar laut Wireshark vom Client raus es passiert aber nichts. Um das aber genau sagen zu können musst man mal im Koppelsegment MT zu FB messen und checken ob die dort ankommen.
Das es 5-10 Minuten geht und dann stockt ist die typische Umschaltzeit in der von Boradcast auf Multicast umgeschaltet wird. Die MC Frames kommen aber nicht an.
Ersetzt man den Mikrotik im o.a. Setup z.B. mit einem preiswerten 25€ Cisco 880er (eBay etc.) funktioniert das Setup sofort und absolut fehlerfrei!
Es liegt also de facto am Featureset des Mikrotik.
Eine VLC Client hat den Vorteil das man die IGMP Kommunikation genau ansehen kann. Bei PIM scheitert ein IGMP Join. Sehr wahrscheinlich weil das PIM Routing auf dem MT aktuell kein PIM im SSM Mode supportet was für Magenta TV zwingend erforderlich ist.
SSM erzingt auch immer IGMPv3. In einem PIM Netzwerk ohne SSM funktioniert SSM Multicast nicht.
Leider war nirgendwo in der Mikrotik Doku zu erfahren ob SSM supportet ist oder nicht. Da die erforderlichen SSM Setup Kommandos fehlen kann man davon ausgehen das es nicht supportet ist und damit scheidet dann die PIM Option mit Routing von vorn herein aus.
Bleibt also einzig nur die Proxy Variante. Diese scheint aber nicht mit IGMPv3 zurechtzukommen und forwardet den Join request vermutlich nicht. Der geht zwar laut Wireshark vom Client raus es passiert aber nichts. Um das aber genau sagen zu können musst man mal im Koppelsegment MT zu FB messen und checken ob die dort ankommen.
Das es 5-10 Minuten geht und dann stockt ist die typische Umschaltzeit in der von Boradcast auf Multicast umgeschaltet wird. Die MC Frames kommen aber nicht an.
Ersetzt man den Mikrotik im o.a. Setup z.B. mit einem preiswerten 25€ Cisco 880er (eBay etc.) funktioniert das Setup sofort und absolut fehlerfrei!
Es liegt also de facto am Featureset des Mikrotik.
ist IPTV und Multicast in Sterben und würde durch das neue System
Das ist zu bezweifeln, denn dann müssten Millionen Kunden mit hohem Kostenaufwand umgestellt werden. Ohne Multicast ist eine effizente und skalierbare Übertragung nicht möglich und würde massiv Resourcen fressen. Das diese Plattform kurzfristig umgestellt wird ist nicht zu erwarten. Woher hast du diese "Meldungen"? 🤔
Das ist bedauerlich, dass MT hier nicht richtig funktioniert. Kann dieses (Fehl-)Verhalten nicht bei MT adressiert werden?
Bzgl. der Umstellung bei der Telekom: Ich meinte nicht, dass sie das bisherige System einstampfen würden. Aus den Telekom-Foren entnahm ich, dass die MR401 nicht mehr weiter vertrieben werden, statt dessen nur noch die MagentaTV One bzw. der Magenta Surf Stick. Sowie ich das verstanden habe, arbeiten die neuen Geräte anders.
Ich habe spaßeshalber einen MagentaTV Stick über den MT laufen lassen. Da ich nicht den neuen Tarif habe, konnte ich kein Live-TV schauen. Jedoch die Mediatheken liefen über den MT per WLAN ohne Probleme
Man findet auf der Telekom unter TV Receiver keine MRxxx mehr.
-> Telekom
Multicast über die MR sollen aber weiter möglich sein d.h. es erfolgt keine "Zwangsumstellung", Neukunden.
Bzgl. der Umstellung bei der Telekom: Ich meinte nicht, dass sie das bisherige System einstampfen würden. Aus den Telekom-Foren entnahm ich, dass die MR401 nicht mehr weiter vertrieben werden, statt dessen nur noch die MagentaTV One bzw. der Magenta Surf Stick. Sowie ich das verstanden habe, arbeiten die neuen Geräte anders.
Ich habe spaßeshalber einen MagentaTV Stick über den MT laufen lassen. Da ich nicht den neuen Tarif habe, konnte ich kein Live-TV schauen. Jedoch die Mediatheken liefen über den MT per WLAN ohne Probleme
Man findet auf der Telekom unter TV Receiver keine MRxxx mehr.
-> Telekom
Multicast über die MR sollen aber weiter möglich sein d.h. es erfolgt keine "Zwangsumstellung", Neukunden.
Da ich nicht den neuen Tarif habe, konnte ich kein Live-TV schauen.
Doch das kann man auch ohne Tarif wenn man nur die Öffentlich Rechtlichen sieht! Habs grad mal mit dem TV Stick probiert... Müsste man mal sniffern was die nutzen. Aber gut möglich das die das Tunneln und im Tunnel weiterhin Multicast machen da diese Geräte ja auch den Zugang aus anderen Providernetzen supporten. Mal den Wireshark bemühen...
ich frage mich nur:
in der Beschreibung ganz zu Beginn dieser Seite wird eine erfolgreiche Konfiguration beschrieben, allerdings mit OS V6.x.
Kamen die aktuellen Probleme erst mit der Version OS V7 rein?
in der Beschreibung ganz zu Beginn dieser Seite wird eine erfolgreiche Konfiguration beschrieben, allerdings mit OS V6.x.
Kamen die aktuellen Probleme erst mit der Version OS V7 rein?
Wäre möglich. Das kann man wohl nur testen wenn man downgraded.
geht bei mir laut Beschreibung nur auf die V7.5 - blöd
Es wäre hilfreich, wenn jemand aus der Community eine funktionierende Konfiguration RouterOS V7 und Multicast für MagentaTV zur Verfügung stellen würde.
Ich hoffe, dass es "nur" ein Konfigurations- und kein "fehlendes" OS-Feature ist.
Ich hoffe, dass es "nur" ein Konfigurations- und kein "fehlendes" OS-Feature ist.
Denke ich eher nicht. Ist ja konfigtechnisch schon alles durchgetestet worden und die MC Konfig ist ja auch nun kein Hexenwerk. Bei Cisco sind das 2 einfache Kommandos.
Das ist entweder ein FW Bug oder was wahrscheinlicher ist: RouterOS 7 supportet kein SSM.
Du kannst ja selber mal einen Test machen mit klassischem PIM Routing wie es HIER beschrieben ist.
Das Setup ist mit VLC in 3 Minuten erledigt und man kann den MC dann in einem PIM Routing Design oder mit IGMP Proxy testen. Beides funktioniert fehlerlos was den Verdacht nährt SSM ist nicht supportet!
Sicher wir man wohl nur sein wenn man die Mikrotik Support Hotline einmal kontaktiert und nachfragt.
Das ist entweder ein FW Bug oder was wahrscheinlicher ist: RouterOS 7 supportet kein SSM.
Du kannst ja selber mal einen Test machen mit klassischem PIM Routing wie es HIER beschrieben ist.
Das Setup ist mit VLC in 3 Minuten erledigt und man kann den MC dann in einem PIM Routing Design oder mit IGMP Proxy testen. Beides funktioniert fehlerlos was den Verdacht nährt SSM ist nicht supportet!
Sicher wir man wohl nur sein wenn man die Mikrotik Support Hotline einmal kontaktiert und nachfragt.
In RouterOS 7 fehlt der Support zu SSM offensichtlich
https://help.mikrotik.com/docs/display/ROS/PIM-SM
In RouterOS 6 dagegen war es im separaten Multicast-Package mal supported
https://wiki.mikrotik.com/wiki/Manual:Multicast_detailed_example
D.h. abwarten und Tee trinken oder Router tauschen wenn kein Downgrade möglich ist.
Gruß Sid.
https://help.mikrotik.com/docs/display/ROS/PIM-SM
ssm-range (IPv4 | IPv6; Default: ) Currently not implemented
In RouterOS 6 dagegen war es im separaten Multicast-Package mal supported
https://wiki.mikrotik.com/wiki/Manual:Multicast_detailed_example
Q. Does MT support Source Specific Multicast (SSM)?
A. Yes, SSM is a part of PIM-SM specification and we support it.
A. Yes, SSM is a part of PIM-SM specification and we support it.
D.h. abwarten und Tee trinken oder Router tauschen wenn kein Downgrade möglich ist.
Gruß Sid.
...was dann auch den Funktionsunterschied von Ver. 6 zu Ver. 7 erklärt!
Danke für das Feedback! 👍
Danke für das Feedback! 👍
oder Router tauschen...
Cisco 880 gibts für 25€ bei eBay zur Überbrückung der Wartezeit! 😉
Hab es mal ins Forum von MT gepostet. Mal sehen, ob von da was kommt.
Kannst du den Link mal posten damit man das mitverfolgen kannt? 😉
Bin hier noch auf einen Hinweis gestoßen, der zwar bei mir nicht geholfen hat (evtl. sind dazu noch weitere Einstellungen notwendig), jedoch ggf. noch einen Hinweis geben könnte.
Es gäbe anscheinend eine Unverträglichkeit zw. MagentaTV und IPv6.
In der "akzeptierten" Lösung würde MagentaTV durch Deaktivieren von IPv6 laufen.
Es gäbe anscheinend eine Unverträglichkeit zw. MagentaTV und IPv6.
In der "akzeptierten" Lösung würde MagentaTV durch Deaktivieren von IPv6 laufen.
Telekom Multicast rennt m.W. gar nicht auf IPv6 und ist v4 only. Funktioniert auch hier in einem Dual Stack Netz auf einem Cisco vollkommen fehlerfrei. Der o.a. MT Test war auch in einem v4 only Netz so das man das als Ursache ausschliessen kann.
Das kann es also sehr wahrscheinlich nicht sein und es spricht mehr fürs fehlende SSM.
Das kann es also sehr wahrscheinlich nicht sein und es spricht mehr fürs fehlende SSM.
Support Antwort von Mikrotik zur SSM Frage:
"RouterOS supports SSM Multicast, configuration requires the use of PIM with IGMPv3. At its current state it is not possible to use custom SSM-range.
At it`s core, IGMPv3 uses joins the dedicated source and diverts it correctly to the client.
We do not have ready example to share, please, follow the resources below, if configuration assistance is required, particulary consultants, provide full configuration support, provided additional fee."
"RouterOS supports SSM Multicast, configuration requires the use of PIM with IGMPv3. At its current state it is not possible to use custom SSM-range.
At it`s core, IGMPv3 uses joins the dedicated source and diverts it correctly to the client.
We do not have ready example to share, please, follow the resources below, if configuration assistance is required, particulary consultants, provide full configuration support, provided additional fee."
Nach all meinen o.g. (erfolglosen) Versuchen (Magenta-TV <-> MikroTik) habe ich die MT-Schiene verlassen und den MT-Router durch einen DrayTek Vigor 2135 (günstig über Kleinanzeigen) ersetzt.
Dieser bietet mir zum einen ausreichend Möglichkeiten, mein Netzwerk nach meinen Wünschen aufzusetzen UND v.a.... IGMP/Multicast (Magenta-TV über MR401) läuft problemlos ohne Ruckler, Aussetzer, stockende Bilder...
Einen Nutzen hatte das Ganze: ich habe einiges über Netzwerk-Konfiguration gelernt.
Dieser bietet mir zum einen ausreichend Möglichkeiten, mein Netzwerk nach meinen Wünschen aufzusetzen UND v.a.... IGMP/Multicast (Magenta-TV über MR401) läuft problemlos ohne Ruckler, Aussetzer, stockende Bilder...
Einen Nutzen hatte das Ganze: ich habe einiges über Netzwerk-Konfiguration gelernt.
Nur interessehalber:
Kann der Draytek richtiges PIM Routing, also Multicast Routing wie der Cisco (und auch MT) oder arbeitet er auch nur als IGMP Proxy?
Kann der Draytek richtiges PIM Routing, also Multicast Routing wie der Cisco (und auch MT) oder arbeitet er auch nur als IGMP Proxy?
Der Draytek arbeitet "nur" als IGMP Proxy
Zu Beginn hatte ich auch das Phänomen der "stockenden / eingefrorenen" Bilder.
In meinem Fall (PPPoe) war der Haken "PPP Header hinzufügen" die Lösung.
Da ich den MT-Router nicht mehr beitze weiß ich nicht, ob evtl. diese eine Einstellung dort auch möglich gewesen wäre und es dann auch dort funktioniert hätte.
Vielleicht hilft dieser Hinweis anderen MT-Usern.
Zu Beginn hatte ich auch das Phänomen der "stockenden / eingefrorenen" Bilder.
In meinem Fall (PPPoe) war der Haken "PPP Header hinzufügen" die Lösung.
Da ich den MT-Router nicht mehr beitze weiß ich nicht, ob evtl. diese eine Einstellung dort auch möglich gewesen wäre und es dann auch dort funktioniert hätte.
Vielleicht hilft dieser Hinweis anderen MT-Usern.
Ja, das ist eine interessante Information!
Die Frage ist allerdings WAS genau mit "Encapsulate IGMP in PPPoE" gemeint ist bzw. was es technisch bewirkt?
Bei einem PPPoE Router würde man ja als Admin immer davon ausgehen das sämtliche IP Kommunikation, was natürlich auch Multicasts inkludiert, auch via PPPoE rausgeht. Zumindestens ist das ja auch beim Cisco Router so dem man erwartungsgemäß nicht extra sagen muss das IGMP über PPPoE rausgehen soll an einem PPPoE Interface.
Möglich auch das damit ein MTU Setting gemeint ist wegen des PPPoE Header Overheads was aber normalerweise ja global am Interface gesetzt wird. Ist schon etwas wirr....
Die Frage ist allerdings WAS genau mit "Encapsulate IGMP in PPPoE" gemeint ist bzw. was es technisch bewirkt?
Bei einem PPPoE Router würde man ja als Admin immer davon ausgehen das sämtliche IP Kommunikation, was natürlich auch Multicasts inkludiert, auch via PPPoE rausgeht. Zumindestens ist das ja auch beim Cisco Router so dem man erwartungsgemäß nicht extra sagen muss das IGMP über PPPoE rausgehen soll an einem PPPoE Interface.
Möglich auch das damit ein MTU Setting gemeint ist wegen des PPPoE Header Overheads was aber normalerweise ja global am Interface gesetzt wird. Ist schon etwas wirr....
Habe dazu was gefunden.
Encapsulate PPP
Encapsulate PPP
OK, das beschreibt mehr oder minder die klassischen Basics beim PPP Setup und seine Authentication usw.
Bleibt aber die Frage: WAS hat das ganze mit IGMP bzw. Multicasting zu tun??
PPP bzw. PPPoE ist ja ein Klassiker der millionenfach an xDSL und teils auch Glasfaseranschlüssen rennt und IP darüber transportiert. Wobei es bei IP egal ist welche Adresse, ob UDP oder TCP usw.
Warum differenziert also Draytek da IGMP?? 🤔 Kein anderer Hersteller macht das und die Fragen stellen sich auch andere zu recht.
Bei Draytek steht lapidar:
Enable this function if the interface type for IGMP is PPPoE. It depends on the specifications regulated by each ISP. If you have no idea to enable or disable, simply contact your ISP providers.
Das hört sich so an als ob man dem Proxy damit sagt das er bitte auch das PPPoE Interface (WAN Port) für IGMP benutzen soll. Ohne den Haken nutzt er es vermtlich nur für lokale Netze. Ist aber jetzt auch nur geraten.
Ich hatte die Mikrotik Proxy Funktion aber in einem lokalen LAN getestet also mit normalem Ethernet Routing so das PPP gar nicht das Thema ist. Mit einer pfSense als Proxy rennt das z.B. auch per PIM Routing mit einem weiteren Cisco.
Beim Mikrotik rennt weder der Proxy noch die PIM Routing Alternative. Ich denke immer noch das Mikrotik einen Bug im SSM Multicasting hat. Aber mal sehen...die 7.13 ist ja jetzt raus und da kann man ja mal wieder einen Versuch starten um zu verifizieren was der Mikrotik Support offiziell sagt. Zitat:
"RouterOS supports SSM Multicast, configuration requires the use of PIM with IGMPv3. At its current state it is not possible to use custom SSM-range.
At it`s core, IGMPv3 uses joins the dedicated source and diverts it correctly to the client.
We do not have ready example to share, please, follow the resources below, if configuration assistance is required, particulary consultants, provide full configuration support, provided additional fee.
Versuch macht klug... 😉
Bleibt aber die Frage: WAS hat das ganze mit IGMP bzw. Multicasting zu tun??
PPP bzw. PPPoE ist ja ein Klassiker der millionenfach an xDSL und teils auch Glasfaseranschlüssen rennt und IP darüber transportiert. Wobei es bei IP egal ist welche Adresse, ob UDP oder TCP usw.
Warum differenziert also Draytek da IGMP?? 🤔 Kein anderer Hersteller macht das und die Fragen stellen sich auch andere zu recht.
Bei Draytek steht lapidar:
Enable this function if the interface type for IGMP is PPPoE. It depends on the specifications regulated by each ISP. If you have no idea to enable or disable, simply contact your ISP providers.
Das hört sich so an als ob man dem Proxy damit sagt das er bitte auch das PPPoE Interface (WAN Port) für IGMP benutzen soll. Ohne den Haken nutzt er es vermtlich nur für lokale Netze. Ist aber jetzt auch nur geraten.
Ich hatte die Mikrotik Proxy Funktion aber in einem lokalen LAN getestet also mit normalem Ethernet Routing so das PPP gar nicht das Thema ist. Mit einer pfSense als Proxy rennt das z.B. auch per PIM Routing mit einem weiteren Cisco.
Beim Mikrotik rennt weder der Proxy noch die PIM Routing Alternative. Ich denke immer noch das Mikrotik einen Bug im SSM Multicasting hat. Aber mal sehen...die 7.13 ist ja jetzt raus und da kann man ja mal wieder einen Versuch starten um zu verifizieren was der Mikrotik Support offiziell sagt. Zitat:
"RouterOS supports SSM Multicast, configuration requires the use of PIM with IGMPv3. At its current state it is not possible to use custom SSM-range.
At it`s core, IGMPv3 uses joins the dedicated source and diverts it correctly to the client.
We do not have ready example to share, please, follow the resources below, if configuration assistance is required, particulary consultants, provide full configuration support, provided additional fee.
Versuch macht klug... 😉
