Утечка маршрутов BGP: разбор инцидента и наши действия

22 января 2026 года ошибка автоматической настройки политики маршрутизации привела к случайной утечке некоторых префиксов протокола граничного шлюза (BGP) с маршрутизатора в нашем дата-центре в Майами, Флорида. Хотя утечка маршрутов повлияла на некоторых клиентов Cloudflare, также пострадали и несколько внешних сторон, поскольку их трафик был случайно перенаправлен через наше расположение дата-центра в Майами.

Утечка маршрутов длилась 25 минут, вызвав перегрузку на части нашей магистральной инфраструктуры в Майами, повышенные потери для части клиентского трафика Cloudflare и увеличение задержки для трафика, проходящего по этим каналам связи. Кроме того, часть трафика была отброшена фильтрами межсетевого экрана на наших маршрутизаторах, которые настроены на прием только трафика для сервисов Cloudflare и наших клиентов.

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

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

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

При таком типе утечки маршрутов нарушаются правила беспропастной маршрутизации (valley-free routing), поскольку обновления BGP отправляются от AS64501 своему пиру (AS64502), а затем неожиданно вверх к провайдеру (AS64503). Зачастую сторона, допустившая утечку (в данном случае AS64502), не готова обрабатывать объем трафика, который она получит, и у нее могут быть даже не настроены фильтры межсетевого экрана для приема всего трафика, идущего в ее направлении. Проще говоря, после отправки обновления маршрута пиру или провайдеру, оно должно распространяться дальше только клиентам, а не другому пиру или AS провайдера.

Во время инцидента 22 января мы вызвали аналогичную утечку маршрутов, при которой мы взяли маршруты от некоторых наших пиров и распространили их в Майами некоторым нашим пирам и провайдерам. Согласно определениям утечки маршрутов в RFC7908, мы вызвали на интернете смесь утечек маршрутов Типа 3 и Типа 4.

22 января 2026 года в 20:25 UTC мы отправили изменение через нашу платформу автоматизации политик, чтобы удалить BGP-анонсы из Майами для одного из наших дата-центров в Боготе, Колумбия. Это было сделано целенаправленно, так как ранее мы направляли часть IPv6-трафика через Майами в дата-центр в Боготе, но недавние обновления инфраструктуры устранили такую необходимость.

Это изменение привело к следующему дифу (программе, которая сравнивает файлы конфигурации, чтобы определить, чем или отличаются ли они вообще):

[edit policy-options policy-statement 6-COGENT-ACCEPT-EXPORT term ADV-SITELOCAL-GRE-RECEIVER from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-COMCAST-ACCEPT-EXPORT term ADV-SITELOCAL-GRE-RECEIVER from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-GTT-ACCEPT-EXPORT term ADV-SITELOCAL-GRE-RECEIVER from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-LEVEL3-ACCEPT-EXPORT term ADV-SITELOCAL-GRE-RECEIVER from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-PRIVATE-PEER-ANYCAST-OUT term ADV-SITELOCAL from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-PUBLIC-PEER-ANYCAST-OUT term ADV-SITELOCAL from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-PUBLIC-PEER-OUT term ADV-SITELOCAL from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-TELEFONICA-ACCEPT-EXPORT term ADV-SITELOCAL-GRE-RECEIVER from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-TELIA-ACCEPT-EXPORT term ADV-SITELOCAL-GRE-RECEIVER from]
-      prefix-list 6-BOG04-SITE-LOCAL;

Хотя на первый взгляд это изменение политики кажется безобидным — просто удаление списков префиксов, содержащих униокастные префиксы BOG04, — оно привело к созданию излишне разрешительной политики:

policy-options policy-statement 6-TELIA-ACCEPT-EXPORT {
    term ADV-SITELOCAL-GRE-RECEIVER {
        from route-type internal;
        then {
            community add STATIC-ROUTE;
            community add SITE-LOCAL-ROUTE;
            community add MIA01;
            community add NORTH-AMERICA;
            accept;
        }
    }
}

Теперь политика помечала каждый префикс типа "internal" как допустимый и добавляла некоторые информативные сообщества (communities) ко всем соответствующим префиксам. Но что более важно, политика также принимала маршрут через фильтр политики, что привело к внешнему анонсированию префикса, который предназначался для внутреннего использования. Это проблема, потому что условие совпадения "route-type internal" в JunOS или JunOS EVO (операционных системах, используемых устройствами HPE Juniper Networks) соответствует любому не-внешнему типу маршрута, такому как маршруты Internal BGP (IBGP), что и произошло в данном случае.

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

Когда ошибочная конфигурация политики была применена в 20:25 UTC, серия непреднамеренных обновлений BGP была отправлена от AS13335 пирам и провайдерам в Майами. Эти обновления BGP можно увидеть исторически, просматривая файлы MRT с помощью инструмента monocle или используя RIPE BGPlay.

