Selectel IPv4 prefix route leaking - Академия Selectel

Selectel IPv4 prefix route leaking

Кирилл Малеванов Кирилл Малеванов Технический директор 22 мая 2018

В ночь с 15 на 16 июля 2017 в сети Selectel случилось одно из наиболее запомнившихся событий, которое привело к ухудшению (вплоть до полной недоступности) связности сети Selectel с зарубежным сегментом интернета. И это настолько запомнилось, что этому случаю было посвящено выступление технического директора Selectel на конференции сетевых операторов ENOG-14. Но обо всём по порядку. […]

Изображение записи

В ночь с 15 на 16 июля 2017 в сети Selectel случилось одно из наиболее запомнившихся событий, которое привело к ухудшению (вплоть до полной недоступности) связности сети Selectel с зарубежным сегментом интернета. И это настолько запомнилось, что этому случаю было посвящено выступление технического директора Selectel на конференции сетевых операторов ENOG-14.

Но обо всём по порядку.

Описание сети

На тот момент сеть Selectel выглядела следующим образом. Selectel присутствует в двух городах РФ — Санкт-Петербурге и Москве, в каждом городе есть два пограничных маршрутизатора.

Каждый из маршрутизаторов анонсирует «в мир» сети Selectel от автономной системы AS 49505. К каждому из маршрутизаторов подключены аплинки и пиринги.

Крупнейшие аплинки Selectel — ТрансТелеком, РЕТН и Раском.
Крупнейшие пиринговые точки, к которым подключена сеть Selectel — MSK-IX, DATA-IX, DE-CIX.

На некоторых пиринговых точках (в частности, MSK-IX, DATA-IX и другие) использовались more-specific префиксы для увеличения объема входящего трафика через эти точки обмена. На DE-CIX more-specific префиксы не использовались.

Автономная система 49505 используется также для предоставления распределённой сети DNS-серверов. Серверы размещены в нескольких странах на разных аплинках, с серверов анонсируются две подсети /24 с использованием BGP anycast.

Internet Exchange

Internet Exchange (IX), точка обмена трафиком — это пиринговая сеть для разных сетевых операторов, представляющая собой один логический коммутатор, к которому подключены все операторы, и пару серверов, обеспечивающих общее распространение маршрутной информации между участниками точки обмена трафиком (роут-серверы, RS).

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

Blackhole

Blackhole, в переводе «чёрная дыра», это механизм, позволяющий операторам связи защищаться от DDoS на свои сети. Этот механизм не позволяет сохранить доступность атакованного ресурса, но, по крайней мере, направлен на сохранение работоспособности сети оператора, у которого располагается данный ресурс, или через которого данный ресурс доступен.

