Как Verizon и BGP Optimizer устроили большой оффлайн

Автор оригинала: Tom Strickx
  • Перевод


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


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


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


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


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


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


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


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


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


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



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


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



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


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


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


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


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


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


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


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



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


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


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


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



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


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



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


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


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


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


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

Southbridge
352,01
Обеспечиваем стабильную работу серверов
Поделиться публикацией

Комментарии 12

    +2
    А с другой стороны, BGP Optimizer очень похож на костыли, которые решают проблемы возникшие в результате желания сэкономить.
      0
      Эти костыли, как мне кажется — следсвия полного отсутствия в BGP механизмов работы с sub/super-netting, вопреки его разрекламированной направленности на «policy-preferred routing».
      Можно много чего разрулить при помощи localpref, и MED, еще больше — при помощи community (которые, в принципе, точно так же манипулируют localpref и MED), но вот против ломаспецификов нет приема.
      Хочешь положить болт на все предпочтения окружающих — плодишь специфик в нужную тебе сторону, и все — никакие обычные средства других АС его не обойдут, только еще более твердый лом в виде явных префикс-листов.

      В итоге и появляются такие автоматические костылезаторы.
        0
        Я не совсем про это. А про ситуации когда, к примеру, покупается два аплинка, как бы для резервирования, но полоса обоих в сумме равна полному трафику в эту AS. Манипулирование спецификами позволяет разбалансировать. Ну а упадёт один канал, что ж, абоненты потерпят. В РФ это сплошь и рядом. Рвут самую дешёвую ВОЛС, где все гонят основной трафик, начинается деградация, пинги в сотни миллисекунд, дропы.
        Кроилово приводит к попадалову, как любили упоминать на одном захиревшем сетевом форуме.
          +1
          Если покупать каналы и использовать их на 50% — или прибыли не будет или клиентов, которые не потерпят высоких цен.
            0
            А если аплинков больше двух и запас полосы N+1? Балансировать всяко придется, пока каждый из аплинков не будет вмещать полный трафик до AS, а это нерентабельно.
          +1
          BGP Optimizer — это инструмент. Как и любым инструментом, если им правильно пользоваться — можно получить много плюшек. А если нет — то получаем вышеописанные события.
          +3
          Виноватых тут все трое:
          — безусловно главный виновник торжества Verizon, который добродушно принял все прилетевшее от кастомера с одним-единствнный законным префиксом, да еще и со скоростью реакции мертвой черепахи; Какая халатность…
          — тот самый сталепрокатный завод, который принял префиксы от одного аплинка и спокойно передал другому (зачем вообще отправлять аплинку что-либо кроме себя? Рухтер — купил, АС — купил, настроить — не купил?);
          — ну и в последнюю очередь второй аплинк DQE со своими странными оптимизаторами. Оно, конечно, очень некрасиво плодить фейковые специфики, а даже если решились на такую подлость, то хотя бы с no-export отдавали бы кастомерам, но, все же, это на совести такого провайдера.
            +4
            То чувство, когда недавно читал на хабре статью, где описываются похожие случаи из прошлого и что тряхнуть опять может в любой момент.
              +1
              с тем же успехом навигатор мог бы отправить поток машин с многополосного шоссе на узкую улочку

              Спасибо за пояснения на примере из жизни :))
                +3
                Самое интересное в ситуации — это как работает NOC у этих провайдеров. У Cloudflare все четко работает, мониторинг, инженеры. У какого то мелкого провайдера тоже инженеры NOC работают, а вот у Verizon все фигово, ни по телефону ни по email не отвечают, случись что серьезней и с их стороны — фиг до них дозвонишься, весь инет положат и будут сидеть и молчать. Вот с этим нужно тоже что то решать.

                Интересно, у наших крупных провайдеров NOC работает исправно?
                  0
                  Попробую высказаться по поводу «решать».
                  Я не первый такого мнения, и в статье (и даже в комментах) этот вопрос отчасти уже фигурировал в форме аналогии с навигатором и узкой улочкой. Аналогия, в принципе, относительно верная. Ящетаю, что для конфигурации BGP нужно выдавать права подобные автомобильным и сделать специальную официальную комиссию. Чтобы не было монополистов данные права должен выдавать IEEE, а не Cisco, ну это формальности.
                  Естественно, до полноценных автомобильных правил не докатиться, иначе придётся повсюду вешать аппараты-алкочекеры, но это было бы неплохо. :) Ну можно хотя бы перед способностью конфигурации BGP делать интеллектуальную капчу — по N вопросов, проверяющих адекватность инженера в данный момент и дающих доступ до конфигурации
                  +1
                  Коллеги подсказывают, что появилось более детальное описание инцидента в блоге CF.

                  Today we will dive into the archived routing data and analyze it. The format of the code below is meant to use simple shell commands so that any reader can follow along and, more importantly, do their own investigations on the routing tables.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое