Hi.
War nicht mal im Gespräch, das Verfahren zum Aufbau des VPN Tunnels zu ändern, damit sich die allgemeine CPU Auslastung der Knoten verbessert, und die Knoten mehr Leistung erhalten?
Wie ist denn da der Stand der Dinge?
1 „Gefällt mir“
Ist aktuell für Q3 in Planung. Leider müssen wir dafür einiges umbauen und aktuell beobachten wir auch noch die direkte Integration in Gluon. Aktuell müsste es ja auf eigene Faust integriert werden.
Von daher, es wird so bald wie möglich kommen wenn es technisch und zeitlich passt.
2 „Gefällt mir“
Es wäre natürlich gut, wenn bis dahin auch das Problem mit RAM/Load bei mehr als 3000 Einträgen in der TG gelöst wäre … dann wäre das sicher ein riesen Schub für die Performance und Stabilität!
1 „Gefällt mir“
Auch wenn dieser Thread schon etwas älter ist, scheint er doch für diese Infos passend zu sein:
Der aktuelle Stand ist, dass L2TP (wenn es überhaupt kommt) wahrscheinlich frühestens nächstes Jahr kommt. Aktuell sprechen z.B. folgende Punkte dagegen:
- Bei L2TP kann man auf Serverseite nicht so einfach Knoten rausschmeißen, die falsch parametriert sind und das Netz stören/lahm legen
- In manchen DS-Lite- oder Double-NAT-Szenarien hat L2TP angeblich Probleme (Referenz?)
- Kein IPv6-Support (in Tunneldigger, der aktuell erfolgversprechendsten Implementierung)
- Codequalität und Maintenance-Status von L2TP sind problematisch. Änderungen müssen im Wesentlichen über die Linux-Kernel-Entwickler laufen, statt sonst über gluon.
- der Geschwindigkeitszuwachs wird selten benötigt, und wenn doch, gibt es mit dem Offloader eine Alternative.
Das ist erstmal nur eine wertfreie Auflistung der Punkte, die ich gerade gehört habe.
Hier gibts weitere Details:
Das sind viele Kröten…
Und wir haben ja auch gestern drüber gesprochen, dass das dann eigentlich nicht so sinnvoll ist. Die geschwindigkeit wird in der Regel eher durch WLAN-Probleme/Mesh runter gedrückt und da hilft dann auch L2TP oder ein offloader nicht.
Also mit den ganzen - für mich neuen - Informationen bin ich sogar eher dagegen das einzuführen.
1 „Gefällt mir“
Soweit ich sehen kann, ist L2TP aka. Tunneldigger jetzt in gluon drin.
Würde mich freuen, wenn es an dieser Baustelle weiter ginge, weil ich dann zu Hause ohne stromfressenden Offloader und ohne 3x Grundrauschen trotzdem nahezu Wirespeed bekommen würde.
Tut uns leid. Wir haben uns erst am Wochenende beim Freifunk Hessen Treffen in Darmstadt darüber unterhalten und sind weiterhin alle der Meinung, dass die Nachteile dieser Lösung, wie zum Beispiel kein IPv6, Probleme mit Paketverlust und vieles weitere noch immer gegen einen Einsatz von L2TP sprechen. Ein viel Größeres Problem als der Speed des VPN sind aktuell weiterhin die vielen 841er die es in unserem Netz gibt und die einfach zu wenig Leistung haben.
Das heißt aber nicht, dass wir die L2TP Lösung nicht im Auge behalten. Wir wägen aktuell hauptsächlich zwischen Stabilität und dem einzigen Argument für L2TP, nämlich der höheren Geschwindigkeit ab.
Gibt es einen bestimmten Grund, warum du bei dir zuhause Wirespeed brauchst? (Reines Interesse)
Also das IPv6 nicht unterstützt wird, ist natürlich uncool, aber für ca. 6-8x mehr Performance würde ich darauf gerne verzichten. IPv4 hat ja auf absehbare Zeit eh noch jeder. Und mit Paketverlusten habe ich bei Telekom-Vectoring aktuell überhaupt keine Probleme (da kann ich von Unitymedia letztes Jahr allerdings auch ganz anderes berichten).
Was mich aktuell ein wenig stört, ist dass meine drei 841er nur 10% meiner Anschlussgeschwindigkeit nutzen können, dafür aber (weil jeder einen Uplink hat) über 3 GB pro Tag sinnlosen Traffic erzeugen. Mit L2TP würde ein Uplink reichen, die anderen könnten per LAN meshen (würde also auch die Gateways entlasten).
Dass ich wirklich Wirespeed brauche ist natürlich selten, ich achte im Moment halt immer darauf, dass ich beim Daten übertragen im Privaten WLAN bin und nicht im Freifunk. Wenn man aber in manchen Geschäften oder Kneipen Freifunk anbietet, und es ist sehr viel langsamer als ohne WLAN (LTE), braucht es halt noch mehr Aufklärungsarbeit als eigentlich nötig.
Was spräche denn dagegen, L2TP und fastd alternativ in der Firmware anzubieten? Man müsste doch nur noch die L2TP Gegenstellen auf den Gateways einrichten, vom Routing her wäre wahrscheinlich nicht viel zu tun (kann sein dass ich mich da gewaltig täusche).
Alternativ werde ich doch nochmal die Offloader-in-VMware-Option testen, und die 841er mit LEDE und VLANs für Privat/Freifunk laufen lassen.
Gibt es irgendwo Messungen oder belastbare Daten zu den Performance-Problemen bei Paket Loss von L2TP vs. fastd?
Das große Problem ist, dass wir keine Insellösung betreiben wollen. Wenn wir L2TP als Option anbieten, dann für alle.
Das sehe ich, ebenfalls als Telekom Kunde, anders. Paketverluste treten häufig zur „Prime-Time“ auf, wenn auch marginal und unter 1%.
Die 841er sollten auch so weit wie möglich vermieden werden. Durch die geringe Ausstattung von 4MB Flash und 32MB RAM kommen die Geräte regelmäßig an Grenzen, das wird auch mit L2TP nicht besser werden, da dies ja weiteren Speicherplatz benötigt. Langfristig sollten 841er komplett ersetzt werden.
Wenn verschlüsseltes WLAN verfügbar und bekannt ist, sollte dies auch immer Freifunk vorgezogen werden. Das kommunizieren wir sehr offen und häufig.
Geschäfte und Kneipen haben einen anderen Use-Case. Hier sollte erst recht auf 841er verzichtet werden und, je nach Größe, eventuell auf Offloader plus Ubiquiti Hardware gesetzt werden.
Das würde bedeuten wir müssen 2 Firmwares für jede Version releasen und maintainen. Das ist ein Mehraufwand von über 100%. Außerdem werden perspektivisch 80% der Freifunker auf L2TP wechseln wollen wegen der vermeindlich besseren Performance.
Der Aufwand auf den Gateways ist zwar überschaubar, wir haben aber noch keine Erfahrungen mit den Wechselwirkungen die so ein Setup mit sich bringt. (fastd und L2TP auf einer Netzwerkbrücke) Das Risiko für einen Komplettausfall ist deshalb zurzeit zu groß.
Das ist zurzeit die beste Lösung für deinen Fall.
Meine Erfahrung hat gezeigt, dass L2TP bei allem über 0,2% Paket Loss nicht mehr nutzbar ist (<2 Mbit/s Durchsatz). Dagegen funktionierte Fastd noch relativ stabil, auch bei instabilen Verbindungen.
Auf dem Freifunk Hessen Treffen wurden noch einige andere Alternativen zu Fastd besprochen die wir in Betracht ziehen sollten. Als Beispiel wäre die Umstellung auf Babel mit z.B. Wireguard VPN. Wir müssen alle Lösungen allerdings für unsere Ansprüche adaptieren und eingehend testen.
Das wird aber noch einige Releases dauern.
Als erstes steht bei uns der Wechsel zu LEDE auf dem Plan, wodurch sich auch schon einige Dinge ändern werden.
1 „Gefällt mir“
Klar ist ein 841er nichts für eine Kneipe. Aber bei 30-50 Sitzplätzen wäre man mit einem oder zwei 1043er mit L2TP wahrscheinlich fertig, bei minimalem Stromverbrauch, Verkabelungsaufwand und Anschaffungskosten. Das wäre mit Offloader + Ubiquity schon deutlich anders.
Für mich sah das in gluon so aus, als könnte man das mit einer Firmware erschlagen (wenn der Flash groß genug ist). Wäre beim 4MB Modell aber wahrscheinlich nicht der Fall, da hast Du recht.
Hatte jemand mal die Idee, fastd im Kernel zu implementieren? Damit wären wahrscheinlich alle Probleme behoben. Für BSD gibt es da sogar was. Nicht dass ich es mir zutrauen würde, aber so komplex ist fastd ja eigentlich nicht.
Ein 1043 schafft heute schon 20-30 Mbit/s über Fastd.
Leider nein, sonst würde der Knoten ja Fastd und L2TP gleichzeitig aufbauen. Gluon bietet nur jetzt beides an für den Firmware Build, sollte aber exclusiv gebaut werden.
Der Quellcode ist offen, wenn du den Drang hast das zu bauen, Feel Free ;-)