«Увійти в телефон, між нас і guys на SRI…», Kleinrock… said in an interview:
"Ви typed the L and we asked on the phone, "Do you see the L?""
"Yes, we see the L," came the response.
"Ви типовані О, і ми зробили,"
"Yes, we see the O."
"Then we typed the G, and the system crashed" ...Yet a revolution had begun…
Початок Інтернету.
Всім привіт!
Мене звуть Олександр, я мережевий інженер у компанії 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 до іншої, не вносячи зміни в атрибути, що передаються 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
ЯК 100
1.1.0.0/16
50.50.50.10/24
ISP #2
ЯК 200
2.2.0.0/16
50.50.50.20/24
ISP #3
ЯК 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-порталу, доступного за адресою .
Напишіть у коментарі або особисті повідомлення для отримання доступу до тестування.
Висновок
Точки обміну трафіком виникли на зорі інтернету як інструмент вирішення питання неоптимального проходження трафіку між операторами зв'язку. Зараз з появою нових глобальних сервісів і збільшенням кількості CDN трафіку точки обміну продовжують оптимізувати роботу глобальної мережі. Збільшення кількості IXP у світі несе користь як кінцевого користувача сервісу, так операторів зв'язку, операторів контенту тощо. Для учасників IXP вигода виявляється у скороченні витрат на організацію зовнішніх пірингів, скороченні кількості трафіку, за який доводиться платити вищим операторам, оптимізації маршрутизації, можливості мати прямий стик із операторами контенту.
Корисні посилання
- Подивитись карту розташування точок обміну трафіком:
- Подивитись детальну статистику з BGP пірінгу, в тому числі і присутність на IXP:
Джерело: habr.com