Хабрахабр

[Перевод] Как Verizon и BGP Optimizer устроили большой оффлайн

Крупная утечка маршрутов повлияла на большие секторы интернета, включая Cloudflare

Что случилось?

06 в 10:30 UTC в интернете случился коллапс: на небольшую компанию на севере Пенсильвании хлынул поток трафика из множества маршрутов, проходящих через крупного провайдера Verizon (AS701), — с тем же успехом навигатор мог бы отправить поток машин с многополосного шоссе на узкую улочку. 24. Этого вообще не должно было произойти, ведь Verizon не должен был рассылать эти маршруты всему интернету. В результате у многих веб-сайтов на Cloudflare и многих других провайдеров возникли проблемы с доступом. Чтобы узнать, как так вышло, читайте дальше.

Проблему усугубил BGP Optimizer от Noction. Мы уже писали о подобных происшествиях раньше, времени они случаются, но на этот раз последствия ощутили по всему миру. Например, наш IPv4-маршрут 104. У него есть функция, которая разбивает полученные IP-префиксы на более мелкие и конкретные. 0. 20. 20. 0/20 разделился на 104. 0/21 и 104. 0. 8. 20. Как если бы дорожный указатель на Пенсильванию заменили на два других: «Питтсбург, штат Пенсильвания» и «Филадельфия, штат Пенсильвания». 0/21. Иначе возникают вот такие неприятности. Разделяя большие блоки IP на мелкие, сеть управляет трафиком внутри себя, но это разделение не должно было стать общедоступным.

По сути интернет — это сеть, состоящая из сетей, которые называются автономными системами. Чтобы объяснить, что случилось дальше, давайте сначала вспомним, по какой схеме работает интернет. Все сети связаны друг с другом по протоколу Border Gateway Protocol (BGP). У каждой автономной системы свой уникальный идентификатор. BGP соединяет эти сети и образует структуру интернета, в которой трафик проходит, допустим, от вашего интернет-провайдера к популярному веб-сайту в другой части света.

Эти маршруты могут быть конкретными (как определенный город на карте) или общими (как область). Через BGP сети обмениваются сведениями о маршрутах, а именно: как добраться до них из любой точки. Тут-то и случилась беда.

Конкретные маршруты имеют приоритет над общими (в том же навигаторе, например, маршрут до Букингемского дворца будет более конкретным, чем маршрут до Лондона). Один интернет-провайдер в Пенсильвании (AS33154 — DQE Communications) использовал в своей сети BGP Optimizer, то есть в их сети было много конкретных маршрутов.

Оптимальными они кажутся потому, что в них больше деталей и конкретики. DQE предоставил эти конкретные маршруты своему клиенту (AS396531 — Allegheny Technologies Inc), а оттуда они попали к транзитному провайдеру (AS701 — Verizon), который разнес эти «оптимальные» маршруты по всему интернету.

И хотя существуют эффективные способы защиты от таких сбоев, отсутствие у Verizon фильтров привело к коллапсу, затронувшему множество сервисов, таких как Amazon, Linode и Cloudflare. И все это не должно было выйти за пределы Verizon.

Они не были предназначены для такого мощного трафика, что и привело к перебоям. В итоге на Verizon, Allegheny и DQE обрушился вал пользователей, пытающихся получить доступ к этим сервисам через их сети. И даже если бы ресурсов хватило, DQE, Allegheny и Verizon не должны были рассказывать всем об идеальном маршруте к Cloudflare, Amazon, Linode и т д.


Процесс утечки BGP с BGP Optimizer.

В худшие моменты сбоя мы наблюдали потерю приблизительно 15% мирового трафика.


Уровни трафика в Cloudflare во время инцидента.

Как можно было предотвратить утечку?

Есть несколько способов.

Если бы у Verizon был такой лимит на префиксы, ничего бы не случилось. Для BGP-сессии можно настроить жесткий лимит принимаемых префиксов, и если количество префиксов превысит порог, роутер прервет сессию. Почему лимитов не было? Такому провайдеру, как Verizon, установить его ничего бы не стоило. У меня одна версия: небрежность и лень.

IRR (Internet Routing Registry) — это распределенная база данных интернет-маршрутов, в которую сети добавляют записи. Еще один способ предотвратить такие утечки — фильтрация на основе IRR. Если бы использовались фильтры IRR, ни одна из этих сетей не приняла бы ошибочные конкретные маршруты. Другие сетевые операторы используют эти записи в IRR, чтобы создавать списки конкретных префиксов для BGP-сессий с другими сетями. IRR-фильтры ничего бы не стоили Verizon и никак бы не ограничили их сервис. Невероятно, но у Verizon вообще не было такой фильтрации в BGP-сессиях с Allegheny Technologies, хотя IRR-фильтрация используется (и прекрасно задокументирована) уже больше 24 лет. И снова — небрежность и лень.

Она устанавливает фильтры по исходной сети и размеру префикса. В прошлом году мы реализовали и развернули платформу RPKI, которая как раз предотвращает подобные утечки. RPKI указывает, что более конкретные префиксы принимать нельзя, независимо от пути. Cloudflare объявляет префиксы с максимальным размером 20. Многие провайдеры, например, AT&T уже успешно применяют RPKI в своей сети. Чтобы этот механизм работал, в сети нужно включить BGP Origin Validation.

Если бы в Verizon использовали RPKI, они бы увидели, что предложенные маршруты недопустимы, и роутер автоматически отклонил бы их.

Cloudflare советует всем сетевым операторам развернуть RPKI прямо сейчас!


Предотвращение утечки маршрутов с помощью IRR, RPKI и лимита на префиксы.

Все эти рекомендации прекрасно описаны в нормах MANRS (Mutually Agreed Norms for Routing Security).

Как решили проблему

Это было непросто — может, потому, что когда все началось, на восточном побережье США было еще раннее утро. Команда по сетям Cloudflare связалась с пострадавшими сетями AS33154 (DQE Communications) и AS701 (Verizon).


Скриншот письма в Verizon.

При нашей поддержке по телефону DQE смогли прекратить рассылку «оптимизированных» маршрутов к Allegheny Technologies Inc. Один из наших сетевых инженеров быстро связался с DQE Communications, и после небольшой задержки нас соединили с тем, кто мог решить проблему. Все стабилизировалось и пришло в норму. Мы благодарны им за помощь.


Скриншот попыток связаться со службами поддержки DQE и Verizon

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

Отрасли пора принять более эффективные меры, чтобы обеспечить безопасность маршрутизации, например, с помощью таким систем, как RPKI. Мы в Cloudflare не хотели бы повторения подобного, но делается для этого, к сожалению, очень мало. Особенно это касается вас, Verizon. Мы надеемся, что крупные провайдеры последуют примеру Cloudflare, Amazon и AT&T и начнут проверять маршруты. Мы все еще ждем ответа.

Мы заботимся о наших клиентах, и инженеры в США, Великобритании, Австралии и Сингапуре вышли на связь через несколько минут после того, как мы обнаружили проблему. И хотя мы не могли повлиять на случившееся, приносим свои извинения за перебои в обслуживании.

Другие статьи с тегом BGP.

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»