Точка обмена трафиком: от истоков к созданию собственной IX

«We set up a telephone connection between us and the guys at SRI…», Kleinrock… said in an interview:
«We typed the L and we asked on the phone, „Do you see the L?“»
«Yes, we see the L,» came the response.
«We typed the O, and we asked, „Do you see the O.“»
«Yes, we see the O.»
«Then we typed the G, and the system crashed»…

Yet a revolution had begun…

The beginning of the internet.

Всем привет!

Меня зовут Александр, я сетевой инженер в компании Linxdatacenter. В сегодняшней статье речь пойдет про точки обмена трафиком (Internet Exchange Point, IXP): о том, что предшествовало их появлению, какие задачи они решают и как строятся. Также в данной статье я продемонстрирую принцип работы IXP с помощью платформы EVE-NG и программного маршрутизатора BIRD, чтобы было понимание, как это работает «под капотом».

Немного истории

Если посмотреть сюда, то можно заметить, что бурный рост количества точек обмена трафиком начался в 1993 году. Это связано с тем, что большинство трафика существовавших на тот момент операторов связи проходило через backbone-сеть США. Так, например, когда трафик шел от оператора во Франции до оператора в Германии, он из Франции сначала попадал в США, и только потом из США в Германию. Backbone-сеть в данном случае выступала транзитом между Францией и Германией. Даже трафик внутри одной страны часто проходил не напрямую, а через опорные сети американских операторов.

Такое положение вещей сказывалось не только на стоимости доставки транзитного трафика, но и на качестве каналов и задержке. Количество пользователей сети Интернет увеличивалось, появлялись новые операторы, объем трафика возрастал, интернет взрослел. Операторы по всему миру начали понимать, что нужен более рациональный подход к организации межоператорского взаимодействия. «Зачем мне, оператору А, платить за транзит через другую страну, чтобы доставить трафик оператору Б, который располагается на соседней улице?». Примерно такой вопрос задавали себе операторы связи в то время. Так, в разных частях мира в точках концентрации операторов начали появляться точки обмена трафиком:

• 1994 – LINX в Лондоне,
• 1995 – DE-CIX во Франкфурте,
• 1995 – MSK-IX, в Москве и т.д.

Интернет и наши дни

Концептуально архитектура современного интернета представляет из себя множество автономных систем (autonomous system, AS) и множество связей между ними, как физических, так и логических, которые определяют путь прохождения трафика от одной AS к другой.

В качестве AS обычно выступают операторы связи, интернет-провайдеры, CDN, дата-центры, компании энтерпрайз сегмента. AS организуют логические связи (peering) между собой, как правило, средствами протокола BGP.

То, как автономные системы организуют эти связи, определяется рядом факторов:

• географическими,
• экономическими,
• политическими,
• договоренностями и общими интересами между владельцами AS,
• и т.д.

Конечно, в данной схеме есть определенная структура и иерархия. Так, операторы делятся на tier-1, tier-2 и tier-3, и если клиентами для местного интернет-провайдера (tier-3) являются, как правило, обычные пользователи, то, например, для операторов уровня tier-1 клиентами являются другие операторы. Операторы tier-3 агрегируют на себе трафик своих абонентов, операторы связи tier-2, в свою очередь, агрегируют трафик tier-3 операторов, а tier-1 – весь интернет-трафик.

Схематически это можно представить так:

На данной картинке видно, что трафик агрегируется снизу вверх, т.е. от конечных пользователей к tier-1 операторам. Также имеет место горизонтальный обмен трафиком между примерно равнозначными между собой AS.

Неотъемлемой частью и одновременно недостатком данной схемы является некая беспорядочность связей между автономными системами, располагающимися ближе к конечному пользователю, в пределах географической зоны. Рассмотрим картинку ниже:

Предположим, что в крупном городе присутствует 5 операторов связи, пиринг между которыми, по тем или иным причинам, организован, как показано выше.

Если пользователь Петя, подключенный к интернет-провайдеру Go, захочет получить доступ к серверу, подключенному к провайдеру ASM, то трафик между ними будет вынужден проходить через 5 автономных систем. Таким образом увеличивается задержка, т.к. увеличивается количество сетевых устройств, через которые пойдет трафик, а также объем транзитного трафика на автономных системах между Go и ASM.

Как сократить количество транзитных AS, которые вынужден проходить трафик? Правильно – точка обмена трафиком.

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

Что такое точка обмена трафиком?

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

• уменьшить задержку,
• сократить количество транзитного трафика,
• оптимизировать маршрутизацию между AS.

Учитывая, что IXP присутствуют во многих крупных городах мира, то это все благоприятно сказывается и на сети Интернет в целом.

Если вышеописанную ситуацию с Петей решать с помощью IXP, то получится примерно так:

Как устроена точка обмена трафиком?

Как правило, IXP – это отдельная AS со своим блоком публичных IPv4/IPv6 адресов.

Сеть IXP чаще всего представляет из себя сплошной L2 домен. Иногда это просто VLAN, в котором размещаются все клиенты IXP. Когда же речь идет о более крупных, географически распределенных IXP, то для организации L2 домена могут использоваться такие технологии, как MPLS, VXLAN и т.д.

