[chris12]

Meine ganzen rsync Backups türmen sich auch enorm, da nichts durch geht Gra -> RBX

[Paul20666]

2 Stunden Später:

wget -O /dev/null http://speedtest.netcologne.de/test_1gb.bin
--2016-03-05 14:13:26-- http://speedtest.netcologne.de/test_1gb.bin
Auflösen des Hostnamen »speedtest.netcologne.de«.... 194.8.194.20
Verbindungsaufbau zu speedtest.netcologne.de|194.8.194.20|:80... verbunden.
HTTP Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 1073741824 (1,0G) [application/octet-stream]
In »»/dev/null«« speichern.

100%[================================================== ===========>] 1.073.741.824 362K/s in 1h 44m

2016-03-05 15:58:06 (167 KB/s) - »»/dev/null«« gespeichert [1073741824/1073741824]

[gentlemon]

Ja, sind beides Game (OVH) in SBG1.

Gerade hat's den einen bei mir komplett zerlegt. Der hat aktuell einfach mal 70% Loss.


Scheint als würde es an OVH liegen.

Kurz getestet:


aus GRA (SYS):

~# wget -O /dev/null http://speedtest.netcologne.de/test_1gb.bin
--2016-03-05 15:46:07-- http://speedtest.netcologne.de/test_1gb.bin
Resolving speedtest.netcologne.de (speedtest.netcologne.de)... 194.8.194.20
Connecting to speedtest.netcologne.de (speedtest.netcologne.de)|194.8.194.20|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1073741824 (1.0G) [application/octet-stream]
Saving to: `/dev/null'

100%[================================================== ================================================== ===================>] 1,073,741,824 36.4M/s in 99s

2016-03-05 15:47:46 (10.4 MB/s) - `/dev/null' saved [1073741824/1073741824]


aus SBG1 (Game, OVH)


# wget -O /dev/null http://speedtest.netcologne.de/test_1gb.bin
--2016-03-05 15:44:55-- http://speedtest.netcologne.de/test_1gb.bin
Resolving speedtest.netcologne.de (speedtest.netcologne.de)... 194.8.194.20
Connecting to speedtest.netcologne.de (speedtest.netcologne.de)|194.8.194.20|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1073741824 (1.0G) [application/octet-stream]
Saving to: ‘/dev/null’

/dev/null 63%[================================================== ==> ] 651.43M 3.84MB/s eta 1m 47s


# wget -O /dev/null http://speedtest.netcologne.de/test_1gb.bin
--2016-03-05 15:45:18-- http://speedtest.netcologne.de/test_1gb.bin
Resolving speedtest.netcologne.de (speedtest.netcologne.de)... 194.8.194.20
Connecting to speedtest.netcologne.de (speedtest.netcologne.de)|194.8.194.20|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1073741824 (1.0G) [application/octet-stream]
Saving to: `/dev/null'

100%[================================================== ================================================== ===================>] 1,073,741,824 8.33M/s in 2m 58s

2016-03-05 15:48:16 (5.76 MB/s) - `/dev/null' saved [1073741824/1073741824]



Aus FFM:


# wget -O /dev/null http://speedtest.netcologne.de/test_1gb.bin
--2016-03-05 15:45:27-- http://speedtest.netcologne.de/test_1gb.bin
Resolving speedtest.netcologne.de (speedtest.netcologne.de)... 194.8.194.20
Connecting to speedtest.netcologne.de (speedtest.netcologne.de)|194.8.194.20|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1073741824 (1.0G) [application/octet-stream]
Saving to: `/dev/null'

100%[================================================== ================================================== ===================>] 1,073,741,824 46.6M/s in 28s

2016-03-05 15:45:55 (37.1 MB/s) - `/dev/null' saved [1073741824/1073741824]

[Paul20666]

Hallo,

ist dein Server auch im SBG 1? Ist es ein OVH (Game) ?

Hier mal 2 SBG1 im Vergleich mit einem SYS RBX:

http://i.imgur.com/xa7mBV6.png

Paul

[gentlemon]

Aktuell bin ich mir da nicht so sicher ob das an OVH liegt:

getesteter Server ist gerade in Verwendung:


# ./speedtest-cli --server 6601
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from OVH SAS (xxx.xxx.xxx.xxx)...
Hosted by NetCologne (Cologne) [402.37 km]: 40.324 ms
Testing download speed........................................
Download: 627.20 Mbit/s
Testing upload speed............................................. .....
Upload: 161.30 Mbit/s
# ./speedtest-cli --server 6670
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from OVH SAS (xxx.xxx.xxx.xxx)...
Hosted by hotspot.koeln (Cologne) [402.37 km]: 15.378 ms
Testing download speed........................................
Download: 595.51 Mbit/s
Testing upload speed............................................. .....
Upload: 170.31 Mbit/s



# iperf -c ip.in.frank.furt -i 1 -r
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to ip.in.frank.furt, TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 5] local ip.in.sb.g port 55395 connected with ip.in.frank.furtport 5001
[ ID] Interval Transfer Bandwidth
[ 5] 0.0- 1.0 sec 64.0 MBytes 537 Mbits/sec
[ 5] 1.0- 2.0 sec 47.4 MBytes 397 Mbits/sec
[ 5] 2.0- 3.0 sec 45.0 MBytes 377 Mbits/sec
[ 5] 3.0- 4.0 sec 36.6 MBytes 307 Mbits/sec
[ 5] 4.0- 5.0 sec 46.0 MBytes 386 Mbits/sec
[ 5] 5.0- 6.0 sec 49.2 MBytes 413 Mbits/sec
[ 5] 6.0- 7.0 sec 46.1 MBytes 387 Mbits/sec
[ 5] 7.0- 8.0 sec 52.1 MBytes 437 Mbits/sec
[ 5] 8.0- 9.0 sec 20.2 MBytes 170 Mbits/sec
[ 5] 9.0-10.0 sec 31.8 MBytes 266 Mbits/sec
[ 5] 0.0-10.0 sec 439 MBytes 368 Mbits/sec
[ 4] local ip.in.sb.g port 5001 connected with ip.in.frank.furt port 3980
[ 4] 0.0- 1.0 sec 86.2 MBytes 723 Mbits/sec
[ 4] 1.0- 2.0 sec 93.4 MBytes 784 Mbits/sec
[ 4] 2.0- 3.0 sec 90.8 MBytes 762 Mbits/sec
[ 4] 3.0- 4.0 sec 73.9 MBytes 620 Mbits/sec
[ 4] 4.0- 5.0 sec 84.9 MBytes 712 Mbits/sec
[ 4] 5.0- 6.0 sec 88.6 MBytes 744 Mbits/sec
[ 4] 6.0- 7.0 sec 84.9 MBytes 712 Mbits/sec
[ 4] 7.0- 8.0 sec 89.5 MBytes 751 Mbits/sec
[ 4] 8.0- 9.0 sec 79.3 MBytes 665 Mbits/sec
[ 4] 9.0-10.0 sec 83.1 MBytes 697 Mbits/sec
[ 4] 0.0-10.0 sec 857 MBytes 717 Mbits/sec

[Paul20666]

Reopen....

Wieder das selbe Problem im SBG1/2! Alle Verbindungen richtung extern sind tot! (OVH Game Reihe SBG)

http://i.imgur.com/OG9ie8D.png


Nie wieder Server im SBG! Mal gespannt wie lange es wieder dauert.. Route jetzt einige Leute über SYS Server...

Wer soll mit einem so instabilen SBG Netz arbeiten können ?

Bei euch wieder das selbe ?

Mit freundlichen Grüßen

Paul

[Felix]

Auf http://status.ovh.com/ werden die Meldungen von travaux.ovh.net (mit etwas Verzögerung durch die Übersetzung) auf Englisch bereitgehalten.

[J-B]

Ich tue mich wirklich schwer, wenn ich sehe das solche Informationen nicht in Englisch gehalten werden.

Früher wurden solche Infos noch im Forum aufs deutsche übersetzt.

[gentlemon]

