Netzwerk lahm von Deutschen Anbieter

  • Thread starter Thread starter elmo404
  • Start date Start date
E

elmo404

Guest
Hallo zusammen

Ich könnte echt Hilfe brauchen...

Versuche vergebens meinem Serverhoster klar zu machen, dass der Server den ich von Ihm habe mit der Anbindung ein ernsthaftes Problem hat. Ich habe mir von dem jeweiligen Anbieter ein Server aus dem Restposten ergattert.

Angaben zum Server

Prozessor: Intel Xeon E3-1230v2
RAM: 32 GB DDR3
HDD: 2x 2TB
Anbindung: 100 m/bit

Mir ist bewusst, dass ich mit einer 100 m/bit Anbindung maximal 10-12 mb pro Sekunden runterladen kann. Jedoch reden wir hier von 80-150 Kilobytes in der Sekunde, was mir der Server wiedergibt.

Ich habe Zuhause eine 1 G/Bit Anbindung und lade normalerweise zwischen 90mb bis zu 120mb pro Sekunde runter. Bei dem oben genannten Server war es bei der Anfangszeit ebenfalls so, dass ich zwischen 12-14mb pro Sekunde Upload wie Download hingebracht habe...

Damit ich Euch einen Eindruck verschaffen kann, habe ich eine Testfile in der grösse von 1 Gigabyte hochgeladen und sicher verlinkt. Sagt mir doch bitte bescheid, ob Ihr ebenfalls eine sehr niedrige Downloadrate habt.

wolke.quakehost.ch

1000MB.test

Nextcloud - a safe home for all your data
wolke.quakehost.ch wolke.quakehost.ch

Das testfile befindet sich auf dem Server wo schwierigkeiten macht.

Ich habe dem Anbieter bereits alle schwierigkeiten geschildert.


Hier ein Auszug des Hosters

Sehr geehrte Frau ********

Vielen Dank für Ihre Nachricht. Zum Test Ihrer Serveranbindung nutzen Sie bitte iperf3.


Mein Part

Gesagt getan.

Hier der Auszug von iperf3

[ 4] local 81.7.13.** port 3*290 connected to 85.31.185.** port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 101 MBytes 848 Mbits/sec 2 260 KBytes [ 4] 1.00-2.00 sec 98.9 MBytes 829 Mbits/sec 0 325 KBytes [ 4] 2.00-3.00 sec 97.7 MBytes 820 Mbits/sec 0 351 KBytes [ 4] 3.00-4.00 sec 98.2 MBytes 824 Mbits/sec 0 361 KBytes [ 4] 4.00-5.00 sec 98.7 MBytes 828 Mbits/sec 0 366 KBytes [ 4] 5.00-6.00 sec 98.7 MBytes 828 Mbits/sec 0 369 KBytes [ 4] 6.00-7.00 sec 98.8 MBytes 829 Mbits/sec 0 369 KBytes [ 4] 7.00-8.00 sec 98.6 MBytes 827 Mbits/sec 45 322 KBytes [ 4] 8.00-9.00 sec 98.9 MBytes 829 Mbits/sec 0 352 KBytes [ 4] 9.00-10.00 sec 98.7 MBytes 828 Mbits/sec 0 356 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 988 MBytes 829 Mbits/sec 47 sender [ 4] 0.00-10.00 sec 986 MBytes 827 Mbits/sec receiver iperf Done.

Antwort des Hosters

Sehr geehrte Frau ********
Vielen Dank für Ihre Nachricht. Ihre Anbindung ist also in Ordnung, eine zusätzliche Prüfung ist daher unsererseits nicht nötig. Sofern Sie also Probleme mit dem Download haben, kann das an folgenden Punkten liegen, geordnet absteigend mit der Wahrscheinlichkeit:
* Performanz der Server HDD/zu hoher I/O Load
* Performanz der HDD Ihrer Teststation
* Bandbreite ausserhalb des Datacenters zu Ihrem Testanschluss Wie empfehlen die Prüfung der ersten beiden Punkt, da Sie den 3. Punkt ebensowenig wie wir beeinflussen können.

