---

@Gelöschter Nutzer@  schrieb:

@erik2k3

 

Was sagt der ASUS-Support dazu?

 

Hat der verwendete Router die "neueste" Firmware

Version 1.00.14_build508 2017/05/15?

---

FW : v1.00.14 build508 May. 5, 2017

und warum soll der ASUS Support etwas dazu sagen wenn : 

DSL-Uplink stabil ist

DSL modulation
VDSL2
Annex mode
ANNEX B
DSL Uptime
4 days 2 hours 32 minute(s) 9 seconds

Ich immer an den gateway ran komme ?

Jeder trace kommt immer so weit : 

PS C:\Users\x-ray> date;tracert google.com
02 July 2018 19:44:12
Unable to resolve target system name google.com. <<<<< aha , DNS request ging nicht durch ....
PS C:\Users\x-ray> date;tracert google.com
02 July 2018 19:44:18 <<<<< 6 sekunden später kann google aufgelöst werden

Tracing route to google.com [216.58.207.78]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  DSL-AC87VG [192.168.1.1]
  2    12 ms    26 ms    12 ms  62.155.245.195
  3    10 ms    10 ms    10 ms  f-ed11-i.F.DE.NET. DTAG .DE [62.154.15.38]
  4    12 ms    11 ms    11 ms  80.150.170.30
  5    14 ms    12 ms    12 ms  108.170.252.65
  6    11 ms    11 ms    11 ms  72.14.234.247
  7    11 ms    10 ms    11 ms  216.58.207.78

Trace complete.

>>>>>>>>>> hier werde ich NICHT via der oben genannten IP geroutet

Ich kann daher die Frage nach dem Asus Support nicht nachvollziehen, der Router stellt die Verbindung mit dem Gateway her, damit ist Asus raus. Der Rest liegt beim routing der Telekom (zimundest innerhalb deren Netz)

ganz einfach, wenn das problem bei telekom liegen würde, wäre das schon längst aufgefallen bei einer domain wie google denn auch das wird gemonitort daher finde ich die Frage nicht verkehrt wobei ein tracert nicht immer akzeptiert wird z.b. bei überlast ist das eine unwichtige Abfrage die hinten rüber fallen darf.

communityTE

ganz einfach, wenn das problem bei telekom liegen würde, wäre das schon längst aufgefallen bei einer domain wie google denn auch das wird gemonitort daher finde ich die Frage nicht verkehrt wobei ein tracert nicht immer akzeptiert wird z.b. bei überlast ist das eine unwichtige Abfrage die hinten rüber fallen darf.

Das ist richtig, dennoch :

Wie beschrieben ist dies nicht immer der Fall, meist tags über habe ich keine Probleme.

Dennoch zeigt der trace einwandfrei dass das routing ins stocken gerät und _etwas_ nicht stimmt.

Da ich end-user bin, und leider keinen Zugriff mehr auf die DTAG Server habe, kann ich hier keine weitere Aktionen meiner seits unternehmen... 

Daher die Frage : Was kann ich als end-user noch alles tun, ausser den Leuten an der Hotline dauernd zu erklären wo ICH das Problem sehe.

Wenn die Antwort aber IMMER ist : "Naja, das ist nicht mehr unser Netz" , ich : "Doch ! ist es !" -- "Okay, geb ich mal weiter .... " .... was soll ich denn noch alles machen ?

CyberSW

Ich finde auch deine irrsinnigen Tracerts witzlos .. warum ne Domain antracern, bei welcher eh nicht auf Pings geantwortet wird?

Welche domain meinst Du denn nun ?

Irrsinnige traces ? 

Dann erklär mal bitte warum die traces irrsinning sind ... 

Okay, sehe schon, da kommt keine Antwort darauf weil jemand der 2 Falschaussagen in einem Satz macht, ist der beste Bestandteil einer user-community.

Fall Du dennoch etwas lernen willst : 

Trace zeigt dir an wo das Paket verloren geht.

Damit kannst Du z.B. sehr leicht sehen welche ports in core switchen ein flapping haben, oder wo anders wenn es beim client heisst "timeout" ... 

Da Du anscheinend keine Ahnung hast wie ein Request gestellt wird, hier ein high-level overview : 

Client -> DNS Server mit FQDN Anfrage für eine Auflösung (A , IP4 | AAAA IP6)