Для определения ресурсов, на которые надо не передавать трафик, операторами используется так-называемая blackhole community. В конце 2016 года эта коммьюнити была включена в RFC 7999 в список well-known communities (https://tools.ietf.org/html/rfc7999).

Обычно операторы очень осторожно применяют blackhole community, и, как правило, эта коммьюнити применяется только на /32 префиксы. Но настройки у некоторых точек обмена трафиком и у некоторых операторов позволяют приём blackhole-маршрутов с маской подсети, отличной от /32.

Александр Ильин, технический директор MSK-IX

MSK-IX внедрил услугу BGP Blackholing одним из первых на мировых точках обмена трафиком. Описанная коллегами из Selectel проблема нашу инфраструктуру не затронула, так как согласно правилам предоставления Blackhole на наших Route Serverах допустимы только маршруты от /25 до /32. В соответствии с политикой региональных интернет-регистратур RIR (RIPE, RADB, и т.д.) Blackhole community может быть установлено только на уже анонсируемые Участником сети. RS принимает от Участника анонсы сетей только если данные сети также анонсируются Участником без атрибута и такого рода ошибки будут отфильтрованы на входе. Мы также поддерживаем актуальную базу контактов участников и в подобных случаях оперативно блокируем нарушителей.

Александр Ильин, технический директор MSK-IX

Инцидент: первая кровь

Итак, всё произошло в ночь с 15 на 16 июля 2017 года. То есть, с субботы на воскресенье. Большинство сетевых инженеров, осмелюсь предположить, в ночь с субботы на воскресенье летом всё-таки отдыхают. В 0:30 (время тут и далее московское) техническому директору на мобильный телефон поступил звонок от дежурных инженеров технической поддержки Selectel: «Что-то странное происходит, мы пока не знаем что, но симптомы — клиенты жалуются на недоступность зарубежных серверов с серверов Selectel, или серверов в Selectel с зарубежных серверов. Плюс в офисной сети перестал работать мессенджер Slack».

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

0:30 — очень неудачное время поиска аномалий на графиках загрузки интернет-каналов. В это время, как правило, заканчивается ЧНН (час наибольшей нагрузки) на интернет-сетях, и падение трафика может быть вызвано не только аварийными причинами, но и обычным поведением в течение суток, и в целом не очень заметно.

С учётом недостаточности собранного материала и короткого времени диагностики проблемы, был сделан вывод «наверное, что-то сломалось в ТТК». После чего BGP-сессия с ТТК была деактивирована. Перестройка маршрутов привела к исправлению проблемы, Slack заработал, связность была восстановлена, клиенты начали подтверждать полную работоспособность сервиса. Техническая поддержка отправлена связываться с технической поддержкой ТрансТелекома.

Прерванный ночной сон был продолжен.

Инцидент: основная часть

Около 02:00 опять перестал работать мессенджер Slack из офисной сети, опять повторилась ситуация с недоступностью значимой части зарубежных ресурсов. Это при отключенном канале от ТрансТелекома, то-есть, или первое предположение было ошибочно (но почему тогда после отключения BGP-сессии с ТТК всё заработало?), или проблема получила дальнейшее распространение. Дежурные инженеры технической поддержки сообщили о массовых звонках клиентов с жалобами на недоступность ресурсов. Массовость звонков и анализ выданных клиентам подсетей показал, что проблемы касаются большинства используемых в сети Selectel IP-префиксов, то есть проблема носит глобальный характер, а не группируется на каком-то одном префиксе.

Техническая поддержка опять стала собирать результаты выполнения команды traceroute, как от серверов изнутри Selectel, так и от серверов снаружи.
Изучение трассировок показало, что проблемы локализуются в районе DE-CIX. Причем, есть значительная асимметрия проблемных потоков трафика. Если маршрут от Selectel к конечным ресурсам проходит через DE-CIX, то проблем может не наблюдаться. А вот если обратный маршрут проходит через DE-CIX, то проблема недоступности однозначно проявляется. Диагностика таких проблем очень часто усложнена асимметрией трафика и использованием ECMP у операторов. Например, один пакет из сети оператора А в сеть Selectel может быть отправлен через DE-CIX, второй — через DATA-IX, а третий через Cloud-IX.

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

Дальше инженеры стали внимательно анализировать информацию на looking glass различных операторов. Глаз зацепился за вывод информации с маршрутизаторов ТрансТелекома.

Selectel анонсирует префикс 188.93.16.0/21 своим аплинкам и more-specific префикс 188.93.16.0/22 на часть точек обмена трафиком. Для того, чтобы аплинки не брали more-specific префиксы “снаружи”, всем аплинкам анонсируются те же more-specific префиксы с коммунити no-export, т.е. внутри сетей аплинков эти префиксы должны присутствовать в RIB с best маршрутом на клиентскую сессию. Но при поднятой сессии с ТрансТелекомом было обнаружено, что на московском маршрутизаторе ТТК (с которым прямой сессии у Selectel не было в тот момент) присутствует селектеловский more-specific префикс, ведущий через некоторую автономную систему 2854.

Автономная система 2854 не числится в аплинках или пирингах Selectel, т.е. она никак не должна являться транзитной автономной системой для префиксов Selectel. Откуда в ТТК взялся этот префикс? Непонятно.

Смотрим на looking glass DE-CIX. Вот роут-сервер, вся информация соответствует ожиданиям.

Как и предполагалось, на роут-сервере префикс указывает сразу на маршрутизатор Selectel. More-specific префикса нет, Selectel не анонсирует more-specific на DE-CIX. Но что-то остановило от перехода к следующему looking glass, и маршрутная информация была запрошена с роут-сервера №2.

Ой!

Во-первых, на роут-сервере №2 откуда-то взялся more-specific префикс 188.93.16.0/22. Откуда он там взялся? AS path 2854 49505. То-есть, опять AS 2854 вдруг анонсирует префиксы Selectel через себя. Во-вторых, насторожило коммьюнити (65535, 666). Это же blackhole community! AS 2854 откуда-то берет more-specific префиксы Selectel, после чего отдаёт их в сторону роут-сервера №2 DE-CIX с установленной blackhole community!

Сравним вывод с РС1 и РС2 на DE-CIX:

Да. На РС1 нет more-specific, и маршрут идет сразу в Selectel, как и положено. На РС2 есть more-specific из 2854 с установленной blackhole community.

Логично, что маршрутизаторы операторов, которые берут маршруты с роут-серверов DE-CIX, «видят» маршрут в Selectel best’ом по more-specific префиксу, трафик на который фильтруется самим DE-CIX.

Когда примерно стало понятно, в чём заключается проблема маршрутизации через DE-CIX, в чат-группе связистов Санкт-Петербурга возникли вопросы «почему у нас тоже нет связи с некоторыми зарубежными ресурсами». Диагностика «по проторенной дорожке» показала, что опять таки проблема с AS 2854, которая анонсирует через себя очень много маршрутов, в том числе, на операторов Санкт-Петербурга, с использованием blackhole community. У ШПД операторов жалобы от абонентов стали обретать массовый характер только к утру, это специфика ШПД для физических лиц и времени возникновения проблем (напомню, ночь с субботы на воскресенье, лето — многие домашние пользователи в это время на дачах, в отпуске, спят).

Кто виноват

В ходе диагностики определён номер автономной системы, которая анонсирует некорректные маршруты на РС2 DE-CIX, AS 2854. Кто это? Эта информация нужна для того, чтобы оперативно смочь связаться с ними и сказать, что там делают «не дело». AS 2854 — это российская «дочка» глобального оператора Equant (он же Orange Business Services), ранее в РФ эта компания называлась Роспринт.

Естественно, на адрес noc@rosprint.net было отправлено письмо с описанием проблемы, на указанные телефоны стали звонить инженеры технической поддержки. Среди технических контактов был даже найден мобильный телефон одного из инженеров. Звонок на мобильный телефон инженеру желаемых результатов не дал. Инженер Роспринта оказался в отпуске и вообще где-то в районе озера Байкал, а не у компьютера. Звонки в техническую поддержку Роспринта сначала заканчивались предложением написать им письмо с описанием проблемы, а в понедельник «придут сетевики и может быть разберутся». Почтовый ящик noc@rosprint.net в нерабочее время, видимо, игнорируется. Дошло уже до того, что техническая поддержка Роспринта, услышав «я из компании Selectel», стала просто вешать трубку.

Что делать

Помимо того, что мы всеми силами пытались выйти на связь с инженерами Роспринта, предпринимались попытки как-то исправить ситуацию или уменьшить проблемы.
Первая попытка исправить ситуацию из самого Selectel. Надо отключить more-specific, тогда они не будут попадать на РС2 DE-CIX, где 100% становятся best-маршрутами для участников DE-CIX. Отключили. Да, эти маршруты перестали попадать на РС2, но теперь на РС2 были агрегированные маршруты до сетей Selectel. На РС1 был маршрут 188.93.16.0/21 через AS 49505 (правильный маршрут от Selectel), но на РС2 — маршрут 188.93.16.0/21 с AS path 2854 49505 и blackhole community.

Частично связность восстановилась, теперь на DE-CIX не стало more-specific маршрутов до сетей Selectel. Связность не восстановилась у тех операторов и от тех ресурсов, которые использовали маршруты с РС2 в качестве best, несмотря на AS path.
Ок. Мы не можем достучаться до инженеров Роспринта. Будем стучаться до других инженеров.

Попытка написать письмо с описанием проблемы, а потом позвонить для увеличения приоритета обращения в техническую поддержку DE-CIX, успеха не возымела.

Инженеры технической поддержки DE-CIX стали отрицать свою причастность к управлению маршрутной информацией на роут-серверах. Мы просили отключить Роспринт от роут-серверов DE-CIX, так как они посылают неверную информацию на роут-сервер, а мы не можем достучаться до инженеров Роспринта.

Тогда мы стали писать письма в MSK-IX и DATA-IX с просьбой отключить Роспринт (так как они осуществляют некорректные действия с префиксами с IX). И был расчет на то, что при падении двух крупных каналов на точки обмена трафиком техническая поддержка Роспринта будет обязана сообщить о данном происшествии сетевым инженерам, а те начнут разбираться.

Ночь прошла

Так, в диагностике и попытках связаться с Роспринтом прошла ночь. Вдруг в 11:26 (когда MSK-IX и DATA-IX тоже убедились в некорректности действий Роспринта и были готовы произвести отключение их от роут-серверов), пришло сообщение из Роспринта:

Вот и всё. Ни извините, ни контактов, ничего…

Уроки

Из происшедшего мы вынесли несколько уроков. К сожалению, уроки эти были достигнуты на своём опыте борьбы с нашими проблемами, но, надеюсь, чему-то в дальнейшем этот текст поможет и другим операторам:

  • На IX надо всегда смотреть два роут-сервера.
  • Связность до своей сети надо мониторить снаружи. Используя для мониторинга связности не просто ping/HTTP GET, а различные API сервисов, в том числе stat.ripe.net.
  • Наличие more-specific префиксов нам, вопреки распространённому среди операторов мнению об их вредности, помогло диагностировать проблему.
  • Заключая контракты на полосу интернет-трафика с аплинками, желательно предусматривать возможность работы с использованием только одного оператора, а не просто обеспечивать необходимое резервирование на случай выхода из строя одного из пограничных маршрутизаторов.
  • Anycast, если таковые сегменты есть, желательно отделять по автономной системе от основной сети.

Почему РС на DE-CIX принял маршруты на сети Selectel от AS 2854?

Потому что AS 49505 является членом AS-SET AS-URAL для anycast префиксов. А уже AS 2854 может анонсировать префиксы из AS-URAL.


Современные IT-системы и сети связи это постоянное взаимодействие пользователей и различных IT-сервисов, которые в свою очередь зависят/взаимодействуют с другими IT-сервисами как напрямую от пользователя (аутентификация по соцсетям и т.п.), так и напрямую между собой. Нарушение работы IT-сервисов, связанности их с пользователями или между собой сразу же сказывается на пользователях, причем зачастую неочевидным способом. Вариант «не работает совсем» является наиболее простым методом неисправности, другие же случаи требуют «траблшутинга» как со стороны сотрудников технической поддержки, взаимодействующих напрямую с пользователями/владельцами сервисов, так и инженеров. Что проще, разобраться детально или ответить «ошибка не в нашей зоне ответственности», «это интернет, тут никто ни за что не отвечает»? Да, ошибки/проблемы одних операторов связи могут сказываться на работе пользователей/сервисов, находящихся у других операторов связи, не имеющих никаких прямых отношений с «источником проблемы», через сети которого трафик даже не идет транзитом. Отдельной проблемой является то, что операторы связи имеют персонал разного уровня квалификации, не говоря уже о сотрудниках, работающих в ночное время и выходные дни, различные политики эскалирования проблемы, т.к. для оператора связи первичны подключенные к нему пользователи/сервисы, а решение эскалировать «чужую» проблему своим системным администратором, а может сперва и Руководству, в ночное время зависит уже от конкретного дежурного, от реакции его коллег на предыдущие эскалации и т.п. Зачастую единственным вариантом быстрой эскалации проблемы являются прямые контакты руководителей и администраторов операторов связи, возможность пройти по цепочке контактов и выйти на нужного сотрудника. В чужой монастырь со своим уставом ходить не принято, так что тут инициативу на себя могут взять или национальные организации, либо уже признанные международные организации, например RIPE для региона Европа-Россия, установив общие для всех своих членов «правила игры».

Алексей Кузнецов, заместитель начальника УСИТ СПбГУ