Сервис Cloudflare был недоступен в течение получаса из-за ошибки в конфигурации маршрутизатора



    17 июля 2020 года с 20:25 UTC (23:25 МСК) по 22:10 UTC (18 июля 01:10 МСК) в работе сервиса Cloudflare наблюдались проблемы по всему миру. Хотя специалисты Cloudflare смогли быстро разобраться в ситуации, но избежать прерывания глобальных сервисов им не удалось. Причем инцидент оказался достаточно серьезным — на полчаса пользователям оказались недоступны многие интернет-ресурсы, включая Discord, Valorant, Patreon, GitLab, Medium, Zendesk, Gematsu, Windows Central, Crunchyroll, многие игровые серверы (Riot Games, FIFA, Steam), Stream Labs и даже портал Downdetector.

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

    Инциденту предшествовала аварийная ситуация — сначала произошел разрыв связи между дата-центрами Cloudflare в Ньюарке и Чикаго. Это привело к возникновению критической нагрузки на дата-центры Cloudflare в Атланте и Вашингтоне, округ Колумбия. Оперативно реагируя на эту ситуацию сетевой инженер Cloudflare обновил конфигурацию на маршрутизаторе глобальной магистрали в Атланте, чтобы уменьшить и перераспределить нагрузку на узлы системы. Однако, оказалось, что в новой конфигурации маршрутизатора была допущена ошибка (вместо удаления маршрутов Атланты из магистрали было прописано пропускать все маршруты BGP в магистраль), поэтому он стал ресолвить неверные маршруты после прерывания связи с частью дата-центров. Именно это привело к недоступности некоторых частей сети и прерыванию многих сервисов.

    Что именно было не так сделано.
    Сетевой инженер удалил одну строку в блоке настроек маршрутизатора. Данный блок определелял список принимаемых маршрутов и фильтровал их в соответствии с указанным списком префиксов. Фактически, вместо удаления всего блока была удалена только строка со списком префиксов.

    {master}[edit]
       atl01# show | compare 
       [edit policy-options policy-statement 6-BBONE-OUT term 6-SITE-LOCAL from]
       !       inactive: prefix-list 6-SITE-LOCAL { ... }
    
    Содержимое блока:
       from {
           prefix-list 6-SITE-LOCAL;
       }
       then {
           local-preference 200;
           community add SITE-LOCAL-ROUTE;
           community add ATL01;
           community add NORTH-AMERICA;
           accept;
       }   
    


    Специалисты Cloudflare поняли, что что-то пошло не так в их сети из-за сбоя в работе маршрутизатора в Атланте, они изолировали это устройство из рабочей сети и перенаправили трафик сервиса по корректным маршрутам. Через некоторое время работа Cloudflare была полностью восстановлена.

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

    См. также:

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

      +7

      … к слову о централизации интернета.


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


      И странно что их архитектура не отрабатывает автоматически разрыв связи между ДЦ и перераспределение нагрузки.

        +4

        Статья оставляет ощущение, что всё висит на соплях и не очень квалифицированных дежурных инженерах.


        Интересно, сколько сотен гигабит маршрутизировал неверно настроенный агрегат?

          –3

          Видать, те же проблемы, что и у Боинга — наняли индусов с сертификатами?

            +5

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


            Это примерно как с водителем автобуса — он может много лет ездить плавно и быть вежливым (и об этом никто слова не скажет), но стоит ему всего один раз (за все эти годы) резко затормозить или кому-то нагрубить — сразу начнутся разговоры в духе "совсем водители автобусов охренели", а о годах плавных вежливых поездок вспомнят разве что единицы.

              +1

              Только у Cloudflare это уже третий случай падения за прошедший год.
              Правда до этого у них 6 лет всё нормально работало (как они сами заявляют во время первого падения в июле 2019).

                0

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

                  0

                  «Ничто так не поднимает боевой дух солдата, как вид его товарища, севшего в калошу».

            –3

            BGP… Протокол динамической маршрутизации…
            Он должен динамически перестроить маршруты, а не ждать когда инженер(?) с левым конфигом сломает интернет.

              +2
              BGP настраивается вручную с помощью правил и сетевых политик, их задают сетевые администраторы. Они задают, например, номер автономной системы и как найти соседние автономные системы и их номера. Нет какого-то единого центра, который раздает топологию Интернета всем остальным. Отсюда вывод: сбои в Интернете были, есть и будут происходить и дальше.
                –3

                BGP настраивается и он работает. Канал отрубился и BGP перестраивает маршруты. Так? С этим спорить не будете?
                Зачем лезть куда-то с кривыми конфигами, если правильно настроенный BGP должен сам отработать отваливание канала!?

                  0

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

                    0

                    Очень даже может быть

                    +7
                    Смотрите: канал отвалился между Ньюарком и Чикаго. Нагрузка автоматически перераспределилась между Атлантой и Вашингтоном. Всё замечательно.
                    Но администратор видит, что датацентр в Атланте не справляется с возросшей нагрузкой, BGP этого не понимает, поскольку маршрут всё таки есть. Человек переписывает правила BGP, чтобы снизить эту нагрузку и делает ошибку в командах. Может, не те строки скопировал из инструкции, абзацем ошибся. И всё, теперь BGP работает неправильно.
                +5

                Старая шутка: на то он и отказоустойчивый кластер, чтобы падать:)

                  0
                  Забавно, столько сервисов недоступных перечислено и ни слова про 1.1.1.1, недоступность которого просто убила доступность всего остального «живого» интернета. Лично у меня оно просто перестало даже отвечать на пинги, при этом проверил с рабочего ПК (хотя провайдер тот же по сути) — там оно было доступно.

                  Такие косяки просто недопустимы когда ты «замкнул» на себе половину интернета.
                    0
                    Гораздо интереснее, что аналогичным образом себя вел днс от гугла, который 8.8.8.8. Причем мой местный провайдерский тоже лег, с теми же симптомами — выдавал таймаут на бОльшую часть запросов и всё. Единственный, кто работал — днс от яндекса (но они, видимо, просто не успели обновить?)

                    И вот у меня вопрос: ладно, «исчезли» все, кто пользовался сервисами Cloudflare — это понятно и объяснимо, они или пользовались их днс или сидели за серверами, которые пользовались их днс. Но! Почему mail.ru не резолвился? Они же типа тут, местные.
                      0
                      DNS от Yandex тоже не работал, как раз dig'ал в этот момент все, что помнил, пытаясь найти рабочие.
                        0
                        Ну, значит мне повезло — я 77.88.8.8 использовал пока сбой шел, всё нужное — работало
                      +1

                      Справедливости ради, это выбор каждого — использовать 1.1.1.1 (а также остальные сервисы) или нет, никто насильно не заставляет, недоступность ресурсов которые через них проксируются — косяк не только Cloudflare но также и владельцев ресурсов.


                      Хочется HA — не стоит расчитывать на одного провайдера независимо от его крутизны и обещаний, у меня по умолчанию стоит ещё и 8.8.8.8 — и всё работало (теперь, наверное, ещё кого-то добавлю).


                      Что интересно — на пинги 1.1.1.1 таки отвечал, только вот время ответа было сначала ~130ms и чуть позже ~380ms (с потерями около 50%) вместо обычных 15ms, я сначала подумал что таки накрыло их мощнейшей DoS...

                      +4
                      Cloudflare заявила, что сожалеет об этом неумышленном сбое.

                      Работаю в сетевой компании и когда происходят какие-то аварии, потребители само собой начинают звонить диспетчеру, так вот не было ни одной(со слов диспетчеров) серьезной аварии, чтобы кто-нибудь из звонивших не сказал «вы должны были нас заранее предупредить что сегодня авария будет».
                        0

                        Изменения в конфигурации конечно же шли через патч в гите с автоматическим апдейтом после мержа и конечно патч сначала ревьюил кто-то еще.
                        Если все так, то волноваться нечего.)

                        • НЛО прилетело и опубликовало эту надпись здесь

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

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