Мнение Cloudflare об отключении OVHcloud 30 октября
30 октября 2024 года поставщик облачного хостинга OVHcloud (AS16276) столкнулся с кратковременным, но значительным отключением. Согласно их отчету об инциденте, проблема началась в 13:23 UTC и была описана просто как « Происходит инцидент на нашей магистральной инфраструктуре ». OVHcloud отметил, что инцидент закончился 17 минут спустя, в 13:40 UTC. Как крупный глобальный поставщик облачного хостинга, некоторые клиенты используют OVHcloud в качестве источника для сайтов, предоставляемых Cloudflare — если заданный контент-актив отсутствует в нашем кэше для сайта клиента, мы извлекаем актив из OVHcloud.
Мы наблюдали, как трафик начал падать в 13:21 UTC, как раз перед заявленным временем начала. К 13:28 UTC он был примерно на 95% ниже, чем до инцидента. Восстановление, по-видимому, началось в 13:31 UTC, а к 13:40 UTC, заявленному времени окончания инцидента, он достиг примерно 50% от уровня до инцидента.
Cloudflare обычно обменивается большей частью своего трафика с OVHcloud по пиринговым ссылкам. Однако, как показано ниже, объем пирингового трафика во время инцидента значительно упал. Похоже, что некоторый небольшой объем трафика на короткое время начал проходить по транзитным ссылкам из Cloudflare в OVHcloud из-за внезапных изменений в дата-центрах Cloudflare, в которых мы получали запросы OVHcloud. (Пиринг — это прямое соединение между двумя сетевыми провайдерами с целью обмена трафиком. Транзит — это когда одна сеть платит промежуточной сети за передачу трафика в сеть назначения.)
Поскольку мы пирингуем напрямую, мы обмениваемся большей частью трафика через наши частные сеансы пирингования с OVHcloud. Вместо этого мы обнаружили, что маршрутизация OVHcloud в Cloudflare полностью прекратилась на несколько минут, затем переключилась на один порт Internet Exchange в Амстердаме и, наконец, нормализовалась глобально через несколько минут.
Как показывают графики ниже, мы обычно видим наибольший объем трафика от OVHcloud в наших центрах обработки данных во Франкфурте и Париже, поскольку OVHcloud имеет крупные центры обработки данных в этих регионах. Однако при этом переходе к транзиту и переходе к точке обмена данными Amsterdam Internet Exchange мы увидели всплеск трафика, направляемого в наш центр обработки данных в Амстердаме. Мы подозреваем, что изменения маршрутизации являются самыми ранними признаками либо внутренней реконвергенции BGP, либо общего восстановления сети в пределах AS12676, начиная с их присутствия вблизи нашей точки обмена данными в Амстердаме.
В отчете о расследовании, опубликованном OVHcloud, отмечается, что инцидент был вызван « проблемой в конфигурации сети, ошибочно допущенной одним из наших пиринговых партнеров », и что « мы немедленно перенастроили наши сетевые маршруты для восстановления трафика ». Одним из возможных объяснений инцидента с магистральной сетью может быть утечка маршрута BGP упомянутым пиринговым партнером, когда OVHcloud мог принять полную таблицу Интернета от однорангового узла и, следовательно, перегрузить свою сеть или сеть пирингового партнера трафиком или вызвать неожиданные внутренние обновления маршрута BGP в AS12676.
При расследовании того, какая утечка маршрута могла стать причиной инцидента, затронувшего OVHcloud, мы обнаружили доказательства нарушения максимального порогового значения префикса на нашем пиринге с Worldstream (AS49981) в Амстердаме.
Поскольку количество полученных префиксов превысило лимиты, настроенные для нашего пирингового сеанса с Worldstream, сеанс BGP автоматически перешел в состояние ожидания. Это предотвратило влияние утечки маршрута на сеть Cloudflare. При анализе данных протокола мониторинга BGP (BMP) из AS49981 до автоматического отключения сеанса мы смогли подтвердить, что Worldstream отправлял объявления с AS-путями, которые содержали их транзитного провайдера Tier 1 восходящего потока.
За это время мы также обнаружили более 500 000 объявлений BGP от AS49981, поскольку Worldstream объявлял маршруты многим своим одноранговым узлам, что видно на Cloudflare Radar.
Позже Worldstream разместил на своей странице статуса уведомление, в котором говорилось, что в их сети произошла утечка маршрутов, в результате чего маршруты были непреднамеренно объявлены всем одноранговым узлам:
Мы полагаем, что Worldstream также раскрыл маршруты в ходе пиринговой сессии OVHcloud в Амстердаме, что и привело к сегодняшним последствиям.
Заключение
Cloudflare уже писала о существенных утечках маршрутов, и существует несколько методов, позволяющих предотвратить влияние утечек маршрутов BGP на вашу сеть. Один из них — установить максимальные ограничения префиксов для однорангового узла, чтобы сеанс BGP автоматически разрывался, когда одноранговый узел отправляет больше префиксов, чем ожидается. Другие перспективные меры — это Autonomous System Provider Authorization (ASPA) для BGP, где Resource Public Key Infrastructure (RPKI) помогает защитить сеть от принятия маршрутов BGP с недействительным путем AS, или RFC9234, который предотвращает утечки, привязывая строгие отношения между клиентами и поставщиками к обновлениям BGP. Для повышения устойчивости Интернета мы рекомендуем операторам сетей следовать рекомендациям, определенным в MANRS для операторов сетей manrs.org/netops/
Мы наблюдали, как трафик начал падать в 13:21 UTC, как раз перед заявленным временем начала. К 13:28 UTC он был примерно на 95% ниже, чем до инцидента. Восстановление, по-видимому, началось в 13:31 UTC, а к 13:40 UTC, заявленному времени окончания инцидента, он достиг примерно 50% от уровня до инцидента.
Cloudflare обычно обменивается большей частью своего трафика с OVHcloud по пиринговым ссылкам. Однако, как показано ниже, объем пирингового трафика во время инцидента значительно упал. Похоже, что некоторый небольшой объем трафика на короткое время начал проходить по транзитным ссылкам из Cloudflare в OVHcloud из-за внезапных изменений в дата-центрах Cloudflare, в которых мы получали запросы OVHcloud. (Пиринг — это прямое соединение между двумя сетевыми провайдерами с целью обмена трафиком. Транзит — это когда одна сеть платит промежуточной сети за передачу трафика в сеть назначения.)
Поскольку мы пирингуем напрямую, мы обмениваемся большей частью трафика через наши частные сеансы пирингования с OVHcloud. Вместо этого мы обнаружили, что маршрутизация OVHcloud в Cloudflare полностью прекратилась на несколько минут, затем переключилась на один порт Internet Exchange в Амстердаме и, наконец, нормализовалась глобально через несколько минут.
Как показывают графики ниже, мы обычно видим наибольший объем трафика от OVHcloud в наших центрах обработки данных во Франкфурте и Париже, поскольку OVHcloud имеет крупные центры обработки данных в этих регионах. Однако при этом переходе к транзиту и переходе к точке обмена данными Amsterdam Internet Exchange мы увидели всплеск трафика, направляемого в наш центр обработки данных в Амстердаме. Мы подозреваем, что изменения маршрутизации являются самыми ранними признаками либо внутренней реконвергенции BGP, либо общего восстановления сети в пределах AS12676, начиная с их присутствия вблизи нашей точки обмена данными в Амстердаме.
В отчете о расследовании, опубликованном OVHcloud, отмечается, что инцидент был вызван « проблемой в конфигурации сети, ошибочно допущенной одним из наших пиринговых партнеров », и что « мы немедленно перенастроили наши сетевые маршруты для восстановления трафика ». Одним из возможных объяснений инцидента с магистральной сетью может быть утечка маршрута BGP упомянутым пиринговым партнером, когда OVHcloud мог принять полную таблицу Интернета от однорангового узла и, следовательно, перегрузить свою сеть или сеть пирингового партнера трафиком или вызвать неожиданные внутренние обновления маршрута BGP в AS12676.
При расследовании того, какая утечка маршрута могла стать причиной инцидента, затронувшего OVHcloud, мы обнаружили доказательства нарушения максимального порогового значения префикса на нашем пиринге с Worldstream (AS49981) в Амстердаме.
Oct 30 13:16:53 edge02.ams01 rpd[9669]: RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 141.101.65.53 (External AS 49981) changed state from Established to Idle (event PrefixLimitExceeded) (instance master)Поскольку количество полученных префиксов превысило лимиты, настроенные для нашего пирингового сеанса с Worldstream, сеанс BGP автоматически перешел в состояние ожидания. Это предотвратило влияние утечки маршрута на сеть Cloudflare. При анализе данных протокола мониторинга BGP (BMP) из AS49981 до автоматического отключения сеанса мы смогли подтвердить, что Worldstream отправлял объявления с AS-путями, которые содержали их транзитного провайдера Tier 1 восходящего потока.
За это время мы также обнаружили более 500 000 объявлений BGP от AS49981, поскольку Worldstream объявлял маршруты многим своим одноранговым узлам, что видно на Cloudflare Radar.
Позже Worldstream разместил на своей странице статуса уведомление, в котором говорилось, что в их сети произошла утечка маршрутов, в результате чего маршруты были непреднамеренно объявлены всем одноранговым узлам:
Из-за ошибки конфигурации на одном из основных маршрутизаторов все маршруты были на короткое время объявлены всем нашим одноранговым узлам. В результате мы получили больше трафика, чем ожидалось, что привело к перегрузке на некоторых путях. Чтобы решить эту проблему, мы временно отключили эти сеансы BGP, чтобы локализовать проблему и стабилизировать сеть. Приносим извинения за неудобства
Мы полагаем, что Worldstream также раскрыл маршруты в ходе пиринговой сессии OVHcloud в Амстердаме, что и привело к сегодняшним последствиям.
Заключение
Cloudflare уже писала о существенных утечках маршрутов, и существует несколько методов, позволяющих предотвратить влияние утечек маршрутов BGP на вашу сеть. Один из них — установить максимальные ограничения префиксов для однорангового узла, чтобы сеанс BGP автоматически разрывался, когда одноранговый узел отправляет больше префиксов, чем ожидается. Другие перспективные меры — это Autonomous System Provider Authorization (ASPA) для BGP, где Resource Public Key Infrastructure (RPKI) помогает защитить сеть от принятия маршрутов BGP с недействительным путем AS, или RFC9234, который предотвращает утечки, привязывая строгие отношения между клиентами и поставщиками к обновлениям BGP. Для повышения устойчивости Интернета мы рекомендуем операторам сетей следовать рекомендациям, определенным в MANRS для операторов сетей manrs.org/netops/
