AS_PATH не змінився, а трафік пішов іншим шляхом: як перевірити BGP ORIGIN

Коли знайомий AS_PATH дає хибне відчуття спокою

Уявімо ранкову перевірку після звичайної мережевої зміни. Сервіси доступні, канали не впали, але клієнтський трафік тепер приходить через дорожчого провайдера. Черговий порівнює AS_PATH і бачить знайомі ASN тієї самої довжини.

BGP — це протокол обміну маршрутною інформацією між автономними системами, або AS. Кожна AS має номер ASN. Атрибут AS_PATH містить записану в анонсі послідовність AS, але незмінний AS_PATH не доводить, що решта політики та атрибутів також не змінилися. Він також не є точним вимірюванням фактичного шляху кожного пакета.

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

Спочатку уточніть напрямок проблеми. Ваш маршрутизатор обирає наступний вузол для вихідного трафіку серед відомих йому маршрутів. Шлях вхідного трафіку до вашого префікса обирають зовнішні автономні системи за власними правилами. Зміна локального BGP-шляху й переміщення вхідного трафіку можуть відбутися одночасно, але це ще не доводить спільну причину.

Не плутайте ORIGIN з origin AS

Ці поняття відповідають на різні запитання. Origin AS — автономна система, з якої почав поширюватися префікс. У простому AS_PATH, що складається зі звичайної послідовності AS, це зазвичай крайній правий ASN. Агрегація може ускладнити таке визначення, а сам origin AS не підтверджує право мережі анонсувати префікс.

AS_PATH — це послідовність AS, записана в BGP-анонсі. Вона потрібна, зокрема, для виявлення маршрутних петель і застосування політик. ORIGIN — окремий обов’язковий атрибут із класифікацією походження маршрутної інформації. Оскільки політика маршрутизації може його переписати, ORIGIN не слід сприймати як незмінний журнал первинної події.

ORIGIN має три значення:

• IGP — маршрутна інформація вважається внутрішньою для AS, що створила анонс; багато реалізацій призначають це значення маршрутам, доданим через явний мережевий анонс;
• EGP — інформацію отримано через історичний протокол EGP; нині це значення трапляється рідко;
• INCOMPLETE — інформацію отримано іншим способом; це типове початкове значення під час перерозподілу маршруту з іншого джерела.

Точна поведінка команд анонсування й перерозподілу залежить від реалізації та політик. Числові коди цих значень — IGP = 0, EGP = 1 і INCOMPLETE = 2. У поширених алгоритмах вибору найкращого шляху нижчий код має перевагу, тому IGP порівнюється як кращий за EGP, а EGP — за INCOMPLETE. RFC 4271 визначає значення ORIGIN і загальний процес прийняття рішення, але не встановлює єдиного повного порядку всіх критеріїв для кожної платформи. Тому перевіряйте документацію конкретної реалізації. Водночас INCOMPLETE не означає пошкоджений, підроблений або недостовірний маршрут. Це лише значення атрибута.

Зберіть однаковий зріз для одного префікса

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

Позначте етап, із якого взято кожен запис:

• маршрут у стані, отриманому від сусіда до імпортної, тобто вхідної, політики;
• маршрут після імпортної політики у локальній таблиці BGP;
• анонс після експортної, тобто вихідної, політики, який ваш маршрутизатор надсилає сусідові.

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

Для кожного запису збережіть:

• next hop — адресу наступного маршрутизатора, куди слід передати трафік, і сусіда, від якого надійшов маршрут;
• Local Preference — внутрішній пріоритет маршруту в межах вашої AS; більше значення зазвичай має перевагу;
• AS_PATH та ORIGIN;
• MED — підказку сусідній AS щодо бажаної точки входу; умови його порівняння залежать від реалізації та політики;
• communities — мітки BGP, за якими мережі застосовують погоджені правила;
• інші специфічні для платформи критерії вибору, якщо вони є;
• позначку найкращого шляху та пояснення вибору, якщо система його показує;
• час появи або останньої зміни маршруту.

Звірте контрольну площину BGP із фактичним потоком пакетів: сам запис у таблиці не доводить, яким каналом ішов увесь трафік у потрібний момент.

Додайте незалежну зовнішню точку спостереження. Колектор маршрутів збирає BGP-анонси від підключених мереж, а looking glass дає змогу переглянути маршрут із певної чужої мережі. Зовнішній сервіс може показувати лише обраний ним найкращий маршрут, а не всі отримані варіанти. Порівнюйте дані одного періоду та записуйте, з якої мережі й у який час отримано кожне спостереження.

Перевірте дві конкуруючі гіпотези

Перша гіпотеза — ORIGIN змінився у вашій мережі. Перегляньте останні зміни способу створення анонсу та всі політики, які можуть явно встановлювати ORIGIN. За поширених початкових налаштувань заміна явного мережевого анонсу на перерозподіл часто змінює IGP на INCOMPLETE, але це потрібно перевірити на конкретній платформі.

Порівняйте маршрут до імпортної політики з локальним результатом, якщо досліджуєте отриманий від провайдера маршрут. Для власного префікса перевірте анонс після експортної політики окремо для кожного сусіда. Так ви відділите початкове значення від локального переписування.

Друга гіпотеза — ORIGIN переписала мережа на транзитному шляху. Якщо ви надсилаєте обом провайдерам однаковий ORIGIN, а зовнішні точки бачать інше значення лише на шляхах, що проходять через одного з них, це корисний доказ розходження. Проте він ще не доводить, що атрибут змінив саме безпосередній провайдер: це могла зробити інша AS між вашим вихідним анонсом і точкою спостереження.

Збережіть повні атрибути, AS_PATH, часові мітки та результати з кількох точок, бажано розташованих у різних мережах і на різній відстані вздовж шляху. Якщо доступний looking glass провайдера, порівняйте його дані з дальшими спостереженнями. Остаточно приписувати політику конкретній мережі варто лише після достатньої локалізації або підтвердження від цієї мережі.

Чи справді вирішальним був ORIGIN

Знайдена відмінність ORIGIN ще не доводить її впливу на вибір маршруту. У багатьох реалізаціях раніше за ORIGIN оцінюються специфічні для платформи локальні критерії, Local Preference, локальне створення маршруту та довжина AS_PATH. Точний порядок, умови порівняння й додаткові кроки залежать від платформи та налаштованої політики.

Для вихідного трафіку порівняйте всі локальні кандидати на своєму маршрутизаторі. Якщо, наприклад, Local Preference різний, рішення зазвичай буде прийнято до порівняння ORIGIN. Щоб показати вплив ORIGIN, потрібно довести, що маршрути однакові за критеріями, які ваша платформа перевіряє раніше, а причина вибору справді доходить до ORIGIN.

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

Контрольну перевірку виконуйте в лабораторії або на явно обмеженій тестовій ділянці. Не змінюйте ORIGIN у всьому робочому середовищі лише для підтвердження гіпотези.

Cloudflare повідомляє, що в описаному нею експерименті майже 70% спостережуваних BGP-шляхів отримали інше значення ORIGIN, ніж установила мережа-джерело. Це результат конкретного експерименту та його методики, а не правило про 70% маршрутів чи трафіку всього інтернету.

Виправляйте причину, а не симптом

Якщо ORIGIN змінила ваша політика створення або експорту анонсу, виправте саме вузьке правило: приберіть ненавмисне переписування або відновіть потрібний спосіб анонсування. Якщо зміна відбулася поза вашою AS, причинне виправлення потребує дії мережі, яка переписує атрибут. Локальна політика може лише контрольовано зменшити вплив такого переписування на ваш вибір маршруту.

Для передбачуваного вибору вихідного маршруту можна встановити явний Local Preference на маршрутах, отриманих від провайдерів. Обмежте правило потрібним класом маршрутів або префіксів. Спочатку перевірте його в лабораторії чи на ізольованій тестовій ділянці. Local Preference зазвичай передається разом із маршрутами внутрішнім BGP-сусідам, щоб маршрутизатори AS узгоджено обирали вихід. Тому переконайтеся, що умови правила збігаються лише з потрібними маршрутами, і оцініть його дію на всіх внутрішніх маршрутизаторах, куди ці маршрути поширюються. Резервний маршрутизатор сам по собі не є безпечним тестовим середовищем.

Local Preference у вашій мережі не є прямим засобом керування вхідним трафіком з інтернету. У деяких схемах зміна локального найкращого шляху може опосередковано змінити ваші вихідні анонси, тому після неї їх також потрібно перевірити. Для навмисного керування вхідним трафіком використовуйте лише підтверджені провайдером communities та інші підтримувані ним механізми. AS_PATH prepending — повторення власного ASN в анонсі для зниження привабливості шляху — і MED можуть слугувати сигналами, але зовнішні мережі не зобов’язані враховувати їх так, як ви очікуєте.

Не намагайтеся зробити політику передбачуваною простим примусовим встановленням IGP: ORIGIN може не бути вирішальним критерієм, а далі за шляхом його знову можуть переписати. Якщо докази локалізують зміну до провайдера, передайте йому вихідний анонс, зовнішні спостереження та часові мітки й попросіть пояснити політику та доступні підтримувані засоби керування.

Перед зміною визначте очікуваний найкращий і резервний шляхи, область дії правила та точні умови відкату. Після зміни перевірте локальні кандидати, анонси до сусідів, фактичний потік трафіку й зовнішні точки. Відкочуйтеся, якщо зник резервний шлях, почалися неочікувані анонси або відкликання маршрутів, чи правило зачепило інші префікси.

Антипатерни

• вважати незмінний AS_PATH доказом незмінної політики або фактичного шляху пакетів;
• трактувати кожен INCOMPLETE як помилку чи ознаку недостовірності;
• називати конкретного провайдера джерелом переписування за одним зовнішнім знімком;
• одночасно змінювати ORIGIN, Local Preference, MED і AS_PATH prepending;
• тестувати політику на резервному маршрутизаторі без перевірки її поширення через внутрішній BGP;
• намагатися керувати вхідним трафіком локальним Local Preference;
• порівнювати знімки різного часу без журналу змін;
• використовувати ORIGIN або origin AS як доказ права анонсувати префікс.

Висновок

Незмінний AS_PATH — лише одна частина картини. Спочатку відокремте вихідний трафік від вхідного, потім порівняйте один префікс на однакових етапах обробки та звірте BGP-дані з фактичним потоком. Відмінний ORIGIN підтверджує зміну атрибута, але не автоматично її автора чи вплив на рішення. Перед виправленням доведіть усі три ланки: де значення розійшлося, чи дійшов процес вибору до ORIGIN і яка обмежена зміна усуне підтверджену локальну причину або зменшить залежність від зовнішнього переписування без пошкодження резервування.

Джерела

• BGP ORIGIN attribute manipulation and its impact on the Internet
• RFC 4271: A Border Gateway Protocol 4