ich hab jetzt schon mehrfach erlebt, dass bei kaputten DSL-Modems, die ein paar Pakete verlieren, L2TP-Verbindungen besonders betroffen sind.
Im privaten Netz fällt es noch gar nicht auf, Fastd kommt halbwegs damit zurecht und schafft oft noch 4-5 Mbit/s und L2TP krüppelt mit weniger als einem halben Mbit.
Weiß jemand woran das liegt? Eigentlich sind es doch beides UDP-Tunnel. Hat Fastd da irgendwelche Fehlerbehebungsmechanismen?
Würde mich mal interessieren, falls jemand eine Erklärung dafür hat.
Tipp an alle: Wenn mal ein Anschluss lahmt, einfach mal ein anderes DSL-Modem probieren bzw. mit einem mtr auf die private öffentliche IPV4 die Paketverluste sichtbar machen.
Man durch L2TP merke ich erst, wie viele DSL-Modems eigentlich einen Schlag haben.
@anon75826926, kannst du was dazu sagen, warum Fastd das so viel besser wegstecken kann als L2TP? Hast du da irgendwas speziell erhöht oder angepasst, damit die Verbindung robuster wird?
Gibt hier echt zwei drei Anschlüsse, die über Fastd passabel funktionieren und mit L2TP unbrauchbar sein.
Öh, bestimmte Marken von DSL-Modems? An sich sehe ich jetzt nichts, was fastd und L2TP von außen gesehen unterscheidet. fastd hat auch keine besonderen Mechanismen zur Fehlerkorrektur etc. Mit welcher fastd-Method ist das?
also die Situation ist so. Sagen wir eine DSL-Leitung verliert 3% der Pakete, was man auf einem mtr deutlich sieht.
Dann funktioniert fastd noch relativ normal mit 5-7 Mbit/s, L2TP krüppelt aber mit unter einem Mbit oder die Verbindung reißt so oft ab, das surfen gar nicht mehr möglich ist.
Fastd steht ganz normal auf salsa2012+umac. Ich sehe halt den Unterschied auch nicht, aber er ist ganz deutlich spürbar, wenn man so einen Fall hat, reproduzierbar an mehreren Stellen so erlebt.
Mit dem Hersteller des Modems hat das erstmal nichts zu tun, die Pakete werden bei allen Verbindungen verloren. Auch bei einem mtr auf die öffentliche IP des Anschlusses. Aber Speedtest.net zeigt trotzdem quasi die volle Bandbreite und Fastd arbeitet auch gut. Nur halt L2TP ist nicht nutzbar.
Das ist der Person dann oft schwer vermittelbar, wenn für sie alles normal aussieht, weil nicht verstanden wird, was Paketverluste sind.
Kann ich hier bestätigen.
Auf wackeligen Leitungen sollte man bei Fastd bleiben.
Ich unterstellte bislang, dass da noch eine Fehlersicherungsschicht (CRC-Prüfung bei der Kompression) greift und daher weniger Junk-UDP durch geleitet wird.
Ich muss vorausschicken, dass es reine Spekulation ist und ich mir das noch nicht per tcpdump angeschaut habe.
Ich vermute, dass L2TP beschädigte Pakete nicht aufgrund von Prüfsummen etc. zurückweist und defekte Pakete dann den Batman mehr belasten als wenn ein FastD im rahmen der Verschlüsselung/Kompression die fehlerhaften bereits intern verwirft und nicht bis zum Batman durchleitet.
Warum dann aber Batman den einen Paketverlust anders handhabt als den anderen: Keine Ahnung.
Zumal es ja nicht um Interfaces „nahe der Saturation“ geht, wo man es eventuell noch mit „gesparter Resourcen auf einem shared medium“ erklären könnte.
Interessante Theorie, definitiv eine Überprüfung wert.
Aber dagegen spricht die Beobachtung in der Tunneldigger-Logdatei, dass der Tunnel die ganze Zeit aufgebaut wird und wieder abreißt. Wenn es ein Batmanproblem wäre, müsste doch der Tunnel an sich stabil sein. Bei den richtig schlechten DSL-Leitungen fragt der Tunneldigger im Minutentakt abwechselnd an beiden Gateways an.
Ich glaube, dass die Kontrollverbindung irgendwie abreißt und dann der Tunnel abgeschaltet wird. Ich glaube, dass man die robuster machen müsste.
Dann wäre es eventuell sinnvoller, den Tunnel trotz der Paketverluste stehen zu lassen. Denn der Reconnect bringt ja offensichtlich wenig (nix), und während der Reconnect-Zeiten bricht dann alle weg.
Wie schnell flappt das denn?
Kompression macht fastd zwar nicht, aber die Verschlüsselung und Integritätsprüfung der Pakete könnte in der Tat einen Einfluss auf das Problem haben. 2 Dinge fallen mir ein, die potentiell eine Auswirkung haben könnten:
fastd verwirft doppelte und extrem start reorderte Pakete (um mehr als 64 Sequenznummern), ich weiß nicht, wie das mit L2TP ist? Gibt es da auch Sequenznummern? Werden Reordering und Duplikate erkannt, wenn ja, wie behandelt? Ich habe schon DSL-Anschlüsse gesehen, bei denen der ISP für UDP absolut keine sinnvollen Flows definiert hat und jedes Paket intern anders geroutet wird, was zu ständigem Reordering führt
Es gibt einige extrem kaputte DSL-Modems, die nicht nur im Header, sondern auch im Payload alles, was nach bekannten IP-Adressen aussieht, NATen. Unverschlüsselte Tunnel kann man da drüber vergessen.
Man könnte mal vergleichen mit anderen fastd-Methods:
„null“: Keine Verschlüsselung, keine Integritätsprüfung, keine Erkennung von Reordering & Duplikaten
„null+cipher-test“: Keine Verschlüsselung, keine Integritätsprüfung, aber Erkennung von Reordering & Duplikaten
„null+salsa2012+umac“: Keine Verschlüsselung, aber Integritätsprüfung, Erkennung von Reordering & Duplikaten
(für cipher-test muss die Methode mit CONFIG_FASTD_ENABLE_METHOD_CIPHER_TEST=y in der include/config von Gluon aktiviert werden)
Wenn man den Log-Level von fastd auf ‚debug2‘ stellt, bekommt man auch ne Menge Ausgaben über Reordering und Duplikate, wenn vorhanden.
Was mir hier in dem Thread eindeutig fehlt, ist eine Betrachtung der zugrunde liegenden Paketgroessen der UDP Pakete des Tunnels und damit der resultierenden Fragmentanzahl.
Ich kenne diese Protokolle bisher so gut wie gar nicht, aber wenn zB aus irgendeinem bloeden Grund im Testumfeld L2TP gerade immer ein Byte zu gross wird (das ist auch der Testpayload dann ggf geschuldet), dann geht jeweils 1 Fragment mehr auf die Reise und ist moegliches Verlustopfer. Also pro Tunnelpaket hat man dann doppelte Verlustrate. Je mehr Fragmente man hat pro Paket, so geringer wird dann der Unterschied. Bei 1 und 2 ist es dann halt immer besonders heftig.
DAS ist dann in erster Linie der Schlag ins Kontor denke ich mal. Alles andere sind dann noch Folgekosten. Wenn die Ltg echt schlecht ist, dann moechte man uU dann doch MTUs so anpassen, dass sich die Fragmentanzahl im Mittel minimiert. Da muesste man sich dann vermutlich auch noch das Spektrum der Nutzlasten anschauen.
War 3% Verluste bei DSL eigentlich schon ein uebel gewaehltes Bsp oder ist das gaengige Praxis ? Hoert sich ethernetmaessig bereits deutlich an der Grenze der Verkraftbarkeit an. Ist bei P2P aber evtl nicht ganz so tragisch. Habe das nie betrachtet.
Bei der Fritzbox kann man ja wunderschoen bequem tracen. Sollte man bei so einem Vergleich sicher mal machen.
mit einem wdr3600 komme ich auf 160+mbit up und down
bei 190 Mbit ist das Gateway am ende
bei einem 841 v9 kam ich auf ca. 90 mbit relativ schwankend :-/
(Alle Tests kabelgebunden)
Läuft sehr Gut durch Batman fragmentiert es ja mind 1 mal von daher ist die garantierte Bandbreite durch 2 voll ausgenutzt.
DFN ohne Probleme, Rhön Energie geht auch super, bei Unitymedia gibts beim ersten verbindungsaufbau mit dem broker immer mal Fehler im log.
Da aber meist Batman Compat 15 verwendet wird, wären es 32 Bytes von Batman die dazu kommen:
1332 + 32 = 1364
Die 32 bytes von Batman beinhalten schon einen enkapsulierten Ethernet-Frame, demnach kommen nicht noch mal 14 Bytes drauf. Bei Batman Compat 14 sind es quasi 4 Bytes die zu übrig bleiben.
Fyi: Die 4 zusätzlichen Bytes bei Compat 15 kommen vom TVLV Header.
Ich sehe jetzt nicht so richtig, was das alles mit diesem Thread zu tun hat… das ist eher „was mit Batman“ und ein L2TP Fastd Vergleich wohl eher nicht.
L2TP hat keine Fehlerkorrektur
So kann bei hoher Fragmentierung und defekten Paketen die Datenrate in den Keller gehen.
Optimal ist denke ich mal 2 Fragmente (Optimal wäre natürlich keine Fragmente geht halt technisch nicht überall)
Wenn die Client MTU zu hoch ist kann es sein das aus einem Paket insgesamt 3 Fragmente werden
So ist die maximale Bandbreite dann nur noch 1/3 und die Wahrscheinlichkeit das bei einem defekten Paket alle 3 Pakete neu übertragen werden müssen erhöht sich um 50%.
Und dann muss man immer noch Glück haben das das Endgerät die übermittelte MTU nutzt → mein Macbook interessiert die nämlich die Bohne (zumindest über Wlan)
Ich weiß nicht, ob das was damit zu tun hat, aber hat eigentlich echt niemand außer uns das Problem, dass Freifunk mit L2TP-VPN-Verbindungen nicht an Fritzboxen des Typs 7270/7170 funktioniert?
