Netzwerkguru gesucht, ratlos seit 4 wochen..

dante`afk

dante`afk

Legende
Thread Starter
Mitglied seit
28.02.2008
Beiträge
6.531
Ort
New York
Heya,

okay folgender sachverhalt:

vor 2 monaten umgezogen (AT&T uverse) 75/75mbit. lief super fuer 1 monat, vor 4 wochen ploetzlich an einem freitag fing ich ploetzlich an staendig ausm teamspeak zu fliegen. wenn ich mich wieder verbunden habe hat es gelagged, ich konnte keine channels switchen, ich sah packet loss in meiner client connection info.

dann wurde overwatch released, ich flog staendig aus overwatch servern raus. company skype for business chat, ich flog staendig aus dem chat raus, alles nur fuer milisekunden und danach war ich wieder verbunden. internet langsam, facebook/twitter bilder/videos luden sehr langsam. path of exile ping/lagspikes. vor allem abends und am wochenende ganz schlimm.

bis heute habe ich diese probleme und auch die anderen 3 laptops/rechner im haushalt zeigen die gleichen symptome auf (w10 x64, w7 x64)
speedtest.net und pingtest.net sind 1a, vollspeed, gute ping, kein packetloss/jitter.


- 3 techniker waren bisher hier vom ISP, geschaetzt ueber 10 stunden im haus verbracht
- 3x ISP router gewechselt, die weisse buchse an der wand gewechselt, glassfaserkabel gecheckt, konnten nichts finden
- meine verbindung wurde an einen anderen port im keller (gebaeudekomplex, alle hier haben den gleichen ISP) verbunden worden, gleiches problem.
- eigenen router angeschlossen ohne ISP router, selbes problem
- statische IP zugewiesen bekommen vom ISP, gleiches problem
- ipv6 deaktiviert, gleiches problem.
- abesicherten modus gestartet, alle windows services/installationautostarts deaktiviert, selbes problem
- blizzard und teamspeak support kontaktiert, troubleshooting bekommen aber auch keine abhilfe
- ob wlan oder wired, selbes problem
- alle geraete ausgeschaltet, abgesteckt und jedes geraet einzeln mit direktverbindung zum router getestet, selbes problem

der ISP sagt mir immer es wurde ihrerseits nichts geaendert.


nun das kuriose:
wenn ich ueber mein handy (tmobile) internet auf mein rechner tethere, KEINE probleme
wenn ich nen VPN nutze und nach texas, chicago, selbst germany oder frankreich verbinde und somit mein internet nutze, KEINE probleme


was zum teufel?



tracert zu overwatch

Tracing route to 37.244.0.3 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms dsldevice.attlocal.net [192.168.1.254]
2 10 ms 9 ms 90 ms 108-200-224-1.lightspeed.bcvloh.sbcglobal.net [108.200.224.1]
3 2 ms 1 ms 2 ms 71.151.85.34
4 4 ms 3 ms 2 ms 75.25.192.144
5 3 ms 3 ms 2 ms 75.25.192.99
6 3 ms 3 ms 3 ms 12.83.69.29
7 12 ms 11 ms 11 ms gar13.cgcil.ip.att.net [12.122.132.121]
8 10 ms 11 ms 11 ms chi-b21-link.telia.net [213.248.87.253]
9 32 ms 32 ms 32 ms nyk-bb1-link.telia.net [62.115.140.70]
10 127 ms 128 ms 127 ms prs-bb3-link.telia.net [213.155.135.4]
11 87 ms 127 ms 127 ms prs-b8-link.telia.net [62.115.118.81]
12 113 ms 113 ms 113 ms blizzard-ic-307020-prs-b8.c.telia.net [62.115.46.154]
13 108 ms 111 ms 165 ms 37.244.9.33
14 165 ms 165 ms 165 ms 24.105.31.16
15 115 ms 114 ms 114 ms prs-b8-link.telia.net [62.115.118.81]
16 165 ms 165 ms 101 ms blizzard-ic-307020-prs-b8.c.telia.net [62.115.46.154]
17 166 ms 165 ms 154 ms 37.244.9.33
18 154 ms 166 ms 155 ms 24.105.31.16
19 166 ms 153 ms 166 ms 37.244.0.3


tracert zum ts server

