Entertain im Netzwerk, Test und Analyse
17 years ago
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
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
21390
39
This could help you too
15 years ago
20355
0
59
Solved
192
0
5
865
0
11
17 years ago
Eine Frage: Dein Switch macht IGMPv2 genau wie meiner. Musstest du die Tabellen manuell anlegen? Wenn ich "nur" IGMPv2 aktiviere, bleibt dass Bild bei IPTV nach 10 Sekunden hängen. Tabellen könnt ich manuell setzen, müsste damit allerdings ein wenig experimentieren (Netgear machts mir da etwas schwer :)
Danke im Vorraus.
0
17 years ago
--------------------------------------------------------------------------------
> Sehr schöner Beitrag.
Danke!
> Eine Frage: Dein Switch macht IGMPv2 genau wie meiner. Musstest du die Tabellen
> manuell anlegen? Wenn ich "nur" IGMPv2 aktiviere, bleibt dass Bild bei IPTV nach
> 10 Sekunden hängen. Tabellen könnt ich manuell setzen, müsste damit
> allerdings ein wenig experimentieren (Netgear machts mir da etwas schwer :)
Die Tabelle wird durch IGMP automatisch angelegt. Der Media Receiver fordert einen Stream entsprechend an, wodurch der Eintrag in die Tabelle gemacht wird.
Wäre ja auch schlecht machbar, bei jedem Programmwechsel ne andere Multicast-Adresse einzutragen.
Bei mir gibt es auch gar keine Möglichkeit, die Tabelle manuell anzulegen.
Setzt du sonst die gleiche Hardware ein? Was ist denn das genau Modell deines Switches?
Solange IGMP deaktiviert ist, müsste sich deine Switch ja "dumm" stellen und die Multicasts an alle Ports leiten. Funktioniert das denn?
> Danke im Vorraus.
Bitte, evtl. kann ich ja helfen!
Gruß
Mechman
0
17 years ago
Hallo Mechman,
"Mechman" (Nickname) schrieb:
> ich habe seit kurzem auch Entertain und möchte hier eine Analyse zum
> Traffic im Netzwerk vorstellen und mit einigen Gerüchten aufräumen.
Vielen Dank für die Mühe! *lach
> 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.
Das passt nicht zu unserer Erfahrung. Beim Speedport W 700V ist es zwar
seit der Firmware 3.15.000 der Fall, beim Speedport W 920V wohl "von haus
aus" aber beim Speedport W 701V und Speedport W 900V gibt es regelmäßig
Probleme, wenn der Media Receiver NICHT am LAN-Port 3 oder 4 hängen. Ein
aktuelles Beispiel finden Sie im Thread
<>.
> IGMP Queries sind
> auf dem Netzwerk nur in V2 zu sehen, er sendet keine V3 Queries.
Das wäre zu schön. Wir haben Ihren Beitrag weitergeleitet, um dies
möglichst bestätigen zu lassen. Wegen der Antwort von "Dr.Einstein"
plagen uns aber noch gewisse Zweifel.
Mit freundlichen Grüßen
Ihr T-Online-Team
--- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
http://forum.t-online.de/ -> Service-Foren
--- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
0
17 years ago
--------------------------------------------------------------------------------
> > 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.
>
> Das passt nicht zu unserer Erfahrung. Beim Speedport W 700V ist es zwar
> seit der Firmware 3.15.000 der Fall, beim Speedport W 920V wohl "von haus
> aus" aber beim Speedport W 701V und Speedport W 900V gibt es regelmäßig
> Probleme, wenn der Media Receiver NICHT am LAN-Port 3 oder 4 hängen. Ein
> aktuelles Beispiel finden Sie im Thread
> <>.
Das ist eine Vermutung, da die Multicasts auf alles Ports des Speedport ausgegeben werden (habe ich mit Wireshark geprüft).
Aber die Switch im Speedport W 701V kann natürlich zusätzlich noch QOS portbasiert machen. Das Datenblatt zum verbauten Switch-Chip verrät das. Was da konfiguriert ist, kann ich natürlich nicht prüfen. Aber IGMP kann die Switch im Speedport nicht, da ist das Datenblatt auch eindeutig. Evtl. gibt es verschiedene Hardware-Varianten?
Auf Nummer sicher geht man natürlich, wenn man Port 3 oder 4 benutzt, wie es empfohlen wird. Der Uplink zu meiner Switch geht auch über Port 4.
> > IGMP Queries sind
> > auf dem Netzwerk nur in V2 zu sehen, er sendet keine V3 Queries.
>
> Das wäre zu schön. Wir haben Ihren Beitrag weitergeleitet, um dies
> möglichst bestätigen zu lassen. Wegen der Antwort von "Dr.Einstein"
> plagen uns aber noch gewisse Zweifel.
Ja, da würde ich auch gerne noch wissen, warum das bei ihm nicht geht. Bezüglich der IGMP Version werde ich nochmal nachprüfen und einen Traffic-Log mit Wireshark erstellen.
Gruß
Mechman
0
17 years ago
habe das mit IGMP jetzt nochmal geprüft. Es läuft aktuell alles in v2 ab. Der Router antwortet auf Queries zwar mit einem "Join Group 224.0.0.22" (das ist die Multicast-Adresse, auf der IGMPv3 Router hören), aber es tut sich sonst nichts in dieser Gruppe. Der Speedport W 701V hört also nur schonmal, ob da anfragen kommen. Da kann sich natürlich in Zukunft was ändern.
Alles andere (Join und Leave der Multicasts) läuft auf dem Multicast-Adresse 224.0.0.1 und 224.0.0.2 ab, wo meine Switch und der Router auch drauf hören.
Ich kann gerne mal einen Ausschnitt des Logs von Wireshark posten. Kann es vielleicht auch sein, dass sich das bei VDSL anders verhält?
Gruß
Mechman
0
17 years ago
--------------------------------------------------------------------------------
> Ich kann gerne mal einen Ausschnitt des Logs von Wireshark posten. Kann es
> vielleicht auch sein, dass sich das bei VDSL anders verhält?
>
> Gruß
> Mechman
Ich vermute es ganz stark, da wie gesagt bei meinem VDSL 50 Anschluss mein IGMPv2 Switch "Netgear GS1081" nach 10 Sekunden das Bild abbricht. Dabei spielt es keine Rolle, ob ich IGMP ausschalte oder aktiviere. Ist IGMPv2 aktiv, werden Multicasts automatsich der Tabelle zugeordnet, allerdings ist ein manuelles nachtragen möglich. Ich vermute, dass bei VDSL eventuell 1..2 Multicast Adressen zusätzlich "freigeschaltet" werden müssen, wenn man nicht die Version 3 besitzt.
Ich werde mal bei Zeit Wireshark Trace machen
0
17 years ago
0
17 years ago
Gruß
Mechman
0
17 years ago
Hallo Mechman und "Dr.Einstein",
"Dr.Einstein" (Nickname) schrieb:
> Nachtrag: Gerade einfach mal Wireshark denVerkehr protokolliert: Es
> tauchen nur IGMPv3 Nachrichten auf, keine IGMPv2. (VDSL50)
Das ist zu schade, denn in Bezug auf IGMPv3 kennen wir keine für den
Heimgebrauch erschwinglichen Switches. Wir möchten uns aber noch
ausdrücklich bei Ihnen beiden für den Input bedanken! *zwinkern
Mit freundlichen Grüßen
Ihr T-Online-Team
--- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
http://forum.t-online.de/ -> Service-Foren
--- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
0
17 years ago
Mein Switch hatte die FW Version 1.0.1_06. "IGMP Snooping Status" = aktiv und "Block Unknown Multicast Address" = aktiv hat zum Ergebnis geführt, dass nach ca. 5-10 Sekunden das Bild komplett hängen blieb (Laut Trace kamen 2 IGMPv3 Membership Anforderungen zu dem Zeitpunkt).
Da der Switch ja nur IGMPv2 statt IGMPv3 unterstützt, wird er die Pakete als unknown markieren. Daraufhin folgende Einstellungen: "IGMP Snooping Status" = aktiv und "Block Unknown Multicast Address" = deaktiv. Nach den 5-10 Sekunden blieb das Bild wieder hängen, jedoch nur halb. Ca. 1/2 Bild pro Sekunde kam anscheinend durch. Eventuell ging die CPU Last des Switches zu dem Zeitpunkt auf 100%, ein Anpingen des Switches war nicht mehr möglich, trotzdem kamen die UDP Pakete von den Fernsehsendern vereinzelt an (ca. 500 Pakets/s).
So, nach der Aktion hab ich dann mal die neueste Firmware 3.0.2 für den Switch aufgespielt und siehe da, es funktioniert. Jedoch werden logischerweise IGMPv3 Gruppen nicht automatisch gebildet und das Netzwerk wird mit dem Stream "geflootet".
Was ich persönlich merkwürdig finde: Der Netzwerkverkehr in den ersten 5-10 Sekunden beim Senderwechsel geschehen nur zwischen dem "Router-Port" und dem "X301T-Port". Nachdem die beiden Membership IGMPv3-Pakete passieren, werden alle weiteren Pakete auf alle Ports verstreut. Das Bild lief aber vorher (ebenfalls) sauber...
Ich frage mich ernsthaft, ob IGMPv3 überhaupt notwendig ist, wenn ja, wofür?
Ich werde die nächsten Tage mal versuchen, die IGMP Anforderungen anhand der MAC Adresse in VLANs zu unterteilen, damit diese nur die entsprechenden Ports am Switch ansprechen (virtuell IGMPv3? :-)
Ein Dankeschön an das TOT, und ganz besonders an Mechman.
P.S. Endlich verschwinden 2 von 3 Cat7 Kabeln, die unterm Teppich verlegt sind
0
Unlogged in user
Ask
from