Mein Part
Alle Punkte wurden sauber kontrolliert und beobachtet. Selbst bei einer null Auslastung der Festplatte ist das Netzwerk lahm... Die Festplatten bringen Datenübertragungen bis zu 467 Megabyte pro Sekunde hin... Tempraturen lassen sich leider nicht auslesen...

Alles dem Hoster so geschildert und seit dato nichts mehr bekommen oder gehört....

Was würdet Ihr tun? Wie kann ich dem Hoster beweisen das die Anbindung zu wenig Leistung bringt?
 
Also bei mir funktionierte das jetzt von mehreren Stellen aus problemlos, getestet von der DTAG, einem Server in Wuppertal, einem Server in Frankreich und einem in Washington - da komme ich auf teilweise über 100 Mbps.

Hast du mal einen Traceroute vom Server zu deinem Anschluss gemacht?
Falls du an der Glasfaser keine eigene IPv4-Adresse hast (DSLite): Gib deinem Server mal eine IPv6-Adresse und versuche, darüber zu laden. Die AFTRs der Provider, die von IPv6 nach IPv4 umsetzen sind gerne mal der Flaschenhals und den kannst du mit nativem IPv6-Traffic umgehen ;-)

Nachtrag:
Oh, mit einem Server habe ich es jetzt doch reproduzierbar hinbekommen, dass es auch unter 1 MByte/s gefallen ist.
Kannst du einmal prüfen, wie der Traceroute von deinem Server zu 217.144.138.248 aussieht?
 
Hallo Lord Gurke :-D

Vielen lieben Dank für deine prompte Antwort.

Ich habe Dir ein Trace Route Screenshot gemacht. Was meinst Du dazu? Bei meinem Anbieter kann ich die ipV6 Funktion anwählen und per sofort aktivieren. Weshalb dies nun auf einmal zu schwierigkeiten kommt ist mir jedoch immer noch unklar.

Hier das Bild:

wolke.quakehost.ch

forum.jpg

Nextcloud - a safe home for all your data
wolke.quakehost.ch wolke.quakehost.ch
 
Der Traceroute ist von deinem Anschluss zum Server? Da sieht es so aus, als wenn mit Erreichen des Netzwerks deines Hosters ordentlich Packetloss auf der Leitung ist.
Kannst du mal von deinem Server aus einen Traceroute oder besser MTR zu deinem Glasfaseranschluss machen? Denn der Traffic kann von A->B einen anderen Weg nehmen als von B-A ;-)

Unter Linxu geht das z.B. ganz gut mit:
Code: 
mtr --report --report-cycles 100 --interval 0.5 ip.deines.anschlusses
 
traceroute to **.eichi.me (213.3.14.43), 30 hops max, 60 byte packets
1 85-31-185-98.gw.dsw-c6kb.as35366.net (85.31.185.98) 0.373 ms 0.463 ms 0.5 53 ms
2 po164.bbsw-h3-j1cr.as35366.net (185.2.8.145) 0.344 ms 0.552 ms 0.445 ms
3 po204.bbsw-h5a-ams.as35366.net (185.2.8.10) 19.993 ms 20.129 ms 20.194 ms
4 te0-0-0-10.rcr21.b031955-0.ams03.atlas.cogentco.com (149.14.141.153) 20.397 ms 20.468 ms 20.622 ms
5 be3197.ccr41.ams03.atlas.cogentco.com (154.54.56.153) 20.372 ms 20.126 ms be3198.ccr42.ams03.atlas.cogentco.com (154.54.57.77) 20.080 ms
6 be2814.ccr42.fra03.atlas.cogentco.com (130.117.0.142) 17.398 ms be2813.ccr4 1.fra03.atlas.cogentco.com (130.117.0.122) 17.333 ms 17.233 ms
7 be3187.agr41.fra03.atlas.cogentco.com (130.117.1.117) 17.456 ms be3186.agr4 1.fra03.atlas.cogentco.com (130.117.0.2) 17.107 ms be3187.agr41.fra03.atlas.cog entco.com (130.117.1.117) 17.540 ms
8 * 80.157.201.197 (80.157.201.197) 18.398 ms 27.708 ms
9 f-ed11-i.F.DE.NET.DTAG.DE (62.154.15.162) 21.740 ms * 19.662 ms
10 62.157.249.182 (62.157.249.182) 27.171 ms * 26.975 ms
11 * i79zhb-005-bun11.bb.ip-plus.net (138.187.130.60) 40.550 ms 44.921 ms
 
