Hoher Paketverlust zu (bestimmten?) Telekomkunden

[JimPanse]

Folgendes Szenario: Rechner A (Telekomkunde, DSL, 16Mbit/1Mbit), Rechner B (KD-Kunde, Kabel, 20Mbit/1Mbit), Rechner B hat FTP-Server installiert, Rechner A FTP-Client, Testdatei 100MB groß, beide Rechner haben sonst keine Geschwindigkeitseinbußen, FTP-Serverbetreiberwechsel (A<-B )schaffte keine Abhilfe.

A kann B mit max. Bandbreite (128Kb/s) Datei senden, B kann A Datei aber nur mit 10-20Kb/s senden.

Ein Pathping auf die IP 79.198.110.1 brachte diese Statistik hervor:

Code: Alles auswählen

Routenverfolgung zu p4FC66E01.dip.t-dialin.net [79.198.110.1]
über maximal 30 Abschnitte:
  0  notebook.ANY [192.168.0.2]
  1  192.168.0.254
  2  83-169-162-106-isp.superkabel.de [83.169.162.106]
  3  83-169-174-118-isp.superkabel.de [83.169.174.118]
  4  83-169-183-126-isp.superkabel.de [83.169.183.126]
  5  83-169-128-217-isp.superkabel.de [83.169.128.217]
  6  83-169-128-5-isp.superkabel.de [83.169.128.5]
  7  212.162.4.97
  8  ge-5-1.hsa2.Berlin1.Level3.net [4.68.108.104]
  9  62.156.138.177
 10  bs-eb1.BS.DE.net.DTAG.DE [62.154.99.78]
 11  87.186.246.137
 12     *        *        *
Berechnung der Statistiken dauert ca. 300 Sekunden...
            Quelle zum Abs.  Knoten/Verbindung
Abs. Zeit   Verl./Ges.=   %  Verl./Ges.=   %  Adresse
  0                                           notebook.ANY [192.168.0.2]
                                0/ 100 =  0%   |
  1    0ms     0/ 100 =  0%     0/ 100 =  0%  192.168.0.254
                                0/ 100 =  0%   |
  2    6ms     0/ 100 =  0%     0/ 100 =  0%  83-169-162-106-isp.superkabel.de [83.169.162.106]
                                0/ 100 =  0%   |
  3   18ms     0/ 100 =  0%     0/ 100 =  0%  83-169-174-118-isp.superkabel.de [83.169.174.118]
                                0/ 100 =  0%   |
  4   17ms     0/ 100 =  0%     0/ 100 =  0%  83-169-183-126-isp.superkabel.de [83.169.183.126]
                                0/ 100 =  0%   |
  5   13ms     0/ 100 =  0%     0/ 100 =  0%  83-169-128-217-isp.superkabel.de [83.169.128.217]
                                0/ 100 =  0%   |
  6   16ms     0/ 100 =  0%     0/ 100 =  0%  83-169-128-5-isp.superkabel.de [83.169.128.5]
                                0/ 100 =  0%   |
  7   20ms     0/ 100 =  0%     0/ 100 =  0%  212.162.4.97
                                0/ 100 =  0%   |
  8   13ms     0/ 100 =  0%     0/ 100 =  0%  ge-5-1.hsa2.Berlin1.Level3.net [4.68.108.104]
                                >>>9/ 100 =  9%<<<   |
  9   34ms     9/ 100 =  9%     0/ 100 =  0%  62.156.138.177
                                >>>2/ 100 =  2%<<<   |
 10  ---     100/ 100 =100%    >>>89/ 100 = 89%<<<  bs-eb1.BS.DE.net.DTAG.DE [62.154.99.78]
                                0/ 100 =  0%   |
 11   46ms    11/ 100 = 11%     0/ 100 =  0%  87.186.246.137
                               >>>89/ 100 = 89%<<<   |
 12  ---     100/ 100 =100%     0/ 100 =  0%  notebook [0.0.0.0]

Ablaufverfolgung beendet.

Könnte jemand von Euch einen Pathping auf besagte IP durchführen und das Ergebnis mitteilen bzw. hat jemand eine Erklärung dafür, warum der Paketverlust (markiert mit >>> ... <<<) zwischen den Routern bzw. am Router so hoch ist?

Danke.

[miles]

Das kann viele Gründe haben und würde ich einfach beobachten. Ich denke, dass es nur ein temporärer Zustand ist!

Ein Paket, dass von A nach B geschickt wird, kann eine ganz andere Route nehmen, als ein Paket, dass von B nach A geschickt wird! Auch können mehrere Pakete von A nach B unterschiedliche Routen nehmen. Insbesondere, wenn zwischen 2 Anbietern kein direktes Routing existiert (was hier ja der Fall ist, zumindest laut deinem Trace, da wird ja über Level3 geroutet)

Einfach mal von beiden Seiten aus ein traceroute zum anderen machen! Ggf. sieht man da unterschiedliche Routen!

Nach deinen Trace scheint es zu dem Zeitpunkt im Level3 in Berlin ein Routerproblem gegeben zu haben. Kommt schonmal vor ist aber in der Regel nach kurzer Zeit behoben und betrifft nur einen Teil des Traffics!

[JimPanse]

Das kann viele Gründe haben und würde ich einfach beobachten. Ich denke, dass es nur ein temporärer Zustand ist!

Ein Paket, dass von A nach B geschickt wird, kann eine ganz andere Route nehmen, als ein Paket, dass von B nach A geschickt wird! Auch können mehrere Pakete von A nach B unterschiedliche Routen nehmen. Insbesondere, wenn zwischen 2 Anbietern kein direktes Routing existiert (was hier ja der Fall ist, zumindest laut deinem Trace, da wird ja über Level3 geroutet)

Einfach mal von beiden Seiten aus ein traceroute zum anderen machen! Ggf. sieht man da unterschiedliche Routen!

Nach deinen Trace scheint es zu dem Zeitpunkt im Level3 in Berlin ein Routerproblem gegeben zu haben. Kommt schonmal vor ist aber in der Regel nach kurzer Zeit behoben und betrifft nur einen Teil des Traffics!

Diese Info hatte ich unterschlagen, Route A->B ist eine andere als Route B->A. Nur leider ist es kein temporärer Zustand, immerhin besteht er seit dem ich bei KD bin und es ist keine Besserung in Sicht.

Was mich dabei irritiert, nicht nur der Übergang von Level3 zur DTAG weist Paketverluste auf, sondern nachfolgende DT-Router auch.

KD kann nicht weiterhelfen, und als nicht DT-Kunde kann ich mir jetzt schon die Antwort von der DT denken, wenn ich sie darauf anspreche.

[amax]

Ich komme auch nur bis Berlin ( über Frankfurt), dann ist Schluß.
[ externes Bild ]

[ThoRo]

Was mich dabei irritiert, nicht nur der Übergang von Level3 zur DTAG weist Paketverluste auf, sondern nachfolgende DT-Router auch.

Das dürfte ein Problem im DTAG Netz sein. Selbst als DT Kunde komme ich nicht über die IP 87.186.246.137 hinaus, danach antwortet kein Router mehr..

Code: Alles auswählen

traceroute to 79.198.110.1 (79.198.110.1), 64 hops max, 40 byte packets
 1   (192.168.0.1)  0.904 ms  0.473 ms  0.432 ms
 2  * * *
 3  87.186.246.2 (87.186.246.2)  6.354 ms  6.276 ms  6.641 ms
 4  bs-eb1.bs.de.net.dtag.de (62.154.99.78)  16.176 ms bs-sb1.bs.de.net.dtag.de (62.154.99.126)  13.235 ms bs-eb1.bs.de.net.dtag.de (62.154.99.78)  15.417 ms
 5  87.186.246.137 (87.186.246.137)  14.734 ms  14.709 ms  15.975 ms
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  *

Der 4. Hop sieht schon sehr merkwürdig aus....

MfG

ThoRo

[JimPanse]

Die Route von A nach B sieht wie folgt aus:

Code: Alles auswählen

 1    <1 ms    <1 ms    <1 ms  . [192.168.2.1]
  2     *        *        *     Zeitüberschreitung der Anforderung.
  3     5 ms     5 ms     5 ms  87.186.246.138
  4    11 ms    11 ms    11 ms  62.154.32.226
  5    11 ms    11 ms    11 ms  so-6-0.hsa2.Hamburg1.Level3.net [4.68.127.241]
  6    17 ms    25 ms    21 ms  so-5-1-0.mp1.Hamburg1.Level3.net [4.68.115.254]
  7    36 ms    49 ms    34 ms  so-1-0-0.mp2.Berlin1.Level3.net [4.68.128.38]
  8    72 ms    33 ms    17 ms  ae-12-53.car2.Berlin1.Level3.net [4.68.108.80]
  9    19 ms    19 ms    19 ms  212.162.4.98
 10    34 ms    33 ms    33 ms  83-169-128-6-isp.superkabel.de [83.169.128.6]
 11    24 ms    24 ms    24 ms  83-169-128-218-isp.superkabel.de [83.169.128.218]
 12    21 ms    22 ms    21 ms  83-169-183-122-isp.superkabel.de [83.169.183.122]
 13    24 ms    23 ms    24 ms  83-169-174-113-isp.superkabel.de [83.169.174.113]
 14    45 ms    45 ms    43 ms  91.xx.xx.xx

Eine leicht andere Route, besonders fällt ins Auge, sie geht nicht über den monierten DTAG-Router.

[amax]

Da scheint noch mehr im argen zu liegen.
Bestimmte URL bekommen ich garnicht und trotz z. Z.noch verfügbaren 16000 kbit Bandbreite, laden viele Seiten
gefühlbar langsamer als bei einem 384-light der T-com..

[miles]

Aber dann wird man aus KD-Kunden-Sicht nicht viel mahcen können. Auf das Routing hat man keinen Einfluss und wenn das Problem im Telekom-Netz ist, dann heißt es wohl: Abwarten und hoffen,d ass die da was dran machen!

[mankei]

Moin Boys,

ich habe im IE meine Startseite ändern müssen, weil die von T-Online z. Zt. ein Ewiglader ist.

[amax]

Aber dann wird man aus KD-Kunden-Sicht nicht viel mahcen können. Auf das Routing hat man keinen Einfluss und wenn das Problem im Telekom-Netz ist, dann heißt es wohl: Abwarten und hoffen,d ass die da was dran machen!

Klar liegt das hier wohl in der Verantwortung der T-com........
Aber durch weiteren Ausbau des peering seitens KD, eröffnet sich auch wieder ein etwas weniger belastetes Routing.

Es kann nicht sein, dass wenn man nach z.B Stockholm gelangen möchte, über das Level3.net nach New York geroutet wird,
um dort auf congentco umzusteigen und wieder den Weg komplett zurück zumachen.

Klar diese carrier übergeben in den USA , aber man kann auch an Colt übergeben wie jetzt geschehen.
Glatte 110 ms weniger und 14 statt 28 hop!