Крупный сбой Cloudflare: как отказ BGP парализовал часть интернета

20 февраля 2026 года в 17:48 по UTC в Cloudflare произошел сбой обслуживания, когда часть клиентов, использующих услугу Cloudflare "Принеси свой собственный IP-адрес" (Bring Your Own IP, BYOIP), увидели, что их маршруты в Интернет были отозваны через протокол BGP (Border Gateway Protocol).

Проблема не была вызвана, прямо или косвенно, кибератакой или каким-либо злонамеренным действием. Эта проблема была вызвана изменением, которое Cloudflare внесла в то, как наша сеть управляет IP-адресами, подключенными через конвейер BYOIP. Это изменение привело к тому, что Cloudflare непреднамеренно отозвала префиксы клиентов.

Для некоторых клиентов BYOIP это привело к недоступности их сервисов и приложений из Интернета, вызывая таймауты и ошибки подключения во всех их развертываниях Cloudflare, использующих BYOIP. Подмножество 1.1.1.1, в частности наш адрес назначения one.one.one.one, также пострадало. Общая продолжительность инцидента составила 6 часов и 7 минут, большая часть этого времени была потрачена на восстановление конфигураций префиксов до состояния, предшествовавшего изменению.

Инженеры Cloudflare откатили изменение, и отзыв префиксов прекратился, как только мы начали наблюдать сбои. Однако до того, как инженеры смогли откатить изменение, из сети Cloudflare было отозвано около 1100 префиксов BYOIP. Некоторые клиенты смогли восстановить свой сервис самостоятельно, используя панель управления Cloudflare для повторной анонсации своих IP-адресов. Мы устранили инцидент, когда восстановили все конфигурации префиксов.

Мы приносим извинения за последствия для наших клиентов. Сегодня мы вас подвели. Этот пост представляет собой подробный рассказ о том, что именно произошло, и о том, какие системы и процессы дали сбой. Мы также изложим шаги, которые мы предпринимаем, чтобы предотвратить повторение подобных простоев.

На этом графике показано количество префиксов, анонсированных Cloudflare во время инцидента соседу по BGP, что коррелирует с воздействием, поскольку префиксы, которые не были анонсированы, были недоступны в Интернете:

Из общего количества 6500 префиксов, анонсированных этому пиру, 4306 были префиксами BYOIP. Эти префиксы BYOIP анонсируются каждому пиру и представляют все префиксы BYOIP, которые мы анонсируем глобально.

Во время инцидента с 17:56 до 18:46 UTC было отозвано 1100 префиксов из общего числа 6500. Из 4306 общих префиксов BYOIP 25% префиксов BYOIP было отозвано непреднамеренно. Мы смогли обнаружить воздействие на one.one.one.one и откатить проблемное изменение до того, как были затронуты другие префиксы. В 19:19 UTC мы опубликовали руководство для клиентов о том, что они смогут самостоятельно устранить последствия этого инцидента, перейдя в панель управления Cloudflare и повторно анонсировав свои префиксы.

Cloudflare смогла откатить многие изменения анонса около 20:20 UTC, что привело к восстановлению 800 префиксов. Оставалось еще около 300 префиксов, которые не удалось восстановить через панель управления, потому что конфигурации служб для этих префиксов были удалены с граничных серверов из-за программной ошибки. Эти префиксы были восстановлены вручную инженерами Cloudflare в 23:03 UTC.

Этот инцидент не затронул всех клиентов BYOIP, потому что изменение конфигурации применялось итеративно, а не мгновенно для всех клиентов BYOIP. Как только выяснилось, что изменение конфигурации вызывает воздействие, оно было отменено до того, как пострадали все клиенты.