1.|-- 91-143-90-251.gw.dsw-c6ka 0.0% 100 0.4 0.5 0.3 1.5 0.1
2.|-- po162.bbsw-h3-j1cr.as3536 0.0% 100 1.2 4.7 0.3 182.7 24.0
3.|-- po204.bbsw-h5a-ams.as3536 0.0% 100 19.9 46.3 19.8 212.8 53.1
4.|-- te0-0-0-10.rcr21.b031955- 0.0% 100 20.2 20.3 20.1 21.5 0.1
5.|-- be3197.ccr41.ams03.atlas. 0.0% 100 20.4 20.4 20.0 21.5 0.1
6.|-- be2813.ccr41.fra03.atlas. 0.0% 100 17.1 17.3 17.0 17.6 0.0
7.|-- be3186.agr41.fra03.atlas. 0.0% 100 17.7 17.4 17.1 17.7 0.0
8.|-- 80.157.201.197 28.0% 100 18.4 24.5 18.3 59.5 8.0
9.|-- f-ed11-i.F.DE.NET.DTAG.DE 24.0% 100 19.2 24.3 19.1 58.6 7.6
10.|-- 62.157.249.182 28.0% 100 27.1 32.1 26.8 63.5 7.7
11.|-- i79zhb-005-bun11.bb.ip-pl 27.0% 100 27.4 32.3 27.0 63.4 7.5
12.|-- be100.zhbic20p-ipn001.blu 23.0% 100 27.6 33.2 27.3 66.7 7.7
13.|-- 213.3.210.65 27.0% 100 27.8 32.8 27.3 66.8 7.0
14.|-- suisse.eichi.me 45.0% 100 28.8 34.0 28.6 66.4 7.9
 
OK... Das könnte ein Indiz dafür sein, dass ab Hop 8 (da, wo Cogent den Traffic an die DTAG gibt) irgendwas ausgelastet ist, weil ab da aus der Gegenrichtung der Packetloss einsetzt.
Ob das aber wirklich so ist, müsste man mit dem MTR mal klären (habe in meinem Post über deinem einmal ergänzt).
Falls sich das da auch bestätigt, müsste dein Hoster mal mit Cogent herumschimpfen oder den Traffic zur Swisscom woanders entlang schicken.
Auf jeden Fall solltest du den entsprechenden MTR machen, denn den kann man dann dem Support hinlegen.

Aus dem MTR ergibt sich das gleiche Bild: Ab Hop 8 hast du sehr ordentlichen Packetloss (23-28% ist schon echt viel), da bekommt man dann natürlich keine guten Geschwindigkeiten hin.
Hier solltest du dem Support diesen MTR mal schicken und darauf hinweisen, dass das eine Störung am Peering zwischen Cogent und Telekom ist und sie dem mal nachgehen sollen und ggf. das Routing entsprechend bei sich mal anpassen, damit der Traffic in Richtung Swisscom nicht über Cogent geroutet wird.
Du kannst meinen Beispiel-MTR von der Telekom aus gerne mitsenden, damit sie sehen, dass es definitiv an Cogent liegt.

An der DTAG liegt es in dem Fall mit hoher Wahrscheinlichkeit nicht, denn von der Telekom aus erreiche ich deine Swisscom-IP gänzlich ohne Packetloss - und es werden sogar die selben Router traversiert wie in deinem Traceroute ab Hop 10:

Code: 
HOST: grob-gw                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 62.155.244.139             0.0%    10    4.2   4.6   4.1   5.7   0.6
  2.|-- 217.5.118.14               0.0%    10    9.2   9.1   8.6   9.3   0.3
  3.|-- 62.157.249.182             0.0%    10    8.3   8.2   8.0   8.4   0.1
  4.|-- i79zhb-005-bun11.bb.ip-pl  0.0%    10   14.2  14.1  13.9  14.6   0.2
  5.|-- be100.zhbic20p-ipn001.blu  0.0%    10   18.4  18.6  18.4  18.8   0.2
  6.|-- 213.3.210.65               0.0%    10   21.7  21.9  21.6  22.1   0.2
  7.|-- xxxxxxxxxxxxxxx            0.0%    10   23.5  23.5  23.3  23.9   0.2
 