Tracing route to unknown.Level3.net [63.210.145.186]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms dsldevice.attlocal.net [192.168.1.254]
2 9 ms 17 ms 3 ms 108-200-224-1.lightspeed.bcvloh.sbcglobal.net [108.200.224.1]
3 2 ms 2 ms 1 ms 71.151.85.34
4 4 ms 2 ms 2 ms 75.25.192.144
5 2 ms 2 ms 3 ms 75.25.192.99
6 6 ms 3 ms 3 ms 12.83.69.29
7 12 ms 11 ms 11 ms gar13.cgcil.ip.att.net [12.122.132.121]
8 10 ms 10 ms 10 ms ae3.chi11.ip4.gtt.net [173.241.128.29]
9 35 ms 35 ms 35 ms xe-11-2-0.dal34.ip4.gtt.net [89.149.129.161]
10 37 ms 35 ms 37 ms as20473.xe-5-1-2.cr1.dfw1.us.as4436.gtt.net [69.31.63.238]
11 35 ms 34 ms 35 ms unknown.Level3.net [63.210.145.186]
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hast du mal testhalber an der MTU gedreht? Der verlinkte Wikipedia Artikel zur MTU verweist übrigens auf eine Webseite mit ein paar ganz nützlichen Tests: https://www.dslreports.com/tools
 
welche der programme sollte ich von da benutzen?

habe die mtu noch nicht verstellt.
 
Der Tweak Test klang interessant, habe ihn allerdings nicht in meinem Browser ans laufen gekriegt. Aber die MTU verstellt man direkt in Windows, dazu brauchst du sonst nichts.
 
Hast du mal 100 Pings auf eine beliebige Adresse ausgeführt und nach Loss geschaut?

ping 8.8.8.8 -n 100
 
also schon der erste Hop bei deinem Provider zeigt eine deutlich schwankende Leistung beim Antwortverhalten, der steht also schonmal gut unter (Über-)Last - eine Antwortzeit zwischen 3ms und 90ms ist für einen "Einwahlrouter" eher untypisch. Hop1 ist der Router bei dir zu Hause!
Code: 
2 10 ms 9 ms 90 ms 108-200-224-1.lightspeed.bcvloh.sbcglobal.net [108.200.224.1]
2 9 ms 17 ms 3 ms 108-200-224-1.lightspeed.bcvloh.sbcglobal.net [108.200.224.1][CODE]

Die Antwortzeiten im AT&T Backbone sind OK, Probleme gibt es dann wieder in den Backbones der Peeringpartner (Telia & ip4.gtt) - zumindest scheinbar, es kann natürlich sein, daß die Antwortzeiten aufgrund der (Über-)Last vom Einwahlrouter kommen, der die ICMP-Requests und -Replys nicht schnell genug weiterleitet.

[QUOTE]wenn ich ueber mein handy (tmobile) internet auf mein rechner tethere, KEINE probleme[/QUOTE]
Versteh ich das richtig?
Du verbindest dein Handy via WLAN mit dem  "Problematischen" Internetzugang von AT&T und nutzt dann via USB das Handy als Modem!

[QUOTE]wenn ich nen VPN nutze und nach texas, chicago, selbst germany oder frankreich verbinde und somit mein internet nutze, KEINE probleme
[/QUOTE] Also du baust über die "Problematische" Internetverbindung von AT&T eine VPN Verbindung zu einem VPN Provider auf und surfst dann über dieses VPN ohne Lags etc?


Diese beiden Konstellationen müsstest du Paralell zu dem normalen Zugang testen - also mit einem PC/Lappi den direkten Zugang nutzen und mit einem 2 Gerät via Handy oder VPN.
Wenn dann wirklich die eine Verbindung laggt und lange Antwortzeiten hat, während die ander Verbindung Störungsferei läuft, bedfinden wir uns im Bereich des Esoterischen, weil eigentlich unmöglich (die VPN Verbindung könnte natürlich über ganz andere Peeringpartner gehen, die Handyverbindung aber eher nicht)

Des weiteren solltest du zeitgleich zu den Verbindungsproblemen mal im Taskmanager die CPULast anschauen, und mit "DPC-Latency Checker" die Latenzen innerhalb deines System überwachen, möglicherweise schiesst da ja irgendein Treiber quer - dagegen spricht wiederum das Verhalten via Handy/VPN.
 
Zuletzt bearbeitet:
dirk11 schrieb:
Einen ISP, der sich so um seine Kunden kümmert, möchte ich mal in Deutschland erleben.
Zum Vergrößern anklicken....

ja bin auch erstaunt dass die ueber solche laengen gehen um zu helfen. auch rufen die staendig an und fragen wie es laeuft.

NTB schrieb:
Hast du mal 100 Pings auf eine beliebige Adresse ausgeführt und nach Loss geschaut?

ping 8.8.8.8 -n 100
Zum Vergrößern anklicken....

ping zum google dns
ping 8.8.8.8 -n 100

Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=21ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=19ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=19ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=19ms TTL=43
Reply from 8.8.8.8: bytes=32 time=24ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=19ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=19ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=19ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=21ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=19ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=19ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=19ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=19ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=19ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=21ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43
Reply from 8.8.8.8: bytes=32 time=20ms TTL=43

ping zum NA overwatch server
ping 37.244.0.3 -n 100

Pinging 37.244.0.3 with 32 bytes of data:
Reply from 37.244.0.3: bytes=32 time=165ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=165ms TTL=242
Reply from 37.244.0.3: bytes=32 time=153ms TTL=242
Reply from 37.244.0.3: bytes=32 time=165ms TTL=242
Reply from 37.244.0.3: bytes=32 time=153ms TTL=242
Reply from 37.244.0.3: bytes=32 time=154ms TTL=242
Reply from 37.244.0.3: bytes=32 time=153ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=165ms TTL=242
Reply from 37.244.0.3: bytes=32 time=154ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=153ms TTL=242
Reply from 37.244.0.3: bytes=32 time=153ms TTL=242
Reply from 37.244.0.3: bytes=32 time=154ms TTL=242
Reply from 37.244.0.3: bytes=32 time=165ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=165ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=154ms TTL=242
Reply from 37.244.0.3: bytes=32 time=165ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=154ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=165ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=165ms TTL=242
Reply from 37.244.0.3: bytes=32 time=153ms TTL=242
Reply from 37.244.0.3: bytes=32 time=153ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=154ms TTL=242
Reply from 37.244.0.3: bytes=32 time=165ms TTL=242
Reply from 37.244.0.3: bytes=32 time=165ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=167ms TTL=242
Reply from 37.244.0.3: bytes=32 time=165ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=154ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=165ms TTL=242
Reply from 37.244.0.3: bytes=32 time=153ms TTL=242
Reply from 37.244.0.3: bytes=32 time=153ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=165ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=153ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=154ms TTL=242
Reply from 37.244.0.3: bytes=32 time=153ms TTL=242
Reply from 37.244.0.3: bytes=32 time=153ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=165ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=165ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=167ms TTL=242
Reply from 37.244.0.3: bytes=32 time=153ms TTL=242
Reply from 37.244.0.3: bytes=32 time=153ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=153ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=165ms TTL=242
Reply from 37.244.0.3: bytes=32 time=153ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=160ms TTL=242
Reply from 37.244.0.3: bytes=32 time=165ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=165ms TTL=242
Reply from 37.244.0.3: bytes=32 time=165ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=165ms TTL=242
Reply from 37.244.0.3: bytes=32 time=165ms TTL=242
Reply from 37.244.0.3: bytes=32 time=153ms TTL=242
Reply from 37.244.0.3: bytes=32 time=154ms TTL=242
Reply from 37.244.0.3: bytes=32 time=153ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=165ms TTL=242
Reply from 37.244.0.3: bytes=32 time=153ms TTL=242
Reply from 37.244.0.3: bytes=32 time=153ms TTL=242
Reply from 37.244.0.3: bytes=32 time=153ms TTL=242
Reply from 37.244.0.3: bytes=32 time=153ms TTL=242
Reply from 37.244.0.3: bytes=32 time=153ms TTL=242
Reply from 37.244.0.3: bytes=32 time=153ms TTL=242
Reply from 37.244.0.3: bytes=32 time=165ms TTL=242
Reply from 37.244.0.3: bytes=32 time=153ms TTL=242
Reply from 37.244.0.3: bytes=32 time=154ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242
Reply from 37.244.0.3: bytes=32 time=153ms TTL=242
Reply from 37.244.0.3: bytes=32 time=166ms TTL=242

Ping statistics for 37.244.0.3:
Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 153ms, Maximum = 167ms, Average = 161ms

Digi-Quick schrieb:
also schon der erste Hop bei deinem Provider zeigt eine deutlich schwankende Leistung beim Antwortverhalten, der steht also schonmal gut unter (Über-)Last - eine Antwortzeit zwischen 3ms und 90ms ist für einen "Einwahlrouter" eher untypisch. Hop1 ist der Router bei dir zu Hause!
Code: 
2 10 ms 9 ms 90 ms 108-200-224-1.lightspeed.bcvloh.sbcglobal.net [108.200.224.1]
2 9 ms 17 ms 3 ms 108-200-224-1.lightspeed.bcvloh.sbcglobal.net [108.200.224.1][CODE]

Die Antwortzeiten im AT&T Backbone sind OK, Probleme gibt es dann wieder in den Backbones der Peeringpartner (Telia & ip4.gtt) - zumindest scheinbar, es kann natürlich sein, daß die Antwortzeiten aufgrund der (Über-)Last vom Einwahlrouter kommen, der die ICMP-Requests und -Replys nicht schnell genug weiterleitet.


Versteh ich das richtig?
Du verbindest dein Handy via WLAN mit dem  "Problematischen" Internetzugang von AT&T und nutzt dann via USB das Handy als Modem!

 Also du baust über die "Problematische" Internetverbindung von AT&T eine VPN Verbindung zu einem VPN Provider auf und surfst dann über dieses VPN ohne Lags etc?


Diese beiden Konstellationen müsstest du Paralell zu dem normalen Zugang testen - also mit einem PC/Lappi den direkten Zugang nutzen und mit einem 2 Gerät via Handy oder VPN.
Wenn dann wirklich die eine Verbindung laggt und lange Antwortzeiten hat, während die ander Verbindung Störungsferei läuft, bedfinden wir uns im Bereich des Esoterischen, weil eigentlich unmöglich (die VPN Verbindung könnte natürlich über ganz andere Peeringpartner gehen, die Handyverbindung aber eher nicht)

Des weiteren solltest du zeitgleich zu den Verbindungsproblemen mal im Taskmanager die CPULast anschauen, und mit "DPC-Latency Checker" die Latenzen innerhalb deines System überwachen, möglicherweise schiesst da ja irgendein Treiber quer - dagegen spricht wiederum das Verhalten via Handy/VPN.[/QUOTE]

ich deaktiviere meinen ethernet adapter. dann lass ich mein handy quasi als router/hotspot fungieren und verbinde dann per wlan stick von meinem computer auf das handy. dadurch habe ich dann internet auf dem rechner ohne lags und probleme. bekomme knapp 30mbit dadurch. natuerlich ist die ping schlechter aber ich sehe keine lags, internetseitenladezeigen sind gut und sonst haengt auch nichts. keine drops vom TS oder overwatch.

zur VPN frage, richtig. ich nutze die verbindung von AT&T, verbinde auf ein VPN (PIA) und selbst da keine probleme.

hier sind mal die gleichen tracerts waehrend ich mit dem VPN drin bin. laut speedtest.net ist das in chicago, ca. ne stunde von hier entfernt - bin momentan in cleveland.

Tracing route to 37.244.0.3 over a maximum of 30 hops

1 10 ms 10 ms 10 ms 10.164.1.1
2 * * * Request timed out.
3 12 ms 11 ms 12 ms xe-0-1-0-5.r05.chcgil09.us.bb.gin.ntt.net [129.250.207.209]
4 33 ms 33 ms 12 ms ae5.er2.ord7.us.zip.zayo.com [64.125.12.85]
5 33 ms 33 ms 12 ms 128.177.105.58.IPYX-106626-011-ZYO.zip.zayo.com [128.177.105.58]
6 33 ms 70 ms 118 ms prs-bb3-link.telia.net [80.91.251.97]
7 118 ms 67 ms 67 ms 37.244.0.3



Tracing route to unknown.Level3.net [63.210.145.186]
over a maximum of 30 hops:

1 73 ms 10 ms 10 ms 10.164.1.1
2 * * * Request timed out.
3 12 ms 12 ms 11 ms xe-0-3-0-9.r06.chcgil09.us.bb.gin.ntt.net [129.250.207.213]
4 11 ms 11 ms 11 ms ae11.chi11.ip4.gtt.net [199.229.229.193]
5 39 ms 38 ms 39 ms xe-10-2-1.dal34.ip4.gtt.net [89.149.130.186]
6 38 ms 38 ms 38 ms as20473.xe-5-1-2.cr1.dfw1.us.as4436.gtt.net [69.31.63.238]
7 38 ms 38 ms 38 ms as20473.xe-5-1-2.cr1.dfw1.us.as4436.gtt.net [69.31.63.238]
8 40 ms 40 ms 40 ms unknown.Level3.net [63.210.145.186]


der ISP ist halt leider nun auch ratlos, ich versuche herauszufinden woran das problem nun liegen kann dass ploeztlich vor 4 wochen entstanden ist.


hier ist mal nen 15 minuten langes tracert(?) mit winMTR zum overwatch server und zum ts server. der loss beim ts server (linkes bild) war teilweise mal bei 40%.

[img]http://i.imgur.com/Ng1bSqt.jpg[/img]

kann man demnach sagen das problem liegt definitv bei ATT oder bei mir?


hier nochmal 15 minuten waehrend ich mit dem VPN verbunden bin

[img]http://i.imgur.com/1nylZ6F.jpg[/img]
Zum Vergrößern anklicken....
 
Zuletzt bearbeitet:
Digi-Quick schrieb:
also schon der erste Hop bei deinem Provider zeigt eine deutlich schwankende Leistung beim Antwortverhalten, der steht also schonmal gut unter (Über-)Last - eine Antwortzeit zwischen 3ms und 90ms ist für einen "Einwahlrouter" eher untypisch.
Zum Vergrößern anklicken....

Wenn die Hops danach OK sind, ist völlig egal, wie der Hop selbst antwortet. Offensichtlich routet er ja Pakete ohne Probleme. Auf Pings antworten und Pings routen sind zwei unterschiedliche Codepfade, wobei bei Routern der erstere generell niedrig priorisiert ist.
 
Genau so ist es.

Ich würde aktuell erstmal empfehlen, WinMTR so lange mit laufen zu lassen, bis das Problem einmal auftritt. Wenn, sobald das Problem auftritt, auf einmal alle Hops oder nur ein paar der letzten Los aufzeigen, kann man weiter über das Problem spekulieren.

Zum Thema MTU:
Eigtl musst du hier nichts anpassen, denn Windows hat per Default Path MTU Discovery an. Das heißt es prüft selbstständig bei einer Verbindung wieviele Daten nun wirklich durch passen. Idealerweise sollte das bei einer DSL Verbindung mit PPPoE 1492 sein. ( PPPoE Header ist 8 Byte groß).


Auch wenn TCM es bereits geschrieben hat, will ich es hier auch noch mal sagen: Loss auf Hops zwischen Quelle und Ziel sind Wurst. Dieser wird erst interessant, wenn er sich durchgängig auf Teilen des Pfades zeigt.
 
TCM schrieb:
Wenn die Hops danach OK sind, ist völlig egal, wie der Hop selbst antwortet. Offensichtlich routet er ja Pakete ohne Probleme. Auf Pings antworten und Pings routen sind zwei unterschiedliche Codepfade, wobei bei Routern der erstere generell niedrig priorisiert ist.
Zum Vergrößern anklicken....
Wenn aber schon der Einwahlrouter Antwortzeiten von mehr als 50 ms hat, ist das ein deutliches Zeichen von Überlastung des "Einwahlrouters" - wodurch auch immer!
https://en.wikipedia.org/wiki/Network_congestion


- - - Updated - - -

Seratio schrieb:
Auch wenn TCM es bereits geschrieben hat, will ich es hier auch noch mal sagen: Loss auf Hops zwischen Quelle und Ziel sind Wurst. Dieser wird erst interessant, wenn er sich durchgängig auf Teilen des Pfades zeigt.
Zum Vergrößern anklicken....
Eben nicht, wenn ein Teil der Route zum Ziel überlastet ist, dann ist die Kommunikation zwischen Quelle und Ziel mindestens gestört.
Siehe Network Congestion!

@topic bzw,
Bei den Bildern ist zu sehen, daß der Kundenrouter (dsldevice.attlocal.net) ein Paketloss von 8 bzw. 19% hat, was auf Überlastung und/oder thermische Probleme schliesen läßt.
Irgenwas befeuert den Router (bzw. die integrierte Firewall).
Bei der VPN Verbindung treten ebenfalls deutliche Packetlosses von 14 bzw. 21% auf.
Hier könnten natürlich ebenfalls thermische Probleme vorlegen, halte ich aber für unwahrscheinlich.
(der 2. Hop darf offenbar nicht auf ICMP Requests / Ping antworten)

Fazit: Irgendwas aus deinem lokalen Netz feuert sowiel Daten /Traffic auf deinen Router, daß dieser unter der Last zusammenbricht - vorzugsweise sind das Trojaner, PUP's und sonstiges Getier. Es kann aber auch ein "wildgewordener" Netzwerktreiber (evtl. in Zusammenspiel mit einem Windows Update) oder einfach eine defekte Netzwerkkarte sein.
 
Zuletzt bearbeitet:
Wie du auf thermische Probleme schließt, ist mir ein Rätsel.

Wenn es am lokalen Router liegt, warum ist dann bei den anderen Hops kein Loss?
 
NTB schrieb:
Wie du auf thermische Probleme schließt, ist mir ein Rätsel.
Zum Vergrößern anklicken....
Ganz einfach, thermisch Probleme können genau so ein Verhalten zur Folge haben.
Was glaubts du, warum eigentlcih alle aktuellen CPUs runtertakten und/oder Throtteln wenn Sie zu heiss werden?
(In früheren Zeiten sind die dann einfach abgeraucht.)

Wenn es am lokalen Router liegt, warum ist dann bei den anderen Hops kein Loss?
Zum Vergrößern anklicken....
Kein Loss, aber z.T. signifikant hohe Antwortzeiten!
Die beim Ping gemessene Zeit ist die Zeit, die zwischen Senden des Pings und dem Eintreffen des Echos vergeht. Da addieren sich die Latenzen aller dazwischenliegenden Hops!
 
Zuletzt bearbeitet:
Ich würde auch eher sagen, dass der mtr unaufällig aussieht. Alles nach dem Router lüppt ja gut.

Zum besseren Verfolgen, wie schon geschrieben, mtr (oder Pingplotter auf Tablet/Smarphone) laufen lassen und beobachten, was abgeht, wenn es zu Problemen kommt.
 
Digi-Quick schrieb:
Wenn aber schon der Einwahlrouter Antwortzeiten von mehr als 50 ms hat, ist das ein deutliches Zeichen von Überlastung des "Einwahlrouters" - wodurch auch immer!
Zum Vergrößern anklicken....

Das wird schon allein dadurch entkräftet, dass die nächsten Hops ja niedrige und stabile Zeiten liefern. Diese Pakete müssen ja schließlich auch durch den ersten Hop.
 
TCM schrieb:
Das wird schon allein dadurch entkräftet, dass die nächsten Hops ja niedrige und stabile Zeiten liefern. Diese Pakete müssen ja schließlich auch durch den ersten Hop.
Zum Vergrößern anklicken....
Es ist in der Tat ein nicht homogenes Fehlerbild. Das macht die Sache leider nicht einfach. Auch mein Ansatz ist nur eine Möglichkeit für die einige Faktoren sprechen, andere Faktoren widersprechen dem wiederum - zumindest dem Anschein nach.
 
Natürlich KÖNNEN thermische Probleme Ursache sein. Kann aber auch eine Störung durch ein anderes Gerät neben dem Netzwerkkabel sein.
 
Kabel habe ich alle gegen neue auswechselt.

Formatiert habe ich zwar in Erwägung gezogen, aber ich noch nicht vollzogen, da die anderen Rechner unabhängig voneinander ja die selben Symptome aufweissen.
 
Ich bin mit Netzwerken weniger fit als einige hier, kenne mich aber mit Elektronik recht gut aus.

Bei so einem Fehlerbild, mit plötzlichem Anfang, würde ich auf eine sterbende Hardware / Wackelkontakt tippen. Gibt es irgendwelche Hardware, die noch nicht gewechselt wurde?

Vielleicht auch elektromagnetische Einstreuungen, z. B. von einem defekten Motor (Kühlschrank, Klimaanlage, Lift, Neonröhre, ...). Hast Du Industrie im gleichen Haus / in der Nähe / entlang des Kabelweges? Schon mal eine USV probiert (die haben üblicherweise einen Netzfilter)? Testweise die Netzwerkgeräte und einen PC vom USV-Akku (also ohne Netzstrom) betreiben.

Frage an die Netzwerk-Gurus: Hat VPN eine Fehlerkorrektur eingebaut? Das könnte erklären, wieso die VPN-Verbindung nicht betroffen ist.

- - - Updated - - -

PS: hast Du einen Glasfaseranschluss? Wenn ja, und es sich um eine elektromagnetische Störung handelt, dann muss diese nach dem Glasfaseranschluss zuschlagen. Also alles was danach kommt einmal an die USV im Akkubetrieb hängen. KEINE Kupferkabel irgendwoanders hin (Z. B. zum Kabel-TV oder Audioanlage).

- - - Updated - - -

PPS: Wenn Du keine USV auftreiben kannst: Test mit Minimalsystem: Router -- PC. Beide Geräte AN DER GLEICHEN STECKDOSE. Keine Kabel zu irgendeinem anderen Gerät mit Stromanschluss (Brummschleifengefahr).

- - - Updated - - -

PPPS:

dante`afk schrieb:
nun das kuriose:
wenn ich ueber mein handy (tmobile) internet auf mein rechner tethere, KEINE Probleme
Zum Vergrößern anklicken....

Das könnte tatsächlich auf eine elektromagnetische Störung hindeuten.
 
Zuletzt bearbeitet:
war letzte woche unterwegs. das mit der elektronik klingt interessant. also der router und diese kleine weisse box an der wand sind in einem nebenraum, da sind auch wachmaschine und trockner. mir stehen dort 3 steckdosen zur verfuegung, hatte das kabel dann auch testweisse in eine andere buchste gesteckt aber wenn die alle dort sind, liegt es wohl nahe dass diese betroffen sein koennten?

ja ist glasfaster, hab mit dem techniker dann vorgestern nochmal gesprochen, meine leitung soll angeblich nur fuer mich sein, auch wenn 200 andere im haus hier beim gleichen anbieter sind.
 
dante`afk schrieb:
war letzte woche unterwegs. das mit der elektronik klingt interessant. also der router und diese kleine weisse box an der wand sind in einem nebenraum, da sind auch wachmaschine und trockner. mir stehen dort 3 steckdosen zur verfuegung, hatte das kabel dann auch testweisse in eine andere buchste gesteckt aber wenn die alle dort sind, liegt es wohl nahe dass diese betroffen sein koennten?
Zum Vergrößern anklicken....
Ein nutzloser Versuch. Wenn Du andere Geräte als Störquelle ausschließen willst, mußt Du diese schon abschalten und eventuell auch ausstecken. Und selbst das kann u.U. nicht ausreichend sein, weil in die Spannungsversorgung induzierte Störungen sogar von einem anderen Haus in der gleichen Straße stammen können, oder von vorbeifahrenden U-Bahnen, oder von einer Außenreklame oder oder oder...
Um Störungen durch das Stromversorgungsnetz als Einstreuung über das Netzteil des betroffenen Gerätes ausschließen zu können, mußt Du Dein Gerät schon via Akku/Batterieversorgung/USV betreiben.
Jedenfalls dann, wenn Du keine passenden Meßmöglichkeiten wie z.B. einen Spectrum-Analyzer zur Verfügung hast (und damit umgehen kannst).
 
@dante:
Was ist das für eine kleine weiße Box? Der Glasfaseranschluss? Wenn du es nicht genau weißt, mach mal ein Foto.

Und systematisches Testen: Minimalsystem, also nur Router und ein PC, beide an einer USV im Akkubetrieb.
Falls du keine USV hast oder auftreiben kannst: nur den Router und einen Notebook im Akkubetrieb.
In beiden Fällen KEINE Kabel zu irgendwelchen anderen Geräten (zum Beispiel Audio, HDMI zum Fernseher, etc., auch am Router alle anderen Netzwerkkabel ausstecken ) Dann untersuchen, ob die Störungen noch auftreten.

(USV = unterbrechungsfreie Stromversorgung.)
 
Zuletzt bearbeitet:
schon getan mit dem minimalsystem. auch alles in der wohnung abgesteckt und nur pc und router angelassen, leider dasselbe problem.





ganz paranoid gestern formatiert, windows komplett frisch drauf. nur teamspeak und overwatch getestet, sonst war nichts auf dem rechner, selbes problem.

vorgestern hab ich im gebaeude 5 leute gefragt, alle bis auf eine berichteten von aehnlichen problemen. doch keiner nutzt das internet so wie ich, auch keiner spielt am pc von denen.

also AT&T kann mir jetzt sonst was erzaehlen. der speedtest mag zwar super sein (verbindet ja zu dem naehesten knoten zu AT&T) aber wenn alles andere was ausserhalb davon ist fuern arsch ist.....
 
