Застосування протоколу BGP в Internet

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

Оскільки Internet розвинувся і зріс протягом останніх років, то стало очевидним існування поважних проблем масштабування. Вони включають:

Вичерпання адресного простору мереж класу B. Основним явищем у цій проблемі є брак місця у цьому класі адрес для організацій середнього розміру; клас C із максимально 254 адресами для станцій занадто малий, тоді як клас B, який допускає до 65534 адрес, занадто великий для його повного використання.

Збільшення таблиць раутінгу в Internet-раутерах понад здатність наявного програмного забезпечення (і мережевих адміністраторів) до ефективного управління ними.

Можливе вичерпання 32-бітового адресного простору IP.

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

BGP-4 є розширенням BGP-3, який підтримує агрегування раутінгової інформації та її обмеження, базуючись на архітектурі внутрішньодоменного безкласового раутінгу (CIDR). Подальший розгляд базується на припущенні, що Internet є збіркою довільно сполучених автономних систем, тобто Internet моделюється загальним графом, де вузлами є автономні системи, а його ребра – це сполучення між парами автономних систем.

Класичне означення автономної системи розглядає її як множину раутерів, які знаходяться під окремим технічним адмініструванням з використанням внутрішніх шлюзових протоколів та спільних метрик для маршрутування пакетів всередині автономної системи, і зовнішнього шлюзового протоколу для маршрутування пакетів до інших автономних систем. Від часу опрацювання цього класичного означення воно приймає, що одна автономна система (AS) використовує декілька внутрішніх шлюзових протоколів (IGP) і, тим самим, декілька систем метрик всередині AS. Вживання терміну “автономна система” робить наголос на факті, що навіть коли вживаються багато IGP і метрик, то адміністрування AS виявляється перед іншими автономними системами у тому, що існує окремий узгоджений внутрішній план раутінгу і наявна сумісна картина того, як призначення може бути досягнене через цю AS. Автономні системи вважаються адміністрованими окремим адміністративним органом щонайменше з метою подання раутінгової інформації системам поза даною AS.

Топологічна модель BGP

Коли говорять про існування сполучення між двома автономними системами, то це означає два факти:

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

BGP-сполучення: існує BGP-сесія між BGP-спікерами у кожній із AS і ця сесія повідомляє маршрути, які можуть бути використані для певних призначень через оголошення автономних систем.

Документ RFC 1772 впроваджує додаткове обмеження для BGP-спікерів, які формують BGP-сполучення: вони повинні спільно використовувати ту саму підмережу Канального рівня, що й їх граничні шлюзи, тобто вимагається, щоб BGP-сесія між суміжними автономними системами не підтримувалася будь-яким раутінгом всередині AS або між AS. Випадки, які не відповідають цьому обмеженню, не розглядаються в цьому документі. Отже, в кожному сполученні кожна автономна система має один або більше BGP-спікерів і один або більше граничних шлюзів, і всі ці BGP-спікери і граничні шлюзи розташовані у спільній підмережі Канального рівня. Відзначимо, що BGP-спікери не мусять бути граничними шлюзами і навпаки. Шляхи, оголошені BGP-спікером однієї AS для даного сполучення, можуть бути можливими для будь-якого з граничних шлюзів іншої AS у тій самій спільній підмережі, добто допускаються непрямі сусіди.

Більшість трафіку, який переноситься в автономній системі, генерується і завершується у цій AS (тобто IP-адреси джерела або призначення IP-пакету ідентифікують станцію, внутрішню відносно даної AS). Трафік, який відповідає цьому опису, називають внутрішнім або локальним, інший трафік називають транзитним. Головною метою використання BGP є управління потоком транзитного трафіку.

На підставі того, як окрема AS поводиться із транзитним трафіком, розрізняють такі категорії AS:

AS-відгалуження (stub AS) – це автономна система, яка має тільки одне сполучення з іншою AS. AS-відгалуження переносить тільки локальний трафік.

AS із багатьма під’єднаннями (multihomed AS) – це AS, сполучена більш, ніж з однією іншою AS, але непридатна для переносу транзитного трафіку.

Транзитна AS (transit AS) - це AS, сполучена більш, ніж з однією іншою AS і призначена (з можливими політичними обмеженнями) до перенесення як локального, так і транзитного трафіку.

Оскільки повний шлях в AS забезпечує ефективний і простий спосіб для уникнення петель раутінгу і виключає проблему “підрахунку до безмежності”, пов’язану із певними алгоритмати “вектор-відстань”, то BGP не має топологічних обмежень на взаємні сполучення автономних систем.

BGP в Internet

Топологічні обставини. Загальна топологія Internet розгладається як довільне сполучення транзитних AS, AS із багатьма під’єднаннями та AS-відгалужень. З метою зменшення впливу поточної інфраструктури Internet два останні види AS не мусять використовувати BGP. Вони можуть вживати інші протоколи (наприклад, EGP) для обміну інформацією про досяжність із транзитними AS. Транзитні автономні системи можуть позначати цю інформацію як таку, що може вивчатися певними методами, відмінними від використаних у BGP. Те, що BGP не місить використовуватися в AS із багатьма під’єднаннями та AS-відгалуженнях, не має негативного впливу на загальну якість раутінгу між автоногмними системами для трафіку, який генерується або завершується в AS із багатьма під’єднаннями та AS-відгалуженнях. Однак, рекомендується використовувати BGP також і в цих автономних системах. У цих випадках BGP забезпечує переваги у ширині смуги та характеристиках перед іншими протоколами (наприклад, EGP). Крім того, це може зменшити потребу у використанні маршрутів за замовчуванням та забезпечити кращий вибір маршрутів всередині AS для AS із багатьма під’єднаннями.

Глобальна природа BGP. На глобальному рівні BGP використовується для поширення раутінгової інформації серед багатьох автономних систем. Потік інформації можна представити, як це показано на рис. 3.73.

Рис. 3.73.

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

Відношення між BGP-сусідами. Раутери, які комунікуються безпосередньо один з одним чернез BGP, називають BGP-спікерами. Вони можуть бути розташовані всередині тієї ж AS або в різних AS. BGP-спікери в кожній AS комунікуються із іншими для обміну інформацією про досяжність мереж, базуючись на системі стратегій, встановленій у кожній AS. Для даного BGP-спікера кожен інший BGP-спікер, з яким комунікується даний, вважається зовнішнім відповідником (peer), якщо він розміщений в іншій автономній системі, і внутрішнім відповідником, якщо він розміщений у тій самій AS. Можна було б вважати, що всередині AS потрібно багато BGP-спікерів. Звичайно, коли AS має багато під’єднань до інших AS, потрібно багато BGP-спікерів. Всі BGP-спікери, які відносяться до одної автономної системи, повинні назовні давати сумісний образ цієї AS. Тому BGP-спікери мусять мати сумісну раутінгову інформацію. Ці шлюзи можуть комунікуватися між собою через BGP або іншим чином. Стратегічні обмеження, прийняті для всіх BGP-спікерів всередині автономної системи, мусять бути сумісними. Для виявлення можливої несумісності слід впроваджувати відповідні технології, такі як помічені IGP (див. нижче).

У випадку зовнішніх відповідників, вони мусять належати різним автономним системам, але використовувати спільну підмережу Канального рівня. Ця спільна підмережа повинна використовуватися для перенесення BGP-повідомлень між вказаними відповідниками. Використання BGP через проміжну AS робить неправильною інформацію про шлях в AS. Для встановлення того, до якої автономної системи відноситься BGP-спікер, у BGP необхідно використовувати номер автономної системи.

Вимоги до агрегування маршрутів. Щоб мати можливість генерувати агреговані маршрути на підставі часткової раутінгової інформації, необхідне сумісне впровадження BGP-4. Наприклад, BGP-спікер на границі автономної системи (або групи автономних систем) повинен бути здатним генерувати агреговані маршрути для всієї системи IP-адрес призначень[1], над якою він здійснює адміністративний контроль (включно з тими адресами, які йому виділені), навіть коли не всі з них досяжні у той сам час.

Сумісне впровадження може забезпечувати здатність до визначення того, коли можуть бути генеровані агреговані NLRI.

Сумісне впровадження вимагається для отримання здатності до визначення, як можуть бути агреговані NRLI.

Сумісне впровадження вимагається для підтримки таких опцій, якщо мають справу із маршрутами, що перекриваються:

встановлення як менш, так і більш точних (specific) маршрутів;

встановлення тільки більш точного маршруту;

встановлення тільки менш точного маршруту;

невстановлення жодного маршруту.

Деякі стратегії раутінгу можуть залежати від NRLI (наприклад, “дослідницькі” порівняно з “комерційними”). Тому BGP-спікер, який здійснює агрегування маршрутів, повинен бути ознайомлений, якщо можливо, про можливі включення стратегій раутінгу при агрегуванні NRLI.

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

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

AS із багатьма під’єднаннями (multihomed AS) може не діяти як транзитна автономна система щодо іншої AS, оголошуючи тільки маршрути до призначень, внутрішніх для цієї AS.

AS із багатьма під’єднаннями (multihomed AS) може стати транзитною для обмеженої множини суміжних AS, тобто для деяких, але не для всіх суміжних AS дана автономна система діє як транзитна. Це здійснюється через оголошення раутінгової інформації тільки для цієї обмеженої множини автономних систем.

Автономна система може використовувати або не використовувати певні AS для переносу транзитної інформації до себе.

Певна кількість критеріїв, пов’язаних із характеристиками, може бути контрольована з використанням BGP:

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

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

Переваги внутрішніх маршрутів перед зовнішніми.

Для сумісності всередині автономної системи шляхи з рівною вартістю, отримані внаслідок поєднання стратегій і звичайних процедур вибору маршруту, повинні бути розв’язані у сумісний спосіб (без протиріч).

Для BGP справедливе фундаментальне правило, що AS оголошує для своїх сусідніх автономних систем тільки ті маршрути, які вона сама використовує. Це правило відображає парадигму “стрибок за стрибком”, яка загалом вживається у сьогоднішньому Internet.

Вибір шляху за допомогою BGP. Одним із головних завдань BGP-спікерів є визначення різних шляхів від себе до множини призначень, охоплених певним адресним префіксом, вибір найкращого шляху із застосуванням відповідних стратегічних обмежень і наступне оголоження цього шляху усім своїм сусіднім BGP. Ключове питання полягає в тому, як виявляються і порівнюються різні шляхи. У традиційних протоколах типу “вектор-відстань” (наприклад, у RIP) існує тільки одна метрика (лічильник стрибків), пов’язана із шляхом. Тому порівняння двох шляхів зводиться до порівняння двох чисел. Ускладнення в раутінгу всередині автономної системи виникають внаслідок відсутності універсально обумовленої метрики серед автономних систем, яка могла б бути вжита для визначення зовнішніх шляхів. Замість того, кожна AS може мати власну систему критеріїв для визначення шляху.

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

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

Процес призначення ступеня переваги шляху базується на декількох джерелах інформації:

на явній інформації, присутній в повному AS-шляху;

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

Можливими критеріями для призначення ступеня переваги шляху є:

Номер AS (AS count). Шлях із меншим номером AS загалом кращий.

Міркування стратегії. BGP підтримує раутінг, базований на стратегії, який оснований на керованому розподілі раутінгової інформації. BGP-спікер може бути інформований про певні стратегічні обмеження (як всередині, так і зовні своєї AS) і здіснювати відповідний вибір шляху. Шляхи, які не відповідають стратегічним обмеженням, надалі не розглядаються.

Наявність або відсутність певної автономної системи або автономних систем у шляху. Засобами інформації з-поза меж BGP автономна система може знати про певні експлуатаційні характеристики (наприклад, ширину смуги, MTU, внутрішній діаметр AS) певних автономних систем і може надавати їм перевагу або навпаки.

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

Підмножини AS - шляху. AS-шлях, який є підмножиною довшого AS-шляху до того самого призначення, повинен отримати перевагу перед довшим шляхом. Будь-яка проблема у коротшому шляху (наприклад, його відмова) може також бути проблемою в довшому шляху.

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

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

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

Впровадження BGP повинні дозволяти AS надавати перевагу певному шляху до призначення, якщо наявний понад один шлях. Щонайменше, впровадження повинне підтримувати цю можливість через дозвіл адміністративного призначення ступеня переваги для маршруту, основаного виключно на IP-адресі сусіда, від якого прийнятий маршрут. Прийнятний діапазон призначеного ступеня переваги може міститися в межах [0, 2³¹-1].

Впровадження BGP повинні дозволяти AS ігнорувати маршрути із певних автономних систем в атрибуті шляху AS_PATH. Така функція може бути впроваджена через використання техніки, описаної в RFC 1104 "Models of Policy Based Routing", і через призначення “безмежності” ("infinity").як ваги для таких автономних систем. Процес виділення маршрутів повинен ігнорувати маршрути, які мають вагу, рівну “безмежності”.

Взаємодія з іншими зовнішніми протоколами раутінгу. Автономна система повинна оголошувати мінімальні агрегати для своїх внутрішніх призначень з урахуванням обсягу адресного простору, який поточно вживається. Це може бути використане адміністраторами автономних систем, які не вживають BGP-4, для встановлення того, на скільки маршрутів розділяється окремий агрегат.

Маршрут, який переносить атрибут шляху ATOMIC_AGGREGATE, не може бути експортований у BGP-3 або EGP2, доки таке експортування не може бути здійснене без розділення NRLI маршруту.

Для забезпечення поступової міграції BGP-спікер може бути учасником як EGP2, так і BGP-4, тобто BGP-спікер може приймати IP-інформацію про досяжність як у сенсі EGP2, так і в розумінні BGP-4. Інформація, прийнята EGP2, може бути внесена в BGP-4 з атрибутом шляху ORIGIN, встановленим в 1. Подібним чином інформація, прийнята через BGP-4, може бути внесена в EGP2. В останньому випадку, однак, існує потреба запобігти можливому інформаційному вибуху, коли IP-префікс, прийнятий від BGP-4, позначає множину послідовних мереж класів A/B/C. Внесення NRLI, прийнятих BGP-4, які позначають IP-підмережі, вимагає від BGP-спікера внесення відповідних мереж у EGP2. Локальна система повинна забезпечити механізм контролю обміну інформацією про досяжність між EGP2 і BGP-4. Зокрема, сумісне впровадження вимагається для підтримки всіх із далі вказаних опцій, коли здійснюється внесення у EGP2 інформації про досяжність, прийнятої від BGP-4:

внесення тільки маршруту за замовчуванням (0.0.0.0); заборона експорту будь-яких інших NRLI;

дозвіл керованого деагрегування, але тільки для окремих маршрутів; дозвіл експорту неагрегованих NRLI;

дозвіл експорту тільки неагрегованих NRLI.

Обмін раутінговою інформацією через EGP2 між BGP-спікерами, які є учасниками BGP-4, і чистими Egp2-спікерами може з’являтися тільки в межах автономної системи (домену).

Для забезпечення поступової міграції BGP-спікер може бути учасником як BGP-3, так і BGP-4, тобто BGP-спікер може приймати IP-інформацію про досяжність у сенсі BGP-3 і BGP-4.

BGP-спікер може вносити інформацію, отриману від BGP-4, до BGP-3 таким чином:

якщо атрибут шляху AS_PATH маршруту BGP-4 переносить сегмент шляху AS_SET, то атрибут AS_SET маршруту BGP-3 повинен бути побудований через очищення сегменту AS_SET як сегменту AS_SEQUENCE із результуючим AS_PATH, який є окремим AS_SEQUENCE. Оскільки ця процедура призводить до втрати інформації set/sequence, то вона не може впливати на захист від появи петель раутінгу, але може впливати на стратегії, базовані на змісті або порядку атрибутів AS_PATH.

якщо NRLI, отримані від BGP-4, вносяться у BGP-3, то необхідно усвідомлювати можливий інформаційний вибух, коли коли даний IP-префікс позначає множину послідовних мереж класів A/B/C. Внесення NRLI, прийнятих BGP-4, які позначають IP-підмережі, вимагає від BGP-спікера внесення відповідних мереж у BGP-3. Локальна система повинна забезпечити механізм контролю обміну інформацією про досяжність між BGP-3 і BGP-4. Зокрема, сумісне впровадження вимагається для підтримки всіх із далі вказаних опцій, коли здійснюється внесення у BGP-3 раутінгової інформації, прийнятої від BGP-4:

внесення тільки маршруту за замовчуванням (0.0.0.0); заборона експорту будь-яких інших NRLI;

дозвіл керованого деагрегування, але тільки для окремих маршрутів; дозвіл експорту неагрегованих NRLI;

дозвіл експорту тільки неагрегованих NRLI.

Обмін раутінговою інформацією через BGP-3 між BGP-спікерами, які є учасниками BGP-4, і чистими BGP-3-спікерами може з’являтися тільки в межах автономної системи (домену). Всередині певної автономної системи BGP-діалог між усіма BGP-спікерами цієї автономної системи може здійснюватися або тільки через BGP-3, або тільки через BGP-4.

Операції через комутовані віртуальні кола. Коли використовують BGP через підмережі з комутованими віртуальними колами (Switched Virtual Circuit - SVC) може бути бажано мінімізувати трафік, генерований BGP. Зокрема, може бути бажано вилучити трафік, пов’язаний з періодичними повідомленнями KEEPALIVE. BGP включає механізм для операцій через SVC, який дозволяє уникнути утримання постійно відкритих SVC і дозволяє виключити періодичне висилання повідомлень KEEPALIVE.

Нижче описано, як оперувати без періодичних повідомлень KEEPALIVE, щоб мінімізувати використання SVC, застосовуючи інтелектуальний менеджер SVC-кола. Запропонована схема може бути використана до “неперервних” кіл, які підтримують властивості, подібні до моніторингу якості зв’язку або ехо-запитів для визначення стану сполучності каналу. Механізм, описаний нижче, придатний тільки між BGP-спікерами, які сполучені безпосередньо через спільне віртуальне коло.

Встановлення сполучення BGP. Ця властивість вибирається шляхом встановлення в нуль значення параметра Hold Time в повідомленні OPEN.

Характеристики менеджера кіл. Менеджер кіл повинен мати достатню функціональність, щоб бути здатним компенсувати відсутність періодичних повідомлень KEEPALIVE:

він повинен бути здатним визначани недосяжність Канального рівня у прогнозований скінченний період появи відмови;

при визначенні недосяжності він повинен:

стартувати конфігурований таймер непрацездатності (подібно до типового значення Hold timer);

пробувати повторно встановити сполучення Канального рівня;

при вичерпанні таймера непрацездатності він повинен:

вислати до TCP позначення DEAD через внутрішнє коло;

якщо сполучення повторно встановлене, він повинен:

закрити таймер непрацездатності;

вислати позначення до TCP.

Властивості TCP. Слід зробити незначні модифікації в TCP для оброблення внутрішніх повідомлень від менеджера кіл:

DEAD: вилучити чергу пересилання і перевати TCP-сполучення;

UP: переслати будь-які дані з черги або дозволити оброблення вихідного сполучення TCP.

Спільні властивості. Деякі впровадження нездатні гарантувати, що процес BGP і менеджер кіл можуть оперувати як єдине ціле, тобто вони можуть діяти окремо, коли один із них зупинено. У цьому випадку необхідно впровадити періодичне двостороннє опитування між BGP-процесом і менеджером кіл. Якщо BGP-процес виявляє, що менеджер кіл не працює, то він повинен закрити всі відповідні TCP-сполучення. Якщо менеджер кіл виявляє, що BGP-процес не працює, то він повинен закрити всі свої сполучення, пов’язані із цим BGP-процесом і вилучити будь-які подальші вхідні сполучення.

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

За означенням всі тразитні автономні системи повинні бути здатні переносити трафік від або до його призначень, розташованих зовні цієї AS. Це вимагає певного ступеня взаємодії та координації між BGP і внутрішнім шлюзовим протоколом (IGP), яка здійснюється цією конкретною AS. Загалом трафік, утворений поза даною AS, пересилається як через внутрішні шлюзи (тобто шлюзи, які підтримують тільки IGP), так і через граничні шлюзи (шлюзи, які підтримують як IGP, так і BGP). Всі внутрішні шлюзи приймають інформацію про зовнішні маршрути від одного або більше граничних шлюзів автономних систем через IGP.

Залежно від механізму, використаного для поширення BGP-інформації всередині даної AS, слід приділити особливу увагу для досягнення сумісності між BGP та IGP, оскільки зміни стану поширюються через AS із різною швидкістю. Може існувати інтервал часу між моментом, коли певний граничний шлюз A приймає нову раутінгову інформацію, згенеровану іншим граничним шлюзом B всередині тієї самої AS, і моментом, коли IGP всередині цієї AS стає здатним маршрутувати транзитний трафік до граничного шлюза B. Протягом цього часового інтервалу може з’являтися або некоректний раутінг, або “чорні дірки”.

Для мінімізації таких проблем раутінгу граничний шлюз A не повинен оголошувати жодним своїм зовнішнім відповідникам маршрути до певної множини зовнішніх призначень, пов’язаних із даним адресним префіксом X через граничний шлюз B, доки всі внутрішні шлюзи всередині AS не будуть готові маршрутувати трафік до цих призначень через коректний вихідний граничний шлюз B. Іншими словами, внутрішній раутінг повинен збігатися до правильного вихідного шлюзу перед орглошенням маршрутів через цей шлюз до зовнішніх відповідників.

Нижче розглянені окремі техніки, придатні для досягнення стабільної взаємодії між BGP та IGP всередині автономної системи.

Поширення BGP-інформації через IGP. Оскільки BGP може забезпечити власний механізм для переносу BGP-інформації всередині AS, то він також може бути використаний в IGP для танспорту цієї інформації, доки IGP підтримує повне поширення раутінгової інформації, забезпечуючи механізм для розподілу BGP-інформації та збіжність за один прохід (роблячи механізм ефективним на елементарному рівні). Якщо IGP використовується для переносу BGP-інформації, то період десинхронізації, описаний вище, взагалі не з’являється, оскільки BGP-інформація поширюється всередині AS синхронно з IGP, а IGP збігається більш чи менш одночасно з поступанням нової раутінгової інформації. Відзначимо, що IGP тільки переносить BGP-інформацію і не повинен інтерпретувати чи обробляти її.

Помічений внутрішній шлюзовий протокол. Певні внутрішні шлюзові протоколи можуть помічати маршрути, зовнішні відносно AS, на підставі ідентифікації їх кінцевих точок, доки вони переносять ці маршрути всередині AS. Кожен граничний шлюзовий протокол повинен використовувати ідентичні мітки для оголошення зовнішньої раутігової інформації (прийнятої через BGP) як в IGP, так і при поширенні цієї інформації до інших внутрішніх відповідників (відповідників всередині тієї ж AS). Мітки, генеровані граничним шлюзом, повинні унікально ідентифікувати цей конкретний граничний шлюз; інші граничні шлюзи повинні вживати інші мітки.

