Ils connaissent pas le protocole Spanning Tree? C'est gros là quand même :/

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.

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.

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.

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.

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)