Beiträge von MMax

Zitat von Mordor

Das sollte kein Problem sein. Entweder dein vServer wird nach dem Ende der DDOS Attacke wieder freigegeben, oder netcup wird Dir sicherlich von sich aus anbieten, den Vertrag zu kündigen (wenn die Attacke zu lange dauert).

Auf welchen Äußerungen von netcup und persönlichen Erfahrungen beruhen diese Ansichten?

Ich vermute mal Kunde „___“ wird von meinem Thread erfahren haben. Und da der dort beschriebene Zwischenfall nach über einem Monat immer noch nicht geklärt werden konnte (sonst hätte ich dies bereits mitgeteilt), sind seine Bedenken meiner Ansicht nach auch völlig berechtigt.

Zitat

Wenn Du jetzt schon mit einer Attacke rechnest, ist ein vServer evtl. gar nicht das richtige für dich.

Wann soll er denn sonst mit einer Attacke rechnen? An deinem persönlichen Erfahrungsschatz, wie man DDoS-Attacken auf absehbare Zeit ausschließen kann, wären hier sicherlich einige interessiert.

@___
Falls man an keine Mindestvertragslaufzeit gebunden sein will, bieten sich auch CloudServer an, welche sich aber eher erst für einen etwas größeren Verwendungszweck eignen.

Zu einer Mindestvertragslaufzeit von weniger als drei Monaten würde ich dir aber in jedem Fall raten, wenn du deine Ausgaben zwar niedrig halten, aber dennoch möglichst flexibel bleiben willst.

Zitat von tr1cky

Naja, UDP Services in Deutschland zu schützen wird teurer, ich denke, dass dir netcup hier keine günstige Lösung bereitstellen kann.

Dass ein vServer mit einem derartigen Schutz teurer wird, hatten wir - ich und mein Freund, der den vServer im vorliegenden Fall gemietet hat - bereits vermutet. Ob wir diesen Mehraufwand aber auch wirklich in Zukunft benötigen, lässt sich allerdings nur schwer beurteilen, schließlich kam es gegen uns erst zu einem Angriff dieser Art.

Etwas unverständlich ist für uns vor allem die Vorgehensweise seitens netcup, uns ohne Vorankündigung die IP dauerhaft zu sperren, meinen Freund dann lediglich über den Grund der Sperrung in Kenntnis zu setzen und von ihm im Anschluss eine schriftliche Zusicherung zu verlangen (offenbar zur rechtlichen Absicherung), dass er nicht „erneut“ gegen die AGB verstoßen wird. Einfach aus dem Grund, weil sein vServer „übermäßig viele Ressourcen genutzt“ hätte. Somit wird mein Freund von netcup als Opfer des Angriffs wie ein Täter behandelt. Hinzu kommt, dass nach unserer Auffassung gar keine Pflichtverletzung gegen Punkt 5.7 der AGB vorliegt und bereits in einem ähnlichen Fall in der Vergangenheit ein Amtsgericht die gleichartigen Maßnahmen eines Anbieters als unrechtmäßig beurteilt hat. Demnach sollte man als Kunde von netcup nach meinen bisherigen Erfahrungen besser Rechtswissenschaften studiert haben, überdurchschnittliche Erfahrungen im Bereich der Informationstechnik gesammelt haben und genügend Zeit mitbringen, um bei vergleichbaren Zwischenfällen die bezahlte Leistung gegenüber dem Kundenservice geltend machen zu können.

Zitat von tr1cky

Sollte es nur gelegentlich zu Angriffen kommen, solltest du dir einen Anbieter suchen, der automatisch nullrouted, ansonsten gibt es Anbieter in Deutschland wo die Kosten vor dem Schutz von UDP Angriffen inkl. kleinem Rootserver bei 50€ / Mon. liegen, ich weiß nicht, ob das noch im Budget liegt, aber es wird wohl noch die günstigste Methode sein, dich vor Angriffen zu schützen.

Vielen Dank für deine sachkundigen Ratschläge! Übergangsweise hilf uns derzeitig eines unserer Mitglieder mit einem neuen Serversystem bei einem anderen Anbieter aus, damit wir unsere Dienste nach ca. einer Woche Abwesenheit wieder anbieten konnten. Besonders ärgerlich war für uns der hohe Aufwand der hierfür betrieben werden musste und das unsere Dienste nach dem langen Ausfall derzeitig nur noch von weniger als der Hälfte unserer früheren Besucher wahrgenommen werden.

Ein neuer Anbieter kommt für uns aus Budget-Gründen allerdings erst in Frage, wenn netcup nach der Leistungseinstellung von weiteren Zahlungsaufforderungen für die weitere Vertragslaufzeit gegenüber meinem Freund absieht und einer vorzeitigen Vertragsauflösung zustimmt.

Huch, netcup hat wohl aufgerüstet.