Затронутые клиенты BYOIP сначала столкнулись с поведением, называемым "Охота за BGP-маршрутом" (BGP Path Hunting). В этом состоянии соединения конечных пользователей проходят через сети в поисках маршрута к целевому IP-адресу. Такое поведение будет сохраняться до тех пор, пока открытое соединение не превысит таймаут и не завершится ошибкой. Пока префикс не будет анонсирован где-либо, клиенты будут продолжать наблюдать этот режим отказа. Этот сценарий "цикл до отказа" затронул любой продукт, который использует BYOIP для анонсации в Интернет. One.one.one.one, который является подмножеством 1.1.1.1, — это префикс, подключенный как префикс BYOIP, и он пострадал таким же образом. Этот префикс, который поддерживался Cloudflare, но с использованием наших собственных продуктов, позволил нам быстро обнаружить эту проблему. Полная разбивка по затронутым сервисам приведена ниже.

Была также группа клиентов, которые не смогли восстановить сервис, переключая префиксы в панели управления Cloudflare. Когда инженеры начали повторно анонсировать префиксы для восстановления сервиса этих клиентов, эти клиенты могли наблюдать повышенную задержку и сбои, несмотря на анонсирование их IP-адресов. Это произошло потому, что настройки адресации для некоторых пользователей были удалены с граничных серверов из-за проблемы в нашем собственном программном обеспечении, и состояние пришлось распространять обратно на границу.

Мы собираемся разобраться, что именно сломалось в нашей системе адресации, но для этого нам нужно кратко рассмотреть основу — Addressing API, который является основным источником истины для IP-адресов клиентов в Cloudflare.

Addressing API — это авторитетный набор данных об адресах, присутствующих в сети Cloudflare. Любое изменение в этом наборе данных немедленно отражается в глобальной сети Cloudflare. Хотя мы находимся в процессе улучшения того, как эти системы развертывают изменения, в рамках программы Code Orange: Fail Small, на сегодняшний день клиенты могут настраивать свои IP-адреса, взаимодействуя с общедоступными API, которые настраивают набор баз данных, запускающих рабочие процессы, распространяющие изменения на границу Cloudflare. Это означает, что изменения в Addressing API немедленно распространяются на границу Cloudflare.

Анонсирование и настройка IP-адресов в Cloudflare включает несколько шагов:

• Клиенты сигнализируют Cloudflare об анонсировании/отзыве IP-адресов через Addressing API или BGP Control

• Addressing API дает указание машинам изменить анонсы префиксов

• BGP будет обновлен на маршрутизаторах, как только достаточно машин получат уведомление об обновлении префикса

• Наконец, клиенты могут настроить продукты Cloudflare на использование адресов BYOIP через привязки сервисов (service bindings), которые назначат продукты этим диапазонам

Addressing API позволяет нам автоматизировать большинство процессов, связанных с тем, как мы анонсируем или отзываем адреса, но некоторые процессы по-прежнему требуют ручных действий. Эти ручные процессы рискованны из-за их непосредственной близости к продакшену. В рамках программы Code Orange: Fail Small одной из целей устранения последствий было удаление ручных действий, выполняемых в Addressing API, и замена их безопасными рабочими процессами.

Конкретный элемент конфигурации, который сломался, был изменением, пытающимся автоматизировать действие клиента по удалению префиксов из сервиса BYOIP Cloudflare — обычный запрос клиента, который сегодня выполняется вручную. Удаление этого ручного процесса было частью нашей работы по программе Code Orange: Fail Small, направленной на перевод всех изменений к безопасному, автоматизированному развертыванию с контролем состояния. Поскольку список связанных объектов префиксов BYOIP может быть большим, это было реализовано как часть регулярно выполняемой подзадачи, которая проверяет префиксы BYOIP, которые должны быть удалены, а затем удаляет их. К сожалению, эта регулярная подзадача очистки отправляла запрос к API с ошибкой.

Вот API-запрос из подзадачи очистки:

 resp, err := d.doRequest(ctx, http.MethodGet, `/v1/prefixes?pending_delete`, nil)

