20
Routingprobleme bei der Telekom?
Hallo,
knoble gerade hier an einem Problem:
VDSL 50 Anschluss der Telekom über Fritzbox 7490 kommt nicht zu allen IP Addressen:
8.8.8.8 geht
1.1.1.1 geht nicht
ein Tracert zeigt timeouts ab dem Ersten Telekom Gateway an.
Hat jemand ein ähnliches Problem?
knoble gerade hier an einem Problem:
VDSL 50 Anschluss der Telekom über Fritzbox 7490 kommt nicht zu allen IP Addressen:
8.8.8.8 geht
1.1.1.1 geht nicht
ein Tracert zeigt timeouts ab dem Ersten Telekom Gateway an.
Hat jemand ein ähnliches Problem?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 444293
Url: https://administrator.de/contentid/444293
Ausgedruckt am: 22.11.2024 um 02:11 Uhr
20 Kommentare
Neuester Kommentar
Kann das von hier (Wuppertal) nicht nachvollziehen, aus anderen Netzen auch nicht.
NACHTRAG:
Das scheint auch generell bei der Telekom keine echte Störung zu sein, zumindest dieser Karte nach zu urteilen
NACHTRAG:
Das scheint auch generell bei der Telekom keine echte Störung zu sein, zumindest dieser Karte nach zu urteilen
Hier ist beides o.k.
lks
PS: PLZ 749xx Vorwahl 0726x
lks
PS: PLZ 749xx Vorwahl 0726x
Hallo,
auch bei mir kein Problem.
auch bei mir kein Problem.
Ich schließe mich meinen Vorrednern an.
Hallo,
die Aufgabe eines Routers ist, Datenpakete weiterzuleiten und nicht, irgendwelche PING-Requests zu beantworten.
Es gibt diverse Szenarien, in denen die ICMP-Anfragen tatsächlich verworfen werden.
Gruß,
Jörg
die Aufgabe eines Routers ist, Datenpakete weiterzuleiten und nicht, irgendwelche PING-Requests zu beantworten.
Es gibt diverse Szenarien, in denen die ICMP-Anfragen tatsächlich verworfen werden.
Gruß,
Jörg
Hallo,
sowas hatte ich schon zweimal:
bei einem Business-Telekom-Anschluss mit fester IP (die von der Telekom per DHCP vergeben wird) wurde die Verbindung hergestellt, aber das Ping lief nur bis zum ersten Telekom-Server.
Das Problem war ein "Einwahlserver" der Telekom, der irgendetwas fehlerhaft verteilte. Der normale Telekom-Support war völlig überfordert (man erklärte mir bsplw dass eine feste IP kein DHCP niemals nicht hat) - irgendwer im second level hatte dann aber was gehört von einem Serverproblem und nach einer Weile war das Problem behoben. Das scheint Anschlüsse ohne feste IP nicht zu betreffen.
Abhilfe: nicht bei sich selbst den Fehler suchen, Störungsmeldung, der Telekom sagen dass diese ganzen Lämpchen am Router lustig blinken und wenn die dann Sagen, dass nur Fritzbox & TelekomRouter supportet werden freundlich darauf insistieren, dass wenn der Ping bis ins Telekomnetz gelangt - der Fehler bei der Telekom liegen muss.
Grüße
lcer
sowas hatte ich schon zweimal:
bei einem Business-Telekom-Anschluss mit fester IP (die von der Telekom per DHCP vergeben wird) wurde die Verbindung hergestellt, aber das Ping lief nur bis zum ersten Telekom-Server.
Das Problem war ein "Einwahlserver" der Telekom, der irgendetwas fehlerhaft verteilte. Der normale Telekom-Support war völlig überfordert (man erklärte mir bsplw dass eine feste IP kein DHCP niemals nicht hat) - irgendwer im second level hatte dann aber was gehört von einem Serverproblem und nach einer Weile war das Problem behoben. Das scheint Anschlüsse ohne feste IP nicht zu betreffen.
Abhilfe: nicht bei sich selbst den Fehler suchen, Störungsmeldung, der Telekom sagen dass diese ganzen Lämpchen am Router lustig blinken und wenn die dann Sagen, dass nur Fritzbox & TelekomRouter supportet werden freundlich darauf insistieren, dass wenn der Ping bis ins Telekomnetz gelangt - der Fehler bei der Telekom liegen muss.
Grüße
lcer
Moin,
auch hier (Südbayern) z.Zt. keine solchen Probleme...
Schönes WE
auch hier (Südbayern) z.Zt. keine solchen Probleme...
Schönes WE
Hallo,
Stand das in Grimms Märchen?
Bei meinen Kunden gehen die sogar auf den LANCOM wenn ich das will. Es hängt immer davon ab, wie viel Kompetenz man vermittelt
Gruß,
Jörg
Stand das in Grimms Märchen?
Bei meinen Kunden gehen die sogar auf den LANCOM wenn ich das will. Es hängt immer davon ab, wie viel Kompetenz man vermittelt
Gruß,
Jörg
Hallo,
Nein, aber der Support neigt zum Märchenerzählen.
Wie gesagt, mir ist es nicht nur erst einmal passiert, dass der freundliche Mitarbeiter mich fragte, ob die grüne Lampe am Router blinkt, nachdem ich ihm gesagt hatte, dass der Router eine IP am WAN erhält und ich bis ins Telekom-netz pingen kann. Aber vielleicht liegt das auch immer daran, welchem Support-Center man zugeordnet wird.
Grüße
lcer
Nein, aber der Support neigt zum Märchenerzählen.
Wie gesagt, mir ist es nicht nur erst einmal passiert, dass der freundliche Mitarbeiter mich fragte, ob die grüne Lampe am Router blinkt, nachdem ich ihm gesagt hatte, dass der Router eine IP am WAN erhält und ich bis ins Telekom-netz pingen kann. Aber vielleicht liegt das auch immer daran, welchem Support-Center man zugeordnet wird.
Grüße
lcer
Ich schließe mich dem TE an, wobei es bei mir ganz speziell und kein unbekanntes Problem ist:
Mein Magenta Giga-Anschluss läuft abends und nachts in die Peering-Streitigkeiten von Hetzner und der Telekom rein. Heißt, dass ich nur morgends und tagsüber eine stabile und unterbrechungsfreie Verbindung zu Hetzner habe.
Kurioserweise haben andere Telekom-Anschlüsse in der näheren Umgebung keine Probleme um die Uhrzeit.
Router ist ein Speedport Smart 3, wenn ich das nächste Mal eine Zyxel VPN100 in der Hand habe, teste ich damit, wobei ich nicht denke, dass es am Routermodell liegt.
Mein Magenta Giga-Anschluss läuft abends und nachts in die Peering-Streitigkeiten von Hetzner und der Telekom rein. Heißt, dass ich nur morgends und tagsüber eine stabile und unterbrechungsfreie Verbindung zu Hetzner habe.
Kurioserweise haben andere Telekom-Anschlüsse in der näheren Umgebung keine Probleme um die Uhrzeit.
Router ist ein Speedport Smart 3, wenn ich das nächste Mal eine Zyxel VPN100 in der Hand habe, teste ich damit, wobei ich nicht denke, dass es am Routermodell liegt.
Zitat von @117471:
die Aufgabe eines Routers ist, Datenpakete weiterzuleiten und nicht, irgendwelche PING-Requests zu beantworten.
die Aufgabe eines Routers ist, Datenpakete weiterzuleiten und nicht, irgendwelche PING-Requests zu beantworten.
Das gilt dann aber nur für einzelne Hops (wie bei mir Hop 3), die Pakete werden dann aber definitiv weiter geroutet und das Ziel sollte irgendwann antworten.
Außerdem gehe ich davon aus, dass der TO überhaupt erst Traceroutes und Pings gemacht hat, weil auch die DNS-Anfragen nicht mehr beantwortet wurden - das lässt sich mit "Router antworten manchmal nicht aif Ping" schlecht erklären
Zitat von @lcer00:
Hallo,
Nein, aber der Support neigt zum Märchenerzählen.
Wie gesagt, mir ist es nicht nur erst einmal passiert, dass der freundliche Mitarbeiter mich fragte, ob die grüne Lampe am Router blinkt, nachdem ich ihm gesagt hatte, dass der Router eine IP am WAN erhält und ich bis ins Telekom-netz pingen kann. Aber vielleicht liegt das auch immer daran, welchem Support-Center man zugeordnet wird.
Grüße
lcer
Hallo,
Nein, aber der Support neigt zum Märchenerzählen.
Wie gesagt, mir ist es nicht nur erst einmal passiert, dass der freundliche Mitarbeiter mich fragte, ob die grüne Lampe am Router blinkt, nachdem ich ihm gesagt hatte, dass der Router eine IP am WAN erhält und ich bis ins Telekom-netz pingen kann. Aber vielleicht liegt das auch immer daran, welchem Support-Center man zugeordnet wird.
Grüße
lcer
Support-Center (aus internen Quellen) gibt es zumindest in Österreich nur eines. Ich muss die Jungs und Mädels dort außerdem ein klein wenig verteidigen, weil ich ein paar persönlich kenne: Die sind die ersten an der Front. 1st-Level, extrem viele System zu bedienen, hohe Fluktuation, die haben auch nur den Blick bis kurz hinters FrontEnd.
Jeder 1st-Level-Mitarbeiter der mehr Einblick/Know-How hat, schaut, dass er möglichst schnell aufsteigen kann oder wechselt den Bereich / das Unternehmen. Nicht nur, weil die Bezahlung dort eher schlecht ist, sondern auch weil die Kunden immer gleich einen Wunderwutzi erwarten. Zerrt ganz leicht an den Nerven.
Du bist einer der sich offensichtlich auskennt, von 100ten die täglich anrufen, die 0 Plan von der Materie haben und mit "Es geht nicht" glauben sie hätten eine volle Fehlerbeschreibung abgegeben.
Also vielleicht etwas cool bleiben. Die tun was sie können. Zumindest die, die ich kenne.
Hallo zusammen,
vielleicht ist dieser Hinweis hilfreich:
zu finden unter
https://www.cloudflarestatus.com/#past-incidents
vielleicht ist dieser Hinweis hilfreich:
Apr 26, 2019
Cloudflare 1.1.1.1 resolver availability issue
Resolved - 1.1.1.1 was partially unavailable because of an erroneous BGP blackhole configuration update by an ISP that was propagated by a
Tier 1 provider. Note that our users who were using other IP addresses like 1.0.0.1 still could use the service. The error has been resolved and
1.1.1.1 has resumed normal operation.
Apr 26, 17:36 UTC
Cloudflare 1.1.1.1 resolver availability issue
Resolved - 1.1.1.1 was partially unavailable because of an erroneous BGP blackhole configuration update by an ISP that was propagated by a
Tier 1 provider. Note that our users who were using other IP addresses like 1.0.0.1 still could use the service. The error has been resolved and
1.1.1.1 has resumed normal operation.
Apr 26, 17:36 UTC
zu finden unter
https://www.cloudflarestatus.com/#past-incidents
Blackholing würde tatsächlich zum Phänomen passen, dass die Pakete ab dem ersten Telekom-Hop verworfen werden.
Interessanterweise kann ich diese Blackhole-Route in unseren Logs finden. Normalerweise protokollieren wir alle empfangenen Blackhole-Routen - diese haben wir aber weder von der DTAG und sonst auch niemandem erhalten. Das spricht dagegen, dass die DTAG selbst diese Blackhole-Route erzeugt hat.
Da die DTAG keine Blackhole-Routen mit einer Präfixlänge < /32 akzeptiert, muss die Blackhole-Route auch spezifisch die 1.1.1.1/32 betroffen haben.
Zudem verifiziert die Telekom die empfangenen Routen zumindest gegen ROA und normalerweise müssen fremde ASN auch explizit autorisiert werden, um Blackhole-Routen für Cloudflare weiterzuleiten.
Jetzt bin ich total hibbelig und will wissen, WER diese Blackhole-Route dort eingeworfen hat...
Interessanterweise kann ich diese Blackhole-Route in unseren Logs finden. Normalerweise protokollieren wir alle empfangenen Blackhole-Routen - diese haben wir aber weder von der DTAG und sonst auch niemandem erhalten. Das spricht dagegen, dass die DTAG selbst diese Blackhole-Route erzeugt hat.
Da die DTAG keine Blackhole-Routen mit einer Präfixlänge < /32 akzeptiert, muss die Blackhole-Route auch spezifisch die 1.1.1.1/32 betroffen haben.
Zudem verifiziert die Telekom die empfangenen Routen zumindest gegen ROA und normalerweise müssen fremde ASN auch explizit autorisiert werden, um Blackhole-Routen für Cloudflare weiterzuleiten.
Jetzt bin ich total hibbelig und will wissen, WER diese Blackhole-Route dort eingeworfen hat...
Hallo,
das Problem existiert weiterhin. Die Telekom hat keine Lust das Problem zu beheben und schiebt es auf die Kunden Hardware.
Zumindest geht das Telefon wieder seit ich auf dem Router IPv6 eingeschaltet habe.
Die 1.1.1.1 war nur ein Beispiel. Wenn ein Anschluss bei mir nicht geht ist meine Übliche Vorgangsweise Ping zu:
Damit erschlägt man schon 90 Prozent der Probleme an einem 0815 Anschluss.
das Problem existiert weiterhin. Die Telekom hat keine Lust das Problem zu beheben und schiebt es auf die Kunden Hardware.
Zumindest geht das Telefon wieder seit ich auf dem Router IPv6 eingeschaltet habe.
Die 1.1.1.1 war nur ein Beispiel. Wenn ein Anschluss bei mir nicht geht ist meine Übliche Vorgangsweise Ping zu:
- 8.8.8.8
- 1.1.1.1
- google.com
Damit erschlägt man schon 90 Prozent der Probleme an einem 0815 Anschluss.
Hallo,
Und warum pingst Du dorthin?
Damit löst Du sicherlich keine Probleme und Du gewinnst auch keine Erkenntnisse aus den Ping-Anfragen.
Genau so gut könntest Du dein Hintergrundbild ändern.
Gruß,
Jörg
Zitat von @Phill93:
Wenn ein Anschluss bei mir nicht geht ist meine Übliche Vorgangsweise Ping zu:
Wenn ein Anschluss bei mir nicht geht ist meine Übliche Vorgangsweise Ping zu:
- 8.8.8.8
- 1.1.1.1
- google.com
Und warum pingst Du dorthin?
Damit löst Du sicherlich keine Probleme und Du gewinnst auch keine Erkenntnisse aus den Ping-Anfragen.
Genau so gut könntest Du dein Hintergrundbild ändern.
Gruß,
Jörg
Ping zu 8.8.8.8, 1.1.1.1: IPv4 ins Internet funktioniert
Ping zu google.com: DNS funktioniert.
Das Funktioniert unter jedem Betriebsystem gleich und das kann selbst ein Laie wenn ich ihm das über Telefon durchgebe. So kann man schon mal einschätzen wo man weitersuchen muss.
Je nach Ergebniss kommen dann komplexere Dinge (für Laien) wie ein Ping zum Gateway, etc.
Gruß
Phill93
Ping zu google.com: DNS funktioniert.
Das Funktioniert unter jedem Betriebsystem gleich und das kann selbst ein Laie wenn ich ihm das über Telefon durchgebe. So kann man schon mal einschätzen wo man weitersuchen muss.
Je nach Ergebniss kommen dann komplexere Dinge (für Laien) wie ein Ping zum Gateway, etc.
Gruß
Phill93
Mal ganz profan deine Verbindung getrennt und neu aufgebaut, um eine neue IP zu erhalten?
Dass dein Traceroute nach dem ersten DTAG-Hop abbricht, muss nicht zwingend ein ausgehendes Problem sein, es kann auch ein Routingproblem von der DTAG zu dir sein.
Insbesondere, wenn du im Moment eine IP hast, die mit 46.x.x.x beginnt, kann es schlicht sein, dass sie das jetzt woanders einsetzen und dein Anschluss die Verbindungstrennung nicht mitbekommen hat.
Dass dein Traceroute nach dem ersten DTAG-Hop abbricht, muss nicht zwingend ein ausgehendes Problem sein, es kann auch ein Routingproblem von der DTAG zu dir sein.
Insbesondere, wenn du im Moment eine IP hast, die mit 46.x.x.x beginnt, kann es schlicht sein, dass sie das jetzt woanders einsetzen und dein Anschluss die Verbindungstrennung nicht mitbekommen hat.
Zitat von @LordGurke:
Mal ganz profan deine Verbindung getrennt und neu aufgebaut, um eine neue IP zu erhalten?
Dass dein Traceroute nach dem ersten DTAG-Hop abbricht, muss nicht zwingend ein ausgehendes Problem sein, es kann auch ein Routingproblem von der DTAG zu dir sein.
Insbesondere, wenn du im Moment eine IP hast, die mit 46.x.x.x beginnt, kann es schlicht sein, dass sie das jetzt woanders einsetzen und dein Anschluss die Verbindungstrennung nicht mitbekommen hat.
Mal ganz profan deine Verbindung getrennt und neu aufgebaut, um eine neue IP zu erhalten?
Dass dein Traceroute nach dem ersten DTAG-Hop abbricht, muss nicht zwingend ein ausgehendes Problem sein, es kann auch ein Routingproblem von der DTAG zu dir sein.
Insbesondere, wenn du im Moment eine IP hast, die mit 46.x.x.x beginnt, kann es schlicht sein, dass sie das jetzt woanders einsetzen und dein Anschluss die Verbindungstrennung nicht mitbekommen hat.
Wenn er zu google tracen kann aber zu cloudfare nicht, so ist das ein ausgehndes Routingproblem bei der DTAG, denn sonst sollte der trace auch zu google nicht gehen, wenn es nur die Rückroute zu ihm wäre.
lks
Zitat von @Lochkartenstanzer:
Wenn er zu google tracen kann aber zu cloudfare nicht, so ist das ein ausgehndes Routingproblem bei der DTAG, denn sonst sollte der trace auch zu google nicht gehen, wenn es nur die Rückroute zu ihm wäre.
Wenn er zu google tracen kann aber zu cloudfare nicht, so ist das ein ausgehndes Routingproblem bei der DTAG, denn sonst sollte der trace auch zu google nicht gehen, wenn es nur die Rückroute zu ihm wäre.
Das wäre dann richtig, wenn man davon ausgeht, dass es nur wenige Routingwege gäbe.
Da bei der DTAG aber tatsächlich nach dem ersten Hop eine recht große Anzahl unterschiedlicher Router auftaucht, ist es möglich, dass durch unterschiedliche Gewichtungen von Routen und eventueller Aggregation (das wissen wir alles nicht, wie es bei der DTAG in der Routingtabelle aussieht) zu fehlerhaftem Routing in Richtung des TO kommt.
Beispiele:
~# traceroute -I -q 1 -A 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 62.155.244.139 (62.155.244.139) [AS3320] 18.649 ms
2 217.0.198.14 (217.0.198.14) [AS3320] 26.078 ms <----
3 80.150.170.30 (80.150.170.30) [AS3320] 27.557 ms
4 108.170.251.193 (108.170.251.193) [AS15169] 23.780 ms
5 108.170.233.37 (108.170.233.37) [AS15169] 23.515 ms
6 google-public-dns-a.google.com (8.8.8.8) [AS15169] 23.968 ms~# traceroute -I -q 1 -A administrator.de.
traceroute to administrator.de. (82.149.225.19), 30 hops max, 60 byte packets
1 62.155.244.139 (62.155.244.139) [AS3320] 18.203 ms
2 217.239.48.166 (217.239.48.166) [AS3320] 23.156 ms <---
3 194.25.211.99 (194.25.211.99) [AS3320] 23.603 ms
4 ae0-3003.er1.fra1.aixit.net (83.141.5.106) [AS29551] 23.580 ms
5 www.administrator.de (82.149.225.19) [AS29551] 23.793 ms~# traceroute -I -q 1 -A 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
1 62.155.244.139 (62.155.244.139) [AS3320] 18.557 ms
2 d-ed5-i.D.DE.NET.DTAG.DE (217.5.71.50) [AS3320] 19.809 ms <----
3 *
4 ae-2-3203.edge5.Dusseldorf1.Level3.net (4.69.136.250) [AS3356] 38.356 ms
5 212.162.30.242 (212.162.30.242) [AS3356/AS9057] 26.165 ms
6 one.one.one.one (1.1.1.1) [AS13335] 25.068 msWenn bei der DTAG intern mit OSPF oder (deutlich wahrscheinlicher) IS-IS gearbeitet wird, würden normalerweise alle /32-Routen der einzelnen PPPoE-Sessions in die Routingtabellen aller Router gespült. Dann müssten aber alle Router bei der DTAG zig Millionen Routen halten, was aus naheliegenden Gründen vermieden wird.
Stattdessen wird man das Netz in viele kleine Zonen unterteilen, bei denen innerhalb der Zonen zwar eine tatsächlich vollständige Routingtabelle existiert, aber außerhalb der Zonen nur aggregierte Routen weitergegeben werden.
Hat der TO nun also eine Adresse, welche nicht mehr zu ihm geroutet wird, hängt es davon ab ob seine Pakete diese kleine Zone verlassen (dann fehlt die Rückroute) oder nicht (dann ist die Route da).
Diese Zonen sind nicht unbedingt geographisch zu sehen sondern eher darauf ausgelegt, wie schnell die Pakete an die Backbone-Router der Telekom gehen (die vermutlich nur die aggregierten internen Routen enthalten).
Jenachdem, wie innerhalb dieser Router dann die Routen gewichtet werden, kommt entweder noch eine Verbindung zustande - oder eben nicht.
Das ist alles rein spekulativ, ich gehe aber einfach mal davon aus, dass die Telekom nicht alles grundsätzlich anders macht als andere Provider, deren internes Routing ich sehen durfte
Der TO kann ja seine eigene IP mal hierüber von verschiedenen Standorten innerhalb der DTAG versuchen zu erreichen:
https://f-lga1.f.de.net.dtag.de/index.php?pageid=traceroute
Die Traceroutes erfolgen per UDP, was ein bisschen doof ist, falls eine Firewall da sitzt, die UDP einfach verschluckt - mit FritzBoxen funktioniert das aber in der Regel problemlos.
Kurzum:
Ja, es kann natürlich auch am ausgehenden Routing liegen. Aber das wäre recht deutlich auf den ATLAS-Messungen aufgefallen.
Wäre das ausgehende Routing gestört, beträfe dies eine höhere Anzahl Anschlüsse und es hätte wenigstens einen bei der ATLAS-Messung geben müssen, der die 1.1.1.1 nicht erreichen konnte.
Umgekehrt fällt eine möglicherweise fehlerhaft geroutete IP-Adresse eines einzelnen Anschlusses bei sowas schlicht nicht auf.
Die angesprochenen IP-Adressen beginnend mit 46.x.x.x habe ich deshalb erwähnt, weil diese zumindest teilweise als "Migration"-Pool ausgewiesen sind. Diese erhält man nur über einen recht kurzen Zeitraum, dann wird normalerweise eines Nachts die Verbindung durch die Telekom getrennt und danach erhält man wieder "normale" IP-Adressen.
Falls diese Trennung aus irgendeinem Grund bei dem Anschluss nicht geklappt hat und die Telekom dieses Migrations-Netz inzwischen woanders routet, wäre das zumindest eine plausible Erklärung dafür.
