L2TP besonders anfällig für Paketverluste auf der DSL-Leitung?

Technik
21

Ausser den Gluon/Kernel Versionen als Parameter gibts es dann noch unterschiedliche Anwendungs-Testfälle, die dann helfen eine Testmatrix duenn aber aussagekraeftig zu besiedeln.

Aber vermutlich faengt man erst mal an und schaut sich Traces an bei einem lahmen und einem schnellen Fall und dann iteriert man sich an sinvolle Fälle heran. Entweder ist es dann schon klar wie Klossbrühe oder man weiss dann, wie man Testfälle sinnvoll strukturiert (ihh hoert sich nach Arbeit an, ich weiss… nicht unzufällig ist der verwandte Thread ja auch schon alt und grau. :smile: )

Aber zum Tracen hier schon mal mal :

http://www.wehavemorefun.de/fritzbox/Capture.lua sehr fein

22

Mitschnitte haben wir mal gemacht, da ist mir nichts aufgefallen.

23

Wenn bei IP Fragmente verloren gehen, dann schlaegt halt nach einer gefuehlten Ewigkeit von 30+s o.ae. der Reassembly Timer zu und dann wird alles weggeworfen und es geht ein ICMP TimeExceed/ Fragment Reassembly failed raus an den Sender. Bei v6 muss das aehnlich aussehen. Das busybox netstat ist aber sehr spartanisch und ausserdem werden 0 Zeilen haeufig gar nicht ausgegeben. Normalerweise sucht man da im ICMP Histogram inbound/outbound und das relativiert man dann zu dem was man ueber frames weiss. Glaube /proc/net/netstat ist auch nicht ausfuehrlicher als netstat…

Evtl muss man dann auf der fbox tracen und dann auswerten.

Auch der intelligente fastd kann gegen Verluste de-facto nichts machen. UDP sieht unvollstaendige IP Pakete ja erst gar nicht. Der Reassembly Timer hat fast ausschliesslich diagnostischen Wert und den, den Speicher von alten fragmenten zu befreien. Bei vielen Verlusten braucht man vor allem viel Speicher. (hatte frueher viel mit NFS zu tun… ), weil der Timer IIRC und wenn das nicht verbessert sprich adaptiv geworden ist, so lang ist, dass die Anwendung (oder TCP) selbst laengst Retransmissions geschickt hat.

Man muesste das dann zB mit zwei FFRs - mit unterschiedlichen Tunneln - nacheinander in derselben Umgebung testen - idealerweise mit dem selben gegenueber. Evtl identischer Copy-Test oder aehnliches.

Meine Fbox behauptet uebrigens, in Spitzenzeiten nur 80 nicht behebbare (CRC) Fehler/Std in Frames zu haben, im Mittel 40. Das ist Potenzen von einstelligen Prozentwerten weg. Ist auch immer noch ein oller 6000er Anschluss mit Bandbreitenreserven. Das mag wohl deutlich mehr werden, wenn man die Grenzen geht. Da habe ich keine Erfahrung. Aber es wird wohl auch noch deutlich mehr Gruende fuer Verluste geben.

24

Danke für die ausführlichen Erklärungen!

Aber physikalisch problematische Leitungen hatte ich bisher noch nicht.

Der Stand bei uns ist: Ab 2016.1.x läuft L2TP nicht mehr an einer 7270 oder 7170 und bei ein paar neueren muss man den Teredofilter deaktivieren. Letzteres gilt insbesondere für die Kabelversion, die Unitymedia vertreibt.

Da es von der Softwareversion des Gluon abhängt und eben nicht von der Leitung, muss da was anders laufen. Entweder im Kernel oder im Tunneldigger. Woran es genau liegt, wissen wir noch nicht.

Wir geben mittlerweile ein Gluon 2015.1.5 an Besitzer von problematischen DSL-Routern.

25

Moin.

Da in dem Thread der Begriff TEREDO auftauchte und ich diesen nicht kannte, habe ich mich mal auf die Suche gemacht.

Interessant fand ich einen Artikel bei GOLEM: Xbox verletzt Teredo-Standart

In diesem Artikel wird auf einen WIKI-Eintrag verwiesen: Teredo ist ein Tunnelprotokoll

Moment! Tunnelprotokoll habe ich hier schon mal gelesen. :blush:

Im WIKI liest man dann: Teredo ist ein IPv6-Übergangsmechanismus. Dieses Kommunikationsprotokoll für den Datenverkehr mit dem Internet ist gemäß RFC 4380 spezifiziert.

Unter dem Link im WIKI Gefahren steht:
Durch die Tunnelung des IPv6 besteht die Gefahr, dass insbesondere die Sicherheitsfunktionalitäten NAT-basierter IPv4-Router vollständig ausgehebelt werden können. Bei den durch Teredo erzeugten IPv4 UDP-Paketen handelt es sich um Pakete, bei denen die in diesem Szenario vorhandenen Paketfilter wirkungslos bleiben. Es liegt seit 2007 eine Analyse durch Symantec vor, die diesen Sachverhalt bestätigt. Dem sicherheitsorientierten Administrator wird daher empfohlen, bis zur Verfügbarkeit entsprechender Firewalls den durch Teredo benutzten UDP-Port 3544 komplett zu sperren.

In dem Artikel bei GOLEM findet sich auch ein Hinweis auf eine Supportseite bei AVM, welche allerdings nicht mehr aktuell ist.
Eine Suche bei AVM förderte dann doch was zu tage: Verbindung mit Teredo-Protokol nicht möglich .

Unter Ursache, liest man:
Bei bestehender IPv6-Internetanbindung blockiert die FRITZ!Box aus
Sicherheitsgründen den UDP-Port 3544. Anwendungen können dadurch nicht
über das Teredo-Protokoll auf das Internet zugereifen und somit auch
nicht die FRITZ!Box-Firewall umgehen und anstelle der vorhandenen
IPv6-Verbindung der FRITZ!Box mittels Teredo eine eigene IPv6-Verbindung
herstellen. Die FRITZ!Box folgt damit standardisierten Empfehlungen für
Heimnetzgeräte (RFC 6169 Abschnitt 3.1.3) sowie den Empfehlungen des Bundesamts für Sicherheit in der Informationstechnik.

Die Frage, die ich mir nun zu der Überschrift dieser Diskussion stelle ist:

Kann es sein, das aufgrund der Filterregeln für dieses Protokoll es auf dem Übertragungsweg zu den beschriebenen Einschränkungen/Fehlern kommt? Und basieren unsere verwendeten Tunnelprotokolle auf den beschriebenen RFCs?

Der Hauptgrund dieser Überlegung:
Bei bestehender IPv6-Internetanbindung blockiert die FRITZ!Box aus Sicherheitsgründen den UDP-Port 3544.

Und es wird wohl nicht nur bei AVM so sein.

Was wenn nun ein Gerät in der Übertragungskette diese Filterregel erkennt und versucht diesen Datenfluß entsprechend zu unterbinden … ? Und es teilweise gelingt?

Sollte mein Geschreibsel völlig das Thema verfehlt haben, bitte ich dieses zu entschuldigen und meinen Beitrag zu verschieben oder zu löschen.

Gruß

26

Nein.
„komplette Sperre“ ist etwas anderes als „Paketverlust“.
Du suchst vermutlich eher einen Thread mit Überschriften der Art „überhaupt keine Verbindung hinter Router xy“, wie z.b. diesen.

27

Das dubiose ist halt, dass die Verbindung nicht blockiert, sondern auf 0,5 bis 2,5 Mbit/s gedrosselt wird. Das kann kein Feature sein, sondern ist definitiv irgendwo ein Bug. Und tritt nur mit Gluon 2016.x auf, nicht mit 2015er Versionen.

28

Ich höre mich grade im Bekanntenkreis um ob jemand eine 7270/7170 im Einsatz hat …

Die meisten haben jedoch entweder eine 7390/7490 oder halt irgend nen Noname Routerzwang Schrott.

testen könnte ich wenn ich eine auftreibe mit:

Server (Ubuntu 16.04.1 LTS):

filename:       /lib/modules/4.4.0-53-generic/kernel/net/batman-adv/batman-adv.ko
version:        2015.2
description:    B.A.T.M.A.N. advanced
author:         Marek Lindner <mareklindner@neomailbox.ch>, Simon Wunderlich <sw@simonwunderlich.de>
license:        GPL
srcversion:     76BD26E30704FC5D5D41FEB
depends:        libcrc32c
intree:         Y
vermagic:       4.4.0-53-generic SMP mod_unload modversions

und auf der Routenseite läuft Gluon 2016.2.1

Mit den neueren Fritzboxen läuft die Combo super Stabil und Performant.

29

Spannend wäre dann, welche L2TP/Tunneldigger-Version.

Ich kann nur sagen: habe ich eine Leitung mit Packet-Loss und ein halbwegs aktuelles Gluen (vom Sommer), dann läuft der Futro mit dem FastD dort besser als der Futro mit dem L2TP.
Hat die DSL-Wananbindung „keine Probleme“, dann läuft der Traffic über den Futro mit dem L2TP (und selbst im Gespann aus L2TP-841er und FastD-Futro läuft der meiste Traffic dann über den 841er.)

Aber das ist halt nur eine lokale Betrachtung.

30

Ich kenne jetzt deine Situation nicht im Detail, aber wenn es Paketverluste auf der DSL-Leitung gibt, würde ich den DSL-Router mal tauschen. Bei O2 z. B. sind das aber auch oft Messfehler, weil deren Router Pings nicht korrekt verarbeiten.

Kurzum, es gibt eigentlich keine DSL-Leitungen mit Paketverlusten.

31

Wenn Du der Vertragnehmer der Leitung bist, dann solltest Du das wirklich tun!
(Hat aber mit dem Thema doch herzlich wenig zu tun, warum/ob/mit welcher Version fastd besser mit Loss und/oder Lag (oder Packet reordering?) zurechtkommt?)

1 „Gefällt mir“