Scheint als hätte sich ENDLICH was getan: http://travaux.ovh.net/?do=details&id=16333

Kann aber wirklich nicht angehen, dass das länger als 1 Monat dauert, nach dem ersten Auftreten.

[gentlemon]

Ich habe mir gestern mal wieder die Mühe gemacht, nachdem über 3 Wochen lang über den Support / Störungshotline absolut nichts lief / läuft außer die Standard Antwort "Wir warten auf die Antwort der Techniker", direkt Oles anzuschreiben und den mal zu fragen, wann sich endlich was in SBG ändert.

Nachdem ich ihm erklärt habe, was genau los ist, habe ich relativ flott (3 Stunden später) eine Antwort bekommen, dass er den Loss bestätigen kann und sich morgen (heute) mit dem Team darum kümmern wird:

http://puu.sh/mIJSy/b4c90f42f2.png

http://puu.sh/mIJTz/3d414ba6bd.png

Mehr Infos hab ich leider aktuell auch nicht und ein offizielles / öffentliches Statement ist das leider auch nicht. Warte ich auch schon seit 3 Wochen vergeblich drauf.

Was ich schwer enttäuschend finde, ist, dass ich mich 3 Wochen lang täglich mit dem Support rumschlage, die mir jedes Mal sagen man tausche jetzt erstmal die Kabel, man wartet auf die Antwort eines Technikers oder sonstigen Unsinn, aber sich letzten Endes absolut nichts tut. Dabei hatte es sich schon sehr früh abgezeichnet (mit unter mit Beginn dieses Threads), dass ich nicht der einzige sein kann, der diese Probleme hat und dass es sich hierbei um ein größeres Problem handeln muss, das wird aber anscheinend auf Seite des französischen Support gänzlich ignoriert.

Diagnose bei einem MTR mit internem Loss zwischen 3 Maschinen die alle im selben Rack stehen und jeweils nur über einen Hop gehen, sollte nicht zu schwer sein.

Bin mittlerweile mehr als 2 Jahre bei OVH und soweit eigentlich zufrieden gewesen, aber jetzt an dem Punkt angekommen, wo auch mir die Hutschnur reißt. Probleme können immer auftreten, habe da auch wirklich Verständnis für und versuche soweit es in meiner Macht steht die Ursache durch MTRs, Tests und dergleichen zu finden, aber mehr als 3 Wochen so etwas durch machen zu müssen ist nicht zumutbar.


3 Server sind bereits ausgelaufen / nicht verlängert worden und mit den restlichen 15 Servern werde ich es aller Wahrscheinlichkeit nach auch so handhaben. Sowas mache ich nicht erneut durch, ist leider nicht das erste Mal.

[NoTeefy]

Guten Abend

Langsam reicht es mir hier auch. Bei der Betrachtung der Weathermap in SBG wird einem ja speiübel. Ständig verschlechtert sich der Ping meiner Dedicated Maschinen von Woche zu Woche. Alle stehen in SBG und sind in den letzten 3 Wochen nicht attackiert worden. Der Durchschnittsping war bei ca. 500 verschiedenen Verbindungsstellen um die 30-40ms. Mittlerweile reden wir da von 120ms und es verschlechtert sich jede Woche. Was ist da los? Man kümmert sich um seine Kunden und deren Server aber nicht um das eigentliche Netzwerk. Das ist echt nicht annehmbar. Ich denke mir immer, was ich für ein Glück habe, dass auf diesen Servern keine produktive Systeme laufen.
Gibt es da irgendwann ein offizielles Statement oder muss man sich wieder wochenlang mit dem (ich sage mal "speziellen") Support auseinandersetzen? Für sowas habe ich echt keine Nerven mehr. Mir wird auch jedes Mal ein Standardszenario als Antwort zurückgesendet (Kabel kaputt, Switchprobleme, Netzkartenfehler etc.). Es kann doch nicht sein, dass jede Woche die Kabel kaputt gehen....


Freundliche Grüsse
Ein treuer Kunde

[Paul20666]

Hallo,

manchmal habe ich das Gefühl, als ob die Netzwerk-Abteilung Samstag und Sontag nicht in ihr eigenes Monitoring guckt..

-->Für alle die es noch nicht wissen: Ab ca. ~80% gibt es PPS lost...!!

http://i.imgur.com/Yc6IJ3m.png
http://i.imgur.com/IHIVWTf.png

Da nun auch das RBX probleme macht, gibt es ja noch das GRA...

Ich habe mal wieder den SBG Cheff auf Twitter ne PM geschrieben. Mal gespannt wann es besser wird.

Leider ist meine Geduld so langsam am Ende...

[J-B]

# wget -O /dev/null http://speedtest.tele2.net/1GB.zip
--2016-01-23 11:04:44-- http://speedtest.tele2.net/1GB.zip
Auflösen des Hostnamen »speedtest.tele2.net (speedtest.tele2.net)«... 90.130.70.73, 2a00:800:1010::1
Verbindungsaufbau zu speedtest.tele2.net (speedtest.tele2.net)|90.130.70.73|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 1073741824 (1,0G) [application/zip]
In »»/dev/null«« speichern.

/dev/null 100%[================================================== ==========================>] 1,00G 112MB/s in 9,4s

2016-01-23 11:04:54 (109 MB/s) - »»/dev/null«« gespeichert [1073741824/1073741824]

Rechenzentrum
SBG 1

Läuft ...

[gentlemon]

Wie schaut's bei euch aus ?

Scheiße.. wie gehabt.

FFM <-> SBG konstant 2-3% Loss.

Vom internen Loss ganz zu schweigen. Aber das ist ja mittlerweile Standard. Problem besteht laut internem (SBG<->SBG) Smokeping auch schon gute 4 Wochen (Anfang KW 52 - 2015, ab ca. 21.12.2015)

http://puu.sh/mFSo7/0ba5be3147.png

erkennt man auch ganz gut von extern:

http://puu.sh/mFSAw/3c43984d23.png

[maxs97]

Same here

Liegt einfach daran das nur der Link FRA-SBG um 2 weitere 100G Strippen erweitert wurde, aber nicht das rechenzentrumsinterne Netz.
Ich hab vor einigen Tagen Oles via Twitter angeschrieben, seine Aussage dazu war das nächste (evtl. schon diese) Woche der Ausbau beginnt, evtl. kommt da also noch was.

Gruß

[Paul20666]

Hallo,

leider ist das Problem nach dem Upgrade nicht behoben... Alle neuen Server kommen ins RBX...

Wie schaut's bei euch aus ?

http://i.imgur.com/QKZDGVL.png

[Lisa]

Hallo,

das stand noch auf meiner ToDo, auch hier im Forum Bescheid zu geben

Danke Paul, fürs mitdenken

Gruß,
Lisa

[Paul20666]

Hallo,

ein Upgrade steht jetzt als Task im Tracker! Danke hier an Lisa für den super Einsatz

http://travaux.ovh.net/?do=details&id=16275

[TheReakKaysu]

Das merkt man wirklich extrem. Aber was auch mega cool ist, 4 Server, gleiches Rack, alle zu einander 3-5% Loss.

Und wenn ich das hier sehe, wird mir schlecht:

http://puu.sh/mzmcx/0940ed075c.png
http://puu.sh/mzlXl/fb1c22ac5e.png

Aber Problem wird sich bestimmt irgendwann von alleine lösen, wenn dann die Kunden weg sind.

Da hat sich die OVH Führung wohl ein bisschen beim aufkommendem Volumen verschätzt. Bin gespannt wie schnell OVH auf das Problem reagiert.

Immerhin ist GRA jetzt am Wochenende wieder grün, das war bis vor 2-3 Wochen auch jeden Abend teilweise rot. Das jetzt RBX und SBG aber mittlerweile so ausgelastet sind kann nicht lange haltbar sein.

[gentlemon]

Das merkt man wirklich extrem. Aber was auch mega cool ist, 4 Server, gleiches Rack, alle zu einander 3-5% Loss.

Und wenn ich das hier sehe, wird mir schlecht:

http://puu.sh/mzmcx/0940ed075c.png
http://puu.sh/mzlXl/fb1c22ac5e.png

Aber Problem wird sich bestimmt irgendwann von alleine lösen, wenn dann die Kunden weg sind.

[denis]

Unabhängig vom GAME DDoS Schutz, im Moment ist sehr viel rot auf der weathermap, und das merkt man teilweise schon deutlich.

[gentlemon]

Naja, bei mir lässt das immer noch auf allen Server schwer zu wünschen übrig:

Server sind teilweise nicht mal in Verwendung.

http://puu.sh/mz731/aea5b5cdc3.png

http://puu.sh/mz75r/521caa3a13.png

http://puu.sh/mz78l/5361dd5650.png

[Paul20666]

Hallo,

zumindest das total überlastete Level 3 Peering (fra-5-n7) wurde geupgradet. Seitdem gibt es schon mal deutlich weniger Probleme!

Danke an den SBG RZ Admin


Paul

[TheReakKaysu]

Ich hätte gerne noch den i7 6700k im Angebot. DAS wäre ein Traum - aber nur ohne den Game DDoS Schutz

Sonst war das Angebot eigentlich OK aber wahrscheinlich ist die Zielgruppe für die größeren Gameserver einfach zu klein - erst Recht wenn die Höhe des Packetloss davon abhängt wie viele Verbindungen auf einem Server sind. In Zukunft werde auch ich deshalb definitiv auf andere Serverreihen umstellen.

[gentlemon]

Meinen Erfahrungen nach, macht es keinen Sinn, mehr als 4GB Ram / CPU Thread zu haben.
Auch die 480er SSDs sind nicht zwingend notwendig, Grundausstattung mit 2x240GB würde vollkommen reichen.

Für alle die mehr Ram / SSD brauchen, wäre eine Upgrade Möglichkeit gut.

[Lisa]

Hallo,

@TheReakKaysu vielen Dank erstmal

Es ist nicht möglich den Schutz zu deaktivieren, da dadurch unsere Infrastruktur in Mitleidenschaft gezogen werden könnte. Das ist also eine Sicherheitsmaßnahme.

Nach der Prüfung beim Netzwerkteam weiß ich mehr. Ich denke aber eher nicht, dass es hierbei mit der Firewall zusammenhängt. Aber das wissen wir erst, wenn ich eine Rückmeldung erhalten habe. Wie versprochen sage ich natürlich direkt Bescheid, sobald ich etwas Neues habe.

Hättet Ihr denn Vorschläge, welche Hardwarekonstellation bei den Gameservern für euch passend wäre? Dann gebe ich das gerne mal nach oben weiter.

lg,
Lisa : ))

[J-B]

Es liegt ja auch ganz klar am Preis. MC-32 mit ~84 Euro noch zu finanzieren. Der nächste mit 215 Euro monatlich, dürfte wohl für jedem Gamer zu teuer sein.

[gentlemon]

Läuft jetzt so wie immer ab (bin mittlerweile mehr als 2 jahre bei OVH). Läuft einige Monate gut (max 2-3) und dann fängt's wieder an. Man muss sich wieder wochenlang mit dem inkompetenten franz. Supporter rumschlagen. Egal wie gut man denen Infos liefert (MTR, Smokeping, Rote weathermap...) Die erzählen einem dann wieder es würde an [Hier zufällige Diagnose einfügen] liegen (Netzwerkkabel, Netzwerkkarte, ...), tauschen dann das ganze Zeug aus, Problem ist allerdings bei mehreren Servern immer noch das gleiche und dann braucht's etliche Tage/Wochen bis man bei allen Instanzen angeklopft hat (mehrfach deutscher Support, Support Leitung, Oles über Twitter etc.) bis sich mal was tut.

Einschlägige Beispiele die ich da bisher mitgemacht habe: Ausbau SBG -> GRA, SBG Anbindung an FRA Erweiterung, Mitigation mit der neuen Enterprise Reihe und jetzt das hier wieder. Gab noch einige Sachen zwischendurch, bin ich aber zu faul das jetzt alles zu schreiben.

Ganz abgesehen von den hohen Pingsspitzen immer wieder, die die immer noch nicht im Griff haben (und wohl auch nie in den Griff bekommen werden), weil die Infrastruktur nicht dafür ausgelegt ist. Kommt von der Umleitung beim VAC wenn zuviel los ist. Wenn SBG viel zu tun hat, dann wird das durch ein anderes VAC gejagt und naja, ob das Paket von SBG nach RBX und dann wieder nach SBG geht oder direkt durchs VAC in SBG merkt man dann doch. Das ist bezüglich der Gameserver Reihe natürlich absolut untragbar.

Alles eher suboptimal für die Gameserverreihe, denke auch, dass der MC-32 besonder häufig gekauft wird, weil da die Preis Leistung stimmt. Egal ob man den nun für Gameserver verwenden will oder nicht. Die CPU ist halt doch sehr gut.

[TheReakKaysu]

Das mag ein Problem sein (Game DDoS Schutz), das andere, warum die anderen Server so schlecht verkauft werden ist einfach, weil das Verhältnis von CPU zu Ram nicht stimmt. Bringt einem in der Gamereihe (32er ausgenommen) überhaupt nichts, wenn man Unmengen an Ram hat, die aber nicht befeuern kann, weil man nur eine CPU hat die bei einem ordentlichen Verhältnis eher 48-64GB Ram gut brauchen könnte statt 128GB. Ist zumindest bei Minecraft so.

Und statt hier mal den Kunden zu fragen, wird halt einfach entschieden und sich dann gewundert warums nicht läuft. Ist aber schon seit Jahren so bei OVH.

Das dürfte in der Tat auch dazu beitragen.

Aber ich kenne eben auch Organisationen die hier eine mittlere zweistellige Zahl an "großen" Game Servern gemietet haben nur um die nach einem Monat wieder abzustoßen weil der Packetloss für die nicht tragbar ist. Mal schauen ob sich das jetzt wieder bessert in den nächsten Wochen.

[gentlemon]

Das die Game Reihe deshalb extrem schlecht davon kommt dürfte niemanden verwundern: https://twitter.com/olesovhcom/statu...66254707859456

Das mag ein Problem sein (Game DDoS Schutz), das andere, warum die anderen Server so schlecht verkauft werden ist einfach, weil das Verhältnis von CPU zu Ram nicht stimmt. Bringt einem in der Gamereihe (32er ausgenommen) überhaupt nichts, wenn man Unmengen an Ram hat, die aber nicht befeuern kann, weil man nur eine CPU hat die bei einem ordentlichen Verhältnis eher 48-64GB Ram gut brauchen könnte statt 128GB. Ist zumindest bei Minecraft so.

Und statt hier mal den Kunden zu fragen, wird halt einfach entschieden und sich dann gewundert warums nicht läuft. Ist aber schon seit Jahren so bei OVH.

[TheReakKaysu]

An dieser Stelle noch einmal ein großes Dankeschön an Lisa auf die hier wirklich noch verlass ist

Leider nur ein Tropfen auf den heißen Stein. Ich bin wirklich für den Preis bei OVH zufrieden aber das halt ein immer wiederkehrendes Problem welches zu 100% an der Game DDoS Firewall liegt immer wieder neu vom Netzwerkteam aufgerollt werden muss ist echt ätzend. Schön wäre es wenn man auch einfach diesen schlechten Game DDoS Schutz deaktivieren könnte (leider permanent aktiviert auch wenn man im Webinterface die Regeln deaktivieren kann).

Das die Game Reihe deshalb extrem schlecht davon kommt dürfte niemanden verwundern: https://twitter.com/olesovhcom/statu...66254707859456

[gentlemon]

Wenn du jetzt kein DNS Server betreibst, wieso blockst du kein UDP auf der Firewall?

Habe ich natürlich auch dran gedacht, aber war in dem Fall Teamspeak.

[Lisa]

Hallo,

ich melde mich nochmal kurz hier bei euch.

Ich stehe nun mit einem Kollegen des Netzwerkteams in Kontakt (an der VAC Firewall sollte dies nicht liegen) und habe bereits alle Testergebnisse zur Prüfung weitergeleitet.

Danke für euere Unterstützung.

Ich sage nochmal Bescheid, sobald ich mehr weiß.

Gruß,
Lisa : ))

[J-B]

... (UDP, ziemlcih einfache Angriffe, immer gleiche Pakete, gleicher Port...), .

Wenn du jetzt kein DNS Server betreibst, wieso blockst du kein UDP auf der Firewall?

[gentlemon]

Ja das beste an der Geschichte ist, die Enterprise wurden mir immer weggeschossen (UDP, ziemlcih einfache Angriffe, immer gleiche Pakete, gleicher Port...), da wurde mir dann gesagt "ja können wir nichts machen, wechseln Sie auf die Gameserverreihe" - hab ich gemacht, lief auch eine zeitlang wirklich gut. Mitte November hat es aber dann angefangen mit dem Loss.

Interner und externer Loss sind aber bei der Gameserverreihe nicht tragbar. Und das sind bei mir in der Peak auch mal gut und gerne 15% (wenn auch nur über kurze Zeiträume). Nur kannste dir vorstellen, was bei 15% noch so in Richtung lagfreies spielen geht .

[TheReakKaysu]

Ich hab auch 4 von denen am laufen. Wenn Peak ist, sind die nicht mehr zu gebrauchen. Absolut nicht mehr. Auch intern nicht.

Seit etlichen Tagen kämpf ich mich mit dem franz. Support ab, der mir immer wieder was anderes erzählt. Mal das Netzwerkkabel fehlerhaft (bei 4 Servern gleichzeitig? - ich weiß ja nicht), mal die Netzwerkkarte, mal die Mitigation, Haben mir schon 2 mal geschrieben, dass das Problem jetzt behoben sein. Was aber schlichtweg nicht stimmt. 4 Server alle die gleichen Probleme. Bei der Enterprise Reihe läuft allerdings alles einwandfrei.

Bist also nicht alleine mit dem Problem.

Hatte Mitte September/November ähnliche Probleme mit den Game Servern. Sobald mehr Traffic auf die Dingern kommt gibt es Packetloss.
Wurde dann irgendwann durch eine Infrastruktur Upgrade behoben aber jetzt gibt es genau die gleichen Problemen wieder. Bin es jetzt aber mittlerweile auch leid immer wieder Tests zu machen, solange der Packetloss noch so niedrig ist wie momentan (~1-3%) ist es mir erstmal egal.
Einfach sofern möglich die Enterprise Server nehmen die den Game DDoS Schutz zum Glück nicht haben.

[Lisa]

@gentlemon

Könntest du mir dazu ein Ticket erstellen und mir die entsprechende Ticketnummer mitteilen?

Oder mir nur die Ticketnummer durchgeben, von dem aktuell bereits offenen Ticket?

Vielen Dank

glg,
Lisa

[Lisa]

Hallo Paul, hallo gentlemon,

ich stehe diesbezüglich bereits mit unserem Firewall-Team in Kontakt.

Ich halte euch diesbezüglich auf dem Laufenden.

Gruß,
Lisa

[gentlemon]

Ich hab auch 4 von denen am laufen. Wenn Peak ist, sind die nicht mehr zu gebrauchen. Absolut nicht mehr. Auch intern nicht.

Seit etlichen Tagen kämpf ich mich mit dem franz. Support ab, der mir immer wieder was anderes erzählt. Mal das Netzwerkkabel fehlerhaft (bei 4 Servern gleichzeitig? - ich weiß ja nicht), mal die Netzwerkkarte, mal die Mitigation, Haben mir schon 2 mal geschrieben, dass das Problem jetzt behoben sein. Was aber schlichtweg nicht stimmt. 4 Server alle die gleichen Probleme. Bei der Enterprise Reihe läuft allerdings alles einwandfrei.

Habe langsam die Vermutung, dass die Ihre Systeme da einfach überlasten.

Und weils so schön ist, das anzusehen, hier noch die Smokepings:

(alle Game Server in SBG)

von SBG nach SBG:

http://puu.sh/mqGFm/d8018ea347.png


von RBX nach SBG:
http://puu.sh/mqGQ6/7d317149da.png

und FRA nach SBG:
http://puu.sh/mqGLn/ef43811edf.png


Schlimme an der Sache sind die dreisten und unfähigen Antworten, die mir im Support Ticket gegeben werden:

Dear Customer,

You have a loss rate of 1 ICMP packet out of 20.

It's very normal and that should not cause any network problem.

Staying at your disposal.

Best Regards,
XXXXX

Bist also nicht alleine mit dem Problem.

[Paul20666]

Hallo,

ich habe 5 Dedis aus der MC-32 Reihe. Hierbei bemerke ich bei einigen, dass wenn die Anzahl der TCP Verbindungen über 1200 geht, die Geschwindigkeit dieser langsam wird und ab ca. 2,5 K viele abbrechen. Auf allen anderen Server läut es besser.

Desweiteren ist aufgefallen, dass die "garantierte" interne Gbit Verbindung sehr selten existent ist.

http://prntscr.com/9ocvou (OVH Speedtest)
http://prntscr.com/9occ2p (Upload)

Bei 1700:

[ 3] local 151.80.110.* port 46910 connected with 62.210.156.* port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 1.0 sec 4.05 MBytes 34.0 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 1.0- 2.0 sec 3.91 MBytes 32.8 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 2.0- 3.0 sec 3.45 MBytes 29.0 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 3.0- 4.0 sec 632 KBytes 5.18 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 4.0- 5.0 sec 880 KBytes 7.21 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 5.0- 6.0 sec 816 KBytes 6.68 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 6.0- 7.0 sec 744 KBytes 6.09 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 7.0- 8.0 sec 824 KBytes 6.75 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 8.0- 9.0 sec 296 KBytes 2.42 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 9.0-10.0 sec 112 KBytes 918 Kbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 10.0-11.0 sec 696 KBytes 5.70 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 11.0-12.0 sec 648 KBytes 5.31 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 12.0-13.0 sec 928 KBytes 7.60 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 13.0-14.0 sec 864 KBytes 7.08 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 14.0-15.0 sec 984 KBytes 8.06 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 15.0-16.0 sec 832 KBytes 6.82 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 16.0-17.0 sec 608 KBytes 4.98 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 17.0-18.0 sec 624 KBytes 5.11 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 18.0-19.0 sec 576 KBytes 4.72 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 19.0-20.0 sec 904 KBytes 7.41 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 20.0-21.0 sec 1.24 MBytes 10.4 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 21.0-22.0 sec 240 KBytes 1.97 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 22.0-23.0 sec 808 KBytes 6.62 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 23.0-24.0 sec 2.84 MBytes 23.9 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 24.0-25.0 sec 2.25 MBytes 18.9 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 25.0-26.0 sec 2.21 MBytes 18.5 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 26.0-27.0 sec 744 KBytes 6.09 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 27.0-28.0 sec 472 KBytes 3.87 Mbits/sec


Der full Gbit Port ist bei allen Problemservern dabei.

http://prntscr.com/9ocxj6

Der Ping über so eine Verbindung schwankt dann extrem und ist zwichen 80 und 900 MS!

Was alles geacht wurde:

-Mainboard+Netzwerkkarte getauscht
-Switch Ports geändert
-Verbindungen zwichen den Switches durchgemessen
-Im rescue mode mit Website Stresstesting im internen Netz getestet

Leider gehen uns die Ideen aus...

Wenn also einer eine Idee haben sollte würden wir uns da sehr drüber freuen.

Ihr könnt es auch selbst testen, ob ihr selbst davon betroffen seit:

(Benötigt wird ein Webserver)

apt-get install apache2-utils

ab -n 20000 -c 5 http://Ziel-IP/index.php

Am besten von einem 2. Server und im Internen OVH netz da von der Abor schnell zu viel SYN/Sekunde geblockt werden.

Mit freundlichen Grüßen

Paul