Gelöst
Zielabhängiger Paketverlust im Telekom-Core hinter BNG 80.146.128.143 (Glasfaser Nordwest Gebiet) - VoIP-Aussetzer unter Last
vor 23 Tagen
Hallo zusammen,
ich habe an meinem Glasfaser-Anschluss (1000/500, Glasfaser-Nordwest-Ausbaugebiet von Anfang 2025, Glasfasermodem 2, eigener Router per PPPoE) seit einiger Zeit VoIP- und RDP-Aussetzer, sobald größere Downloads laufen. Ich habe das ausführlich durchgemessen und kann das Problem auf den Telekom-Core hinter meinem BNG eingrenzen. Bandbreite und Optikwerte sind übrigens top - es geht rein um Paketverlust.
Kernbefund: Der Verlust ist zielabhängig. Während ein Speedtest gegen den Telekom-eigenen Ookla-Server Düsseldorf läuft (Download ca. 1020 Mbit/s), verlieren alle Pfade über den Telekom-Core 5-16% der Pakete - darunter auch die Telekom-eigenen Speedtest-Server. Google und Cloudflare bleiben im selben Zeitfenster bei 0% Verlust über tausende Proben.
Messmethode: TCP-Connect-Probes (5/s, Retransmit bei ~1000 ms = verlorenes Paket) plus parallele ICMP-Pings mit 10 Hz, jeweils vor, während und nach der Last. Ergebnis über mehrere Läufe reproduzierbar:
| Ziel | idle | Download über Telekom-Server | Download über Hetzner ( Peering ) |
|---|---|---|---|
| dssd/ffm/ham.wsqm.telekom-dienste.de | sporadische Bursts | 8-9% Verlust | sauber |
| VPN -Endpunkte Arbeitgeber (teutel, ewe-tel) | sauber | 5-16% Verlust | sauber |
| Hetzner-Server (46.225.81.25) | sauber | 3,8% Verlust | sauber |
| Google (v4+v6), Cloudflare | sauber | 0% (>2000 Proben) | sauber |
IPv6 ist genauso betroffen wie IPv4 (2% zu ffm.wsqm über v6, Google-v6 parallel 0%). Es gibt außerdem Verlust-Bursts auf den betroffenen Pfaden, während meine Leitung nachweislich idle ist (<13 Mbit/s) - vermutlich Last anderer Kunden auf demselben Element.
Was ich ausschließen kann:
- Mein Router/Heimnetz: alle Interface- und Fehlercounter null, CPU unter Volllast >60% idle. Vor allem kann ein lokales Gerät nicht nach Ziel-Netz sortieren - Google-Pakete laufen durch dieselbe Hardware wie die betroffenen.
- Das GFNW-Zugangsnetz und der GPON-Baum: transportieren alle Ziele gleich, der Verlust ist aber zielabhängig. Der Engpass liegt also hinter der L2- BSA -Übergabe im Telekom-Teil.
- Regionales Problem generell: Ein zweiter Telekom-Anschluss im gleichen Ausbaugebiet ( BNG 80.146.128.178, gleicher Standort) zeigt mit identischem Testverfahren nur 0,3-0,6% kurze Verluste beim TCP-Ramp-Up - bei mir sind es 5-16% über die komplette Download-Phase.
Pfaddetails von meinem Anschluss ( BNG -Peer 80.146.128.143): Die betroffenen Ziele routen über die Core-Adjazenzen 62.154.43.10/.14 → 87.128.210.57 (Telekom-intern) bzw. 62.159.98.90 → 80.156.162.158 (Richtung teutel). Der saubere Google-Pfad läuft über 62.159.98.18 → 80.150.170.70.
Meine Bitte: Könnt ihr das an die Netztechnik geben und die Auslastung/Fehler auf den Uplinks bzw. der Aggregation hinter BNG 80.146.128.143 prüfen lassen? Ich vermute ein überlastetes oder fehlerhaftes Element auf genau diesen Adjazenzen - das Gebiet ist erst Anfang 2025 in Betrieb gegangen. Ich kann das Problem jederzeit auf Zuruf reproduzieren und liefere gern Rohdaten mit Zeitstempeln (alle Messungen liegen vor).
Gruß, Ben
104
0
27
Das könnte Ihnen auch weiterhelfen
vor 5 Stunden
29
0
11
vor 22 Tagen
in
110
0
36
in
2
0
0
vor 37 Minuten
in
47
0
6
vor 2 Stunden
37
0
1
Beliebte Tags letzte 7 Tage
Das könnte Sie auch interessieren
Kaufberatung anfragen
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.
Angebote anzeigen
Informieren Sie sich über unsere aktuellen Internet-Angebote.
vor 23 Tagen
Hallo @OptiBen,
vielen Dank für das Gespräch.
Ich habe nun ein Ticket erstellt und leite es an unsere Diagnoseabteilung weiter.
Grüße Detlev
0
vor 22 Tagen
Hallo @OptiBen, um das zu analysieren, brauchen die Kollegen einen Hin- und Rücktrace. LG^Mirko
0
11
von
vor 20 Tagen
Hallo @OptiBen, ich habe alle deine Nachrichten erhalten. Ich habe mittlerweile eine vorläufige Rückmeldung bekommen. Die Kollegen haben sich alles angeschaut, und die Strecken, die wir prüfen können, zeigen keine Auffälligkeiten in Bezug auf Fehler und Auslastung. Der Kollege wird das aber weitergeben, um zusätzliche Prüfungen durchzuführen. Vielleicht – und das kann ich nicht versprechen – möchten die Kollegen sich bei dir melden. Wenn du einverstanden bist, gebe ich deine Kontaktdaten gerne weiter. LG^Mirko
von
vor 20 Tagen
@Mirko St. . ja, gerne - Kontaktdaten könnt ihr weitergeben, freue mich über den Rückruf.
Falls es einfacher ist: wenn mir jemand kurz eine Mail schickt, schicke ich direkt eine kompakte PDF-Zusammenfassung des Befunds zurück (Messreihe, Adjazenzen, Vorschläge zur weiteren Eingrenzung) - dann muss niemand am Telefon mitschreiben.
Danke euch fürs Dranbleiben!
von
vor 20 Tagen
Ok, dann gebe ich diese weiter. Im Moment sind keine weiteren Daten erforderlich. LG ^Mirko
Uneingeloggter Nutzer
von
vor 18 Tagen
@Mirko St. - kurzes, konsolidiertes Update, und sorry für die vielen Nachträge: ich habe in den letzten Tagen kontrolliert nachdiagnostiziert (gepaarte Lastfenster, Gegentests) und dabei auch eine eigene frühere Vermutung korrigiert. Hier der aktuelle, belastbare Stand - falls die Netz-/Diagnosetechnik "mitliest":
Das Problem ist unverändert reproduzierbar. Mehrere kontrollierte Gegentests der letzten Tage haben es sauber eingegrenzt:
Konkret merke ich das weiterhin im Alltag: mein Arbeits- VPN / Remote-Desktop friert unter Downstream-Last immer mal wieder 1-2 Sekunden ein und die VoIP-Telefonie zur Arbeit (die läuft auch über VPN ) hat kurze Aussetzer - beides läuft über genau die betroffene Zielklasse. Es ist also kein reines Messphänomen, sondern eine anhaltende Störung im (Arbeits)alltag.
0
5
von
vor 12 Tagen
@Mirko St. Danke für das Statusupdate.
von
vor 12 Tagen
👍
von
vor 9 Tagen
Hallo @OptiBen, es wurden wirklich sehr umfangreiche Prüfungen vorgenommen.
Wir sehen auf allen Teilen der Strecke, auch auf den Übergängen in andere Netze, keine Drops, Errors oder Überlastungen zu allen Tageszeiten.
Was die Telefonie angeht:
Es gibt keine Anzeichen für einen Fehler innerhalb des Telekom-Netzes oder auf dem Kundenanschluss. Das Problem liegt höchstwahrscheinlich in der Verwendung eines nicht priorisierten Drittanbieter-SIP-Servers. Die Telefonie läuft ja über die VPN -Verbindung. LG ^Mirko
Hinweis:
Uneingeloggter Nutzer
von
Akzeptierte Lösung
akzeptiert von
vor 9 Tagen
Hallo @OptiBen, es wurden wirklich sehr umfangreiche Prüfungen vorgenommen.
Wir sehen auf allen Teilen der Strecke, auch auf den Übergängen in andere Netze, keine Drops, Errors oder Überlastungen zu allen Tageszeiten.
Was die Telefonie angeht:
Es gibt keine Anzeichen für einen Fehler innerhalb des Telekom-Netzes oder auf dem Kundenanschluss. Das Problem liegt höchstwahrscheinlich in der Verwendung eines nicht priorisierten Drittanbieter-SIP-Servers. Die Telefonie läuft ja über die VPN -Verbindung. LG ^Mirko
Hinweis:
5
von
vor 9 Tagen
@OptiBen, wie gesagt, wir haben alles sehr ausführlich geprüft. Im Netz der Telekom sind keine Fehler zu sehen. LG ^Mirko
@OptiBen
0
von
vor 9 Tagen
Hallo @Mirko St. , danke für die klare Rückmeldung.
Dann müssen wir hier leider einen Widerspruch festhalten: Die dokumentierte Messung vom 16.07. (16:18-16:20 Uhr MESZ) zeigt reproduzierbar Paketverlust über mehrere voneinander unabhängige Zielnetze gleichzeitig - darunter Ihre eigenen wsqm-Messserver in Düsseldorf, Frankfurt und Hamburg - während Google, Cloudflare und Quad9 in derselben Minute fehlerfrei bleiben. Diese Zielselektivität ist von der Anschlussseite aus nicht erzeugbar, und für die wsqm-Server verlässt der Weg das Telekom-Netz zu keinem Zeitpunkt. „Keine Fehler im Netz" und diese Werte lassen sich nicht beide gleichzeitig halten.
Mir ist klar, dass die aggregierte Telemetrie das nicht abbildet - dass sie es nicht zeigt, heißt aber nicht, dass es nicht auftritt.
Damit der Vorgang nachvollziehbar bleibt, zwei Bitten:
1. Bitte halten Sie das Ticket offen und geben Sie die Messung mit dem exakten Zeitfenster an das zuständige Netz-/Diagnoseteam weiter - nicht auf Forenebene abschließen.
2. Für eine gemeinsame Live-Korrelation stelle ich jederzeit ein Zeitfenster bereit.
Ich betrachte das Problem als unverändert offen und dokumentiere den weiteren Verlauf entsprechend.
Danke.
0
von
vor 4 Tagen
Hallo @OptiBen,
wie Mirko bereits schrieb, wurde die gesamten genannten Zeiträume als auch weitere durch die Kollegen betrachtete Zeiträume kontrolliert und es sind für uns, wie bereits oben erwähnt, weder auf den Teilstrecken als auch an den Übergängen keinerlei Überlast bzw. auch keine Drops.
Viele Grüße ^Daniel Wi.
Hinweis:
Uneingeloggter Nutzer
von
vor 9 Tagen
@OptiBen
Ich betrachte das Problem als unverändert offen und dokumentiere den weiteren Verlauf entsprechend.
Hallo @Mirko St. , danke für die klare Rückmeldung.
Dann müssen wir hier leider einen Widerspruch festhalten: Die dokumentierte Messung vom 16.07. (16:18-16:20 Uhr MESZ) zeigt reproduzierbar Paketverlust über mehrere voneinander unabhängige Zielnetze gleichzeitig - darunter Ihre eigenen wsqm-Messserver in Düsseldorf, Frankfurt und Hamburg - während Google, Cloudflare und Quad9 in derselben Minute fehlerfrei bleiben. Diese Zielselektivität ist von der Anschlussseite aus nicht erzeugbar, und für die wsqm-Server verlässt der Weg das Telekom-Netz zu keinem Zeitpunkt. „Keine Fehler im Netz" und diese Werte lassen sich nicht beide gleichzeitig halten.
Mir ist klar, dass die aggregierte Telemetrie das nicht abbildet - dass sie es nicht zeigt, heißt aber nicht, dass es nicht auftritt.
Damit der Vorgang nachvollziehbar bleibt, zwei Bitten:
1. Bitte halten Sie das Ticket offen und geben Sie die Messung mit dem exakten Zeitfenster an das zuständige Netz-/Diagnoseteam weiter - nicht auf Forenebene abschließen.
2. Für eine gemeinsame Live-Korrelation stelle ich jederzeit ein Zeitfenster bereit.
Ich betrachte das Problem als unverändert offen und dokumentiere den weiteren Verlauf entsprechend.
Danke.
dann wirst Du hier nicht weiter kommen und einen anderen Weg nutzen müssen 👍
Gruß Waage1969
0
0
Akzeptierte Lösung
akzeptiert von
vor 4 Tagen
Hallo @OptiBen,
wie Mirko bereits schrieb, wurde die gesamten genannten Zeiträume als auch weitere durch die Kollegen betrachtete Zeiträume kontrolliert und es sind für uns, wie bereits oben erwähnt, weder auf den Teilstrecken als auch an den Übergängen keinerlei Überlast bzw. auch keine Drops.
Viele Grüße ^Daniel Wi.
Hinweis:
0
Uneingeloggter Nutzer
von