Auteur Sujet: [RESOLU] Problème chez l'hébergeur Oxalide  (Lu 11747 fois)

0 Membres et 1 Invité sur ce sujet

fl0w

  • Professionnel des télécoms
  • Client SFR sur réseau Numericable
  • *
  • Messages: 722
[RESOLU] Problème chez l'hébergeur Oxalide
« Réponse #24 le: 24 janvier 2015 à 11:07:13 »
Ils connaissent pas le protocole Spanning Tree? C'est gros là quand même :/

BadMax

  • Client Free adsl
  • Modérateur
  • *
  • Messages: 3 455
  • Malissard (26)
[RESOLU] Problème chez l'hébergeur Oxalide
« Réponse #25 le: 24 janvier 2015 à 13:23:23 »
C'est parce que le réseau de Mgmt est sans doute basé sur des matériels plus basiques sur lesquels aucune contre-mesure n'a été prévue : BPDUguard, storm-control, etc. Meme avec un spanning-tree bien configuré, on peut l'enfumer, par exemple avec une boucle inter-Vlan ou un équipement connecté qui filtre les BPDU etc etc

Sinon y'a TRILL ou SPF qui est plus efficace mais c'est "du luxe" pour un réseau de mgmt.

Synack

  • AS16080 Rentabiliweb Telecom
  • Expert
  • *
  • Messages: 687
[RESOLU] Problème chez l'hébergeur Oxalide
« Réponse #26 le: 25 janvier 2015 à 14:03:53 »
Hello,

tout d'abord hors technique, une remarque : Je suis le seul à être exaspéré par les "experts","ultra" et compagnie dans tous les sens sur les communiqués pour se prétendre exceptionnel quand il arrive un problème ? Ca fait beaucoup de blabla à raconter une belle histoire plutôt que de raconter les faits et comment c'est géré, ça me donne pas trop confiance perso ce genre de discours, je ne trouve pas la com bonne.


Sinon techniquement pour le peu qui est dit :

- Je suis surpris que sur ce type de problème le backbone n'annonce plus aucune route à personne nulle part. Pour moi il y a un vrai problème quelque part dans la conception/architecture. Comment une boucle de niveau 2 peu impacter un coeur de réseau de cette manière ?

- Une boucle réseau L2 entre des sites ? Ca se fait encore ça ? Même pour du management, ça coûte pas bien cher de faire un réseau L3 de gestion avec de l'OSPF. Là encore, que le L2 de management impacte les routeurs BGP, pour moi c'est un problème de conception, j'ai du mal à l'imaginer. Pourquoi partir sur TRILL/SPF ou sur tout autre solution L2 quand un 3560G d'occasion à moins de 1500 Euros sait très bien faire de l'OSPF et gérer une area de management sur un réseau séparé ? (ou même du PowerConnect ou autre moins cher encore) Après il y a aussi les technos MAN L2 (plus toutes jeunes) qui existent comme chez Foundry/Brocade ou tu peux déclarer un anneau L2 protégé.

- Pour le "storm" L2. Ca dépend pas mal des équipements mais aussi du type de paquet. Entre unicast, multicast, broadcast, et autres le traitement n'est pas toujours le même, notamment sur le traitement en CPU central. Par exemple le problème FranceIX ce n'était pas du broadcast mais du discard en masse. Faut aussi voir que malheureusement beaucoup trop de petits opérateurs branchent leur port FranceIX sur un L2 au lieu de directement connecter un routeur, ce qui n'est pas propre (reste que c'est à l'IX d'être strict sur sa politique de protection et d'autorisation)

- Pour le choix d'hébergeur : OVH et d'autres low cost ne sont pas adaptés pour ce type de client, ils ne fournissent pas un support d'infogérence poussé, le choix dépend souvent de la présence ou non d'équipes d'admin sys complètes chez les sociétés en fait. Un Ecritel, Lynkbynet, Prosodie ou autres vont vendre une infogérance en général avec l'hébergement (je vais pas m'étendre sur le niveau de qualité selon les boîtes qui m'a parfois désespéré), là où un gros hoster comme OVH ou Online ne veut pas se prendre trop la tête avec de l'humain et des cas particuliers et mise à fond sur le hosting pur automatisé au max. Typhoon est devenu une référence sur l'hébergement à valeur ajoutée ces dernières années (pas sûr que ça continue avec le rachat, je suis plus trop), c'est sûr que ses clients sont différents de ceux des gros low coster. Oxalyde je suis un peu surpris aussi qu'ils aient ces références par rapport à leur taille, mais il y a peut-être un aspect politique/loby derrière toutes ces références. Aussi parfois quand on a 2-3 références concurrentes, c'est plus facile de convaincre un client de venir, parce qu'il ne prend pas de risque, c'est "ce que tout le monde prend".

