Packet Loss bei 80.156.162.17

[#1]

Unsere Firma hat seit Wochen nachhaltige Probleme von mehreren Standorten (Goettingen, Frankfurt,...), unser Rechenzentrum in UK zu erreichen (z.B. zur IP Addresse 66.155.19.115). Waehrend eine 100 MB Datei ueber Vodafone und andere Anbieter in 1-2 Minuten runterladbar ist, dauert es von allen Telekom-Anschluessen 6 - 10 mal zu lange! Sogar unsere Dienstelle in USA kann von der UK (ueber den Atlantik) in 1 Minute schneller runterladen, als unsere Telekom-Anschluesse in Deutschland.

Es ist direkt mit einem

PING 66.155.19.115 /t

ersichtlich. Waehrend alle getesteten Konkurrenz-Provider oder Kontinente ohne Fehler antworten, haben NUR unsere Telekom-Standorte 40-50% Paketverluste!

Um das Problem aus der GEGENRICHTUNG fuer Sie genauer einzugrenzen, haben wir von unserem UK RZ fuer Sie MTR Tests zu drei verschiedenen Telekom Knoten durchgefuehrt.

In allen Fallen passieren die Aussetzer beim Eintritt von London in das Telekom-Netzwerk bei Ihrem 80.156.162.17. Da das Problem sich in Wochen NICHT "selbst korregiert" hat, ist es also offensichtlich Ihrem "Monitoring" entgangen. 

Wir haben zwar zuerst versucht eine Stoermeldung (Nr. 265239482) zu oeffnen, aber konnten leider dort nicht zu den notwendigen Fachleuten zum Thema Routing/Peering durchdringen. Wir bitten daher um dringende Hilfe, diese Problematik intern in den richtigen Fachbereich zu eskalieren.

Anbei die MTR Logs UK zu drei verschiedenen Telekom Addressen - wo man erkennt, dass ab Ihrem 80.156.162.17 ein sehr wesentlicher Anteil der Pakete nicht durchgehen:

von UK nach 217.5.116.122
|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                             10.254.64.2 -    0 |   75 |   75 |    0 |    0 |    9 |    0 |
|                            64.34.10.137 -    0 |   75 |   75 |    1 |    1 |   29 |    2 |
|100ge-et-3-2-0.ldn-telehw-cor-1.peer1.net -   0 |   75 |   75 |    2 |    2 |   14 |    2 |
|be6139.rcr21.b023101-0.lon13.atlas.cogentco.com 0 | 75 |   75 |    2 |    2 |    4 |    2 |
|   be2350.ccr42.lon13.atlas.cogentco.com -    0 |   75 |   75 |    2 |    2 |   30 |    2 |
|                           80.156.162.17 -   43 |   28 |   16 |   15 |   15 |   17 |   16 |
|           pd9ef3a16.dip0.t-ipconnect.de -   43 |   28 |   16 |   19 |   19 |   20 |   20 |
|                           217.5.111.221 -   40 |   28 |   17 |    0 |   22 |   22 |   22 |
|                           217.5.116.122 -   48 |   25 |   13 |    0 |  368 | 2284 |   23 |
|________________________________________________|______|______|______|______|______|______|

von UK nach 217.0.153.6
|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                             10.254.64.2 -    0 |   47 |   47 |    0 |    2 |   17 |    0 |
|                            64.34.10.137 -    0 |   47 |   47 |    1 |    2 |   39 |    1 |
|100ge-et-3-2-0.ldn-telehw-cor-1.peer1.net -   0 |   47 |   47 |    2 |    2 |   17 |    2 |
|be6139.rcr21.b023101-0.lon13.atlas.cogentco.com 0 | 47 |   47 |    2 |    2 |    4 |    2 |
|   be2350.ccr42.lon13.atlas.cogentco.com -    0 |   47 |   47 |    2 |    3 |   30 |    2 |
|                           80.156.162.17 -   25 |   24 |   18 |    0 |   15 |   16 |   16 |
|           pd9ef3a16.dip0.t-ipconnect.de -   42 |   17 |   10 |    0 |   19 |   27 |   19 |
|             ne-sa21-i.NE.DE.NET.DTAG.DE -   28 |   22 |   16 |   19 |   19 |   32 |   19 |
|           pd9009906.dip0.t-ipconnect.de -   35 |   20 |   13 |   16 |   19 |   66 |   16 |
|________________________________________________|______|______|______|______|______|______|

von UK nach 87.139.11.78
|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                             10.254.64.2 -    0 |   91 |   91 |    0 |    0 |    3 |    0 |
|                            64.34.10.137 -    0 |   91 |   91 |    1 |    2 |   43 |    1 |
|100ge-et-3-2-0.ldn-telehw-cor-1.peer1.net -   0 |   91 |   91 |    2 |    2 |   35 |    2 |
|be6139.rcr21.b023101-0.lon13.atlas.cogentco.com 0 | 91 |   91 |    2 |    2 |    5 |    2 |
|   be2350.ccr42.lon13.atlas.cogentco.com -    0 |   91 |   91 |    2 |    3 |   77 |    2 |
|                           80.156.162.17 -   15 |   56 |   48 |   15 |   15 |   18 |   16 |
|                k-ea8-i.K.DE.NET.DTAG.DE -   20 |   50 |   40 |   17 |   17 |   18 |   17 |
|                k-ea8-i.K.DE.NET.DTAG.DE -   39 |   36 |   22 |   17 |   17 |   17 |   17 |
|                          62.156.246.177 -   28 |   44 |   32 |   16 |   16 |   21 |   21 |
|                          62.156.246.185 -   30 |   41 |   29 |   16 |   16 |   25 |   17 |
|           p578b0b4e.dip0.t-ipconnect.de -   33 |   40 |   27 |   25 |   25 |   26 |   25 |
|________________________________________________|______|______|______|______|______|______|
 

[#2 · Accepted solution]

Hallo @Andy_Schmidt,

es hat etwas gedauert, aber hier habe ich die Antwort für Sie:

Das ist so nicht ganz richtig. Wir haben den Leitungsweg und den betreffenden Übergabepunkt durch unsere Fachabteilung prüfen lassen. Die Überlast-Situation entsteht (wie gesagt) durch Nutzung ungeeigneter Routen außerhalb unseres Netzes. Wir können Ihnen versichern, dass auf unserer Seite ausreichend Kapazitäten vorhanden sind und haben keine Möglichkeit, die Wahl der jeweiligen (Fremdnetz-)Route zu beeinflussen.

Wir bitten Sie um Verständnis, dass unsere Supportmöglichkeiten am Netzübergabepunkt enden und ich Ihnen zum gleichen Sachverhalt keine anderslautende Antwort geben kann.

Viele Grüße Martina Ha.

[#3]

Hallo @Andy_Schmidt,

bitte entschuldigen Sie, dass ich mich so spät melde.

Wir helfen gerne so gut wir können, dazu jedoch bitte ich Sie, ihr Profil zu ergänzen und mir dann hier kurz Bescheid zu geben.

Zu Ihrem Profil kommen Sie hier:
https://telekomhilft.telekom.de/t5/user/myprofilepage/tab/personal-profile%3Atelekom-custom-user-pro...

Beste Grüße,
Sarah S.

[#4]

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".  😉

[#5]

Hallo @Andy_Schmidt,

vielen Dank für das nette Gespräch.

Wie gesagt, habe ich Ihre Angaben zu den Problemen mit dem Peering, einmal an unseren zuständigen technischen Fachbereich zur Überprüfung abgegeben.

Sobald ich hier eine Antwort habe, melde ich mich bei Ihnen.

Viele Grüße Martina Ha.

[#6]

Danke sehr, @Martina Ha. fuer die Nachverfolgung und den Anruf bei meinem Kollegen.

Ich kann aktuell noch ein weiteres wichtiges Detail liefern. Das Problem in Ihrem problem-behafteten Karlsruher Knoten (80.156.162.17) wird umgangen, wenn man es schafft die Routenprioritaeten stattdessen auf Ihren Frankfurter Knoten 80.157.204.69 umzuleiten.

Vielleicht hilft diese Zusatzinfo Ihrem Netzwerkteam als erhaertendes Indiz.

Dies ist nur ein dritter Hinweis, dass es ein Problem mit 80.156.162.17 gibt. (1. Hinweis: andere Netzwerk-Provider am gleichen Standort funktionieren, 2. Hinweis: Geht sogar mit Telekom, solange man mit VPN vorbeiroutet, 3. Hinweis: geht mit Telekom sogar ohne VPN, solange man die obige IP Addresse vermeiden kann)

Ich glaube als aussenstehender Kunde hab' ich nun alle mir zugaenglichen Vorarbeiten geleistet. Hoffentlich verdient mir das das Gehoer bei den technischen Experten in Ihrem Haus.

Beste Gruesse aus New York,

Andy Schmidt

[#7]

Hallo @Andy_Schmidt,

danke für die Informationen. Ich habe Sie an die Verantwortlichen weitergereicht.

Viele Grüße Martina Ha.

[#8]

Hallo @Andy_Schmidt,

hier habe ich die Antwort vom Fachbereich für Sie:

Die Qualität der Kommunikation zwischen Nutzer und Inhalte-Anbieter hängt nicht allein von der Anbindung des Kunden, sondern auch von der des Anbieters ab. Der Anbieter hat eigene Maßstäbe, nach der er diese auswählt oder ausbaut. Verschiedene Anbieter liefern aktuell große Datenmengen an Kunden in unserem Netz aus und nutzen dafür weniger geeignete Wege, wodurch es zu Überlasten kommt. Wir arbeiten mit den Anbietern daran, zusätzliche Kapazitäten in Betrieb zu nehmen. Hier sind wir auch auf das Zutun der Anbieter angewiesen.

Parallel hat ihr Dienstleister die Möglichkeit, ihren Datenverkehr über einen besser geeigneten Weg in unser Netz zu leiten. So wie Sie es geschrieben haben, ist dies ja bereits von Ihnen veranlasst worden.

Viele Grüße Martina Ha.

[#9]

Verehrte @Martina Ha.,

Aufrichtigen Dank fuer die Verbindung zum Fachbereich und die Weiterleitung derer generellen Stellungnahme.

Fuer den konkreten Fall wuenscht sich mein deutscher Klient allerdings ein spezifische Aktion. Als Telekom Kunde zahlt diese Firma ausser fuer die lokale Anbindung, eben auch fuer ein effektives Management Ihres Netzwerkes, was Telekom-Kunden eine reibungslose Internet-Nutzung ermoeglicht.

Es ist nicht akzeptabel, dass die Firma ihren eigenen Netzwerk-Consultant engagieren musste, der Ihrer Fachabteilung dann die genaue Schwachstelle in Karlsruhe aufzeigt und ausserdem genug Kenntisse der Routing-Protokolle besitzt, um bei Drittparteien eine Woche spaeter eine manuelle Umgehung ueber Frankfurt anzustossen.

Stattdessen erwartet Ihr Kunde, dass die Telekom ein angemessenes, internes Monitoring betreibt, damit Sie bei anhaltenden Brandbreitenprobleme pro-aktiv in Ihren Routingtabellen/-datenbanken die Pfadlaenge, Routing-Cost, o.ae. so modifizieren koennen, damit andere Netzwerke solch eine Schwachstelle selbststaendig und unverzueglich de-prioritisieren koennen.

Die Geschaeftsleitung erbittet daher eine qualifizierte Aussage, was bei der Telekom nun als Resultat konkret  unternommen wird, damit man meine Consulting-Dienste nicht in ein paar Wochen erneut einschalten muss, wenn’s bei der Telekom irgendwo anders versagt. Fuer ein Quasi-Monopol bei der Lokalverkabelung gelten strengere Massstabe und man kann sich nicht legitim hinter einem “Zutun der Anbieter” verstecken.

Sie koennen uns auch gerne die Postanschrift des zustaendigen Vorstandes des Netzwerkbereichs mitteilen, damit wir unsere Einschaetzung dort, sowie bei der Bundesnetzagentur, nochmal postschriftlich aktenkundig machen koennen.

Mit freundlichem Gruss,

Andy Schmidt

[#10]

Hallo @Andy_Schmidt,

ich mache mich mal schlau, wer dafür der genaue Ansprechpartner ist.

Es geht doch um den Anschluss bei der hinterlegten Kundennummer in Ihrem Profil?

Viele Grüße Martina Ha.

[#11]

Dankeschoen, @Martina Ha.!

Ja, wir haben das Problem eingangs mit dem Roedermarker Telekom-Firmenanschluss des im Profil hinterlegten Unternehmens in beiden Richtungen eingegrenzt.

Danach haben wir es dann aber auch mit einem anderen Telekom-Anschluss eines Telekom-Privatkunden in Goettigen identisch reproduziert, um extra-sicher auszuschliessen, dass dieses Problem vielleicht nur ein Fehler im lokalen Anschluss sei, oder nur ein "regionales" Problem des Bereich's Darmstadt/Offenbach.

Beste Gruesse,

Andy Schmidt

[#12]

Hallo @Andy_Schmidt,

da Sie mit dem Anschluss Kunde bei T-System sind, kann ich Sie leider nur an Ihren Ansprechpartner dort verweisen, wenn es hier um die Frage der Kosten geht.
Da kann und darf ich Ihnen hier leider nicht weiterhelfen.

Wann es aufgrund von Absprachen mit den anderen Anbietern mehr Kapazitäten geben wird, kann ich Ihnen leider nicht sagen.

Viele Grüße Martina Ha.

[#13]

Hallo @Martina Ha., 

Es geht nicht um die Kosten/Hoehe der Gebuehren, sondern darum dass Ihr Netzwerkbereich bei ueberlasteten Knoten die Routing-Datenbank fuer Ihr Netzwerk so aktualisieren muss, dass diese ueberlasteten Knoten (bis zu einem spaeteren Ausbau) von den Netzwerkpartnern dynamisch de-prioritisiert werden koennen.

---

Wann es aufgrund von Absprachen mit den anderen Anbietern mehr Kapazitäten geben wird, kann ich Ihnen leider nicht sagen.

---

Das verstehe ich vollkommen, dass ein alloziieren zusaetzlicher Resourcen nicht ueber Nacht moeglich ist. Darum ist es eben um so kritischer, dass das DTAG Netzwerk bis dahin einen schwachen Ingress-Punkt in ihr Netzwerk akurat ueber die eigenen Route-Advertisings fuer Dritte "inattraktiv" macht, damit diese dynamisch auf performante Ingress-Punkte ausweichen -- so wie das im Internet weltweit zwischen den Backbone-Partnern die Praxis ist.

---

da Sie mit dem Anschluss Kunde bei T-System sind, ... kann und darf ich Ihnen hier leider nicht weiterhelfen.

---

Wenn die Telekom bei Erwaehnung ihrer Tochergesellschaft T-Systems in die Krise kommt, dann kann ich auch gerne das Profil aendern und stattdessen statt unserem Firmenanschluss unseren gleich betroffenen Telekom Privatanschluss in Kassel eintragen, damit Sie keinen buerokratischen Restriktionen unterliegen. Das Logo auf dem Service-Vertrag aendert nichts am technischen Manko im Netzwerkmanagement, das sich hier als das zugrundeliegende Problem herauskristalliert hat.

Beste Gruesse,

Andy Schmidt

[#14]

Hallo @Andy_Schmidt,

entschuldigen Sie bitte die späte Antwort.

Ich habe Ihr Anliegen noch einmal an unsere Spezialisten weitergeleitet.

Es wird allerdings etwas Zeit in Anspruch nehmen, dies zu überprüfen.

Ich wünsche Ihnen einen guten Rutsch und melde mich dann im neuen Jahr wieder bei Ihnen.

Viele Grüße Martina Ha.

[#15 · Accepted solution]

Hallo @Andy_Schmidt,

es hat etwas gedauert, aber hier habe ich die Antwort für Sie:

Das ist so nicht ganz richtig. Wir haben den Leitungsweg und den betreffenden Übergabepunkt durch unsere Fachabteilung prüfen lassen. Die Überlast-Situation entsteht (wie gesagt) durch Nutzung ungeeigneter Routen außerhalb unseres Netzes. Wir können Ihnen versichern, dass auf unserer Seite ausreichend Kapazitäten vorhanden sind und haben keine Möglichkeit, die Wahl der jeweiligen (Fremdnetz-)Route zu beeinflussen.

Wir bitten Sie um Verständnis, dass unsere Supportmöglichkeiten am Netzübergabepunkt enden und ich Ihnen zum gleichen Sachverhalt keine anderslautende Antwort geben kann.

Viele Grüße Martina Ha.

[#16]

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. 

[#17]

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.

[#18]

Hast du noch die Probleme wir haben jemanden mit einer Leased Line können das gern überprüfen. Würde uns auch Interessieren!

Lg 

[#19]

Zum Glueck hatten wir einen guten Provider, der uns zweimal geholfen hatte, durch Anpassung DERER Routes gezielte, untragbare Telekom Eingangsknoten zu umgehen.  Somit kann ich nichts zum aktuellen Status dieser konkreten Telekom Schnecken-Knoten sagen - bis ich vielleicht durch einen Nebeneffekt einer Aenderung bei irgendeinem "Hop" ploetzlich irgendwo anders bei der Telekom landen werde, die Leute recht gerne vor die buchstaebliche Wand laufen laesst.

[#20]

@Andy_Schmidt 

Das freut mich das du eine Lösung gefunden hast 

Das wundert mich nicht das du hier keine richtige Hilfe bekommen hast. Naja wird oft sehr schnell angeboten nur im bei wichtigen Themen endet es immer mit ,, an der Telekom liegt es nicht . ,,

Naja in deinen Texten stand auch nichts von weiterer produktbuchung

Die einzigsten erfolgreichen Lösungen sind ,, Danke hab jetzt WLAN Knopf gefunden,, oder ,, da ist die Kundennummer ,, 

Ok wollte dir nur helfen aber es geht ja jetzt also schönes Wochenende.

[#21]

---

@mostar1981  schrieb:
Ok wollte dir nur helfen

Mit dem Beitrag?

[#22]

@der_Lutz 

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

[#23]

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

[#24]

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ß