Posté par gUI (Mastodon) .
Évalué à 5.
Dernière modification le 05 octobre 2021 à 09:06.
À noter que l'article de Cloudflare a une 2e partie très intéressante sur les effets pas forcément anticipés d'une telle panne sur les serveurs DNS publics qui eux, marchent pourtant bien (spoiler : les applications qui font des retry sur le DNS facebook, ou les humains qui du coup vont massivement sur d'autres réseaux sociaux).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
"Move fast and break things" became a pervasive mantra of the Internet, and not only did Facebook's Mark Zuckerberg adopt this as the operating principle for Facebook's internal engineering effort, but he went further to observe that “Unless you are breaking stuff, you are not moving fast enough.” Perhaps we should simply be grateful that Facebook does not build aeroplanes, nuclear power plants or automobiles.
Geoff Huston dans un article de juillet a propos d'un incident sur Akamaï :
Si certains ont pensé à une attaque, il n’en était rien. Il s’agissait bien d’une panne, consécutive au déploiement d’une mise à jour d’entretien pour les routeurs de l’entreprise. Elle était si énorme que même les équipements internes étaient inaccessibles, bloquant notamment les techniciens car leurs badges n’étaient plus validés par les systèmes de sécurité.
C'est allé assez loin :-)
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
Posté par Big Pete .
Évalué à 5.
Dernière modification le 06 octobre 2021 à 10:38.
Ben c'est comment dire, BGP, c'est ce qui tient tout le réseau. Si ça part en sucette, tout ce qui est au dessus tombe. Et compte-tenu de sa nature (échange dynamique de routes et distribution de la topologie du réseau entre routeurs), il peut très bien y avoir des réactions en chaine. Donc oui, généralement, une boulette dans BGP, ça peut faire d’énormes dégâts.
Le DNS est aussi un bon candidat à la boulette de conf aussi.
Perso, ce que je trouve inquiétant dans l'incident Facebook, ce n'est pas tant que le réseau de prod soit tombé, ça bon, c'est limite compréhensible, c'est que tout le réseau d'exploitation, en gros, les couloirs de service, soit aussi tombé. Généralement, c'est une bonne pratique de séparé sur des infra bien distincte ce qui à trait au trafic de production et ce qui de l'ordre de l'exploitation et de la maintenance. Ils ont quand même été obligé de se rendre physiquement sur les DC, pour relancer le réseau avec en plus des problèmes d'accés du au fait que les systèmes de sécurité des DC était aussi impacté.
Je crois qu'ils ont un gros boulot d'analyse post-mortem à faire. Et d'ailleurs, ce travail si il est publié du moins en partie, sera surement très intéressant pour tout le monde.
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
Posté par claudex .
Évalué à 3.
Dernière modification le 06 octobre 2021 à 10:43.
Généralement, c'est une bonne pratique de séparé sur des infra bien distincte ce qui à trait au trafic de production et ce qui de l'ordre de l'exploitation et de la maintenance.
D'après le rapport, ils ont bien un oob distinct mais il est tombé en même temps que la prod. (j'imagine qu'ils vont corriger ce problème)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
BGP, c'est le seul truc visible. Et chez les gros, il est automatisé pour, notamment, retiré les annonces quand des trucs internes déconne. Ici, je n'ai pas l'impression que BGP soit en cause, c'est juste que les trucs internes ont déconné partout, donc, sur chaque site, l'automatisation a bien fait son boulot et retiré les annonces bgp et donc facebook n'était plus joingnable. Mais les annonces seraient restées, ça n'aurait sans doute pas mieux fonctionné (peut-être moins de problème sur les resolvers dns, mais ça ne change pas vraiment le résultat final).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Tu veux dire que les automatismes autour de BGP ont fonctionné mais qu'une autre boulette en est à l'origine ? En gros, BGP n'est qu'un symptome et non la cause racine. C'est ça ?
Posté par Big Pete .
Évalué à 2.
Dernière modification le 06 octobre 2021 à 11:03.
Ben disons que c'est pas super clair sur la root cause de leur incident. Si j'en crois le lien posté plus haut :
This was the source of yesterday’s outage. During one of these routine maintenance jobs, a command was issued with the intention to assess the availability of global backbone capacity, which unintentionally took down all the connections in our backbone network, effectively disconnecting Facebook data centers globally.
Sauf qu'on ne sait pas de quelle commande ils parlent. Si je me projette sans mon propre environnement de travail, ce type d'isolation de site, ou de re-routage de flux réseau, est souvent effectué via le routage (insertions, retrait d'annonces, jeu sur les priorité, le poids des routes, etc, bref, de l'ingénierie BGP).
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
Je parle de la partie eBGP vu que c'est celle qu'on voit (et je suppose que c'était là dessus qu'était la remarque initiale). Et, au moins pour le DNS, c'est bien parce qu'ils étaient isolés en interne qu'ils ont retiré les annonces externes:
To ensure reliable operation, our DNS servers disable those BGP advertisements if they themselves can not speak to our data centers,
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Oui, vu comme ça. Mais il font surement tourné du BGP en interne aussi, sur leur backbone.
Our engineering teams have learned that configuration changes on the backbone routers that coordinate network traffic between our data centers caused issues that interrupted this communication. This disruption to network traffic had a cascading effect on the way our data centers communicate, bringing our services to a halt.
Après, je comprend ce que tu veux dire, le problème c'est pas BGP en soi, y a pas de probléme spécifique a ce protocole de routage en tant que tel, c'est juste que sa nature et sa fonction dans le réseau fait que si on se plante en faisant une modif de conf avec, cela peut avoir des conséquences très importante sur tout le reste.
Et on est beaucoup a penser que l'automatisation, si c'est très bien en terme d'exploitation (ça permet souvent d'éviter justement des erreurs humaines fréquentes), ça a aussi un revers, quand ça foire (rarement), ben ça foire méchamment. Du coup, faut vraiment faire attention dans la façon dont on automatise certains process.
Après, je ne connais pas en détail leur infra, mais je sais qu'il sont à l'origine de pas mal de travaux sur l'utilisation de BGP pour l'interconnexion de datacenter, par exemple, cette RFC : https://datatracker.ietf.org/doc/html/rfc7938
Après, je comprend ce que tu veux dire, le problème c'est pas BGP en soi, y a pas de probléme spécifique a ce protocole de routage en tant que tel,
On peut penser aussi qu'un tel système ne devrait pas être aussi sensible à l'erreur. Par exemple, le TTL du DNS permet d'éviter que la perte d'un serveur temporaire entraine une cascade de panne.
BGP est peut être trop permissif, ou les nœuds acceptent trop facilement des confs en erreur.
Par exemple, le TTL du DNS permet d'éviter que la perte d'un serveur temporaire entraine une cascade de panne.
Mais par contre, ça empêche la correction d'une erreur rapidement, ce qui a aussi un impact négatif (et qui fait que beaucoup de monde utilise un TTL très bas, ce qui ruine son avantage).
BGP est peut être trop permissif, ou les nœuds acceptent trop facilement des confs en erreur.
Je ne comprends pas vraiment ce que tu veux dire, de ce point de vu, tous les protocoles de routage dynamiques ont le même problème. Et je ne vois pas trop comment tu veux vérifier que quand un peer retire une annonce, il ment.
Encore une fois, dans ce cas, de ce que j'en ai compris, BGP a fonctionné exactement comme prévu. C'est juste que quand un DC perd la connectivité, il a annonce qu'il n'est plus joignable. Ce qui est un comportement attendu. C'est juste que c'est arrivé à tous les DC en même temps.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Ben, encore une fois, c'est sa nature même de protocole d'échange de route. La force de BGP c'est de pouvoir passer à l'échelle sur des réseaux énormes, typiquement, c'est même sa raison d'être, et le fait qu'il est utilisé à large échelle pour gérer le routage sur internet. Et globalement, ça marche plutôt bien. Dans le cas de Facebook, leur réseau interne est tellement gros qu'ils en viennent aussi a utiliser BGP pour gérer le routage sur leur backbone, là ou d'autres utiliseraient des IGP comme OSPF ou IS-IS, mais ces protocoles réseau ne passent plus en terme de temps de convergence et de stabilité quand la topologie deviens trop complexe.
Après, ils disent qu'ils ont un outil de vérification des conf réseau qui normalement n'aurait pas du laisser passé ça, mais bon, on en sait pas vraiment plus. Le diable est dans les détail. Mais, amha, le probléme c'est pas le protocole en soi, c'est plutôt la façon dont il est utilisé, les process (automatique ou pas), l'architecture du réseau (séparation stricte de l'exploitation et de la prod), etc …
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
Comme tous les outils de vérification, ça vérifie ce qui est prévu (donc connu ou envisagé.) Et dans normalement on sent la supposition …qui me laisse penser qu'il y a un concours de circonstances malencontreuses (certains cas ont probablement été testés séparément, mais comme un malheur de Murphy n'arrive jamais seul ils l'ont eu dans l'os.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Non mais sometimes shit happen. Limite, ça se comprend, ça veut pas dire que c'est normal, qu'il y a pas du boulot pour corriger le tir, que ce soit sur l'aspect purement technique que sur le pilotage des opérations. Ce qui n'est vraiment pas normal, c'est que la même opération ai pu mettre par terre a la fois le réseau de production, et le réseau de maintenance, ce qu'on appelle dans le jargon, le réseau out-of-band, c'est a dire un réseau normalement physiquement séparé du réseau de production et dont la fonction est justement de pouvoir passer des commandes sur les routeurs et autres équipement réseau quand le réseau principal est par terre. Le réseau de secours quoi. En gros c'est ce qui a fait que l'incident au lieu de durer quelque minutes à durer quelque heures, et qui a transformé un "j'ai senti un trouble dans la force" en une première page sur tous les canards de la planète.
ça c'est vraiment pas beau. Et quand je postais plus haut la référence a Geoff Huston qui disait en gros, heureusement qu'il font pas des centrales nucléaires chez Facebook, ben, effectivement, ce genre de pépin, aurait tendance a renforcer son point de vue. Après, on sait pas tout, mais dans l'absolu, c'est sur qu'il y a un gros probléme a ce niveau que soit un truc fondamental (defective by design) ou une évolution technique qui a pu rendu leur réseau OOB vulnérable sans qu'ils s'en aperçoivent.
One of the key questions Facebook hasn’t answered yet is why its backup network, called the out-of-band network, didn’t work on Monday. The network is designed to be isolated from the rest of Facebook, providing engineers with a way to remotely fix the system within minutes if it goes down. Facebook’s Janardhan said in a blog post that the out-of-band network didn’t work yesterday, but didn’t explain why.
Le truc à savoir aussi, c'est que techniquement dans le monde du réseau, Facebook c'est un peu une référence sur le plan technique, autant je ne peux pas les piffer sur le plan éthique et sur leur modèle d'affaire, autant il me semble qu'il sont reconnu pour être des pointures dans le domaine des réseaux et des infrastructure datacenter, du moins, de ce que j'en sais. C'est d'autant plus étonnant, et serait d'autant plus intéressant d'avoir le fin mot de l'histoire, pas simplement sur la root cause de l’événement, mais sur le fait que le réseau OOB était ko aussi.
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
Perso, je parie que c'est pour une des deux raisons suivantes (attention, ce n'est que de la pure spéculation, je n'ai pas d'info là dessus):
soit leur oob se connecte aux serveurs de facebook pour faire un tunnel, et là, il n'y avait plus de serveur facebook disponible depuis un réseau distinct. C'est un avantage (si votre réseau entier ne disparaît pas bien sûr) parce que ça permet d'avoir des oob derrière des nat, par exemple en 4g.
soit leur oob a plusieurs connexions disponible (4g, adsl, pigeon…) et ping les dns de facebook pour savoir quelle connexion utilisée. Pareil, c'est pratique si votre infra ne disparaît pas entièrement.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Voilà ! Je comprends le point soulevé par big Pete, mais je soupçonne comme toi (sans avoir pu me le formuler aussi clairement) un fort couplage de l'oob. Quand à être une référence en terme de réseau, j'ai toujours vu pour ma part qu'ils ont de la r&d et de la comm' sur le sujet…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Et on est beaucoup a penser que l'automatisation, si c'est très bien en terme d'exploitation (ça permet souvent d'éviter justement des erreurs humaines fréquentes), ça a aussi un revers, quand ça foire (rarement), ben ça foire méchamment. Du coup, faut vraiment faire attention dans la façon dont on automatise certains process.
Oui, après, il y a plusieurs méthodes qui permettent d'éviter que ça ait un impact sur toute l'infra d'un coup. Mais dans ce cas, ce n'était pas une commande qui était censé avoir un impact.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# La version côté Est de l'Atlantique
Posté par Glandos . Évalué à 7.
https://www.bortzmeyer.org/facebook-octobre-2021.html
Y a moins de graphiques. Mais quand même.
[^] # Re: La version côté Est de l'Atlantique
Posté par gUI (Mastodon) . Évalué à 5. Dernière modification le 05 octobre 2021 à 09:06.
À noter que l'article de Cloudflare a une 2e partie très intéressante sur les effets pas forcément anticipés d'une telle panne sur les serveurs DNS publics qui eux, marchent pourtant bien (spoiler : les applications qui font des retry sur le DNS facebook, ou les humains qui du coup vont massivement sur d'autres réseaux sociaux).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Move fast and break things
Posté par Big Pete . Évalué à 6.
Geoff Huston dans un article de juillet a propos d'un incident sur Akamaï :
https://www.potaroo.net/ispcol/2021-07/outage.html
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
# Badges plus validés
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 5.
Le Brief de Next-Inpact
C'est allé assez loin :-)
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
# Les explications de Facebook
Posté par Colargol (site web personnel) . Évalué à 3. Dernière modification le 05 octobre 2021 à 20:16.
https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/
# encore BGP ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
C'est moi ou la plus part des gros "outages" de GAFAM sont dû à des problèmes de configuration BGP ?
"La première sécurité est la liberté"
[^] # Re: encore BGP ?
Posté par Big Pete . Évalué à 5. Dernière modification le 06 octobre 2021 à 10:38.
Ben c'est comment dire, BGP, c'est ce qui tient tout le réseau. Si ça part en sucette, tout ce qui est au dessus tombe. Et compte-tenu de sa nature (échange dynamique de routes et distribution de la topologie du réseau entre routeurs), il peut très bien y avoir des réactions en chaine. Donc oui, généralement, une boulette dans BGP, ça peut faire d’énormes dégâts.
Le DNS est aussi un bon candidat à la boulette de conf aussi.
Perso, ce que je trouve inquiétant dans l'incident Facebook, ce n'est pas tant que le réseau de prod soit tombé, ça bon, c'est limite compréhensible, c'est que tout le réseau d'exploitation, en gros, les couloirs de service, soit aussi tombé. Généralement, c'est une bonne pratique de séparé sur des infra bien distincte ce qui à trait au trafic de production et ce qui de l'ordre de l'exploitation et de la maintenance. Ils ont quand même été obligé de se rendre physiquement sur les DC, pour relancer le réseau avec en plus des problèmes d'accés du au fait que les systèmes de sécurité des DC était aussi impacté.
Je crois qu'ils ont un gros boulot d'analyse post-mortem à faire. Et d'ailleurs, ce travail si il est publié du moins en partie, sera surement très intéressant pour tout le monde.
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
[^] # Re: encore BGP ?
Posté par claudex . Évalué à 3. Dernière modification le 06 octobre 2021 à 10:43.
D'après le rapport, ils ont bien un oob distinct mais il est tombé en même temps que la prod. (j'imagine qu'ils vont corriger ce problème)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: encore BGP ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Il y a déjà eu des outages complet à cause de DNS ? Le service DNS semble un peu plus costaux par construction, non ?
"La première sécurité est la liberté"
[^] # Re: encore BGP ?
Posté par claudex . Évalué à 3.
Il y a déjà eu des outages complets à cause de bgp ? (je veux dire du protocole, pas un outil qui retire les annonces)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: encore BGP ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Pas à ma connaissance… Par contre, on a déjà eu des peurs sur le DNS (entre autre à cause d'attaque sur les serveurs principaux.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: encore BGP ?
Posté par claudex . Évalué à 4.
BGP, c'est le seul truc visible. Et chez les gros, il est automatisé pour, notamment, retiré les annonces quand des trucs internes déconne. Ici, je n'ai pas l'impression que BGP soit en cause, c'est juste que les trucs internes ont déconné partout, donc, sur chaque site, l'automatisation a bien fait son boulot et retiré les annonces bgp et donc facebook n'était plus joingnable. Mais les annonces seraient restées, ça n'aurait sans doute pas mieux fonctionné (peut-être moins de problème sur les resolvers dns, mais ça ne change pas vraiment le résultat final).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: encore BGP ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Tu veux dire que les automatismes autour de BGP ont fonctionné mais qu'une autre boulette en est à l'origine ? En gros, BGP n'est qu'un symptome et non la cause racine. C'est ça ?
"La première sécurité est la liberté"
[^] # Re: encore BGP ?
Posté par claudex . Évalué à 3.
Oui.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: encore BGP ?
Posté par Big Pete . Évalué à 2. Dernière modification le 06 octobre 2021 à 11:03.
Ben disons que c'est pas super clair sur la root cause de leur incident. Si j'en crois le lien posté plus haut :
Sauf qu'on ne sait pas de quelle commande ils parlent. Si je me projette sans mon propre environnement de travail, ce type d'isolation de site, ou de re-routage de flux réseau, est souvent effectué via le routage (insertions, retrait d'annonces, jeu sur les priorité, le poids des routes, etc, bref, de l'ingénierie BGP).
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
[^] # Re: encore BGP ?
Posté par claudex . Évalué à 4.
Je parle de la partie eBGP vu que c'est celle qu'on voit (et je suppose que c'était là dessus qu'était la remarque initiale). Et, au moins pour le DNS, c'est bien parce qu'ils étaient isolés en interne qu'ils ont retiré les annonces externes:
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: encore BGP ?
Posté par Big Pete . Évalué à 3.
Oui, vu comme ça. Mais il font surement tourné du BGP en interne aussi, sur leur backbone.
https://engineering.fb.com/2021/10/04/networking-traffic/outage/
Après, je comprend ce que tu veux dire, le problème c'est pas BGP en soi, y a pas de probléme spécifique a ce protocole de routage en tant que tel, c'est juste que sa nature et sa fonction dans le réseau fait que si on se plante en faisant une modif de conf avec, cela peut avoir des conséquences très importante sur tout le reste.
Et on est beaucoup a penser que l'automatisation, si c'est très bien en terme d'exploitation (ça permet souvent d'éviter justement des erreurs humaines fréquentes), ça a aussi un revers, quand ça foire (rarement), ben ça foire méchamment. Du coup, faut vraiment faire attention dans la façon dont on automatise certains process.
Après, je ne connais pas en détail leur infra, mais je sais qu'il sont à l'origine de pas mal de travaux sur l'utilisation de BGP pour l'interconnexion de datacenter, par exemple, cette RFC : https://datatracker.ietf.org/doc/html/rfc7938
Voir aussi :
https://www.ipspace.net/Data_Center_BGP/BGP_Fabric_Routing_Protocol
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
[^] # Re: encore BGP ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
On peut penser aussi qu'un tel système ne devrait pas être aussi sensible à l'erreur. Par exemple, le TTL du DNS permet d'éviter que la perte d'un serveur temporaire entraine une cascade de panne.
BGP est peut être trop permissif, ou les nœuds acceptent trop facilement des confs en erreur.
"La première sécurité est la liberté"
[^] # Re: encore BGP ?
Posté par claudex . Évalué à 4.
Mais par contre, ça empêche la correction d'une erreur rapidement, ce qui a aussi un impact négatif (et qui fait que beaucoup de monde utilise un TTL très bas, ce qui ruine son avantage).
Je ne comprends pas vraiment ce que tu veux dire, de ce point de vu, tous les protocoles de routage dynamiques ont le même problème. Et je ne vois pas trop comment tu veux vérifier que quand un peer retire une annonce, il ment.
Encore une fois, dans ce cas, de ce que j'en ai compris, BGP a fonctionné exactement comme prévu. C'est juste que quand un DC perd la connectivité, il a annonce qu'il n'est plus joignable. Ce qui est un comportement attendu. C'est juste que c'est arrivé à tous les DC en même temps.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: encore BGP ?
Posté par claudex . Évalué à 4.
Par exemple une panne de tld, sans mise en cause de bgp.
https://twitter.com/bortzmeyer/status/1446081609799700483?t=NKRjC0WXfiyradxjAhQeVg&s=19
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: encore BGP ?
Posté par Big Pete . Évalué à 3.
Ben, encore une fois, c'est sa nature même de protocole d'échange de route. La force de BGP c'est de pouvoir passer à l'échelle sur des réseaux énormes, typiquement, c'est même sa raison d'être, et le fait qu'il est utilisé à large échelle pour gérer le routage sur internet. Et globalement, ça marche plutôt bien. Dans le cas de Facebook, leur réseau interne est tellement gros qu'ils en viennent aussi a utiliser BGP pour gérer le routage sur leur backbone, là ou d'autres utiliseraient des IGP comme OSPF ou IS-IS, mais ces protocoles réseau ne passent plus en terme de temps de convergence et de stabilité quand la topologie deviens trop complexe.
Après, ils disent qu'ils ont un outil de vérification des conf réseau qui normalement n'aurait pas du laisser passé ça, mais bon, on en sait pas vraiment plus. Le diable est dans les détail. Mais, amha, le probléme c'est pas le protocole en soi, c'est plutôt la façon dont il est utilisé, les process (automatique ou pas), l'architecture du réseau (séparation stricte de l'exploitation et de la prod), etc …
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
[^] # Re: encore BGP ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Comme tous les outils de vérification, ça vérifie ce qui est prévu (donc connu ou envisagé.) Et dans normalement on sent la supposition …qui me laisse penser qu'il y a un concours de circonstances malencontreuses (certains cas ont probablement été testés séparément, mais comme un malheur de Murphy n'arrive jamais seul ils l'ont eu dans l'os.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: encore BGP ?
Posté par Big Pete . Évalué à 5.
Non mais sometimes shit happen. Limite, ça se comprend, ça veut pas dire que c'est normal, qu'il y a pas du boulot pour corriger le tir, que ce soit sur l'aspect purement technique que sur le pilotage des opérations. Ce qui n'est vraiment pas normal, c'est que la même opération ai pu mettre par terre a la fois le réseau de production, et le réseau de maintenance, ce qu'on appelle dans le jargon, le réseau out-of-band, c'est a dire un réseau normalement physiquement séparé du réseau de production et dont la fonction est justement de pouvoir passer des commandes sur les routeurs et autres équipement réseau quand le réseau principal est par terre. Le réseau de secours quoi. En gros c'est ce qui a fait que l'incident au lieu de durer quelque minutes à durer quelque heures, et qui a transformé un "j'ai senti un trouble dans la force" en une première page sur tous les canards de la planète.
ça c'est vraiment pas beau. Et quand je postais plus haut la référence a Geoff Huston qui disait en gros, heureusement qu'il font pas des centrales nucléaires chez Facebook, ben, effectivement, ce genre de pépin, aurait tendance a renforcer son point de vue. Après, on sait pas tout, mais dans l'absolu, c'est sur qu'il y a un gros probléme a ce niveau que soit un truc fondamental (defective by design) ou une évolution technique qui a pu rendu leur réseau OOB vulnérable sans qu'ils s'en aperçoivent.
source : https://texasnewstoday.com/facebook-blames-our-own-creation-engineering-error-for-global-outage/488258/
Le truc à savoir aussi, c'est que techniquement dans le monde du réseau, Facebook c'est un peu une référence sur le plan technique, autant je ne peux pas les piffer sur le plan éthique et sur leur modèle d'affaire, autant il me semble qu'il sont reconnu pour être des pointures dans le domaine des réseaux et des infrastructure datacenter, du moins, de ce que j'en sais. C'est d'autant plus étonnant, et serait d'autant plus intéressant d'avoir le fin mot de l'histoire, pas simplement sur la root cause de l’événement, mais sur le fait que le réseau OOB était ko aussi.
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
[^] # Re: encore BGP ?
Posté par claudex . Évalué à 6.
Perso, je parie que c'est pour une des deux raisons suivantes (attention, ce n'est que de la pure spéculation, je n'ai pas d'info là dessus):
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: encore BGP ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 07 octobre 2021 à 16:24.
Voilà ! Je comprends le point soulevé par big Pete, mais je soupçonne comme toi (sans avoir pu me le formuler aussi clairement) un fort couplage de l'oob. Quand à être une référence en terme de réseau, j'ai toujours vu pour ma part qu'ils ont de la r&d et de la comm' sur le sujet…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: encore BGP ?
Posté par claudex . Évalué à 4.
Oui, après, il y a plusieurs méthodes qui permettent d'éviter que ça ait un impact sur toute l'infra d'un coup. Mais dans ce cas, ce n'était pas une commande qui était censé avoir un impact.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.