Gelöst
Routing zu 1.1.1.1 (Cloudflare DNS) mit hohen Paketverlusten
vor 2 Stunden
Ich habe seit ca. 12 Stunden andauernde Routing-Probleme zu 1.1.1.1 (Cloudflare DNS).
In der Praxis sieht dies in etwa so aus:
mtr -r 1.1.1.1
Start: 2025-12-04T06:41:51+0100
HOST: antares Loss% Snt Last Avg Best Wrst StDev
1.|-- rtr1.jlr.babioch.de 0.0% 10 3.6 6.0 3.4 15.5 3.9
2.|-- p3e9bf3c6.dip0.t-ipconnec 0.0% 10 16.7 14.4 5.1 22.8 6.0
3.|-- f-ed13-i.F.DE.NET. DTAG .DE 0.0% 10 20.4 19.6 11.8 24.5 4.2
4.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
5.|-- if-bundle-66-2.qcore2.fnm 70.0% 10 29.8 25.0 18.0 29.8 6.2
6.|-- if-bundle-11-2.qcore2.f2c 0.0% 10 19.7 23.0 16.4 36.2 6.9
7.|-- 162.158.84.121 0.0% 10 13.8 12.8 11.1 16.1 1.8
8.|-- one.one.one.one 0.0% 10 35.8 34.4 24.5 41.3 5.4
Insbesondere folgende Knotenpunkte haben dabei 80-100% Paketverlust:
if-bundle-66-2.qcore2.fnm-frankfurt.as6453.net 85.3% Loss
if-bundle-11-2.qcore2.f2c-frankfurt.as6453.net 23.2% Loss
Damit ist die Nutzung der Cloudflare DNS Server nicht möglich. Andere DNS Anbieter funktionieren problemlos (9.9.9.9 z.B.).
Bei den o.g. Knotenpunkten scheint es sich um Transitnetze von AS6453 (Tata Communications) zu handeln.
Leider ist es quasi unmöglich sich hier direkt an die betreffenden Netzwerk-Techniker zu wenden. Ihre Klickpfade (Störung melden) sind quasi nutzlos, wenn man als Techniker technische Meldungen an andere Techniker melden möchte, sodass das Problem angegangen werden kann. Ich möchte keine kaputten Geräte, oder Probleme mit meiner Fritzbox melden, es handelt sich hier um ein tiefergehendes Problem auf Netzwerk-Ebene.
65
0
9
Das könnte Ihnen auch weiterhelfen
6278
4
56
in
637
0
4
534
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 2 Stunden
Paketverlust zu one.one.one.one ist 0%, lese ich.
Dass zwischendurch einige Beteiligte keinen Bock oder keine Zeit haben, Pings zu beantworten, ist normal.
0
vor 2 Stunden
es handelt sich hier um ein tiefergehendes Problem auf Netzwerk-Ebene.
Ich habe seit ca. 12 Stunden andauernde Routing-Probleme zu 1.1.1.1 (Cloudflare DNS).
In der Praxis sieht dies in etwa so aus:
mtr -r 1.1.1.1
Start: 2025-12-04T06:41:51+0100
HOST: antares Loss% Snt Last Avg Best Wrst StDev
1.|-- rtr1.jlr.babioch.de 0.0% 10 3.6 6.0 3.4 15.5 3.9
2.|-- p3e9bf3c6.dip0.t-ipconnec 0.0% 10 16.7 14.4 5.1 22.8 6.0
3.|-- f-ed13-i.F.DE.NET. DTAG .DE 0.0% 10 20.4 19.6 11.8 24.5 4.2
4.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
5.|-- if-bundle-66-2.qcore2.fnm 70.0% 10 29.8 25.0 18.0 29.8 6.2
6.|-- if-bundle-11-2.qcore2.f2c 0.0% 10 19.7 23.0 16.4 36.2 6.9
7.|-- 162.158.84.121 0.0% 10 13.8 12.8 11.1 16.1 1.8
8.|-- one.one.one.one 0.0% 10 35.8 34.4 24.5 41.3 5.4
Insbesondere folgende Knotenpunkte haben dabei 80-100% Paketverlust:
if-bundle-66-2.qcore2.fnm-frankfurt.as6453.net 85.3% Loss
if-bundle-11-2.qcore2.f2c-frankfurt.as6453.net 23.2% Loss
Damit ist die Nutzung der Cloudflare DNS Server nicht möglich. Andere DNS Anbieter funktionieren problemlos (9.9.9.9 z.B.).
Bei den o.g. Knotenpunkten scheint es sich um Transitnetze von AS6453 (Tata Communications) zu handeln.
Leider ist es quasi unmöglich sich hier direkt an die betreffenden Netzwerk-Techniker zu wenden. Ihre Klickpfade (Störung melden) sind quasi nutzlos, wenn man als Techniker technische Meldungen an andere Techniker melden möchte, sodass das Problem angegangen werden kann. Ich möchte keine kaputten Geräte, oder Probleme mit meiner Fritzbox melden, es handelt sich hier um ein tiefergehendes Problem auf Netzwerk-Ebene.
in erster Linie um ein Verständnisproblem auf deiner Seite, genau deshalb wäre eine direkte Kommunikation mit den Technikern nicht zielführend
0
vor 2 Stunden
Bei den o.g. Knotenpunkten scheint es sich um Transitnetze von AS6453 (Tata Communications) zu handeln.
Leider ist es quasi unmöglich sich hier direkt an die betreffenden Netzwerk-Techniker zu wenden. Ihre Klickpfade (Störung melden) sind quasi nutzlos
Ich habe seit ca. 12 Stunden andauernde Routing-Probleme zu 1.1.1.1 (Cloudflare DNS).
In der Praxis sieht dies in etwa so aus:
mtr -r 1.1.1.1
Start: 2025-12-04T06:41:51+0100
HOST: antares Loss% Snt Last Avg Best Wrst StDev
1.|-- rtr1.jlr.babioch.de 0.0% 10 3.6 6.0 3.4 15.5 3.9
2.|-- p3e9bf3c6.dip0.t-ipconnec 0.0% 10 16.7 14.4 5.1 22.8 6.0
3.|-- f-ed13-i.F.DE.NET. DTAG .DE 0.0% 10 20.4 19.6 11.8 24.5 4.2
4.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
5.|-- if-bundle-66-2.qcore2.fnm 70.0% 10 29.8 25.0 18.0 29.8 6.2
6.|-- if-bundle-11-2.qcore2.f2c 0.0% 10 19.7 23.0 16.4 36.2 6.9
7.|-- 162.158.84.121 0.0% 10 13.8 12.8 11.1 16.1 1.8
8.|-- one.one.one.one 0.0% 10 35.8 34.4 24.5 41.3 5.4
Insbesondere folgende Knotenpunkte haben dabei 80-100% Paketverlust:
if-bundle-66-2.qcore2.fnm-frankfurt.as6453.net 85.3% Loss
if-bundle-11-2.qcore2.f2c-frankfurt.as6453.net 23.2% Loss
Damit ist die Nutzung der Cloudflare DNS Server nicht möglich. Andere DNS Anbieter funktionieren problemlos (9.9.9.9 z.B.).
Bei den o.g. Knotenpunkten scheint es sich um Transitnetze von AS6453 (Tata Communications) zu handeln.
Leider ist es quasi unmöglich sich hier direkt an die betreffenden Netzwerk-Techniker zu wenden. Ihre Klickpfade (Störung melden) sind quasi nutzlos, wenn man als Techniker technische Meldungen an andere Techniker melden möchte, sodass das Problem angegangen werden kann. Ich möchte keine kaputten Geräte, oder Probleme mit meiner Fritzbox melden, es handelt sich hier um ein tiefergehendes Problem auf Netzwerk-Ebene.
Ich kenne auch keine Kontaktmöglichkeiten zu den Tata Communications Leuten.
Ansonsten muss Dir klar sein, dass Deine "Messung" für ganz andere IP-Pakete gemacht ist als die IP-Pakete zum DNS, um die es Dir geht.
Und diese ganz andere IP-Pakete werden von den beteiligten Boxen auch anders behandelt.
So ähnlich wie wenn Dein heimischer Router von außen nicht auf irgendwelche Ping reagiert - wenn aber ein angeforderter Netflix Stream ankommt, dann wird der sehr wohl durchgelassen.
Es ist bestenfalls indikativ, dass ein Server oder Gateway MÖGLICHERWEISE auch ein Problem auf für den "normalen" Traffic zum DNS haben könnte.
0
0
vor 2 Stunden
An die Schlauberger:
Ich bin vom Fach und weiß, dass mtr / traceroute auf anderer Ebene funktioniert als DNS selbst . Es sind hier jedoch keine ICMP Paketverluste, DNS Anfragen laufen nämlich ins Leere. Gestern Nachmittag klappte es noch.
dig telekom.de @1.1.1.1 ;; communications error to 1.1.1.1#53: timed out ;; communications error to 1.1.1.1#53: timed out ;; communications error to 1.1.1.1#53: timed out
dig telekom.de @9.9.9.9
; <<>> DiG 9.20.16 <<>> telekom.de @9.9.9.9
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26556
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;telekom.de. IN A
;; ANSWER SECTION:
telekom.de. 98 IN A 3.67.146.210
telekom.de. 98 IN A 63.176.75.230
telekom.de. 98 IN A 3.75.56.200
;; Query time: 14 msec
;; SERVER: 9.9.9.9#53(9.9.9.9) (UDP)
;; WHEN: Thu Dec 04 07:39:53 CET 2025
;; MSG SIZE rcvd: 87
0
1
von
vor einer Stunde
An die Schlauberger:
An die Schlauberger:
Ich bin vom Fach und weiß, dass mtr / traceroute auf anderer Ebene funktioniert als DNS selbst . Es sind hier jedoch keine ICMP Paketverluste, DNS Anfragen laufen nämlich ins Leere. Gestern Nachmittag klappte es noch.
dig telekom.de @1.1.1.1 ;; communications error to 1.1.1.1#53: timed out ;; communications error to 1.1.1.1#53: timed out ;; communications error to 1.1.1.1#53: timed out
dig telekom.de @9.9.9.9
; <<>> DiG 9.20.16 <<>> telekom.de @9.9.9.9
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26556
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;telekom.de. IN A
;; ANSWER SECTION:
telekom.de. 98 IN A 3.67.146.210
telekom.de. 98 IN A 63.176.75.230
telekom.de. 98 IN A 3.75.56.200
;; Query time: 14 msec
;; SERVER: 9.9.9.9#53(9.9.9.9) (UDP)
;; WHEN: Thu Dec 04 07:39:53 CET 2025
;; MSG SIZE rcvd: 87
Ignorier sie, sämtliche Diskussionen sind überflüssig und nicht zielführend.
Ich kann das Problem 100% bestätigen, 1.1.1.1, 1.0.0.1, 1.1.1.2, sind alle nicht vernünftig erreichbar.
Bleibt nur der Wechsel zu einem ISP - die Telekom ist ja leider keiner.
0
Uneingeloggter Nutzer
von
Offizielle Lösung
akzeptiert von
vor einer Stunde
@Karol Babioch
Zum Thema Peering findest Du hier Informationen
-Klick-
VPN versucht?
Ignorier sie, sämtliche Diskussionen sind überflüssig und nicht zielführend.
Ich kann das Problem 100% bestätigen, 1.1.1.1, 1.0.0.1, 1.1.1.2, sind alle nicht vernünftig erreichbar.
Bleibt nur der Wechsel zu einem ISP - die Telekom ist ja leider keiner.
An die Schlauberger:
An die Schlauberger:
Ich bin vom Fach und weiß, dass mtr / traceroute auf anderer Ebene funktioniert als DNS selbst . Es sind hier jedoch keine ICMP Paketverluste, DNS Anfragen laufen nämlich ins Leere. Gestern Nachmittag klappte es noch.
dig telekom.de @1.1.1.1 ;; communications error to 1.1.1.1#53: timed out ;; communications error to 1.1.1.1#53: timed out ;; communications error to 1.1.1.1#53: timed out
dig telekom.de @9.9.9.9
; <<>> DiG 9.20.16 <<>> telekom.de @9.9.9.9
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26556
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;telekom.de. IN A
;; ANSWER SECTION:
telekom.de. 98 IN A 3.67.146.210
telekom.de. 98 IN A 63.176.75.230
telekom.de. 98 IN A 3.75.56.200
;; Query time: 14 msec
;; SERVER: 9.9.9.9#53(9.9.9.9) (UDP)
;; WHEN: Thu Dec 04 07:39:53 CET 2025
;; MSG SIZE rcvd: 87
Ignorier sie, sämtliche Diskussionen sind überflüssig und nicht zielführend.
Ich kann das Problem 100% bestätigen, 1.1.1.1, 1.0.0.1, 1.1.1.2, sind alle nicht vernünftig erreichbar.
Bleibt nur der Wechsel zu einem ISP - die Telekom ist ja leider keiner.
aja,
3
von
vor 55 Minuten
@Karol Babioch
Zum Thema Peering findest Du hier Informationen
-Klick-
@Karol Babioch
Zum Thema Peering findest Du hier Informationen
-Klick-
VPN versucht?
Ignorier sie, sämtliche Diskussionen sind überflüssig und nicht zielführend.
Ich kann das Problem 100% bestätigen, 1.1.1.1, 1.0.0.1, 1.1.1.2, sind alle nicht vernünftig erreichbar.
Bleibt nur der Wechsel zu einem ISP - die Telekom ist ja leider keiner.
aja,
Ah, der gute alte Artikel mit den Unwahrheiten ist immer noch online?
"Nein, die Telekom blockiert keinerlei Dienste oder Internetseiten, weder im DNS noch im Datenpfad."
Quad9:
von
vor 54 Minuten
Ah, der gute alte Artikel mit den Unwahrheiten ist immer noch online?
@Karol Babioch
Zum Thema Peering findest Du hier Informationen
-Klick-
Ah, der gute alte Artikel mit den Unwahrheiten ist immer noch online?
"Nein, die Telekom blockiert keinerlei Dienste oder Internetseiten, weder im DNS noch im Datenpfad."
Quad9:
Keine Unwahrheit, sondern Wahrheit 😉
von
vor 50 Minuten
Keine Unwahrheit, sondern Wahrheit 😉
Ah, der gute alte Artikel mit den Unwahrheiten ist immer noch online?
Keine Unwahrheit, sondern Wahrheit 😉
Dann hast Du vermutlich meinen vorherigen Post nicht ganz gelesen, oder Verständnisprobleme. 😉
Uneingeloggter Nutzer
von
Uneingeloggter Nutzer
von