Route Server

Назначение

Cлужба Route Server (RS) - сетевой сервис, позволяющий упростить пиринговое взаимодействие между участниками MSK-IX и сократить количество индивидуальных администрируемых пиринговых сессий. RS передает BGP-анонсы между подключенными к нему участниками. Таким образом, пиринг с RS позволяет установить пиринговое взаимодействие со всеми остальными участниками MSK-IX, использующими RS.

Использование службы Route Server не влияет на сетевые задержки, так как трафик между интерфейсами участников передается напрямую.

Служба RS действует на общем (пиринговом) VLAN, поддерживает использование 16- и 32-битных номеров AS и позволяет вести обмен трафиком по протоколам IPv4 и IPv6.

Информация для настройки пиринговых сессий с RS

Примечания:

* В городах, для которых приведены адреса двух BGP-спикеров, аппаратная база RS состоит из двух дублирующих серверов, установленных на разнесенных технологических площадках.

** Процедура реконфигурации включает в себя запрос обновлений политик маршрутизации в базах IRR (RIPE и др.), построение/обновление фильтров и их применение в конфигурации RS. Процедура занимает до одного часа.

Как начать пользоваться RS?

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

Чтобы начать пользоваться RS в городе подключения к MSK-IX, настройте взаимодействие с соответствующей служебной автономной системой Route Server AS (см. таблицу выше) по протоколу BGP.

Для этого выполните следующие шаги:

1. Внесите описание политики взаимодействия вашей сети с Route Server AS в базу данных Internet Routing Registry (IRR), поддерживаемую MSK-IX (RIPE, ARIN, RADB).
2. Направьте с любого из авторизованных по договору контактных адресов на адрес noc@ix.ru заявку, содержащую город подключения к MSK-IX, идентификатор организации, номер AS участника и IP-адрес маршрутизатора (IPv4 и/или IPv6).
3. Настройте BGP-сессии со своей стороны со всеми BGP-спикерами службы RS в соответствующем городе.
4. В конфигурации BGP со своей стороны отключите проверку first-as командой no bgp enforce-first-as (или ее аналогами для вашего вендора).

Информация об использовании RS участниками MSK-IX, доступна в Клиентском кабинете MSK-IX.