Gesagt, getan. Ich habe den Befehl unterhalb ausgeführt.

Code: 
mtr --report --report-cycles 100 --interval 0.5 ip.deines.anschlusses

Ausgabe

1.|-- 91-143-90-251.gw.dsw-c6ka 0.0% 100 0.5 0.5 0.3 8.0 0.8
2.|-- po162.bbsw-h3-j1cr.as3536 0.0% 100 0.3 3.5 0.3 188.4 21.6
3.|-- po204.bbsw-h5a-ams.as3536 0.0% 100 19.9 42.4 19.8 207.7 44.9
4.|-- te0-0-0-10.rcr21.b031955- 0.0% 100 20.3 20.3 20.1 22.4 0.2
5.|-- be3197.ccr41.ams03.atlas. 0.0% 100 20.4 20.3 20.1 21.0 0.0
6.|-- be2813.ccr41.fra03.atlas. 0.0% 100 17.4 17.3 17.0 18.6 0.1
7.|-- be3186.agr41.fra03.atlas. 0.0% 100 17.2 17.4 17.1 17.9 0.0
8.|-- 80.157.201.197 19.0% 100 24.2 21.4 18.3 44.2 4.3
9.|-- f-ed11-i.F.DE.NET.DTAG.DE 29.0% 100 19.6 28.4 19.1 339.0 44.5
10.|-- 62.157.249.182 21.0% 100 26.9 27.8 26.8 38.6 2.3
11.|-- i79zhb-005-bun11.bb.ip-pl 19.0% 100 27.2 27.8 26.9 38.4 2.0
12.|-- be100.zhbic20p-ipn001.blu 29.0% 100 27.5 28.1 27.3 40.3 1.9
13.|-- 213.3******* 20.0% 100 27.8 28.3 27.2 38.2 1.8
14.|-- ***************e 45.0% 100 28.6 29.5 28.6 38.6 1.9
 
Nachtrag dazu:
Da havariert Cogent aktuell definitiv sehr stark durch die Gegend - von der Telekom aus kann ich bestimmte Cogent-Dienste auch nur schwierig erreichen. Und auch hier setzt der Loss an einem Router ein, der sehr stark dem Router aus deinem Hop 8 ähnelt:

Code: 
# mtr -4 www.openstreetmap.org. --report --report-cycles 10
HOST: grob-gw                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 62.155.244.139             0.0%    10    4.3   4.4   3.9   5.8   0.6
  2.|-- 217.239.44.170             0.0%    10    8.5   8.6   8.2  10.1   0.5
  3.|-- 80.157.201.198            30.0%    10   19.7  19.8  19.6  20.0   0.1
  4.|-- be3186.ccr41.fra03.atlas. 10.0%    10   17.9  18.2  17.9  18.7   0.3
  5.|-- be2813.ccr41.ams03.atlas. 50.0%    10   20.3  20.2  20.1  20.3   0.1
  6.|-- be2434.agr21.ams03.atlas. 30.0%    10   20.0  20.1  19.9  20.4   0.2
  7.|-- 154.25.9.250              10.0%    10   20.6  20.7  20.4  21.0   0.2
  8.|-- 130.117.76.11             20.0%    10   19.8  19.7  19.6  19.9   0.1

Entweder ist die Störung morgen von selbst vorbei oder dein Hoster sollte das mal bei Cogent melden, damit die das beheben können.
Hier ist definitiv der Transit-Carrier Cogent der Schuldige in der Nummer.
 
Wahnsinn diese Packetloss Rate... Das sind für mich nicht tragbare Serverdienste die ich so betreiben kann. Was kann ich nun tun? Ich würde grundsätzlich gerne bei diesem Hoster bleiben, jedoch ist der Support ganz stark dazu eingestellt nur unter beweise was zu tun.

Dieses Problem besteht seit 2 Monaten permanent...
 
Oh, zwei Monate...?
Der Packetloss dürfte eigentlich nicht so dauerhaft sein... Zumindest ist er mir bisher nicht aufgefallen, aber da es bei mir ja theoretisch auch Dienste wie OpenStreetMap betrifft, hätte ich das wohl gemerkt.

Im Zweifel ist dennoch jetzt die beste Gelegenheit, dem Support den Packetloss als Beweis zu geben und darum zu bitten, dass sie mal über wen anders als Cogent routen, um das Problem abzustellen.
 
Habe nun die Auszüge, die auch Du bereits hier gesichtet hast, weitergeleitet an den Hoster. Ich bin gespannt was nun bei der Sache rauskommt.

Ja die probleme bestehen seit gut 2 Monaten. Ab und an erreichte der Server auch mal wieder 2-3 Megabyte pro Sekunde, aber nur von kurzer Zeit.
 
Ich könnte mir durchaus vorstellen, dass das Peering zwischen Cogent und DTAG notorisch überlastet ist, weil keine der beiden Seiten irgendwie auf eigene Kosten aufrüsten will.
Aber nachdem sowohl die Swisscom als auch EUServ am DECIX in Frankfurt angeschlossen ist, wäre es ja durchaus denkbar, dass beide da mal ihre Routen austauschen und so einen Weg an Cogent und DTAG vorbei finden ;-)
 
Ohje, was erwarte mich hier noch? Kann sich hier ein Serveranbieter weigern? Was heisst es für mich als Kunden dann eigentlich? Ich kann doch grundsätzlich hierfür nichts...
 
elmo404 said:
Habe nun die Auszüge, die auch Du bereits hier gesichtet hast, weitergeleitet an den Hoster. Ich bin gespannt was nun bei der Sache rauskommt.
Click to expand...
Vllt. wäre es auch sinnvoll, den Support auf diesen Forenthread hier hinzuweisen, um deine Argumente zu untermauern, wo das Problem zu lokalisieren ist.
 
elmo404 said:
Ohje, was erwarte mich hier noch? Kann sich hier ein Serveranbieter weigern? Was heisst es für mich als Kunden dann eigentlich? Ich kann doch grundsätzlich hierfür nichts...
Click to expand...
Naja, wie der Anbieter routet ist natürlich im Prinzip seine eigene Angelegenheit. Die Entscheidung, über wen man routen will, hängt maßgeblich von den Bandbreitenkosten ab (und da ist Cogent quasi der Discounter unter den Carriern), aber genau diese Kosten sinken für den Hoster natürlich, wenn er das über einen öffentlichen Internet-Exchange (wie eben den DECIX) macht - denn da kostet die übertragene Bandbreite nichts extra.

Aber wie ich mir gerade die Webseite von EUserv ansehe trifft mich der Schlag der Ironie: Die lädt auch eher sehr zäh. Weil sie selbst von diesem Packetloss-Problem betroffen sind :cool:
Vielleicht möchtest du ja DAS auch mal als Argument vorbringen *gacker*

Code: 
# mtr www.euserv.com. --report --report-cycles 100
HOST: grob-gw                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 2003:0:8200:4800::1        0.0%   100    4.3   5.8   3.9  67.0   8.4
  2.|-- 2003:0:1308:c000::1        0.0%   100   10.7   9.5   8.8  42.8   3.5
  3.|-- 2003:0:1308:c00d::2       17.0%   100    9.6   9.1   8.7   9.6   0.2
  4.|-- be3186.ccr41.fra03.atlas. 17.0%   100    9.4   9.5   9.1  10.0   0.2
  5.|-- be2845.rcr22.fra06.atlas. 16.0%   100    9.6   9.8   9.4  10.5   0.2
  6.|-- te0-0-2-0.nr11.b015761-1.  2.0%   100   10.2  10.2   9.9  10.7   0.1
  7.|-- 2001:978:2:42::e8:2       19.0%   100   17.1  18.3  16.6 121.9  11.7
  8.|-- po205.ipv6.bbsw-h2-j1a.as 12.0%   100   26.0  29.0  25.9 185.3  18.2
  9.|-- po161.ipv6.dsw-c6ka.as353 23.0%   100   23.6  25.1  23.2 124.2  11.5
 10.|-- 2a02:180:ffff:1::551f:b96 26.0%   100   26.0  26.0  25.7  26.6   0.1
 
