Entertain TVplus ist "anders"?

[qwertz.asdfgh]

Öhhhm, wie?

Ja, du hast richtig gelesen.

Und was bedeutet das nun genau fuer TV-Gucken mit T-Entertain?

Es funktioniert.

Sogar das (ich nenne es mal) alte T-Entertain ohne "Plus" konnte im Heimnetzwerk ohne IGMPv3-faehige 1GB-Switches nicht richtig genutzt werden.

Das ist schlicht und ergreifend Quatsch, sowohl das alte Entertain als auch das neue EntertainTV funktioniert mit einfachen Ethernet-Switches (die IGMP-Snooping nicht unterstützen) einwandfrei.

Netzwerkhub-Performance bei Multicast-Streams? Oha.

Wo ist das Problem?

Mit einem HD-Stream ist das Netz voll.

Mit einem, zwei oder gar drei HD-Stream(s) ist ein Fast- oder Gigabit-Netzwerk noch lange nicht voll! Ich kann dir z.B. versichern, selbst 5 HD-Streams bereiten in einem mir bekannten Fast-Ethernet Netzwerk mit 6 verkabelten Clients (2 Receiver, 2 PCs, 1 Notebook und ein MFG) keine Probleme i.V.m. einem einfachen/unmanaged 8-Port (FastEthernet)-Switch der von IGMP-Snooping noch nichts gehört hat. "Voll" ist das Netzwerk dort nie (selbst wenn es mit 3 HD-Streams per Multicast geflutet wird) da es primär für Internetzugang, IPTV, Scannen und Drucken verwendet wird (kein NAS).

 

[Goggo16]

Ich kann dir z.B. versichern, selbst 5 HD-Streams bereiten in einem mir bekannten Fast-Ethernet Netzwerk mit 6 verkabelten Clients (2 Receiver, 2 PCs, 1 Notebook und ein MFG) keine Probleme i.V.m. einem einfachen/unmanaged 8-Port (FastEthernet)-Switch der von IGMP-Snooping noch nichts gehört hat.

Ja was nun. Hub oder Switch?

Eigentlich egal. Das muss dann aber entweder im Labor oder im Museum der Telekom gewesen sein.

Arbeitest Du vielleicht sogar da? Hier im Forum bist Du ja leider ohne Profil unterwegs.

LG, Goggo

 

[qwertz.asdfgh]

Was verstehst du jetzt nicht? Es handelt sich um einen handelsüblichen Fast-Ethernet Switch, der verhält sich bei Multicast-Traffic vergleichbar einem Hub.

PS:
Was habt ihr immer nur mit euren Signaturen. Ich bin eher gegen solche Spielereien, nicht selten haben die mich schön gestört wenn man bestimmte Beiträge gesucht hat.

 

[hyperbel]

Also nocheinmal: Ich möchte im Grunde nur erreichen, dass alles wieder funktioniert, nur eben mit dem neuen EntertainTVplus und dem dazugehörigen MR400.

Bis auf den MR400 ist das komplette Netz identisch zu dem, was vorher jahrelang mit EntertainTV und diversen MR300/301 völlig problemlos funktioniert hat. Einzige Ausnahme war eine Situation vor über 2 Jahren in der eben alte WiFi Router Probleme machten. Durch den Einsatz eines guten Switches _mit_ IGMPv2/v3 snooping konnte genau das behoben werden. Danach gab es keinen Ärger mehr.

Durch die Umschaltung auf Entertain 2.0 wurde es plötzlich erforderlich die AVM 7490 mit einer Laborfirmware zu betreiben, da ETV 2.0 sonst überhaupt nicht funktioniert. Der MR400 ist an einem eigenen Port direkt an der FB7490 angeschlossen. Aber ETV 2.0 kann von Komponenten gestört werden, die an der AVM an einem anderen Port und über besagten IGMP fähigen Switch angeschlossen sind und die mit ETV 2.0 garnichts zu tun haben. Schließe ich wahlweise einen W701V oder einen Netgear WG103 uralt Accesspoint an, dann haben diese keinen Einfluß auf das ETV 2.0

Fehler Option 1: Der ASUS Accesspoint
Fehler Option 2: Die AVM FB7490
Fehler Option 3: Telekom ETV 2.0 macht irgendwas an der SPezifikationen vorbei mit denen die zuvor genannten Komponenten nicht klar kommen und was auch der Switch nicht unterbinden kann.