А вот соответствующая часть реализации API:

	if v := req.URL.Query().Get("pending_delete"); v != "" {
		// игнорировать другое поведение и получить ожидающие удаления объекты из таблицы ip_prefixes_deleted
		prefixes, err := c.RO().IPPrefixes().FetchPrefixesPendingDeletion(ctx)
		if err != nil {
			api.RenderError(ctx, w, ErrInternalError)
			return
		}

		api.Render(ctx, w, http.StatusOK, renderIPPrefixAPIResponse(prefixes, nil))
		return
	}

Поскольку клиент передает pending_delete без значения, результат Query().Get(“pending_delete”) здесь будет пустой строкой (“”), поэтому API-сервер интерпретирует это как запрос всех BYOIP префиксов вместо только тех префиксов, которые должны были быть удалены. Система интерпретировала это как то, что все возвращенные префиксы поставлены в очередь на удаление. Новая подзадача затем начала систематически удалять все BYOIP префиксы и все связанные зависимые объекты, включая привязки сервисов, пока воздействие не было замечено, и инженер не идентифицировал подзадачу и не остановил ее.

Наша промежуточная среда содержит данные, которые максимально соответствуют Production, но в этом случае этого было недостаточно, и макетные данные, на которые мы полагались для моделирования происходящего, были недостаточными.

Кроме того, хотя у нас есть тесты для этой функциональности, покрытие этого сценария в нашем процессе тестирования и среде было неполным. Первоначальное тестирование и проверка кода были сосредоточены на процессе самостоятельного использования BYOIP API и были успешно завершены. Хотя наши инженеры успешно протестировали точный процесс, который бы выполнил клиент, тестирование не охватывало сценарий, в котором служба task-runner самостоятельно выполняла бы изменения пользовательских данных без явного ввода.

Затронутые BYOIP префиксы были затронуты не одинаково, что потребовало более интенсивных шагов восстановления данных. Как часть Code Orange: Fail Small, мы создаем систему, в которой снимки операционного состояния могут безопасно развертываться посредством развертываний, опосредованных состоянием здоровья. В случае, если что-то развертывается и вызывает неожиданное поведение, это можно очень быстро откатить к известному хорошему состоянию. Однако эта система сегодня не находится в Production.

BYOIP префиксы находились в разных состояниях воздействия во время этого инцидента, и каждое из этих различных состояний требовало разных действий:

• Большинство затронутых клиентов имели только отозванные префиксы. Клиенты в этой конфигурации могли зайти в панель управления и переключить свои объявления, что восстановило бы службу. 

• У некоторых клиентов были отозваны префиксы и удалены некоторые привязки. Эти клиенты находились в частичном состоянии восстановления, где они могли переключать некоторые префиксы, но не другие.

• У некоторых клиентов были отозваны префиксы и удалены все привязки сервисов. Они не могли переключать свои префиксы в панели управления, потому что не было сервиса (Magic Transit, Spectrum, CDN), привязанного к ним. Эти клиенты требовали наибольшего времени для устранения, так как должно было быть инициировано глобальное обновление конфигурации, чтобы повторно применить привязки сервисов для всех этих клиентов к каждой машине на границе Cloudflare.

Изменение, которое мы вносили, когда произошел этот инцидент, является частью инициативы Code Orange: Fail Small, направленной на повышение устойчивости кода и конфигурации в Cloudflare. В качестве краткого введения в инициативы Code Orange: Fail Small, работу можно разделить на три категории:

• Требовать контролируемое развертывание для любого изменения конфигурации, которое распространяется на сеть, точно так же, как мы делаем сегодня для выпусков программных бинарников.

• Изменить наши внутренние процедуры «аварийного доступа» и удалить любые циклические зависимости, чтобы мы и наши клиенты могли действовать быстро и получать доступ ко всем системам без проблем во время инцидента.

• Пересмотреть, улучшить и протестировать режимы отказа всех систем, обрабатывающих сетевой трафик, чтобы гарантировать, что они демонстрируют четко определенное поведение при всех условиях, включая неожиданные состояния ошибок.