Vielleicht kannst du notfalls auch mal fragen, was aus dem Peering mit der Swisscom geworden ist:

EUserv Anbindung und Peerings

EUserv bietet das Hosting von dedizierten Rootservern, vServern, Webspace und Onlinespeicher zu fairen Preisen. In den Tarifen sind professionielle Features und viel inklusiver Traffic enthalten.
www.euserv.com

Denn wenn ein Peering zwischen EUserv und der Swisscom besteht, gibt es keinen vernünftigen Grund, den Traffic mit großem Umweg über Cogent und DTAG dahin zu schieben...
 
Ich möchte niemanden schlecht machen, aber dieses problem mit den Ladezeiten besteht eigentlich schon immer bei EUServ. Was mich eher traurig macht. Den eigentlich haben Sie sehr gute Server Hardware zu einem guten Preis. Das einzige was hier halt völlig daneben liegt ist die Anbindung.

Ich habe EUServ Support nun die Auszüge sowie den Link zu diesem Thread freigegeben. Ich hoffe EUServ liest hier dieses Anliegen und kümmert sich auch drum.

Besten Dank jedoch für die Zeit und hoffe auf eine Verbesserung.


Lord Gurke said:
Vielleicht kannst du notfalls auch mal fragen, was aus dem Peering mit der Swisscom geworden ist:
Click to expand...

Gesehen habe ich es.. Glauben tue ich es aber schon lange nicht mehr. Werde es dementsprechend aber zur Sprache bringen.

Ach und übrigens, hier noch die Trace Route die Du wolltest

Lord Gurke said:
Nachtrag:
Oh, mit einem Server habe ich es jetzt doch reproduzierbar hinbekommen, dass es auch unter 1 MByte/s gefallen ist.
Kannst du einmal prüfen, wie der Traceroute von deinem Server zu 217.144.138.248 aussieht?
Click to expand...
1.|-- 91-143-90-251.gw.dsw-c6ka 0.0% 100 0.3 0.4 0.3 2.4 0.2
2.|-- po161.bbsw-h2-j1a.as35366 1.0% 100 0.7 3.6 0.3 136.7 17.0
3.|-- po205.bbsw-h4a-fra.as3536 0.0% 100 7.6 8.7 7.0 115.7 11.5
4.|-- te0-0-1-2.nr11.b015761-1. 0.0% 100 7.7 7.6 7.4 9.7 0.2
5.|-- te0-7-0-2.rcr22.fra06.atl 0.0% 100 7.4 7.6 7.3 9.2 0.3
6.|-- be2845.ccr41.fra03.atlas. 0.0% 100 7.8 7.7 7.4 8.5 0.0
7.|-- be3186.agr41.fra03.atlas. 0.0% 100 7.7 7.8 7.5 11.8 0.4
8.|-- be2115.rcr21.dus01.atlas. 0.0% 100 17.8 17.8 17.6 19.1 0.2
9.|-- 149.6.139.114 0.0% 100 17.8 19.8 17.8 65.7 6.1
10.|-- bc02-sr2-5-1.wtal.portuni 0.0% 100 17.9 18.0 17.9 23.7 0.6
11.|-- bc01-sr1-ve802.wtal.portu 0.0% 100 17.9 18.3 17.8 25.6 1.3
12.|-- btseed-wuppertal1.wup-de. 0.0% 100 18.0 18.0 17.9 20.2 0.2
 
Last edited by a moderator:
Ich möchte niemanden schlecht machen, aber dieses problem mit den Ladezeiten besteht eigentlich schon immer bei EUServ. Was mich eher traurig macht. Den eigentlich haben Sie sehr gute Server Hardware zu einem guten Preis. Das einzige was hier halt völlig daneben liegt ist die Anbindung.

Ich habe EUServ Support nun die Auszüge sowie den Link zu diesem Thread freigegeben. Ich hoffe EUServ liest hier dieses Anliegen und kümmert sich auch drum.

Besten Dank jedoch für die Zeit und hoffe auf eine Verbesserung.


Lord Gurke said:
Vielleicht kannst du notfalls auch mal fragen, was aus dem Peering mit der Swisscom geworden ist:
Click to expand...

Gesehen habe ich es.. Glauben tue ich es aber schon lange nicht mehr. Werde es dementsprechend aber zur Sprache bringen.

Ich betreibe noch Server aus Russland. Habe eine MTR zum Fall Server gemacht und das kam dabei heraus.


HOST: suisse.eichi.me Loss% Snt Last Avg Best Wrst StDev
1.|-- 1-56-183-213.static.edis. 0.0% 100 0.3 0.7 0.3 7.1 1.0
2.|-- msk-m9-cr3.irb-1976.rasco 0.0% 100 1.2 1.9 1.2 29.5 3.4
3.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
4.|-- be4338.204.ccr21.sto01.at 0.0% 100 44.4 44.5 44.2 49.0 0.4
5.|-- be3376.ccr21.sto03.atlas. 0.0% 100 44.1 44.1 43.9 45.4 0.1
6.|-- be2281.ccr41.ham01.atlas. 0.0% 100 43.7 43.8 43.5 45.9 0.2
7.|-- be2815.ccr41.ams03.atlas. 0.0% 100 44.5 44.3 44.0 47.1 0.3
8.|-- be3197.rcr21.b031955-0.am 0.0% 100 47.3 47.3 47.1 48.2 0.0
9.|-- 149.14.141.154 0.0% 100 44.2 55.0 44.0 310.7 41.2
10.|-- po204.bbsw-h3-j1cr.as3536 0.0% 100 64.4 69.0 63.7 396.8 35.9
11.|-- po162.dsw-c6ka.as35366.ne 0.0% 100 56.9 56.9 56.7 58.6 0.2
12.|-- vm2.quakehost.ch 0.0% 100 66.7 66.7 66.5 67.0 0.0



Ach und übrigens, hier noch die Trace Route die Du wolltest

Lord Gurke said:
Nachtrag:
Oh, mit einem Server habe ich es jetzt doch reproduzierbar hinbekommen, dass es auch unter 1 MByte/s gefallen ist.
Kannst du einmal prüfen, wie der Traceroute von deinem Server zu 217.144.138.248 aussieht?
Click to expand...
1.|-- 91-143-90-251.gw.dsw-c6ka 0.0% 100 0.3 0.4 0.3 2.4 0.2
2.|-- po161.bbsw-h2-j1a.as35366 1.0% 100 0.7 3.6 0.3 136.7 17.0
3.|-- po205.bbsw-h4a-fra.as3536 0.0% 100 7.6 8.7 7.0 115.7 11.5
4.|-- te0-0-1-2.nr11.b015761-1. 0.0% 100 7.7 7.6 7.4 9.7 0.2
5.|-- te0-7-0-2.rcr22.fra06.atl 0.0% 100 7.4 7.6 7.3 9.2 0.3
6.|-- be2845.ccr41.fra03.atlas. 0.0% 100 7.8 7.7 7.4 8.5 0.0
7.|-- be3186.agr41.fra03.atlas. 0.0% 100 7.7 7.8 7.5 11.8 0.4
8.|-- be2115.rcr21.dus01.atlas. 0.0% 100 17.8 17.8 17.6 19.1 0.2
9.|-- 149.6.139.114 0.0% 100 17.8 19.8 17.8 65.7 6.1
10.|-- bc02-sr2-5-1.wtal.portuni 0.0% 100 17.9 18.0 17.9 23.7 0.6
11.|-- bc01-sr1-ve802.wtal.portu 0.0% 100 17.9 18.3 17.8 25.6 1.3
12.|-- btseed-wuppertal1.wup-de. 0.0% 100 18.0 18.0 17.9 20.2 0.2





UPDATE VOM 30.12.2019

Der Hoster wurde am 29.12.2019 über alle Auszüge hier im Forum informiert. Hat bis dato nicht stellung genommen hierzu. Ob es daran liegt, dass es kurz vor Neujahr ist und Leute beurlaubt wurden, ist offen.
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top