Problem mit meinem Server-Provider
Hi ! Ich habe schon des öfteren hier gute und auch verständliche Informationen bekommen und hoffe, mich mit meinem aktuellen Problem hier gut aufgehoben.
Also komme ich mal zur Problematik...
Ich habe seit geraumer zeit bei der WebHosting-Firma "Unt-S*er.de" einen vserver gemietet, der in regelmäßigen Abständen abstürzt und meist nur per Supportanfrage resetet werden kann... Hardreset über das Kundencenter schlägt oft fehl, wenns doch mal glückt, ist der vserver danach erst wieder erreichbar wenn ich mich beim support melde. dieser antwortet zwar schnell, aber dann nur, dass kein problem vorliegt und dann ist mysteriöser weise auch der vserver danach wieder erreichbar...
Im Moment habe ich nur einen TS3 server darauf laufen mit einer maximalen Nutzerzahl von 10... ab 3 Usern kommt es zu Paketverlust... und das nicht wenig, sondern sogut wie bei jedem gesprochenen Satz.
Dazu ne Homepage die meiner Meinung nach auch zu langsam lädt.
Auf Anfrage beim Besitzer der Firma wurde mir die Anweisung gegeben ich sollte ein "tracert" senden. Dies tat ich auch mit folgendem Befehl in "cmd.exe" : tracert vs*.vps4fr**.de
Raus kam dabei dieses hier:
Bild auf Anfrage des Providers zensiert...
Daraufhin wurde mir erklärt, dass MEIN Internetprovider (o2) mich von Kiel (Start) über Hamburg dann über Holland und über Frankreich irgendwie sendet zum server und dass daher der Datenverlust kommt.
ok... soweit so gut... ich wusste es nicht besser und da ich ein gnadenloser "Tester" bin und google dabei gerne mein "Opfer" ist, hab ich dann schlichtweg : "tracert google.de" probiert...
dies ergab dann folgendes:
jeder der nun etwas ahnung davon hat (es genügt Wikipedia -> tracert) wird doch nun denken, dass man selber nicht übers Ausland zum Zielserver kommt, sondern dass der Weg zum Zielserver übers Ausland geht. Zumindest beim oberen Bild.
Dazu kommt, dass ich bei jedem tracert auf meinem vserver eine Zeitüberschreitung bekomme. Diese wird begründet durch Router die nicht auf alles antworten, da sie sonst von 10 rechnern über ping zu "crashen" sind. mh^^
Auf die Frage warum ich bei google diese Zeitüberschreitung nicht bekomme, bekam ich die Antwort, dass ich nicht fragen soll, wenn ichs besser weiss...
Da ich mir aber jetzt nicht sicher bin ob ich es "besser weiss" oder nicht habe ich mich hiermit an euch bei Administrator.de gewendet und hoffe genauso nette Antworten zu bekommen, wie ich sie als unregistrierter Nutzer immer gewohnt war
Floddy
EDIT:: Mein jetziger Provider hat mir direkt nach diesem Post direkt ohne Angabe von Gründen zum Monatsende gekündigt x'D
Ich habe seit geraumer zeit bei der WebHosting-Firma "Unt-S*er.de" einen vserver gemietet, der in regelmäßigen Abständen abstürzt und meist nur per Supportanfrage resetet werden kann... Hardreset über das Kundencenter schlägt oft fehl, wenns doch mal glückt, ist der vserver danach erst wieder erreichbar wenn ich mich beim support melde. dieser antwortet zwar schnell, aber dann nur, dass kein problem vorliegt und dann ist mysteriöser weise auch der vserver danach wieder erreichbar...
Im Moment habe ich nur einen TS3 server darauf laufen mit einer maximalen Nutzerzahl von 10... ab 3 Usern kommt es zu Paketverlust... und das nicht wenig, sondern sogut wie bei jedem gesprochenen Satz.
Dazu ne Homepage die meiner Meinung nach auch zu langsam lädt.
Auf Anfrage beim Besitzer der Firma wurde mir die Anweisung gegeben ich sollte ein "tracert" senden. Dies tat ich auch mit folgendem Befehl in "cmd.exe" : tracert vs*.vps4fr**.de
Raus kam dabei dieses hier:
Bild auf Anfrage des Providers zensiert...
Daraufhin wurde mir erklärt, dass MEIN Internetprovider (o2) mich von Kiel (Start) über Hamburg dann über Holland und über Frankreich irgendwie sendet zum server und dass daher der Datenverlust kommt.
ok... soweit so gut... ich wusste es nicht besser und da ich ein gnadenloser "Tester" bin und google dabei gerne mein "Opfer" ist, hab ich dann schlichtweg : "tracert google.de" probiert...
dies ergab dann folgendes:
jeder der nun etwas ahnung davon hat (es genügt Wikipedia -> tracert) wird doch nun denken, dass man selber nicht übers Ausland zum Zielserver kommt, sondern dass der Weg zum Zielserver übers Ausland geht. Zumindest beim oberen Bild.
Dazu kommt, dass ich bei jedem tracert auf meinem vserver eine Zeitüberschreitung bekomme. Diese wird begründet durch Router die nicht auf alles antworten, da sie sonst von 10 rechnern über ping zu "crashen" sind. mh^^
Auf die Frage warum ich bei google diese Zeitüberschreitung nicht bekomme, bekam ich die Antwort, dass ich nicht fragen soll, wenn ichs besser weiss...
Da ich mir aber jetzt nicht sicher bin ob ich es "besser weiss" oder nicht habe ich mich hiermit an euch bei Administrator.de gewendet und hoffe genauso nette Antworten zu bekommen, wie ich sie als unregistrierter Nutzer immer gewohnt war
Floddy
EDIT:: Mein jetziger Provider hat mir direkt nach diesem Post direkt ohne Angabe von Gründen zum Monatsende gekündigt x'D
Please also mark the comments that contributed to the solution of the article
Content-Key: 152888
Url: https://administrator.de/contentid/152888
Printed on: April 26, 2024 at 08:04 o'clock
5 Comments
Latest comment
Ich habe auch mal einen MTR von einer Alice-Leitung aus gemacht. Alice und o2 nutzen an vielen Stellen die selben Übergabepunkte, jedoch kommen meine Daten nicht übers Ausland. Habe aber auch nicht überall abgefragt, worauf das der IP-Adresse zugehörige AS gemountet ist...
Und weil ich es genauer wissen wollte, habe ich das ganze durch eine getunnelte Verbindung bei einem anderen Internetprovider geschickt - praktisch die gleiche Route und auch hier keine verlorenen Pakete.
Warst du während der Traceroutes eigentlich per Kabel oder per WLAN mit dem Internet verbunden?
Sieht zwar auf den ersten Blick nicht danach aus, aber kabellose Verbindungen haben den Nachteil, dass hier und da ein Paket verloren geht und dadurch die kleinen Sternchen im Traceroute entstehen.
Zu deiner anderen Frage:
Ja, es ist richtig, dass einige Router so konfiguriert werden, dass sie entweder garnicht oder nur mit niedrigster Priorität auf ICMP-Pakete (das sind die Pakete, die für Pings, Traceroutes etc... verwendet werden) reagieren sollen.
Wenn der Router also ein bisschen Stress hat, verwirft er entweder die Pakete oder antwortet zu spät.
Das macht auch Sinn:
Wird ein Router praktisch an die Grenze seiner Belastbarkeit gefahren, weil er z.B. die Aufgabe eines ausgefallenen Routers übernehmen muss, ist das Routing der normalen Datenpakete deutlich wichtiger als auf irgendwelche ICMP-Pakete zu antworten.
Wenn nämlich irgendwo ein Router die Aufgabe eines weiteren übernehmen muss, weil es eine Netzwerkstörung gibt, hängen mit Sicherheit sofort 200 Personen an den Rechnern und schicken pausenlos Traceroutes und Pings dadurch, was den Router in der Tat einfach ausbremsen würde.
Such mal in der Suchmaschine deines geringsten Misstrauens nach "WinMTR" - das ist ein kleines Tool, welches pausenlos Traceroutes macht.
Feuer dann mal so etwa 2-3 Minuten damit auf den Server. Damit kannst du am Besten sehen, an welcher Stelle die meisten Pakete verloren gehen oder wo die Latenzzeiten massiv schwanken. Letzteres ist ein Hinweis auf überlastete Router oder Anbindungen.
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. lo1.br01.wup.de.hansenet.net 0.0% 25 25.4 30.8 25.4 95.7 14.7
2. ae1-108.cr01.dus.de.hansenet.net 0.0% 25 28.6 28.5 26.6 39.0 2.5
3. so-1-1-0-0.cr01.fra.de.hansenet.net 0.0% 25 30.7 32.2 28.8 62.8 6.4
4. ae0-0.pr03.decix.de.hansenet.net 0.0% 25 42.6 31.2 28.7 42.6 2.6
5. decix.edpnet.net 0.0% 25 34.6 31.6 30.6 34.6 1.2
6. 77.109.91.122.static.edpnet.net 0.0% 25 34.6 33.3 31.0 40.6 1.8
7. 10.255.0.174 0.0% 25 40.2 38.0 35.2 48.2 2.7
8. 89.149.223.92 0.0% 25 36.6 36.4 34.7 38.7 1.1
9. 178-162-186-139.local 0.0% 24 36.6 35.8 34.7 37.1 1.0
Und weil ich es genauer wissen wollte, habe ich das ganze durch eine getunnelte Verbindung bei einem anderen Internetprovider geschickt - praktisch die gleiche Route und auch hier keine verlorenen Pakete.
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. pptp.ffm.portunity.de 0.0% 21 34.9 34.0 32.9 37.1 1.1
2. gw1.ffm.portunity.de 0.0% 20 33.3 34.6 32.0 40.8 2.1
3. cisco-f4.tal.de 0.0% 20 34.1 34.5 33.1 36.3 0.8
4. tal-de.r1.fra3.de.opencarrier.eu 0.0% 20 36.1 49.5 33.9 190.5 41.5
5. decix.edpnet.net 0.0% 20 36.1 36.5 34.2 41.6 1.7
6. 77.109.91.122.static.edpnet.net 0.0% 20 36.1 36.9 34.1 46.3 2.4
7. 10.255.0.174 0.0% 20 40.1 41.5 38.2 56.6 3.9
8. 89.149.223.92 0.0% 20 40.1 39.8 38.2 40.8 1.0
9. 178-162-186-139.local 0.0% 20 40.1 39.9 38.2 40.5 0.8
Warst du während der Traceroutes eigentlich per Kabel oder per WLAN mit dem Internet verbunden?
Sieht zwar auf den ersten Blick nicht danach aus, aber kabellose Verbindungen haben den Nachteil, dass hier und da ein Paket verloren geht und dadurch die kleinen Sternchen im Traceroute entstehen.
Zu deiner anderen Frage:
Ja, es ist richtig, dass einige Router so konfiguriert werden, dass sie entweder garnicht oder nur mit niedrigster Priorität auf ICMP-Pakete (das sind die Pakete, die für Pings, Traceroutes etc... verwendet werden) reagieren sollen.
Wenn der Router also ein bisschen Stress hat, verwirft er entweder die Pakete oder antwortet zu spät.
Das macht auch Sinn:
Wird ein Router praktisch an die Grenze seiner Belastbarkeit gefahren, weil er z.B. die Aufgabe eines ausgefallenen Routers übernehmen muss, ist das Routing der normalen Datenpakete deutlich wichtiger als auf irgendwelche ICMP-Pakete zu antworten.
Wenn nämlich irgendwo ein Router die Aufgabe eines weiteren übernehmen muss, weil es eine Netzwerkstörung gibt, hängen mit Sicherheit sofort 200 Personen an den Rechnern und schicken pausenlos Traceroutes und Pings dadurch, was den Router in der Tat einfach ausbremsen würde.
Such mal in der Suchmaschine deines geringsten Misstrauens nach "WinMTR" - das ist ein kleines Tool, welches pausenlos Traceroutes macht.
Feuer dann mal so etwa 2-3 Minuten damit auf den Server. Damit kannst du am Besten sehen, an welcher Stelle die meisten Pakete verloren gehen oder wo die Latenzzeiten massiv schwanken. Letzteres ist ein Hinweis auf überlastete Router oder Anbindungen.
Zitat von @Flodding:
Ich habe seit geraumer zeit bei der WebHosting-Firma "Unt-Server.de" einen vserver gemietet, der in
regelmäßigen Abständen abstürzt und meist nur per Supportanfrage resetet werden kann... Hardreset über
das Kundencenter schlägt oft fehl, wenns doch mal glückt, ist der vserver danach erst wieder erreichbar wenn ich mich
beim support melde. dieser antwortet zwar schnell, aber dann nur, dass kein problem vorliegt und dann ist mysteriöser weise
auch der vserver danach wieder erreichbar...
Das klingt vermurkst. Meine Glaskugel sagt zu dem Problem soweit nix, aber das darf einfach nicht passieren.Ich habe seit geraumer zeit bei der WebHosting-Firma "Unt-Server.de" einen vserver gemietet, der in
regelmäßigen Abständen abstürzt und meist nur per Supportanfrage resetet werden kann... Hardreset über
das Kundencenter schlägt oft fehl, wenns doch mal glückt, ist der vserver danach erst wieder erreichbar wenn ich mich
beim support melde. dieser antwortet zwar schnell, aber dann nur, dass kein problem vorliegt und dann ist mysteriöser weise
auch der vserver danach wieder erreichbar...
Installier den Server doch einfach mal neu und schau ob die Abstürze weg sind.
Empfehlen kann ich dir hier: http://www.netcup.de/vserver (Ich finde es "witzig" dass Dein Provider für seine vServer bei RAM 100% angibt)
Im Moment habe ich nur einen TS3 server darauf laufen mit einer maximalen Nutzerzahl von 10... ab 3 Usern kommt es zu
Paketverlust... und das nicht wenig, sondern sogut wie bei jedem gesprochenen Satz.
Dazu ne Homepage die meiner Meinung nach auch zu langsam lädt.
Auf Anfrage beim Besitzer der Firma wurde mir die Anweisung gegeben ich sollte ein "tracert" senden. Dies tat ich auch
Es kann ja sein, dass Dein Provider doof ist. Aber warum haben denn alle das Problem?Paketverlust... und das nicht wenig, sondern sogut wie bei jedem gesprochenen Satz.
Dazu ne Homepage die meiner Meinung nach auch zu langsam lädt.
Auf Anfrage beim Besitzer der Firma wurde mir die Anweisung gegeben ich sollte ein "tracert" senden. Dies tat ich auch