Всі граничні шлюзи всередині окремої AS повинні дотримуватися таких двох правил:

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

Інформація, прийнята від внутрішніх відповідників граничним шлюзом A щодо множини досяжних призначень, пов’язаних з даним адресним префіксом X, не повинна поширюватися до жодного зовнішнього відповідника A, якщо/доки A має IGP-маршрути до множини призначень, охоплених префіксом X, і обидві раутінгові інформації (BGP та IGP) мають ідентичні мітки.

Ці правила гарантують, що жодна раутінгова інформація не буде оголошена назовні, доки IGP не буде здатний її коректно підтримувати. Це також дозволяє уникнути випадків “чорних дірок”.

Одним із можливих методів для помічення BGP-та IGP-маршрутів всередині AS є використання IP-адреси виходу граничного шлюза, який оголошує зовнішні маршрути в AS. У цьому випадку поле "gateway" у повідомленні BGP UPDATE використовується як мітка.

An alternate method for tagging BGP and IGP routes is to have BGP and the IGP agree on a router ID. In this case, the router ID is available to all BGP (version 3 or higher) speakers. Since this ID is already unique it can be used directly as the tag in the IGP.

Альтернативний метод для помічення GGP-та IGP-маршрутів полягає у тому, щоб мати узгоджений ідентифікатор раутера для BGP та IGP. У цьому випадку ідентифікатор раутера доступний всім BGP-спікерам (для BGP версій 3 і вище). Оскільки цей ідентифікатор завжди унікальний, то він може бути безпосередньо використаний як мітка в IGP.

Інкапсуляція. Інкапсуляція забезпечує найпростіший (у поняттях взаємодії між BGP та IGP) механізм для перенесення транзитного трафіку через AS. У цьому випадку транзитний трафік інкапсулюється в IP-данограму, адресовану до вихідного шлюза. Єдиною вимогою до IGP є його здатність підтримувати раутінг між граничними шлюзами всередині тієї ж AS. Адреса вихідного шлюза A для певного зовнішнього призначення X визначена в полі BGP-ідентифікатора BGP-повідомлення OPEN, прийнятого від шлюза A (через BGP) всіма іншими граничними шлюзами всередині даної AS. Для маршрутування трафіку до призначення X кожен граничний шлюз всередині AS інкапсулює його в данограми, адресовані до шлюза A. Шлюз A зійснює виділення оригінальних пакетів і пересилає їх до відповідного шлюза в іншій AS. Оскільки інкапсуляція для перенесення овнішньої раутінгової інформації не базується на IGP, то синхронізація між BGP та IGP не потрібна.

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

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

Інші випадки. Можливі автономні системи з такими IGP, які ані не можуть переносити BGP-інформацію, ані помічати зовнішні маршрути (наприклад, RIP). Крім того, інкапсуляція може бути невикональна або небажана. У таких ситуаціях слід дотримуватися таких двох правил:

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

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

Повищі правила подають необхідні, але не достатні, умови для поширення раутінгової інформації BGP до інших AS. На відміну від момічених IGP, ці правила не можуть забезпечити, щоб внутрішні маршрути до відповідних вихідних шлюзів були доречними перед поширенням маршрутів до інших AS.

Якщо час збіжності IGP менший від певного малого значення X, то часовий інтервал, протягом якого IGP та BGP незсинхронізовані, є менший від X і повища проблема може бути зігнорована коштом перехідного періоду (меншої тривалості від X) нестабільності раутінгу. Розумне значення X є предметом подальших досліджень, але X ймовірно може бути меншим від однієї секунди. Якщо ж час збіжності IGP не може бути зігнорований, то порібні різні спроби. Механізми і техніки, які могли б бути придатними у цьому випадку, ще досліджуються.

[1] У термінології BGP-4 така система називається інформацією досяжності Мережевого рівня (Network Layer Reachability Information – NLRI).