Thread by @GuillaumeRozier

Comment Facebook, Insta et WhatsApp ont pu tomber ?
Cloudflare (qui fournit un CDN très utilisé), a écrit un article complet qui détaille ce qui s’est passé hier soir. blog.cloudflare.com/october-2021-f…

J’essaye de vous le résumer en Français #Thread ⤵

Tout d'abord, je précise que je ne suis pas spécialiste. S'il y a des incohérences ou erreurs, n'hésitez pas à les indiquer en commentaire !

En fait, un DNS c'est quoi ? Ça signifie Domain Name Service. Ce sont des serveurs qui font la traduction entre une adresse humaine ("Facebook.com"), et une adresse informatique ("216.3.128.12"). Un peu comme un GPS traduit une adresse postale en coordonnées géo.

Hier, à 16:51 UTC, Cloudflare découvre que les serveurs DNS de Facebook sont injoignables, ainsi que la plupart des adresses IPs de leurs infrastructures. Qu'est-ce que cela veut dire ?

Ça signifie tout simplement, que lorsque vous tapez "Facebook.com" dans votre navigateur, personne ne sait où se trouvent leurs serveurs. Impossible de charger le contenu, les pages HTML, les images. Facebook est rayé de la carte, introuvable.

Comment c'est possible ? Pour cela, il faut s'intéresser à la manière dont internet est construit. C'est en fait un ensemble de réseaux autonomes (AS, Autonomous Systems) qui sont connectés entre eux. Chaque AS correspond à une organisation, ou grosse entreprise comme Facebook.

Il est nécessaire que ces réseaux se parlent et se connaissent, pour qu'ils puissent échanger des informations. Pour pouvoir accéder à Facebook, il faut que votre box, et tous les routeurs entre Facebook et vous puissent savoir à qui (quel routeur) envoyer vos communications.

C'est là qu'intervient eBGP (Border Gateway Protocol) ! C'est un protocole qui permet ça. Les gros routeurs qui font fonctionner internet échangent régulièrement entre eux, pour pouvoir connaitre la liste de leurs voisins, et les chemins les plus rapides pour aller à tel endroit.

eBGP permet à un réseau (par exemple Facebook) de se faire connaître auprès des autres réseaux. Et d'exister. Un peu comme si vous indiquiez à vos voisins qui vous êtes, pour qu'ils vous transmettent votre courrier s'ils voient passer des lettres qui vous sont destinées.

Par exemple ici, imaginons que AS1 c'est vous, et AS3 c'est Facebook. eBGP permet à chaque AS de se faire connaître auprès des voisins. Grâce à ce protocole, les routeurs vont trouver le chemin le plus rapide pour atteindre AS5. Si ce chemin est coupé, ils vont trouver un autre.

Les AS communiquent régulièrement entre eux via des messages eBGP ("e" pour external, il existe iBGP pour gérer le routage *dans* un réseau), qui peuvent annoncer la modification d'un réseau (comme l'ajout d'un routeur, donc d'un voisin, ou sa suppression).

A 16:58 UTC, Facebook a arrêté d'annoncer l'existence de ses serveurs DNS (via BGP, donc) à ses voisins. En gros, d'un coup, on ne savait où se situait le GPS qui faisait la traduction entre "Facebook.com" et une adresse informatique IP.

Cloudflare conserve quasiment tous les messages BGP afin de pouvoir mettre à jour le "schéma" d'internet, pour acheminer les communications correctement. À 15:50 UTC, ils ont reçu de Facebook une vague de messages BGP indiquant... la suppression d'un réseau.

En clair, Facebook s'est tout simplement lui même supprimé d'internet. Ils ont indiqué à tous leurs voisins de les oublier, ils leur ont indiqué qu'ils n'existaient plus, et ont arrêté de fournir le GPS qui permet de trouver ses serveurs.

Ainsi, hier, lorsque vous vouliez charger "Facebook.com", votre navigateur vous demandait si vous n'aviez pas fait une faute d'orthographe. Tout simplement car votre DNS ne connaissant pas ce nom, car les serveurs DNS de Facebook étaient rayés de la carte.

Reste à savoir pourquoi ces messages BGP ont été envoyés par Facebook. Pas de communication officielle, mais d’après des messages sur Reddit, cela pourrait être la cause d’une mise à jour automatique de routeurs entrainant une mauvaise configuration.