Abgesehen davon, kann der Switch das Problem nicht mal lösen, wenn alle Systeme hinter der AVM in VLAN 7 (Rat des Entertain TVpluss 2nd Level Support) sind, obwohl ETV 2.0 in VLAN 8 spielt.

Ich muss mir ansehen, was die Topologie für Optionen bietet, sowohl den MR400 als auch den ASUS mal in Monitoring zu nehmen und das Notebook mit Wireshark mitlaufen zu lassen. In der AVM gibt es aber auch einige Monitoring Optionen, die ich mir mal ansehen muss.

Zum Callcenteragentstelekomhilfsteam, das sind entweder Berufslose oder aus verschiedensten Berufen kommende Callcenter Mitarbeiter die in der Regel ahnungslos bis zur völligen Inkompetenz sind.

Entertain2 braucht am "WAN Port" igmpv3 damit der Source specified Multicast den spezifizerten Server erreicht. Das Vlan sei es allein Vlan 7 bei BNG - oder 7 oder 8 bei "normalen" Anschlüssen ist hier fürs LAN irrelevant. Auf dem LAN reicht IGMPv2 nach wie vor aus. Der Switch braucht kein IGMP snooping zu können, es werden in dem Fall eben alle Port mit dem in Broadcast gewandelten Multicast Frames geflutet.

Eine saubere IGMPv3 Implementation im Router, ein IGMP snooping fähiger Switch ist das einzige was du brauchst. Die Telekom Gerätschaften machen allerdings durch die Bank Probleme und funktionieren nur selten problemos, das liegt aber nicht an anderen Komponenten im Netzwerk sondern an einer mülligen Hard- und Software. Entertain wird überschätzt, braucht kein Mensch.

 

[Theo Tintensich]

Solange das Netz mit den paar Multicaststreams nicht überfordert wird (was bei einem Fast- und Gigabit-Ethernet Netzwerk nicht passieren sollte) geht alles einwandfrei weiter...

Ach deshalb funktionierte das Netz auch so gut, als ich mit 'unbrauchbaren' Switchen den Entertain-receiver angeschalteet, nachdme ich von der Kombination Speedport/F!B7170 zur F!B 7390 gewechselt war.
(Die 7170 kann ja kein VDSL, der Speedport aber nicht das Netz auf der LAN-Seite, das ich konfiguriert hatte.
Deshalb hatte ich hinter den SP die F!B geklemmt, als zweiten Router, um mein Netz nicht umstellen zu müssen.
Mit dieser Kombination funktionierte alles, anch der Umstellung auf die 7390 konnte ich den Mediareciever bis zum Austausch der Switche nicht mehr verwenden.
Denn das Netz wurde geflutet, kein einziges System war mehr erreichbar. Ca. 10 Minuten nachd em Einschalten des MR blieb alles stehen. Den MR ausgeschalteet, und der Rest funktionierte wieder.)

Einfach die LAN-Schnittstelle des Routers auf 100Mb begrenzen,

Wieso?

Weil der Broadcaststurm dann nur mit 100Mb läuft? ;-)

Du scheinst die "Broadcaststürme" bei Entertain zu überschätzen.

Nein

100Mb/s bei Entertain? Wie sollen die entstehen bei einem (V)DSL-Anschluss?

Du meinst, das private Netz wird auf 50M gebremst, wenn an einen VDSL-50-Anschluss hat?

 

[qwertz.asdfgh]

Weil der Broadcaststurm dann nur mit 100Mb läuft? ;-)

Du scheinst nichts verstanden zu haben...

 

[astralix]

Das gerät aus den Fugen...

Also aufpassen!

1) Die pauschale Aussage, der Telefonsupport ist doof, ist quatsch. Es kommt, wie immer im Leben, auf Zufall und Tagesform an und auch ein gutes Stück weit, wie man selber da aufschlägt.

2) Ich habe bereits mit 1st Level, dem 2nd-Level und dem Online-Support zu tun gehabt. Gemachte Zusagen wurden eingehalten, bis auf einen Rückruf, wurden alle vereinbarten Termine eingehalten.

Es wurde mir erklärt, dass man an einem Problem arbeite, dass bestimmte Geräte allein durch ihre Existenz im gleichen Netz dazu führen können, dass eine der T-Entertain Komponenten einen Broadcast-Storm auslösen kann. Dabei wurde klargestellt, dass es NICHT um ein übliches IGMPvX Problem, HUBs oder Switches oder veraltete WiFi Router geht. Auch wenn man sich seitens des Supports nicht zu einer klare Aussage mit Namen hinreißen lassen wollte, war klar, dass eine der beteiligten T-Entertain Komponenten Mist baut, wenn zufällig eine eigentlich unbeteiligte dritte Komponente im Netz vorhanden ist.

