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

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

Но революцията беше започнала...

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

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

Казвам се Александър, аз съм мрежови инженер в компанията Linxdatacenter. В днешната статия ще говорим за точки на обмен на трафик (Internet Exchange Point, IXP): за това, което предшества появата им, какви задачи решават и как се изграждат. Също така в тази статия ще демонстрирам принципа на работа на IXP с помощта на платформата EVE-NG и софтуерния рутер BIRD, за да се разбере как работи „под капака“.

Няколко факта от историята

Ако погледнем тук, можем да забележим, че бурният растеж на точките на обмен на трафик е започнал през 1993 година. Това е свързано с факта, че повечето от трафика на съществуващите тогава телекомуникационни оператори минаваше през бекбон мрежата на САЩ. Например, когато трафикът от оператор във Франция минаваше до оператор в Германия, той първо достига до Съединените щати, а след това от САЩ до Германия. Бекбон мрежата в случая изпълняваше ролята на транзит между Франция и Германия. Дори трафикът в рамките на една страна често не минаваше направо, а през опорни мрежи на американски оператори.

Такова положение оказваше влияние не само на цената на доставката на транзитен трафик, но и на качеството на каналите и закъснението. Броят на потребителите на интернет нарастваше, появяваха се нови оператори, обемът на трафика растеше, интернетът зрял. Операторите по целия свят започнаха да осъзнават, че необходимостта от по-рационален подход към организацията на междупотребителското взаимодействие е на лице. „Защо аз, оператор А, да плащам за транзит през друга страна, за да доставя трафик на оператор Б, който се намира на съседната улица?“ Примерно такъв въпрос задаваха на себе си телекомуникационните оператори по това време. Така, в различни части на света, на точките на концентрация на оператори започнаха да се появяват точки на обмен на трафик:

• 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 reflectora в iBGP или designated router в OSPF и решава същите проблеми. С нарастването на броя на участниците в точката на обмен на трафик, се увеличава и броят на BGP сесиите, които всеки от участниците трябва да поддържа, т.е. това наподобява класическа full-mesh топология в iBGP. RS решава проблема по следния начин: установява BGP сесия с всеки заинтересован участник на IXP, а той става клиент на RS. При получаване на BGP update от един от своите клиенти, RS разпространява този update на всички останали свои клиенти, разбира се, с изключение на този, от който е получил update. Така 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, се прилагат и тук, а също така се използват и някои допълнителни средства за защита.

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

Вероятно, изброеното по-горе са основните съставни части на всяка IXP, независимо от размера. Разбира се, по-големите IXP могат да използват допълнителни технологии и решения.
Понякога IXP предоставя на своите участници допълнителни услуги:

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

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

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

Топологията на мрежата е представена на изображението по-долу.

Да предположим, че администрираме малка точка за обмен на трафик и предлагаме следните опции за пиринг:

• публичен пиринг,
• приватен пиринг,
• пиринг чрез маршрутно сървър.

Номерът на нашата AS е 555, ние притежаваме блок от IPv4 адреси – 50.50.50.0/24, от който раздаваме IP адреси на желаещите да се свържат с нашата мрежа.

50.50.50.254 – IP адресът, настроен на интерфейса на маршрутен сървър, с който клиентите ще установяват BGP сесия в случай на пиринг чрез RS.

Също така, за пиринг чрез RS, разработихме най-простата политика на маршрутизация, основана на BGP community, която позволява на участниците на IXP да регулират на кого и какви маршрути да изпращат:

BGP community
Описание

LOCAL_AS:PEER_AS
Да предадем префиксите само на PEER_AS

LOCAL_AS:IXP_AS
Да предадем префиксите на всички участници на IXP

Трима клиенти искат да се свържат с нашата IXP и да обменят трафик; да предположим, че това са интернет доставчици. Всички те желаят да организират пиринг чрез маршрутния сървър. По-долу е представена схема с параметрите за свързване на клиентите:

Клиент
Номер на 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 изисква номерът на BGP пир, от който е получено обновлението, да присъства в as-path на приеманото BGP обновление. Но тъй като рутерът не прави промени в as-path, неговият номер ще липсва в него и обновлението ще бъде отхвърлено. Тази настройка се прилага, за да накара рутера да игнорира това правило.

Също така виждаме, че клиентът е настроил BGP общността 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;
  }
}

Важно е да се отбележи, че на рутерния сървър е добър тон да се складират маршрутите от различни пирове в различни 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