‎Entertain im Netzwerk, Test und Analyse

Telekom hilft Community

Telekom Business Community

Privatkunden

Telekom Shops

Kontakt

Entertain im Netzwerk, Test und Analyse

vor 17 Jahren

Hallo zusammen,

ich habe seit kurzem auch Entertain und möchte hier eine Analyse zum Traffic im Netzwerk vorstellen und mit einigen Gerüchten aufräumen.

Meine Hardware ist ein Media Receiver 300, ein Speedport W 701V mit neuester Firmware am DSL 16plus Anschluss.
Die Geräte habe ich in mein Netzwerk eingebunden. Der Speedport läuft als Router. Switch ist ein Optiswitch-800 mit IGMPv2.

Noch ein Wort zum Mediareceiver, bevor ich anfange:
Das Display zeigt einen roten, in Segmente unterteilten Kreis an. Der leuchtet nur, wenn eine Netzwerk / Internetverbindung besteht.
Die kleine rote Uhr leuchtet immer, soll ja eigentlich für den Timer zuständig sein.

Nun weiter (direkter Anschluss des Media Receiver an den Speedport):
Auf dem Speedport läuft ein IGMP-Proxy der für die Verteilung der Multicasts zuständig ist. Die Switch im Speedport kann mit IGMP _nichts_ anfangen und behandelt die Multicasts wie Broadcasts und gibt die Pakete auf allen Ports aus. QOS wird das Gerät daher nicht Port- sondern Servicebasiert machen. Guckt man sich die exportierte Konfiguration des Speedports an, spricht auch einiges dafür. Es ist also egal, an welchem Port der Mediareceiver hängt. IGMP Queries sind auf dem Netzwerk nur in V2 zu sehen, er sendet keine V3 Queries.
Exzessives Zappen (auch blättern des EPG ) bereitet den Geräten manchmal Probleme. Es kommt dadurch zu Artefaktbildung oder Standbildern. Scheinbar verschluckt sich auch manchmal der IGMP-Proxy auf dem Speedport. Es kommt vor, dass der Multicast nicht mehr abbestellt wird und immer ins Netzwerk gesendet wird, auch wenn man das Programm gar nicht mehr guckt. Dann gibt es auf anderen Sendern nur noch Bildfehler.
Normalerweise bestellen der Media Receiver und der Speedport den Multicast allerdings korrekt ab. Wenn der Receiver in Standby ist, kommen also keine Streams mehr an.
Das ändert nichts daran, dass weiterhin Bandbreite für IPTV reserviert bleibt (von der T-Com aus). Das lässt sich auch nicht ändern.

Jetzt binden wir das ganze mit der oben genannten Switch in Netzwerk ein:
Solange IGMP auf der Switch deaktiviert ist, behandelt auch diese Multicasts wie Broadcasts und gibt die Pakete einfach an allen Ports aus. Macht keine Probleme beim Fernsehen, verschwendet halt Netzwerkperformance.
So verhalten sich üblicher Weise auch alle günstiges Switches, die nicht managebar sind.

Dann habe ich IGMPv2 auf der Switch aktiviert. Läuft super! Nur noch die Ports, die auch den Multicast-Stream haben wollen, erhalten ihn auch.
So sieht dann der Multicast Table der Switch aus:

===========================================================
IP Multicast MAC TAG Ports
===========================================================
239.035.129.011 01-00-5e-23-81-0b 1 6.01
Querier Ports: S6.04
239.255.255.250 01-00-5e-7f-ff-fa 1 6.01 6.04
Querier Ports: S6.04
239.035.158.200 01-00-5e-23-9e-c8 1 6.01
Querier Ports: S6.04

6.04 ist der Router, 6.01 der Media Receiver. IP 239.035.129.011 ist der Stream, 239.255.255.250 eine Gruppe, in der der Receiver Statusinformationen ausgibt und 239.035.158.200 vermutlich EPG . Da bin ich mir nicht sicher, lasse mich gerne korrigieren.
Es läuft dann alles genau so gut wie direkt am Speedport W 701V, mit dem Vorteil dies restlichen Rechner im Netzwerk von den Multicast Paketen zu verschonen.

Wir man also sieht, ist kein Switch mit IGMPv3 nötig. Das können auch nur Layer 3 Switches, da viel Rechenleistung gebraucht wird, um die IGMPv3 Pakete zu untersuchen. Daher sind diese Switches auch sehr teuer.
Desweiteren ist IGMPv3 abwärtskompatibel zu v2!

Ja, der Beitrag ist sehr lang geworden, aber ich hoffe es ist interessant und hilft vielleicht auch einigen bei der Hardware-Auswahl.

Das ist der aktuelle Stand bei Entertain, ob sich da in Zukunft die Anforderungen ändern, weiß ich natürlich nicht.

Grüße,
Mechman

21417

vor 17 Jahren
Die ersten 5-10 Sekunden kommen vom DServer per Unicast direkt an die Box, erst danach schwenkt die Box auf den Multicast.

IGMPv3 vermutlich weil die Box da wählen kann von welcher Quelle sie den Stream haben will bzw die sie akzeptiert. Wenn mehrere Streamingserver über das Netz verteilt sind könnte man da vielleicht einfach immer den geografisch naheliegendsten wählen und die Server teilen der Box mit welche das ist. Oder man benutzt es als Sicherheitsfunktion um keine fremden Streams einschieben zu können. Aber das ist nur Spekulation. Hat mal jemand geschaut, ob die STB von dieser Funktion überhaupt gebrauch macht?
0
0
vor 17 Jahren
@Dr.Einstein

Danke für deine Tests, sehr interessant. "Block Unknown Multicast Address" wird es ja dann gewesen sein. Schade, dass sich das Flooding nicht unterbinden lässt...

Nötig scheint ja IGMPv3 nicht zu sein. Siehe bei mir... Warum es da Unterschiede zwischen VDSL und ADSL2+ gibt, weiß wohl nur der, der das entwickelt hat.
Weiß da vielleicht das T-Online Team mehr?

Mit VLANs hätte ich auch experimentiert, wenn es nicht mit IGMPv2 geklappt hätte. Wäre super, wenn du uns auf dem Laufenden hälst.

Freut mich dir geholfen zu haben und auch dir vielen Dank!

@Grinch

Genau, da kommt zuerst ein Unicast, dann ein "Join Group" und dann der Multicast. Der Unicast stoppt dann.

Wie oben schon gesagt, warum bei VDSL IGMPv3 genutzt wird, ist echt ne gute Frage.
Die VDSL und die DSL 16 plus Anschlüsse hängen soweit ich weiß an den gleichen DSLAMs. VLAN Tagging brauchen ja auch nur die VDSL Anschlüsse.
Die Multicast-Adressen sind allerdings gleich. Zumindest bei den Öffentlich Rechtlichen.

Gruß
Mechman
0
0
vor 17 Jahren
Mal eine andere Theorie..
Vielleicht liegts auch gar nicht am Anschluss, sondern am verwendeten Switch.
Evtl gibt dein Switch irgendwie zu verstehen, dass es nur IGMPv2 versteht und die STB stellt sich darauf ein. Während das kleine Switch einfach nur passiv die IGMP Pakete verfolgt und die STB davon nichts mitbekommt.

Ihr könntet ja mal beide Captures machen (von Anfang an, also Router aus, Switch aus, STB aus. Dann Switch an, capture starten, andere Geräte starten), nur die IGMP rausfiltern und online stellen, dass man das mal vergleichen kann.

Ich muss mir dazu noch mal ein paar Unterlagen zu Gemüte führen, meine da mal was gelesen zu haben über verschiedene Arten des IGMP Snoopings.
0
0
vor 17 Jahren
Grinch schrieb:
--------------------------------------------------------------------------------
> Mal eine andere Theorie..
> Vielleicht liegts auch gar nicht am Anschluss, sondern am verwendeten Switch.
> Evtl gibt dein Switch irgendwie zu verstehen, dass es nur IGMPv2 versteht und
> die STB stellt sich darauf ein. Während das kleine Switch einfach nur passiv
> die IGMP Pakete verfolgt und die STB davon nichts mitbekommt.
>
> Ihr könntet ja mal beide Captures machen (von Anfang an, also Router aus,
> Switch aus, STB aus. Dann Switch an, capture starten, andere Geräte starten),
> nur die IGMP rausfiltern und online stellen, dass man das mal vergleichen kann.
>
> Ich muss mir dazu noch mal ein paar Unterlagen zu Gemüte führen, meine da mal
> was gelesen zu haben über verschiedene Arten des IGMP Snoopings.

An sowas dachte ich auch schon. Muss ich auch nochmal testen. So direkt war mit mit IGMPv3 aber auch nichts aufgefallen, als meine Switch noch "dumm" war und die Pakete einfach weiter gab.
Auffallend ist allerdings, dass meine Switch die Queries im Netzwerk macht. Deaktiviere ich IGMP, so kommen die Queries vom Router.

