Um aktiv am Forum teilzunehmen, geben Sie bitte Ihr Login ein:
Foren-Login
Festnetz-Kunde Mobilfunk-Kunde <div id="iframe-error" style="margin-left:140px;color:#f00;font-weight:bold;width:500px;padding:5px 0 0;"> Bitte erlauben Sie die Verwendung von iFrames in Ihrem Browser, um das Forum vollst&auml;ndig nutzen zu k&ouml;nnen. </div>
 
Foren-Suche
 
 
 
Entertain im Netzwerk, Test und Analyse
Thema 6684 von 7219
 
Zurück
Thema: vorheriges | nächstes
05. August 2008 21:17 Re: Entertain im Netzwerk, Test und Analyse
Dr.Einstein
Mitglied seit: 29.07.08
Anzahl Beiträge: 15
Jou, bin dabei. Werde mich in nächstes Zeit mal ransetzten und nochmal ordentliche Netzwerktrace machen.
 
07. August 2008 11:28 Re: Entertain im Netzwerk, Test und Analyse
Mechman
Mitglied seit: 02.08.08
Anzahl Beiträge: 21
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
 
07. August 2008 11:51 Re: Entertain im Netzwerk, Test und Analyse
T-Online-Team
Mitglied seit: 02.07.04
Anzahl Beiträge: 66662
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
-- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 
09. August 2008 18:41 Re: Entertain im Netzwerk, Test und Analyse
Mechman
Mitglied seit: 02.08.08
Anzahl Beiträge: 21
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
 
09. August 2008 21:33 Re: Entertain im Netzwerk, Test und Analyse
Dr.Einstein
Mitglied seit: 29.07.08
Anzahl Beiträge: 15
Bin begeistert, funktioniert einwandfrei :-)
Endlich tauchen automatisch Multicast Gruppen auf.

Recht herzlichen Dank
P.S. mein Netzwerk freut sich nun über weniger Broadcast-Storms :-)
 
11. August 2008 14:52 Re: Entertain im Netzwerk, Test und Analyse
Mechman
Mitglied seit: 02.08.08
Anzahl Beiträge: 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
 
11. August 2008 20:32 Re: Entertain im Netzwerk, Test und Analyse
Grinch
Mitglied seit: 04.02.08
Anzahl Beiträge: 414
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 Freudig hüpfen
 
11. August 2008 23:09 Re: Entertain im Netzwerk, Test und Analyse
Mechman
Mitglied seit: 02.08.08
Anzahl Beiträge: 21
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 Freudig hüpfen


Da sagst du was! Grinsen

Gruß
Mechman
 
11. August 2008 23:31 Re: Entertain im Netzwerk, Test und Analyse
T-Online-Team
Mitglied seit: 02.07.04
Anzahl Beiträge: 66662
 
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 Freudig hüpfen

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
--- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
 
12. August 2008 17:46 Re: Entertain im Netzwerk, Test und Analyse
Grinch
Mitglied seit: 04.02.08
Anzahl Beiträge: 414
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 Erstaunt
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.
 
12. August 2008 18:23 Re: Entertain im Netzwerk, Test und Analyse
powerchen
Mitglied seit: 04.02.07
Anzahl Beiträge: 1
Hallo,

so, zweiter Versuch nachdem der ersten Bit-Nirvana verschwunden ist *grummel*.

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. Wenn ich das TOT wäre, würde ich das aber wahrscheinlich auch nicht
> schreiben, um nicht drauf festgenagelt werden zu können Freudig hüpfen
Da würde ich lieber vorher nochmal RFC3376 gründlich lesen Zwinkern

Grundsätzlich muss ein Host in der Lage sein, sich auf den IGMP Querier
einzustellen. Wenn also der Querier IGMPv2 vorgibt, dann muss ein Host ebenfalls IGMPv2 verwenden. Mehr ist in RFC3376 nicht definiert.

Aber: Das heisst nicht, dass die Anwendung dann auch noch läuft! Sollte eine Anwendung IGMPv3 spezifische Features verwendet, dann funktioniert das nur, wenn der Hosts ebenfalls einen IGMPv3 Protokollstack verwendet. Ein erzwungenes Fallback auf IGMPv2 hilft an der Stelle nicht weiter, da IGMPv2 im Vergleich zu IGMPv3 nur einen eingeschränkten Umfang besitzt.

> Die Joins von IGMPv3 sind immer nur für "any sources". Von den weiteren
> Möglichkeiten von IGMPv3 wird also nicht viel Gebrauch gemacht.
Hast Du mal nachgeschaut, wieviele Group Records die Membership-Reports enthalten, die beispielsweise als Antwort auf ein IGMPv3 Query gesendet werden?

Switches die Query Funktionalitäten haben sind im SoHo Umfeld eher selten, v3 wird jedoch mittlerweile von verschiedenen bezahlbaren Geräten - unter anderem von Zyxel - unterstützt.

powerchen
 
12. August 2008 19:52 Re: Entertain im Netzwerk, Test und Analyse
Mechman
Mitglied seit: 02.08.08
Anzahl Beiträge: 21
powerchen schrieb:
--------------------------------------------------------------------------------
> Hallo,
>
> so, zweiter Versuch nachdem der ersten Bit-Nirvana verschwunden ist *grummel*.

Jepp, passiert hier schnell, wenn man zu lange tippt...


> > Die Joins von IGMPv3 sind immer nur für "any sources". Von den weiteren
> > Möglichkeiten von IGMPv3 wird also nicht viel Gebrauch gemacht.
> Hast Du mal nachgeschaut, wieviele Group Records die Membership-Reports
> enthalten, die beispielsweise als Antwort auf ein IGMPv3 Query gesendet werden?

