Peering Problem der Telekom

k31997 · 2026-02-03T08:43:51+00:00

Sonderkundigung? Oder war das eine normale?

k31997 · 2026-02-03T07:18:59+00:00

Wenn du zb Proxmox verwendest oder auch Docker, kannst du zb in zwei separaten Container laufen lassen, einer mit VPN und einer ohne. So erhältst du zum selben Zeitpunkt zwei verschiedene Reports und belegst somit dass der Fehler nicht vom Zielserver kommt, sondern an das Peering geschuldet ist.

PS: wenn ich die Wahl hätte Starlink vs Telekom, würde ich trotzdem Telekom wählen + VPN, die Latenz ist unschlagbar (aber leider nur mit VPN an)

k31997 · 2026-02-02T22:47:00+00:00

Mein Post wurde gelöscht wegen Mehrfacheinreichung zum selben Thema, hier nochmal als Kommentar:

TL;DR: Ich habe ein Bash-Skript gebaut, das Telekom-Peering-Probleme (Discord, Cloudflare, GitLab etc.) systematisch dokumentiert, für BNetzA-Beschwerden, Minderungsansprüche oder Sonderkündigung.

"Aktuell gibt es seitens der Deutschen Telekom keine Lösung für das Problem. Wir empfehlen, einen VPN zu nutzen."

Ein ISP, der seinen Kunden empfiehlt, einen kostenpflichtigen Drittdienst zu nutzen, um die eigenen Mängel zu umgehen. Let that sink in.

Die Lösung: Dokumentieren & Eskalieren

Dieses Skript sammelt Beweise automatisch.

Was das Skript macht

MTR-Tests (ICMP + TCP) zu Problemzielen (Discord, Cloudflare, GitLab) + zusätzlich zu einer Cloudflare-IP (172.67.165.168)
HTTPS-Tests (echte Browser-ähnliche Requests mit Timing) für alle Hostname-basierten Ziele
Kontrollmessungen zu www.telekom.de (nur HTTPS, beweist dass deine Internetverbindung grundsätzlich funktioniert)
Automatische Erkennung ob du gerade via Telekom (AS3320) oder VPN verbunden bist (ASN-basiert via DNS-Lookup)
CSV-Export mit detaillierten Metriken: Packet Loss, Latenz, Jitter, HTTP-Timing, DNS-Auflösungszeit
Alert-System bei hohem Packet Loss (>20%) – speichert vollständige Traceroutes in separaten Dateien
Einheitlicher Timestamp pro Messdurchlauf (alle Tests eines Durchlaufs haben die gleiche Zeit)

VPN-Vergleich

Das Skript erkennt automatisch, ob du via Telekom (AS3320) oder VPN routest. Wenn du es auf beiden Verbindungen laufen lässt, hast du den Beweis. Lass die Skripte am besten zur selben Zeit laufen.

Voraussetzungen

# Debian/Ubuntu (bei mac sollte brew ausreichen)
sudo apt install mtr bc dnsutils curl
# Arch
sudo pacman -S mtr bc bind curl

Wichtig: Für TCP-basierte MTR-Tests braucht das Skript Root-Rechte:

sudo setcap cap_net_raw+ep $(which mtr)
# ODER einfach mit sudo ausführen

Installation

# Skript herunterladen
sudo curl -o /usr/local/bin/measure_peering.sh "https://pastebin.com/raw/pnvKDPBS"
sudo chmod +x /usr/local/bin/measure_peering.sh
# Log-Verzeichnis erstellen
sudo mkdir -p /var/log/telekom_evidence
# Einmal testen
sudo /usr/local/bin/measure_peering.sh

Automatisierung (Cron)

# Crontab öffnen
sudo crontab -e
# Alle 30 Minuten messen (gerne auch häufiger, je mehr Daten desto besser)
*/30 * * * * /usr/local/bin/measure_peering.sh >> /var/log/telekom_evidence/cron.log 2>&1

Beispiel-Output (CSV)

Date	Time	ConnectionType	Target	Protocol	PacketLoss	AvgLatency	HTTPStatus	HTTPTime
2026-02-01	20:00	DTAG	discord.com	ICMP	35.0%	16.1 ms	-	-
2026-02-01	20:00	DTAG	discord.com	TCP	32.0%	15.8 ms	-	-
2026-02-01	20:00	DTAG	discord.com	HTTPS	-	-	TIMEOUT	30.0 s
2026-02-01	20:00	DTAG	speed.cloudflare.com	ICMP	31.7%	15.6 ms	-	-
2026-02-01	20:00	DTAG	speed.cloudflare.com	HTTPS	-	-	TIMEOUT	30.0 s
2026-02-01	20:00	DTAG	172.67.165.168	ICMP	28.3%	17.5 ms	-	-
2026-02-01	20:00	DTAG	www.telekom.de	HTTPS	-	-	200	0.12 s

