l2tp Tester gesucht!

[Dominik Heidler]

Hi,

das Problem ist allerdings, dass der Server im Internet, von dem die Daten heruntergeladen werden,
die normalen 1500 als MTU hat. Es funktioniert also nur vom Client zum InternetServer.
Dennoch könnte es evtl den Upload ein kleines bisschen entlasten.

+------------+  Ethernet  +---------+  BATMAN via L2TPv3 via DSL  +--------+  W-LAN  +--------+
| InetServer |------------| Gateway |-----------------------------| Router |---------| Client |
+------------+    1500    +---------+             1410            +--------+   1410  +--------+


BATMAN Overhead: 28
L2TPv3 Overhead: 54
DSL: 1492


Der Server sendet also ein Ethernet Paket mit 1500 Byte Payload.
Auf dem Gateway wird es dann in 2 Pakete fragmentiert, die dann erst
auf dem Client wieder reassembled werden.
BTW: Nur der Empfänger kann reassemblen.

In die Upload Richtung schickt der Client seine Daten in kleineren Paketen.
Dadurch kann er die Upload Bandbreite ein wenig effizienter nutzen.

Grüße,
Dominik

Am 07.03.2016 um 23:51 schrieb Robert Langhammer:
> Hallo Cristian,
> 
> die Idee kommt einem als erstes-  Internet 1500 - l2tp - batman - xxxx
> =  Client mtu.
> 
> Man muss also die MTU der Clients umstellen. Da gibt es auch eine DHCP
> option interface-mtu xyz
> Ich glaube aber nicht, dass alle Clients diese Option verarbeiten. Hat
> da schon jemand Erfahrungen damit gemacht?
> Robert
> 
> Am 07.03.2016 um 23:35 schrieb Christian Dresel:
>> Guten Abend
>>
>> Ich dachte bisher eigentlich, dass sich das MTU Problem nicht lösen
>> lässt, aber diese Mail brachte mich auf eine Idee die ich mal
>> "ansprechen" möchte, vielleicht ist die Antwort darauf auch nur, geht
>> nicht weil wegen weiß Gott...
>>
>> Am 07.03.2016 um 13:52 schrieb Robert Langhammer:
>>> Hallo Dominik,
>>>
>>> da warst du jetzt schneller als ich.
>>>
>>> In der default Configuration macht der tunneldigger / broker 1500 - 54 =
>>> 1446.
>>> Ist es sinnvoll die 8Byte für Adsl noch weg zu nehmen. Im LAN, wo der
>>> Router dranhängt haben wir die üblichen 1500 und Über Kabel sind es auch
>>> 1500.
>>>
>>> So wie ich das verstanden habe, wird immer fragmentiert, da die
>>> Wlan-Clients und unser w2ap eine 1500 mtu haben. Dann kommt batman dazu
>>> und wir bräuchten >1500 aber durchs Internet geht nicht mehr.
>> warum muss w2ap denn 1500 haben? Wenn w2ap (angenommen) 1350 hat und
>> Batman seine 28 Bytes (glaub ich) drauf packt, sind wir in dem Bereich
>> was tunneldigger durchjagen kann und müssen hier nicht fragmentieren.
>> Man kanns jetzt noch exakt ausrechnen, das hier ist nurn Beispiel.
>>
>> Überseh ich irgendwas?
>>
>> mfg
>>
>> Christian
>>
>>> Bin ich da richtig?
>>>
>>>
>>> Bremst das Fragmentieren spürbar?
>>>
>>>
>>> Am 07.03.2016 um 13:34 schrieb Dominik Heidler:
>>>> Hi,
>>>>
>>>> ich habe es gefunden:
>>>>
>>>> https://github.com/wlanslovenija/tunneldigger/blob/master/client/l2tp_client.c#L63
>>>>> // L2TP data header overhead for calculating tunnel MTU; takes
>>>>> // the following headers into account:
>>>>> //
>>>>> //   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)
>>>>> //
>>>>> #define L2TP_TUN_OVERHEAD 54
>>>> Das bedeutet, dass L2TPv3 1 Byte *mehr* overhead hat, als FastD.
>>>> Allerdings fahren wir fastd aktuell mit einer unnütig niedrigen MTU (1492-(52+14)=1426).
>>>> Da wir keine Verschlüsselung verwenden, könnten wir fastd theoretisch mit einer MTU von
>>>> 1439 laufen lassen.
>>>> Aber so, wie es aktuell läuft, beträgt der fastd overhead 66 statt 53 byte.
>>>>
>>>> Somit bringt uns der Wechsel eine Verbesserung um 12 byte.
>>>>
>>>> Grüße,
>>>> Dominik
>>
>>
>>
> 
> 
> 
>