Fakten:
Wenn ich den ASUS RT-AC66U gegen einen alten Telekom 710 getaucht habe, war das Problem verschwunden.
Mein ASUS RT-AC66U hat in der Zeit zwischen Auftreten und Lösen des Problems kein Firmware-Update bekommen.
Meine Fritz!Box 7490 hat in der Zeit wahrscheinlich kein Update bekommen.
Die Software-Versionen, die der ASUS seitens der Vermittlungsstelle meldet, habe ich nicht verfolgt, ebensowenig die Software Version des T-Entertain Recorders.

Aber der Support sagte, dass man ein identisches Problem mit anderer Hardware als einem ASUS Router identifiziert habe. Der ASUS Router wurde mit auf die Liste der auslösenden Produkte gesetzt.
Der Support sagte auch, dass man an dem Problem arbeite und ohnehin ein größeres Plattform-Update anstünde.

Aus privaten Gründen habe ich erst einige Zeit nach dem Plattform Upgrade erneut testen können, wie es sich mit dem ASUS RT-AC66U verhält.

Ergebnis:
Das von mir reproduzierbar dargestellte Problem ist nicht mehr nachvollziehbar.

Vermutungen / Rückschlüsse:
Die Wahrscheinlichkeit, dass es ein Problem in der Entertain Software hab, ist relativ hoch.
Die Wahrscheinlichkeit, dass es ein Problem in der Fritz!box ist gering, dass es ein Problem im ASUS AC-RT66U gibt ist nahezu Null, ebensowenig hatten die verwendeten Switches einen Einfluß.

Wer also jetzt noch einen Broadcast Storm im eigenen Netz hat, der hat tatsächlich ein Problem in seiner Netzwerk-Konfiguration, oder er setzt veraltete Netzwerkkomponenten ein.

 

[hyperbel]

Der Telekom Support ist unfähig, das er doof sei hat ja keiner geschrieben, aber allein die Aussagen die du von ihm erhieltest sind absurd.

Es wurde mir erklärt, dass man an einem Problem arbeite, dass bestimmte Geräte allein durch ihre Existenz im gleichen Netz dazu führen können, dass eine der T-Entertain Komponenten einen Broadcast-Storm auslösen kann.

Diese Aussage allein ist schon mehr als absurd. Es wird einzig dann eine Flutung mit Broadcasts im Netz geben wenn Multicast nicht korrekt verarbeitet wird, oder ein Gerät welches massenhaft Broadcast in das Netz bläst ist defekt.

war klar, dass eine der beteiligten T-Entertain Komponenten Mist baut, wenn zufällig eine eigentlich unbeteiligte dritte Komponente im Netz vorhanden ist.

Sorry, die T-Entertain Komponente baut Mist und das unabhängig von einer dritten Komponente.

Wer also jetzt noch einen Broadcast Storm im eigenen Netz hat, der hat tatsächlich ein Problem in seiner Netzwerk-Konfiguration, oder er setzt veraltete Netzwerkkomponenten ein.

Oder hat kein Multicastverkehr der von nicht geeigneter Hardware als Broadcast ins Netz geflutet wird, hat also Entertain nicht geordert.

 

[Theo Tintensich]

Du scheinst nichts verstanden zu haben...

Genau.
Ich habe es bei mir ja auch nur im Netz gehabt, und konnte 'sehen', was passierte.
Ich habe es also weder verstanden und kenne ich es.

(Kleine Preisfrage:
Wenn du durch ein Rohr mit einem Durchmesser von 10cm Wasser mit einem Druck von von 10bar drückst, wird in dem dahinter angeschlossenen Rohr mit einem Durchmesser von 100cm der Druck auch 10bar sein?

Wenn du in einem 100baseT Daten mit einer Geschindigkeit von 99Mb/s schiebst, ist das Netz voll.
Ist es ein GbE-Netz, und kann das liefernde System maximal 100Mb/s liefern, ist das Netz dann immer noch voll?
)

 

[qwertz.asdfgh]

Ich habe es also weder verstanden und kenne ich es.

So scheint es zu sein. Nur weil du es nicht hinbekommen hast lässt dies keine Rückschlüsse darauf zu, dass es prinzipiell nicht funktioniert. Allein schon folgender Kommentar von dir lässt vermuten, dass du dich mit der Thematik nicht ausreichend beschäftigt hast:

Du meinst, das private Netz wird auf 50M gebremst, wenn an einen VDSL-50-Anschluss hat?

Ein paar Beispiele aus der Praxis:
Zusätzlich zu dem in #61 erwähnten Netzwerk mit derzeit 7490 (und früher W920V) sowie FE-Switch kommen noch 2 Netze mit 7390, 3 mit W921V und eines mit 7430 i.V.m. "unbrauchbaren" Switches (Hersteller u.a. Allnet und D-Link, einfache unmanaged GbE-Swichtes ohne IGMP-Snooping Support, hergestellt vor 2010) dazu, alle mit Entertain (1-3 Media-Receiver) an VDSL50 (4x), Fiber 50 (2x) und Fiber 100 (1x).

Die haben alle keine Probleme mit den Receivern bzw. den Multicaststreams (die Clients incl. MR hängen an den Switches), das Netz wird weder mit 50Mb/s, mit 100Mb/s oder gar 1Gb/s geflutet sondern mit der summierten Datenrate der im Netzwerk angeforderten/genutzten Multicaststreams (i.d.R. 1-3 HD-Streams, entspricht 8-24Mb/s).
Separate WLAN-APs gibt es bei diesen Installationen nicht, die IADs sind zentral im Gebäude angeordnet (sorgt für ausreichende Versorgung mit WLAN und tw. DECT) und versorgen dann die (primitiven/"ungeeigneten") Switches (meist im KG bzw. Hausanschlussraum) von wo es dann weiter geht zu den verkabelten Clients (incl. MR).

Warum haben diese Netzwerke i.V.m. "unbrauchbaren" Switches (unmanaged Switches, keine Unterstützung für IGMP-Snooping, das Netzwerk wird mit den Multicaststreams entsprechend geflutet) keine Probleme? Die MR laufen einwandfrei und auch der Rest des jeweiligen Netzwerk wird durch die Multicasstreams nicht verstopft (geflutet != verstopft).

Probleme mit IPTV habe ich in der Praxis nicht mit unmanaged Switches die kein IGMP-Snooping beherrschen (und somit das Netzwerk mit den Multicaststreams fluten) sondern eher mit MRs die z.B. mit WLAN-Bridges oder PLC angebunden sind.

Bei anderen Installationen wurde dagegen (wenn Neuanschaffungen dbzgl. sowieso notwendig oder geplant waren) von Anfang an auf Ethernet-Switches gesetzt die auch IGMP-Snooping beherrschen, bei den o.g. Beispielen war jedoch eine Neuanschaffung bzgl. Switches eben noch nicht nötig/gewünscht als IPTV dazu kam.

Noch nicht aufgezählt hatte ich übrigens mein (ehemaliges) eigenes Netzwerk, dieses lief jahrelang mit einer 7390, 3 Ethernet-Switches (2x Netgear GS108v2 und 1x GS105v2, nicht mit den Modellen GS10xE zu verwechseln die IGMP-Snooping beherrschen) und 3 MRs ohne Probleme (nachdem ich die "Störer" entdeckte und beseitigte) und das obwohl alle 3 Switches anfingen munter zu blinken sobald ein Multicaststream von einem Client (z.B. MR) angefordert wurde (das gesamte Netzwerk wurde mit den Multicaststreams geflutet). Auch der Netzwerkdurchsatz zum NAS hatte währenddessen keine merklichen Einbußen.

Es gab allerdings ein MFG das ab dem 6. HD-Stream nicht mehr per Ethernet ansprechbar war weil er dann die ca. 48Mb/s eingehenden Broadcast-Traffic (ist bei Switches ohne IGMP-Snooping mit Broadcasts zu vergleichen bzw. wird Multicast in Broadcasts umgewandelt) vermutlich nicht mehr verarbeiten konnte, den Rest des Netzwerkes störte das nicht, zudem kam der Fall in der Praxis nicht vor (in der Praxis max. 3 HD-Streams, in seltenen Fällen auch mal 4 HD-Streams).

Wenn du in einem 100baseT Daten mit einer Geschindigkeit von 99Mb/s schiebst, ist das Netz voll.

Wo kommen die 99Mb/s her?

 

[astralix]

Also nocheinmal:

Mein Ziel war es, die Diskussion wieder sachlich zu bekommen, und das sinnlose Support-Bashing abzuwürgen. Außerdem scheint der Irrglaube zu herrschen, dass eine Netzwerkkomponente nicht einen Fehler bei einer anderen Komponente auslösen kann, nur weil sie nichts miteinander zu tun haben. Der ASUS Router ist recht mächtiges kleines Ding mit Mediaplayer, SAMBA Server, FTP und viele anderen Optionen an Bord. Außerdem kann er Seinesgleich im Netz identifizieren und auch DHCP Server und WAN Router via Modem spielen. Er sendet also eine Menge Daten aus eigener Initiative aus und eines dieser Pakete scheint dann wahrscheinlich den MR300 zur Raserei zu treiben. Ob dieses Problem nur auftritt, wenn der MR300 an eine FritzBox angeschlossen ist, und welches Paket / welcher Dienst im ASUS der Auslöser ist und welcher Dienst im MR dann ausklinkt, das wollte der Support nicht sagen.

Und letztendlich hat der Support da sogar recht, denn wenn die Entwicklung da noch nicht sicher war und nur "vermutete", dann könnte es einen Hersteller eine Menge Geld kosten, wenn die Hotline wegen eines nicht vorhandenen Fehlers geflutet wird.

Und nebenbei habe ich das komplette Netz bei mir auf Gigabit, damals konnten alle beteiligten Switche und Router IGMPv2/v3 und während der MR kein Bild mehr produzieren konnte, konnten alle anderen Geräte im Netz noch weiter problemlos und mit normaler Datenrate das Internet nutzen. Es ist also durchaus möglich, dass sich der Datensturm lediglich zwischen zwei Geräten abgespielt hat, oder sogar nur intern im MR oder lediglich vom MR aus ins Netz passierte, wo er dann von Anderen als sinnlos verworfen wurde. Die Diagramme in der Fritzbox zeigten keine 100MBit Auslastung des VDSL mit reinen IPTV Daten.

Ein einfaches Heimnetz hat überhaupt kein Problem damit, wenn der Switch kein IGMP kann. Die Multicast Pakete werden vom Switch, wie ein Broadcast, auf alle Ports weitergegeben. Die angeschlossenen Geräte verwerfen die Pakete, wenn sie den Multicast nicht angefordert haben. Selbst bei 5 HD Strömen kommen da im Mittel keine 20Mb/s zustande. Da die 20Mb/s nur in der einen Richtung laufen, ist die andere Richtung noch zu 100% frei, Multicast erfordert keine Quittung.
Heftig wird es, wenn (sehr) alte Komponenten Multicast als TCP verarbeiten. Dann denken sie nämlich, dass eine Quittung erforderlich ist und senden sogar Repeat- oder NACK Pakete zurück, für jedes Paket, das nicht abgeliefert werden konnte. Das war unter Anderem ein Grund, warum ich meine alten WRT54GL WiFi Router verkauft habe, sie haben dieses Spiel getrieben, wenn man auf einem Mobilen Gerät einen Stream angeschaut hat, dieser Stream dann aber nicht bei der Quelle abgemeldet wurde. (WiFi Bereich verlassen, Notebook zugeklappt ohne den Player zu beenden...) Kommt es dann noch wegen der ganzen Repeat / Retry / NACK Situation zu einem vollen Paket-Puffer und alle neuen Pakete werden per NACK abgelehnt.

-----
Übrigens kann ein sehr einfacher Fehler auch einen Broadcast-Storm erzeugen... Man muss nur zwei Switche versehentlich mal mit zwei Kabeln untereinander verbinden. Früher war das nicht so einfach, weil die Dinger einen dedizierten Uplink Port hatten. Aber heute können die alle Auto-MDIX und da ist das schnell passiert, das die Pakete anfangen zu kreisen

 

[grundigboy]

Hallo,

ich möchte auch etwas beitragen. Mein MR400 hängt an einer als IP-Client konfigurierten 4040 via Switch -> die Zentralabox ist eine 7412 (FW 6.50) am ADSL 16 Entertain Plus. Natürlich hatte ich auch die bekannten Probleme mit Multicast, Switch etc. Da AVM irgendwann im Sommer 2016 versprochen hatte die neue Entertain-Multicasttechnik in die FW zu integrieren, habe ich erst einmal nichts getan. Fernsehen ging ja, wenn auch das Umschalten mit Fehlermeldung "länger" gedauert hat.

Die Beta-FW 06.69-xxx auf der 4040 hat noch nichts geändert. Doch seit vorgestern gibt es auch eine Beta-FW 06.69 für die 7412. ES GEHT out of the box.

Danke AVM!

Schönes WE

Tom