Zielnetzarchitektur und igmpproxy

Als T-Home anno 2006 (damals noch T-Com und T-Online) in das IPTV Geschäft einsteigen wollte, stand man unter einem gewissen Zeitdruck die technischen Voraussetzungen für Multicast zu erfüllen. Um nicht erstmal 2 Jahre lang ein ausgeklügeltes Netz aufzubauen ohne einen Kunden darauf zu haben, entschloss man sich zunächst mit der sogenannten Startnetzarchitektur zu starten. Diese sieht nur eine Verbindung vor, sowohl für Internet, als auch IPTV. Problem an dieser Verbindung ist, dass sie eine Punkt-zu-Punkt Verbindung ist, zwischen DSL-Router und dem Breitbandrouter auf Seiten der Telekom. Diese Verbindung ist „unantastbar“, d.h. soll ein Paket übertragen werden, muss es vom BRAS (aka. BB-RAR) verschickt werden. Ein Aggregationsswitch oder ein DSLAM kann kein Paket dort einschleusen.

Im Falle Multicast heisst das, dass der BRAS der letzte Multicastreplikationspunkt vor dem DSL Router des Kunden darstellt. Also effektiv zwischen BRAS und DSL-Router in Unicast umgewandelt wird (es bleibt natürlich weiterhin Multicast, muss aber für jeden Anschluss vom BRAS kopiert werden). Empfangen also am gleichen DSLAM 2 Anschlüsse den ARD-Stream, so wird dieser trotz Multicast 2mal vom BRAS übertragen. Dies stellt das Aggregationsnetz, welches DSLAMs gebündelt mit den BRAS verbindet, vor gewisse Probleme.

Diese Probleme sollen mit der Zielnetzarchitektur behoben werden, indem man die PPPoE Verbindung zum BRAS nur noch für das Internet oder sonstigen Unicast-Traffic verwendet (mit Ausnahme der Unicast Übertragung beim Umschalten, sowie den VoDs via Entertain). Für den Multicast wird eine 2. Verbindung aufgebaut auf IP-Ebene. Dadurch kann der Multicastreplikationspunkt im Endausbau bis zum DSLAM rücken.

Quelle: http://www.onlinekosten.de/forum/showpost.php?p=1367573&postcount=26
Quelle: Hanussen

Soviel mal zur Theorie. Hauptunterschied zwischen Start- und Zielnetz sind die Umsetzungen der entsprechenden RFCs. So besagt RFC 5135:

The NAT MUST NOT forward Local Network Control Block (224.0.0/24) [RFC 3171] (also known as „link-local multicast“) traffic from its ‚inside‘ interface(s) to its ‚outside‘ interface.

Sowie RFC 3171:

Local Network Control Block (224.0.0/24)

Addresses in the Local Network Control block are used for protocol control traffic that is not forwarded off link.

Entsprechend werden Membership Reports, die eine Adresse des Local Network Control Blocks enthalten direkt verworfen. Fatal ist dabei, dass bei IGMPv3 alle Adressen in einem Report zusammengefasst werden können. Dieser wird dann komplett ignoriert, was dazu führt, dass der IGMP Querier irgendwann sämtlichen Multicasttraffic abschaltet, da er denkt, dieser würde nicht mehr benötigt.

Leider gibt der igmpproxy alle Membership Reports auf sein Upstream Interface weiter, ohne jegliche Prüfung. Befindet sich also ein Gerät im Netz, welches eine Multicastgruppe aus dem link-local Bereich anfragt (bspw die mDNS Implementierung von Vista oder avahi unter Linux), so fordert der igmpproxy diese Gruppe auch auf dem WAN-Interface an.

Um dies zu verhindern habe ich einen kleinen Patch geschrieben, der die Konfiguration von whitelists erlaubt. Nur Multicastgruppen in dieser Liste werden dann auch auf WAN-Seite angefordert.

Den Patch findet ihr hier (funktioniert mit igmpproxy 0.1 beta4 und beta5, nachfolgende Versionen haben den Patch bereits integriert, dann kann direkt mit der Konfiguration weitergemacht werden).

Diesen dann mit patch -p1 < igmpproxy_whitelist_0.1_beta4.patch im Verzeichnis des frisch entpackten igmpproxy anwenden und mit make (und ggf make install) neu kompilieren.

In der config fügt ihr dann im Bereich eures Downstream Interfaces die Zeile whitelist 239.35.0.0/16 hinzu.

Dies sorgt dafür, dass von diesem Interface nur noch Reports aus dem Subnetz 239.35.0.0 mit der Subnetzmaske 255.255.0.0 erlaubt sind und auf WAN-Seite weitergegeben werden. Ihr könnt natürlich noch weitere Gruppen hinzufügen. Ist kein whitelist Eintrag auf einem downstream-Interface vorhanden, ist die funktion deaktiviert und alle Gruppen werden weitergeleitet.

Achtung: dies gilt nur für vom igmpproxy angeforderte Multicastgruppen. Läuft auf dem Router selbst noch ein Programm, das diese Gruppen anfordert, so bringt die whitelist von igmpproxy natürlich nichts und die Reports werden immer noch verworfen. Es lohnt sich also mal die beigetretenen Multicastgruppen mit netstat -ng auf dem Router zu überprüfen.

2 Trackbacks & Pingbacks

  1. Telekom Entertain with OpenWrt » Philipp Klaus's Computing Blog
  2. Anonymous

Kommentar hinterlassen

E-Mail Adresse wird nicht veröffentlicht.


*


Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.