Ich kannte bisher nur das "Feature", dass ich über https manchmal ausgeloggt wurde und dann die Seite nochmal unter http öffnen musste, um wieder antworten zu können.

Die Verwendung der Suche kann gelegentlich hilfreich sein!

• Mein persönlicher Tipp zur Aufzeichnung der hohen Latenzen.
• Eine mögliche Sichtweise seitens netcup zum vorliegenden Sachverhalt.

Zitat von tr1cky

Welche Services laufen auf dem Server? Solltest du lediglich eine Webseite betreiben, kann ich dir eventuell auch behilflich sein, ohne dass zusätzliche Kosten auf dich zukommen.

Im vorliegenden Fall kommt primär die Anwendung Source Dedicated Server auf dem vServer zum Einsatz. Die Daten trafen allerdings auf zufälligen Ports ein und haben dadurch keinen Dienst im speziellen angegriffen.

Zitat von [netcup] Felix

Wenn die Angriffe andauern bleibt einem in dem Fall nur die Möglichkeit in eine Infrastruktur zu investieren, die mit den Angriffen umgehen kann.

Gehen wir als Beispiel davon aus, das Opfer wäre bereits langjähriger Kunde. Der bestehende Vertrag hätte sich erst vor wenigen Monaten um ein weiteres Jahr verlängert und ein erst kürzlich stattgefundener einmaliger DDoS-Angriff hätte nun dazu geführt, dass die IP des Opfers dauerhaft gesperrt wurde und der Vertrag nicht weitergeführt werden kann, solange der Kunde nicht zusichert, dass es in Zukunft keinen (erneuten) Verstoß gegen die AGB geben wird.

Zitat von [netcup] Felix

Wir bieten dafür Firewalls, Loadbalancer und dedizierte Netzwerkuplinks mit entsprechender Bandbreite an. Besonders Angriffe per UDP-Flood erfordern meist eine hohe dedizierte Bandbreite beim Kunden (um andere Kunden nicht zu beeinträchtigen) und einen entsprechenden Paketfilter.

Der Kunde wäre im vorliegenden Beispiel eine Privatperson mit einem monatlichem Einkommen aus einem Angestelltenverhältnis und nicht in der Lage eine individuelle Leistung zu bezahlen, welche ein vielfaches der einkalkulierten Miete für einen mittelgroßen vServer beträgt.

Finanzieren könnte das Opfer maximal einen Anbieter, welcher einen solchen Schutz in größerem Umfang anbietet und die dafür anfallenden Kosten auf alle seine Kunden umlegt.

Welche Maßnahmen sind als Kunde eines Linux-VServers zu treffen, um als Opfer eines DDoS-Angriffs nicht gegen die AGB zu verstoßen?

Zur Ergänzung:
Der Angriff wäre im ungünstigsten Fall mindestens eine DNS Amplification Attack, deren erzeugter Traffic Peak und damit verbundene Schäden dem Kunden als Pflichtverletzung vorgeworfen werden könnten.

Zitat von [netcup] Felix

Eine gelegentliche Responsetime von 200 ms bei einem vServer würde ich aber nicht als starke Verzögerung betrachten.

Was natürlich stark vom Anwendungsfall abhängt. Nun haben Sie ja bereits selber eingeräumt, dass Echtzeitberechnungen, wie sie bei Gameservern häufiger vorkommen, durchaus gewisse Schwierigkeiten damit haben können. Niedrigere Responsetimes (bei angemessener Netzwerkbelastung) werden zwar nicht garantiert, dennoch würde ich mir von Ihnen wünschen, derartige Informationen an uns weiterzugeben, spätestens dann, wenn ein solcher Fall vorliegt.

Zitat

Wie sich die Daten in Ihrem Computerspiel errechnen ist mir nicht bekannt. Wenn ich Ihnen dazu weiter helfen soll, bitte ich Sie weitere Details zu nennen wie die Daten dort errechnet werden.

Um mit den Spielern zu kommunizieren, sendet das Spiel die Daten mittels UDP zwischen dem Server und den Clients. Über die Laufzeit der Pakete wird dann die Latenz errechnet. Evtl. kann Ihnen das der Herr Wachert aber auch noch etwas besser erklären, der ja bekanntlich schon Erfahrung in diesem Bereich gesammelt hat (Siehe: Gameserverdemo #1 Counter-Strike Source).

Zitat

Die Frage verstehe ich nicht. Ich bitte um eine erneute, für mich besser zu verstehende, Fragestellung.

Gut, dann stelle ich die Frage noch einmal anders. Jeder vServer hat Zugriff auf die volle Bandbreite des Nodes, welche zwar fair verteilt wird, aber bei starker Beanspruchung die Responsetime steigen lässt? Ähnliches Verhalten bei mir in der WG, wo ich die Eingangs-Ports des Routers nicht priorisieren kann, wodurch ebenfalls erhöhte Responsetimes entstehen, sobald meine Mitbewohner etwas mit voller Geschwindigkeit herunterladen.

Zitat von [netcup] Felix

Sie können die garantierten Ressourcen uneingeschränkt nutzen. Allerdings können die Vorteile eines vServers ggf. auch zum Nachteil werden (siehe letzter Post von mir dazu).

Ein verzögerter Zugriff auf die Ressourcen ist für uns bereits eine Einschränkung. Wenn ich Sie richtig verstehe, dann ließe sich das von uns geschilderte Phänomen also auf eine für uns ungünstige Verschiebung der Ressourcen durch die von Ihnen eingesetzte Virtualisierung zurückführen.

Zitat

Was wir generell bei einem normalen vServer nicht garantieren, sind Responsetimes bei ICMP-Paketen (bitten Berücksichtigen Sie, dass diese gerne mit niedriger Priorität bearbeitet werden, um andere Pakete zu bevorzugen).

Ich gehe nicht davon aus, dass die Priorisierung von ICMP-Paketen hier Einfluss auf den von uns geschilderten Sachverhalt hat. Die Latenz ist bei den von uns genannten Fällen auch im Spiel erhöht, wie Sie es bereits aus dem Screenshot vom 10.11.2012 entnehmen konnten. Das Spiel sendet hierzu eigene Pakete, welche meines Erachtens nicht niedriger priorisiert werden.

Zitat

Wir bieten gegen Aufpreis optional auch dedizierte Netzwerkports an. Aus Kostengründen lohnt sich dieses aber in der Tat eher bei einem dediziertem Server (Grundpreis 30 Euro / Monat).

Für derartige Überlegungen müsste meiner Einschätzung nach überhaupt erst mal geklärt sein, ob hier eine Auslastung der vorhandenen Netzwerk-Ressourcen vorliegt. Von unserer Seite her würde ich das verneinen oder sind ca. 600kb/s bei zwei vollen CS: S Servern mit jeweils 12 Slots bereits über der zugewiesenen Bandbreite? Andererseits tritt das Problem aber auch schon bei niedrigerer Auslastung auf.

Ergänzung:
Es gibt keinerlei zugewiesene Bandbreite, die vServer auf einem Node davon abhalten würde, die Bandbreite so auszulasten, dass die Latenz für andere nicht steigt?

Zitat von vmk

Anm.: Hervorhebung von mir.

Du widersprichst dir gerade selbst. Wie wäre es mit einem root-Server?

Wo widerspreche ich mir da? Die Latenz ist die meiste Zeit völlig in Ordnung, zeitweise weicht diese dann aber auch deutlich von dem gewohnten Wert ab. Es ist auch nicht so, dass die Latenz zwischenzeitlich mal um 20ms für 2min steigen würde oder so, was vlt. noch zu verkraften wäre. Die Latenz steigt aber eben gleich erheblich, wenn diese vom Normalwert abweicht. Nichts anderes war gemeint, als dass wir eben ein Objekt (den Ball) auf der Karte haben, mit dem die Spieler interagieren und da fallen solche Leistungsschwankungen evtl. mehr ins Gewicht, als auf einer Standardkarte eines Ego-Shooters. Ein Root-Server wäre natürlich ungleich teurer, aber käme in Betracht, wenn man von einem vServer keine gleichbleibend für unsere Zwecke akzeptable Latenz erwarten kann. Diese Aussage wurde vom netcup-Support allerdings bisher so nie gemacht.

Zitat von [netcup] Felix

Wo genau kann ich das dort entnehmen?

Zitat von MMax

[...] Ein aktueller Traceroute vom 19.08.2012 zu netcup.de sollte zudem beweisen, dass der nächstgelegene Host auch weiterhin die IP 37.221.192.3 ist. [...]

Der genaue Wortlaut der Anfrage meines Kollegen:

Zitat

[…] Hierzu auch noch mal ein aktueller Traceroute von meinem vServer zu netcup.de
(78.46.208.25):
$ date && traceroute netcup.de
Sun Aug 19 16:08:11 CEST 2012
traceroute to netcup.de (78.46.208.25), 30 hops max, 60 byte packets
1 37.221.192.3 (37.221.192.3) 0.209 ms 0.181 ms 0.168 ms
2 netcup.de (78.46.208.25) 0.144 ms 0.177 ms 0.167 ms

Wie Sie erkennen können, ist der nächstgelegene Host immer die IP 37.221.192.3, daran hat
sich nichts geändert. […]

Alles anzeigen

Zitat von [netcup] Felix

Das lässt sich nicht bestimmen. Allerdings sind die Nodes in der Regel gleich konfiguriert. Der Node auf dem Ihr vServer läuft gleicht der gängigsten Konfiguration. Andere Kunden auf dem Node haben keine Probleme wie Sie.

Was damit zusammenhängen könnte, dass deren Anwendungsschwerpunkt oft woanders liegt und derartige Latenz-Sprünge da nicht weiter auffallen.

Zitat von [netcup] Felix

Gerne können Sie auch beim Support um einen Node-Wechsel bitten. So können Sie Probleme am Node zu 100% ausschließen.

Die Möglichkeit werde ich mit meinem Kollegen diskutieren. In der Vergangenheit hatte dies bereits einmal für einen längeren Zeitraum geholfen. Letzten Endes scheint es Ihren Ausführungen nach aber keine Garantie dafür zu geben, dass eine solche Maßnahme dauerhaft derartige Probleme beheben könnte, wenn die Nodes alle gleichermaßen eingestellt und auch belastet werden.

Zitat von [netcup] Felix

Die Responsetimes sind ja auch durchaus im grünen Bereich. Daher ist es wohl ganz normal das die Load unter 1 liegt. Diese sollten nicht für "Ruckler" in gängigen Gameservern verantwortlich sein.

In „gängigen Gameservern“ wie CS: S, CS, TF2, HL2DM, L4D2 und CoD führt eine Latenz von über 150ms anstatt wie sonst üblich von unter 1ms, zum ersten Host hinter dem vServer, vermutlich zu Situationen, wo ein Spieler bereits hinter einer Ecke verschwunden ist, vom Gegenspieler aber dennoch gesehen und auch getroffen wird.

Zitat von [netcup] Felix

Bedenken Sie bitte auch das vServer nicht unbedingt für aufwendige Echtzeitberechnungen geeignet sind, da vServer neben den garantierten Ressourcen auch zusätzliche Ressourcen nutzen können, sollten andere vServer auf dem Node diese nicht benötigen. In dem Moment wo diese allerdings benötigt werden, finden Verschiebungen der Ressourcen statt. Z.B. werden die Recheneinheiten an den CPUs vermindert. Ich kann mir durchaus vorstellen, dass sich dieses negativ auf einige Gameserver auswirkt.

Zugegeben, wir erwarten von einem vServer in unserem Fall eine besonders niedrige Latenz, da die Spieler sehr sensibel auf erhöhte Verzögerungen zum Server bei der von uns verwendeten Fußballkarte reagieren. Eine derartige Aussage, dass die von Ihnen „garantierten Ressourcen“ (in unserem Fall 4 GHz CPU-Leistung und 2 GB Arbeitsspeicher) sich nicht für eine uneingeschränkte Verwendung eignen würden, das hören mein Kollege und ich von Ihnen zum allerersten Mal.

Zitat von [netcup] Felix

Der Host http://www.netcup.de wird nie auf ICMP reagieren.

Gut zu wissen. In der Vergangenheit ging dies jedenfalls noch, wie Sie es aus einer Anfrage meines Kollegen vom 19.08.2012 entnehmen können. Das ist aber auch nicht weiter tragisch, denn wie Sie erkennen können, tritt die erhöhte Latenz, wie in allen anderen hier genannten Fällen auch, bereits am nächstgelegenen Host auf.

Zitat

Wenn die Latenz am letztem Hop, sprich in dem Fall an Ihrem vServer so hoch ist, bitte diesen prüfen. Wenn Sie dann immer noch der Meinung sind das ein Problem bei netcup vorliegt, prüfen Sie doch einmal eine IP-Adresse die neben der Ihren liegt.

Die Bandbreitenauslastung lässt sich ja bei Ihnen als Kunde leider nicht überprüfen. Wie wäre es mit einem Traceroute von meinem Privatrechner zu 88.198.182.45? Die Route scheint zwar der unseres vServers zu gleichen, doch wie verlässlich ist diese Überprüfung, wenn der vServer in der Vergangenheit bereits einmal samt IP auf einen anderen Node umgezogen ist?

Zitat

Auch empfehlen wir zu beachten, dass Gameserver z.B. verzögert antworten wenn ein anderes Programm auf dem Server, z.B. der Apache, gerade Ressourcen benötigt. Auf der von Ihnen genannten IP-Adresse, antwortet ein Apache. Wenn Sie gleichmäßige Responsetimes haben möchten, sollten Sie auch für eine gleichmäßige Auslastung auf Ihrem System sorgen.

Wie Sie aus dem Log des von mir erstellten Shell-Scripts zum Messen der Latenz zwischen dem vServer und dem nächstgelegenen Host feststellen können, liegt die Durchnittsbelastung des vServers fast immer unter 1.00, wenn die Latenz erhöht ist. So auch gestern zwischen 22:11 und 23:46 Uhr. Eine Bandbreitenauslastung durch den Apache-Dienst käme über so einen langen Zeitraum einem Angriff gleich, da dieser bis für die Motd-Seiten im Spiel und für die benutzerdefinierten Dateien für die Spieler bei uns kaum Verwendung findet. Selbstverständliche habe ich mir die Logs des Apache-Dienstes auch mal dahingehend angeschaut. So gab es z. B. gestern zwischen 22:15 und 22:24 Uhr keinerlei Anfragen an diesen, dennoch hat mein Shell-Script aber für diesen Zeitraum erhöhte Latenzen gemessen.

2012-11-10 22:15:04 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=169 ms | load average: 0.25
2012-11-10 22:15:24 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=154 ms | load average: 0.25
2012-11-10 22:15:34 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=169 ms | load average: 0.21
2012-11-10 22:15:44 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=172 ms | load average: 0.18
2012-11-10 22:15:55 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=153 ms | load average: 0.29
2012-11-10 22:16:05 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=142 ms | load average: 0.32
2012-11-10 22:16:15 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=166 ms | load average: 0.27
2012-11-10 22:16:25 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=178 ms | load average: 0.23
2012-11-10 22:16:35 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=175 ms | load average: 0.27
2012-11-10 22:16:46 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=179 ms | load average: 0.30
2012-11-10 22:16:56 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=185 ms | load average: 0.25
2012-11-10 22:17:06 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=172 ms | load average: 0.37
2012-11-10 22:17:16 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=186 ms | load average: 0.39
2012-11-10 22:17:26 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=170 ms | load average: 0.41
2012-11-10 22:17:37 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=155 ms | load average: 0.43
2012-11-10 22:17:47 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=149 ms | load average: 0.43
2012-11-10 22:17:57 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=161 ms | load average: 0.44
2012-11-10 22:18:07 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=154 ms | load average: 0.45
2012-11-10 22:18:17 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=171 ms | load average: 0.46
2012-11-10 22:18:27 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=165 ms | load average: 0.38
2012-11-10 22:18:38 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=164 ms | load average: 0.40
2012-11-10 22:18:48 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=154 ms | load average: 0.33
2012-11-10 22:18:58 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=160 ms | load average: 0.28
2012-11-10 22:19:08 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=165 ms | load average: 0.24
2012-11-10 22:19:18 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=164 ms | load average: 0.20
2012-11-10 22:19:38 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=168 ms | load average: 0.36
2012-11-10 22:19:49 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=183 ms | load average: 0.30
2012-11-10 22:19:59 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=160 ms | load average: 0.25
2012-11-10 22:20:09 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=162 ms | load average: 0.30
2012-11-10 22:20:19 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=181 ms | load average: 0.40
2012-11-10 22:20:49 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=176 ms | load average: 0.36
2012-11-10 22:21:20 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=177 ms | load average: 0.41
2012-11-10 22:21:40 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=179 ms | load average: 0.29
2012-11-10 22:21:50 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=177 ms | load average: 0.24
2012-11-10 22:22:00 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=161 ms | load average: 0.20
2012-11-10 22:22:11 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=170 ms | load average: 0.25
2012-11-10 22:22:21 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=168 ms | load average: 0.21
2012-11-10 22:22:31 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=170 ms | load average: 0.26
2012-11-10 22:22:41 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=171 ms | load average: 0.30
2012-11-10 22:22:51 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=173 ms | load average: 0.25
2012-11-10 22:23:01 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=177 ms | load average: 0.29
2012-11-10 22:23:12 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=164 ms | load average: 0.25
2012-11-10 22:23:22 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=160 ms | load average: 0.21
2012-11-10 22:23:32 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=184 ms | load average: 0.25
2012-11-10 22:23:52 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=133 ms | load average: 0.41
2012-11-10 22:24:12 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=157 ms | load average: 0.44
2012-11-10 22:24:23 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=159 ms | load average: 0.37
2012-11-10 22:24:33 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=164 ms | load average: 0.31
2012-11-10 22:24:43 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=161 ms | load average: 0.26
2012-11-10 22:24:53 64 bytes from 37.221.192.3: icmp_req=1 ttl=63 time=174 ms | load average: 0.22

Im Spiel macht sich die erhöhte Latenz natürlich auch bemerkbar:
[Blockierte Grafik: http://88.198.182.44/hohelatenz.jpg]

Da die erhöhte Latenz zum vServer gerade wieder besteht, hier mal ein paar Ergebnisse mit Traceroute von unterschiedlichen Standorten und in beide Richtungen.

2012-11-10 22:28 von meinem PC zum vServer

C:\***>tracert 88.198.182.44




Routenverfolgung zu static.88-198-182-44.clients.your-server.de [88.198.182.44]
über maximal 30 Abschnitte:




  1     1 ms     1 ms     1 ms  *** [192.***]
  2    28 ms    36 ms    28 ms  *** [***]
  3    27 ms    27 ms    27 ms  core1.ber.qsc.de [87.234.11.149]
  4    42 ms    42 ms    43 ms  core1.fra.qsc.de [87.234.12.105]
  5    44 ms    51 ms    44 ms  decix-gw.hetzner.de [80.81.192.164]
  6    48 ms    48 ms    47 ms  hos-bb1.juniper1.rz6.hetzner.de [213.239.240.238
]
  7    47 ms    47 ms    47 ms  gw01-hetzner.netcup.net [78.47.244.254]
  8   226 ms   222 ms   228 ms  static.88-198-182-44.clients.your-server.de [88.
198.182.44]




Ablaufverfolgung beendet.

2012-11-10 22:29 von traceroute.eu zum vServer

traceroute to 88.198.182.44 (88.198.182.44), 30 hops max, 60 byte packets
1 	static.185.212.4.46.clients.your-server.de 	46.4.212.185 	de 	3.686 ms 	3.694 ms 	3.766 ms
2 	hos-tr1.juniper1.rz13.hetzner.de 	213.239.224.1 	de 	0.167 ms 	 	 
	hos-tr4.juniper2.rz13.hetzner.de 	213.239.224.97 	de 	0.125 ms 	 
	hos-tr2.juniper1.rz13.hetzner.de 	213.239.224.33 	de 	0.119 ms
3 	hos-bb2.juniper1.rz6.hetzner.de 	213.239.240.143 	de 	3.025 ms 	2.975 ms 	3.002 ms
4 	gw01-hetzner.netcup.net 	78.47.244.254 	de 	3.128 ms 	3.108 ms 	3.112 ms
5 	static.88-198-182-44.clients.your-server.de 	88.198.182.44 	de 	175.249 ms 	175.251 ms 	175.239 ms

2012-11-10 22:32 vom vServer zu http://www.netcup.de

$ date && traceroute www.netcup.de
Sat Nov 10 22:32:15 CET 2012
traceroute to www.netcup.de (78.46.208.25), 30 hops max, 60 byte packets
 1  37.221.192.3 (37.221.192.3)  181.358 ms  176.879 ms  176.871 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Zitat von Duschcreme

Code

Wed Oct 24 22:16:34 CEST 2012
Linux *** 3.0.42-vs2.3.2.4.0-nc #1 SMP Tue Sep 11 20:27:13 UTC 2012 x86_64 GNU/Linux

Das ist nicht die Version mit der wir die Probleme hatten (3.5.3-vs2.3.4.2.0-nc).

Zitat von Duschcreme

NetCup Antwort war natürlich ne Standard Antwort... es liegt natürlich an meinem vServer an dem ich seit 2 Wochen nichts gemacht habe...

Bei meinem Kollegen gab’s diesmal noch gar keine direkte Antwort, außer die oben erwähnte Systemnachricht.

Zitat von Duschcreme

Jemand Erfahrung mit dem hier oder *** gesammelt?

Nein, leider nicht. Mein Kollege überlegt auch schon ernsthaft stattdessen einen Root-Server zu mieten.

Ich persönlich halte die Leistung von netcup, sofern ohne Fehler - und das Preis-Leistungs-Verhältnis, für sehr gut. Der Support scheint mir etwas schreibfaul zu sein und bemüht sich nach meiner Erfahrung eher selten um klare Antworten und Hilfestellungen.

Würde der Support mal alle von meinem Kollegen genannten Mängel abstellen, dann würden wir uns wohl dazu entscheiden den vServer zu behalten. Zum Betreiben von CS: S-Servern eignet sich dieser nämlich sonst ganz gut.

Zu dem „Update des Kernels“ von heute ist mir noch etwas aufgefallen.

$ date && free -m
Wed Oct 24 23:09:11 CEST 2012
             total       used       free     shared    buffers     cached
Mem:          4096        288       3807          0          0         90
-/+ buffers/cache:        197       3898
Swap:            0          0          0

Zum Vergleich:

$ date && free -m
Thu Jul  5 19:03:13 CEST 2012
             total       used       free     shared    buffers     cached
Mem:          2048        611       1436          0          0        373
-/+ buffers/cache:        237       1810
Swap:         2048          0       2048

Das Ganze erinnert mich ein bisschen an einen Fehler von Ende Juni diesen Jahres.

Zitat von Impact

Er soll diesen Screenshot mal mit net_graph 4 machen.

Das ist nun nicht mehr notwendig. Es gab heute Wartungsarbeiten, womit zumindest das neuere Problem, ein fortlaufendes Ruckeln auf den CS: S-Servern, behoben werden konnte.

Zitat von netcup-Support

[...] wir müssen Wartungsarbeiten am Node Ihres vServers durchführen. Dadurch ist folgender Ihrer vServer am 24.10.2012 zwischen 16:30 und 17:00 für ca. 30 Minuten nicht zu erreichen: [...]

Mit dem Neustart werden wir ein Update des Kernels verbinden wodurch wir Ihnen einen weiteren Neustart des vServers ersparen. [...]

$ date && uname -va
Wed Oct 24 21:50:49 CEST 2012
Linux *** 3.0.46-vs2.3.2.5.2-nc #1 SMP Wed Oct 24 12:28:39 UTC 2012 x86_64 GNU/Linux

Mein Shell-Script, loghighpings.sh, habe ich eben wieder gestartet.

Zitat von Duschcreme

Ich habe bei meinem vServer Saturn seit ungefähr Mitte letzter Woche ebenfalls starke Lag Probleme.

Welche Kernel-Version ist im Einsatz?

Zitat von MMax

Meinem Kollegen ist allerdings noch aufgefallen, dass die unterste Linie im net_graph immer dann orange/rot (siehe [8a]) ausschlägt, sobald es ruckelt.

Hierzu ein Screenshot, aufgenommen von meinem Kollegen.
[Blockierte Grafik: http://s14.directupload.net/images/121022/sdbbjjfs.jpg]

Zitat von sim

Sieht für mich OK aus.
Nur der Juniper Router schlägt mit 100ms AVG ein bissl aus der Reihe.

Die erhöhte Latenz tritt wie gesagt sporadisch auf. Wie du auch in der Log-Datei auf dem Webserver erkennen kannst.

Ergänzend möchte ich noch erwähnen, dass der letzte Neustart des Nodes ausfallbedingt am 17.10.2012 zwischen ca. 13:48 und 15:16 Uhr war. Die aktuelle Kernel-Version ist die 3.5.3-vs2.3.4.2.0-nc #3 SMP Mon Aug 27 16:45:21 UTC 2012 x86_64 GNU/Linux. Zuvor war es lange Zeit der „stabile 2.6er-Kernel“. Vielleicht könnte dies ja was mit dem neuen Problem zu tun haben?

Die erhöhten Latenzen wurden zwischen dem 17.10.2012 und dem 20.10.2012 nicht aufgezeichnet, mangels Autostart-Eintrag.

Wie im Log zu erkennen ist, haben die gemessenen Latenzen in den letzten Tagen nochmals zugenommen. Eine Einschätzung wie „[...] es kann durchaus sein, das ein einzelner Host erhöhte Antwortzeiten auf ICMP anfragen hat, gerade router sind meist so konfiguriert das diese unpriorisiert auf ICMP Anfragen reagieren. [...]“, halte ich für etwas unrealistisch, da die Antwortzeit sonst bei unter 1 ms liegt und nun teilweise mit über 665 ms gemessen wird.

Seit kurzen ruckelt es nun auch noch fortlaufend auf den CS: S-Servern, wovon sich jeder bei Interesse selbst überzeugen kann. Dies allerdings auch ohne erkennbare Latenzerhöhung.

Der Support wurde bereits gestern informiert. Eine Antwort bleibt dieser weiterhin schuldig.

Wir denken daher bereits über einen Anbieterwechsel nach!

Inzwischen hat mein Kollege bereits mehrmals den Support kontaktieren müssen, da das Problem auch weiterhin besteht.

19.08.2012 - Anfrage per Supportformular
Mein Kollege machte den Support nochmals auf das Problem, mit Verweis auf diesen Thread, aufmerksam.

19.08.2012 - Antwort per E-Mail

Zitat

[...] ein einfacher Ping ist leider nicht aussagekräftig, da aus diesem nicht hervor geht an welcher Stelle die erhöhte Latenz auftritt. [...] Daher benötigen wir für solche Diagnosen aussagekräftige Routenverfolgungen die mittels des Tools MTR oder WinMTR angefertigt wurden. [...]

19.08.2012 - Anfrage per Supportformular
Mein Kollege erklärte dem Support, dass bereits aus dem Schreiben vom 22.06.2012, mit einem Traceroute zu google.de (173.194.35.184) und aus dem Thread hier, mit einem Traceroute am 05.07.2012 zu traceroute.eu (88.198.46.60), hervorgehen würde, dass die erhöhte Latenz bereits am nächstgelegene Host hinter dem vServer auftritt. Ein aktueller Traceroute vom 19.08.2012 zu netcup.de sollte zudem beweisen, dass der nächstgelegene Host auch weiterhin die IP 37.221.192.3 ist.

20.08.2012 – Antwort per E-Mail

Zitat

[...] MTR erstellt wie sie richtig erfasst haben, eine Art Traceroute und ping Kombination. Dabei wird jeder Hop des Tracerouts angepingt wodurch dies nachvollziehbarer wird.
Ein normaler Traceroute zeigt immer nur eine Momentaufnahme vom einmaligen Aufbau des Trace Pfades.

Mit dem Tool MTR ist es möglich dies über mehrere Durchgänge zu betrachten wodurch sich dann auch die Dauer der erhöhten Latenzen und ähnlichem erkennen lässt.

Die Ausgabe von MTR/WinMTR ist hier deutlich informativer als bei einem einfachen Traceroute. [...]

21.08.2012 - Anfrage per Supportformular
Mein Kollege machte den Support nochmals darauf aufmerksam, dass der Einsatz von MTR aus seiner Sicht überflüssig wäre: „[...] da bereits der nächstgelegene Host hinter dem vServer für die hohe Latenz verantwortlich ist. Da liegt also kein weiterer Host dazwischen. Ein Aufruf von Ping reicht also in diesem Fall um die hohe Latenz nachzuweisen. [...]“

22.08.2012 - Antwort per E-Mail

Zitat

[...] es kann durchaus sein, das ein einzelner Host erhöhte Antwortzeiten auf ICMP anfragen hat, gerade router sind meist so konfiguriert das diese unpriorisiert auf ICMP Anfragen reagieren.

Erst wenn Sich die erhöhte Latenz dann auch auf die folgenden Hops überträgt kann man davon ausgehen das an dem genannten Hop ein Problem vorliegt. [...]

22.08.2012 - Anfrage per Supportformular
Mein Kollege versicherte dem Support: „ [...] dass sich die erhöhte Latenz in meinem Fall auch auf nachfolgende Hops überträgt, da die unter http://88.198.182.44/ping.log erfassten Latenzen direkten Einfluss auf meine Gameserver hatten. In mehreren Fällen war ich hierzu selbst anwesend, ansonsten lässt sich dieser Zusammenhang auch an den im jeweiligen GS-Log erfassten Spielerreaktionen nachvollziehen.“

23.08.2012 - Antwort per E-Mail

Zitat

[...] wenn sie uns dies zusichern, hilft dies dennoch unserer Analyse nicht weiter. Bitte übersenden sie uns den angeforderten MTR, da dies unserer Analyse entgegen kommt. [...]

24.08.2012 - Anfrage per Supportformular
Mein Kollege erklärte dem Support, dass MTR nach der Installation genauso wie auch bei anderen Kunden auf dem vServer nicht funktionieren würde. Siehe: My Traceroute (mtr-tiny)

24.08.2012 - Antwort per E-Mail

Zitat

[...] bitte machen Sie MTRs von Ihrem Rechner aus Richtung des Vservers. Machen Sie gegebenenfalls traceroutes vom vServer auf ein beliebiges zuverlässiges Ziel.
Und stellen Sie uns diese zur Verfügung. [...]

Meiner Einschätzung nach haben wir bereits genug Anhaltspunkte geliefert und „MRTs“ vom privaten Rechner zum vServer gestalten sich etwas schwierig, wenn man dabei erst auf das Problem mit der hohen Latenz warten muss. Wäre eine derartige Überprüfung nicht vom netcup-Support selbst zu realisieren und zu erwarten? Immerhin steht die Fehlerquelle für uns bereits weitestgehend fest und wird ausschließlich vom Support angezweifelt, während eine weitere Analyse mittels 2. Rechner vorgegeben wird. Wie seht ihr das?

Aktuell besteht auch noch ein weiteres Problem, dass es auf den CS: S-Servern ständig ruckelt. Meinem Kollegen ist dieses Problem seit dem 19.10.2012 bekannt, zuvor hatte er einige Tage nicht gespielt und wurde dann von mehreren Spielern angeschrieben, dass dieses Problem schon seit 1-2 Wochen bestehen würde. Den vServer hatte er daraufhin extra neu gestartet, aber leider ohne Besserung. Ich erfuhr von dem Problem erst am nächsten Tag und habe bereits die Auslastung des vServers mit top und free überprüft, aber nichts besonderes feststellen können. Ich kann im Moment leider selbst nicht auf die CS: S-Server, da mein Grafiktreiber nicht mehr funktioniert und ich auf bereits bestellte Komponenten zum Austausch warte.

Meinem Kollegen ist allerdings noch aufgefallen, dass die unterste Linie im net_graph immer dann orange/rot (siehe [8a]) ausschlägt, sobald es ruckelt. Der Support wurde deswegen bereits gestern kontaktiert. Eine Antwort steht noch aus.

Unsere CS: S Server:
[Blockierte Grafik: http://cache.%5Burl=http://www.gametracker.com/server_info/88.198.182.44:27015/b_350_20_692108_381007_FFFFFF_000000.png%5Dhttp://www.gametracker.com/server_info/88.198.182.44:27015/b_350_20_692108_381007_FFFFFF_000000.png][img][/img][/url]
[Blockierte Grafik: http://cache.%5Burl=http://www.gametracker.com/server_info/88.198.182.44:27045/b_350_20_692108_381007_FFFFFF_000000.png%5Dhttp://www.gametracker.com/server_info/88.198.182.44:27045/b_350_20_692108_381007_FFFFFF_000000.png][img][/img][/url]

Für diesen Monat stehen in unserem High-Ping-Log bereits wieder 12 Einträge für den 7., 1 Eintrag für den 12. und 9 Einträge für den 13.

Ist denn inzwischen bekannt was diese hohen Latenzen zwischen dem vServer und dem nächstgelegenen Host verursacht oder verursachen kann?

Über Vorschläge wie sich das Problem weiter eingrenzen lassen könnte würden wir uns sehr freuen.