Aujourd’hui, CenturyLink/Level(3), un important fournisseur d’accès Internet et de bande passante, a connu une panne importante qui a affecté certains clients de Cloudflare, ainsi qu’un nombre important d’autres services et fournisseurs officiant sur Internet. Pendant que nous attendons l’analyse post-incident de CenturyLink/Level(3), je tenais à présenter le déroulement chronologique de ce que nous avons constaté, la manière dont les systèmes de Cloudflare ont contourné le problème, les raisons pour lesquelles certains de nos clients étaient encore affectés malgré nos mesures d’atténuation et ce qui semble être la probable cause première du problème.
Augmentation des erreurs
À 10 h 03 UTC, nos systèmes de surveillance ont commencé à observer un nombre croissant d’erreurs sur les serveurs d’origine de nos clients. Ces erreurs apparaissaient sous la forme d’erreurs 522 et indiquaient qu’il existait un problème de connexion entre le réseau de Cloudflare et les lieux d’hébergement des applications de nos clients.
Cloudflare est connecté à CenturyLink/Level(3) par l’intermédiaire d’un ensemble vaste et diversifié d’opérateurs réseau. Lorsque nous constatons une augmentation des erreurs de la part d’un opérateur réseau, nos systèmes tentent automatiquement d’atteindre les applications de nos clients via d’autres fournisseurs. Compte tenu du nombre de fournisseurs auxquels nous avons accès, nous sommes généralement en mesure de continuer le routage du trafic, même lorsqu’un fournisseur rencontre un problème.
Atténuations automatiques
Dans le cas qui nous occupe, quelques secondes après l’augmentation du nombre d’erreurs 522, nos systèmes ont automatiquement redirigé le trafic de CenturyLink/Level(3) vers d’autres opérateurs réseau auxquels nous sommes reliés, notamment Cogent, NTT, GTT, Telia et Tata.
En outre, à partir de 10 h 09 UTC, notre centre d’opérations réseau a été alerté et notre équipe a commencé à prendre des mesures supplémentaires afin d’atténuer les problèmes que nos systèmes automatisés n’étaient pas en mesure de traiter automatiquement. Malgré la perte de CenturyLink/Level(3), l’un de nos opérateurs réseau, nous avons réussi à maintenir la fluidité du trafic sur l’ensemble de notre réseau pour la plupart de nos clients et utilisateurs finaux.
Le graphique ci-dessous montre le trafic entre le réseau de Cloudflare et six grands opérateurs de niveau 1 figurant dans la liste des opérateurs réseau auxquels nous nous connectons. La partie rouge montre le trafic de CenturyLink/Level(3), qui a chuté pour devenir quasiment nul pendant l’incident. Vous pouvez également constater de quelle manière nous avons automatiquement redirigé le trafic vers d’autres opérateurs réseau pendant l’incident afin d’atténuer l’impact de ce dernier et de garantir la continuité du trafic.
Le graphique suivant présente les erreurs 522 (qui indiquent notre incapacité à atteindre les applications de nos clients) sur notre réseau au moment de l’incident.
Le pic important de 10 h 03 UTC correspond à la défaillance du réseau CenturyLink/Level(3). Nos systèmes automatisés sont immédiatement intervenus pour tenter de rediriger et de rééquilibrer le trafic vers d’autres opérateurs réseau, ce qui a permis de réduire immédiatement les erreurs de moitié, puis de ramener ces dernières à environ 25 % de la valeur du pic suite à l’optimisation automatique des chemins.
Entre 10 h 03 UTC et 10 h 11 UTC, nos systèmes ont automatiquement désactivé CenturyLink/Level(3) dans les 48 villes dans lesquelles nous sommes connectés à ce dernier et ont redirigé le trafic vers d’autres opérateurs réseau. Nos systèmes prennent en compte la capacité des autres opérateurs avant de rediriger le trafic afin d’éviter les pannes en cascade. C’est pourquoi le basculement sur systèmes redondants, bien qu’automatique, n’est pas instantané dans tous les lieux. Notre équipe a pu appliquer d’autres mesures d’atténuation manuelles afin de réduire encore le nombre d’erreurs de 5 %.
Pourquoi les erreurs ne sont-elles pas tombées à zéro ?
Malheureusement, nous constations toujours un nombre élevé d’erreurs indiquant que nous n’étions toujours pas en mesure de joindre certains clients. CenturyLink/Level(3) étant l’un des principaux opérateurs réseau du monde, de nombreux fournisseurs d’hébergement ne sont connectés à Internet que par l’intermédiaire de leur réseau.
à une « autoroute », la situation revient à ne disposer que d’une seule bretelle de sortie pour desservir une ville. Si la sortie est bloquée, il n’existe aucun moyen d’atteindre la ville. Le problème s’est même accentué dans certains cas, car le réseau de CenturyLink/Level(3) ne reconnaissait pas les suppressions des routes et continuait à annoncer des routes vers des réseaux comme celui de Cloudflare, alors que ces dernières avaient été supprimées. Nous n’avions par conséquent aucun moyen d’accéder aux applications des clients dont l’unique connexion à Internet s’effectuait par l’intermédiaire de CenturyLink/Level(3), ou au sein d’un contexte dans lequel CenturyLink/Level(3) continuait d’annoncer de manière erronée la présence de routes malgré leur suppression. Ces clients ont donc continué à voir des erreurs jusqu’à la résolution du problème chez CenturyLink/Level(3), soit vers 14 h 30 UTC.
Le même problème se posait de l’autre côté du réseau (chez les utilisateurs « consommateurs »). Les particuliers doivent disposer d’une bretelle d’accès à l’autoroute que représente Internet. Par essence, cette bretelle d’accès à Internet constitue d’ailleurs ce que votre FAI vous fournit et CenturyLink est l’un des plus grands fournisseurs d’accès à Internet des États-Unis.
Comme cette panne semblait avoir mis hors ligne l’ensemble du réseau de CenturyLink/Level(3), les particuliers clients de CenturyLink ne pouvaient pas joindre Cloudflare ni tout autre fournisseur d’accès à Internet tant que le problème n’avait pas été résolu. Nous avons constaté une baisse de 3,5 % du trafic mondial pendant la panne, qui était presque entièrement due à une interruption quasi complète du service de FAI proposé par CenturyLink aux États-Unis.
Que s'est-il donc passé ici ?
Nous ne saurons pas exactement ce qui s’est passé tant que CenturyLink/Level(3) n’a pas publié d’analyse post-incident, mais nous pouvons obtenir certains indices en examinant les annonces BGP et la manière dont elles se sont propagées sur Internet pendant la panne. L’acronyme BGP signifie Border Gateway Protocol et désigne un protocole d’échange de route externe. C’est ainsi que les routeurs connectés à Internet s’annoncent les uns aux autres les adresses IP situées derrière eux et donc le trafic qu’ils devraient recevoir.
On constate un nombre important de mises à jour BGP à partir de 10 h 04 UTC. Une mise à jour BGP représente le signal qu’un routeur émet pour indiquer qu’une route a changé ou n’est plus disponible. Dans des conditions normales, le trafic Internet voit passer environ 1,5 Mo à 2 Mo de mises à jour BGP toutes les 15 minutes Au début de l’incident, ce nombre a atteint un pic de plus de 26 Mo de mises à jour BGP par période de 15 minutes. Ce nombre est par ailleurs resté élevé tout au long de l’incident.
Ces mises à jour révèlent l’instabilité des routes BGP à l’intérieur de l’infrastructure de CenturyLink/Level(3). La question est de connaître l’origine de cette instabilité. La mise à jour du statut de CenturyLink/Level(3) propose quelques indices et désigne une mise à jour de Flowspec comme cause principale.
Qu'est-ce que Flowspec ?
Dans la mise à jour de CenturyLink/Level(3), le FAI mentionne qu’une mauvaise règle de Flowspec est à l’origine du problème. Mais qu’est-ce que Flowspec ? Flowspec est une extension de BGP permettant de distribuer facilement des règles de pare-feu sur un réseau, voire entre réseaux, par l’intermédiaire de BGP. Cet outil puissant permet de distribuer efficacement les règles sur l’ensemble d’un réseau de manière presque instantanée. Il s’agit donc d’un outil parfait pour réagir rapidement à une attaque, par exemple, mais qui peut se révéler dangereux en cas d’erreur.
À nos débuts, Cloudflare avait l’habitude d’utiliser Flowspec pour distribuer les règles de pare-feu afin, par exemple, d’atténuer les attaques DDoS à grande échelle sur le réseau. Nous avons subi notre propre panne
provoquée par Flowspec il y a plus de 7 ans.. Nous n’utilisons plus ce protocole depuis, mais il s’agit toujours d’une méthode courante de distribution des règles de pare-feu sur le réseau.
Nous ne pouvons que spéculer sur ce qui s’est passé à CenturyLink/Level(3), mais l’un des scénarios plausibles repose sur l’émission par CenturyLink/Level(3) d’une commande Flowspec afin d’essayer de bloquer une attaque ou toute autre agression dirigée contre son réseau Le rapport de situation indique que la règle Flowspec a empêché l’annonce de BGP lui-même. Nous n’avons aucun moyen de savoir ce qu’était cette règle Flowspec, mais en voici une au format Juniper qui aurait été capable de bloquer toutes les communications BGP sur leur réseau.
route DISCARD-BGP {
match {
protocol tcp;
destination-port 179;
}
then discard;
}
Pourquoi tant de mises à jour ?
Un mystère demeure toutefois, à savoir la raison pour laquelle le nombre de mises à jour BGP mondiales est resté élevé tout au long de l’incident. Si la règle bloquait effectivement BGP, on aurait alors pu s’attendre à voir une augmentation des annonces BGP dans un premier temps, avant de voir ce nombre revenir’ à la normale par la suite.
L’une des explications possibles serait que la règle Flowspec incriminée est arrivée à la fin d’une longue liste de mises à jour BGP. Si tel était le cas, il est alors possible que chaque routeur situé sur le réseau de CenturyLink/Level(3) ait reçu la règle Flowspec. Les routeurs auraient alors bloqué BGP, ce qui les aurait conduits à ne plus recevoir la règle. Ils auraient recommencé à revenir en arrière, en repassant par toutes les règles BGP jusqu’à arriver à nouveau à la règle Flowspec incriminée. BGP aurait alors de nouveau été bloqué, la règle Flowspec n’aurait plus été reçue et ainsi de suite. La boucle n’aurait cessé de se reproduire.
L’un des problèmes résultant de cette boucle est qu’à chaque cycle, la file d’attente des mises à jour BGP aurait continué à s’allonger au sein du réseau de CenturyLink/Level(3). La boucle aurait ainsi pu se prolonger, jusqu’au point où la mémoire et le processeur des routeurs se seraient retrouvés en surcharge, ce qui aurait entraîné un certain nombre de difficultés supplémentaires pour remettre le réseau en ligne.
Pourquoi a-t-il fallu tant de temps pour réparer ?
Il s’agissait d’une panne importante affectant Internet au niveau mondial et l’équipe de CenturyLink/Level(3) en a sans aucun doute été immédiatement alertée. Il s’agit d’un opérateur très sophistiqué, doté d’un centre d’opérations réseau (Network Operations Center, NOC) d’envergure internationale. Alors pourquoi a-t-il fallu plus de quatre heures pour résoudre le problème ?
Encore une fois, nous ne pouvons qu’émettre des spéculations. Premièrement, il est possible que la règle Flowspec et la charge importante imposée aux routeurs par le grand nombre de mises à jour BGP leur aient rendu difficile la connexion à leurs propres interfaces. Plusieurs des autres opérateurs de niveau 1 sont intervenus, à la demande de CenturyLink/Level(3) semble-t-il, afin de supprimer les sessions de peering avec leurs réseaux. Cette opération aurait limité le nombre d’annonces BGP reçues par le réseau CenturyLink/Level(3) et lui aurait donné le temps de récupérer.
Deuxièmement, il se peut également que la règle Flowspec n’ait pas été émise par l’opérateur CenturyLink/Level(3) proprement dit, mais plutôt par l’un de ses clients. De nombreux opérateurs réseau autorisent le peering Flowspec. Ce protocole peut être un outil puissant pour les clients en aval qui souhaitent bloquer le trafic en cas d’attaque, mais il peut rendre la détection d’une règle Flowspec incorrecte beaucoup plus difficile lorsque quelque chose ne va pas.
Enfin, le fait que de tels problèmes se produisent tôt un dimanche matin n’arrange jamais les choses. Les réseaux de la taille et de l’échelle de celui de CenturyLink/Level(3) sont extrêmement compliqués et il peut arriver que de tels incidents se produisent. Nous avons apprécié que leur équipe nous informe du déroulement de l’incident tout au long de ce dernier. #hugops