La Fibre
Télécom => Peering Transit (appairage) => Peering entre opérateurs => Discussion démarrée par: corrector le 29 août 2013 à 21:16:38
-
Je n'arrive pas à joindre 91.121.109.1 dans :
inetnum: 91.121.64.0 - 91.121.127.255
netname: OVH
descr: OVH SAS
descr: Dedicated Servers
Voilà ce que j'ai :
9 21 ms 20 ms 48 ms th2-6k-2-1-po1.intf.nra.proxad.net [78.254.255.1]
10 20 ms 21 ms 21 ms th2-crs16-1-be1000.intf.routers.proxad.net [212.27.57.202]
11 * * * Délai d'attente de la demande dépassé.
12 * * * Délai d'attente de la demande dépassé.
TraceRoute from Network-Tools.com to 91.121.109.1 :
1 29 0 0 8.9.232.73 xe-5-3-0.edge3.dallas1.level3.net
2 Timed out 0 1 4.69.145.14 ae-1-60.edge5.dallas3.level3.net
3 Timed out Timed out 0 178.32.135.25 dal-1-6k.tx.us
4 Timed out Timed out Timed out -
Pas mieux en IPv6 :
inet6num: 2001:41d0::/40
netname: OVH
descr: OVH hosting infrastructures
descr: https://www.ovh.com (https://www.ovh.com)
country: FR
admin-c: OK217-RIPE
tech-c: OTC2-RIPE
status: ALLOCATED-BY-LIR
mnt-by: OVH-MNT
mnt-lower: OVH-MNT
source: RIPE # Filtered
2 * * * Délai d'attente de la demande dépassé.
3 21 ms 21 ms 21 ms 2a01:e00:1:13::1
4 * * * Délai d'attente de la demande dépassé.
-
Ils sont en train de jouer avec le réseau en ce moment :
http://travaux.ovh.net/?project=24&status=all&perpage=50 (http://travaux.ovh.net/?project=24&status=all&perpage=50)
-
Oui, c'est bien ça.
Gros plantage réseau chez OVH. Une maintenance majeure en pleine heure de pointe qui n'est pas maitrisée du tout. Sans doute une grosse partie RBX-1, voire tout RBX-1 est HS!
Et dire que c'est directement Octave Klaba qui est le responsable du réseau.
http://travaux.ovh.net/?do=details&id=9224 (http://travaux.ovh.net/?do=details&id=9224)
Commentaire de OVH - jeudi, 29 août 2013, 20:13
on a fini les routeurs du 1er vlan (70 routeurs)
mais il n'y a rien qui va.
les process OSPF ne veulent plus remonter. on
est en train de simplifier la configuration pour
eviter d'annocer tous les LSA puis redemarrer
les routeurs qui ont planté. on a déjà quelques
routeurs UP. mais il reste beaucoup à faire.
Commentaire de OVH - jeudi, 29 août 2013, 21:38
pendant qu'on essaie de remonter l'OSPF routeur
par routeur, on ajoute la configuration BGP pour
virer l'OSPF de ces petits routeurs.
Leon
-
<troll>Ou alors ce sont tous les serveurs KS 2G transformés en seedbox qui ont fait planter le réseau.</troll>
-
je confirme ovh HS depuis chez moi entre 21h25 et 21h35
quelques autres pertes avant 22h
graph vers un kimsufi sur rbx1
-
Ah ouais, ça c'est vu !
-
Ah ouais, ça c'est vu !
Bonsoir Badmax,
L'on Dirais du Smokeping mais je ne connais pas cette probe,
pourrais tu m'en dire plus ?
Cordialement
Bensay
-
Cela ressemble plus à un graphe issu d'un script perso tracé par munin mais laissons l'intéressé nous éclairer. ;D
-
Compte rendu d'incident d'OVH.
J'en retiens : OVH planifie une grosse intervention dont il sait qu'elle aura des impacts clients en fin d'après-midi, au pic de consommation. De plus, OVH ne préviens pas ses clients, alors que certains pourraient prendre leur dispositions (ceux qui ont des serveurs chez plusieurs hébergeurs). Pour finir, ils ne parlent pas de l'indemnisation dans le post.
Bref, ça n'est pas professionnel du tout comme attitude.
Sur RBX1 nous avons une configuration de reseau
très particuliere qui se base sur 2 routeurs de RBX1
rbx-1-6k et rbx-2-6k. Ces 2 routeurs gere l'interco
d'environ 120-130 petits routeurs. C'est une archi
qui date de 2006 que nous n'avons qu'à RBX1 et la
particularité de cette configuration rendait toutes
les mise en place de nouveaux services complexes
(le VAC, le vrack etc). Il fallait qu'on simplifie
cette configuration en attendant de remplacer tous
ces routeurs par 4 gros, comme dans tous les autres
DC (les 4 routeurs sont arrivés il y a 2 semaines
et on pense faire la migration de RBX1 fin septembre).
On savait la simplification de cette configuration
allait avoir l'impact sur la disponibilité sur DC RBX1
et on savat qu'on allait devoir changer quelques
routeurs par les spares. On a donc preferé faire
l'inter dans la journée où nous avons le maximum
des staffs pour intervenir rapidement sur le hard.
et ça n'a pas loupé. Nous avons finalement dû virer
l'OSPF completement et mettre que le BGP.
88 routeurs ont été reconfigurés et il en reste encore 42.
On pourra pousser la configuration definitive sur
ces 42 derniers routeurs sans generer de pannes
nouvelles puis apres retirer l'ancienne conf. Après
le coup on se dit qu'on aurait dû faire ça dés le depart ..
Le probleme de RBX1 a impacté 2 autre routeurs qui
s'occupent du vrack 1.0 et qui n'ont pas été mis à jour
il y a 2-3 mois. Avec un uptime de plusieurs années
et les problemes d'aujourd'hui, nous avons eu la
fragmentation de la RAM et nous avons dû les redemarrer.
Les autres DC n'ont pas été impactés. Le probleme
concernait le DC RBX1 rt une partie de la soirée
le vrack 1.0 / IP LB. Le VAC1 ne fonctionnait pas
correctement durant une periode.
Nous sommes désolés pour la panne generées et sa durée.
-
complètement d'accord avec toi leon...
ça fait un peu légé de dire que pour avoir tout le staff dispo il font la migration en pleine journée....
si tu sais qu'il y a un gros risque tu fais ça de nuit quitte à payer du monde en trop, et à en mettre d'autre d'astreinte.
la j'ai l'impression qu'ils ont vraiment voulu économiser sur les cout de la main d’œuvre, tout en étant légèrement optimiste sur l'impact possible de la panne...
-
Le coup de "on l'a fait en heure de pointe parce qu'on savait que ça risquait de foirer", il fallait oser...
-
Et voici le message qui a été posté sur une mailing list OVH par OVH juste avant l'intervention.
Je commence à avoir des doutes sur OVH...
the internal network in the RBX1 has an old
setup and we wanted/need to change it. one day.
lot of problems with the internal routing
between the VAC and RBX1, between all DC and
RBX1. lot of loops and strange things ..
well, it has to be done and it will be done now.
it's quite difficult since we talk about 130
small routers and I don't believe that we will
do it with 0 packet lost. but it can be done
without any downtime .. if we pray and lot.
so let's pray together and let's do it
Au final, ils ne l'ont pas dit, mais c'est 3h de downtime ou plus, sur tout type de serveurs, de RBX-1, mais aussi parfois d'autres datacenter, et ça n'a pas épargné les serveurs "hauts de gamme".
Sinon, j'ai cherché à savoir si les clients seraient remboursés... et c'est mesquin. Pour avoir une garantie SLA avec remboursement, il faut payer une "option utilisation pro" qui coute 15% du prix du serveur. Et dans ce cas, OVH rembourse 5% par heure de downtime!!! Donc l'option paye directement à OVH le remboursement de 3h de downtime par mois! ENORME! Je sais que mon raisonnement est simpliste, mais quand même...
Leon.
-
c'est ça le low cost.
ils sont tellement gros qu'ils s'en fichent de l'impact pour les clients.
ok ca va gueuler 2 jours sur les forums puis tout le monde va passer à autre chose jusqu'à la prochaine panne.
un peu à la méthode free. on déploie de la beta puis on voit. ovh c'est les meme méthodes.
-
Bonsoir Badmax,
L'on Dirais du Smokeping mais je ne connais pas cette probe,
pourrais tu m'en dire plus ?
Cordialement
Bensay
Cela ressemble plus à un graphe issu d'un script perso tracé par munin mais laissons l'intéressé nous éclairer. ;D
C'est mirtouf qui gagne un lot en porcelaine. Par contre, je n'utilise pas munin, c'est 100% homemade.
C'est utilisé en environnement professionnel pour vérifier la disponibilité de l'accès Internet dans son ensemble en testant une centaine de sites web, la majorité en France et situé sur différents peerings dont des IX.
Si y'a des motivés pour re-écrire tout ça en perl ou autre langage plus évolué, contact MP.
-
Tu peux consulter :
http://munin-monitoring.org/wiki/HowToWritePlugins (http://munin-monitoring.org/wiki/HowToWritePlugins)
et laisser ta contribution à cette adresse :
https://github.com/munin-monitoring/contrib/tree/master/plugins (https://github.com/munin-monitoring/contrib/tree/master/plugins)
quelqu'un pourrait être tenté de l'améliorer.