Das sind mehrere. Da kommen eben alle auf einmal, während bei IGMPv2 mehrere Membership-Reports nötig sind. Bis dahin ja noch kein Problem.
So lang es funktioniert, funktioniert es halt.

Gruß
Mechman
 
12. August 2008 20:48 Re: Entertain im Netzwerk, Test und Analyse
Grinch
Mitglied seit: 04.02.08
Anzahl Beiträge: 414
powerchen schrieb:
--------------------------------------------------------------------------------

> Grundsätzlich muss ein Host in der Lage sein, sich auf den IGMP Querier
> einzustellen. Wenn also der Querier IGMPv2 vorgibt, dann muss ein Host ebenfalls
> IGMPv2 verwenden. Mehr ist in RFC3376 nicht definiert.
Nichts anderes hab ich behauptet.. der Host stellt sich auf den Querier ein.

> Aber: Das heisst nicht, dass die Anwendung dann auch noch läuft! Sollte eine
> Anwendung IGMPv3 spezifische Features verwendet, dann funktioniert das nur, wenn
> der Hosts ebenfalls einen IGMPv3 Protokollstack verwendet. Ein erzwungenes
> Fallback auf IGMPv2 hilft an der Stelle nicht weiter, da IGMPv2 im Vergleich zu
> IGMPv3 nur einen eingeschränkten Umfang besitzt.
Klar kann man nicht die Features von IGMPv3 im IGMPv2 Kompatibilitätsmodus nutzen. Die Anwendung muss davon aber nicht unbedingt etwas mitbekommen. Denn im Endeffekt beschränken sich die Änderungen für die Anwendungen darauf, dass sie die Quellen angeben können.
Wie der Host Stack letztlich reagiert, wenn die Anwendung einen Sourcefilter angibt er aber im Kompatibilitätsmodus ist, ist in der RFC nicht dokumentiert, oder zumindest hab ich dazu nichts gefunden. Entweder er ignoriert es komplett, oder die Filterung findet auf Hostebene statt, oder er lässt es ganz bleiben. Ich persönlich tippe auf Möglichkeit 2. Hat mal jemand den Quelltext von Windows CE? Zwinkern Wie auch immer, ist die Quelle im gleichen Netz wie das Ziel gibt es keinen den es interessieren würde was der Host für einen Source-Filter angibt, von daher entweder ist das entweder der Anwendung oder dem Kernel egal, oder sie ignorieren die Pakete bei abweichender Quelladresse.

Aber warum an dieser Stelle über ungelegte Eier diskutieren? Derzeit gibt die MSTV Anwendung keine Source-Liste mit an und es ist fraglich, ob sie das je tun wird. Vielleicht läuft die Sicherung der Quelle auch über RTP oder der Stream wird in irgendeiner Form signiert, damit man nicht fremde Streams einschieben kann (hat das eigentlich schon mal jemand probiert?). Denn eine wirklich große Hilfe ist der Sourcefilter nicht, da von WAN Seite sicher schon entsprechende Maßnahmen getroffen wurden, dass nicht andere auf diese Gruppen rausstreamen können. Davon abgesehen lassen sich Quelladressen auch fälschen Zwinkern

> Hast Du mal nachgeschaut, wieviele Group Records die Membership-Reports
> enthalten, die beispielsweise als Antwort auf ein IGMPv3 Query gesendet werden?
Soviele wie in ein Paket reinpassen Zwinkern
Dass es Unterschiede gibt ist klar, aber ob die STB mit einem Report alle Groups angibt oder jede in einem Einzelnen, kann dem Endanwender letzlich egal sein, darum kümmert sich wieder der oben genannte IGMP Stack.
 
12. August 2008 21:15 Re: Entertain im Netzwerk, Test und Analyse
T-Online-Team
Mitglied seit: 02.07.04
Anzahl Beiträge: 66662
 
Hallo Grinch,

"Grinch" (Nickname) schrieb:

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

Wir fragten uns auch - bzw. den, der uns informierte - was für Änderungen
denn auf uns zukämen, die IGMPv2-Switches überfordern würden. Die Antwort
lautet schlicht: SSM. Gemeint ist damit
http://en.wikipedia.org/wiki/Source-specific_multicast

Das ist offenbar gerade das, was Sie befürchten.

Mit freundlichen Grüßen
Ihr T-Online-Team

--- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
http://forum.t-online.de/ -> Service-Foren
--- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
 
31. August 2008 15:56 Re: Entertain im Netzwerk, Test und Analyse
0Zero
Mitglied seit: 31.08.08
Anzahl Beiträge: 2
Da mich gerade das selbe Problem plagt, daher wie ich einen MediaReceiver über einen weiteren Switch am Speedport betreiben kann, hab ich diese Diskussion mit grossem Interesse verfolgt.
Wenn ich dies nun alles recht verstanden habe, dann komm ich zu dem Schluss, dass ich maximal zwei Empfangsgeräte (MediaReceiver) pro Speedport betreiben kann und und diese auch noch direkt mit dem Speedport verbinden muss.
Bei meiner bestehenden Infrastruktur im Haus, in der nur jeweils ein LAN-Kabel die wichtigsten Zentren verbindet und sonst Switches die Verteilung übernehmen, seh ich also derzeit keine Möglichkeit TV über VDSL in verschiedene Zimmer zu bringen.
Da ich umgekehrt aber auch in jedem Zimmer ein Koaxkabel für Kabel-TV habel, bleibt mir eigentlich nur die Umstellung zurück auf Digitales Kabel-TV. Oder sind hier andere Lösungen in Aussicht?
 
Seite
2
von 3
Weitere Informationen zum Forum
Thema 6684 von 7219
Zur Zeit aktive Benutzer
24 (0 registrierte, 24 Gäste)


Moderatoren
1 Moderatoren


Telekom Team
 
Zurück