1721 VPN, trennen v. LAN Ports funktioniert nicht

[kingcrunch]

Guten Tag,

ich habe ein Problem mit einem Lancom 1721 VPN, FW 8.00.0221RU2 HWRelease E, Annex B (jedenfalls glaube ich das die Ursache beim Router zu suchen ist) und T-Entertain (16000 er Leitung).

Die Internetverbindung und die parallele Entertain-Verbindung funktionieren einwandfrei, keine Probleme.

An einem der LAN-Ports des Routers hängt ein W-LAN AP/Repeater von Siemens, Modell Gigaset WLAN Repeater 108.

Sobald der Entertain-Receiver eingeschaltet wird (oder aufnimmt ohne aktivierten TV-Modus) scheint so viel Traffic (augenscheinlich Multicasts) auf dem LAN-Port an dem der WLAN AP hängt (alle anderen Ports identisches Problem) weitergeleitet zu werden das dieser quasi zusammenbricht.

Es herrschen dann massive Probleme eine WLAN Verbindung aufzubauen, teilweise wird das Netz gar nicht mehr gefunden (unabhängig ob die SSID versteckt oder sichtbar geschaltet ist). Sobald eine Verbindung besteht, ist diese so extrem langsam das jeglicher verwendeter Browser behauptet der gewünschte Server antworte nicht, bzw. fallen die DNS requests schon auf die Nase. Die LED für Netzwerktraffic am AP/Repeater flackert ununterbrochen schnell.

Sobald der Receiver ausgeschaltet wird, läuft alles wieder reibungslos.
Bevor ich nun auf eine 25000er Leitung aufstocke möchte ich herausfinden ob das Problem Leitungsbezogen (zu wenig Bandbreite) oder bei dem Router oder WLAN-AP zu suchen ist und ob ein aufstocken der Bandbreite überhaupt etwas bringt.

Ich habe bereits alle Netzwerkports zueinander unsichtbar geschaltet, was keine Verbesserung brachte.
Dann habe ich mein Endgerät direkt an den Router angeschlossen (physikalisch, Netzwerkkabel), ohne Verbesserung.

Das sollte eigentlich das Siemens-Gerät ausschließen...

Ich bin sogar soweit gegangen Receiver und sonstige Netzwerkgeräte über zwei VLANs voneinander zu trennen und diese auf getrennte Netzwerkports zu legen, was auch nichts änderte.

Seitdem bin ich etwas ratlos und kann nur TV gucken/aufnehmen oder surfen. Ich hoffe ihr könnt mir helfen dieses Problem zu lösen.


Vielen Dank & Grüße,
Alex

[Dr.Einstein]

Dein Netzwerk muss komplett IGMPv3 fähig sein, sonst machen alle
Netzelemente aus den Multicasts Broadcasts, die sich auch je nach Konfiguration
über die VLANs hinaus ausbreiten können.

Eine Idee wäre:
- Receiver direkt an Lancom hängen
- mit Schnittstellentags Kommunikation untereinander unterbinden
- ETH-Ports entsprechend LAN-1 / LAN-2 zuordnen
- eigenes Subnetz für den Receiver aufmachen, von beliebig auf
entsprechendes LAN-Netz richten

Gruß Dr.Einstein

[AS1306]

@kingcrunch - Das ist ein altbekanntes Problem, was mit der Möglichkeit des IGMP-Snoopings in den LAN/WLAN-Kombigeräten beseitigt worden ist. Gerade in der ersten Zeit des IP-TV Angebotes gab es diese Möglichkeit nicht, was immer wieder zu diesen Anfragen führte. Irgendwann war die kritische Masse erreicht und eine Lösung hierfür angeboten worden - Punkt 4! IP-TV
Da Dir das bei dem 1721 natürlich aufgrund des nicht vorhandenen WLAN-Modules nicht viel bringt, bleibt Dir tatsächlich nur die Möglichkeit von Dr. Einstein. Seine Idee funktioniert übrigens - war am Anfang auch meine "Notlösung". Ein Ansatz wäre noch ein AP mit IGMP-Snooping Unterstützung oder gleich auf ein LANCOM-Gerät mit integriertem WLAN-Modul zu wechseln. Anders wirst Du den Broadcast/Multicast nicht vom WLAN trennen können. Dein Netz muss also nicht zwangsläufig komplett IGMPv3-fähig sein. (Kosten/Nutzen-Aspekt mal mit eingebracht ...) Es hat definitiv nichts mit der von Dir erwähnten "leitungsmäßigen Bandbreite" zu tun.

Gruß Andreas

[kingcrunch]

Aloha,


Dr. Einstein & Andreas, vielen Dank!
Auf das Schnittstellentagging bin ich gar nicht gekommen.
Die Vorbereitungen waren alle schon getroffen, eigenes Subnetz für den Receiver existierte bereits, der Receiver hängt auch direkt am Lancom,
das umkonfigurieren der LAN-Ports dauerte keine fünf Minuten.
Success! Das Problem hat mich echt lange beschäftigt und ist jetzt gelöst.


Herzlichen Dank für eure Hilfe!

Grüße,
Alex

[Dr.Einstein]

@kingcrunch: Schön, dass es klappt

@AS1306:

Sagen wir so, ICMPv3 Unterstützung in allen Komponent macht schon Sinn,
wenn jetzt z.B. Entertain to go kommt, wo du über WLAN (iPad/iPhone/Android)
den Stream abgreifen kannst. Ich denke, dass wird auch auf IGMPv3 basieren
(siehe VLC Player, ist ja das gleiche).

Ich hatte schon 1-2 Mal den Fall, dass wirklich ein unfähiger Switch Broadcasts
draus macht, und AP mit IGMP-Snopping das WLAN trotzdem geflutet hat.
Switch ersetzt gegen einen 50€ Netgear Switch mit IGMPv3, alles super.

Gruß Dr.Einstein

[AS1306]

@Dr. Einstein - Ne, ich zweifle da überhaupt nicht am Sinn des IGMPv3 und stimme Dir auch bezüglich der zukünftigen Entwicklung vollkommen zu. Wenn es so umgesetzt wird, ist es ja auch die "sauberste" Lösung. Vermutlich wird die Telekom in ihren Routern das genau so realisiert haben. Ich hatte Alex nur in der gleichen Situation wie mich vor ca. 2 Jahren gesehen. Da hat sich diesbezüglich keiner - aber auch nur ansatzweise - um solch ein Problem gekümmert. War ein Nischenmarkt und für LANCOM wohl nicht interessant genug. Mit der zunehmenden Verbreitung und dem Erreichen der kritischen Masse wurde es "GOTT-SEI-DANK" implementiert. Zeigt mir doch, dass man hier recht flexibel auf den Markt reagiert. Bei mir kam anfänglich noch das Problem des 1823´er hinzu - nur 2 LAN-Buchsen (siehe Signatur) ... dann wird es auch noch einmal spannender. Hatte mir daher damals noch einen L-320AGN zugelegt und es damit gelöst. Bei meinem Bruder hatte ich den nun auch von Alex genutzten Ansatz realisiert - das klappt ebenfalls prima! Ist natürlich auch immer davon abhängig, ob eine direkte Verbindung zum Receiver ohne weiteres hergestellt werden kann. Vor 2-3 Jahren sah es da ja auch noch ganz anders aus. Heute stehen einem notfalls noch Powerline (dLAN-Adapter zum Beispiel) oder den von Dir bereits erwähnten Switch für den "schmalen" Geldbeutel (Was ja bekanntlich auch immer relativ ist!) zur Verfügung.
Die Schwarz/Weiß-Geschichte hatte mich etwas irritiert, daher auch das "MUSS-NICHT-KOMPLETT-SEIN" ... und viel wichtiger ist es im Endeffekt, dass Alex einen Denkanstoß für die Lösung seines Problemes bekam.

Gruß Andreas

PS: Lasst VoIP nicht sterben - mag meinen 1823 nicht hergeben, was aber aufgrund von IPv6 sicherlich irgendwann dann doch mal der Fall sein wird, weil muss ...

[janosch]

Dein Netzwerk muss komplett IGMPv3 fähig sein, sonst machen alle
Netzelemente aus den Multicasts Broadcasts, die sich auch je nach Konfiguration
über die VLANs hinaus ausbreiten können.

Das denke ich nicht Tim. Der Sinn eines VLANs ist die Trennung der Broadcastdomänen also, dass Broadcasts ihre Netze nicht verlassen.

Im Übrigen ist die Multicast Implementation der Telekom nach eigener Aussage auch weit entfernt vom Standard.

[Dr.Einstein]

Dein Netzwerk muss komplett IGMPv3 fähig sein, sonst machen alle
Netzelemente aus den Multicasts Broadcasts, die sich auch je nach Konfiguration
über die VLANs hinaus ausbreiten können.

Wie geschrieben. Wenn z.B. keine Schnittstellentags hinterlegt sind, verbreiten
sich umgewandelte Broadcasts über VLAN Grenzen hinaus. Alles schon erlebt.
Glaub mir, wenn man schon Lancom zig Mal für Entertain eingerichtet hat,
kennt man einige Schwachstellen, die das Netzwerk in die Knie zwingen.
Außerdem kanns dir passieren, dass ein nicht IGMPv3 fähiger Switch den
Broadcast auf dein eigentlich isoliertes VLAN raufhaut.

Gruß Dr.Einstein