• Hallo zusammen,

    wegen MagentaTV bin ich vor einiger Zeit von pfSense zu einem Ubiquiti ER-X gewechselt. Nachdem das igmpproxy-Paket in pfSense aktualisiert wurde, habe ich einen neuen Versuch unternommen, MagentaTV mit pfSense ans Laufen zu bekommen. Und wie auch andere schon geschrieben haben: es geht!

    Da ich ein paar Beiträge gesehen habe, wo Probleme mit der Konfiguration aufgetreten sind, möchte ich meine Konfiguration hier exemplarisch erläutern und auch ein paar Hinweise zur Fehlersuche geben. Die Profis verzeihen mir bitte die ein oder andere Unschärfe und Vereinfachung. :-)

    MagentaTV - Multicast und Unicast

    Zunächst einmal ist es für die Fehlersuche hilfreich zu verstehen, wie die Media Receiver für MagentaTV funktionieren und was es mit Unicast und Multicast in diesem Zusammenhang auf sich hat. Auf die Feinheiten von Unicast und Multicast möchte ich hier nicht detailliert eingehen, nur so viel: bei Unicast wird ein Paket von einem Sender zu einem Empfänger geschickt. Bei Multicast wird ein Paket von einem Sender an einen oder mehrere Empfänger geschickt. Technisch wird das realisiert, indem ein Empfänger einer so genannten Multicast-Gruppe beitritt und so sein Interesse bekundet, die Pakete zu empfangen, die an diese Gruppe geschickt werden. Der Sender sendet dabei ein Paket also nicht mehrfach an einzelne Hosts, sondern sendet das Paket an die Adresse der Mutlicast-Gruppe. Die aktiven Netzwerkkomponenten kümmern sich dann darum, dass die Pakete "vervielfältigt" werden und an die interessierten Empfänger geschickt werden. Für Multicast-Gruppen sind Adressen im Bereich 224.0.0.0/4, sprich 224.0.0.1 bis 239.255.255.254 vorgesehen, wobei nicht alle frei verwendet werden dürfen, da es einige Adressen gibt, die für spezielle Zwecke reserviert sind.

    Für das Ausspielen von IPTV hat Multicast den Vorteil, dass die benötigte Bandbreite reduziert wird. Wenn zum Beispiel 1000 Haushalte ARD schauen und die Übertragung per Unicast realisiert wäre, müsste der Server jedes Paket 1000 mal senden - an jeden Haushalt eins. Neben der benötigten Bandbreite erzeugt das auch höhere Last auf Serverseite - das skaliert also nicht gut. Bei Multicast sendet der Server das Paket nur einmal und die Pakete werden nur an den Stellen durch die aktiven Netzkomponenten "vervielfältigt", wo es nötig ist.

    Allerdings hat Multicast auch Nachteile, weswegen wir uns überhaupt mit dem IGMP-Proxy und Paketfilterregeln beschäftigen müssen. Der eine Nachteil besteht darin, dass Multicast-Traffic standardmäßig nicht geroutet wird, das bedeutet, Multicast-Pakete werden vom Router in der Regel verworfen. Hier springt der IGMP-Proxy ein. Der zweite Nachteil liegt darin, dass es bei Multicast nach dem Beitreten zu einer Gruppe länger dauert als bei Unicast, bis das erste Paket empfangen werden kann. Deswegen fordern die Media Receiver der Telekom beim Umschalten auf einen anderen Sender den Stream zunächst per Unicast an und schalten erst nach ein paar Sekunden im Hintergrund auf Multicast um. Das ist der Grund, weswegen man ohne irgendeine besondere Konfiguration an der pfSense beim Umschalten immer ein paar Sekunden den Sender sehen kann und es danach anfängt zu ruckeln und irgendwann der Stream ganz stoppt.

    Eine weitere Besonderheit von Multicast ist, dass zwischendurch geprüft wird, ob ein Empfänger überhaupt noch online ist. Falls nicht, wird der Empfänger aus dieser Gruppe entfernt und es wird auch nicht versucht, weiter Pakete an ihn zu senden.

    Um nun erfolgreich Multicast-Pakete empfangen zu können, kommen zwei verschiedene Protokoll zum Einsatz: IGMP und UDP. IGMP-Pakete dienen zur Verwaltung der Multicast-Gruppen. D.h. wenn ein Empfänger einer Gruppe beitreten möchte, schickt er ein bestimmtes IGMP-Paket. Wenn geprüft werden soll, ob ein Empfänger noch online ist, wird dies auch durch IGMP-Pakete gemacht. Über UDP wird der eigentliche Content, also die Video-/Audio-Daten an die Multicast-Gruppe geschickt.

    Zusammengefasst müssen also IGMP-Pakete aus unserem internen Netz zur Telekom und zurück geroutet werden. Und wir müssen UDP-Pakete an die Multicast-Gruppe akzeptieren und routen, die nicht wie andere UDP-Pakete als Antwort auf eine Anfrage aus unserem Netz dienen und deswegen vom Paketfilter eigentlich abgewiesen werden.

    Konfiguration

    IGMP-Proxy

    Die von MagentaTV verwendeten Multicast-Gruppen liegen im Adressbereich 232.0.0.0/16. Da MagentaTV auf IGMPv3 bzw. so genanntes Source Specific Multicast setzt, müssen wir auch noch die Quelle kennen. Die ist in unserem Fall eine einzelne Adresse, nämlich 87.141.215.251. Diese beiden Adressen brauchen wir für den upstream-Teil der Konfiguration des IGMP-Proxys. Für den downstream-Teil benötigen wir das interne Netz, in dem sich der bzw. die Media Receiver befinden. Wenn das interne Netz zum Beispiel das Netz 192.168.1.0 mit Netzmaske 255.255.255.0 ist, sieht die Konfiguration wie folgt aus:

    Bildschirmfoto 2020-05-22 um 18.15.56.png

    Paketfilter Regeln

    IGMP Outbound

    Wir müssen dafür sorgen, dass der Media Receiver IGMP-Pakete versenden darf. Wer es sich einfach machen möchte, kann bei der Default allow LAN to any rule unter Advanced Options Allow IP options aktivieren. So erreicht aber der komplette IGMP-Verkehr aus dem lokalen Netz die pfSense und den IGMP-Proxy. Wer es gerne etwas kontrollierter haben möchte, legt eine zusätzliche Regel an, die IGMP-Pakete nur von den Media Receiver erlaubt. Im Beispiel heisst die Regel LAN MagentaTV IGMP. Ich habe einen Alias für die Receiver angelegt und diesen als Source verwendet. Wer nur einen besitzt, kann als Source direkt die IP-Adresse des Media Receivers verwenden. In dieser Regel Allow IP options aktivieren.

    ACHTUNG: Die neue Regel muss vor(!) der Default allow LAN to any rule stehen, da sonst die IGMP-Pakete schon verworfen werden, bevor sie überhaupt bei unserer neuen Regel ankommen.

    Bildschirmfoto 2020-05-22 um 18.21.58.png

    UDP Inbound

    Jetzt haben wir erstmal soweit alles konfiguriert, dass der Media Receiver einer Multicast-Gruppe beitreten kann. Trotzdem stockt das Bild noch nach ein paar Sekunden, weil wir den Content per Multicast noch nicht akzeptieren. Hierfür müssen wir auf der WAN-Seite eine Regel anlegen, die UDP-Pakete mit Quelle 87.141.215.251 und Ziel 232.0.0.0/16 akzeptiert. Wenn ihr diese Regel jetzt hinzufügt, müsste schon das Umschalten von UDP auf Multicast funktionieren und ihr solltet einige Zeit ohne Ruckeln ein Bild sehen können. Allow IP options braucht nicht aktiviert zu werden.

    Bildschirmfoto 2020-05-22 um 18.28.41.png

    IGMP Inbound

    Jetzt fehlt noch der letzte Baustein: IGMP-Pakete eingehend zu akzeptieren. Wenn ihr bis hierher gefolgt seid, werdet ihr feststellen, dass trotzdem nach einiger Zeit (ein bis zwei Minuten) der Stream kurzzeitig abbricht, um kurz darauf wieder zu laufen. Das liegt daran, dass die "Sendeseite" zwischenzeitlich per IGMP-Paket prüft, ob der Empfänger überhaupt noch online ist. Da diese Pakete verworfen werden, wird der Empfänger aus der Multicast-Gruppe entfernt, es kommt also kein Content mehr an. Der Media Receiver versucht dann wieder der Gruppe beizutreten und das Spiel beginnt von neuem, bis wieder das IGMP-Paket verworfen wird.

    Deswegen fügen wir folgende Regel auf der WAN-Seite hinzu. Bitte hier aber die Allow IP options aktivieren!

    Bildschirmfoto 2020-05-22 um 18.34.27.png

    Zusammen sieht das WAN-seitig dann so aus:

    Bildschirmfoto 2020-05-22 um 18.35.59.png

    Jetzt solltet ihr unterbrechungsfrei MagentaTV über pfSense schauen können.

    Setup

    Als Referenz hier mein Setup: Telekom VDSL 100 -> DrayTek Vigor 130 (reiner Modembetrieb) -> APU.1D4 mit pfSense (macht PPPoE und VLAN 7-Tagging) -> Cisco SG350 -> TP-Link T1500G-8T

    Ein MR 401 hängt am T1500G-8T, ein MR 201 hängt direkt am SG350. Beide Switches unterstützen IGMPv3 Snooping.

    Ich hoffe, das hilft dem ein oder anderen. :-)

    Freue mich über Feedback!


  • @arnog

    Ich habe es bei mir genau eingerichtet und es läuft fast perfekt.
    Aber ich habe ab und zu freezer.
    Manchmal 1 am Abend, aber manchmal auch mehrere pro Stunde.
    Die Sender sind eigentlich egal.

    Ganz schlimm wird es wenn ich einen Download am PC starte. dann hackt und stottert es komplett.

    Gibt es die Möglichkeit eine Bandbreite für IGMP zu reservieren, so dass diese absoluten Vorrang vor allen anderen hat?

    Viele Grüße

    ProNet


  • @pronet36

    IGMP ist nur das Steuerprotokoll, über das der Receiver mitteilt, dass er einer Multicast-Gruppe beitreten möchte bzw. dass er an den Pakten interessiert ist. Diese Nachrichten sind im Vergleich zum Content relativ klein und tauchen bei weitem nicht so oft auf, wie der eigentliche Content. Insofern vermute ich, dass die Priorisierung von IGMP Dir nicht helfen wird. Bei Dir scheint der eigentliche Multicast Content Probleme zu machen.

    Aus der Ferne ist es gerade etwas schwierig, Dir hier zu helfen, ohne etwas mehr über Dein Setup zu wissen (verwendete Switches, Access Points, wie sind die Receiver angebunden usw.). Kannst du das mal aufschreiben und vielleicht ein Bild posten?


  • @arnog

    Hi,

    vielen dank für die Antwort!
    Meine Konfiguration sieht folgendermaßen aus:

    Draytek Vigor 165 (als reines Modem)---pfsense---Switch (netgear GS108Ev3) und an diesem Switch hängen die 2 Mediareceiver.

    IGMPv3 snooping ist im Switch aktiviert und mit der alten Konfiguration (Fritzbox als Router) lief das ganze absolut fehlerfrei.
    Sollte der Switch Scheiße sein, habe ich auch kein Problem einen anderen zu kaufen... ;-)

    Viele Grüße

    Pronet36


  • @pronet36

    Ich denke, dass die Telekom von sich aus schon die Multicast-Pakete priorisiert - habe da aber bisher keine Pakete protokolliert, um das mit Sicherheit sagen zu können. Die Pakete sollten also schon in der richtigen "Reihenfolge" priorisiert bei dir ankommen. Dein internes, kabelgebundenes Netz sollte in jedem Fall schneller sein als die externe Anbindung. Deswegen kann ich mir im Moment nur den Switch als Übeltäter vorstellen.

    Hast du beim Wechsel auf die pfSense den Tarif bzw. die Bandbreite umgestellt? Falls der Switch die Probleme verursacht, könnte das ein Grund sein, wieso es vorher lief, jetzt aber nicht mehr.

    Was Du mal testen könntest, um zu sehen, ob der Switch die Probleme macht: Klemm mal Deine(n) WiFi Access Point(s) ab und schalte das IGMP Snooping aus(!). Dann teste mal bei einer längeren Session, ob du noch Aussetzer hast. Falls nein, parallel mal kabelgebunden einen Download starten. Falls das auch alles ohne Probleme geht, IGMP-Snooping wieder einschalten. Wenn jetzt Aussetzer auftreten, ist der Switch überfordert. Die WiFi Access Points dürfen dabei nicht angeschlossen sein, weil Multicast-Verkehr im WiFi mit einer festgesetzten, recht niedrigen Datenrate übertragen wird. Wenn Du die WiFi Access Points für den Test abklemmst und den Download mit Kabel startest, verhinderst Du, dass Du wegen der Multicast-Problematik im WiFi wieder andere Testartefakte bekommst.

    Eigentlich wird Multicast-Verkehr in einem LAN wie Broadcast behandelt, das heißt, alle Multicast-Pakete werden an alle Ports eines Switches weitergeleitet. Wenn Du IGMP Snooping aktivierst, passieren zwei Sachen: der Switch liest IGMP-Nachrichten mit und merkt sich, an welchem Port ein Host einer Multicast-Gruppe beigetreten ist. Wenn dann Multicast-Verkehr reinkommt, filtert der Switch den Multicast-Verkehr und leitet die Pakete nur an die Ports weiter, an denen ein Host der entsprechenden Multicast-Gruppe beigetreten ist. Wenn also IGMP-Snooping ausgeschaltet ist, landet der komplette Multicast-Verkehr auch an den Ports, an denen die WiFi Access Points angeschlossen sind (und nicht alle WiFi Access Points beherrschen selber IGMP Snooping).