eine Fritz-VPN-Verbindung zu einem Server in einem DC aufgebaut, und bin etwas erschüttert, daß augenscheinlich die 7490 nicht mehr als ca. 20 MBit/sec an meinem VDSL 50-Anschluß hinbekommt.
Aus aktuellem Anlass grabe ich das Thema aus, weil ich diese Zahl heute nicht bestätigen kann, sondern "ohne Tricks" im Grundsatz die nachfolgenden Quellen mit etwa der Hälfte, nämlich
max. 10 Mbit/s in einem VPN-IP-Sec. In meinen LAN-LAN-Kopplungen mit FritzBoxen 7490_07.60 untereinander und zu einer 4050_08.1x wurde zum aktivierten iperf-Server der FritzBox-Router gemessen. Einmal über die IPv4, also im VPN-LAN-LAN, und über den dynDNS/MyFritz.net, also direkt im WAN (Internet).
Die Fritzboxen haben nicht genug Verschlüsselungsleistung für mehr als etwa 10 Mbit/s je nach Modell.
_#10_
VPN kostet Rechenleistung. Die Fritzbox hat davon nicht unendlich viel.
Das Limit ist jetzt nicht deine Internetanbindung sondern der Prozessor der Fritzbox.
_#2_
3270 --> 7272: 950 KBits/s;
7272 --> 3270: 2,87 MBits/s;
7272 --> 7490: 12,8 MBits/s;
7490 --> 7272: 12,3 MBits/s.
PC --> PC ohne VPN: 92,5 MBits/s, hier begrenzt der 100 MBit Switch und die eine Netzwerkkarte.
_#27_
LAN-LAN mit einer 7390 8-9 Mbit,
LAN-LAN mit einer 7362SL ebenfalls 8-9 Mbit,
LAN-LAN zu einer 6490 Cable 4-5 Mbit.
_#17_
Also ich sichere von meinen Cloudservern jede Nacht ca 5GB an Daten auf meine HeimNAS. Früher habe ich das VPN über meine 7490 laufen lassen. Selbst mit allen möglichen IPSEC Tricks habe ich nicht mehr als 20MBit hinbekommen. Ich benutze jetzt einen alten i5-650 auf dem ich einen OpenVPN Client laufen lasse und "ziehe" mir darüber die Daten auf die NAS. Damit erreiche ich meine 92MBit down und 35MBit up, allerdings hat der i5-650 natürlich auch AES-NI. Kurzum, ihr braucht einen Rechner, der die Verschlüsselung beschleunigt, sonst hat das keinen Sinn ...
_#30_
[ Menü: Hilfe und Info, ganz unten Fritz!Box-Support aufrufen ]
Hat wer schon
|__| Messpunkt "TWAMP-Light reflector" nach RFC 5357 aktivieren getestet?
Durchsatzmessungen (mit iperf2)
Diese Funktion ermöglicht die Messung der Übertragungsgeschwindigkeit zwischen der FRITZ!Box und einem Computer in Ihrem Heimnetz oder im Internet mit Iperf.
Iperf ist ein frei verfügbares Programm zur Messung der Übertragungsgeschwindigkeit von TCP- und UDP-Daten zwischen einem Server und einem Client. Die FRITZ!Box dient als Iperf-Server, so dass die Messung auf Ihrem Computer ganz einfach mit einem Iperf-Client erfolgen kann.
Den Iperf-Client kann man für verschiedenste Betriebssysteme aus dem Internet downloaden. Weitere Informationen zu Iperf finden Sie im Internet.
Code:
Aktivieren Sie den Iperf-Server der FRITZ!Box für die Schnittstelle,
über die Sie die Messung durchführen wollen.
|X| Messpunkt für einen Iperf-Client im Heimnetz aktivieren, Port 4711 für TCP und UDP
|X| Messpunkt für einen bidirektionalen Iperf-UDP-Test im Heimnetz aktivieren,
Port 4712 für UDP
|X| Messpunkt für einen Iperf-Client im Internet aktivieren,
Port 4711 für TCP/UDP und Port 4712 für UDP an der Firewall öffnen.
Ihre FRITZ!Box ist derzeit unter folgender Adresse im Internet erreichbar: your.dynDNS.de
Am Anschluss VDSL 60/22 mit Laptop über WiFi (to fast for 22 Mbit/s) gemessen zu Fiber 150/75:
Code:
lmde:~$ date ; iperf -c 192.168.13.1 -t 90 -i 30 -p 4711
Do 16. Okt 08:45:32 CEST 2025
------------------------------------------------------------
Client connecting to 192.168.13.1, TCP port 4711
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 1] local 192.168.13.109 port 36088 connected with 192.168.13.1 port 4711
[ ID] Interval Transfer Bandwidth
[ 1] 0.0000-30.0000 sec 289 MBytes 80.9 Mbits/sec
[ 1] 30.0000-60.0000 sec 300 MBytes 83.9 Mbits/sec
[ 1] 60.0000-90.0000 sec 299 MBytes 83.6 Mbits/sec
[ 1] 0.0000-90.2324 sec 888 MBytes 82.6 Mbits/sec
# LAN-to-LAN-VPN / IP-Sec
Code:
lmde:~$ date ; iperf -c 10.42.0.1 -t 90 -i 30 -p 4711
Do 16. Okt 08:32:34 CEST 2025
------------------------------------------------------------
Client connecting to 10.42.0.1, TCP port 4711
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 1] local 192.168.13.109 port 48214 connected with 10.42.0.1 port 4711
[ ID] Interval Transfer Bandwidth
[ 1] 0.0000-30.0000 sec 27.0 MBytes 7.55 Mbits/sec
[ 1] 30.0000-60.0000 sec 26.5 MBytes 7.41 Mbits/sec
[ 1] 60.0000-90.0000 sec 26.5 MBytes 7.41 Mbits/sec
[ 1] 0.0000-90.7439 sec 80.1 MBytes 7.41 Mbits/sec
# LAN-to-WAN
Code:
lmde:~$ date ; iperf -c your.dynDNS.de -t 90 -i 30 -p 4711
Do 16. Okt 08:28:53 CEST 2025
------------------------------------------------------------
Client connecting to your.dynDNS.de, TCP port 4711
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 1] local 192.168.13.109 port 51900 connected with 91.40.87.24 port 4711
[ ID] Interval Transfer Bandwidth
[ 1] 0.0000-30.0000 sec 66.8 MBytes 18.7 Mbits/sec
[ 1] 30.0000-60.0000 sec 70.1 MBytes 19.6 Mbits/sec
[ 1] 60.0000-90.0000 sec 66.5 MBytes 18.6 Mbits/sec
[ 1] 0.0000-90.2979 sec 204 MBytes 18.9 Mbits/sec
Das sieht dann am iperf-Server z.B. Fiber 150/75 mit 4050_08.1x so aus.
Am Anschluss Fiber 150/75 mit Laptop über LAN (to fast for 75 Mbit/s) gemessen zu VDSL 60/22:
Code:
lmde:~$ date ; iperf -c 10.42.0.1 -t 90 -i 30 -p 4711
Do 16. Okt 09:16:47 CEST 2025
------------------------------------------------------------
Client connecting to 10.42.0.1, TCP port 4711
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 1] local 10.42.1.141 port 42418 connected with 10.42.0.1 port 4711
[ ID] Interval Transfer Bandwidth
[ 1] 0.0000-30.0000 sec 1000 MBytes 280 Mbits/sec
[ 1] 30.0000-60.0000 sec 1.03 GBytes 294 Mbits/sec
[ 1] 60.0000-90.0000 sec 1.16 GBytes 331 Mbits/sec
[ 1] 0.0000-90.1070 sec 3.16 GBytes 301 Mbits/sec
# LAN-to-LAN-VPN / IP-Sec
Code:
lmde:~$ date ; iperf -c 192.168.13.1 -t 90 -i 30 -p 4711
Do 16. Okt 14:27:28 CEST 2025
------------------------------------------------------------
Client connecting to 192.168.13.1, TCP port 4711
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 1] local 10.42.1.140 port 42666 connected with 192.168.13.1 port 4711
[ ID] Interval Transfer Bandwidth
[ 1] 0.0000-30.0000 sec 31.8 MBytes 8.88 Mbits/sec
[ 1] 30.0000-60.0000 sec 32.9 MBytes 9.19 Mbits/sec
[ 1] 60.0000-90.0000 sec 33.1 MBytes 9.26 Mbits/sec
[ 1] 0.0000-90.3231 sec 97.9 MBytes 9.09 Mbits/sec
# LAN-to-WAN
Code:
lmde:~$ date ; iperf -c bg*.myfritz.net -t 90 -i 30 -p 4711
Do 16. Okt 14:29:08 CEST 2025
------------------------------------------------------------
Client connecting to bg*.myfritz.net, TCP port 4711
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 1] local 10.42.1.140 port 44026 connected with 91.36.234.195 port 4711
[ ID] Interval Transfer Bandwidth
[ 1] 0.0000-30.0000 sec 210 MBytes 58.7 Mbits/sec
[ 1] 30.0000-60.0000 sec 209 MBytes 58.5 Mbits/sec
[ 1] 60.0000-90.0000 sec 209 MBytes 58.5 Mbits/sec
[ 1] 0.0000-90.3613 sec 628 MBytes 58.3 Mbits/sec
Mit Wireguard (und aktuellen FritzBoxen>07.50) gibt es diese Begrenzung nicht, dort werden mit der 7490 ca. 40 Mbit/s im LAN-to-LAN-VPN erreicht.
FRITZ!Box und WireGuard VPN - Der große Performance Test mit FRITZ!OS 7.57
Wireguard-Tunnel Geschwindigkeit messen
"In theory WireGuard should achieve very high performance."
wireguard.com/performance/
"Our Inline design solves the problem, at the cost of lower single-tunnel throughput."
PDF
Weil derzeit
bei Performancethemen auch Peering als Ursache mit IPv6 auftaucht, z.B.
_#22_, noch der Hinweis es sind alles Telekomanschlüsse, auch hier bei einer Messung aus Windows/CMD mit
iperf2-2.2.x-win64 ...
Code:
..\iperf2>iperf-2.2.1-win64.exe -c 10.29.2.1 -t 8 -i 2 -p 4711
------------------------------------------------------------
Client connecting to 10.29.2.1, TCP port 4711
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[ 1] local 10.42.1.3 port 62789 connected with 10.29.2.1 port 4711
[ ID] Interval Transfer Bandwidth
[ 1] 0.00-2.00 sec 1.25 MBytes 5.24 Mbits/sec
[ 1] 2.00-4.00 sec 1.88 MBytes 7.86 Mbits/sec
[ 1] 4.00-6.00 sec 2.25 MBytes 9.44 Mbits/sec
[ 1] 6.00-8.00 sec 2.25 MBytes 9.44 Mbits/sec
[ 1] 0.00-8.04 sec 7.75 MBytes 8.09 Mbits/sec
..\iperf2>iperf-2.2.1-win64.exe -c 29*.selfhost.de -t 8 -i 2 -p 4711
------------------------------------------------------------
Client connecting to 29*.selfhost.de, TCP port 4711
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[ 1] local 10.42.1.3 port 62778 connected with 87.162.59.117 port 4711
[ ID] Interval Transfer Bandwidth
[ 1] 0.00-2.00 sec 10.4 MBytes 43.5 Mbits/sec
[ 1] 2.00-4.00 sec 13.8 MBytes 57.7 Mbits/sec
[ 1] 4.00-6.00 sec 13.8 MBytes 57.7 Mbits/sec
[ 1] 6.00-8.00 sec 13.8 MBytes 57.7 Mbits/sec
[ 1] 0.00-8.03 sec 51.8 MBytes 54.1 Mbits/sec
Hat die Telekom ihr Peering Problem mittlerweile gelöst? "Die Sache ist,
die Telekom hat kein Peeringproblem. Sie
hat eine Peeringstrategie. Anbieter, die ihren Kunden im Telekomnetz gute Leistung bieten wollen müssen an die Telekom zahlen. Das machen eigentlich alle Großen, mangels Alternative. Der BF6 Spieler sucht ein Pingproblem zuerst bei den BF6-Servern und nicht bei der Telekom, also zahlt EA da lieber. Wo du das Problem hast ist bei Selfhosted oder kleineren Anbietern, die eben nicht an die Telekom zahlen wollen oder können. Aber da sind die Kunden noch eher bereit, das auf die Serveranbieter zu schieben. Und selbst wenn du weißt, das dein ISP das Problem ist, wechselst du den oder gehst du lieber auf nen anderen, ggf. finanziell besser aufgestellten Server? Die Strategie der Telekom geht hier voll auf. Gut für die Aktionäre, schlecht für die Nutzer."
Ein Beispiel zu EA)
Re: Packet Loss um 2020
Da musst du nichts Aufzeichnen, die Probleme sind allen komplett inkl. allen Ursachen bekannt. Aber keiner will daran etwas ändern.Telia, Level3 und noch so... - 5638887
forums.ea.com
Telekom Backbone vs. 1&1 Versatel Backbone "Wir sprechen bei Smokepings zwar ausschließlich von Latenzen, die tatsächlichen Übertragungsraten zu den Stoßzeiten sinken jedoch massivst bei einem überlasteten Peering ein. Wenn Latenzen von 10ms auf 50ms wachsen, kann die tatsächliche Übertragungsgeschwindigkeit auch ganz einfach in den Bereich 0,1 bis 10 Mbit - von ursprünglichen 800-1000 Mbit zur Nachtzeit sinken. Daher sind Smokepings trotz dessen ein guter Indikator um auch auf Bandbreitenprobleme beim Telekom-Peering und Transit aufmerksam zu machen."
"Leider steigt die Latenz abends in Richtung DTAG über IPv6 stark an und es gehen Pakete verloren. ... Für den Kunden ist dein gehosteter Service langsam, während alle anderen schnell sind. Das führt niemand ohne technische Expertise auf die Telekom zurück."
Latenz / Packet Loss zu DTAG über twelve99 (Arelia, ehm. Telia) IPv6.
Bei kleineren Netzbetreibern, mit nur wenigen L3-BSA Übergabepunkten in DE (bspw. easybell), kann das dann ggf. auch mal etwas deutlicher negativ auffallen, da der Weg zum nächsten Übergabepunkt ggf. auch mal etwas weiter entfernt liegen kann (und sich das dann somit spürbar negativ auf die Latenz auswirkt).
telekomhilft.telekom.de bei Problemem, die wir ohne Telekom nicht hätten:
Packet losses beim Übergang zu twelve99.net und ganz allgemein
Peeringprobleme - Probleme bei Datenübertragung, hohe PING-Zeiten, schlechte Verbindungen. Die
Bandbreite und Latenz -
Die wichtigsten Unterschiede, bei
AWS erklärt.
Was verursacht Packet Loss? telekomhilft bei
Packet loss über Berlin *.dip0.t-ipconnect.de oder
Packet loss 15-60% oder
Pingprobleme - hoher Ping & Packet Loss trotz stabiler Leitung "das Problem tritt nur sporadisch auf, wenn das
Telekom / Cloudflare Peering überlastet ist."
ICMP Typ 8,ping Typ 11,echo
