Резюме

  • В публичном отчёте BGPMon говорилось, что проблемы с доступностью сервисов Google 12 марта 2015 года были связаны с утечкой маршрутов: префиксы Google были получены Hathway AS17488 и переданы Airtel AS9498, который затем распространил анонсы среди пиров [1].
  • Наблюдаемое окно было коротким — с 08:58 до 09:14 UTC, однако BGPMon сообщил о 336 затронутых IPv4-префиксах Google, включая префиксы нескольких автономных систем Google [1].
  • Позже RFC 7908 использовал утечку Hathway–Airtel как пример утечки маршрутов, при которой префиксы пира передаются транзитному провайдеру и вызывают масштабные перебои в работе сервисов Google в Европе и Азии [2].
  • Статья не утверждает злого умысла, точных потерь клиентов или полной внутренней первопричины. Поверхность ответственности уже: приём маршрутов от клиента, экспорт в сторону транзита и пиров, проверка отношений, сигналы об утечках маршрутов и сохранённые доказательства.

Что произошло

BGPMon описал публичный сигнал как перебой в работе сервисов Google. Его отчёт начался с сообщений пользователей и публикации в прессе о том, что в основном пострадали пользователи в Европе и Индии. Затем BGPMon использовал свои данные BGP и выявил изменение маршрутизации: пути многих префиксов Google сместились и стали включать Airtel AS9498 в Индии в период с 08:58 до 09:14 UTC [1].

Важнее всего деталь AS-path. BGPMon писал, что префиксы по-прежнему анонсировались Google AS15169. Это означает, что событие не было простым перехватом источника маршрута, при котором другая сеть выдавала бы себя за Google. Вместо этого, по данным BGPMon, Google имел пиринг с Hathway AS17488, Hathway передал маршруты своему транзитному провайдеру Airtel AS9498, а Airtel распространил анонсы среди пиров на точках обмена интернет-трафиком [1].

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

RFC 7908 даёт терминологию для этого класса сбоев. Он определяет утечку маршрутов как анонсы маршрутизации, распространённые за пределы предполагаемой области, где предполагаемая область задаётся политиками импорта и экспорта между автономными системами. RFC привёл утечку Hathway–Airtel с 336 префиксами Google как наблюдаемый пример и поместил её в таксономию утечек маршрутов, а не в общую категорию сбоев [2].

У публичных доказательств есть границы. Данные BGPMon подтверждают путь, число префиксов и временное окно, которые он наблюдал. Они не публикуют карты маршрутов Hathway, политику импорта Airtel, внутреннюю телеметрию Google, процесс принятия решений каждого пира или какое-либо юридическое распределение ответственности. Поэтому статья Daniel должна избегать чрезмерных утверждений. Сильное утверждение: публичные данные о маршрутизации показали сбой контроля отношений и распространения.

Более слабое и неподтверждённое утверждение: каждого пострадавшего пользователя, бизнес-потери и решения операторов можно восстановить только по публичным данным BGP.

Почему это важно

Этот инцидент по-прежнему полезен, потому что показывает, как на платформу облачного масштаба может повлиять небольшое число решений по маршрутизации за пределами её собственной сети. Google владел сервисом и анонсировал префиксы. Однако если маршрут, полученный от пира, был передан транзитному провайдеру и затем предпочтён другими сетями, пользователи могли потерять обычную доступность, хотя Google не совершал исходной ошибки маршрутизации.

Это делает цепочку ответственности многосторонней. Поверхностью контроля Hathway был маршрут, который он изучил, принял и экспортировал. Поверхностью контроля Airtel было то, принял ли он маршрут от Hathway как клиентскую или пиринговую доступность и экспортировал ли его затем пирам. Поверхностью контроля других сетей было то, предпочли ли они путь через Airtel своему обычному маршруту до Google. Поверхностью контроля Google были мониторинг и координация с пирами, но сама утечка маршрутов находилась на границе «клиент — транзит», описанной BGPMon [1].

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

Инцидент также показывает, почему безопасность маршрутизации не может остановиться на проверке источника RPKI. Если источником остаётся Google AS15169, проверка только источника может пройти, хотя путь всё ещё неверен. Подотчётность за утечку маршрутов касается пути и отношения, а не только держателя префикса. Важные вопросы: был ли маршрут получен от нужного соседа, было ли разрешено ему покинуть эти соседские отношения и имели ли нижестоящие сети достаточно доказательств, чтобы отклонить путь.

Технический уровень

Простейшая модель — реестр маршрутной политики. Сеть должна знать, какие префиксы может отправлять каждый клиент, пир и провайдер и куда эти маршруты можно экспортировать. Если клиент отправляет собственный префикс, провайдер может его нести. Если пир отправляет маршрут, принимающая сеть, как правило, не должна превращать этот маршрут в транзит для другого провайдера или пира. Точное коммерческое отношение может быть сложным, но политика маршрутизатора всё равно должна его кодировать.

В отчёте BGPMon говорилось, что затронутый путь включал Google AS15169, Hathway AS17488 и Airtel AS9498. Там же сказано, что Airtel распространил анонсы среди пиров на точках обмена интернет-трафиком и что некоторые сети могли предпочесть путь через Airtel, поскольку клиентские маршруты могут быть предпочтительнее пиринговых [1]. Это наблюдение помещает инцидент на границу между локальными предпочтениями, экономикой «клиент/провайдер» и фильтрацией утечек маршрутов.

