Die Telekom hilft Community zieht um und ist bis zum 8. Januar 2025 nur eingeschränkt zugänglich.
Höherer Wireguard Durchsatz bei niedrigerer MTU?
vor 6 Monaten
Hallo zusammen,
der Logik nach senkt eine höhere MTU die Anzahl zu behandelnder Pakete und sorgt für mehr Durchsatz. Eine niedrigere MTU müsste den Durchsatz eigentlich senken, statt diesen zu steigern.
Wird eine Wireguard Standard Tunnel MTU von 1420 verwendet, liegt der Durchsatz bei ~10-11 MB/s, also bei ca. 100 Mbit/s.
Nun handelt es sich um einen Fiber Giga Anschluss und 1-10 Gigabit/s Gegenstellen in Rechenzentren, die gut angebunden und nicht immer gleich ausgelastet sind. D.h. für Tests stehen genug freie Ressourcen bereit.
Mehrere andere MTU Werte ergaben keine sonderlich großen Unterschiede. Wird die Wireguard Tunnel MTU jedoch auf 1280 geändert, steigt der Durchsatz auf ca. 70 MB/s oder mehr.
Kann jemand erklären, worin dieses Verhalten begründet ist oder wie die Ursache dafür gefunden werden kann? Für ein bisschen Input wäre ich wirklich dankbar.
Wo auch immer Ihr seid, habt einen schönen Tag. 🙂
Viele Grüße
GigaFiberOhneGigaSpeed
688
30
Das könnte Ihnen auch weiterhelfen
vor 3 Jahren
1207
0
3
709
0
1
vor 4 Jahren
404
0
2
Community Guide
vor 6 Monaten
Recht simpel !ist die MTU zu hoch, denn werden Pakete fragmentiert , statt eines, werden dann zwei übertragen und müssen im Ziel,wieder zusammengefügt werden.
7
Antwort
von
vor 6 Monaten
dazu habe doch nicht geschrieben, sondern nur das Fragmentierungen zu einem geringeren Durchsatz führen.
Und das ist logisch. Welches die optimale MTU für wireguard steht auf einem anderen Blatt.
Entscheiden ist ja auch die Beste MTU für den gesamten Path
Wer es genau wissen will lässt es mal über Wireshark laufen
Community Guide
vor 6 Monaten
ich habe ganz viele Links dazu mit Erklärungen:
https://schroederdennis.de/vpn/wireguard-mtu-size-1420-1412-best-practices-ipv4-ipv6-mtu-berechnen/
https://www.lalber.org/2020/02/quicktipp-wireguard-langsam-mtu-einstellen/
https://forum.opnsense.org/index.php?topic=35877.0
0
5 Sterne Mitgestalter*in
vor 6 Monaten
Wer macht denn hier die Verbindung? Nicht das Rechenpower hier der Flaschenhals ist.
Zudem braucht Wireguard auch nochmal selbst eigenes Overhead auf die Pakete.
Kann man doch sich einfach anschauen ob die Pakete durch Tunnel fragmentiert werden müssen.
0
5 Sterne Mitglied
vor 6 Monaten
Z. B. Peering in andere Netze ist ein Grund.
In Videospielkonsolen, z. B. Nintendo Switch, steht sie ab Werk auf einem Wert unter <1492 für Online Gaming. Xbox One und Series glaube ich auch.
Dann bei IPv6 Netzen kann es sein, dass die MTU 1280 beträgt beim Peering . Z. B. müssen die 1492 Bytes dann fragmentiert werden bei der Übergabe auf 1280.
Und manche Videospieleratgeber empfehlen eine MTU von 1200 einzustellen im Router zum Internet.
Die Frage ist nur, stelle ich sie im Client ein von z. B. LAN MTU 1400 und defragmentiert sie dann der Router vielleicht wieder auf 1492 und dort lahmts oder umgekehrt das Gleiche, von LAN 1500 auf 1492 oder weniger?
So jetzt wird die Sache noch lustiger, weil manche Router können PPPoE Jumbo Frames, d. h. vom LAN mit MTU 1500 Bytes (Manche LAN Hardware kann Jumbo Frames mit MTU bis 10000 usw. Bytes.) auf Point to Point Protocol over Ethernet mit MTU 1508 Byte (8 Bytes sind für PPPoE.) über Glasfaser, DSL oder Kabel.
Das wäre das Optimum, weil MTU 1500 ist LAN Standard, geht direkt über PPPoE ohne fragmentierung und den sollte jede Ethernet Hardware fressen und hardwarebeschleunigt in grössere Jumbo Frames verarbeiten können und visa vi.
An alter Hardware wird es scheitern bei manchen Netzbetreibern. Deshalb, lass die MTU Einstellungen auf Standard des jeweiligen Gerätes und die im Router auf die des Providers, Telekom MTU 1492 oder was der Routerhersteller für Telekom verwendet. (Praktisch gehen auch PPPoE MTU Werte unter 1492 bei der DTAG . Finger weg davon, selbst wenn es in einem Fachartikel steht!)
Das hängt so extrem vom Routing ab national, international, also sinnlos darin/daran herum zu stellen! Lieber einen guten Router mit Hardwarebeschleunigung dafür her nehmen, der das automatisch macht.
0
4 Sterne Mitglied
vor 6 Monaten
Erstmal Vielen Dank an alle, die sich hier beteiligen.
Gemessen wird der Durchsatz mit HTTPS Downloads verschiedener Server, 1-3 Downloads von schnellen Servern. Angabe des Browsers zur Downloadrate wie auch Interfaceübersicht/Netzwerkauslastung im Taskmanager unter Linux. Die MTU wird mit 'traceroute --mtu dnsname.beliebiger.gegenstelle' geprüft sowie beim Aktivieren des Tunnelinterfaces via Terminal validiert.
Genau das ist das Logikproblem, vor dem ich stehe. Trotz Anpassung der Tunnel MTU auf 1412 an die Telekom PPPoE MTU von 1492, sinkt der Durchsatz sehr stark ab.
Hinzu kommt, dass Verbindungen ohne VPN Tunnel mit der Anschluss IP der Telekom bei einer MTU von 1492 (PPPoE) auf Werte 70-112 MB/s kommen. Hier muss dieselbe Umgebung (LAN Default MTU 1500), Hardware, Software die Leistung liefern. Wireguard erzeugt Overhead, aber eine niedrigere MTU müsste den Overhead steigern wodurch der Durchsatz sinken müsste. Es ist jedoch genau anders herum.
Mehrere Online Artikel empfehlen, aufgrund von IPv6 keine kleineren MTU Werte einzusetzen als 1280. Daher wurden keine kleineren MTU Werte getestet.
Meinem Verständnis nach muss das jeder handelsübliche Router tun, wenn ich ohne VPN Tunnel ins Internet gehe. LAN MTU 1500, Telekom PPPoE MTU 1492, erreicht volle Geschwindigkeit trotz Splitting. Eine kleinere MTU steigert die Anzahl der zu behandelnden Pakete, dennoch steigt der Durchsatz. Damit ist auch bewiesen, dass die eingesetzte Hardware 70 MB/s trotz suboptimaler/niedrigerer MTU erreichen kann.
Die Telekom verbindet meine Fritzbox mit einer MTU von 1492 auch bei aktivierter RFC4638 Option im Supportbereich der Fritzbox, siehe dazu DTAG -Fiber- FTTH -Unterstuetzung-von-RFC4638-Jumbo-Frames/m-p/6361250#M2137782" target="_blank">https://telekomhilft.telekom.de/t5/Festnetz-Internet/ DTAG -Fiber- FTTH -Unterstuetzung-von-RFC4638-Jumbo-Frames/m-p/6361250#M2137782 sowie 'traceroute --mtu dnsname.beliebiger.gegenstelle' ohne aktiven VPN Tunnel und einer LAN MTU von 1500. Sobald das Paket das LAN verlässt, ändert sich die MTU auf 1492.
4
Antwort
von
vor 6 Monaten
Die FB setzt meines wissens nach die Frames vom LAN hardwarebeschleunigt wieder zu MTU grossen Frames für die PPPoE Verbindung zusammen.
Was sein kann ist, das wird nirgends öffentlich dokumentiert sein bei AVM, dass die Echtzeitpriorisierung in den Priorisierungseinstellungen die defragmentierung vom LAN zum WAN aussetz.
Wäre auch total logisch, so raus wie sie vom LAN rein kommen, wenn <1492 Bytes, für (Bild-)Telefonie und Echtzeitdaten.
Ich würde versuchsweise mal eine Liste für Wireguard mit den Diensten/Ports anlegen und als Echtzeit eintragen.
4 Sterne Mitglied
vor 6 Monaten
Darüber freue ich mich, Danke. Ich frage beim Anbieter nach, ob ich Dritten eine Konfiguration zukommen lassen darf oder ob dieser mir einen Testaccount zur Verfügung stellt.
Gute Idee, die ich gleich ausprobiert habe. Verbessert bei einer MTU von 1412 mit "Alle Geräte/Alle Protokolle" sowie "Alle Geräte/UDP" nicht den Durchsatz.
1
Antwort
von
vor 6 Monaten
Der VPN Anbieter hat einen Testzugang bereitgestellt und ermöglicht damit Tests durch Dritte. Der Testzugang besteht bis zum 14.07.2024.
@buenniwurden per privater Nachricht Wireguard Profile für Windows, MacOS und Linux bereitgestellt.
4 Sterne Mitglied
vor 6 Monaten
In der Zwischenzeit wurden weitere Tests durchgeführt und das Fehlerbild teils besser eingerenzt.
Verwendet man eine Multi Hop Konfiguration, so besteht die Problematik mit einer MTU von 1412 mit einem Durchsatz von max. 10 MB/s.
Verwendet man keine Multi Hop sondern eine Single Hop Konfiguration, so steigt der Durchsatz auch mit einer MTU von 1412 auf ca. 60 MB/s.
Dieser Sachverhalt wurde dem Anbieter zwecks Rücksprache bereits gemeldet.
Dennoch war in einem kurzen Test der Durchsatz mit einer MTU von 1280 und einer Single Hop Verbindung weiterhin höher, die Verbindung wirkt stabiler.
Viele Grüße
GigaFiberOhneGigaSpeed
8
Antwort
von
vor 6 Monaten
Ich habe mal gegen einen Server getestet mit dem Profil MAC-CH-ZRT-004
Mehr Zeit kann ich diese Woche nicht investieren
ohne Wireguard:
curl https://mirror.kamp.de/ubuntu-releases/24.04/ubuntu-24.04-live-server-amd64.iso -output c:\batch\test.zip
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2627M 100 2627M 0 0 60.5M 0 0:00:43 0:00:43 --:--:-- 60.7M
Mit einer MTU von 1420
curl https://mirror.kamp.de/ubuntu-releases/24.04/ubuntu-24.04-live-server-amd64.iso -output c:\batch\test.zip
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2627M 100 2627M 0 0 15.4M 0 0:02:50 0:02:50 --:--:-- 10.9M
mit einer MTU von 1280:
curl https://mirror.kamp.de/ubuntu-releases/24.04/ubuntu-24.04-live-server-amd64.iso -output c:\batch\test.zip
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2627M 100 2627M 0 0 12.2M 0 0:03:34 0:03:34 --:--:-- 11.6M
Die Unterschiede zwischen MTU 1280 und 1420 dürften reiner Zufall sein.
Außerdem müsste man bei dem Versuch ja auch die MTU auf der Server Seite ändern und nicht nur beim Client .
Der Test ist aber vermutlich nicht aussagekräftig. Zu viele Störeinflüsse spielen eine Rolle.
IPERF 3 im Servermode würde hier besser Ergebnisse bringen.
Community Guide
vor 6 Monaten
Ich komme leider erst nächste Woche zum Test... wenn für Dich @GigaFiberOhneGigaSpeed OK, dann schicke ich @Stefan die Konfigurationsdateien, er ist noch mehr Profi als ich mit VPN /Netzwerken und Co
1
Antwort
von
vor 6 Monaten
Hallo @buenni,
Du darfst die Dateien gerne an Stefan weiterleiten. Der Zugang ist nur bis Sonntag, also Ende dieser KW, gültig.
Viele Grüße
GigaFiberOhneGigaSpeed
4 Sterne Mitglied
vor 6 Monaten
Der VPN Anbieter hat mit eigener Infrasfruktur Tests durchgeführt und der Support kann die Problematik nicht nachvollziehen.
0