Элементы IXP

• СКС. Здесь ничего необычного: стойки, оптические кроссы, патч-панели.
• Коммутаторы – основа IXP. Порт коммутатора — точка входа в сеть IXP. Также коммутаторы выполняют часть функций по безопасности – фильтруют мусорный трафик, который не должен присутствовать на сети IXP. Как правило, коммутаторы подбираются исходя из требований к функционалу – надежность, поддерживаемая скорость портов, функции безопасности, поддержка sFlow и т.д.
• Route server (RS) – неотъемлемая и необходимая часть любой современной точки обмена трафиком. По принципу работы очень сильно напоминает route reflector в iBGP или designated router в OSPF и решает те же проблемы. По мере роста количества участников точки обмена трафиком, увеличивается количество BGP сессий, которое необходимо поддерживать каждому из участников, т.е. это напоминает классическую full-mesh топологию в iBGP. RS решает проблему следующим образом: устанавливает BGP-сессию с каждым заинтересованным участником IXP, и тот становится клиентом RS. Принимая BGP update от одного из своих клиентов, RS рассылает данный update всем остальным своим клиентам, разумеется, за исключением того, от которого данный update был получен. Таким образом, RS избавляет от необходимости устанавливать full-mesh между всеми участниками IXP и элегантно решает проблему масштабируемости. Стоит отметить, что сервер маршрутов прозрачно передает маршруты от одной AS к другой, не вноcя изменения в передаваемые BGP атрибуты, например не добавляет номер в своей AS в AS-path. Также на RS происходит базовая фильтрация маршрутов: например, RS не принимает martians networks и префиксы самой IXP.

  В качестве решения route server часто используется программный маршрутизатор с открытым исходным кодом – BIRD (bird internet routing daemon). Он хорош тем, что он бесплатен, быстро разворачивается на большинстве linux дистрибутивов, имеет гибкий механизм настройки политик маршрутизации/фильтрации, не требователен к вычислительным ресурсам. Также, в качестве RS может быть выбран и аппаратный/виртуальный маршрутизатор Cisco, Juniper и т.д.

• Безопасность. Поскольку сеть IXP – это концентрация большого количества AS, то и политика безопасности, которой должны следовать все участники, должна быть хорошо прописана. Как правило, все те же механизмы, которые применяются при установлении BGP-соседства между двумя отдельными BGP-пирами вне IXP, применяются и здесь, а также используются некоторые дополнительные средства защиты.

  Например, хорошей практикой является пропуск трафика только с определенного mac-адреса участника IXP, который обговаривается заранее. Запрет трафика с полями ethertype, отличающимися от 0x0800(IPv4), 0x08dd(IPv6), 0x0806(ARP); это делается для того, чтобы отфильтровать трафик, которому нет места при BGP-пиринге. Также могут применяться такие механизмы как GTSM, RPKI и т.д.

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

• размещают на IXP TLD DNS-сервера,
• устанавливают аппаратные NTP-сервера, давая возможность участникам точно синхронизовать время,
• предоставляют защиту от DDoS-атак и т.д.

Принцип работы

Разберем принцип работы точки обмена трафиком на примере простейшей IXP, смоделированной средствами EVE-NG, а после рассмотрим базовую настройку программного маршрутизатора BIRD. Для упрощения схемы мы опустим такие важные вещи, как резервирование и отказоустойчивость.

Топология сети представлена на рисунке ниже.

Предположим, что мы администрируем небольшую точку обмена трафиком и предоставляем следующие варианты пиринга:

• публичный пиринг,
• приватный пиринг,
• пиринг через route server.

Номер нашей AS – 555, мы владеем блоком IPv4 адресов – 50.50.50.0/24, из которого выдаем IP-адреса, для желающих подключиться к нашей сети.

50.50.50.254 – IP-адрес, настроенный на интерфейс route server’а, с данным IP клиенты будут устанавливать BGP-сессию в случае пиринга через RS.

Также для пиринга через RS мы разработали простейшую политику маршрутизации на основе BGP community, которая дает возможность участникам IXP регулировать кому и какие маршруты отправлять:

BGP community
Описание

LOCAL_AS:PEER_AS
Передать префиксы только PEER_AS

LOCAL_AS:IXP_AS
Передать префиксы всем участникам IXP

К нашей IXP желают подключиться и обменяться трафиком 3 клиента; допустим, это интернет-провайдеры. Все они желают организовать пиринг через route server. Ниже представлены схема с параметрами подключения клиентов:

Клиент
Номер AS клиента
Анонсируемые клиентом префиксы
ip адрес выданный клиенту для подключения к IXP

ISP #1
AS 100
1.1.0.0/16
50.50.50.10/24

ISP #2
AS 200
2.2.0.0/16
50.50.50.20/24

ISP #3
AS 300
3.3.0.0/16
50.50.50.30/24

Базовая настройка BGP на маршрутизаторе клиента:

router bgp 100
 no bgp enforce-first-as
 bgp log-neighbor-changes
 neighbor 50.50.50.254 remote-as 555
address-family ipv4
  network 1.1.0.0 mask 255.255.0.0
  neighbor 50.50.50.254 activate
  neighbor 50.50.50.254 send-community both
  neighbor 50.50.50.254 soft-reconfiguration inbound
  neighbor 50.50.50.254 route-map ixp-out out
 exit-address-family

ip prefix-list as100-prefixes seq 5 permit 1.1.0.0/16
route-map bgp-out permit 10
 match ip address prefix-list as100-prefixes
 set community 555:555

Здесь стоит отметить настройку no bgp enforce-first-as. По умолчанию, BGP требует, чтобы в as-path принимаемого BGP апдейта, присутствовал номер as bgp пира, от которого данный апдейт был получен. Но поскольку route server не вносит изменения в as-path, его номер будет отсутствовать в as-path и апдейт будет отброшен. Данная настройка применяется, чтобы маршрутизатор начал игнорировать данное правило.

Также мы видим, что клиент установил bgp community 555:555 на данный префикс, что согласно нашей политике означает, что клиент хочет анонсировать данный префикс всем остальным участникам.

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

Пример конфигурации BIRD:

define ixp_as = 555;
define ixp_prefixes = [ 50.50.50.0/24+ ];

template bgp RS_CLIENT {
  local as ixp_as;
  rs client;
}

Далее описывается фильтр, который не принимает martians префиксы, а также префиксы самой IXP:

function catch_martians_and_ixp()
prefix set martians;
prefix set ixp_prefixes;
{
  martians = [ 
  0.0.0.0/8+,
  10.0.0.0/8+,
  100.64.0.0/10+,
  127.0.0.0/8+,
  169.254.0.0/16+,
  172.16.0.0/12+,
  192.0.0.0/24+,
  192.0.2.0/24+,
  192.168.0.0/16+,
  198.18.0.0/15+,
  198.51.100.0/24+,
  203.0.113.0/24+,
  224.0.0.0/4+,
  240.0.0.0/4+ ];

  if net ~ martians || net ~ ixp_prefixes then return false;

  return true;
}

Данная функция реализует политику маршрутизации, которую мы описали ранее.

function bgp_ixp_policy(int peer_as)
{
  if (ixp_as, ixp_as) ~ bgp_community then return true;
  if (ixp_as, peer_as) ~ bgp_community then return true;

  return false;
}

filter reject_martians_and_ixp
{
  if catch_martians_and_ixp() then reject;
  if ( net ~ [0.0.0.0/0{25,32} ] ) then {
    reject;
  }
  accept;


}

Настраиваем пиринг, применяем соответствующие фильтры и политики.

protocol as_100 from RS_CLIENT {
  neighbor 50.50.50.10 as 100;
  ipv4 {
    export where bgp_ixp_policy(100);
    import filter reject_martians_and_ixp;
  }
}

protocol as_200 from RS_CLIENT {
  neighbor 50.50.50.20 as 200;
  ipv4 {
    export where bgp_ixp_policy(200);
    import filter reject_martians_and_ixp;
  }
}

protocol as_300 from RS_CLIENT {
  neighbor 50.50.50.30 as 300;
  ipv4 {
    export where bgp_ixp_policy(300);
    import filter reject_martians_and_ixp;
  }
}

Стоит отметить, что на route server’e является хорошим тоном складывать маршруты от разных пиров в разные RIB. BIRD позволяет это делать. В нашем же примере для простоты все апдейты, принятые от всех клиентов, складываются в одну общую RIB.

Итак, проверим, что у нас получилось.

На route server’e видим, что со всеми тремя клиентами установлена BGP-сессия:

Видим, что мы получаем префиксы от всех клиентов:

На маршрутизаторе as 100 видим, что при наличии всего одной BGP-сессии с сервером маршрутов, мы получаем префиксы и от as 200 и от as 300, при этом BGP-атрибуты не поменялись, как если бы пиринг между клиентами осуществлялся напрямую:

Таким образом мы видим, что наличие сервера маршрутов значительно упрощает организацию пиринга на IXP.

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

Linxdatacenter IX

В Linxdatacenter мы построили собственную IXP на базе отказоустойчивой инфраструктуры из 2-х коммутаторов и 2-х route-серверов. Сейчас наша IXP запущена в тестовом режиме, и мы приглашаем всех желающих подключиться к Linxdatacenter IX и принять участие в тестировании. При подключении вам будет предоставлен порт с пропускной способностью 1 Gbit/s, возможность пиринга через наши route-сервера, а также доступ в личный кабинет IX-портала, доступного по адресу ix.linxdatacenter.com.

Пишите в комментарии или личные сообщения для получения доступа к тестированию.

Вывод

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

Полезные ссылки

• Посмотреть карту расположения точек обмена трафиком: www.internetexchangemap.com
• Посмотреть подробную статистику по BGP пирингу, в том числе и присутствие на IXP: www.peeringdb.com

Источник: habr.com