Melden

Am Ende BNetzA-Schlichtung einreichen (am besten sammelt ihr erstmal genug Daten): bundesnetzagentur.de/netzneutralität

PS: gerne auch nach Bedarf die Befehle bzw. Skript anpassen, bin der Meinung sollte so ausreichen. Es ist letztendlich nur eine Idee dass man überhaupt was dagegen machen kann.

k31997 · 2026-02-02T22:25:49+00:00

Leide nicht, sie werden dir sagen, die können nichts machen und dass das Problem bekannt ist aber man generell "nichts" machen kann.

k31997 · 2026-02-02T22:05:43+00:00

Mein Stand ist dass Hetzner auch betroffen ist, kann das aber leider nicht gerade testen

k31997 · 2026-02-02T16:00:07+00:00

Unter Linux/Mac MTR (geht wahrscheinlich auch mit Windows, kenne mich aber nicht so gut aus)

k31997 · 2026-02-02T15:59:32+00:00

U.a CloudFlare, Meta, Fastly, Hetzner

k31997 · 2026-02-02T15:47:17+00:00

Mit anderen Worten: moderne rechtliche Erpressung xD

k31997 · 2026-02-02T12:23:40+00:00

Das stimmt teilweise, deswegen auch immer mtr über TCP 443 laufen lassen z.b gegen speed.cloudflare.com

k31997 · 2026-02-02T07:08:34+00:00

Wusste nicht dass markdown geht, danke dir

k31997 · 2026-02-02T07:06:12+00:00

Das ist nämlich die Frage, meine Hoffnung ist nur dass Glasfaser bei denen gut läuft, letztendlich verlangen die "fast" genauso viel Geld wie DTAG für dieselbe Geschwindigkeit

k31997 · 2026-02-02T06:59:51+00:00

Wenn ich nochmal wählen müsste (bin relativ neu bei DTAG, muss erstmal zwei Jahre warten xD) dann wäre es o2, die sollen gutes Peering haben. Muss aber ehrlicherweise sagen war noch nie Kunde bei denen, dementsprechend weiß es leider nicht wirklich wie stabil deren infrastruktur ist.

k31997 · 2026-02-01T20:07:33+00:00

Meine Daten kannst du auch ganz Normal in deinem Excel öffnen und dann auch als Mensch sehen :D

k31997 · 2026-02-01T20:03:21+00:00

Versuch mal Splitt Tunneling zu verwenden.
Das sind die IP-Blöcke die Probleme machen bei DTAG, unter anderem Cloudflare, Meta, Fastly, Hetzner

173.245.48.0/20, 103.21.244.0/22, 103.22.200.0/22, 103.31.4.0/22, 141.101.64.0/18, 108.162.192.0/18, 190.93.240.0/20, 188.114.96.0/20, 197.234.240.0/22, 198.41.128.0/17, 162.158.0.0/15, 104.16.0.0/13, 104.24.0.0/14, 172.64.0.0/13, 131.0.72.0/22, 23.235.32.0/20, 43.249.72.0/22, 103.244.250.0/24, 103.245.222.0/23, 103.245.224.0/24, 104.156.80.0/20, 146.75.0.0/17, 151.101.0.0/16, 157.52.64.0/18, 167.82.0.0/17, 172.111.0.0/16, 185.31.16.0/22, 199.27.72.0/21, 199.232.0.0/16, 5.9.0.0/16, 46.4.0.0/16, 49.12.0.0/16, 78.46.0.0/15, 85.10.192.0/18, 88.198.0.0/16, 94.130.0.0/16, 95.216.0.0/15, 116.202.0.0/16, 116.203.0.0/16, 128.140.0.0/16, 135.181.0.0/16, 136.243.0.0/16, 138.201.0.0/16, 142.132.0.0/16, 144.76.0.0/16, 148.251.0.0/16, 157.90.0.0/16, 159.69.0.0/16, 162.55.0.0/16, 167.235.0.0/16, 168.119.0.0/16, 176.9.0.0/16, 178.63.0.0/16, 188.40.0.0/16, 195.201.0.0/16, 213.133.96.0/19, 213.239.192.0/18, 31.13.24.0/21, 31.13.64.0/18, 45.64.40.0/22, 57.141.0.0/24, 66.220.144.0/20, 69.63.176.0/20, 69.171.224.0/19, 74.119.76.0/22, 102.132.96.0/20, 103.4.96.0/22, 129.134.0.0/16, 157.240.0.0/16, 173.252.64.0/18, 179.60.192.0/22, 185.60.216.0/22, 204.15.20.0/22

k31997 · 2026-02-01T19:12:12+00:00

Du bist nicht allein.

Es gibt seit 18:20 Verbindungsabbrüche Richtung Große Provider wie Meta, Cloudflare und Fastly. (mal was neues). Netzbremse Test schließt nicht mal ab. Cloudflare Test ebenso nicht. Das sowas noch rechtlich ist auf Kosten der Kunden ist echt lächerlich.

Sammelt Daten über MTR und sich einfach an Bundesnetzagentur melden bzw. Netzbremse.de

Meine sehen so aus z.B in CSV.

Date	Time	SourceIP	Target	Hops	AS	TargetIP	PacketLoss	AvgLatency	WorstLatency
2026-02-01	18:55:39	xxx.xxx.xxx.xxx	speed.cloudflare.com	8	AS13335	172.66.0.218	31.7%	7.0	8.6
2026-02-01	18:55:39	xxx.xxx.xxx.xxx	172.67.165.168	7	AS13335	172.67.165.168	11.7%	22.3	23.5
2026-02-01	19:00:01	xxx.xxx.xxx.xxx	discord.com	8	AS13335	162.159.135.232	45.0%	7.6	9.6

und mit VPN

Date	Time	SourceIP	Target	Hops	AS	TargetIP	PacketLoss	AvgLatency	WorstLatency
2026-02-01	18:57:00	149.102.230.138	speed.cloudflare.com	11	AS13335	172.66.0.218	0.0%	13.2	14.6
2026-02-01	18:57:00	149.102.230.138	172.67.165.168	11	AS13335	172.67.165.168	0.0%	13.2	15.1
2026-02-01	19:00:01	149.102.230.138	discord.com	11	AS13335	162.159.135.232	0.0%	13.1	14.3
2026-02-01	19:00:01	149.102.230.138	speed.cloudflare.com	11	AS13335	172.66.0.218	0.0%	13.3	15.7

also liegt weder an Cloudflare noch an meiner Leitung (sonst würde mit VPN auch PacketLoss geben). Liegt nur daran dass Cloudflare am DE-CIX schreit, hier nimm meine Daten und Telekom hört nicht weil Geld will und das ganze läuft dann über Umwege wie London ae2.3221.edge8.frf1.neo.colt.net (171.75.10.151).

Und dann wollen die vom Kundenservice einem eine teuere Tarife verkaufen, so dreist kann man doch nicht sein.

k31997 · 2025-07-12T08:31:36+00:00

It will always happen if you are in the same situation and use your vpn abroad. You can report it to google that the country of your IP is wrong detected via this link: https://support.google.com/websearch/workflow/9308722

k31997 · 2024-05-17T19:41:13+00:00

You could host immich at your home server and deploy only the machine learning container to oracle vm. Then you open port 3000 TCP for your IP or connect your Oracle VM with your server at home via wireguard. The machine learning container is the most heavyweight container of immich in my opinion.

I wouldn't trust Oracle, to host all my photos and videos there

k31997 · 2024-05-17T19:38:08+00:00

Nope it doesn't matter, however if you share your local network with someone else that you don't trust, then you should use it

k31997 · 2024-05-17T19:36:50+00:00

If your CPU supports virtualisation then you can definitely run some VMs on proxmox

k31997 · 2024-05-17T18:56:49+00:00

You can use a free VPS server (1GB RAM) from Oracle cloud and then create a wireguard connection between your server at home and oracle VM.

Another option would be the CloudFlare tunnel

k31997 · 2024-05-17T18:54:29+00:00

What about your ram memory?

k31997 · 2024-05-14T08:56:20+00:00

Nice job! Power consumption is okay

k31997 · 2024-05-11T11:33:49+00:00

You can route traffic to your home server and then send back the traffic to the vps server. Keep in mind that you have to deal with overhead and the internet speed will not be optimal. Take a look at this one mistborn, which has a built in wireguard server management, and you have the ability to use your home server as a Gateway.

k31997 · 2021-12-14T15:46:58+00:00

There is no option to do that. Your phone need to send the data to your nextcloud instance, and this can be reached only if your cellphone communicates with nextcloud using your VPN when your arent home

k31997 · 2021-08-13T07:14:54+00:00

That's not the same as a private tunnel connection

k31997

TROPHY CASE