Информация о политике маршрутизации Route Server AS содержится в базе RIPE (сайт https://www.ripe.net или утилита whois -h whois.ripe.net as[Номер AS]).

Для отладки маршрутизации и контроля BGP-анонсов, принимаемых RS, пользуйтесь службой Looking Glass.

Политика маршрутизации RS

Обмен роутинговой информацией между RS и каждым участником осуществляется по протоколу BGP4, описанном в RFC4271. Пиры RS получают от RS лучший выбранный маршрут из принятых от всех пиров. При передаче BGP-анонса от RS атрибут Next-Hop содержит IP-адрес того маршрутизатора, от которого данный анонс были получен RS; атрибут AS_PATH передается без изменений. Таким образом, обмен трафиком участников происходит напрямую, минуя RS.

RS обрабатывает BGP-анонсы по следующим принципам:

1. Не принимаются анонсы приватных сетей, маршрута по умолчанию (default route), прочих сетей специального назначения (RFC6890).
2. Не принимаются анонсы приватных AS и AS специального назначения (RFC5398, RFC6996, RFC7300, RFC7607).
3. Не принимаются анонсы сетей, для которых значение origin объекта route/route6 в базе данных IRR не совпадает с номером начальной AS в атрибуте AS_PATH анонса.
4. Не принимаются анонсы сетей, для которых номер последней добавленной AS в атрибуте AS_PATH анонса не совпадает с номером AS участника, с которым установлена BGP-сессия.

5. Осуществляется проверка валидности анонсов с точки зрения технологии RPKI (RFC6480), проставляется соответствующее BGP-community по результатам проверки.

   1. Анонс со статусом RPKI_VALID принимается, если его AS входит в as-set или равна aut-num, которые указаны в export или mp-export политике взаимодействия AS участника с AS роут-сервера.
   2. Анонсы со статусом RPKI_INVALID не принимаются.
   3. Анонсы со статусом RPKI_UNKNOWN проверяются по пунктам 6-7.
6. Анонс принимается, если для него описан route/route6 объект в IRR DB, входящий в as-set или aut-num, которые указаны в export или mp-export политике взаимодействия AS участника с AS роут-сервера. Размер префикса route/route6 объекта и BGP-анонса должны совпадать, за исключением пункта 7.
7. Анонс принимается, если для него не описан route/route6 объект в IRR DB, но при этом описан route/route6 агрегата данного префикса, удовлетворяющий требованиям пункта 6. Анонсы, удовлетворяющие критериям пункта 7, дополнительно маркируются специальным BGP-community (RSAS:65500).

Атрибуты BGP community

Здесь и далее RSAS означает номер Route Server AS в соответствующем городе.

Route Server поддерживает две группы атрибутов BGP community: базовые и дополнительные. Атрибуты базовой группы действуют в порядке, приведенном в таблице. Приоритет обработки управляющих BGP Community: Large > Standard.

Базовые

Дополнительные

Примечания:

1. В случае отсутствия атрибута BGP community или при его несоответствии указанному списку, префикс принимается и передается всем участникам.
2. В Looking Glass в детальной информации по префиксам отображаются только базовые BGP community. Для дополнительных BGP community отображается результат их применения.
3. При передаче анонсов через RS атрибуты управляющих community MSK-IX вырезаются, остальные BGP community передаются прозрачно.
4. Все анонсы имеют по умолчанию local-preference 100.
5. BGP community RSAS:65500 применяется для маркировки префиксов, для которых в IRR описан агрегат (более широкая сеть), и при этом сами префиксы не описаны в IRR.
   • IPv4: Данное BGP community применяется для префиксов до /24 включительно. Префиксы от /25 до /32 этим BGP community не маркируются и принимаются только если для них описан route объект в явном виде.
   • IPv6: Данное BGP community применяется для префиксов до /48 включительно. Префиксы от /49 до /128 этим BGP community не маркируются и принимаются только если для них описан route6 объект в явном виде.
6. Префиксы с атрибутом BGP no-export (65535:65281) прозрачно передаются участникам с сохранением атрибута.

Особенности работы с управляющими BGP Standard Community в случае 32-битных номеров AS

Если вы используете управляющие BGP Large Community, данная таблица не применяется.

Для построения политики взаимодействия с участниками MSK-IX, использующими 32-битные номера автономных систем, воспользуйтесь приведенной ниже таблицей соответствия номера AS участника и номера community, который необходимо использовать в качестве peer-as (см. описание базовых BGP community).

Защита от DDoS-атак методом Blackholing

MSK-IX предоставляет своим участникам механизм защиты от DDoS-атак методом Blackholing. Данный механизм позволяет участнику на время атаки полностью отфильтровать входящий трафик на атакуемый префикс своей сети в рамках BGP-сессий, установленных с RS.

Фильтрация трафика производится путем замены Next-hop в полученных от участника BGP-анонсах на адрес фильтрующего интерфейса (Blackhole) сетей MSK-IX. Замена Next-hop производится RS автоматически, при получении от участника анонса с установленным Blackhole community 65535:666. При снятии атрибута Blackhole community маршруты трафика на данный префикс автоматически восстанавливаются.

Примечания:

1. Атрибут 65535:666 для Blackhole Community используется в соответствии с RFC 7999.
2. Для протокола IPv4 RS принимает сети с атрибутом 65535:666 размером от /25 до /32 включительно. Во избежание ошибок рекомендуется использовать /32.
3. Для протокола IPv6 RS принимает сети с атрибутом 65535:666 размером от /49 до /128 включительно. Во избежание ошибок рекомендуется использовать /128.
4. Участникам, пользующимся RS, рекомендуется настроить прием от RS анонсов сетей с атрибутом 65535:666 размером от /25 до /32 включительно для IPv4 и от /49 до /128 включительно для IPv6.
5. В соответствии с политикой региональных интернет-регистратур RIR (RIPE, RADB, и т.д.) Blackhole community может быть установлено только на уже анонсируемые Участником сети. RS принимает от Участника анонсы сетей с атрибутом 65535:666 только если данные сети также анонсируются Участником без атрибута 65535:666.

Параметры фильтрующего интерфейса Blackhole

Протокол быстрой сходимости BFD

Протокол Bidirectional Forwarding Detection (BFD) предназначен для быстрого определения нарушения возможности прохождения пакетов через сети передачи данных и перестроения маршрутизации на альтернативные пути. Протокол поддерживается всеми серверами службы Route Server проектов MSK-IX.

Для активации протокола BFD в рамках BGP-взаимодействия с Route Server пришлите на адрес noc@ix.ru заявку с адреса технического или административного представителя Вашей организации.

Таймеры и параметры протокола BFD (значения по умолчанию)*

Примечания:

* Если вы хотите использовать другие таймеры BFD, согласуйте их с техническими представителями MSK-IX.

Cостояние BFD сессий с Route Server можно увидеть в Looking Glass MSK-IX в разделах Summary и Neighbor Info.