@elfulus 

Wie du dem MTR entnehmen kannst tritt der Verlust aber auch eigentlich erst nach dem Telekomnetz auf und nicht im Telekomnetz.

Level 3 ist außerhalb. Der letzte Punkt ist pd9ef371e und da gibt es noch keinen Paketverlust.

Nutz mal IPv6, da solltest du ne andere Route bekommen. Evt. hat sich das Problem dann schon geklärt.

@FelixKruemel
ich sehe das mit der MTR genauso. Aber es erklärt nicht warum ein Kollege, der bis auf die t-ipconnects davor exakt die gleichen Level3 nodes verwendet und dann zu exakt den gleichen VPN Servern kommt, keine Probleme hat, während der Kollege, der über den gleichen pd9ef371e t-ipconnect an diesem Level3 node hängt, auch die gleichen Probleme hat wie ich . Der erste ipconnect kann es aber auch nicht sein, weil über den auch alle anderen Internet Routen (außerhalb VPN ) ohne Probleme laufen, z.B. Google:

IPv6 ist bei mir keine leichte Option. Habe ich bisher zu Hause auf dem Router abgeschaltet und ist nicht durchgängig auf der anderen Seite.

Seit meiner VPN -Verbindung heute morgen gegen 8.50Uhr hat sich meine Route zum VPN in nur einem Zwischen-Hop verändert, und zwar an genau jenem, der das Problem war. Statt - wie die letzten 3 Tage - immer pd9ef2a8a.dip0.t-ipconnect.de [217.239.42.138] steht da nun die nicht auflösbare IP 217.239.40.102. Zunächst hatte ich damit heute morgen keinerlei Packet loss mehr.

Meine Kollege, der in der selben Situation war wie ich, hatte immer noch den obigen DTAG hop dazwischen und auch immer noch den gleichen Packet loss.

Inzwischen hat sich das gleiche Problem aber auch bei mir über diesen neuen Hop wieder eingestellt und bei meinem Kollegen mit dem ursprünglichen Hop ist es momentan zufriedenstellend.😣

Auf jeden Fall liegt es weder bei mir noch beim Kollegen an den PCs, da das Problem nicht auftaucht, wenn man stattdessen per Wifi hotspot über ein Vodafone Handy geht. Wenn man das im laufenden Betrieb macht, ändert sich nicht mal die VPN IP auf der anderen Seite. Nur die Route läuft dann anders und alles funktioniert nach zwei drei Rucklern klaglos und ohne Packet loss. Wieder zurück auf die Telekom-Route=>wieder packet loss.

Außer dem o.g. Zwischen-Hop ist sonst nur noch der erste Hop ab Fritzbox nur bei uns beiden gleich (p3e9bf014.dip0.t-ipconnect.de [62.155.240.20]), aber das ist der Eingangsknoten, der auch bei anderen Verbindungen außerhalb VPN benutzt wird und dabei scheinbar unproblematisch ist. Langsam gehen mir die Ideen aus 🤔

Was die Peering /Level3-These betrifft: Wir haben einen anderen Kollegen, der aus Neukölln auch Telekom und exakt die gleichen Peering -Knoten und VPN -Adressen benutzt wie wir, aber keine Probleme hat. Bei dem sind nur die vorherigen ipconnect Hops vor dem Level3 Peering komplett anders.

Andererseits war auch mein Packet loss Problem vom März diesen Jahres  in Richtung AWS US auch über exakt diesen Peering -Knoten lag-10.edge4.Berlin1.Level3.net in deren Netz. Heutzutage läuft diese Verbindung von damals direkt (ohne Level3) über pao-sb3-i.PAO.US.NET. DTAG .DE.

Aktuell:

Gruß vom elfulus

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.

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

• immer: Client=>Fritzbox=>p3e9bf014.dip0.t-ipconnect.de =>
• weiter über...
  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)
  
  
  
• immer weiter über....
  =>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

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