BGP-зомби: Как «мёртвые» маршруты атакуют интернет

Здесь, в Cloudflare, мы отмечали Хэллоуин своей собственной охотой на зомби. Зомби, которых мы хотим устранить, — это те, что нарушают работу основного фреймворка, отвечающего за маршрутизацию интернет-трафика: BGP (протокол граничного шлюза).

BGP-зомби — это забавное название для маршрута, который застрял в зоне, свободной от маршрутов по умолчанию (Default-Free Zone, DFZ) Интернета: совокупности всех интернет-маршрутизаторов, которым не требуется маршрут по умолчанию, возможно, из-за пропущенного или потерянного отзыва префикса.

Коренная причина появления зомби может быть разной — от багов в программном обеспечении маршрутизаторов до общей медлительности обработки маршрутов. Это случается, когда префикс BGP должен был исчезнуть из Интернета, но по той или иной причине он присоединяется к нежити и задерживается на какое-то время.

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

Чтобы понять медлительность, которая часто приводит к появлению BGP-зомби, нам нужно поговорить о поиске путей. Поиск путей происходит, когда маршрутизаторы, работающие по BGP, исчерпывающе ищут наилучший путь к префиксу, определяемый совпадением по самому длинному префиксу (Longest Prefix Matching, LPM) и атрибутами маршрутизации BGP, такими как длина пути и локальные предпочтения. Это становится актуальным в наших наблюдениях за тем, как именно маршруты застревают, как долго они застревают и насколько они видны в Интернете.

Например, поиск путей происходит, когда более специфичный префикс BGP отзывается из глобальной таблицы маршрутизации, и сетям нужно откатиться на менее специфичное BGP-объявление. В этом примере мы используем 2001:db8::/48 для более специфичного BGP-анонса и 2001:db8::/32 для менее специфичного префикса. Когда /48 отзывается исходной автономной системой (AS), маршрутизаторы BGP должны распознать, что этот маршрут отсутствует, и начать направлять трафик на IP-адреса, такие как 2001:db8::1, через маршрут 2001:db8::/32, который всё ещё остаётся, пока префикс 2001:db8::/48 отсутствует.

Давайте посмотрим, как это может выглядеть на практике, с помощью нескольких диаграмм.

_{Диаграмма 1: Активный маршрут 2001:db8::/48}

В этом начальном состоянии 2001:db8::/48 активно используется для пересылки трафика, который весь проходит через AS13335 на пути к AS64511. В этом случае AS64511 была бы клиентом BYOIP Cloudflare. AS64511 также анонсирует резервный маршрут другому интернет-провайдеру (ISP), AS64510, но этот маршрут не активен даже в таблице маршрутизации AS64510 для пересылки на 2001:db8::1, потому что 2001:db8::/48 является более длинным совпадающим префиксом по сравнению с 2001:db8::/32.

Становится интереснее, когда AS64510 сигнализирует об отзыве 2001:db8::/48 через Cloudflare (AS13335), возможно, потому что DDoS-атака закончилась, и клиент решает использовать Cloudflare только тогда, когда он активно подвергается атаке.

Когда клиент сигнализирует Cloudflare (через BGP Control или API-вызов) об отзыве анонса 2001:db8::/48, все маршрутизаторы BGP должны сойтись на этом обновлении, что включает в себя поиск путей. AS13335 отправляет сообщение об отзыве BGP для 2001:db8::/48 своим напрямую подключенным BGP-соседям. Хотя новость об отзыве может быстро дойти от AS13335 до других сетей, до некоторых соседей она может дойти быстрее, чем до других. Это означает, что пока все не получили и не обработали отзыв, сети могут пытаться маршрутизировать друг через друга, чтобы достичь префикса 2001:db8::/48 — даже после того, как AS13335 его отозвала.

_{Диаграмма 2: Маршрут 2001:db8::/48 отозван через AS13335}

Представьте, что AS64501 немного медленнее остальных — возможно, из-за использования старого оборудования, перегруженности оборудования, программной ошибки, специфичных настроек конфигурации, неудачного стечения обстоятельств или какого-то другого фактора — и всё ещё не обработала отзыв /48. Это само по себе может быть BGP-зомби, поскольку маршрут застревает на короткий период. Наши пинги к 2001:db8::1 так и не могут достичь AS64511, потому что AS13335 знает, что /48 должен быть отозван, но некоторые маршрутизаторы с полной таблицей ещё не сошлись на этом результате.

Время, затрачиваемое на поиск путей, усиливается из-за так называемого Минимального Интервала Анонсирования Маршрутов (Minimum Route Advertisement Interval, MRAI). MRAI определяет минимальное время между сообщениями об анонсировании BGP от маршрутизатора BGP, что означает, что он намеренно вводит задержку в несколько секунд между каждым обновлением анонса BGP. RFC4271 рекомендует значение MRAI в 30 секунд для eBGP-обновлений, и хотя это может сократить болтливость BGP или даже потенциальные колебания обновлений, это также увеличивает время поиска путей.

На следующем цикле поиска путей даже AS64501, которая ранее всё ещё указывала на несуществующий маршрут /48 от AS13335, должна обнаружить, что анонс /32 — это всё, что осталось для достижения 2001:db8::1. Как только это произойдёт, поток трафика станет следующим:

_{Диаграмма 3: Откат маршрутизации к 2001:db8::/32, а 2001:db8::/48 исчез из DFZ}

Это означало бы, что поиск путей BGP завершён, и Интернет осознал, что 2001:db8::/32 — это наилучший доступный маршрут к 2001:db8::1, и что 2001:db8::/48 действительно исчез. Хотя в этом примере мы намеренно ограничили поиск путей всего двумя циклами, в реальности их может быть гораздо больше, особенно с учётом того, насколько сильно AS13335 связана с тысячами пиринговых сетей и глобальными провайдерами уровня Tier-1.

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

Зомби привлекли наше внимание в последнее время, так как их заметили некоторые из наших клиентов, использующих Bring-Your-Own-IP (BYOIP) для анонсирования по требованию в Magic Transit. BYOIP может быть настроен в двух режимах: "постоянно включён" (always-on), когда префикс анонсируется непрерывно, или "по требованию" (on-demand), когда префикс анонсируется только тогда, когда клиент этого пожелает. Для некоторых клиентов с режимом по требованию циклы анонсирования и отзыва могут происходить чаще, что может привести к увеличению числа BGP-зомби.

Имея это в виду, а также зная, как работает поиск путей, давайте породим собственного зомби в Интернете. Для этого мы возьмём запасной блок IPv4 и IPv6 и анонсируем их следующим образом:

Как только маршруты будут анонсированы и стабилизированы, мы приступим к отзыву более специфичных маршрутов, анонсированных через Cloudflare глобально. Пара быстрых кликов — и мы успешно воскресили мёртвых.

Вариант А: Жуткие шлюзы

Одно место, где зомби часто возникают, — это между вышестоящими провайдерами. Когда один маршрутизатор в сети данного провайдера обновляется немного медленнее, маршруты могут застревать.

Возьмём, к примеру, следующую петлю, которую мы наблюдали между двумя нашими партнёрами-апстримами:

7. be2431.ccr31.sjc04.atlas.cogentco.com
8. tisparkle.sjc04.atlas.cogentco.com
9. 213.144.177.184
10. 213.144.177.184
11. 89.221.32.227
12. (waiting for reply)
13. be2749.rcr71.goa01.atlas.cogentco.com
14. be3219.ccr31.mrs02.atlas.cogentco.com
15. be2066.agr21.mrs02.atlas.cogentco.com
16. telecomitalia.mrs02.atlas.cogentco.com
17. 213.144.177.186
18. 89.221.32.227

Или эта петля — наблюдавшаяся в том же тесте на отзыв — между двумя другими провайдерами:

15. if-bundle-12-2.qcore2.pvu-paris.as6453.net
16. if-bundle-56-2.qcore1.fr0-frankfurt.as6453.net
17. if-bundle-15-2.qhar1.fr0-frankfurt.as6453.net
18. 195.219.223.11
19. 213.144.177.186
20. 195.22.196.137
21. 213.144.177.186
22. 195.22.196.137

Вариант Б: Неупокоенная ЛВС (локальная вычислительная сеть)

Одновременно зомби могут возникать целиком внутри данной сети. Когда маршрут отзывается из сети Cloudflare, каждое устройство в нашей сети должно индивидуально начать процесс отзыва маршрута. Хотя обычно это плавный процесс, вещи всё же могут застревать.

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

10. 192.0.2.112
11. 192.0.2.113
12. 192.0.2.112
13. 192.0.2.113
14. 192.0.2.112
15. 192.0.2.113
16. 192.0.2.112
17. 192.0.2.113
18. 192.0.2.112
19. 192.0.2.113

В отличие от большинства вымышленных орд ходячих мертвецов, наш хорошо заметный "зомби" имеет ограниченное время жизни в большинстве крупных сетей — в данном случае всего около 6 минут, после чего большинство сетей повторно сошлись на менее специфичном префиксе как на наилучшем пути. К сожалению, это довольно короткий срок — в некоторых случаях мы наблюдали, как долгоживущие "зомби" вызывали проблемы с доступностью более 10 минут. Можно с уверенностью сказать, что это дольше, чем большинство сетевых операторов ожидали бы от конвергенции BGP в нормальной ситуации.

Но вы можете спросить — это тот самый избыточный поиск пути, о котором мы говорили ранее, или "зомби" BGP? На самом деле, это зависит от ожиданий и допусков относительно того, сколько времени должна занимать конвергенция BGP для обработки отзыва префикса. В любом случае, даже спустя более 30 минут после нашего отзыва более специфичного префикса, мы легко можем наблюдать "зомби"-маршруты в публичных коллекторах route-views:

~ % monocle search --start-ts 2025-10-28T12:40:13Z --end-ts 2025-10-28T13:00:13Z --prefix 198.18.0.0/24
A|1761656125.550447|206.82.105.116|54309|198.18.0.0/24|54309 13335 395747|IGP|206.82.104.31|0|0|54309:111|false|||route-views.ny

Вы можете утверждать, что от шести до одиннадцати минут (или больше) — это разумное время для конвергенции BGP в наихудшем случае на уровне сетей Tier-1, хотя и это кажется натяжкой. Даже если отбросить это, наши данные показывают, что вполне реальные "зомби" BGP существуют в глобальной таблице маршрутизации, и они будут негативно влиять на трафик. Любопытно, что мы наблюдали, что задержка из-за избыточного поиска пути хуже в IPv4, при этом самое длительное воздействие на IPv6 в крупных (Tier-1) сетях составило чуть более 4 минут. Можно предположить, что это частично связано с гораздо большим количеством IPv4-префиксов в глобальной таблице маршрутизации Интернета по сравнению с глобальной таблицей IPv6, и с тем, как устройства BGP обрабатывают их раздельно.

_{Источник: RIPEstat’s BGPlay}

Часть задержки, по-видимому, происходит от того, насколько взаимосвязана AS13335; активный пиринг с большой частью Интернета увеличивает вероятность того, что маршрут "застрянет" в определенном месте. Учитывая это, возможно, "зомби" жил бы меньше, если бы мы действовали в противоположном направлении: постоянно анонсируя менее специфичный префикс в 13335 и анонсируя более специфичные префиксы через нашего локального ISP в ходе нормальной работы. Поскольку отзыв будет исходить из сети, вероятно, менее связанной пирингом, время конвергенции может быть короче:

Действительно, как и предсказывалось, мы все равно получаем "застрявший" маршрут, и он живет всего около 20 секунд на уровне сети Tier-1:

19. be12488.ccr42.ams03.atlas.cogentco.com
20. 38.88.214.142
21. be2020.ccr41.ams03.atlas.cogentco.com
22. 38.88.214.142
23. (waiting for reply)
24. 38.88.214.142
25. (waiting for reply)
26. 38.88.214.142

К сожалению, эти 20 секунд — все равно значимые 20 секунд — хоть и лучше, но это не тот результат, к которому мы стремимся. Точная продолжительность будет зависеть от сетей местных ISP, с которыми вы связаны, и она вполне может достигать нескольких минут "застрявшей" маршрутизации.

В обоих случаях первоначальное время анонсирования не привело к потерям, и "зомби" не создавался, так как оба пути оставались действительными в течение всего их начального времени жизни. "Зомби" создавались только тогда, когда более специфичный префикс полностью отзывался. Вновь анонсированный маршрут не подвержен избыточному поиску пути так, как отозванный более специфичный маршрут. Как говорится, хорошие (новые) новости разносятся быстро.

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

Для трафика, который достигает Cloudflare по "застрявшим" маршрутам, мы внедрим внутренние улучшения пересылки трафика BGP, которые позволят осуществлять более плавный отвод трафика, даже если маршруты по ошибке указывают на нас. Во многом это будет closely напоминать функциональность известного сообщества BGP no-export на наших серверах, работающих с BGP. Это означает, что даже если мы получаем трафик от внешних сторон из-за "застрявшей" маршрутизации, у нас все равно будет возможность доставить трафик нашим конечным клиентам через туннельное соединение или через Cloudflare Network Interconnect (CNI). Мы с нетерпением ждем возможности сообщить о положительном эффекте после внедрения этого улучшения для более плавного дренажа трафика по умолчанию.

Для трафика, который не достигает границы Cloudflare, а вместо этого циркулирует между сетевыми провайдерами, нам необходимо использовать другой подход. Поскольку мы знаем, что откат маршрутизации с более специфичного на менее специфичный префикс более подвержен "вспышкам" BGP-зомби, мы рекомендуем клиентам использовать многоэтапный процесс дренажа, когда они хотят отвести трафик от границы Cloudflare для префикса по требованию, не создавая при этом петель маршрутизации или событий черной дыры. Процесс дренажа при удалении трафика для префикса BYOIP из Cloudflare должен выглядеть следующим образом:

1. Клиент уже анонсирует пример префикса из Cloudflare, например, 198.18.0.0/24

2. Клиент начинает нативно анонсировать префикс 198.18.0.0/24 (т.е. той же длины, что и префикс, который он рекламирует через Cloudflare) из своей сети интернет-провайдерам, на которых он хочет перевести трафик.

3. Через несколько минут клиент инициирует отзыв BGP из Cloudflare для префикса 198.18.0.0/24.

В результате получается чистый переход: impactful "зомби" избегаются, потому что префикс той же длины (198.18.0.0/24) остается в глобальной таблице маршрутизации. Избыточный поиск пути избегается, потому что вместо того, чтобы маршрутизаторам нужно было агрессивно искать отсутствующее совпадение по более специфичному префиксу, они могут откатиться на анонс той же длины, который сохраняется в таблице маршрутизации от нативно созданного пути к сети клиента.

_{Источник: RIPEstat’s BGPlay}

Мы собираемся продолжать совершенствовать наши методы измерения BGP-"зомби", так что в будущем вас ждут новые инсайты. Также в работе других участников сообщества по измерению "зомби" есть интересные моменты, и она дает полезные данные. Что касается борьбы с программными ошибками, приводящими к созданию BGP-"зомби", вендоры маршрутизаторов должны реализовать RFC9687, таймер BGP SendHoldTimer. Основная идея заключается в том, что локальный маршрутизатор может с помощью SendHoldTimer определить, если удаленный маршрутизатор неожиданно перестал обрабатывать сообщения BGP, что снижает вероятность длительного "застревания" "зомби".

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