[maxs97]

Korrigert mich wenn ich falsch liege, aber alle externen Links laufen doch über mindestens einen POP, und die sind schon lange auf 100G aufgerüstet? Insofern würde das keinen Sinn machen.

[gentlemon]

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

Verstehe ich das richtig das die rechenzentrumsinternen Links auf 100G geupgradet werden sollen? Das wäre ja wunderbar

Soweit mich mein Schulfranzösisch da durchblicken lässt, gilt das nur für Verbindungen zwischen manchen Rechenzentren (außen Anbindung)

Ich habe auch intern extremen Loss. Mal schauen - soll wohl einiges in der Woche passieren.

[maxs97]

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

Verstehe ich das richtig das die rechenzentrumsinternen Links auf 100G geupgradet werden sollen? Das wäre ja wunderbar

[maxs97]

Auslaufen lassen würde ich den auch gern, jedoch ist das in meinem Fall ein mSP mit SSDs in SBG.
Das Ding hüte ich wie meinen Augapfel

[gentlemon]

Habe aktuell nur noch welche in SBG1 / SBG2, da ich die die ich ablaufen lassen konnte ablaufen lassen habe. War nicht tragbar für mich.

Aktuell stehen die in

SBG1 - Rack: 74B09
SBG1 - Rack: 74A10
SBG1 - Rack: 74A11
SBG1 - Rack: 74B13
SBG2 - Rack: 71B04
SBG1 - Rack: 74A07

Mehr kann ich leider nicht mehr nachsehen. Sind alle ausnahmslos davon betroffen.



Ab Dezember fängts an:

http://puu.sh/mZphi/80edd0921b.png

http://puu.sh/mZpin/76860a2e96.png

[schenkewitz]

Wir hatten gestern Mittag und heute ebenfalls wieder Mittags mit allen verbliebenen Servern bei OVH in SBG 4 extreme Probleme zu den zPool HA-NAS Storages. Wir haben dort ebenfalls 30 bis 50% Packet Loss, sodass ein Betrieb von VMs von diesen Data Stores nicht mehr möglich ist.

Bei uns ist es das Rack 90C13, in dem wir gleich mehrere Server haben. Andere Server in den Racks 73A07 & 73A08 in SBG 1 hatten weniger Probleme mit dem Erreichen der HA-NAS Storages.

Nach bzw. von extern waren die Server alle durchgehend und ohne Probleme erreichbar. Wir haben sie allerdings auch alle in einem vRack laufen, weshalb das Routing der IP-Blöcke ja ein wenig anders ist.

Alle 94 betroffenen VMs laufen bei uns jetzt per Veeam Instant Recovery auf den Backup-Hosts in RBX bis OVH das Problem beseitigt hat.

EDIT:

Ich hab das Problem seit 5 Wochen.

In welchen Racks sind deine Server beheimatet?

[gentlemon]

Ich hab das Problem seit 5 Wochen.

Hier mal ein aktueller Smokeping:


Intern: (SBG <-> SG)
http://puu.sh/mZnrB/de30180eac.png


Gleiches Bild zeichnet sich auf fast allen Servern in SBG ab:

Von Frankfurt aus:

http://puu.sh/mZnzb/8806b63a35.png
http://puu.sh/mZnDs/ee20d8c44f.png

könnte hier jetzt alles mit lossy Smokepings zupacken....


Ist seit Anfang / MItte Dezember so. Bisher gab's 3 Versuche seitens OVH SBG in den Griff zu bekommen (Upgrade nach FFM, 2x Upgrade innerhlab von SBG), bringt nur leider absolut nichts.


Macht dabei absolut keinen Unterschied ob da die Mitigation an ist oder nicht. Gleiche gilt für die Firewall. In aller Deutlichkeit: Das ist seit Wochen einfach nur hart am Abscheißen.

[Dragon]

Na da bin ich ja mal gespannt, ob das was wird. Viel Erfolg.

[maxs97]

Hey Dragon,

jap das ist eine OVH Kiste.
Der Schutz selbst (Tilera) ist nicht permanent aktiv, nur das Firewall-Netzwerk.

Ich habe das nun getestet und es scheint tatsächlich so als sei die Firewall überlastet.

Für mich ist das aber keine Lösung, da ich die Firewall als zusätzliche Maßnahme nutze um das gröbste rauszufiltern.
Ich kann es auch ehrlich gesagt nicht verstehen wieso OVH diese dann nicht einfach aufrüstet. Das Problem besteht ja nicht erst seit gestern und ist ziemlich konstant.

Ich leite das mal als Störungsticket weiter, Ticket-ID 2016020719026688.

Gruß

Maximilian

[Dragon]

Ohne jetzt einen Server in SBG zu haben und dazu gross was sagen zu koennen, aber dir ist bewusst, dass der DDoS-Schutz bei deinem Server aktiv ist?
Davon ausgehend, dass das eine OVH Kiste ist und der Schutz permanent aktiv geschaltet sein soll, hast du es mal ohne probiert?

[maxs97]

Hallo,

ich eröffne diesen Thread einfach mal um herauszufinden ob es einigen von euch ähnlich ergeht.

Ich betreibe nun seit einigen Monaten unter anderem einen Server in SBG4, Rack 90A10.
Bis vor ca. 2 Monaten war dieser auch immer ohne Probleme zu erreichen, jetzt hat dieser regelmäßig 20-30 % Paketverlust. Das betrifft nicht nur die Abendstunden, sondern ist auch jetzt (14:30 Uhr) so.

Nun hat sich die Netzwerkauslastung ja wie schon oft bemerkt in den letzten Monaten erhöht, deswegen wurden vor kurzem zwischen FRA-SBG und FRA-RBX jeweils zwei neue 100G Links gelegt.
Leider schient das Netzwerk im Rechenzentrum jedoch noch immer überlastet, auf die Frage von den dieses geupgradet werde antwortet Oles nur mit "soon".

Hat jemand von euch ähnliche Probleme in SBG? Vor allem versuche ich herauszufinden ob eventuell nur der TOR-Switch überlastet ist oder das Problem auch andere Racks betrifft.

Jetzt folgen noch zwei Traceroutes, einmal von meinem privaten Anschluss und einmal aus dem First-Colo in Frankfurt:

Privater Anschluss:
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| xxx.xxx.xxx.xxx- 0 | 103 | 103 | 20 | 21 | 25 | 22 |
| 217.0.117.167 - 0 | 103 | 103 | 20 | 21 | 24 | 23 |
| 87.186.196.146 - 0 | 103 | 103 | 21 | 24 | 42 | 25 |
| 217.239.45.50 - 0 | 103 | 103 | 21 | 26 | 32 | 29 |
| fra-5-a9.de.eu - 0 | 103 | 103 | 21 | 22 | 26 | 24 |
| sbg-g2-a9.fr.eu - 0 | 103 | 103 | 24 | 25 | 29 | 25 |
| vac2-0-a9.fr.eu - 0 | 103 | 103 | 24 | 25 | 30 | 27 |
| vac2-1-n7.fr.eu.firewall - 0 | 103 | 103 | 24 | 25 | 29 | 27 |
| vac2-2-n7.fr.eu - 0 | 103 | 103 | 24 | 25 | 30 | 28 |
| vac2-3-n7.fr.eu - 0 | 103 | 103 | 24 | 25 | 28 | 26 |
| No response from host - 100 | 20 | 0 | 0 | 0 | 0 | 0 |
| frontend-1.dspsrv.ovh - 23 | 53 | 41 | 23 | 28 | 35 | 25 |
|________________________________________________| ______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

Server in Frankfurt:

frontend-1.msesterhenn.de (0.0.0.0) Sun Feb 7 14:27:13 2016
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 79.133.35.65 0.0% 101 1.9 7.8 0.8 54.2 8.8
2. cr02.fra1.de.first-colo.net 0.0% 101 0.5 1.2 0.4 20.9 2.9
3. ???
4. sbg-g2-a9.fr.eu 0.0% 101 4.3 4.3 3.9 7.3 0.5
5. vac2-0-a9.fr.eu 0.0% 101 4.4 8.8 4.1 271.3 31.4
6. vac2-1-n7.fr.eu.firewall 0.0% 100 4.0 4.1 3.8 5.6 0.0
7. vac2-2-n7.fr.eu 0.0% 100 3.9 4.1 3.8 6.7 0.2
8. vac2-3-n7.fr.eu 0.0% 100 3.9 4.1 3.9 4.9 0.0
9. ???
10. frontend-1.dspsrv.ovh 31.0% 100 14.4 6.9 3.7 14.8 3.1

Grüße

Maximilian