Entertain im Netzwerk, Test und Analyse

[#1]

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

[#2]

Sehr schöner Beitrag.

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.

[#3]

Dr.Einstein schrieb:
--------------------------------------------------------------------------------
> 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

[#4]

 
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
--- --- --- --- --- --- --- --- --- --- --- --- --- --- ---

[#5]

T-Online-Team schrieb:
--------------------------------------------------------------------------------

> > 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

[#6]

Hallo,

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

[#7]

Mechman schrieb:
--------------------------------------------------------------------------------

> 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

[#8]

Nachtrag: Gerade einfach mal Wireshark denVerkehr protokolliert: Es tauchen nur IGMPv3 Nachrichten auf, keine IGMPv2. (VDSL50)

[#9]

Das ist ja echt interessant. Also sollte ich nochmal erwähnen, dass meine Analyse nur für DSL 16plus gilt.

Gruß
Mechman

[#10]

 
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
--- --- --- --- --- --- --- --- --- --- --- --- --- --- ---

[#11]

So, hab mal ein wenig mit Wireshark und meinem Switch Netgear GS108T rumexperimentiert:

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

[#12]

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?

[#13]

@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

[#14]

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.

[#15]

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

[#16]

Jou, bin dabei. Werde mich in nächstes Zeit mal ransetzten und nochmal ordentliche Netzwerktrace machen.

[#17]

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

[#18]

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
-- -- -- -- -- -- -- -- -- -- -- -- -- -- --

[#19]

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

[#20]

Bin begeistert, funktioniert einwandfrei :-)
Endlich tauchen automatisch Multicast Gruppen auf.

Recht herzlichen Dank
P.S. mein Netzwerk freut sich nun über weniger Broadcast-Storms

[#21]

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

[#22]

Scho recht *schelm

Zum Thema IGMPv2 und Zukunft. Also laut RFC muss jeder IGMPv3 Host sich auch auf IGMPv2 und IGMPv1 verstehen. Ich denke auch mal, dass das eh die Grundfunktionalität von Windows CE ist und bis in alle Ewigkeiten funktionieren wird. Wenn ich das TOT wäre, würde ich das aber wahrscheinlich auch nicht schreiben, um nicht drauf festgenagelt werden zu können (:D

[#23]

Grinch schrieb:
--------------------------------------------------------------------------------
> Scho recht *schelm
>
> Zum Thema IGMPv2 und Zukunft. Also laut RFC muss jeder IGMPv3 Host sich auch auf
> IGMPv2 und IGMPv1 verstehen. Ich denke auch mal, dass das eh die
> Grundfunktionalität von Windows CE ist und bis in alle Ewigkeiten funktionieren
> wird.

So hatte ich das auch verstanden!


> Wenn ich das TOT wäre, würde ich das aber wahrscheinlich auch nicht
> schreiben, um nicht drauf festgenagelt werden zu können (:D


Da sagst du was! :D

Gruß
Mechman

[#24]

 
Hallo Grinch,
"Grinch" (Nickname) schrieb:
> Zum Thema IGMPv2 und Zukunft. Also laut RFC muss jeder IGMPv3 Host sich
> auch auf IGMPv2 und IGMPv1 verstehen. Ich denke auch mal, dass das eh
> die Grundfunktionalität von Windows CE ist und bis in alle Ewigkeiten
> funktionieren wird. Wenn ich das TOT wäre, würde ich das aber
> wahrscheinlich auch nicht schreiben, um nicht drauf festgenagelt werden
> zu können (:D
Wir haben die Nachricht erhalten, dass zwar die IADs auch IGMPv2-Clients
unterstützten, aber die IGMP-Kommunikation zwischen IAD und Backbone und
IAD und Media Receiver über IGMPv3 liefe. Daher sei nicht zu empfehlen,
einen IGMPv2-Switch einzusetzen, da dies in der Zukunft nicht mehr
funktionieren werde.
Wenn wir hier sehen, wie virtuos Sie, "Mechman" und "Dr. Einstein" von
den technischen Möglichkeiten Gebrauch machen, können wir dies natürlich
etwas abschwächen: Schaffen Sie sich IGMPv2-Clients nicht extra für
Entertain an, denn zu einem - uns allerdings nicht bekannten - späteren
Zeitpunkt wird das nicht mehr funktionieren. Solange es noch geht, geht's
halt. *lach
Mit freundlichen Grüßen
Ihr T-Online-Team
--- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
http://forum.t-online.de/ -> Service-Foren
--- --- --- --- --- --- --- --- --- --- --- --- --- --- ---

[#25]

Nungut, ich weiss natürlich nicht, was man sich da für Scherze für die neue Netzarchitektur mit VLAN8 ausgedacht hat. Mit etwas Glück funktionierts da aber auch, wenn man nur den Versionswert für other ändert. Dann spricht der Speedport im LAN v2 und im WAN v3. Also bekommt es eigentlich keiner mit, dass intern mit v2 gearbeitet wird. Zumindest solange man nicht von der Source Option von v3 Gebrauch macht. Das funktioniert bei mir derzeit auch noch problemlos.
Wird man dann sehen ::o
Die Lösung hier ist natürlich mal in erster Linie für die, die über ein Switch verfügen, das sich nur auf passives IGMPv2 Snooping versteht.