Изменение, которое мы пытались развернуть, попадает в первую категорию. Перемещая рискованные, ручные изменения в безопасные, автоматизированные обновления конфигурации, которые развертываются опосредованно состоянием здоровья, мы стремимся повысить надежность сервиса.

Критическая работа уже велась для улучшения поддержки изменения конфигурации Addressing API через поэтапное тестовое посредничество и лучшие проверки корректности. Эта работа велась параллельно с развернутым изменением. Хотя превентивные меры не были полностью развернуты до сбоя, команды активно работали над этими системами, когда произошел инцидент. Следуя нашему обещанию Code Orange: Fail Small требовать контролируемого развертывания любых изменений в Production, наши инженерные команды глубоко проникают во все слои нашего стека, чтобы выявлять и исправлять все проблемные находки. Хотя этот сбой сам по себе не был глобальным, радиус поражения и воздействие были неприемлемо большими, что еще больше укрепляет Code Orange: Fail Small как приоритет, пока мы не восстановим уверенность в том, что все изменения в нашей сети являются максимально постепенными. Теперь поговорим более конкретно об улучшениях этих систем.

Одна из проблем в этом инциденте заключается в том, что флаг pending_delete интерпретировался как строка, что затрудняло как клиенту, так и серверу рационализацию значения флага. Мы улучшим схему API для обеспечения лучшей стандартизации, что значительно упростит тестированию и системам проверку, правильно ли сформирован вызов API или нет. Эта работа является частью третьего направления работы Code Orange, которое направлено на создание четко определенного поведения при всех условиях.

Сегодня клиенты вносят изменения в схему адресации, которые сохраняются в авторитетной базе данных, и эта же база данных используется для оперативных действий. Это делает процессы ручного отката более сложными, потому что инженерам необходимо использовать снимки базы данных вместо рационализации между желаемым и фактическим состояниями. Мы перепроектируем механизм отката и конфигурацию базы данных, чтобы обеспечить легкий способ быстро откатывать изменения, а также ввести уровни между конфигурацией клиента и Production.

Мы будем делать снимки данных, которые мы читаем из базы данных и применяем к Production, и применять эти снимки так же, как мы развертываем все другие изменения Production, опосредованно метриками здоровья, которые могут автоматически остановить развертывание, если что-то пойдет не так. Это означает, что в следующий раз, когда у нас возникнет проблема, при которой база данных перейдет в плохое состояние, мы сможем почти мгновенно вернуть отдельных клиентов (или всех клиентов) к работающей версии.

Хотя это временно заблокирует наших клиентов от возможности делать прямые обновления через наш API в случае сбоя, это означает, что мы сможем продолжать обслуживать их трафик, пока мы работаем над исправлением базы данных, вместо того чтобы быть недоступными в это время. Эта работа соответствует первому и второму направлениям работы Code Orange, которые включают быстрый откат, а также безопасное, опосредованное состоянием здоровья развертывание конфигурации.

Мы улучшим наше мониторинговое обеспечение, чтобы обнаруживать, когда изменения происходят слишком быстро или слишком широко, например, быстрый отзыв или удаление BGP префиксов, и отключать развертывание снимков, когда это происходит. Это создаст своего рода автоматический выключатель, чтобы остановить любой вышедший из-под контроля процесс, который манипулирует базой данных от наличия большого радиуса поражения, как мы видели в этом инциденте.

У нас также есть текущая работа по прямому мониторингу того, что сервисы, запущенные нашими клиентами, ведут себя правильно, и эти сигналы также могут использоваться для срабатывания автоматического выключателя и остановки потенциально опасных изменений от применения, пока у нас не будет времени на расследование. Эта работа соответствует первому направлению работы Code Orange, которое включает безопасное развертывание изменений.

Ниже приведена хронология событий, включая развертывание изменения и шаги по устранению: