hallo konsolen,
ich geh jetzt kurz auf die mcast problematik und den ansatz ein, der mit der neuen aontv.ini verfolgt wird. dann sollte es klar sein, worauf man achten muß, wenn man dem tg einen switch nachschaltet.
1. das problem:
wenn man keine vorkehrungen trifft und eine stb (oder einen anderen multicast receiver) an das tg anschließt, dann werden alle ethports mit dem mcast traffic, den der mcast receiver anfordert, gefloodet. es gibt jetzt verschiedene möglichkeiten dieses flooding zu verhindern, eine davon ist
2. der ansatz der telekom
die telekom hat in der aontv.ini ein 2. vlan für video eingerichtet und ethport 3 und 4 in dieses vlan gestellt. dadurch wird der mcast traffic auf diese 2 ethports eingeschränkt und die pc im data-vlan bleiben von den streams verschont.
nachteil: das ganze ist eine stat. angelegenheit und dadurch etwas unflexibel. weiter tritt bei 2 stb's folgendes prob auf:
wenn stb1 z.b. orf1 abonniert und stb2 orf2, dann wird natürlich auch stb1 mit orf2 überflutet und umgekehrt. der mcast traffic ist zwar auf das video-vlan beschränkt, die ethports werden jedoch nicht differenziert.
3. igmp snooping
bei der neuen aontv.ini versuchen wir, die mcast problematik mit igmp snooping zu lösen.
wenn igmp snooping aktiviert ist, dann untersucht das tg die igmp membership reports ("joins" ), die die stb rausschickt, wenn sie einer bestimmen gruppe beitreten will und schaltet selektiv den einen ethport, an dem die stb hängt, für diese gruppe frei. die anderen ethports bleiben für mcast traffic gesperrt, sodaß die pc's nicht mit dem stream zugemüllt werden.
hat folgende vorteile:
- der user kann die stb an jedem ethport anhängen
- user ohne aontv können die ini ohne konfigurationsänderung übernehmen und haben alle 4 ethports für ihre pc's zur verfügung
- wenn 2 stb's im einsatz sind, kommen sie sich nicht mehr in die quere
4. ein zusätzlicher switch am tg
wenn ein switch an das tg angeschlossen wird, dann wird der igmp snooping mechanismus ausgehebelt, falls der switch selbst kein igmp snooping kann, denn:
wenn die stb am switch einen join rausschickt, dann öffent das tg natürlich den ethport für die gruppe, der die stb beigetreten ist. der stream geht richtung switch- kann der jetzt kein igmp snooping, dann flutet er alle switchports mit dem stream und man ist wieder dort, wo man nicht sein will...(deshalb sollte auch kein hub eingesetzt werden).
weiters ist bei verwendung eines switches ein detail in der neuen aontv.ini zu beachten: die fastleave-option ist aktiv.
das kann zu folgendem problem führen, wenn am switch 2 oder mehrere stb's hängen:
angenommen 2 stb's schauen grad orf1- alles ist paletti-, dann wechselt der user von stb2 auf orf2. die stb2 schickt einen leave für orf1 raus und das tg sperrt den ethport, an dem der switch hängt, sofort für orf1. folge: auf der stb1 wirds dunkel und der user von stb1 is sauer...
deshalb ist bei verwendung eines switches mit 2(+) stb's die fastleave-option (zumindest an dem port, an dem der switch hängt) zu deaktivieren:
=>eth bridge igmpsnooping ifconfig brname bridge intf ethport{1|2|3|4} fastleave disabled
so, das wär jetzt mal das wichtigste zur neuen aontv.ini, viel spaß- und rückmeldungen sind wie immer hochwillkommen
.
lg
zid
(lan-ip ändern, ppp- und atm-schnittstellen deaktivieren oder gleich ganz löschen).
.