Схуднення таблиці маршрутизації в Інтернеті

від Торе Андерсон

Коли провайдер або автономна система (AS), така як Redpill Linpro, отримує блок глобально унікальних IP-адрес (що називається префіксом), він повинен рекламувати його в глобальній таблиці маршрутизації в Інтернеті. Ця реклама призводить до того, що всі інші AS у світі дізнаються, що новий префікс уже діє, а також як і куди надсилати будь-які IP-пакети, призначені для нього. Зв’язок встановлено, і всі задоволені. Правильно?

Хіба що є проблема. Кількість префіксів у глобальній таблиці маршрутизації Інтернету зростає з тривожною швидкістю. На момент написання статті глобальна таблиця маршрутизації Інтернету складається з бл. 635 000 префіксів IPv4 та 33 000 префіксів IPv6. Вони рекламуються прибл. 55000 різних АС з усього світу.

Розміри глобальних таблиць маршрутизації IPv4 та IPv6 з часом (джерело: Звіт CIDR)

Зростання, звичайно, можна пояснити тим, що Інтернет зростає, але це лише половина історії. Це також економічна проблема; для того, щоб рекламувати новий префікс (або меншу підмножину вже існуючого префікса), АС майже нічого не коштує. Натомість ці витрати несуть усі інші АС, які повинні мати цей префікс у таблицях маршрутизації на своїх маршрутизаторах. Простіше кажучи: в Інтернеті забруднювач робить ні платити.

Більшість організацій, включаючи Redpill Linpro, вирішували цю проблему, кидаючи на неї гроші. Вони звертаються до таких постачальників, як Cisco Systems або Juniper Networks, і купують їх маршрутизатори. Вони створені спеціально для того, щоб мати можливість виконувати високошвидкісну переадресацію маршрутизації мережевого трафіку, навіть якщо таблиця маршрутизації повинна зрости за мільйон маршрутів. Вони роблять справді приголомшливі коробки, але не помиляються, вони, звичайно, роблять ні коштують дешево. Тому ми хотіли б побачити, чи існував розумніший та економічніший спосіб вирішення цієї проблеми в майбутньому.

Використання комутатора як маршрутизатора

За роки, що минули з того часу, як ми придбали наші поточні Інтернет-маршрутизатори Juniper MX, можливості IP-маршрутизації комутаторів товарних центрів обробки даних значно покращились до того моменту, коли їх можна використовувати для серйозних завдань IP-маршрутизації. Більшість із них використовують вдосконалену мережеву операційну систему (NOS), яка підтримує всі необхідні протоколи, зокрема протокол Border Gateway Protocol (BGP), який використовується для обміну інформацією про маршрутизацію через Інтернет.

Як описано в попередньому дописі, ми тестуємо HPE Altoline 6920 у нашій лабораторії. Altoline 6920, як і інші комутатори, що базуються на наборі мікросхем Broadcom Trident II, здатний обробляти до 720 Гбіт/с пропускної здатності, зберігаючи порти 48x10GbE + 6x40GbE в компактному шасі 1RU. Його ціна, швидше за все, становить однозначний відсоток від ціни традиційного Інтернет-маршрутизатора зі схожим рейтингом пропускної здатності.

Щоб досягти цих вражаючих властивостей та щільності, зберігаючи привабливо низьку ціну, очевидно, слід піти на певні компроміси. Одним з них є масштабованість таблиці маршрутизації; чіпсет Trident II просто не можна запрограмувати з більш ніж 131 072 маршрутами. Цього недостатньо для обробки повної таблиці маршрутизації в Інтернеті сьогодні. Це справедливо і для більшості інших наборів мікросхем комутаторів ЦОД.

Отже, на цьому етапі ми могли зробити висновок, що обмеження таблиці маршрутизації унеможливлює використання недорогого комутатора в якості Інтернет-маршрутизатора. Але замість того, щоб здаватися так просто і продовжувати кидати гроші на проблему, ми вирішили витратити деякий час, роздумуючи трохи «нестандартно».

Чи справді нам потрібна повна таблиця маршрутизації в Інтернеті?

Перше, що ми зрозуміли, це те, що з нашої точки зору переважна більшість Інтернет-маршрутів є зайвими. Наприклад: навіть незважаючи на те, що маршрути, що рекламуються італійським провайдером, відрізняються від маршрутів, які рекламує іспанський провайдер, дуже ймовірно, що ми будемо маршрутизувати пакети, призначені для них обох, однаково. Шляхи до цих напрямків можуть не розходитися, поки добре після того, як пакети дістануться до континентальної Європи, ще довго після того, як вони покинуть нашу мережу.

Друге розуміння полягає в тому, що навіть якщо розглянуті маршрути не були надлишковими, тобто, що ми зазвичай використовували б різних постачальників IP-транзиту, щоб дістатися до них, різниця між ними насправді не приносить реальної вигоди. Redpill Linpro має двох основних постачальників IP-транзиту. У більшості випадків насправді не помітно різниці, який із них використовується для доставки трафіку, призначеного для мереж за межами Скандинавії.

Третє усвідомлення полягає в тому, що більшість маршрутів у глобальній таблиці маршрутизації Інтернету залишаться повністю невикористаними. Переважна більшість нашого транспорту ніколи не залишає Скандинавію. Проте маршрут, рекламований, скажімо, північнокорейським провайдером, займе в наших маршрутизаторах стільки ж місця, скільки маршрут, який рекламує один з найбільших провайдерів у Скандинавії. Це так, якщо ми навіть ніколи не відправляли жодного пакета цьому північнокорейському провайдеру.

Висновок полягає в тому, що насправді нам не потрібна повна таблиця в Інтернеті. Натомість ми можемо розрізнити «важливі» та «не важливі» маршрути. Маршрут можна класифікувати як «важливий» на основі таких критеріїв, як обсяг трафіку, який ми йому відправляємо, якщо він належить до мережі в нашому географічному оточенні, якщо він рекламується безпосереднім партнером або якщо на ньому розміщені послуги, які відповідають особливе значення для наших клієнтів.

Набір «важливих» маршрутів буде зручно вписуватися в чіпсет сучасного комутатора ЦОД, навіть якщо ми встановимо планку класифікації «важливих» дуже низько.

RIB та FIB

Для того, щоб насправді класифікувати маршрут як «важливий» чи ні, нам спочатку потрібно дізнатися про його існування. Це означає, що нам все одно доведеться отримати повну таблицю маршрутизації Інтернету від наших постачальників ІР-транзиту. То чи означає це, що наш проект комутатора як маршрутизатора приречений на провал? Ні, не обов'язково!

Буває, що будь-який сучасний мережевий пристрій (як маршрутизатори, так і комутатори) насправді містить (принаймні) дві різні таблиці маршрутизації.

Перша таблиця називається Інформаційна база пересилання, або скорочено FIB. FIB знаходиться всередині самого набору мікросхем переадресації пакетів і є тим, що використовується для здійснення маршрутизації кожного окремого пакета, який проходить комутатор. FIB - це таблиця маршрутизації, про яку я вже говорив у цій публікації, оскільки саме тут знайдено обмеження розміру.

Друга таблиця називається інформаційною базою маршрутизації (RIB). RIB живе знаходиться всередині NOS. Його розмір насправді обмежений лише обсягом пам'яті, доступної для NOS. Altoline 6920 має 8 Гб пам'яті, чого достатньо для того, щоб вмістити десятки мільйонів маршрутів - досить просто, щоб вмістити кілька копій таблиці маршрутизації в Інтернеті.

Взаємозв'язок між RIB та FIB полягає в тому, що інформація з першого використовується для програмування другого. Наприклад, Інтернет-маршрутизатор, підключений до двох різних провайдерів IP-транзиту, отримає дві копії таблиці Інтернет-маршрутизації (по одній від кожного провайдера). Обидві копії зберігаються в RIB (який на той момент міститиме понад 1,2 мільйона маршрутів).

Для кожного унікального префікса, знайденого в RIB, NOS наступним чином вирішить, який із двох альтернативних маршрутів є найкращим. Потім він продовжує програмувати найкращий маршрут до ПІБ. Однак не найкращий маршрут залишатиметься в RIB, так що якщо в даний час найкращий маршрут буде змінений або знятий провайдером транзиту IP, що рекламує його, NOS зможе негайно перепрограмувати FIB відповідно.

Остаточний план: зарезервувати FIB лише для важливих маршрутів

Ми маємо намір вставити ще один критерій у потоці інформації від RIB до FIB. Для того, щоб маршрут RIB поширився на FIB, він повинен бути не тільки «найкращим», але він також повинен бути у списку «важливих» маршрутів. Якщо це не так, він не запрограмований у ПІБ. Однак RIB все ще міститиме кожен маршрут, оскільки точний набір маршрутів, які є «важливими», є динамічним і може змінюватися.

Звичайно, навіть незважаючи на те, що ми тримаємо «не важливі» маршрути подалі від ПІБ, це не означає, що ми не матимемо зв’язку з цими мережами. Щоб забезпечити зв’язок з усім Інтернетом, а не лише з «важливими» частинами, ми маємо намір встановити «маршрут останньої інстанції» (також відомий як «маршрут за замовчуванням») у FIB, який спрямований на наш основний IP-транзит провайдера.

Маршрут останньої інстанції насправді нічим не відрізняється від будь-якого іншого «важливого» маршруту, за винятком того факту, що він охоплює весь простір IP-адрес. RIB також міститиме окремий маршрут останньої інстанції, що вказує на наш вторинний постачальник IP-транзиту, готовий бути автоматично підвищений до FIB, якщо збій призведе до зупинки основного транзитного IP-з'єднання.

Отримати пакет до «неважливого» пункту призначення тоді стає роботою постачальника послуг ІР-транзиту, незалежно від того, де в світі це знаходиться. Це, по суті, нічим не відрізняється від сучасної ситуації - за винятком того, що ми досягаємо цього, використовуючи один запис маршруту у FIB замість сотень тисяч.

Доказ реалізації концепції за допомогою Cumulus Linux NOS

Звичайно, необхідно переконатися, що план справді спрацює на практиці, тому ми створили доказ концепції в нашій лабораторії. Ми встановили Cumulus Linux на комутаторі Altoline 6920 і налаштували його для встановлення сеансів IPv4 та IPv6 BGP для двох наших поточних прикордонних маршрутизаторів.

Два прикордонних маршрутизатори будуть рекламувати всю комутаційну таблицю IPv4 та IPv6 до комутатора. Як ми і очікували, це не спрацювало. ASIC просто не може впоратися з такою кількістю маршрутів, і FIB заповнює повністю:

Наступним кроком є визначення, які маршрути є «важливими». Незважаючи на те, що лише фантазія обмежує спосіб прийняття цієї класифікації, для підтвердження концепції ми обрали наступний статичний список:

Маршрут останньої інстанції (маршрут за замовчуванням)
Усі маршрути, не отримані від постачальника послуг транзиту IP (тобто маршрути, отримані від однорангових мереж)
Всі маршрути до скандинавських клієнтів нашого основного постачальника послуг IP-транзиту

Усі інші маршрути класифікуються як «не важливі», і ми будемо тримати їх подалі від ПІБ. Тепер ми можемо продовжувати створювати карту маршрутів, яка відповідає таким маршрутам:

Останньою частиною загадки є змусити демон BGP фільтрувати всі отримані маршрути BGP через карту маршрутів, що містять лише важливі маршрути, перед тим, як встановлювати їх у FIB. Це робиться за допомогою параметра table-map, завдяки чому остаточна конфігурація BGP виглядає так:

Як і очікувалося, це робить споживання FIB набагато розумнішим і відповідає можливостям перемикача Altoline 6920:

Успіху! Ми зменшили таблицю маршрутизації в Інтернеті до розміру, який буде зручно вписуватися в FIB комутатора товарних центрів обробки даних, одночасно підтримуючи повний зв’язок із усім глобальним Інтернетом.

Резюме

Зменшення FIB дозволить нам будувати нашу мережу, використовуючи комутатори товарних центрів обробки даних, а не традиційні маршрутизатори Інтернету. Нова мережа зможе обробляти значно більші обсяги трафіку за певну частку вартості, завдяки чому ми зможемо запропонувати пропускну здатність Інтернету за конкурентоспроможними цінами в рамках пропонованих послуг з керованих послуг.

Дописи в цій серії

Ви хочете працювати з Торе Андерсоном? Ми завжди шукаємо людей, які мають досвід роботи з Linux та програмним забезпеченням з відкритим кодом. Повідомте нас, якщо ви зацікавлені у приєднанні до нашої команди!

Шукаєте більше вмісту? Перегляньте наш техблог або прочитайте наші технічні довідки та інструкції.

Підпишіться через RSS

Посилання

Зв'язок

[email protected]
redpilllinpro
redpilllinpro
Redpill-Linpro
redpill-linpro
RedpillLinproIT

"Різдвяні поради, прийоми та статті для системних адміністраторів та інших технічно налаштованих. З побажаннями щасливих свят!"