IPTV und seine Probleme

IPTV ist eine praktische Sache. Wer das Paket Entertain von der Telekom (oder von einem anderen Anbieter hat) kann prinzipiell von jedem PC Fernsehen schauen. In so weit ausreichend Bandbreite vorhanden ist kann das auch im lokalen Netzwerk genutzt werden. Hier einmal eine alternative Möglichkeit dennoch nicht auf WLAN zu verzichten, wenn die HW nicht unbedingt ideal geeignet ist Multicasts entsprechend einzuschränken.Was aber passiert wenn WLAN ins Spiel kommt?
Jetzt wird es dann doch Spannend und man muss schon etwas in die Trickkiste greifen. Einfach ist es wenn man einen Router hat der IGMP Snooping kann. Was passiert denn eigentlich hier genau.
Der Mediareceiver der T-COM baut sobald ein TV Programm gewählt wurde eine Unicast Verbindung auf, nachdem diese erfolgreich war wird die Verbindung auf Multicast umgestellt. Dieser Multicast wird vom Router, bei mir eine Fritzbox auf alle LAN Ports verteilt. Von dort aus habe ich nun auf allen Ports einen Datenstrom von 4-20MBit/s je nachdem welche Sender in welcher Qualität und Menge gesehen werden. Ein oder beliebig viele angeschlossene WLAN Access Points werden jetzt mit diesem Multicast Storm geflutet. Die verbleibende Bandbreite reicht weder für vernünftigen Internetverkehr, noch reicht es aus um hierüber irgendetwas gescheit zu machen. Die Verbindung bricht regelrecht zusammen. Wird der Mediareceiver ausgeschaltet normalisiert sich das recht schnell. Schnell wird klar, IPTV und WLAN werden nicht wirklich Freunde. (Auch nicht die 5GHz Versionen und auch nicht die x 100MBit Bandbreiten Kisten)
Ziel müsste es sein, den Multicast Datenstrom nur an die Ports auszuliefern, die ihn auch verarbeiten. Das würde mit der VLAN Einstellung und mit IGMP Snooping erfolgen. Auch hierbei müsste man dann den WLAN Port ausnehmen.
Welche Alternativen gibt es aber doch noch wenn es mit dem IGMP Snooping nicht will wie es soll? Portseperation oder Port Isolation heisst das Zauberwort. Die Hilfe des TP-Link sagt dazu folgendes: "Port Isolation is used to limit traffic flow from a single port to a group of ports. This method of segmenting the flow of traffic is similar to using VLANs to limit traffic, but is more restrictive" Klingt erst einmal gut.
Die Idee dahinter ist folgende. Wenn ich die Verbindung vom zentralen LAN Port des Routers zum WLAN AP damit trenne bekomme ich auch kein Multicast Storm mehr. Entscheidend ist das die LAN Adressen des Accesspoints, worüber auch die Verwaltung erfolgt, in einem anderen Netzwerk sind. Es ist dabei nicht wichtig welches Netzsegement der AP an die Clients weiter gibt. Die Netzwerkadresse des Management Interfaces muss keinesfalls mit der Netzwerkadresse der über WLAN angeschlossenen Clients übereinstimmen.
Nun zeigt sich der Vorteil wenn man einen Linux Server hat, der nebenbei auch noch als zentraler LAN Router agiert. Ich spendiere den APs mal ein eigenes Netzwerk, 192.168.1.0/24, für das Management. Die Clients im WLAN bekommen vom DHCP Server auf dem Linux Server Ihre Adressen im Netzwerk 192.168.8.0/24. Also durchaus eine komplett andere Range. Da die AP keine logische Verbindung zum zentralen Router in der DMZ haben ist es gar kein Problem, denn über den LAN Router geht es jetzt ganz normal auch ins Internet und auch die Clients bekommen wie üblich die Adressen. Einzigster Effekt ist, vom LAN Port des Internetrouters gibt es jetzt keine "physiche" Verbindung mehr zum LAN Port der APs. Somit gibt es auch keinen Multicast und es ist Ruhe auf der WLAN Verbindung.
Etwas kompliziert aber Ziel erreicht.

Links:


imported from www2.georg-keller.eu

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.