Résumé

  • Une tâche de nettoyage a envoyé le paramètre pending_delete sans valeur. L’API Addressing l’a interprété comme une demande portant sur tous les préfixes BYOIP ; la tâche a ensuite supprimé des préfixes et des liaisons de service associées.
  • Environ 1 100 préfixes ont été retirés. Quelque 800 ont pu être rétablis par une nouvelle annonce ; près de 300 avaient aussi perdu leur configuration de service en périphérie et ont exigé une restauration ultérieure à l’échelle du réseau. Le retour de la route ne constituait qu’une étape du rétablissement.

Le second temps du rétablissement

L’incident raconté par Cloudflare le 20 février 2026 peut se résumer à une panne BGP. Le détail décisif vient après le retour des routes : pour certains préfixes clients, l’annonce est revenue alors que les systèmes périphériques de Cloudflare ne possédaient plus les liaisons indiquant quel service devait traiter le trafic. La route est revenue avant le service.

Cette distinction est concrète. Un préfixe peut être enregistré au nom d’un client, autorisé à être annoncé par un fournisseur, présent dans la base d’adressage de celui-ci, annoncé en BGP, lié à un produit, puis configuré sur ses machines périphériques. Ces états sont liés, mais aucun ne remplace les autres. Une route visible ne prouve pas qu’un paquet arrive au bon service.

Selon le post-mortem, une tâche périodique devait automatiser la suppression des préfixes qu’un client souhaitait retirer de BYOIP. Elle a transmis pending_delete sans valeur. L’implémentation décrite ne sélectionnait les suppressions en attente que si la valeur textuelle du paramètre n’était pas vide. Sans valeur, l’API renvoyait donc tous les préfixes BYOIP. La tâche les a traités comme des éléments à supprimer et a également retiré des objets dépendants, dont des liaisons de service.

Cloudflare affirme qu’il ne s’agissait pas d’une attaque. La nouvelle version de l’API Addressing a été déployée à 17 h 46 UTC ; la tâche a commencé à s’exécuter dix minutes plus tard et les retraits de routes ont débuté. Les ingénieurs ont identifié puis arrêté le processus à 18 h 46. Environ 1 100 préfixes ont été retirés pendant cette période, soit 25 % des 4 306 préfixes BYOIP annoncés mondialement selon Cloudflare. Le rapport décrit aussi 6 500 préfixes visibles depuis un pair : ce dénominateur différent ne doit pas être confondu avec le total BYOIP mondial.

Le déploiement progressif a limité le périmètre de l’incident : le changement n’avait pas atteint tous les clients quand il a été interrompu. Cela montre l’intérêt d’un déploiement par étapes, sans en faire pour autant une procédure de reprise.

Une annonce n’est pas un service

La documentation de Cloudflare distingue l’annonce BGP, qui attire le trafic d’un préfixe vers son réseau, de la liaison de service, qui rattache ce trafic à un produit comme CDN, Spectrum ou Magic Transit. Pour certains usages CDN, une carte d’adresses ajoute encore un autre état. Si une automatisation supprime à la fois le préfixe et ses liaisons, annoncer de nouveau la route peut restaurer la joignabilité vers le réseau du fournisseur sans rétablir le chemin produit en périphérie.

La solution proposée dans le tableau de bord était donc conditionnelle. À 19 h 19 UTC, Cloudflare a demandé aux clients de réannoncer leurs préfixes. Vers 20 h 20, environ 800 avaient été rétablis. Près de 300 ne pouvaient pas être réparés par une simple bascule : leurs configurations de service avaient été retirées des systèmes périphériques. Les clients ne pouvaient pas recréer une liaison absente de la configuration accessible à leur compte. Les ingénieurs ont dû restaurer ces états, puis diffuser une configuration globale, opération achevée à 23 h 03 UTC. Cloudflare a indiqué une durée totale de six heures et sept minutes.

Le rapport public ne donne ni le nombre de clients, ni la géographie, ni les pertes de revenus ou les montants dus au titre des SLA. Il décrit toutefois des parcours distincts : retrait de route seulement, suppression partielle de liaisons, ou disparition de toutes les liaisons de service. Une même « panne BYOIP » recouvrait donc plusieurs délais et responsables de reprise.

