Unerklärliches Bandbreitenproblem

[mmabln]

HI,

ich bin im April von der Telekom zu 1&1 wg. des Peerings gewechselt, Vertrag ist VDSL 250, die Leitung bringt "nur" um die 120/40 Mbit/s, aber lief seit dem Wechsel stabil und auch mit guter Performance zu allen Endpunkten. Bevor die Frage kommt: Ich hänge im AS 8881, also Versatel Netz.

Vor ein paar Tagen gab es eine DSL Unterbrechung tagsüber und ich habe die Gelegenheit genutzt, um mal FritzOS auf der 7510 auf Version 8.25 zu updaten. Seitdem sind mir die Probleme aufgefallen, ich kann aber nicht sicher sagen, ob sie wirklich damit in Zusammenhang stehen. Vor ca. 2 Wochen war aber definitiv noch alles i.O.

Nun zum Problem:

Ich habe völlig unerklärliche Bandbreiteneinbrüche im Downstream bei TCP Verbindungen - NUR bei TCP Verbindungen und NUR im Downstream. UDP und ESP (ipsec) funktionieren mit der erwarteten Bandbreite.

Einige der Tests die ich gemacht habe mit iperf3 -c x.x.x.x -R (reverse = Client empfängt)

iperf3 Test Lokal -> proof.ovh.net: TCP (default) <5 mbit/s, UDP: ~100 mbit/s
iperf3 Test Lokal -> meinem netcup server: TCP (default) <5 mbit/s, UDP: ~100 mbit/s
iperf3 Test Lokal ==IPSEC-Tunnel===> Netcup server: TCP ~100 mbit/s

Andere Tests:

speedof.me Test: Down: <5 mbit/s, Up: ~40 mbit/s
Bandbreitenmessung Test: Down: <5 mbit/s, Up: ~40 mbit/s
Fritzbox Speedtest: Down: ~107 mbit/s, Up: ~40 mbit/s
Download Ubuntu ISO (Cloudflare): ~100 mbit/s
Download CentOS ISO: < 10 mbit/s

Meinen Netcup-Server per ipsec-VPN als Proxy konfiguriert: Alle Test-Webseiten oben bringen 90...100 mbit/s downstream wie gewünscht. Aber das ist natürlich keine Dauerlösung.

Ich dachte schon ich werde gedrosselt (letzten Monat ca. 3 TB gezogen), aber soweit ich weiß ist das bei 1&1 nicht der Fall.

Was mir aufgefallen ist: Beim Reconnect (Reboot) der Fritzbox bekomme ich jedesmal erstmal ein PPPoE Timeoutfehler, DSL ist relativ schnell da, aber die PPPoE Anmeldung dauert mehrere Minuten. Ebenso kann die Fritzbox plötzlich die von 1&1 zugewiesene Rufnmmer nicht mehr registrieren (die 3 portierten funktionieren allerdings).

Wilde Theorie: Kann es sein, dass ich mich garnicht mehr richtig per PPPoE anmelden kann und nun irgendwie in einem "fallback" Betrieb mit einer künstlichen Bandbreitenbegrenzung gelandet bin? Die (V)DSL Werte und Statistiken auf der Fritzbox sehen alle wie vorher aus, Leitungskapazität 130/40, keine Fehler, Störabstand etc. sieht alles ok aus (was ja auch die Tests eigentlich bestätigen).

Ich befürchte wenn ich das so dem 1&1 Support schildere wird es ewig dauern bis ich auf jemanden treffe der nicht nach Schema-F vorgeht und überhaupt was mit den Infos anfangen kann.

Hat hier jmd. noch irgendeine Idee?

Danke & Gruß
Markus

 

[frank_m24]

Wilde Theorie: Kann es sein, dass ich mich garnicht mehr richtig per PPPoE anmelden kann und nun irgendwie in einem "fallback" Betrieb mit einer künstlichen Bandbreitenbegrenzung gelandet bin?

Nein, weil dann wären auch UDP und IPSec Verbindungen betroffen.

Ich könnte mir drei mögliche Ursachen vorstellen:
Das Peering, also es kommt zu vereinzelten Paketverlusten. TCP reagiert darauf empfindlich mit Retransmissions, während UDP/IPsec Verbindungen das auf Applikationsebene abfangen. Das wäre ein Provider-Problem.
Oder deine MTU/MSS Konfiguration passt nicht, ggf. auch ein Clamping Problem
Oder deine TCP Parameter sind schlecht, vor allem die Congestion Control Einstellungen.

 

[mmabln]

