Spiele Lags WoT extrem hoch . Betrifft NUR Telekom Kunden

Gelöst

Hallo ihr lieben, 

seit mehreren Wochen haben ganz viele Spieler bei WoT (World of Tanks) arge Lag Probleme sodass Events nicht spielbar sind. 

 

Es äußert sich so, das die Pingzeit bei mir ca. bei 30ms liegt, was bei mir schon hoch ist, sonst immer so bei 15-20ms. das ist nicht das Problem sondern wirklich die Lags, die ja nicht durch die Zeit entstehen. 

 

Es gibt bei WoT zwei Spieleserver auf EU Raum . EU1 und EU2

 

EU1 = lags    login.p1.worldoftanks.eu

EU2 = keine lags.     login.p2.worldoftanks.eu

 

Ich habe jetzt mal eine pingabfrage über CMD durchgeführt, sowie eine Traceroute mit dem Tool PingPlotter. 

Anbei mal den Screenshot WoT-EU1. Interresant sind die drei leeren Tracerouten (gelb makiert) die nix anzeigen, aber ab da die Störung auftritt. Ist eindeutig zu sehen. Was interessant ist es gibt keine Daten über die dahinter laufenen Hobs.  Vorhin hatte ich einmal einen Trace drinnen da lief es irgendwie über einen Hob Namens Telia, der den extrem hohen Ping ausführte und das dauernd. Somit war kein Spielen auf EU1 mehr möglich . 

 

Wie gesagt es betrifft alle Kunden bei der Telekom, es gab viele Bestätigungen von anderen Mitspieler die ebenfalls diesesn Telia Eintrag hatten . 

 

Diese Lags laufen bereits seit mehren Wochen . 

 

Wie kann seitens der Telekom die Route verändert werden wie z.B. im zweiten Trace des EU2 zu sehen wo alles i.O ist ? 

 

Liebe Grüße Florian

 

 

2 AKZEPTIERTE LÖSUNGEN

@muc80337_2 

 

wow wozu bist du hier wenn dich sowieso leute nerven .. Ganz ehrlich ich versuche das zu verstehen aber wenn jemand wie du solche aussagen trifft das man nervt dann setzt dich lieber woanders ran . 

 

@olliMD 

ja das verstehe ich, nur wer kann den das sagen wer der nächste Betreiber ist ? das ist ja der Punkt den ich versuche herauszufinden . Jemand der diese Problematik versteht aber selbst nciht hat, der kann schnell sagen es nervt oder sonst was . Aber wozu ist dann ein Forum oder eine Community da ?

 

Freundlichkeit ist hier wohl extrem Groß geschrieben Überglücklich

Lösung in ursprünglichem Beitrag anzeigen  

Lösung
Telekom hilft Team
Hallo @Florian39,

der Datenaustausch zwischen den Netzen einzelner Internet-Serviceprovider erfolgt über Internet-Knoten. Dieser Zusammenschluss der Netze nennt sich Peering. Die Knotenpunkte haben eine begrenzte Bandbreite. In Abhängigkeit vom Datenverkehr und der verfügbaren Bandbreite an einem Knotenpunkt kann es zu Engpässen im Datenverkehr von einem Internet-Serviceprovider zu einem anderen kommen. So können unterschiedliche Downloadraten oder Antwortzeiten zu einem Dienst zu unterschiedlichen Tageszeiten entstehen, wenn der Datenverkehr über einen Internet-Knoten geführt wird.

Kommt es aufgrund von Überlastsituationen zu Engpässen bei Übergängen zu Providern, über die der Server erreicht werden muss, wird sich die Ping-Laufzeit verschlechtern, da Pakete am Netzübergang zum anderen Provider in einer Queue (Warteschlange) sequentiell abgearbeitet werden müssen. In einem solchen Fall sind wir bestrebt, mit dem jeweiligen Netzbetreiber eine Aufrüstung der Verbindungen zu erreichen. Eine einseitige Lösung allein durch die Telekom ist in einem solchen Fall nicht möglich. Lediglich das Umrouten des Verkehrs kann ggf. zu einer temporären Entschärfung der Situation führen. Kundenindividuelle Routenwechsel sind technisch nicht umsetzbar.

Bevor von einem Peeringproblem ausgegangen werden kann, sollten lokale Fehler wie gestörte DSL-Verbindungen oder Fehler im Heimnetzwerk (fehlerhafte Verkabelung, gestörtes WLAN, defektes Endgerät) ausgeschlossen werden.


Mögliche Fehlerbilder:
•Verlangsamter Seitenaufbau beim Abruf bestimmter Webseiten
•Störungen beim Abruf bestimmter Video- und Audiostreams (Tonaussetzer, Bildruckler, Verpixelungen, Abbrüche)(Achtung nicht bei Fernseh- oder VoD-Streams bei einem Entertainanschluß)
•Schlechte Performance bei bestimmten Gaming-Anwendungen (verspätete Reaktion auf Aktionen, Verbindungsabbrüche) - Lange Pinglaufzeiten zu bestimmten, nicht direkt an das Telekom-Netz angeschlossene Server (Richtwerte:innerhalb Deutschland ca.30-70ms, Nordamerika Ostküste ca.120ms, Westküste ca.200ms). Bei extremer Überlast auf Peeringverbindungen können darüber hinaus auch Paketverluste auftreten
•Schlechte Downloadraten beim Dateidownload von bestimmten Servern bis hin zu Downloadabbrüchen

Wann können diese Symptome auf ein Problem einer Peeringverbindung zurückgeführt werden?
•Die o.g. Störungen treten nicht bei jeglicher Internetkommunikation, sondern nur bei bestimmten Zielen oder Anwendungen und auch nur zu bestimmten Zeiten auf.
•Die Fehler treten nicht einmalig, sondern regelmäßig über mehrere Tage/Wochen (evtl. nur zu bestimmten Zeitenwie z.B. 18-21 Uhr) auf.
•Peeringprobleme haben eine hohe Wirkbreite, daher kommt es in diesem Fall zu einer Häufung ähnlicher Probleme bei mehreren Kunden in gleichen Zeiträumen.
Möglichkeiten zur Analyse bzw. weiteren Eingrenzung:
Einen Traceroute zu dem betroffenen Server starten. Ist im Traceroute ein signifikanter Laufzeitsprung beim Übergang vom Telekom-Backbone zum Peering-Partner (erkennbar am aufgelösten Hostnamen oder Wechsel von IP-Adressbereichen) zu beobachten, deutet dies auf einen Engpass bzw. Performanceprobleme auf dieser Verbindung hin. Laufzeitsprünge hinter diesem Übergang liegen außerhalb des Einflussbereiches der Telekom und deuten auf Leitungsengpässe anderer Provider oder Serverprobleme hin.

Traceroutebeispiel mit Laufzeitsprung auf Peeringübergang:

C:\tracert www.cogentco.com
Routenverfolgung zu cogentco.com [38.100.128.10] über maximal 30 Abschnitte:
1 [1 ms [1 ms [1 ms speedport.ip [192.168.2.1]
2 19 ms 19 ms 19 ms 217.0.119.148
3 19 ms 19 ms 19 ms 217.0.86.86
4 20 ms 20 ms 20 ms f-ea1.F.DE.net.DTAG.DE [62.154.18.22]
5 465 ms 463 ms 464 ms po2-0.core01.fra01.atlas.cogentco.com [212.20.159.38]
6 465 ms 465 ms 465 ms po1-1.core01.fra03.atlas.cogentco.com [130.117.1.197]
7 466 ms 465 ms 482 ms te2-8.ccr01.fra03.atlas.cogentco.com [130.117.1.30]
8 465 ms 464 ms 466 ms te3-3.mpd01.fra03.atlas.cogentco.com [130.117.1.53]
9 466 ms 462 ms 461 ms cogentco.com [38.100.128.10]

Ablaufverfolgung beendet.

Traceroutebeispiel ohne Laufzeitsprung auf Peeringübergang:

C:\tracert youtube.de
Routenverfolgung zu youtube.l.google.com [208.117.236.69] über maximal 30 Abschnitte:
1 [1 ms [1 ms [1 ms speedport.ip [192.168.2.1]
2 19 ms 19 ms 19 ms 217.0.119.148
3 19 ms 19 ms 19 ms 217.0.86.86
4 20 ms 20 ms 20 ms f-ea5.F.DE.net.DTAG.DE [62.154.16.161]
5 20 ms 21 ms 20 ms te-4-4.car2.Frankfurt1.Level3.net [4.68.110.253]
6 29 ms 20 ms 32 ms vlan99.csw4.Frankfurt1.Level3.net [4.68.23.254]
7 21 ms 20 ms 20 ms ae-92-92.ebr2.Frankfurt1.Level3.net [4.69.140.29]
8 29 ms 35 ms 35 ms ae-2-2.ebr1.Dusseldorf1.Level3.net [4.69.132.137]
9 32 ms 35 ms 35 ms ae-48-108.ebr2.Dusseldorf1.Level3.net [4.69.141.90]
10 33 ms 35 ms 35 ms ae-44.ebr1.Amsterdam1.Level3.net [4.69.141.74]
11 28 ms 32 ms 35 ms ae-46-106.ebr2.Amsterdam1.Level3.net [4.69.141.98]
12 46 ms 35 ms 36 ms ae-2.ebr2.London1.Level3.net [4.69.132.133]
13 105 ms 105 ms 105 ms ae-41-41.ebr1.NewYork1.Level3.net [4.69.137.66]
14 115 ms 108 ms 107 ms ae-71-71.csw2.NewYork1.Level3.net [4.69.134.70]
15 105 ms 105 ms 105 ms ae-24-79.car4.NewYork1.Level3.net [4.68.16.70]
16 110 ms 111 ms 111 ms GOOGLE-INC.car4.NewYork1.Level3.net [4.78.166.246]
17 118 ms 118 ms 118 ms 10.33.128.1
18 126 ms 126 ms 126 ms 10.33.254.170
19 182 ms 182 ms 180 ms 10.33.254.121
20 181 ms 183 ms 183 ms 10.33.254.130
21 184 ms 184 ms 184 ms 10.33.176.74
22 185 ms 185 ms 185 ms youtube.com [208.117.236.69]

Wo genau es zu Engpässen kommt, kann man im Traceroute am besten daran erkennen, ab welchem Hop (bezeichnet den Weg über einen Router) sich die Laufzeiten signifikant erhöhen. Oft ist die Engstelle der Punkt (Hop), ab dem die Daten vom Netz der Deutschen Telekom an einen Partner übergeben werden oder dahinter. In den Beispielen sieht man, dass am 4. Hop(x.DTAG.DE) die Antwortzeiten noch gering sind und sich erst später, außerhalb unseres Einflussbereiches, erhöhen.

Bei der Übertragung von Daten im Internet, findet ein permanenter Austausch zwischen dem Netz der Telekom und anderen Netzbetreibern statt. Um zu vermeiden, dass es durch das ständig wachsende Datenvolumen zu Engpässen kommt, ist die Telekom im engen Austausch mit anderen Anbietern.
Für den Ausbau der Kapazitäten bei der Netzzusammenschaltung müssen allerdings beide Seiten einen Beitrag leisten.

Viele Grüße
Oliver I.

Lösung in ursprünglichem Beitrag anzeigen  

In dem Bild mit der Makeriung ist alles hinter Hop 4 bereits außerhalb des Telekom Netzes und das fehlende heißt dur die Server reagieren nicht auf ICMP.  Das Endergebnis ist ja trotzdem 40ms, nur weil die Server dazwischen nicht antworten heißt es nicht das sie nicht arbeiten. 

Mein heimischer Router (Fritzbox 7590) antwortet auch nicht auf ICMP von außen und damit nicht auf einen Ping von außen. Ist eine Einstellungssache. Und trotzdem arbeitet die Box gut.

 

Falls die FRITZ!Box unangeforderte Anfragen aus dem Internet verwerfen soll, anstatt mit ICMP-Kontrollnachrichten zu antworten, aktivieren Sie in der Benutzeroberfläche der FRITZ!Box unter "Internet > Filter > Listen" die Option "Firewall im Stealth Mode". Falls die Option nicht angezeigt wird, aktivieren Sie zunächst die Erweiterte Ansicht.

 

https://avm.de/service/fritzbox/fritzbox-7590/wissensdatenbank/publication/show/57_Sicherheitsfunkti...

 

 

grafik.png


@Florian39  schrieb:

Es äußert sich so, das die Pingzeit bei mir ca. bei 30ms liegt, was bei mir schon hoch ist, sonst immer so bei 15-20ms. das ist nicht das Problem sondern wirklich die Lags, die ja nicht durch die Zeit entstehen.


Ich vermute mal, dass die Lags einfach durch eine Überlast an einem Netzübergang auftreten.

Wenn ein Spiel aktuell gehyped ist, dann kann so etwas vermutlich leicht passieren.

Lösung
Telekom hilft Team
Hallo @Florian39,

der Datenaustausch zwischen den Netzen einzelner Internet-Serviceprovider erfolgt über Internet-Knoten. Dieser Zusammenschluss der Netze nennt sich Peering. Die Knotenpunkte haben eine begrenzte Bandbreite. In Abhängigkeit vom Datenverkehr und der verfügbaren Bandbreite an einem Knotenpunkt kann es zu Engpässen im Datenverkehr von einem Internet-Serviceprovider zu einem anderen kommen. So können unterschiedliche Downloadraten oder Antwortzeiten zu einem Dienst zu unterschiedlichen Tageszeiten entstehen, wenn der Datenverkehr über einen Internet-Knoten geführt wird.

Kommt es aufgrund von Überlastsituationen zu Engpässen bei Übergängen zu Providern, über die der Server erreicht werden muss, wird sich die Ping-Laufzeit verschlechtern, da Pakete am Netzübergang zum anderen Provider in einer Queue (Warteschlange) sequentiell abgearbeitet werden müssen. In einem solchen Fall sind wir bestrebt, mit dem jeweiligen Netzbetreiber eine Aufrüstung der Verbindungen zu erreichen. Eine einseitige Lösung allein durch die Telekom ist in einem solchen Fall nicht möglich. Lediglich das Umrouten des Verkehrs kann ggf. zu einer temporären Entschärfung der Situation führen. Kundenindividuelle Routenwechsel sind technisch nicht umsetzbar.

Bevor von einem Peeringproblem ausgegangen werden kann, sollten lokale Fehler wie gestörte DSL-Verbindungen oder Fehler im Heimnetzwerk (fehlerhafte Verkabelung, gestörtes WLAN, defektes Endgerät) ausgeschlossen werden.


Mögliche Fehlerbilder:
•Verlangsamter Seitenaufbau beim Abruf bestimmter Webseiten
•Störungen beim Abruf bestimmter Video- und Audiostreams (Tonaussetzer, Bildruckler, Verpixelungen, Abbrüche)(Achtung nicht bei Fernseh- oder VoD-Streams bei einem Entertainanschluß)
•Schlechte Performance bei bestimmten Gaming-Anwendungen (verspätete Reaktion auf Aktionen, Verbindungsabbrüche) - Lange Pinglaufzeiten zu bestimmten, nicht direkt an das Telekom-Netz angeschlossene Server (Richtwerte:innerhalb Deutschland ca.30-70ms, Nordamerika Ostküste ca.120ms, Westküste ca.200ms). Bei extremer Überlast auf Peeringverbindungen können darüber hinaus auch Paketverluste auftreten
•Schlechte Downloadraten beim Dateidownload von bestimmten Servern bis hin zu Downloadabbrüchen

Wann können diese Symptome auf ein Problem einer Peeringverbindung zurückgeführt werden?
•Die o.g. Störungen treten nicht bei jeglicher Internetkommunikation, sondern nur bei bestimmten Zielen oder Anwendungen und auch nur zu bestimmten Zeiten auf.
•Die Fehler treten nicht einmalig, sondern regelmäßig über mehrere Tage/Wochen (evtl. nur zu bestimmten Zeitenwie z.B. 18-21 Uhr) auf.
•Peeringprobleme haben eine hohe Wirkbreite, daher kommt es in diesem Fall zu einer Häufung ähnlicher Probleme bei mehreren Kunden in gleichen Zeiträumen.
Möglichkeiten zur Analyse bzw. weiteren Eingrenzung:
Einen Traceroute zu dem betroffenen Server starten. Ist im Traceroute ein signifikanter Laufzeitsprung beim Übergang vom Telekom-Backbone zum Peering-Partner (erkennbar am aufgelösten Hostnamen oder Wechsel von IP-Adressbereichen) zu beobachten, deutet dies auf einen Engpass bzw. Performanceprobleme auf dieser Verbindung hin. Laufzeitsprünge hinter diesem Übergang liegen außerhalb des Einflussbereiches der Telekom und deuten auf Leitungsengpässe anderer Provider oder Serverprobleme hin.

Traceroutebeispiel mit Laufzeitsprung auf Peeringübergang:

C:\tracert www.cogentco.com
Routenverfolgung zu cogentco.com [38.100.128.10] über maximal 30 Abschnitte:
1 [1 ms [1 ms [1 ms speedport.ip [192.168.2.1]
2 19 ms 19 ms 19 ms 217.0.119.148
3 19 ms 19 ms 19 ms 217.0.86.86
4 20 ms 20 ms 20 ms f-ea1.F.DE.net.DTAG.DE [62.154.18.22]
5 465 ms 463 ms 464 ms po2-0.core01.fra01.atlas.cogentco.com [212.20.159.38]
6 465 ms 465 ms 465 ms po1-1.core01.fra03.atlas.cogentco.com [130.117.1.197]
7 466 ms 465 ms 482 ms te2-8.ccr01.fra03.atlas.cogentco.com [130.117.1.30]
8 465 ms 464 ms 466 ms te3-3.mpd01.fra03.atlas.cogentco.com [130.117.1.53]
9 466 ms 462 ms 461 ms cogentco.com [38.100.128.10]

Ablaufverfolgung beendet.

Traceroutebeispiel ohne Laufzeitsprung auf Peeringübergang:

C:\tracert youtube.de
Routenverfolgung zu youtube.l.google.com [208.117.236.69] über maximal 30 Abschnitte:
1 [1 ms [1 ms [1 ms speedport.ip [192.168.2.1]
2 19 ms 19 ms 19 ms 217.0.119.148
3 19 ms 19 ms 19 ms 217.0.86.86
4 20 ms 20 ms 20 ms f-ea5.F.DE.net.DTAG.DE [62.154.16.161]
5 20 ms 21 ms 20 ms te-4-4.car2.Frankfurt1.Level3.net [4.68.110.253]
6 29 ms 20 ms 32 ms vlan99.csw4.Frankfurt1.Level3.net [4.68.23.254]
7 21 ms 20 ms 20 ms ae-92-92.ebr2.Frankfurt1.Level3.net [4.69.140.29]
8 29 ms 35 ms 35 ms ae-2-2.ebr1.Dusseldorf1.Level3.net [4.69.132.137]
9 32 ms 35 ms 35 ms ae-48-108.ebr2.Dusseldorf1.Level3.net [4.69.141.90]
10 33 ms 35 ms 35 ms ae-44.ebr1.Amsterdam1.Level3.net [4.69.141.74]
11 28 ms 32 ms 35 ms ae-46-106.ebr2.Amsterdam1.Level3.net [4.69.141.98]
12 46 ms 35 ms 36 ms ae-2.ebr2.London1.Level3.net [4.69.132.133]
13 105 ms 105 ms 105 ms ae-41-41.ebr1.NewYork1.Level3.net [4.69.137.66]
14 115 ms 108 ms 107 ms ae-71-71.csw2.NewYork1.Level3.net [4.69.134.70]
15 105 ms 105 ms 105 ms ae-24-79.car4.NewYork1.Level3.net [4.68.16.70]
16 110 ms 111 ms 111 ms GOOGLE-INC.car4.NewYork1.Level3.net [4.78.166.246]
17 118 ms 118 ms 118 ms 10.33.128.1
18 126 ms 126 ms 126 ms 10.33.254.170
19 182 ms 182 ms 180 ms 10.33.254.121
20 181 ms 183 ms 183 ms 10.33.254.130
21 184 ms 184 ms 184 ms 10.33.176.74
22 185 ms 185 ms 185 ms youtube.com [208.117.236.69]

Wo genau es zu Engpässen kommt, kann man im Traceroute am besten daran erkennen, ab welchem Hop (bezeichnet den Weg über einen Router) sich die Laufzeiten signifikant erhöhen. Oft ist die Engstelle der Punkt (Hop), ab dem die Daten vom Netz der Deutschen Telekom an einen Partner übergeben werden oder dahinter. In den Beispielen sieht man, dass am 4. Hop(x.DTAG.DE) die Antwortzeiten noch gering sind und sich erst später, außerhalb unseres Einflussbereiches, erhöhen.

Bei der Übertragung von Daten im Internet, findet ein permanenter Austausch zwischen dem Netz der Telekom und anderen Netzbetreibern statt. Um zu vermeiden, dass es durch das ständig wachsende Datenvolumen zu Engpässen kommt, ist die Telekom im engen Austausch mit anderen Anbietern.
Für den Ausbau der Kapazitäten bei der Netzzusammenschaltung müssen allerdings beide Seiten einen Beitrag leisten.

Viele Grüße
Oliver I.

@Oliver I.  schrieb:
Eine einseitige Lösung allein durch die Telekom ist in einem solchen Fall nicht möglich. Lediglich das Umrouten des Verkehrs kann ggf. zu einer temporären Entschärfung der Situation führen. Kundenindividuelle Routenwechsel sind technisch nicht umsetzbar.

Auch ist es nach meinem Verständnis so, dass es eine Route hin gibt - und die wird im Telekomnetz festgelegt. Und dass es eine Route zurück gibt - und die wird im Fremdnetz festgelegt, da kann die Telekom überhaupt nichts machen.

Mal ein Hinweis zu der Erklärung, dass die Verantwortung ab Hop 5 bei einem Peering-Partner liegt.

Das ist augenscheinlich richtig.

Hop 4 gehört noch zur DTAG, Hop 5 jemanden anders.

 

Wenn jetzt Hop 5 deutlich länger zur Antwort benötigt, heißt das nicht, dass das Problem bei jenem Anbieter liegt. Denn das Peering findet zwischen Hop 4 und 5 statt. Es kann also einfach eine zu schwach dimensionierte Leitung zwischen diesen beiden Systemen sein. Daher ist das eine geteilte Angelegenheit zwischen der DTAG und dem Peering-Partner.

Hallo Oliver, 

 

ja kann das alles nachvollziehen was du schreibst und verstehe auch die technische Seite ganz gut , sonst hätte ich mich damit nicht beschäftigt. 

Die Frage ist doch wer legt den die Service Provider fest worüber die Traceroute läuft ? Komisch ist doch nur das es NUR Telekom Kunden betrifft, und alle den HOP bei Telia markant in ihren Tracerouten genauso sehen wie ich auch. 

 

bei dem zweiten Servert ist der Provider Telia ja nicht mit drin und da funktioniert ja alles bestens . 

 

es muss doch möglich sein die Trace Route zu verändern . Wenn jetzt auf einmal aufgrund irgendwelchen Verträgen ein Provider dazwischen genommen wird der diese Leistung und auch die Qualität NICHT leisten kann, dann sehe ich dennoch den Netzbetreiber in der Pflicht diesen herauszunehem. Oder ist das dann die Qualität die Kunden erzählt wird ? 

 

 

Liebe Grüße

 

Florian

 


@Florian39  schrieb:

Wenn jetzt auf einmal aufgrund irgendwelchen Verträgen ein Provider dazwischen genommen wird der diese Leistung und auch die Qualität NICHT leisten kann, dann sehe ich dennoch den Netzbetreiber in der Pflicht diesen herauszunehem.


Verfügbare Bandbreite hat wenig mit Qualität zu tun. Und wenn die Bandbreite raus genommen wird, führt das automatisch zu einer Überlast auf der anderen Route.

Betrifft nicht nur WoT in Verbindung mit Talia, das neue Cod als Beispiel auch.. lässt sich nur abwarten was die Telekom und Talia miteinander abkaspern

@olliMD 

Hm .. ja aber wenn ein Provider dazwischen steckt der eben das nicht liefern kann , ist es sehr wohl ein Qualitätsproblem.. Die frage ist doch warum wird z.B. nicht die funktionierende Route weiterbenutzt ? Bandbreite ok verstehe, aber dann darf ich mir keinen Provider daziwschen packen der das eben nciht liefern kann , man sieht ja das es nicht funktioniert . 

 

warum nimmt man den die Bandbreite raus ? das muss mir dann mal jemand erklären .. das ist doch unlogisch in der heutigen Digitalen Zeit . 

@DasGenie
garnix wird passieren weil sich niemand dafür zuständig fühlt obwohl es eindeutig ist . Der Kunde ist der doofe, naja mal sehen wieviel leute dann in Zukunft ihren Vertrag kündigen werden . 

So habe nochmal nachgesehn. 

 

anbei mal noch Screenshots das defenitiv etwas nciht stimmt. Und es sieht so aus als liegt es am Backbone. Backbone liefert an den nächsten Hop 100% Verlustpakete. 

 

 

Da wird die Telekom nicht viel machen können.


@Florian39  schrieb:
Backbone liefert an den nächsten Hop 100% Verlustpakete.

Du hast das vermutlich immer noch nicht ganz verstanden.

Es mag sein, dass auf ICMP Nachrichten 0% zurückkommt sprich auf ICMP ein Verlust von 100% passiert.

Das heißt aber überhaupt nichts für normale IP-Pakete, die anders als ICMP Pakete eine Payload enthalten - dass die nicht weiter befördert werden würden.

 

@muc80337_2 

 

und wer  kann dann was machen das die ICMP nicht 100% lost sind ? Oder ist das Schicksal für alle die das Problem haben ? wenn ihr darüber ja bescheid wisst was passiert , dann die frage was kann gemacht werden ?  

 

ist schon merkwürdig das es nur Telekomkunden betrifft . Vodafone, Unitymedia etc. haben das Problem nicht und anscheint wissen da  die Provider was sie tun . 


@Florian39  schrieb:

und wer  kann dann was machen das die ICMP nicht 100% lost sind ? . 


Jetzt nerv nicht sondern lies halt mal was man DIr schreibt oder mach Dich im Internet schlau.

 

Dass ein Knoten auf ICMP-Nachrichten nicht antwortet ist sch...egal ob die Pakete aus dem Telekomnetz oder aus einem anderen Netz kommen, das ist eine Konfigurationssache.

 

Das ist wie wenn jemand beim Klingeln an der Haustür nicht antwortet. Aber durch die Haustür kommt er selbst dennoch rein und auch wieder raus.


@Florian39  schrieb:

und wer  kann dann was machen das die ICMP nicht 100% lost sind ?


Der Betreiber des Knotens. Denn der entscheidet, ob der Router seine ganze Kraft auf das Weiterleiten von Paketen mit Nutzdaten konzentriert oder sinnlose Ping-Anfragen beantworten soll.

 

Aber eigentlich sind wir hier nicht da, um einen Grundlagenlehrgang Netzwerke zu geben.

@muc80337_2 

 

wow wozu bist du hier wenn dich sowieso leute nerven .. Ganz ehrlich ich versuche das zu verstehen aber wenn jemand wie du solche aussagen trifft das man nervt dann setzt dich lieber woanders ran . 

 

@olliMD 

ja das verstehe ich, nur wer kann den das sagen wer der nächste Betreiber ist ? das ist ja der Punkt den ich versuche herauszufinden . Jemand der diese Problematik versteht aber selbst nciht hat, der kann schnell sagen es nervt oder sonst was . Aber wozu ist dann ein Forum oder eine Community da ?

 

Freundlichkeit ist hier wohl extrem Groß geschrieben Überglücklich


@Florian39  schrieb:

Aber wozu ist dann ein Forum oder eine Community da ?


Um gezielte Fragen zu beantworten und keine Grundlagenschulung zu betreiben. Du verstehst die Worte von @muc80337_2  schon nicht, ich versuche es auf Urania-Niveau. Um aber die Antworten zu verstehen, sind Grundkenntnisse notwendig. Die Vermittlung kann ein Forum nicht leisten. Und wenn ich es machen wollte, würde ich Seminare an der VHS anbieten und sogar eine Entschädigung dafür bekommen Zwinkernd

Ansonsten gibt es jede Menge Literatur im Netz, um sich einzulesen.


@Florian39  schrieb:

wow wozu bist du hier wenn dich sowieso leute nerven .. Ganz ehrlich ich versuche das zu verstehen aber wenn jemand wie du solche aussagen trifft das man nervt dann setzt dich lieber woanders ran .


Wie kommst Du auf einen solchen Blödsinn, dass mich "sowieso leute nerven"?

 

Offenbar ist das, was ich Dir geschrieben hatte, bereits zu kompliziert für Dich, das ist natürlich schade:

 

@muc80337_2  schrieb:

Es mag sein, dass auf ICMP Nachrichten 0% zurückkommt sprich auf ICMP ein Verlust von 100% passiert.

Das heißt aber überhaupt nichts für normale IP-Pakete, die anders als ICMP Pakete eine Payload enthalten - dass die nicht weiter befördert werden würden.


 

Nabend in die Runde,

 

ich muss leider das auch bestätigen das das Routing zum Server seit ein paar Wochen argh schlecht ist. Das Problem ist bei mir aber schon auf der Seite der Telekom also ab Hop 3-4 da schaukeln sich Pingzahlen bis 4000ms + und die Packetfehler liegen bei 40-50% das ist schon argh.

 

C:\>tracert login.p1.worldoftanks.eu

Routenverfolgung zu woteu1.login.wargaming.net [185.12.240.54]
über maximal 30 Hops:

1 1 ms <1 ms <1 ms fritz.box
2 5 ms 4 ms 4 ms p3e9bf747.dip0.t-ipconnect.de
3 12 ms 11 ms 10 ms pd900c5e5.dip0.t-ipconnect.de [217.0.197.229]
4 464 ms * * 62.157.250.38
5 10 ms 10 ms 10 ms ae33.franco71.fra.seabone.net [195.22.214.165]
6 11 ms 10 ms 10 ms 169.254.0.4
7 10 ms 9 ms 9 ms 10.255.4.137
8 22 ms 22 ms 23 ms 10.255.4.143
9 22 ms 22 ms 22 ms 10.255.1.224
10 22 ms 21 ms 21 ms 10.255.1.181
11 22 ms 22 ms 22 ms am3-sl-a54.fe.core.pw [185.12.240.54]

Ablaufverfolgung beendet.

C:\>

 

Hop 4 gehört meiner Auskunft nach der Deustchen Telekom, oder irre ich mich da? Aber meist sind die Probleme schon bei Hop 3 da schaukeln sich dann die Paketloss hoch und die Pings auch.

Auf T-online.de siehts aber auch übel aus was denn da los?

 

C:\>tracert t-online.de

Routenverfolgung zu t-online.de [62.138.239.100]
über maximal 30 Hops:

1 1 ms <1 ms <1 ms fritz.box
2 6 ms 4 ms 5 ms p3e9bf747.dip0.t-ipconnect.de
3 14 ms 14 ms 14 ms 217.5.104.178
4 16 ms 16 ms 14 ms 62.159.61.230
5 16 ms 15 ms 15 ms hbg-bb3-link.telia.net [62.115.120.70]
6 * * * Zeitüberschreitung der Anforderung.
7 15 ms 15 ms 15 ms ffm-b5-link.telia.net [62.115.114.89]
8 16 ms 15 ms 15 ms ffm-b4-link.telia.net [62.115.116.17]
9 16 ms 15 ms 16 ms akamai-ic-317162-ffm-b4.c.telia.net [62.115.149.23]
10 * * 1347 ms po111.bs-a.sech-fra.netarch.akamai.com [72.52.48.194]
11 554 ms 664 ms 690 ms a72-52-1-157.deploy.static.akamaitechnologies.com [72.52.1.157]
12 17 ms 16 ms 16 ms ae120.access-a.sech-fra.netarch.akamai.com [72.52.48.197]
13 19 ms 19 ms 20 ms a72-52-52-242.deploy.static.akamaitechnologies.com [72.52.52.242]
14 19 ms 18 ms 18 ms www.t-online.de [62.138.239.100]

Ablaufverfolgung beendet.

C:\>

Telekom hilft Team
Hallo @A.Breck

Ich werde mal schauen, ob ich dazu morgen Antworten bekomme. Melde mich wieder hier und "ignoriere" deine selbigen Anfragen in den anderen Threads. Fröhlich

Viele Grüße & einen schönen Sonntag noch.
Nadine H.

Guten Abend,

 

vielen Dank das Sie da dran bleiben, es ist im Moment echt schlimm. Auch wenn ich weiss das durch Corona im Moment viel im Netz los ist, aber gerade deswegen ist da ein gutes Routing A und O. Hier mal aktuelle Screenshots von meinen Routing...