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

Technik
12

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.

4 „Gefällt mir“
13

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.

1 „Gefällt mir“
14

Ich verteile per dhcp
option interface-mtu 1332;

und im broker benutze 1364

Läuft auf einer Dedibox

mit einem wdr3600 komme ich auf 160+mbit up und down
bei 190 Mbit ist das Gateway am ende :wink:
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.

15

1332 + 28 (batman inkl. 14 bit ethernet header)

16

Der erste Ethernet Frame ist zu viel, L2TP hat schon einen Ethernet Frame in der Berechnung:

L2TPv3 via UDP:
20 bytes (IP header)
8 bytes (UDP header)
4 bytes (L2TPv3 Session ID)
4 bytes (L2TPv3 Cookie)
4 bytes (L2TPv3 Pseudowire CE)
14 bytes (Ethernet)
Overhead: 54 Bytes

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.

Gruß
Cyrus

2 „Gefällt mir“
17

Besten dank für die ausführliche Validierung

Ja benutze Batman Compat 15
einfach ubuntu drauf alles per apt nachinstalliert was man so braucht und läuft.

18

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.

19

Es geht um Paketverluste

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) :wink:

20

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?

Querlink: L2TP / Tunneldigger funktionieren nicht an einer FB 7270 - #11 von MPW

Die Diskussion dazu sollte eigentlich im anderen Thema stattfinden, aber manchmal hab ich das Gefühl, dass L2TP einfach ein bisschen wackelig ist.

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“