Ich könnte mir drei mögliche Ursachen vorstellen:
Das Peering, also es kommt zu vereinzelten Paketverlusten. TCP reagiert darauf empfindlich mit Retransmissions, während UDP/IPsec Verbindungen das auf Applikationsebene abfangen. Das wäre ein Provider-Problem.
Oder deine MTU/MSS Konfiguration passt nicht, ggf. auch ein Clamping Problem
Oder deine TCP Parameter sind schlecht, vor allem die Congestion Control Einstellungen.

Ich habe es sowohl unter Linux (VM mit bridged Netzwerk) als auch mit drei anderen verschiedenen Windowsrechnern getestet, die Ergebnisse waren immer wie oben beschrieben. Was mich irritiert ist eben, dass es zu einigen Endpunkten wie dem AVM Speedcheck als auch den Ubuntu releases per Cloudflare völlig ok ist, für alle anderen gängigen Seiten/Tests aber mies. Gerade auch die Bandbreitenmessung hat ja ein eigenes AS und direktes Peering wenn ich es richtig gesehen habe.

Hier nochmal der Test zu OVH:

adrock@linux:~/Desktop> iperf3 -c proof.ovh.net -R
Connecting to host proof.ovh.net, port 5201
Reverse mode, remote host proof.ovh.net is sending
[  5] local 192.168.179.126 port 34978 connected to 141.95.207.211 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   256 KBytes  2.09 Mbits/sec               
[  5]   1.00-2.02   sec   512 KBytes  4.14 Mbits/sec               
[  5]   2.02-3.00   sec   384 KBytes  3.20 Mbits/sec               
[  5]   3.00-4.00   sec   384 KBytes  3.14 Mbits/sec               
[  5]   4.00-5.00   sec   384 KBytes  3.15 Mbits/sec               
[  5]   5.00-6.00   sec   384 KBytes  3.15 Mbits/sec               
[  5]   6.00-7.00   sec   384 KBytes  3.15 Mbits/sec               
[  5]   7.00-8.00   sec   256 KBytes  2.10 Mbits/sec               
[  5]   8.00-9.00   sec   384 KBytes  3.14 Mbits/sec               
[  5]   9.00-10.00  sec   512 KBytes  4.21 Mbits/sec               
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.02  sec  3.94 MBytes  3.29 Mbits/sec   64            sender
[  5]   0.00-10.00  sec  3.75 MBytes  3.15 Mbits/sec                  receiver

Währenddessen MTR im Hintergrund lief:

                                           My traceroute  [v0.95]
linux (192.168.179.126) -> proof.ovh.net (141.95.207.211)                          2026-07-02T16:50:56+0200
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                   Packets               Pings
 Host                                                            Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. AS???    192.168.179.1                                        0.0%    15    0.2   2.2   0.2  10.4   2.8
 2. AS???    192.168.178.1                                        0.0%    15    0.9   1.1   0.8   2.9   0.6
 3. AS8881   ber0811aihk001.versatel.de                           0.0%    15    5.3   6.6   5.3  14.4   2.5
 4. AS8881   vlan213.100M.flensburg1.distribution.komtel.net      6.7%    15    9.4  13.5   5.8  38.0   8.0
 5. AS16276  1und1.as8881.de.eu                                   0.0%    15   14.3  15.4  13.9  26.2   3.0
 6. AS16276  be104.fra-fr5-pb2-nc5.de.eu                          0.0%    15   22.5  20.7  18.2  24.8   2.2
 7. (waiting for reply)
 8. (waiting for reply)
 9. (waiting for reply)
10. AS16276  be104.lil1-rbx8-sbb1-nc5.fr.eu                       0.0%    15   29.4  25.8  24.7  33.3   2.4
11. AS16276  37.59.16.20                                          0.0%    15   26.5  24.6  23.7  26.5   0.7
12. (waiting for reply)
13. (waiting for reply)
14. (waiting for reply)
15. AS16276  rbx.proof.ovh.net                                    0.0%    14   24.3  24.3  24.0  24.9   0.3

Ich sehe da keinen Paketverlust und auch keine kritische Latenz.

 

[mmabln]

Tja, was soll ich sagen, Problem gelöst. Es war das FritzOS Update 8.20 -> 8.25.

Ich habe die 7510 auf 8.20 recovered und schon war die Geschwindigkeit wieder OK. Sie hat sich dann gleich wieder auf 8.25 geupdated (Auto-Update war noch aktiviert), und schon war die Geschwindigkeit wieder schlecht.

Nach nochmaligem Recover ohne Internetverbindung, alte Einstellungen wieder eingespielt, Auto-Update deaktiviert, Internet angeschlossen -> Läuft!



Tatsächlich das erste Mal dass ich mit einem FritzOS Update ein Problem hatte.

 

[frank_m24]

War der Traffic Shaper falsch eingestellt?

 

[mmabln]

War der Traffic Shaper falsch eingestellt?