@dr. Einstein: Wie sieht das bei dir aus?

Ich prüfe den Ansatz mal und melde mich wieder.

Gruß
Mechman
0
0
vor 17 Jahren
Jou, bin dabei. Werde mich in nächstes Zeit mal ransetzten und nochmal ordentliche Netzwerktrace machen.
0
0
vor 17 Jahren
Es gibt Neuigkeiten! Der Grinch hat Recht!

Es gibt also active und passive IGMP Snooping. Viel findet man nicht darüber, auch nicht in Datenblättern der Switches. Man erkennt es aber daran, dass der Switch selbst die IGMP Queries im Netzwerk sendet. Habe ein Gerät gefunden, wo die Funktion angegeben wird:
http://www.draytek.com/product/Switch/G2080.php

Wenn mein Switch kein IGMP Snooping aktiv hat und der Router und Receiver rebootet werden, läuft alles in IGMPv3 ab, aktiviere ich dann IGMPv2 im Switch, ändert sich alles auf IGMPv2.

Screenshot des Umschaltvorgangs:
http://img357.imageshack.us/img357/2509/igmpxd5.gif

.7 ist der Router, .9 Switch und .14 Receiver.
Die Joins von IGMPv3 sind immer nur für "any sources". Von den weiteren Möglichkeiten von IGMPv3 wird also nicht viel Gebrauch gemacht.

Man könnte für Switches ohne active IGMP Snooping mal versuchen, die exportierte Konfiguration des Speedport W 701V mit dem fbeditor an der Stelle

mrouter {
igmp_version_for_upstream = 3;
igmp_version_for_other = 3;
igmp_prio = 32;
}

zu ändern und dort direkt auf IGMPv2 zu beschränken.
Das habe ich allerdings noch nicht getestet.

Gruß
Mechman
0
0
vor 17 Jahren
Hallo Mechman,
"Mechman" (Nickname) schrieb:
>Nötig scheint ja IGMPv3 nicht zu sein. Siehe bei mir...
Wir können den Einsatz von IGMPv2-Switches nicht empfehlen - auch wenn
das aktuell bedingt funktionieren mag, kann sich das durch technische
Änderungen auf der Plattform zukünftig ändern.
Mit freundlichen Grüßen
Ihr T-Online-Team
-- -- -- -- -- -- -- -- -- -- -- -- -- -- --
http://forum.t-online.de/ -> Service-Foren
-- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0
0
vor 17 Jahren
T-Online-Team schrieb:
--------------------------------------------------------------------------------

>
> Wir können den Einsatz von IGMPv2-Switches nicht empfehlen - auch wenn
> das aktuell bedingt funktionieren mag, kann sich das durch technische
> Änderungen auf der Plattform zukünftig ändern.

Schon klar. Sollte was nicht funktionieren, muss der Receiver natürlich erst direkt am Router in Originalkonfiguration getestet werden.

Noch eine Ergänzung für Leute mit IGMPv2 Switches, die nur passive Snooping können:

Ersetzt man die Zeilen in der exportierten Konfiguration

mrouter {
igmp_version_for_upstream = 3;
igmp_version_for_other = 3;
igmp_prio = 32;
}

durch

mrouter {
igmp_version_for_upstream = 2;
igmp_version_for_other = 2;
igmp_prio = 32;
}

mit dem fbeditor, so spricht der Router nur noch IGMPv2. So lang das funktioniert, kann man den Umweg ja benutzen.
Bis es eine Änderung bei Entertain gibt, sind ja vielleicht günstige Switches mit IGMPv3 auf dem Markt.

Gruß
Mechman
0
0
vor 17 Jahren
Bin begeistert, funktioniert einwandfrei :-)
Endlich tauchen automatisch Multicast Gruppen auf.

Recht herzlichen Dank
P.S. mein Netzwerk freut sich nun über weniger Broadcast-Storms
0
0
vor 17 Jahren
Dr.Einstein schrieb:
--------------------------------------------------------------------------------
> Bin begeistert, funktioniert einwandfrei :-)
> Endlich tauchen automatisch Multicast Gruppen auf.
>
> Recht herzlichen Dank
> P.S. mein Netzwerk freut sich nun über weniger Broadcast-Storms :-)

Super!

Danke auch nochmal an Grinch, das war der entscheidende Hinweis.

Gruß
Mechman
0
0