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

„Настроихме телефонна връзка между нас и момчетата от SRI…“, каза Клайнрок в интервюто си:
„Написахме L и попитахме по телефона: „Виждате ли L?““
„Да, виждаме L,“ дойде отговорът.
„Написахме O и попитахме: „Виждате ли O?““
„Да, виждаме O.“
„След това написахме G, и системата се срина“...

Още една революция беше започнала…

Началото на интернет.

Здравейте на всички!

Аз се казвам Александър, аз съм мрежов инженер в компанията 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 обновление от един от своите клиенти, RS разпространява това обновление на всички останали свои клиенти, разбира се, с изключение на този, от когото е получено. По този начин, RS избягва необходимостта от изграждане на full-mesh между всички участници в IXP и елегантно решава проблема с мащабируемостта. Трябва да се отбележи, че маршрутизатора транспарентно предава маршрути от една AS на друга, без да внася промени в предаваните 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 предлага на своите участници допълнителни услуги:

• разполагат TLD DNS сървъри на IXP,
• инсталират хардуерни 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 на рутера на клиента:

маршрутизатор bgp 100
 no bgp enforce-first-as
 bgp лог-соседние-изменения
 сосед 50.50.50.254 удаленный-as 555
адрес-семейство ipv4
  мрежа 1.1.0.0 маска 255.255.0.0
  сосед 50.50.50.254 активират
  сосед 50.50.50.254 изпраща-общност и двете
  сосед 50.50.50.254 мек-конфигурация входяща
  сосед 50.50.50.254 маршрут-карта ixp-out навън
 изход-адрес-семейство

ip префикс-списък as100-префикси seq 5 позволи 1.1.0.0/16
маршрут-карта bgp-out позволи 10
 съвпадение ip адрес префикс-списък as100-префикси
 задайте общност 555:555

Тук е важно да се отбележи настройката no bgp enforce-first-as. По подразбиране BGP изисква, когато в as-path на полученото BGP обновление липсва номерът на as bgp пер, от когото е получено това обновление. Тъй като рутерът не променя as-path, неговият номер ще липсва в as-path и обновлението ще бъде отхвърлено. Тази настройка се прилага, за да накара маршрутизатора да игнорира това правило.

Също така виждаме, че клиентът е настроил bgp общност 555:555 за този префикс, което съгласно нашата политика означава, че клиентът иска да анонсира този префикс на всички останали участници.

За маршрутизаторите на останалите клиенти настройката ще бъде аналогична, с изключение на техните уникални параметри.

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

определете ixp_as = 555;
определете ixp_prefixes = [ 50.50.50.0/24+ ];

template bgp RS_CLIENT {
  локален as ixp_as;
  rs клиент;
}

Следва описанието на филтър, който не приема martians префикси, както и префиксите на самата IXP:

функция catch_martians_and_ixp()
префикс набор martians;
префикс набор 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;
}

Тази функция реализира политиката на маршрутизиране, която описахме по-рано.

функция 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;
}

филтър reject_martians_and_ixp
{
  if catch_martians_and_ixp() then reject;
  if ( net ~ [0.0.0.0/0{25,32} ] ) then {
    reject;
  }
  accept;


}

Настройваме пиринг, прилагаме съответните филтри и политики.

протокол as_100 от RS_CLIENT {
  съсед 50.50.50.10 as 100;
  ipv4 {
    експорт където bgp_ixp_policy(100);
    внос филтър reject_martians_and_ixp;
  }
}

протокол as_200 от RS_CLIENT {
  съсед 50.50.50.20 as 200;
  ipv4 {
    експорт където bgp_ixp_policy(200);
    внос филтър reject_martians_and_ixp;
  }
}

протокол as_300 от RS_CLIENT {
  съсед 50.50.50.30 as 300;
  ipv4 {
    експорт където bgp_ixp_policy(300);
    внос филтър reject_martians_and_ixp;
  }
}

Важно е да се отбележи, че в route server е добре да се съхраняват маршрути от различни пиринг партньори в различни RIB. BIRD позволява това. В нашия пример, за опростяване, всички обновления, получени от всички клиенти, се съхраняват в една обща RIB.

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

На маршрутизатора видим, че с всички трима клиенти е установена BGP-сесия:

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

На маршрутизатора с AS 100 виждаме, че при наличие на само една BGP-сесия със сървър за маршрути, получаваме префикси както от AS 200, така и от AS 300, като BGP атрибутите не са се променили, както би се случило, ако пироването между клиентите се осъществяваше директно:

Така виждаме, че наличието на сървър за маршрути значително улеснява организацията на пироването на IXP.

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

Linxdatacenter IX

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

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

Извод

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

Полезни връзки

• Вижте картата на местоположението на точките за обмен на трафик: www.internetexchangemap.com
• Вижте подробна статистика за BGP пироване, включително присъствието на IXP: www.peeringdb.com

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