➜  ~ monocle search --start-ts 2026-01-22T20:24:00Z --end-ts 2026-01-22T20:30:00Z --as-path ".*13335[ d$]32934$*"
A|1769113609.854028|2801:14:9000::6:4112:1|64112|2a03:2880:f077::/48|64112 22850 174 3356 13335 32934|IGP|2801:14:9000::6:4112:1|0|0|22850:65151|false|||pit.scl
A|1769113609.854028|2801:14:9000::6:4112:1|64112|2a03:2880:f091::/48|64112 22850 174 3356 13335 32934|IGP|2801:14:9000::6:4112:1|0|0|22850:65151|false|||pit.scl
A|1769113609.854028|2801:14:9000::6:4112:1|64112|2a03:2880:f16f::/48|64112 22850 174 3356 13335 32934|IGP|2801:14:9000::6:4112:1|0|0|22850:65151|false|||pit.scl
A|1769113609.854028|2801:14:9000::6:4112:1|64112|2a03:2880:f17c::/48|64112 22850 174 3356 13335 32934|IGP|2801:14:9000::6:4112:1|0|0|22850:65151|false|||pit.scl
A|1769113609.854028|2801:14:9000::6:4112:1|64112|2a03:2880:f26f::/48|64112 22850 174 3356 13335 32934|IGP|2801:14:9000::6:4112:1|0|0|22850:65151|false|||pit.scl
A|1769113609.854028|2801:14:9000::6:4112:1|64112|2a03:2880:f27c::/48|64112 22850 174 3356 13335 32934|IGP|2801:14:9000::6:4112:1|0|0|22850:65151|false|||pit.scl
A|1769113609.854028|2801:14:9000::6:4112:1|64112|2a03:2880:f33f::/48|64112 22850 174 3356 13335 32934|IGP|2801:14:9000::6:4112:1|0|0|22850:65151|false|||pit.scl
A|1769113583.095278|2001:504:d::4:9544:1|49544|2a03:2880:f17c::/48|49544 1299 3356 13335 32934|IGP|2001:504:d::4:9544:1|0|0|1299:25000 1299:25800 49544:16000 49544:16106|false|||route-views.isc
A|1769113583.095278|2001:504:d::4:9544:1|49544|2a03:2880:f27c::/48|49544 1299 3356 13335 32934|IGP|2001:504:d::4:9544:1|0|0|1299:25000 1299:25800 49544:16000 49544:16106|false|||route-views.isc
A|1769113583.095278|2001:504:d::4:9544:1|49544|2a03:2880:f091::/48|49544 1299 3356 13335 32934|IGP|2001:504:d::4:9544:1|0|0|1299:25000 1299:25800 49544:16000 49544:16106|false|||route-views.isc
A|1769113584.324483|2001:504:d::19:9524:1|199524|2a03:2880:f091::/48|199524 1299 3356 13335 32934|IGP|2001:2035:0:2bfd::1|0|0||false|||route-views.isc
A|1769113584.324483|2001:504:d::19:9524:1|199524|2a03:2880:f17c::/48|199524 1299 3356 13335 32934|IGP|2001:2035:0:2bfd::1|0|0||false|||route-views.isc
A|1769113584.324483|2001:504:d::19:9524:1|199524|2a03:2880:f27c::/48|199524 1299 3356 13335 32934|IGP|2001:2035:0:2bfd::1|0|0||false|||route-views.isc
{trimmed}

^{В приведённом выше выводе monocle мы видим временную метку нашего BGP-обновления, за которой следует next-hop в анонсе, ASN сети, передающей определённому сборщику маршрутов, задействованный префикс, а также путь AS и BGP-сообщества, если они найдены. В конце каждой строки вывода также указан экземпляр сборщика маршрутов.}

Рассматривая первое обновление для префикса 2a03:2880:f077::/48, путь AS — 64112 22850 174 3356 13335 32934. Это означает, что мы (AS13335) взяли префикс, полученный от Meta (AS32934), нашего пира, и затем анонсировали его в сторону Lumen (AS3356), одного из наших вышестоящих транзитных провайдеров. Мы знаем, что это утечка маршрутов, так как маршруты, полученные от пиров, предназначены только для повторного анонсирования нижестоящим (клиентским) сетям, а не другим пирам или вышестоящим провайдерам.

В результате утечки и передачи непредназначенного трафика на наш маршрутизатор в Майами от провайдеров и пиров мы столкнулись с перегрузкой на нашем магистральном канале между Майами и Атлантой, как видно на графике ниже.

Это привело бы к повышенным потерям для части трафика клиентов Cloudflare и к более высокой, чем обычно, задержке для трафика, проходящего по этим каналам. Помимо этой перегрузки, трафик от сетей, чьи префиксы мы утекли, был бы отброшен фильтрами брандмауэра на наших маршрутизаторах, которые настроены принимать только трафик для сервисов Cloudflare и наших клиентов. На пике мы отбрасывали около 12 Гбит/с трафика, входящего на наш маршрутизатор в Майами для этих префиксов, не принадлежащих нашим клиентам.

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

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

Что касается наших конфигураций политик маршрутизации и автоматизации, мы:

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

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

• Добавляем автоматическую оценку политик маршрутизации в наши CI/CD-пайплайны, которая специально ищет пустые или ошибочные условия политик.

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

Чтобы помочь предотвратить утечки маршрутов в целом, мы:

• Проверяем реализацию поставщиками сетевого оборудования стандарта RFC9234 (Роли в BGP и атрибут Only-to-Customer) в рамках подготовки к развёртыванию этой функции, которая является единственным способом независимо от политики маршрутизации предотвратить утечки маршрутов, вызванные на уровне локальной автономной системы (AS).

• Способствуем долгосрочному внедрению RPKI Авторизации провайдера автономной системы (ASPA), где сети могли бы автоматически отвергать маршруты, содержащие аномальные пути AS.

Самое главное, мы хотели бы ещё раз принести извинения за влияние, которое мы оказали на пользователей и клиентов Cloudflare, а также за любое влияние, ощущаемое внешними сетями.