Первый элемент контроля — авторизация префиксов. Провайдер должен знать, какие префиксы клиент уполномочен анонсировать или пропускать транзитом. Если Hathway не был уполномочен обеспечивать транзит для этих префиксов Google в сторону Airtel, маршрут следовало отклонить или по крайней мере задержать для проверки.

Второй элемент контроля — тегирование отношений. Маршрут, полученный от пира, должен нести тег происхождения, который не позволяет экспортировать его так, будто это клиентская доступность. Маршрут, полученный от клиента, следует проверять на соответствие ожидаемой принадлежности префиксов, route-объектам, историческим путям и явному разрешению клиента.

Третий элемент контроля — политика экспорта. Даже если маршрут принят для локального использования, он не должен автоматически отправляться каждому пиру. Политика экспорта должна отвечать на более узкий вопрос: подходит ли этот маршрут для этого соседа в рамках данных отношений?

Четвёртый элемент контроля — обнаружение утечек маршрутов. Короткую утечку всё равно можно измерить. Полезная запись включает время первого и последнего появления, AS-путь, затронутые префиксы, коллекторы маршрутов, изменения локальных предпочтений, отзывы маршрутов и проверки коллекторов после устранения. Окно с 08:58 до 09:14 UTC, зафиксированное BGPMon, — именно тот публичный временной интервал, который операторы должны уметь сопоставлять с внутренними журналами [1].

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

Кто пострадал

В статье BGPMon говорилось, что, судя по сообщениям, в основном пострадали пользователи в Европе и Индии, и делался вывод, что утечка была замечена только в Европе, что согласуется с упомянутыми в ней отчётами в Twitter [1]. В RFC 7908 использована более широкая формулировка о перебоях в работе сервисов Google в Европе и Азии [2]. Более поздний материал Vice описывал событие как глобальный сбой Google и использовал инцидент, чтобы объяснить, как глобальная система маршрутизации может превращать выбор маршрутов в видимые пользователям сбои [3].

Эти источники оправдывают формулировку о влиянии на доступность. Они не оправдывают выдуманные подсчёты пользователей, суммы компенсаций, внутренние потери Google или утверждение, что все сервисы Google не работали по всему миру. Безопасная формулировка: публичные наблюдатели маршрутов и публичные отчёты связали событие с проблемами доступности сервисов Google, а самые ясные технические доказательства дают путь маршрута и данные о префиксах.

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

Стандарт подотчётности

Для Hathway закрывающие доказательства должны начинаться с сессии, на которой были получены маршруты Google, и сессии, на которой они были экспортированы. Они должны показывать карты маршрутов, списки префиксов, классификацию отношений, записи об исключениях, проверки route-объектов и хронологию отзыва маршрутов.

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

Для пострадавших пиров доказательства должны включать, почему путь через Airtel был предпочтён прямым или обычным путям до Google. BGPMon предположил локальное предпочтение клиентских маршрутов как одну из возможных причин [1]. Это уже взаимодействие бизнеса и маршрутизации, а не просто программная ошибка. Вопрос подотчётности в том, может ли политика предпочтений усилить аномальный путь быстрее, чем мониторинг успеет его заметить.

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

Область доктрины Heng.lu — BGP/маршрутизация и доказательства сетевых ресурсов. Реестр может сказать, кто держит префикс или автономную систему, но действующая маршрутная политика решает, куда фактически идёт трафик. Поэтому реестр маршрутов должен связывать права из реестра, отношения между автономными системами, политику маршрутизаторов и операционную непрерывность. Правильного источника недостаточно, если путь нарушает предполагаемые отношения.

За чем следить дальше

Первый сигнал — могут ли операторы назвать сбойный класс маршрутов. Расплывчатого заявления о том, что маршрутизация исправлена, недостаточно. Публичная запись должна говорить, была ли проблема в фильтрации клиентских префиксов, экспорте пиринговых маршрутов, локальных предпочтениях, генерации route-объектов, настройке max-prefix или во временном исключении, которое не было ограничено.

Второй сигнал — развёрнуты ли механизмы контроля, учитывающие отношения. RFC 7908 описал постановку проблемы. Более поздние механизмы, такие как BGP Roles и Only-to-Customer, а также авторизация путей в стиле ASPA, движутся в направлении, которого требует этот инцидент: маршрутная политика должна представлять область отношений «провайдер/клиент/пир», а не полагаться только на память и ручные фильтры.

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

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

Изменение сценариев

Оценка становится более серьёзной, если доказательства показывают, что маршрут был принят, несмотря на явные несоответствия в авторизации префиксов, что сигналы сработали и были проигнорированы, что тот же класс отношений снова дал утечку или что публичные сообщения опустили AS-путь и данные о префиксах после видимого вреда для пользователей.

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

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

Источники

[1] BGPMon, «Что вызвало перебои в работе сервисов Google?»,https://www.bgpmon.net/what-caused-the-google-service-interruption/

[2] RFC 7908, «Определение проблемы и классификация утечек BGP-маршрутов»,https://www.rfc-editor.org/rfc/rfc7908.txt

[3] Vice, «Анатомия глобального сбоя Google»,https://www.vice.com/en/article/anatomy-of-a-globe-spanning-google-outage/