Packet loss über Berlin pd9ef2a8a.dip0.t-ipconnect.de [217.239.42.138]
4 years ago
Schönen guten Tag,
seit ca. 24h (vielleicht aber auch länger) habe ich von meinem T-DSL50 Anschluss über einen VPN -Tunnel nach Frankfurt/M. in mein Unternehmen 10% (morgens) bis 40% packet loss (nachmittags). Spätestens dann wird das Arbeiten schwierig bis unmöglich. Zuerst dachte ich natürlich an Probleme beim VPN Server, im Unternehmensnetzwerk oder an meinem PC. Aber nach einiger Analyse konnte ich das ausschließen:
Alle anderen von mir getesteten Routen durchs Internet, die immer über andere dip0.t-ipconnects als die im Betreff laufen, funktionieren problemlos (Google, Zeitungen, MS Office, AWS, internationale Seiten). Nur der Weg zum Unternehmens- VPN Server hat diesen packet loss.
Zudem habe ich die trace / ping / IP Daten von 7 weiteren Kollegen im Home Office abgeglichen, die auch in Berlin und Brandenburg ansässig sind und meist die gleichen Fritzboxen verwenden. Sie nutzen alle die gleichen VPN Server, viele auch Telekom DSL.
Von diesen Kollegen hat außer mir noch ein weiterer das gleiche Problem, die anderen aber nicht. Die einzige Gemeinsamkeit von uns zwei " VPN -Problem-Berlinern", die nur uns beide betrifft, aber alle anderen nicht: wir kommen in unserer Route über pd9ef2a8a.dip0.t-ipconnect.de [217.239.42.138] (er von Hohenschönhausen, ich von Weißensee). Ein weiterer Kollege ohne Probleme sitzt in Neukölln und hat fast die gleichen Geräte, T-DSL, Hops aber leicht andere t-ipconnects (siehe Bild unten links).
Durch Vergleich aller traceroutes, ping Zeiten und VPN Korridore kann ich mit gewisser Sicherheit sagen, dass bei pd9ef2a8a.dip0.t-ipconnect.de der Hase im Pfeffer liegen könnte, weile alle weiteren und früheren Hops auf dem Weg bei den anderen Kollegen auch vorkommen, aber nie Probleme hervorrufen.
Hier ein Bild von traffic zwischen einem Server hinter dem VPN und 4 verschiedenen Kollegen im Home Office. In der Mitte ich und mein Kollege (beide mit Packet Loss), die über den gleichen t-ipconnect laufen:
Vielleicht kann jemand diese Probleme bestätigen oder hat eine Idee, wie man so etwas als Ticket öffnen kann, ohne langwierige DSL-, Fritzbox-Tests und ähnliches über sich ergehen lassen zu müssen? Ich arbeite selber in der IT und würde mir nach Möglichkeit gern die einfachen Helpdesk-Tests ersparen 😉
edit 17:49: habe jetzt auch Störungsticket (yyy) geöffnet.
Beste Grüße vom elfulus
---
Hinweis: Ticketnummer enfernt
1218
12
4 years ago
@elfulus
Bitte probier das mal auch zeitgemäß über IPv6. Wenn es dann auch auftritt ist die Wahrscheinlichkeit für ein Peering Problem zum Anbieter größer.
Mach auch gerne mal nen MTR, da sieht man besser die Anzahl der verlorenen Pakete pro Hop (am besten auch über v4 und v6): https://github.com/White-Tiger/WinMTR
Einige Routing Probleme konnte man hier im Forum schon erfolgreich lösen. Ist es ein Peering / IP-Transit Problem kann das anders aussehen, da die Gegenstelle dann auch entsprechend mitarbeiten (und evt. Bezahlen) muss.
4
Answer
from
4 years ago
Mein MTR:
Der MTR der anderen ist eher ohne Loss.
Die eigentliche letzte Gegenstelle, mit der der Tunnel aufgebaut wird, ist im MTR nicht zu sehen. Im Bild meines ersten Posts kann oben die tracerts zum eigentlichen VPN -Server sehen (den ich aber als Unternehmensdaten aus dem Bild entfernt habe). Dieser VPN -Server mit der selben IP wird aber genauso auch von den anderen Kollegen benutzt, die keine Probleme haben. Peering Probleme würde ich eher ausschließen, weil exakt dieselben Peering nodes auch bei den Kollegen ohne Probleme in der Hop-Liste stehen.
Gruß vom elfulus
Unlogged in user
Answer
from
4 years ago
Hallo,
ich habe ebenfalls seit gestern ähnliche Probleme. Hier sind MTRs zu zwei Spieleservern, der erste in Großbritannien, bei dem keine Probleme auftreten, der zweite in Deutschland (möglicherweise Frankfurt) der nicht spielbar ist. Wohnort ist Marburg, etwa 80km von Frankfurt entfernt.
0
4 years ago
Moin.
Ich habe nun seit Ewigkeiten Probleme mit einigen Peerings im DTAG Netz. Bei mir ist vorallem das gesamte Fastly Netzwerk sehr langsam (peak 1Mbps download). Interessanterweise kann man unten im MTR entnehmen dass man mich wohl durch Level3 schickt bevor ich im Fastly Netzwerk ankomme, obwohl ein direktes Peering mit Fastly besteht.
Außerdem um der bisher vorhandenen Datenmenge in diesem Thread beizutragen hier einmal ein paar MTRs zu euren Problemhosts:
Zu den beiden Runescape servern von @marius13
(Ich denke man kann sich denkten was mit der Magenta Markierung gemeint ist :D)
Kleine Info zu meinem _gateway. Da sind ein paar Firewallregeln drauf die ein bissl streng gegenüber ICMP sind. Daher der teilweise hohe Paketverlust.
4
Answer
from
4 years ago
Ich denke, runescape geht laut der obigen traces mal über GTT und mal über Level3, je nachdem, wer von wo getestet hat.
Die Verbindung zum VPN des TE (also meine 😉) geht aus NO-Berlin auch über Level3. Allerdings gehen auch SW-Berliner Kollegen über DTAG =>Level3 (selber Knoten) zu den selben VPN gateways und haben kaum oder keine Probleme. Dagegen habe ich momentan 33% Loss. Interessanterweise spaltet sich der Traffic zu den load balanced VPN gateways, die sich nur in den letzten 4 bits unterscheiden (x.x.x.15 / x.x.x.21), schon im Telekom-Netz noch vor dem Berliner Level3 Zugang in verschiedene Routen auf, obwohl es bei dieser Bitaufteilung wohl kaum eine andere Subnetmaske wäre🤔:
Ändert aber beim Packet loss sich auch nicht viel:
Gruß vom elfulus.
Answer
from
4 years ago
Guten Tag,
heute läuft es mal über xxxxxx.dip0.t-ipconnect 217.239.40.142 (keine Namensauflösung) und bisher 0% packet loss :-). Level3 Eingang ist genauso wie die letzten 5 Tage (lag-10.edge4.Berlin1.Level3.net, 4.68.73.5)
Fasse mal zusammen, was da die letzten Tage (nicht) lief:
Routen
11.-12.Nov: pd9ef2a8a.dip0.t-ipconnect.de [217.239.42.138] => im Tagesverlauf zunehmend packet loss
13.Nov: ?????????.dip0.t-ipconnect.de [217.239.40.102] => anfänglich ok, im Tagesverlauf wieder zunehmend packet loss
16.Nov: ?????????.dip0.t-ipconnect.de [217.239.40.142] => bisher ok (Stand 16.11., 12:06Uhr)
=>lag-10.edge4.Berlin1.Level3.net [4.68.73.5] => ae-2-3202.ear2.Frankfurt1.Level3.net [4.69.163.82] => Firmen Level3 Eingang=>FirmenVPN Server1/2
Das Einzige, was sich ändert sind die Zwischenhops in der Route und die Auswahl des Load balanced VPN Server auf der Gegenseite. Bezüglich der Wahl einer der beiden VPN Server gibt es aber keinerlei Korrelation mit dem packet loss. Bleiben eigentlich nur die Zwischen-Hops oder unerklärliche Level3-Probleme, die einen nur betreffen, wenn man über eine ganz bestimmte Route zum immer gleichen Level3 gateway kommt.
Störungsticket ist noch offen. Keine Ahnung, ob an irgendeiner Stelle gedreht wurde.
Gruß elfulus
Answer
from
4 years ago
Update: Packet loss Stand 18.00Uhr immer noch 0%
Störungsticket wurde ohne Angaben einer root cause als "behoben" markiert:
Wäre natürlich schön, wenn man mal erfahren würde, wo das Problem lag. Jetzt hoffe ich erstmal, dass die Lösung nachhaltig ist und danke in diesem Fall schonmal dem Telekom-Support.
Gruß vom elfulus
Unlogged in user
Answer
from
4 years ago
bei der Ticketbearbeitung konnten Sie nicht telefonisch erreicht werden. Dann wird das Ticket zurück gestellt und wenn sich der Kunde innerhalb eines Zeitraumes nicht selbst meldet, geschlossen. Insofern gab es hier auch keine Bearbeitung. In der Regel gibt es ein Monitoring des Transportnetzes, mit dem Schwachstellen gefunden werden. Falls möglich auch direkt mit dem Peeringpartner gelöst.
Gruß
Jürgen wo.
0
Unlogged in user
Ask
from