DNS -> Client mit IP im response part

Client -> Gateway mit Ziel an <siehe response info>

Gateway -> Anhand des routing tables wird weiter geschickt, bis da Ziel erreicht ist.

Wenn dann in der chain etwas nicht mehr antwortet da der ARP entry auf eine MAC verweist die outdated ist, dann läuft der client in einen timeout ... 

Und wenn du Schlaumeier etwas Ahnung hättest, was definitiv nicht der Fall ist, dann hättest Du den Sinn der traces gesehen. hier nochmal auf Deutsch für Dich zum mitlesen :

Gateway antowrtet , request wird weiter verteilt , aber kommt an einer Stelle NICHT durch. Dies is nach belieben reprodizierbar.

Wenn der gateway den Request anders routet (via ULM) , dann komme ich nicht via FRA , somit kommt der request auch bei dem entry an , das von DNS Seite in der response mitgeteilt wurde.

Daher : es ist ein routing Problem , denn sobald das Paket mein Haus verlassen hat, bin ich nicht mehr dafür zuständig und habe keine Kontrolle mehr darüber.

Da Du aber ausser "irrsinnige traces" nichts weiter dazu beitragen kannst, würde es mich jetzt wahnsinning interessieren WAS Du denn hier für einen Lösungsansatz hättest ? 

Hallo zurück,

Die Lösung des Problems waren Probleme innerhalb der Lines im T-Kom Netz (NSO Abteilung)...

Daher wieder die Frage an diese Community : 

WAS hat das denn bitteschön mit dem Router zu tun der bei mir steht ?

Durch obige Tests und Ergebnisse habe ich zweifelsfrei nachgewiesen dass die Probleme ausserhalb meiner Geräte liegen.

Es ist mehr als nur schauderlich dass die Leute hier in der Community (sei es Kunden , als auch Angestellte vom "Telekom hilft Team" ) solche, technisch komplett schwachsinnge Beiträge schreiben :

Anja N.

Ohne weitere Details und auch einen alternativen Router zum Test, wird sich das hier eher schwieriger gestalten.
Abschließend kann ich mich hier nur meinen Vorrednern anschließen. Wenn es tatsächlich ein generelles Problem mit diesem Routing gäbe, dann wäre das bereits bekannt.

Viele Grüße Anja W.

Dies ist, nüchtern betrachtet, Schwachsinn der höchsten Ebene und Zeugt von purem Unwissen in der Technik.

Dass dies kein Routing Problem ist, wurde festgeltellt, allerdings war es ein Problem einer line card , da die lines allerdings beim Anschluss nur eine sehr begrenzte Zahl an Kunden beherbirgt und auch nur lokal ist, ist dies kein "generelles" Problem.

Hätten Sie, und die Vorredner, auch nur einen kleinen Funken technischen Verstand, so wären die Vorschläge rund um "Router wechseln" mit folgendem schon komplett aussen vor :

- traceroute

- VPN via NBG ohne Probleme

da die VPN einwandfrei funktioniert hat , liegt der Verdacht nahe dass es ein Bauteil auf regional-area dc war was hier Probleme verursacht hat.

Soviel zum Thema Kompetenz im Netz ... 

Ich habe das selbe Problem. Da wir jetzt alle von zu Hause arbeiten müssen, haben die Tech Jungs von meinem Arbeitgeber meinen Setup professionell analysiert. Deren Schlussfolgerung: Es gibt eine Störung bei der Telekom. Eine bestimmte IP Addresse führt zu timeouts und Packetverlusten.

Daran gibt es überhaupt keinen Zweifel. Mein TraceRT sieht fürchterlich aus, mit TimeOuts ohne Ende.

Die Hotline sagt immer dasselbe: Problem ist mein Router, mein Switch, mein Wlan, das Wetter, der Coronavirus etc...aber niemals wird auch nur im Ansatz auf das wahre Problem eingegangen: der Server, dessen IP Addressse der DTAG gehört, reagiert nicht

Zweimal haben die Damen einfach den Hörer aufgelegt. Das ist auch eine Art das Problem zu lösen. Herzlichen Glückwunsch Deutsche Telekom. 

Mein Arbeitgeber zahlt jetzt den Wechsel zu einem besseren Anbieter. Tschüss Deutsche Telekom.