Deutsche Glasfaser wird der Upload gedrosselt???

    Hallo Zusammen,

    ich bin bisher immer stiller Mitleser gewesen und schreibe heute meinen ersten Betrag. Ich hoffe ich habe die richtige Kategorie ausgewählt. ;)

    Mein Thema ist recht speziell und ich bin mit nicht sicher ob ich eine abschließende Antwort erhalte. Ich würde mich allerdings freue wenn ich ein paar Hinweis zu meinen bisherigen Tests bzw. eine Einschätzung von Euch bekomme.

    Als erste ich habe einen Anschluss der Deutschen Glasfaser mit 400 MBits Download und 200 MBits Upload.

    Wenn ich mir die gängigen Speedtests anschaue bekomme ich die versprochene Leistung auch!

    Soweit alles super!

    Nun zum meinem Problem bzw. meinem Fehlerbild.

    Ich habe eine VPN Verbindung zu meinen Eltern aufgebaut. Diese Verbindung benutzte ich um z.B. ein extern gelagertes Backup auf einem NAS aktuell zu halten.

    Die Verbindung wird über zwei Raspberry PI 4 mittels Wireguard aufgebaut und besteht permanent. Das ganze Konstrukt läuft sehr stabil und ich habe auch keine Probleme mit meinem IPv6-Anschluss und dem IPv4-Anschluss meiner Eltern.

    Somit sieht der gesamte Aufbau so aus:

    Die Theorie sagt nun:

    Schicken meine Eltern Daten dann gehen die mit 40 MBits auf die Reise und nutzen von meinen 400 MBits Downloadrate ca. 10%.

    Schicke ich Daten auf die Reise werden 50% meines Uploads genutzt und bei meinen Eltern 100% der Downloadrate.

    Nun aber zu den Fakten:

    Schicken meine Eltern Daten ist es wie in der Theorie beschrieben:


    Drehe ich die Senderichtung nun um und schicke Daten dann bekomme ich bei meinem Upload nur ca. 40 MBits was nicht dem entspricht was ich erwartet habe.

    Einer meiner ersten Gedanken war die Raspi's sind nicht schnell genug. Aber die Auslastung der beiden Geräte liegt zwischen 10 und 15 % der CPU und unter 1GB beim Speicher. Wenn ich mein NAS Daten über Wireguard oder SSH Daten schicken lasse sehe ich ein identischen Upload verhalten.

    Um nun zu Testen ob es an meinem Anschluss oder meinem Testaufbau liegt habe ich den Port auf dem iperf3 lauscht in der Fritzbox bei meinen Eltern freigegeben und von einem Rechner den iperf-Test wiederholt. Dann erhalte ich den maximalen und erwarteten Upload von 100 MBits!

    Das wäre das Verhalten mit welchem ich über auch über die VPN-Verbindung gerechnet hätte. Das auf der Seite meine Eltern im Download etwas Luft ist liegt daran das dort gerade Fernsehen geschaut wird.

    Nun Frage ich mich ist so etwas bekannt? Drosselt die Deutsche Glasfaser Daten über SSH bzw. VPN um bestimmt Dienste zu limitieren?

    Steht sowas in den AGB's (meiner Meinung nach nicht)? Verstößt das nicht gegen die Netzneutralität?

    So mehr kann ich erstmal nicht berichten. Ich hoffe mit den riesigen Screenshot verschrecke ich niemanden. Ich habe mir aber große Mühe gegeben möglichst alle Informationen in möglichst wenigen Bilder zu zeigen.

    Vorab vielen Dank und viele Grüße

    Isch83

    Wie kommst Du von deinen Messungen auf den Schluss das DG drosselt? Das geben deine Messwerte doch gar nicht her!

    Du stellst lediglich die Bandbreite zwischen deinen beiden Endpunkten fest ohne den Weg dazwischen zu kennen.

    Um eine belastbare Aussage zu treffen müsstest Du zeitgleich jeweils Up- und Downloadrate von den Endpunkten zu einem Endpunkt in dem jeweiligen Providernetz messen, dann zwischen diesen beiden "Providerendpunkten" und diese Messungen mit deinen vergleichen und richtig interpretieren.

    In vielen Foren und nicht nur in diesem wird immer wieder berichtet, das die Interconnection zum/vom Netz der Telekom aus nicht gerade überdimensioniert ist. Wäre das auch in diesem Falle so, dann drosselt nicht DG, sondern DTAG bremst.

    Also ich stelle in den Raum das die Deutsche Glasfaser VPN oder SSH Verbindungen drosselt. Beweisen kann ich es nicht aber es gibt aus meiner Sicht Indizien.

    Ich hab natürlich noch mehr gemessen. Aber um den Eintrag nicht noch komplexer zu machen darauf verzichtet diese zu zeigen.

    Die Leitung meiner Eltern und meine Leitung liefert zu Belieben Zeiten in den gängigen Speedtest inkl. der Breitband Messung der Bundesnetzagentur die versprochene Leistung.

    Wie komme ich nun auf die Drosselung:

    1. mein Upload wird ziemlich sauber bei 40MBits Upload angeschnitten. Selbst bei einer längeren iperf3 Messung gibt es keine Ausreißer nach oben oder unten von diesen 40MBits. Aus meiner Sicht müsste es Schwankungen geben wenn die Kapazität zwischen irgendwelchen Netzteilen existieren würde.

    2. Im letzten Screenshot sieht man das wenn ich ohne VPN/SSH direkt einen iperf-Test durchführe mehr Upload möglich ist auf nur 40MBits.

    Zwischen allen meinen Messungen haben nur wenige Sekunden oder Minuten beim erstellen meines Eröffnungspost gelegen.

    Ich werde aber auch noch weiter testen. Um die Theorie der Netzverbindung zwischen DG und DTAG zu überprüfen werde ich in den nächsten Tagen mal meine Nachbarn besuchen. Die sind auch bei DG und haben wie wir 400/200Mbits. Somit müsste ich dort dann von DG zu DG prüfen könne wie sich das verhält.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    Du könntest ggf. die iperf3 Messung auf Port 22 durchführen (Parameteränderung in iperf3), wenn es eine stumpfe portbasierte Drosselung gäbe, dann wäre das schon ein Indiz. Wenn es allerdings eine applikationsspezifische Drosselung gäbe, dann nutzt der geänderte Port freilich auch nichts.

    Zunächst mal ist festzustellen, dass mindestens zwei Provider beteiligt sind. Nach den bisherigen Daten halte ich es für genauso plausibel, dass der andere Provider die Finger im Spiel hat, wenn es einer von den beiden bewusst herbeiführt.

    Die Testbedingungen sind nicht optimal: Die Fritzbox wird sicherlich versuchen, die Echtzeitdaten vor Paketverlusten zu schützen. Gleichzeitiges Fernsehen oder Telefonieren verbietet sich deshalb eigentlich komplett, während man irgendwelche Bandbreitenmessungen durchführt. Das Traffic Shaping belastet die CPU der Fritzbox und sorgt schon ganz ohne Nebeneffekte für eine Reduzierung der zur Verfügung stehenden Bandbreite deutlich über die tatsächlich von der Echtzeitanwendung genutzte Bandbreite hinaus.

    Die Messung von Protokoll-in-Protokoll ist außerdem schon theoretisch schwierig. Das gilt besonders für TCP-in-TCP (SSH), aber grundsätzlich auch für TCP-in-UDP (Wireguard). Ich würde versuchen, mit UDP-in-UDP die tatsächlich verfügbare Bandbreite abseits von Flow-Control-Algorithmen zu messen. Dabei ist auf MTU-Probleme zu achten.

    Berechtigter und auch richtiger Einwand!

    Hier wurde schon auf die Schwierigkeiten hingewiesen:

    Beitrag

    RE: AON Anschluss - DG Giga - Geschwindigkeitsprobleme bei Single Download

    Wenn ich das alles durch ein VPN durch meinen Hetzner Server schleife und es besser wird, muss es trotzdem nicht unbedingt am Peering liegen.

    Du hast durch den VPN-Overhead eine geringere Paketgröße (MTU), das ändert wieder alles.

    Leider ist der Speed vom/zum Hetznerserver auch sowieso nicht so geil mit TCP-CC auf cubic.

    (Quelltext, 18 Zeilen)

    Ist das ist noch verhältnismäßig gut gerade durch die Uhrzeit.

    Die eingestellte TCP Congestion Control hat auf dem VPN-Server leider auch keinen Einfluss.…
    shavenne
    18. Februar 2022 um 12:17
  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    Guten Morgen Zusammen,

    erst einmal vielen Dank für die Antworten und Ideen.

    Ich Versuche gleiche die Fragen bzw. Themen aufzuteilen und zu beantworten. Ich hoffe es gelingt mir ;)

    Wechsel des Ports auf Port 22 oder einen anderen Port

    Der Wechsel des von ipferf auf Port 22 funktioniert leider nicht so wirklich, da ich einen SSH-Verbindung nutze. Dafür müsste ich erstmal den Port für SSH ändern um dann dort einen Port frei zu haben.

    Wenn ich allerdings einen anderen Port in meinem Testfall 1214 nutze komme ich zu einem identischen Verhalten über Wireguard.

    Allerdings glaube ich ist der Test in dieser Konfiguration etwas sinnfrei denn ich gehe eben über VPN und dort wird mein iperf Datenstrom im VPN Tunnel verpackt. Damit einer der Anbieter auf Portbasis drosseln könnte müsste dieser erstmal den Wireguard-Tunnel aufbrechen. Das halte ich erstmal für nicht möglich. (ja ich weiß Geheimdienste oder ähnliches können das vielleicht oder bestimmt)

    Über die Nacht bin ich dann auf die Idee gekommen die beiden Raspi's einfach mal nicht über die VPN-Strecke miteinander sprechen zu lassen sondern direkt über das Internet in dem ich den entsprechenden Port freigebe. (hatte ich auch schon mit einem anderen Rechner gemacht)

    Siehe da:

    Das zeigt für mich nun folgendes:

    1. Es gibt kein Kapazitätsproblem zwischen den DG und DTAG. Nackter Traffic ohne Wireguard läuft fix über das Internet.

    2. Das immer noch laufende Fernsehprogramm(priorisierte Echtzeitdaten) hat keine Auswirkung darauf das die maximal genutzt Leitungskapazität genutzt wird.

    3. Außerdem denke ich den UDP Test auch mit angepasster MTU-Size kann ich mir ohne VPN sparen, da hier aufgezeigt wurde das eine höhere Datenrate als 40Mbits möglich ist.

    4. Optisch ist die Darstellung in der Fritzbox keine gerade Linie sondern eine weitest gehende maximal Auslastung mit kleinen Zacken drin.

    @alfalfa: Wieso belastet das Traffic Shaping die CPU einer der beiden Fritzbox? In meinem Verständnis müsste das in irgendeiner Infrastruktur eines der beiden Anbieter stattfinden.

    Im weiteren Schritt werde ich heute noch von DG nach DG messen. Hier muss ich mir allerdings noch einen Testaufbau einfallen lassen den ich bei den Nachbarn durchführen kann.

    Mein Ziel wäre zu testen welche maximale Kapazität zwischen den beiden DG Anschlüssen mit und ohne VPN möglich ist.

    Falls ohne VPN ca. 200 Mbits Upload möglich wäre und mit Wireguard nur noch 40 Mbits würde das aus meiner Sicht dafür sprechen das es ein Traffic Shaping gibt.

    Ich wünsche Euch einen guten Start in die Woche und einen schönen Tag!

    Zitat von Isch83

    Wieso belastet das Traffic Shaping die CPU einer der beiden Fritzbox? In meinem Verständnis müsste das in irgendeiner Infrastruktur eines der beiden Anbieter stattfinden.

    Die Fritzbox betreibt Traffic Shaping (oder QoS, aber das bezeichnet eigentlich das Ziel, nicht die Methode). Ankommender Datenverkehr wird gebremst, wenn Echtzeitverkehr stattfindet, damit der nicht unter die Räder kommt. Ob ein Download etwas langsamer ist, stört normalerweise nicht, aber Packet Loss in einer Fernsehübertragung oder beim Telefonieren fällt sofort sehr störend auf. Was die Fritzbox genau macht, ist allerdings nicht öffentlich bekannt.

    Zitat von Isch83

    Außerdem denke ich den UDP Test auch mit angepasster MTU-Size kann ich mir ohne VPN sparen, da hier aufgezeigt wurde das eine höhere Datenrate als 40Mbits möglich ist.

    Das Ziel dieses Tests wäre, Wechselwirkungen der Flow Control Algorithmen von TCP mit der Kapselung durch das VPN auszuschließen. Mit UDP-in-UDP legst du selbst fest, wieviel gesendet wird, und nicht ein Algorithmus, dessen Einflussfaktoren du erstmal herausfinden müsstest.

    Also ich finde es schon auffällig, dass die erreichte Geschwindigkeit in der "schnelleren" Richtung statt des erwarteten theoretischen Werts von 100 MBit/s praktisch nur den Maximalwert von 40 MBit/s erreicht, der exakt dem theoretischen und praktisch ermittelten Maximalwert in der "langsamen" Richtung entspricht. So, als gäbe es da eine Symmetrie-Bedingung, die für beide Richtungen nur den kleineren der beiden richtungsabhängigen Werte aushandelt.

    Allerdings finde ich in der Wireguard-Protokoll-Spezifikation (Link, ziemlich schwere Kost) keinerlei Hinweise auf so eine symmetrische Geschwindigkeitsaushandlung - das wäre für ein VPN-Protokoll wohl auch recht ungewöhnlich.

    Natürlich könnten die RASPIs auch gerade ihr Limit bei 40 MBit/s erreicht haben, aber das wäre natürlich auch ein merkwürdiger Zufall, dass das gerade der Upload-Geschwindigkeit in der langsameren Richtung entspricht.

    Dann noch ein Frage:

    UDP/IP-Transport zwischen den RASPIs ist offenbar IPv4. Will heißen, dass wegen CGNAT am DG-Anschluss nur der RASPI am DG-Anschluss die Verbindung zum RASPI am Telekom-Anschluss aufbauen kann. Anderseits bietet ein Telekom-Anschluss auch IPv6. Eventuell könnte man das ja dort aktivieren, um mal eine Transport-Verbindung zwischen des beiden RASPIs mit IPv6 (mit getunneltem IPv4) zu testen? Vielleicht macht das ja einen Unterschied.

    2 Mal editiert, zuletzt von ::1 (22. August 2022 um 22:10) aus folgendem Grund: Rechtschreibkorrektur

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    Da die DG kein Transit von der DTAG bezieht, wundern mich unterirdische Datenraten eigentlich überhaupt nicht. Teste es mal mit IPv6 an beiden Enden, aber ich glaube da nicht an Besserung. Diesselbe Thematik hatten unsere Kunden auch, da hilft nur sich damit abzufinden oder als ISP Transit bei der Telekom einzukaufen.

    Kapazitätslimits in der Übertragung bei den Providern scheiden aus, da ja ohne VPN die erwarteten Übertragungsraten erreicht werden.

    Ich nutze ebenfalls einen Raspi 4 als VPN Endpunkt für eine Wireguard Verbindung zu einem VServer. Dort erreiche ich ungefähr die 200 MBit/s Upload, die mein Anschluss hergibt, im Download sogar etwas mehr. Eine künstliche Einschränkung bei der DG können wir damit also ausschließen.

    Theoretisch kann man damit auch sagen: der Raspi 4 reicht auch locker, um die Bandbreite zu erreichen. Was aber damals der Fall war: Um diese Bandbreiten auf dem Raspi zu erreichen, war Handarbeit nötig. Wichtig war, auf jeden Fall die Kernel-basierte Wireguard Variante zu benutzen, nicht die im Userspace. Die CPU Auslastung während der Übertragung war vernachlässigbar, die war nie das Nadelöhr. Auch bei geringer Auslastung gab es teilweise langsame Verbindungen. Wichtig: Es war eine MTU und MSS Optimierung von Hand nötig, das hatte je nach Nutzdatenübertragung einen großen Einfluss. Nicht zuletzt spielen die Firewall Regeln eine entscheidende Rolle. Es gibt z.B. so fertige Scripte für die Installation von Wireguard, die waren eine Vollkatastrophe, genau so Dinge wie PiVPN: Nicht brauchbar, wenn es darum geht, die Performance zu optimieren. Allein die iptables Regeln, die die einführten, kosteten 50% der Bandbreite.

    Also: Dort würde ich als Erstes ansetzen. Bei der Konfiguration der Wireguard Knoten kann viel schief gehen, nicht in Wireguard selbst, sondern vor allem auch im umgebenden System (Firewall, MTU, ...).

    Zitat von frank_m

    Kapazitätslimits in der Übertragung bei den Providern scheiden aus, da ja ohne VPN die erwarteten Übertragungsraten erreicht werden.

    Das stimmt, allerdings nur dieses mal. Wir haben dieselben Upstream Provider wie die DG, es gab auch Zeiten in denen man die Endkunden der Eyeball-ISP gut erreichen konnte, das kann sich jedoch auch schnell ändern. Level3,Telia und Cogent sind jedenfalls kein Garant für eine gute Konnektivität zur DTAG, das kann nur ein direkter oder indirekter Transit sein.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
    Zitat von kingpin42

    direkter oder indirekter Transit

    Transit ist das Gegenteil von dem, was du meinst. Als "Transit" bezeichnet man, wenn ein Provider Daten durch sein Netz leitet, die weder aus seinem Netz stammen, noch für sein Netz bestimmt sind. Die Telekom hätte es gerne, wenn ISPs als Kunden einen Zugang zum Telekom-Netz bezahlen, anstatt diesen Zugang als Transit durch die Netze anderer Provider zu bekommen. Häufig wird vermutet, dass die Transit-Kapazitäten der Telekom etwas knapp bemessen sind, damit ein Anreiz besteht, die Telekom für einen direkten Zugang zu bezahlen.

    Wie bereits erwähnt wurde, ist aber in diesem Fall offensichtlich genug Kapazität zwischen den Netzen vorhanden, da Tests ohne VPN die volle Bandbreite des langsameren Anschlusses nutzen können.

    Zitat von alfalfa

    Transit ist das Gegenteil von dem, was du meinst. Als "Transit" bezeichnet man, wenn ein Provider Daten durch sein Netz leitet, die weder aus seinem Netz stammen, noch für sein Netz bestimmt sind. Die Telekom hätte es gerne, wenn ISPs als Kunden einen Zugang zum Telekom-Netz bezahlen, anstatt diesen Zugang als Transit durch die Netze anderer Provider zu bekommen. Häufig wird vermutet, dass die Transit-Kapazitäten der Telekom etwas knapp bemessen sind, damit ein Anreiz besteht, die Telekom für einen direkten Zugang zu bezahlen

    Die Telekom verkauft kein Paid-Peering, Sie verkauft nur Transit. Du bekommst als Kunde IMMER eine Fulltable. Da darfst du gerne mal einen Sales-Rep von der DTGC-Sparte oder entsprechende Personen auf der DENOG-ML/deren NOC anfragen. Du musst das als Kunde dann natürlich nicht als Transit nutzen, das steht wieder auf einem anderen Blatt.

    Unabhängig davon stimmt es für diesen Fall natürlich, das hier augenscheinlich (und vorerst) kein vorsätzliches Unter-Peering an der niedrigeren Leistung verantwortlich ist.

    Das ist nicht im eigentlichen Sinn Transit, auch wenn man diesen Zugang nur bekommt, indem man Transit bucht.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    Hallo Zusammen, vielen Dank für die vielen Antworten.

    Ich hatte gestern leider nur noch wenig Zeit zu testen.

    Die Verbindung zwischen den bei PI's kann von beiden Seite aus geöffnet werden. Auf der Seite der Telekom habe ich IPv6 aktiviert und kann meinen PI über die statische IPv6 Adresse erreichen. Genauso mache ich das auch mit mobilen Geräten.

    Der erste Test mit dem Anschluss meiner Nachbarn konnte ich nur über WLAN und mittels iPhone durchführen. Dabei habe ich die APP iperf aus dem IOS-App-Store geladen.

    Damit konnte ich schonmal zeigen das mein lokaler Raps im Netz der DG mit einem Client der DG über Wireguard mehr als 40 MBits Upload leisten kann.

    Ich wollte heute Abend nochmal testen. Allerdings muss ich schauen mit welchen Geräten und welchem Aufwand ich das vertretbar hinbekomme.

    Der PI als limitierender Faktor scheidet damit aus meiner Sicht aus.

    DG zu DG über Wireguard ist ebenfalls schneller als 40 MBits

    Ich vergleich jetzt die Konfiguration der beiden Wireguard-Schnittstellen in meinem Raspi um zusehen ob es da Unterschiede gibt.

    Für die Mobilen Geräte habe ich die Verbindung mittels PiVPN eingerichtet. Für die SitetoSite-Verbindung habe ich das ganze über eine manuelle Konfiguration gemacht.

    Die große Unbekannte ist dann noch die Verbindung zur Telekom. Da habe ich noch keine Idee wie ich da weiter testen kann.

    Nur mal als Anhaltspunkt: Über WLAN mit einen iPhone SE2 und aktuellem iOS an einer FB5530 (ca. 1,5 m Distanz Sichtverbindung) mit aktuellem FRITZ!OS und dem DG Speedtest erhalte ich als Durchsatz meine gebuchten Raten (400/200 Mbps).

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
    Zitat von Isch83

    Die große Unbekannte ist dann noch die Verbindung zur Telekom. Da habe ich noch keine Idee wie ich da weiter testen kann.

    Der Punkt ist doch, dass du ohne Wireguard die volle Bandbreite erreichen kannst. Solange wir nicht über zeitlich begrenzte Probleme reden ("Rush Hour"), kann es dann ja nur noch am Tunnel liegen.

    Wie gesagt, ein ganz heißer Tipp ist MTU. Wenn die nur um ein paar Byte falsch konfiguriert ist, kann das durchaus mal 40% Bandbreite kosten.

    frank_m : Ich verneige mich vor Dir! :)

    Die MTU-Size ist die richtige Richtung gewesen in welche ich forschen musste. Ich testet zwar noch was die richtige MTU-Size für meine DG-Seite ist. Aber die ersten Test sehen viel versprechend aus.

    Ich kann aus meinem beruflichen Umfeld (SAP-Basis) bereits ein besonders Augenmerk auf die MTU-Size allerdings habe ich bisher nie erlebt das man einen merklichen Unterschied erzeugen konnte. Somit habe ich mal wieder etwas gelernt :)