- Concernant le problème lui même ma curiosité :
1) Est-ce que le réseau de management est branché sur les ports mgmt des équipements ou juste sur un port quelconque ?
2) Est-ce que le L3 et le L2 des sites sont gérés directement sur le coeur sans edge ?
3) Est-ce que les préfixes étaient bien déclarés sur l'ensemble des routeurs de coeur ou du moins bien redondés ?
4) Est-ce que le réseau de management c'était pas juste une boucle L2 sur les équipements directement ? (là ça ferait très peur)

Franchement je ne vais pas m'avancer à dire que c'est du pipeau mais l'explication et le style des communiqués me laisse suspicieux de mon côté, tant sur la cause que sur les conséquences que ça a.


Mais bon ça ne fait que renforcer ces principes :
- Eviter autant que possible le L2
- Ne jamais faire de L2 entre plusieurs sites (hors technos MPLS ou modernes et encore, il vaut mieux séparer au max du coeur)
- Le coeur de réseau ne doit pas voir passer de L2, c'est le rôle des routeurs edge en dessous.
- Un réseau de management ne doit jamais "leaker" sur le réseau principal et vice versa


C'est con parce que le jour où c'est arrivé je compatissais pour eux, mais de voir les communiqués et les explications change la vision que j'ai de l'incident à présent :/

My 2 cents.

corrector

  • Invité
[RESOLU] Problème chez l'hébergeur Oxalide
« Réponse #27 le: 25 janvier 2015 à 14:39:54 »
Hello,

tout d'abord hors technique, une remarque : Je suis le seul à être exaspéré par les "experts","ultra" et compagnie dans tous les sens sur les communiqués pour se prétendre exceptionnel quand il arrive un problème ? Ca fait beaucoup de blabla à raconter une belle histoire plutôt que de raconter les faits et comment c'est géré, ça me donne pas trop confiance perso ce genre de discours, je ne trouve pas la com bonne.
Disons que ça tombe un peu à plat : on a eu une panne générale, qui a duré, on a eu du mal à trouver la cause (parce qu'on cherchait pas du bon coté), ça prouve qu'on est des super pros, hein? Hein? Hein dis qu'on est des super pros? Tu veux dire que je suis un pro super top moumoute?

T'es méchaaaaaaaaaaaant!

vivien

  • Administrateur
  • *
  • Messages: 32 514
    • Twitter LaFibre.info
[RESOLU] Problème chez l'hébergeur Oxalide
« Réponse #28 le: 25 janvier 2015 à 16:26:10 »
Je suis en phase que la durée de la panne (un peu plus de 2h si on regarde l'horodatage du forum) semble en décalage par rapport au problème annoncé.

Maintenant, on a déjà vu des problèmes simples se transformer en catastrophe suite a de mauvaises prises de décision. Je pense à la  panne d'un disjoncteur haute tension sur le Datacenter N+1 de Redbus, en mars 2006. La panne du disjoncteur étaient du a des micro coupures du réseau ERDF. Il s'en est suivit plusieurs décisions catastrophiques entraînant plusieurs coupure électriques et l'idée lumineuse de brancher en direct les serveurs sur les groupes (sans onduleurs dont les batteries étaient à plat). De nombreux serveurs n'ont pas supportés et il a fallu changer les alimentations. Les groupes ont alimentés plusieurs jours le datacenter et déjà a l'époque ils fessaient de la communication avec possibilité de suivre les camions citerne qui approvisionnaient régulièrement le datacenter.

fl0w

  • Professionnel des télécoms
  • Client SFR sur réseau Numericable
  • *
  • Messages: 722
[RESOLU] Problème chez l'hébergeur Oxalide
« Réponse #29 le: 26 janvier 2015 à 10:45:08 »
Redbus, le cas d'école :D

BadMax

  • Client Free adsl
  • Modérateur
  • *
  • Messages: 3 455
  • Malissard (26)
[RESOLU] Problème chez l'hébergeur Oxalide
« Réponse #30 le: 26 janvier 2015 à 17:45:43 »
Un article sur ZDNet est paru à propos d'Oxalide : http://www.zdnet.fr/actualites/panne-oxalide-maxime-kurkdjian-dg-il-n-y-a-pas-un-seul-responsable-39813533.htm

Panne Oxalide, Maxime Kurkdjian, dg : "Il n’y a pas un seul responsable"

Réseaux : La semaine dernière, l’hébergeur Oxalide a été victime d’une panne d’ampleur. De nombreux sites de presses, mais aussi des services, étaient indisponibles pendant plusieurs heures. Une semaine après les faits, nous avons pu interroger Maxime Kurkdjian, directeur associé de l’hébergeur.


Vendredi 16 janvier, 9h52 : soudainement, une trentaine de sites de presse ne répondent plus. 20minutes, Le Parisien, L’Express mais aussi ZDNet, CNET France et Gamekult tombent. La panne se prolonge et, dans un contexte d’attaques des hacktivistes islamistes, beaucoup s’inquiètent d’un possible Ddos massif à l’encontre des sites de presse. Mais assez rapidement, l’hébergeur Oxalide, point commun des différents sites affectés, dèment la thèse de l’attaque : il s’agit d’une panne affectant le « cœur de réseau » selon les premières informations.
Boucle malheureuse

« Vendredi, suite à une erreur de documentation, une boucle réseau s’est crée sur notre réseau d’administration » explique à ZDNet.fr, Maxime Kurkdjian, co-fondateur d’Oxalide « Cela a crée ce qu’on appelle un broadcast storm qui s’est propagé par la suite à l’ensemble de notre infrastructures. Une partie de nos équipements, des routeurs Juniper situés au cœur du réseau ont été affectés par ce problème et se sont mis en défaut ».

Résultat ? Environ 3 heures d’interruption totale de service pour les sites concernés et une longue après midi chaotique avant un rétablissement complet. « Je ne crois pas qu’un problème de cet ampleur se soit déjà manifesté auparavant. On a déjà connu deux interruptions de service consécutives aux alentours de 2010 mais rien de comparable » rappelle Maxime Kurkdjian.

La panne est venue d’une simple erreur de "documentation" selon Maxime Kurkdjian: « Un des switch avait deux ports déjà utilisés, ce qui n’était pas répertorié dans la documentation à notre disposition. On a donc eu une incohérence entre la configuration physique et la configuration logique du réseau » Une première erreur qui a rapidement débordé, suite à des choix de design réseau peu judicieux.

« La boucle réseau qui s’est créée aurait pu restée cantonnée au réseau d’administration mais celui-ci s’est propagé à d’autres. On n’a pas respecté les bonnes pratiques qui consistent à isoler les différents réseaux, ce qui a conduit à une propagation ». Les deux réseaux de secours prévus pour l’occasion ont donc également été affectés, forçant Oxalide à envoyer ses ingénieurs sur place afin de rétablir le service dans les 3 datacenters mutualisés qui abritent leurs machines.
Les emmerdes, ça vole toujours en escadrille

« Il n’y a pas un seul responsable, c’est avant tout plusieurs facteurs qui se sont enchainés pour provoquer une panne de cette ampleur » explique Maxime Kurkdjian. Il serait tentant de résumer le problème simplement en invoquant une bête erreur de câblage, mais la panne est due à plusieurs erreurs faites à différents niveaux, tant dans l’architecture réseau que dans la politique de mise à jour des équipements : « On a par exemple remarqué que certains routeurs, dont l’OS avait été correctement mis à jour, n’avaient pas été affectés par la panne alors que d’autres ont été mis hors service ».

Plusieurs mesures sont prévues par Oxalide pour parer à ces problèmes à l’avenir : une réorganisation complète du réseau, une stabilisation des réseaux de secours via une simplification, le déploiement de nouveaux outils d’analyse réseau afin de détecter en amont des incohérences de ce type. « On a aussi envisagé de mettre en place des solutions automatisées, mais compte tenu des nombreux médias que l’on héberge et des fréquentes montées en charge qu’ils peuvent générer, on reste particulièrement prudents avant d’envisager l’utilisation de ce type d’outils » précise Maxime Kurkdjian. Compréhensible.

Et ces clients justement, que peuvent-ils espérer en termes de compensation commerciale, les garanties de rétablissement n'étant pas tenues ? « Sur ces questions, on est très encadré contractuellement : nous sommes tenus à un rétablissement des services en moins d’une heure. En l’occurrence, cela n’a pas été le cas et on s’expose évidemment à des pénalités encadrées par nos contrats. Au vu du caractère exceptionnel de la panne, on tient à être proactif sur ces sujets là et nous sommes actuellement en train de contacter nos clients pour en discuter avec eux ».

Plus que le défi technique, la communication de crise a posé de sérieux problèmes à l’hébergeur qui, dans un post de blog, rappelle être une société plus habituée « à l’ombre des coulisses d’Internet ». « On cherche à être transparents, et cet incident sera pour nous l’occasion d’améliorer notre communication à l’égard de nos clients » conclut Maxime Kurkdjian.


vivien

  • Administrateur
  • *
  • Messages: 32 514
    • Twitter LaFibre.info
[RESOLU] Problème chez l'hébergeur Oxalide
« Réponse #31 le: 26 janvier 2015 à 20:12:38 »
On peut féliciter Maxime Kurkdjian pour sa transparence, car effectivement l'explication d'une boucle était un peu léger pour faire tomber un réseau (imaginez Orange qui perd tout son réseau a cause d'une tempête de broadcast)

Là, il explique bien les différents facteurs qui ont été réunis pour permettre la panne :
1/ routeurs qui été mis hors service par la tempête de broadcast alors que ce n'est généralement plus le cas (et il reconais qu'une mise à jour corrigeait ce problème)
2/ On n’a pas respecté les bonnes pratiques qui consistent à isoler les différents réseaux, ce qui a conduit à une propagation
3/ Boucle crée sur le réseau d'admin, car documentation pas a jour et équipement non protégé.

Un seul de ces facteurs n'auraient pas été là, il n'y aurait pas eu coupure.

Synack

  • AS16080 Rentabiliweb Telecom
  • Expert
  • *
  • Messages: 687
[RESOLU] Problème chez l'hébergeur Oxalide
« Réponse #32 le: 26 janvier 2015 à 21:14:47 »
Hé bien effectivement bravo pour l'honnêteté dont il fait preuve dans l'interview et de reconnaître les faiblesses de l'architecture ainsi que les erreurs commises. C'est d'autant plus étonnant positivement quand on compare aux premiers communiqués officiels.

ut0mt8

  • AS49477 e-TF1
  • Expert
  • *
  • Messages: 107
  • Boulognes(92)
    • AS49477 Responsable Infrastructure eTF1
[RESOLU] Problème chez l'hébergeur Oxalide
« Réponse #33 le: 27 janvier 2015 à 22:23:16 »
Je n'avais pas vu que l'on parlait de l’incident Oxalyde ici.
Les informations que j'ai eu en off sur #frnog parle effectivement d'une boucle (et donc broadcast storm) sur un L2 traversant connecté à l'ensemble des routeurs edge. Le truc c'est qu'a priori il faisait aussi du L2 (avec des bridge domains) sur leurs MX80.
Les équipements ont semble t'il très très mal réagi. Alors on est bien dans l'explication mauvais design (L2 inter site sur des edge ?!), mauvaise release, bad timing (incident à 9H20 du matin, tout le monde dans les transports...). Et comme d'habitude il s'agissait de points connus, qu'il fallait corriger, mais qui passaient toujours derrière d'autre urgence :)
Shit happens. Cela arrive même aux meilleurs, et je suis bien placé pour le savoir.

Je trouve d'ailleurs l'attitude de la direction d'oxalyde assez bonne. Transparence, soutien aux équipes, priorisation des changements réseaux.   

Kedare

  • Eligible réseau Quentiop (78)
  • Client OVH
  • *
  • Messages: 12
  • Nantes 44
[RESOLU] Problème chez l'hébergeur Oxalide
« Réponse #34 le: 24 février 2015 à 22:04:29 »
1/ routeurs qui été mis hors service par la tempête de broadcast alors que ce n'est généralement plus le cas (et il reconais qu'une mise à jour corrigeait ce problème)

