La Fibre
Hébergeurs et opérateurs pro / entreprises => Hébergeurs et opérateurs pro / entreprises => 
Autres hébergeurs / opérateurs pro => Discussion démarrée par: BadMax le 16 janvier 2015 à 10:37:37
-
Plusieurs sites d'informations sont down :
- tous les sites France * (Info, Inter, etc)
- Le Parisien
- L'Expansion,
- 20minutes
- Mediapart
- Marianne
L'AS ne serait plus visible, donc on ne sait pas encore s'il s'agit d'une attaque DDOS ou d'une panne.
Actualisé 10h38: status sur twitter https://twitter.com/oxalide/status/556013906989424640 (https://twitter.com/oxalide/status/556013906989424640)
Pas d'info sur la cause.
Actualisé 10h40 https://twitter.com/oxalide/status/556022185211756545 (https://twitter.com/oxalide/status/556022185211756545)
Coeur de réseau touché.
-
Posté par acontios (https://lafibre.info/profile/acontios/) sur Twitter :
cc@rt-th2#sh ip bgp routes regular-exp 47841$
Searching for matching routes, use ^C to quit...
cc@rt-th2#
47841 étant leur AS.
-
Trop rapide, j'allais dire que les routes BGP ne sont plus annoncées..
Voici ce que donne un traceroute : (on ne sort pas du réseau, donc absence de routes)
$ mtr -rwc10 www.oxalide.com
Start: Fri Jan 16 10:47:19 2015
HOST: lafibre.info Loss% Snt Last Avg Best Wrst StDev
1.|-- portevlan.adeli.biz 0.0% 10 0.4 0.5 0.3 1.6 0.3
2.|-- ? ? 100.0 10 0.0 0.0 0.0 0.0 0.0
(https://lafibre.info/images/datacenter/201501_oxalide_disponibilite.png)
-
slate, letudiant, gamekult, gameblog, etc...
-
C'est étonnant, pour un hébergeur de taille modeste, d'avoir une politique de peering "sélective" : http://www.peeringdb.com/view.php?asn=47841
Cela se confirme : Ils ne sont pas sur les route serveur de France-IX (pour Equinix Paris, je ne vois pas l'info sur le site, il faut attendre que leur réseau remonte pour vérifier)
-
C'est étonnant aussi de voir autant de sites populaires hébergés chez cet hébergeur "de taille modeste".
-
C'est étonnant, pour un hébergeur de taille modeste, d'avoir une politique de peering "sélective" : http://www.peeringdb.com/view.php?asn=47841
Pas convaincus qu'ils aient une qcq politique de peering en fait : http://bgp.he.net/AS47841#_peers
-
Beaucoup d'hébergeurs de taille modeste savent mieux répondre aux demandes de professionnels, que des hébergeur type OVH, sauf si le prix est le premier critère.
OVH a aussi un intérêt pour un site victime de DDOS massif. Ce n'est pas pour rien que http://www.wikileaks.ch/ est chez OVH.
L'hébergeur Prosodie, qui est d'une taille comparable héberge lui aussi des sites populaires ou critique :
Les sites internet hébergés par Prosodie ont arrêté de répondre pendant les 8h de la coupure. C'est le cas de carrefour.fr, dior.fr, le ministère de l'Intérieur (defense.gouv.fr), le STIF (www.stif.info (http://www.stif.info)), Le Groupe Matelsom (Matelsom.com et Camif.fr) précise « Pour nous, le manque à gagner d’une telle journée est estimé à 250.000 euros, sans compter la perte d’image et de confiance des clients (notamment ceux déjà échaudés de camif.fr). Il aura fallu 8 heures pour que les opérateurs réparent les fibres après le coup de pelleteuse et que PROSODIE relance nos services ! Ce coup de pelleteuse malheureux aura mis 120 personnes au chômage technique depuis ce matin 8h puisque toutes nos applications (système d’information, ERP, comptabilité, sites internet) ont été rendus inaccessibles».
-
@Vivien, je suis bien placé que le choix du prestataire modeste/alternatif est souvent meilleur. Mais là sans aucune contrainte géographique, je trouve étonnant de voir tous ces grands groupes au même endroit.
-
Toujours pas de revendication sur le hashtag #TangoDown pour Oxalide. Ca sent la vraie panne.
-
Une liste de sites touchés.
-
Oxalide est présent sur 3 datacenters d'Equinix : 2 à Saint-Denis (93) et 1 à Rossy-en-France (93)
Une infrastructure sans concession pour un service de qualité :
L’ infrastructure Oxalide a été conçue et construite pour être la plus performante et la plus résiliente possible. Nous avons choisi des prestataires et du matériel de haute-gamme pour construire notre service. Vous avez à disposition du matériel de qualité, dernière génération, pour motoriser vos services.
Connectivité Internet résiliente :
Nous avons sélectionné des transitaires IP de qualité pour garantir la haute disponibilité de votre service. La haute disponibilité est également assurée par des connexions redondées sur nos 3 datacenters. De plus, nos accords de peering « sélectif » avec les points d’échange Equinix-IX et France-IX consolident la maîtrise de notre trafic.
-
C'est reparti.
Ils semblent être sur les route serveur d'Equinix Paris.
Traceroute depuis Adeli en IPv4 (pas d'IPv6 annoncé) :
$ mtr -rwc10 www.oxalide.com
Start: Fri Jan 16 12:13:34 2015
HOST: lafibre.info Loss% Snt Last Avg Best Wrst StDev
1.|-- portevlan.adeli.biz 0.0% 10 0.3 1.4 0.3 10.6 3.2
2.|-- equinix.stdenis.oxalide.net 0.0% 10 6.3 6.6 6.1 9.0 0.7
3.|-- not.updated.oxalide.net 0.0% 10 6.1 6.3 6.0 6.6 0.0
4.|-- not.updated.oxalide.net 0.0% 10 6.4 6.4 6.2 6.8 0.0
De nombreux sites ping, mais ne sont pas remontés, c'est étonnant.
Exemple : http://www.lesnumeriques.com/
Pas de réponse sur le port 80 mais cela répond à l'ICMP.
$ telnet www.lesnumeriques.com 80
Trying 95.131.141.85...
telnet: Unable to connect to remote host: Connection refused
$ telnet www.lesnumeriques.com 443
Trying 95.131.141.85...
telnet: Unable to connect to remote host: Connection refused
Mais cela ping :
$ mtr -rwc100 www.lesnumeriques.com
Start: Fri Jan 16 12:16:57 2015
HOST: lafibre.info Loss% Snt Last Avg Best Wrst StDev
1.|-- portevlan.adeli.biz 0.0% 100 0.8 1.2 0.2 8.2 1.9
2.|-- equinix.stdenis.oxalide.net 0.0% 100 29.0 23.1 6.0 91.4 16.1
3.|-- not.updated.oxalide.net 0.0% 100 6.3 13.8 6.0 268.9 37.2
$ ping www.lesnumeriques.com
PING www.lesnumeriques.com (95.131.141.85) 56(84) bytes of data.
64 bytes from not.updated.oxalide.net (95.131.141.85): icmp_seq=1 ttl=62 time=6.32 ms
64 bytes from not.updated.oxalide.net (95.131.141.85): icmp_seq=2 ttl=62 time=6.46 ms
64 bytes from not.updated.oxalide.net (95.131.141.85): icmp_seq=3 ttl=62 time=6.18 ms
-
En effet, ça semble avancer https://twitter.com/oxalide/status/556048505438216192 (https://twitter.com/oxalide/status/556048505438216192)
-
Ce ne semble pas lié aux attaques lancées par "Arab Warriors Team" en représailles à la une de Charlie Hebdo.
Les premiers éléments en notre possession nous permettent d’écarter l’hypothèse d’une attaque externe de type DDoS
-
Ce ne semble pas lié aux attaques lancées par "Arab Warriors Team" en représailles à la une de Charlie Hebdo.
Les premiers éléments en notre possession nous permettent d’écarter l’hypothèse d’une attaque externe de type DDoS
Salut,
Mis à part le communiqué officiel vide de substance sur leur site WEB, on en sait plus sur les causes de l'incident ?
@++
-
Le communiqué officiel ne dit effectivement... rien :
Retour sur l’incident du 16 janvier
La coutume veut qu’on entende parler d’un hébergeur uniquement quand il y a des problèmes… et aujourd’hui c’est le cas. Ceci, couplé à la tension actuelle des médias, nous contraint d’être sous les feux de la rampe.
Le scénario de l’attaque DDoS écarté
Le 16 janvier à 10h, l’infrastructure de cœur de réseau a subi des dysfonctionnements qui ont impacté l’intégralité de nos clients pendant 90 minutes. Envisagée dans un premier temps, du fait de l’actualité, une attaque de type DDOS, rapidement identifiable, a pu être écartée.
Une fois l’origine de l’incident identifiée et isolée, les solutions de contournement ont permis de rétablir progressivement le service 90 minutes après le début de l’incident. La totalité des sites et services hébergés par Oxalide était de nouveau disponible à midi.
L’incident est toujours en cours d’étude par nos équipes, afin de nous permettre d’établir un diagnostic approfondi et de fournir à nos clients une information détaillée, conforme à la qualité de service qu’Oxalide a toujours su donner.
Une réputation d’experts
Depuis 5 ans, nous n’avons pas connu, sur notre infrastructure, d’incident majeur susceptible d’impacter notre réseau. Il faut effectivement remonter à 2009, et à une coupure électrique globale, pour identifier un incident fortement impactant pour nos clients. Le travail de fond des équipes tout au long de ces années nous a forgé une réputation d’experts sur les architectures web critiques.
Celle-ci a permis de voir des grands noms du web français connus (leparisien.fr, lexpress.fr, 20minutes.fr, etc.) et services moins connus mais qui opèrent un grand nombre de sites (iAdvize, Lengow, Kwanko, clicrdv, etc.) s’appuyer sur nos infrastructures et nos services pour les aider à relever les défis propres à cet environnement synonyme de défis techniques quotidiens.
Nous avons construit et fait évoluer notre infrastructure en conséquence, une infrastructure qui a toujours fait la preuve de sa remarquable robustesse. Nombreux sont les succès que nous avons remportés ensemble : soldes, élections, temps forts de l’actualité… Les exceptionnelles montées en charge de la semaine dernière, dues à la conjonction des attaques terroristes relayées par les sites médias hébergés et des soldes des sites marchands de nos clients, ont été assurées sans le moindre incident.
La direction d’Oxalide
Sébastien & Maxime
-
Il va falloir attendre les explications aux clients j'imagine.
-
Oxalide est présent sur 3 datacenters d'Equinix : 2 à Saint-Denis (93) et 1 à Rossy-en-France (93)
Ils sont quand même pas hébergés dans un datacenter de Hub One dans la zone aéroportuaire d'ADP?
-
Ils sont quand même pas hébergés dans un datacenter de Hub One dans la zone aéroportuaire d'ADP?
Je comprends qu'ils sont à Equinix PA1 (Roissy), PA2 et PA3 (Saint-Denis).
-
J'ai lu en diagonale sorry. Mais j'ai eu confirmation qu'à CDG Hub One a au moins un datacenter (mais a priori réservé pour l'hébergement Aéroports de Paris)
-
[EDIT du 21/01/2015]
Par souci de transparence, nous souhaitons apporter quelques informations complèmentaires aux événements de vendredi. Le rapport d’incident détaillé indique que les routeurs du cœur de réseaux se sont comportés anormalement suite à une opération de routine au sein de notre infrastructure. La connexion d’un élèment actif sur notre réseau interne d’administration dédié à la gestion des routeurs uniquement a provoqué une réaction en chaîne de type ”Broadcast storm », qui a déclenché le mécanisme de protection de tous les nœuds.
Ceux-ci constituent notre colonne vertébrale composée de 4 nœuds ultra-fiables répartis sur 3 sites. Cette colonne est interconnectée via une dizaine de liens à plusieurs opérateurs professionnels et FAI. La déconnexion de tous ces liens, y compris ceux de secours, a coupé nos clients d’Internet. Ces éléments de contexte, ainsi que l’actualité liée aux cyberattaques, ont malheureusement ralenti notre diagnostic et le rétablissement du service.
La situation est complètement revenue à la normale pour l’ensemble de nos clients en début d’après-midi, soit 90 minutes après le début de l’incident.
Même si certains clients ont souligné la transparence d’Oxalide lors de cette communication de crise, nous sommes bien évidemment concernés et désolés de cet incident. Habitués à une qualité irréprochable sur notre infrastructure, nous avons mis en oeuvre des dispositifs pour limiter à l’avenir l’impact de ce type d’incident sur l’infrastructure d’Oxalide.
Nous en profitons pour remercier les équipes d’Oxalide, bien sûr, mais aussi plusieurs confrères, clients et fournisseurs qui nous ont fait part de leurs encouragements car l’actualité nous a involontairement ”propulsés” sur le devant de la scène alors que nous sommes habitués à l’ombre des coulisses d’Internet. Depuis 15 ans que nous faisons ce métier, ils savent à quel point, nous sommes des artisans exigeants avec nous-mêmes et comment un incident peut être mal perçu par un client alors que nous l’aidons tous les jours à résoudre les siens.
On dit souvent que c’est quand il y a un incident que l’on voit la qualité d’un hébergeur.
Nous espérons avoir été à la hauteur.
Sébastien Lucas et Maxime Kurkdjian – La direction
http://www.oxalide.com/2015/01/retour-sur-lincident-du-16-janvier/*
Ultra-fiables, ultra-fiables, il faut le dire vite...
Pourquoi ces broadcasts? Avec cette explication on est bien avancé...
-
Ils ont créé une boucle L2 sur leur réseau d'admin ce qui a saturé les interfaces mgmt des routeurs ? Ce réseau étant commun à tous les sites, ça aurait tout planté. Reste plus qu'à le segmenter pour se prémunir de ce genre d'effet.
-
Il me semble que certains routeurs arrivent a mieux gérer une tempête de broadcast.
J'ai souvenir d'un Cisco 6509 qui avait résisté à une tempête de broadcast de 10 Gb/s sur un de ses ports (pas les ports d'admin, il est vrai)
Inversement, je me souviens avoir vu des routeurs tomber pour beaucoup moins lors d'un pb sur le France-IX.
-
Ils connaissent pas le protocole Spanning Tree? C'est gros là quand même :/
-
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.
-
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.
-
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!
-
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.
-
Redbus, le cas d'école :D
-
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 (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.
-
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.
-
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.
-
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.
-
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)
-
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).