Danke @Sarah S.  fuer Ihre Antwort. Wunschgemaess hab' ich unsere Firmendaten im Profil ausgefuellt.

Wir haben mittlerweile weitere Tests vorgenommen, um das Problem weiter einzugrenzen. Wenn wir von unserem Telekom Firmenanschluss in Roedermark die Telekom "Routen" verwenden lassen, dann gibt es ca. 30% Paketverluste. Die notwendigen Retries des TCP/IP Protokolls machen Downloads somit 6 - 10 mal laenger.

Aber, wenn man vom gleichen Telekom-Anschluss per beliebigen VPN -Anbieter (z.B. NordVPN, Norton VPN , etc.) an den Telekom-eigenen Backbone-Verbindungen vorbeitunnelt, dann passieren die gleichen Downloads in unter einer Minute. Das ist konsistent mit unseren Versuchen von den gleichen Lokationen z.B. mit Vodafone Mobilnetzverbindung die Downloads anzustossen, oder sogar von unserem Standort in New York.

Es gibt nur EIN Scenario, wo der Download der gleichen Datei 10 - 15 Minuten dauert: die Telekom-Routen.

Hier ein Test von soeben, wo wir nochmal den Umkehrfall getestet haben, also vom Web Host in UK (in diesem Fall: 65.151.144.124) zum langsamen DTAG Knoten in Frankfurt (62.156.246.182):

|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                             10.254.64.2 -    0 |  677 |  677 |    0 |    0 |   62 |    5 |
|                            64.34.10.137 -    0 |  677 |  677 |    1 |    2 |   53 |    1 |
|     et-3-2-0.ldn-telehw-cor-1.peer1.net -    0 |  677 |  677 |    2 |    2 |   26 |    3 |
|be6139.rcr21.b023101-0.lon13.atlas.cogentco.com  0|676 |  676 |    2 |    2 |   11 |    2 |
|   be2350.ccr42.lon13.atlas.cogentco.com -    0 |  676 |  676 |    2 |    3 |  162 |    3 |
|                           80.156.162.17 -   21 |  378 |  301 |   15 |   16 |   74 |   16 |
|                          62.156.246.182 -   33 |  295 |  198 |    0 |   69 | 2585 |   17 |

Auch in dieser Richtung sieht man wieder den Abfall ab der urspruenglichh erwaehnten 80.156.162.17 - bis am Ende 1/3 der Pakete verlustig gehen.

Herzlichen Dank fuer Ihr Mithilfe - jeder andere Netz- oder VPN -Anbieter kann das richtig, also sollte das doch sicherlich auch von Ihren Netzwerk-Gurus in den Griff zu bekommen sein, wenn unser Fall nur erstmal bis zu dieser Ebene "hochstoesst".  😉

mostar1981

Ok wollte dir nur helfen

Mit dem Beitrag?

@der_Lutz 

https://youtu.be/vCdczSl9-2Q

Danke trotzdem fuer das Angebot.

Ich bin in der gluecklichen Situation, dass ich als Anbieter einerseits vollen Zugriff auf den Server im Ausland hatte, und andererseits auch auf den privaten Telekom Zugang verschiedener Mitarbeiter in der betroffenen Region. Somit war es mir moeglich, die Paketpfade aus beiden Richtungen zu verfolgen, sogar mit verschiedenen IP-Addressbloecken, und somit die gemeinsame "Bruchstelle" einzugrenzen. 

Ausserdem sind Protokolle wie TCP, IP, BGP etc. meine zweite Muttersprache. In anderen Teilen der Welt hatten wir ein RZ mit eigener A/N, so dass ich intim weiss, wie es aussehen sollte, wenn jemand es RICHTIG machen will (... wenn!).

Da ich wusste, welche Schraube man wo drehen muss, und bei anderen Backbone-Providern kompetente Grespraechspartner fuer die Umsetzung hatte, konnte ich die Schwachstelle Telekom und fuer deren Mangel and Interesse/Kompetenz kompensieren.

Beste Gruesse,

Andy

Ich habe letzten März/April (im 2020 Lockdown) dieselben Probleme gehabt, als ich von zu Hause arbeiten musste. Die Tech-Spezialisten bei meinem Arbeitgeber konnten exakt dieselbe Fehlerquelle identifizieren. Hierbei möchte darauf hinweisen, dass mein Arbeitgeber einer der größten Handelsunternehmen an den globalen Finanzmärkten ist. Vor diesem Hintergrund sind "Latency" und ein reibungsloses und zeitnahes Routing aller Handelsorders absolut kritisch. Daher sind unsere Tech Leute absolute Spezialisten was das Routing von Signalen durch die globalen Telekommunikationsnetze angeht und haben meine Handelsorders damals genauestens nachverfolgt, von mir zu Hause bis zur Ankunft an den Börsencomputern (zB in New Jersey, oder in Frankfurt, oder in London).

Diese Fähigkeit wurde allerdings bei der Telekom Hotline massiv angezweifelt. Man versuchte mir stattdessen einen überteuerten Kundendienstbesuch zu Hause aufzuschwatzen, weil es "bestimmt an meinem Router liegen würde".  So ein Quatsch. Man hat mir Phrasen vorgelesen, die anscheinend auf dem Bildschirm des Hotline Mitarbeiters auftauchten. Es war absurd.

Geduldig habe ich argumentiert und alle technischen "Beweise" versucht mitzuteilen. Im Glauben, dass bei der Telekom genuines Interesse an einer Fehlerbehebung besteht. Allerdings legten die Mitarbeiter(innen) jedesmal sofort auf, als ich anfing die Routeraddressen zu diktieren. Oder ich wurde in die Warteschleife gesetzt und dann wurde aufgelegt. Ich hatte es damals ungefähr ein halbes Dutzend mal probiert, jedesmal mit dem selben Ergebnis: es wurde immer aufgelegt.

Es bestand Null Interesse seitens der Telekom sich der Problematik anzunehmen. Null komma null. Rückblickend ist es sogar eindeutig, dass die Telekom Mitarbeiter geschult sind, derartig detaillierte Hinweise auf ein offensichtlich häufig vorkommendes und bekanntes Problem zu ignorieren.

Für mich war diese Erfahrung natürlich ärgerlich (bis mein Arbeitgeber eine Lösung mit der Firma Vodafone gefunden hat). Mittlerweile find ich es aber aus anthropologischer Sicht sehr interessant. Solche Mitarbeiter muss man auch erstmal finden und selektieren, das ist schon sehr erstaunlich soviel Inkompetenz mit Desinteresse zu verbinden. Hochachtung. 

3 Monate spaeter, und jetzt hat sich das Routing wieder geaendert. Jetzt schleicht aller Verkehr schon wieder durch den Heilbronner Telekom-Knoten 80.156.162.17.

Und, wie zuvor, wenn man ein VPN verwendet, dann geht's ueber den gleichen Anschluss und ueber die gleichen Telekom Leitugn und das gleiche Netz ploetzlich rasend schnell.

Es ist also sehr offensichtlich, dass die VPN Dienste ein zeitgemaesses, dynamisches Routing fuer die Pakete haben, welches Engpaesse umgeht, waehrend die statische Technologie der Telekom den Traffic brutal/absichtlich auf bekanntlich ueberlastete Knoten auflaufen laesst, offensichtlich mit dem Ziel, dass mittelstaendische Kunden fuer teurere Angebote zahlen sollen, die dann qualifizierter bedient werden.

Guten Abend liebes Telekom Team,

ich kann das Problem nachvollziehen und habe genau die gleiche Problematik.

Bei mir ist es die Verbindung von 130.117.51.41 (Cogent Rechenzentrum) zur 80.156.162.17 bzw. zu mir.

Es scheint wohl so, dass die DTAG keinerlei Interesse daran hat das Routing in Ihrem Rechenzentrum zu ändern/optimieren.

Ich bitte dringend darum, dass ihr Rechenzentrum im Rhein-Neckar Raum die Daten korrekt weiter Routet.

Anderfalls wird es wohl notwendig, dass Cogent deren Outbound Route ändern muss, damit es endlich zu einer Lösung kommt.

Gruß