En faite le problème est que les Juniper MX (et pas que) ont un port de management (fxp) directement connecté au RE (Control Plane) sans passer par le PFE (Data Plane), du coup tu n'a aucun moyen de filtrer une broadcast storm sur ce port, et le CPU (d'huitre) du RE prend tout directement, cesse de répondre au PFE qui ne peux survivre que 5 minutes sans RE et fini par shut toutes les interfaces physiques.

Le soucis est confirmé par Juniper qui n'a pas vraiment de solution...  A part ne pas utiliser ce port de management pour manager les devices... ("This is an expected behavior" comme ils disent)

ut0mt8

  • AS49477 e-TF1
  • Expert
  • *
  • Messages: 107
  • Boulognes(92)
    • AS49477 Responsable Infrastructure eTF1
[RESOLU] Problème chez l'hébergeur Oxalide
« Réponse #35 le: 24 février 2015 à 22:27:50 »
Ah oui c'est un truc connu sur les juniper.
Il ne faut pas utiliser les fxp0 pour le management (ou alors le faire sur un truc dont tu es sur, aka un point a point sur un autre équipement, mais cela perd tout son sens). Ce n'est pas le seul problème de la fxp0, par exemple on ne peut pas la mettre dans une routing instance dédié admin.
C'est idiot mais c'est comme ça. C'est une feature comme on dit. Bref à oublier.

En pratique je préconise le management inband (quand tout se passe bien) et l'utilisation du port console via un oob (quand cela se passe mal).


 

Mobile View