Wie schon berichtet, geht die Erneuerung der Infrastruktur inkl. Änderungen an der Firmware weiter.

Mit dem nächsten Schritt werden wir dem »fastd«-Protokoll den Rücken kehren und auf L2TP als Tunnel-Lösung umstellen. Hierzu gibt dieser Beitrag ein paar Hinter­grund­in­for­mationen.

Vorteile:

  • Höherer Datendurchsatz auch bei kleinen Routern:
    Da L2TP ein Protokoll ist, welches direkt durch den Linux-Kernel unterstützt wird, gibt es weniger sogenannte Contextswitches zwischen Kernel- und Userspace. Dies führt zu einem erheblichen Durchsatzzuwachs. Mit dem veralteten, aber auch weit verbreiteten, Router TP-Link WR841N sind Geschwindigkeiten bis zu 30 Mbit/s möglich; mit größeren Modellen deutlich mehr (sofern es lokaler Internetzugang und die Infrastruktur in unserem Backend erlauben).
     
  • Entlastung der Gateways:
    In geringerem Umfang, aber prinzipiell genauso, profitieren auch unsere Gateways von der niedrigeren Last durch den Wechsel auf L2TP. Theoretisch stehen auch bei stärkerer Nutzung unseres Netzwerkes nun mehr Resourcen zur Verfügung — wir werden sehen, wie das in der Praxis sich zeigt.

Nachteile:

  • IPv4-only:
    Die eingesetzte Lösung, die die L2TP-Tunnel zwischen Gateways und Knoten aushanelt, kann derzeit Tunnel nur über das veraltete Protokoll IPv4 aufbauen. Insbesondere an Kabelanschlüssen mit »DS-Lite«, also ohne »echte« IPv4-Adresse und providerseitigem Tunneling von IPv4 über IPv6, kann sich dies als Nachteil erweisen (MTU, Durchsatz).

Die entsprechende Firmware und die dazugehörigen neuen Gateways sind derzeit im Alpha-Test. Aus technischen Gründen (Wechsel auch der Batman-Version) können alte und neue Firmware nicht koexistieren — die Test-Firmware spannt daher die SSID »l2tp.Kreis­GT.frei­funk.net« (und »l2tp.mue­ritz.frei­funk.net« sowie »l2tp.feld­berg.frei­funk.net«) auf, was zu einer kurz­zeitig gefühlt schlechteren Abdeckung führen wird.

Umstellung auf L2TP

Bisherige Kommentare

  1. wusel says:

    FTR, dieser Beitrag kommt über einen Knoten im ‘zzz’-Mesh (außerhalb unseres normalen ‘Versorgungsgebietes’) über L2TP (und das hinter einem Mobilfunkrouter). DNSv6 auf dem Frankfurter Gateway war noch borked, das ist nun aber auch behoben … Anbindung an Kartenserver fehlt allerdings noch :slight_smile:

  2. Das war mir schon klar. Ging mir nur darum, es zusagen, so das es nicht in vergessenheit Gerät, falls es aus welchen Gründen auch immer wie beim letzten mal nur ein kleines Teil des Testnetzes betrifft.

    (Ich habe den Rest auch gelesen, allerdings nicht direkt mit bekommen, da meine beiden Orte wo ich täglich bin aktuell komplett über L2TP laufen.)

  3. wusel says:

    Should be fixed — der isc-dhcpd lief auf l2tp-ham01 schlicht nicht (mehr) :frowning:

    3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1280 qdisc mq state UP group default qlen 1000
        link/ether 00:24:d7:26:94:e4 brd ff:ff:ff:ff:ff:ff
        inet 10.234.137.155/20 brd 10.234.143.255 scope global dynamic wlp2s0
           valid_lft 3600sec preferred_lft 3600sec
        inet6 2001:bf7:1310:128:224:d7ff:fe26:94e4/64 scope global noprefixroute dynamic 
           valid_lft 86391sec preferred_lft 14391sec
        inet6 fe80::224:d7ff:fe26:94e4/64 scope link 
           valid_lft forever preferred_lft forever
  4. wusel says:

    In der Tat, die NAT-Regel fehlte wieder — WTF?!

    root@l2tp-ham01 ~ # traceroute -s 10.234.144.2 v6.de
    traceroute to v6.de (195.30.8.34), 30 hops max, 60 byte packets
     1  * * *
     2  * * *
     3  * * *
     4  * * *
     5  * * *
     6  * * *
     7  * * *
    …
    root@l2tp-ham01 ~ # iptables -L -n -t nat
    …
    SNAT       all  --  0.0.0.0/0            0.0.0.0/0            to:192.251.226.214
    
    …
    root@l2tp-ham01 ~ # iptables -A POSTROUTING -t nat -s 10.0.0.0/8 -o ens3 -j SNAT --to-source 192.251.226.214
    root@l2tp-ham01 ~ # traceroute -s 10.234.144.2 v6.de
    traceroute to v6.de (195.30.8.34), 30 hops max, 60 byte packets
     1  bgp-ham02.4830.org (193.26.120.85)  0.285 ms  0.254 ms  0.233 ms
     2  decix-ham.ham.de.tnib.net (80.81.203.3)  8.212 ms  8.215 ms  8.200 ms
     3  ae5-0.cr0.muc.de.tnib.net (81.92.175.13)  13.355 ms  13.301 ms  13.300 ms
     4  m33-ten0-0-0-2.space.net (81.92.174.134)  15.627 ms  15.855 ms  15.912 ms
     5  m32-te0-0-1-3.space.net (185.54.120.68)  15.492 ms  15.398 ms  15.555 ms
     6  cisco-m-ii-te1-2-v25.space.net (185.54.120.58)  15.228 ms  15.136 ms  14.995 ms
     7  v4only.v6.de (195.30.8.34)  15.562 ms  15.847 ms  15.807 ms
    

    Das muß ich mal genauer beobachten …

Weitere Diskussion über diesen Beitrag bitte im Forum forum.freifunk-kreisgt.de

31 more replies

Diskussionsteilnehmer