Pourquoi la résolution a été aussi longue ? Pas de communication officielle non plus, mais cela a probablement nécessité une intervention manuelle et un accès physique aux serveurs pour les re-configurer.

Tous les outils internes de Facebook étaient aussi concernés, donc communication difficile entre les équipes.

Une rumeur sur Reddit indique que des employés auraient eu du mal à utiliser leur badge pour entrer dans les bâtiments (si c’est vrai, est-est-ce lié à la panne ?).

Bref, c’est probablement une des pannes numériques les plus importantes depuis l’apparition d’internet (au moins en termes d’impact financier), qui va faire réfléchir beaucoup d’Ops avant de toucher à la configuration d’un routeur, ou BGP. 😂

Autre question : pourquoi d’autres sites, totalement indépendants de Facebook (comme Twitter) ont subi des ralentissements ?
Tout simplement car les DNS (par exemple Cloudflare) ont été submergés de requêtes.

Les applications connectées à Facebook, et les humains souhaitant consulter Facebook, n’aiment pas avoir d’erreur. Ils ré-essayent donc, en boucle. Et submergent au passage les DNS.

Ici le nombre de requêtes liées à Facebook captées par Cloudflare. Énorme pic à partir de 16h UTC

Donc le DNS que vous utilisez (probablement fourni par : Orange, SFR, Bouygues, Free, Google, ou Cloudflare) était ralenti, indirectement à cause de Facebook.

Conséquence : lorsque vous chargiez une page, il fallait plus de temps pour obtenir l’adresse de son contenu.

Amusant, mais attendu : l’utilisation de services concurrents (Twitter, Signal, Telegram, Tiktok) a augmenté à partir de 15:45 UTC.

Au travers d’un exercice de transparence, Facebook publie un article apportant quelques éléments nouveaux sur la panne.

engineering.fb.com/2021/10/05/net…

Globalement, Cloudflare avait vu juste. Mais c’est un peu plus tricky.

Facebook réalise régulièrement des maintenances, en éteignant une petite partie de son réseau pour mettre à jour des logiciels, changer du matériel, augmenter la capacité.

Hier, durant une de ces opérations de maintenance, ils ont voulu évaluer la capacité de leur réseau en tapant une commande. Malheureusement celle-ci a complètement éteint le réseau de Facebook (“backbone”), mettant ainsi hors ligne les serveurs.

Leurs systèmes comportent normalement un outil d’audit automatique qui détecte et évite ce genre de commande. Malheureusement il comporte un bug, et n’a pas intercepté celle-ci.

On ne connaissait donc pas cette partie (le fait qu’un ingénieur ait déconnecté les serveurs de Facebook par erreur).

Suite à cela, une seconde erreur est arrivée et a aggravé la situation. C’est celle-ci, qui est la plus grave, et que Cloudflare avait bien décrit.

Comme évoqué en début de thread, Facebook dispose de serveurs DNS pour convertir les adresses humaines en adresse IP vers les serveurs de données. Ces DNS sont les seuls qui “s’exposent” à nous, ils se font connaître grâce à des messages BGP.

Or, pour “assurer un service fiable”, ces serveurs DNS sont conçus pour arrêter d’émettre ces messages BGP dès lors qu’ils n’arrivent pas à contacter les serveurs de données.

Ces serveurs de données ayant été éteints par inadvertance, les serveurs DNS se sont donc automatiquement... coupés du monde.

Facebook indique qu’il était très difficile pour ses ingénieurs d’investiguer car :
1. Les data centers étaient inaccessibles par les moyens habituels (oui, ils étaient éteints)
2. Leurs outils d’investigation ne fonctionnaient plus… car les DNS s’étaient coupés du monde !

Finalement, ils ont dû dépêcher une équipe d’ingénieurs sur place pour redémarrer et reconfigurer les serveurs. Mais les data centers sont conçus pour être très difficiles d’accès pour des raisons de sécurité, et la connexion physique aux serveurs est volontairement complexe.

Je m’arrête là et vous laisse lire l’article de Facebook pour plus de détails. Merci à eux pour la transparence, ça va permettre à tous les sys admin / ops d’apprendre et d’éviter d’autres pannes à l’avenir.