Le site one.one.one.one a également affiché des erreurs HTTP 403. Cloudflare précise que la résolution DNS du résolveur public 1.1.1.1, y compris via DNS-over-HTTPS, n’a pas été affectée. La panne visible du site témoignait de l’impact sur une surface hébergée en BYOIP, pas d’un arrêt du résolveur.

Le chemin de service fait partie de la route

Cloudflare décrit l’API Addressing comme un jeu de données faisant autorité, dont les changements étaient répercutés sur le réseau mondial. Des requêtes client alimentaient des bases et des workflows modifiant les annonces et les liaisons de produits. Le même état stocké représentait à la fois la configuration voulue par le client et les actions opérationnelles. Cloudflare a expliqué que cette conception compliquait le retour arrière : les ingénieurs devaient utiliser des instantanés de base de données plutôt que comparer l’état souhaité à l’état observé.

La lacune de test était tout aussi précise. Les jeux de données de recette et les simulations se sont révélés insuffisants. L’équipe avait testé le parcours de libre-service effectué par le client, mais pas un service de tâches séparé modifiant des données sans demande explicite. Une interface peut être sûre tandis qu’un traitement planifié réutilisant son API ne l’est pas. Tester seulement l’utilisateur laisse hors du modèle le principal d’automatisation.

Les mesures annoncées dépassent donc la vérification d’un paramètre : normaliser les schémas d’API, séparer configuration et état opérationnel, déployer des instantanés sous contrôle de santé, arrêter automatiquement une propagation dégradée et couper les retraits trop rapides ou trop étendus. Cloudflare évoquait aussi la santé réelle des services clients comme signal. Le post-mortem de février annonçait ces travaux ; il ne prouve pas leur achèvement ultérieur.

La promesse commerciale de BYOIP est de conserver une identité d’adresse reconnaissable tout en utilisant les services d’un fournisseur. Le contrat opérationnel est plus nuancé : le client peut posséder le bloc et autoriser son annonce, tandis que le fournisseur exploite le plan de contrôle qui retire la route, choisit le produit et distribue la configuration. Un actif portable peut donc dépendre d’un état que son propriétaire ne sait pas rétablir seul.

Ce n’est pas un argument contre le routage géré. C’est une raison de définir la continuité au niveau du service. Cloudflare indique qu’une réponse API réussie confirme l’enregistrement d’une requête ; la propagation de route demande encore du temps. Sa documentation demande séparément de préparer les liaisons de service avant l’annonce d’un préfixe de production. Un accusé de réception et un service opérationnel sont deux preuves différentes.

Ce qu’une promesse de continuité doit démontrer

Le client ne devrait pas seulement demander si le fournisseur sait annoncer un préfixe. Il doit pouvoir savoir quel état a échoué et quelle autorité peut le réparer. Un calendrier de continuité devrait distinguer quatre jalons : arrêt de la tâche dangereuse ; visibilité de la route dans des observateurs externes ; rétablissement des liaisons et de la configuration périphérique ; réussite du trafic applicatif. Chaque jalon a son responsable et son horloge.

L’incident fournit un test d’acceptation utile : simuler le retour de la route alors que la liaison de service manque. Le fournisseur sait-il détecter cet état ? Peut-il restaurer la configuration d’un client sans retour arrière risqué de toute la base ? La santé du service, et non le seul nombre de routes, peut-elle arrêter un déploiement ? Quels changements le client garde-t-il pendant un gel d’API ?

Une seconde annonce peut faire partie du plan du client, mais elle ne remplace pas universellement la reprise du fournisseur. Les recommandations opérationnelles de Cloudflare rappellent que les annonces qui se chevauchent et la préférence de route doivent être pilotées avec soin. Une route de secours n’aide que si l’autorisation d’origine, le traitement du trafic et le comportement du service ont été testés ensemble. Attirer des paquets vers un réseau dépourvu de l’état applicatif ne fait que déplacer la panne.

La conclusion est mesurable : une adresse identifie une ressource ; une route annonce une possibilité de joignabilité ; une liaison choisit le traitement du trafic ; un service vivant est un résultat. Le reporting de continuité ne devrait pas fusionner ces couches dans un seul voyant vert. Le retour du préfixe était une avancée. Ce n’était pas la fin du rétablissement.

Sources