dante`afk schrieb:
schon getan mit dem minimalsystem. auch alles in der wohnung abgesteckt und nur pc und router angelassen, leider dasselbe problem.
Zum Vergrößern anklicken....
Noch einmal: derlei Versuche sind nette Arbeitsbeschaffung, aber nicht zielführen. Das gestörte Gerät (also der Glasfaser-Umsetzer) muss vom Netz getrennt gespeist werden, und ein direkt folgender WLAN-Router auch (oder ein Laptop direkt anschließen im Akkubetrieb)! Ohne galvanische Trennung wird das nie was.

ganz paranoid gestern formatiert, windows komplett frisch drauf. nur teamspeak und overwatch getestet, sonst war nichts auf dem rechner, selbes problem.
Zum Vergrößern anklicken....
Natürlich "selbes Problem", weil das nie die Ursache war. Musst Du Zeit totschlagen oder wieso machst Du nutzlose Dinge?
 
getrennt diesen geraeten ne externe stromquelle zur verfuegung zu stellen werde ich nicht koennen.

ich mein, wenn dass das problem sein sollte, sollten wohl auch mit dem vpn die selben symptome erscheinen ?
 
Nach allem, was ich bisher gelesen habe, klingt es für mich nach einer Überlastung.


Die ganzen Traceroutes aus http://www.hardwareluxx.de/communit...atlos-seit-4-wochen-1123747.html#post24677439
sind das Messungen zu einem Zeitpunkt, an dem die Verbindung gestört war?
Ich kann dort erstmal nichts problematisches sehen, außer eben die Werte auf dem ersten Hop. Aber da alle folgenden problemlos scheinen, hat das nicht zwingend was zu sagen.

vor allem abends und am wochenende ganz schlimm.
Zum Vergrößern anklicken....

Wenn das so stimmt, könnte es einfach einer Überlastung der Verbindung sein.
Zu diesen Stosszeiten benutzen in der Regel ja mehr Leute die Internetleitung.

Diese Überlastung muss nicht zwingend bei dir lokal, oder beim eigenen Provider sein, sondern kann auch irgendwo auf der Route zum Ziel liegen. Z.B. könnte ein zentraler Knoten auf dem Weg überlastet sein.

Wenn ich nen VPN nutze und nach texas, chicago, selbst germany oder frankreich verbinde und somit mein internet nutze, KEINE probleme
Zum Vergrößern anklicken....
Diese Tatsache legt ebenfalls die Vermutung Nahe, dass irgendwo auf der Route ein Problem vorliegt, und dieser Teil der Route durch den Umweg übers VPN umgangen wird.
Bei einem VPN wird ja zunächst eine Route zu einem anderen Ziel aufgebaut, dadurch logischerweise auch meistens über ganz andere Zwischenstationen, bevor es vom VPN Endpunkt zum eigentlichen Ziel weitergeht.



Ich würde versuchen das Problem so weit wie möglich einzugrenzen und so ausführliche Messungen wie möglich zu machen, am besten über einen längeren Zeitraum (mehrere Tage) durchführen.
Dazu würde ich versuchen ein Tool (habe aber leider keine konkrete Empfehlung) zu finden , dass die Ping Zeiten / Latenzen in einem zeitlichen Zusammenhang darstellen kann, damit man mit einer Auswertung auch das Problem visualisieren und an die entsprechende Stelle weiterleiten kann.

Weiterhin würde ich versuchen mehrere Verbindungen zu unterschiedlichen Zielen zur gleichen Zeit zu messen.
Wenn z.B. die Verbindung zum Blizzard Server packetloss hat,
aber zeitgleich problemlos eine Verbindung zu XYZ funktioniert, was geographisch ganz woanders liegt,
dann kann man die Fehlerquelle weiter einschränken.
 
Da das Problem bei mehreren im Haus auftritt, könnte (!) es eine Störung sein, die in die Stromzuleitung des Hauses oder die Netzwerkleitung nach dem Glasfaseranschluss einstreut. (Industrienanlage in der Nachbarschaft, fehlerhafter Motor von Lift, etc. ...).

Das lässt sich nur auf zwei Wegen klären: entweder wie von Dirk11 und mir beschrieben (Akkubetrieb der Geräte). Oder Du beauftragst einen Profi mit geeigneten Messgeräten.

Bezüglich VPN:

awehring schrieb:
Frage an die Netzwerk-Gurus: Hat VPN eine Fehlerkorrektur eingebaut? Das könnte erklären, wieso die VPN-Verbindung nicht betroffen ist.
Zum Vergrößern anklicken....
 
heute unerwartet nen anruf von ATT bekommen, nachdem mich letzte woche (nach absprache) niemand angerufen hat. anscheinend haben sich mehr leute mit problemen gemeldet, nen dutzend tracerts hin und her gesendet und dann wurde von einem der techs irgendwann Bogon filtering erwaehnt. eventuell sind wir (die affektierten user) auf einem IP block der probleme damit bereitet?

am samstag kommt nochmal nen tech vorbei der mir ne neue statische IP addresse gibt aber auf einem anderen IP block, mal gucken.
 
awehring schrieb:
Frage an die Netzwerk-Gurus: Hat VPN eine Fehlerkorrektur eingebaut? Das könnte erklären, wieso die VPN-Verbindung nicht betroffen ist.
Zum Vergrößern anklicken....

Also wenn ein VPN nicht vernünftig authentifizieren würde, was einer Fehlerkontrolle gleichkommt, dann wäre das alles andere, nur kein VPN was sich VPN nennen darf.
 
Anmelden, um zu antworten.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh