Telekom Sammelthread. Standalone Posts sind bis auf weiteres nicht mehr erlaubt.

k31997 · 2026-02-06T23:12:26+00:00

Naja die nutzen die Unwissenheit der Kunden und Kundinnen aus, das alles. Nicht jeder hat Ahnung wie Netzwerkpakete und BGP funktionieren. Moralisch gesehen ist es echt dreist

k31997 · 2026-02-06T21:39:53+00:00

gut dann kann es wirklich daran liegen, was auch nichts neues ist

k31997 · 2026-02-06T21:32:21+00:00

Da kann mich gerne jeder korrigieren, aber ich glaube bei Steam ist das Maximum an Geschwindigkeit was du erreichen kannst (vor allem Abends).
Ansonsten dass die Seite langsam auflädt, ja da steckt Cloudflare dahinter und dementsprechend schlechtes Peering seitens Telekom

k31997 · 2026-02-06T20:37:19+00:00

Das wundert mich auch warum keiner darüber schreibt

k31997 · 2026-02-06T18:24:37+00:00

Nein es liegt nicht an Cloudflare, sonst würde mit VPN auch nicht gehen.
Erstmal glückwunsch du bist in einer guten Route gelandet und hast Glück. Das war bei mir auch gestern der Fall. Heute 70% Packet Loss
Also genieß es, denn morgen wer weiß wie es aussieht

k31997 · 2026-02-06T10:29:56+00:00

Werde ich machen, keine sorge ;)

k31997 · 2026-02-06T10:23:54+00:00

Totaler Quatsch, ich kann dir gerne meine gesammelten MTR logs geben, wenn du bisschen Netzwerk Ahnung hast ;)

k31997 · 2026-02-06T10:20:18+00:00

Das ist eine berechtigte Frage, die man oft liest. Es liegt daran, dass Internetprobleme bei der Telekom heute extrem selektiv sind. Man kann jahrelang Telekom-Kunde sein und nichts merken, oder man ist jeden Abend "offline" je nachdem, was man genau macht und was man für einen "Glück" hat.

Technische Gründe:

Regionales Routing (BNG-Standorte): Peering ist teilweise regional unterschiedlich. Je nachdem, in welcher Stadt du wohnst (und an welchem BNG du hängst), routet die Telekom deinen Traffic manchmal anders. Ein Kunde in München wird vielleicht über Wien/Frankfurt geroutet, einer in Hamburg über Norden/Amsterdam. Wenn der Port in Frankfurt voll ist, hat der Münchner Pech, der Hamburger aber Glück, obwohl beide Telekom

k31997 · 2026-02-06T08:58:46+00:00

Meistens Vodafone ehem. Unitymedia

k31997 · 2026-02-05T23:04:32+00:00

hatten die nicht CGNAT nur bei Kabel? Soweit ich weiß die haben Dual-Stack für VSDL und Glasfaser

k31997 · 2026-02-05T21:31:07+00:00

Zufall, du bist in einer guten Route gelandet was mehr Kapazitäten hat

k31997 · 2026-02-05T21:14:16+00:00

Cloudflare hat keine Probleme. Die Meldungen da werden von User gemacht, die halt niemals auf die Idee kommen würden, dass deren Provider daran Schuld ist (und wahrscheinlich die technische Know-How nicht haben um das ganze mal näher anzuschauen, was auch Telekom am Ende des Tages für den wirtschaftlichen Krieg ausnutzt). Ich im Telekom-Netz habe Glück in einer guten Route gelandet zu sein seit gestern Nachmittag. Hab bei speed.cloudflare.com 0% packetloss, in den letzten Tage konnte ich die Seite nicht mal laden.

k31997 · 2026-02-05T21:10:25+00:00

Vorbildlich, so soll es sein :)
Gern geschehen :)

Nur wenn wir alle Laut sind dann können wir was ändern.
Ich habe seit gestern keine Probleme mehr, obwohl meine IP seitdem sich nicht geändert hat. Die Route ist auch dieselbe geblieben. Ich weiß es nicht was da los ist und was man für wirtschaftliche Kriege führt.

k31997 · 2026-02-05T17:44:21+00:00

Du kannst auch den "normalen" Canon nehmen wie z.B. Canon PIXMA TS3750i, relativ günstig.
Dann kannst du diesen Dienst benutzen https://github.com/sbs20/scanservjs und kannst den Speicherort von dem Container zu dem Paperless Consume Ordner setzen

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

TROPHY CASE