Das hätte ich gedacht, aber ich habe an den Einstellungen nichts geändert (ich verwende den TS garnicht, da die Box eh hinter einem anderen Router hängt). Ich hatte sie testweise mit 8.25 auf Werkseinstellungen zurückgesetzt, direkt per Kabel mit dem Laptop verbunden und neu eingerichtet per Wizard -> Langsam

 

[tango501]

Problem gelöst. Es war das FritzOS Update 8.20 -> 8.25

Wurde der Fehler dem Hersteller Fritz gemeldet?

 

[mmabln]

Wurde der Fehler dem Hersteller Fritz gemeldet?

Ja, das habe ich gerade auch gemacht. Leider ist das Downgraden ziemlich hakelig (mal davon abgesehen dass man das Recoverytool für 8.20 nur über Umwege bekommt), bin froh das jetzt wieder alles rund läuft, brauche die Verbindung auch für mein Homeoffice, macht keinen Spaß wenn das Firmen VPN mit < 5 mbit/s läuft.

 

[tango501]

mal davon abgesehen dass man das Recoverytool für 8.20 nur über Umwege bekommt

Das Recovery Tool befindet sich auch immer in den zip Files der Laborversionen (ausgenommen Cabelboxen). Diese zip Files auch nach Laborende besser lokal archivieren und nicht löschen, dann kann man bei Bedarf immer darauf zurückgreifen.

 

[Karl.]

Aber mal zum Thema zurück, läuft es mit der 8.25 und deaktivierter Hardwarebeschleunigung?

 

[mmabln]

Aber mal zum Thema zurück, läuft es mit der 8.25 und deaktivierter Hardwarebeschleunigung?

Im 8.20 ist sie aktiviert. Dann würde ich erwarten dass sie auch nach dem Update aktiv war. Hatte ich tatsächlich nicht mehr auf dem Schirm dass da was war, hätte man mal probieren können. Die 7510 gehört zwar nicht zu den bekannten Problemboxen was das angeht, aber man weiß ja nie, evtl. wurde ja ausversehen in der 8.25 etwas verbugt. Nochmal updaten und testen mag ich allerdings nicht, bin froh dass jetzt alles läuft.

 

[klp55tsch]

..., evtl. wurde ja ausversehen in der 8.25 etwas verbugt.

Mit der 8.25 und _aktivierter_ Hardwarebeschleunigung, in Debian 12:

Spoiler: iperf3-Messung

:~ $ /usr/sbin/sysctl net.ipv4.tcp_window_scaling net.ipv4.tcp_moderate_rcvbuf net.core.default_qdisc net.ipv4.tcp_congestion_control
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

:~ $ iperf3 -c speedtest.studiofunk.de -p 5200 -4 -R
Connecting to host speedtest.studiofunk.de, port 5200
Reverse mode, remote host speedtest.studiofunk.de is sending
[  5] local 192.168.178.13 port 55010 connected to 185.209.244.2 port 5200
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  11.3 MBytes  95.2 Mbits/sec                 
[  5]   1.00-2.00   sec  12.6 MBytes   105 Mbits/sec                 
[  5]   2.00-3.00   sec  12.6 MBytes   105 Mbits/sec                 
[  5]   3.00-4.00   sec  12.6 MBytes   105 Mbits/sec                 
[  5]   4.00-5.00   sec  12.6 MBytes   105 Mbits/sec                 
[  5]   5.00-6.00   sec  12.6 MBytes   105 Mbits/sec                 
[  5]   6.00-7.00   sec  12.6 MBytes   105 Mbits/sec                 
[  5]   7.00-8.00   sec  12.6 MBytes   105 Mbits/sec                 
[  5]   8.00-9.00   sec  12.6 MBytes   105 Mbits/sec                 
[  5]   9.00-10.00  sec  12.6 MBytes   105 Mbits/sec                 
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.02  sec   127 MBytes   107 Mbits/sec   50             sender
[  5]   0.00-10.00  sec   124 MBytes   104 Mbits/sec                  receiver

iperf Done.

BTW: In FreeBSD 14.4/15.1 sind die Retransmissions nur 3 (... dort benutze ich für CC, rack statt bbr).

 

[tango501]

Die 7510 gehört zwar nicht zu den bekannten Problemboxen was das angeht, aber man weiß ja nie,

Der SoC kommt ja bei einer ganzen Reihe von Fritz Devices zum Einsatz, aber neben der FB7510 nur in zwei weiteren Boxen, der FRITZ!Box 7530 AX v2 und FRITZ!Box 4050.
Da die FRITZ!Box 7530 AX v2 keine weitere Firmwarepflege mehr erhält, sollten zumindest Anwender der FRITZ!Box 4050 ein vergleichbares Verhalten nachvollziehen könen.