BGP Route Reflection - An Alternative to Full Mesh IBGP
статус документа
У цьому документі міститься специфікація протоколу, запропонованого спільноті Internet. Документ служить запрошенням до дискусії з метою розвитку і вдосконалення протоколу. Поточний стан стандартизації протоколу ви можете дізнатися з документа «Internet Official Protocol Standards» (STD 1). Документ може поширюватися без обмежень.
BGP 1 [1] являє собою протокол междоменной маршрутизації, розроблений для мереж TCP / IP. В даний час в мережі Internet протокол BGP налаштований так, що всі вузли BGP в одній AS повинні утворювати повнозв'язну набір з'єднань (fully meshed) і будь-яка зовнішня маршрутна інформація повинна передаватися всім іншим маршрутизаторів всередині даної AS. Це породжує серйозні проблеми масштабування, які докладно описані разом з альтернативними пропозиціями в документах [2,3].
В даному документі описаний метод «відображення маршрутів» (Route Reflection) і його використання, послаблює вимогу повнозв'язну для IBGP.
1. Введення
В даний час в мережі Internet протокол BGP налаштований так, що всі вузли BGP в одній AS повинні утворювати повнозв'язну набір з'єднань і будь-яка зовнішня маршрутна інформація повинна передаватися всім іншим маршрутизаторів всередині даної AS. Для n вузлів BGP в даній AS потрібно організувати n * (n-1) / 2 унікальних сесій IBGP. Очевидно, що вимога повнозв'язну стає нездійсненним в системах, де велика кількість вузлів IBGP обмінюється значними обсягами маршрутної інформації (така ситуація спостерігається в більшості сучасних мереж).
Ця проблема масштабування і численні пропозиції щодо зниження її гостроти докладно описані в документах [2,3]. Даний документ являє ще один варіант позбавлення від повнозв'язну, відомий як Route Reflection. Цей метод дозволяє вузлу BGP (званому Route Reflector) анонсувати отримані від IBGP маршрути деяким партнерам IBGP. Він змінює загальноприйняту концепцію роботи і додає два нових необов'язкових неперехідних 2 атрибута BGP для запобігання петель при оновленні маршрутів.
Даний документ є переглядом RFC1966 [4] і включає редакційні правки, пояснення і коригування, засновані на досвіді використання відображення маршрутів. Список змін наведено в Додатку.
2. Базові вимоги
Метод Route Reflection задовольняє перерахованим нижче критеріям.
Будь-яке доповнення повинно бути зрозумілим і простим в налаштуванні.
Повинна забезпечуватися можливість переходу від полносвязной конфігурації без необхідності зміни топології або AS. Метод, запропонований в [3], вносить дуже високі витрати в частині управління.
Ці критерії засновані на досвіді використання методу в дуже великих мережах зі складною топологією і безліччю зовнішніх з'єднань.
3. Відображення маршрутів
Основна ідея методу відображення (Route Reflection) дуже проста. Розглянемо приклад, показаний на малюнку 1.
Малюнок 1: Повнозв'язна система IBGP
В автономній системі ASX є три вузли IBGP (маршрутизатори RTR-A, RTR-B, RTR-C). В рамках існуючої моделі BGP якщо RTR-A отримує зовнішній маршрут і вибирає цей маршрут в якості кращого, він повинен анонсувати цей зовнішній маршрут обом вузлів RTR-B і RTR-C. Вузли RTR-B і RTR-C (як вузли IBGP) ні заново анонсувати цей отриманий від IBGP маршрут іншим партнерам IBGP.
Якщо це правило послабити і дозволити вузлу RTR-C анонсувати отримані від IBGP маршрути іншим партнерам IBGP, тоді він буде реанонсіровать (або відображати) маршрути IBGP, отримані від RTR-A, вузлу RTR-B і навпаки. Це дозволить відмовитися від організації сесії IBGP між вузлами RTR-A і RTR-B, як показано на малюнку 2.
Малюнок 2: IBGP з відображенням маршрутів
Схема методу Route Reflection заснована саме на цьому принципі.
4. Термінологія і концепції
Ми використовуємо термін «відображення маршрутів» для опису дій вузла BGP, що анонсує отримані від IBGP маршрути іншим партнерам IBGP. Якщо про вузол BGP говорять як про «відбивачі маршрутів» (Route Reflector або RR), це означає, що даний вузол «відображає» отримані маршрути своїм партнерам.
Партнери, які не є клієнтами.
Вузол RR відображає маршрути між цими групами і може відображати маршрути між клієнтами. Вузол RR разом зі своїми клієнтами утворює кластер (Cluster).
Партнери, які не є клієнтами (Non-Client peer), повинні зберігати повнозв'язну, але для клієнтів це вимога знімається. На малюнку 3 показаний приклад мережі з базовими компонентами RR, який ілюструє термінологію.
Малюнок 3: Компоненти RR
Внутрішні партнери вузла RR діляться на дві групи:
5. Робота методу
Коли RR отримує маршрут від партнера IBGP, він вибирає найкращий шлях на основі своїх критеріїв. Після вибору кращого шляху вузол повинен виконати такі операції в залежності від типу партнера, який передав інформацію про кращому шляху:
Маршрут отриманий від партнера, який не є клієнтом.
Відобразити маршрут всім клієнтам.
Маршрут отриманий від клієнта.
Відобразити маршрут всім партнерам, які не є клієнтами, а також партнерам-клієнтам (оскільки клієнти можуть не бути повнозв'язну).
Автономна система може включати безліч RR. Вузол RR трактує інші рефлектори RR, як звичайні внутрішні вузли BGP. Рефлектор RR може бути налаштований на присутність інших RR як в числі клієнтів, так і серед партнерів, які не є клієнтами.
У простій конфігурації опорна мережа може бути поділена на безліч кластерів. Кожен рефлектор RR налаштовується на те, що інші RR не належать до групи клієнтів (таким чином, всі RR будуть утворювати повнозв'язну систему). Клієнти будуть налаштовуватися на підтримку сесій IBGP тільки з RR в своєму кластері. Завдяки відображенню маршрутів все вузли IBGP отримуватимуть відображену маршрутну інформацію.
В автономній системі можуть бути присутніми вузли BGP, які не розуміють концепцію відображення маршрутів (будемо називати їх звичайними вузлами BGP). Схема відображення маршрутів допускає співіснування зі звичайними вузлами BGP. Такі вузли можуть ставитися до групи клієнтів або не бути клієнтами RR. Це забезпечує можливість простого і поступового переходу від існуючої моделі роботи IBGP до моделі з відображенням маршрутів. Можна почати з створення кластера шляхом настройки одного маршрутизатора в якості зазначеного RR і налаштування інших RR і їх клієнтів як нормальних партнерів IBGP. Поступово можуть створюватися додаткові кластери.
6. Надлишкові RR
Зазвичай кластер клієнтів буде включати один рефлектор RR. В цьому випадку кластер буде ідентифікуватися значенням ROUTER_ID рефлектора RR. Однак такий варіант може не забезпечувати достатню надійність і для резервування в одному кластері може створюватися безліч RR. Все рефлектори RR одного кластера можуть бути налаштовані на використання загального 4-байтового ідентифікатора CLUSTER_ID, який дозволяє будь-якому рефлектора RR відкидати маршрути, одержувані від інших RR того ж кластера.
7. Запобігання петель
При використанні відображення маршрутів можливе виникнення петель при реанонсірованіі в результаті некоректної конфігурації. Метод Route Reflection визначає два нових атрибута для детектування і запобігання таких петель.
ORIGINATOR_ID - необов'язковий, неперехідний атрибут BGP з кодом типу 9. Цей атрибут має розмір 4 байта і створюється рефлектором RR в відбитому маршруті. Атрибут включатиме значення ROUTER_ID джерела маршруту (originator) в локальній AS. Вузлу BGP не слід створювати атрибут ORIGINATOR_ID, якщо останній вже присутня. Маршрутизатора, розпізнавального атрибут ORIGINATOR_ID, слід ігнорувати маршрут, що містять значення його ROUTER_ID як ORIGINATOR_ID.
CLUSTER_LIST - необов'язковий, неперехідний атрибут BGP з кодом типу 10. Цей атрибут є послідовність значень CLUSTER_ID, що представляють шлях відображення, по якому передавався маршрут. Формат атрибута показаний нижче.
Поле Length 3 вказує число октетів.
Коли рефлектор RR відображає маршрут, він повинен додати локальне значення CLUSTER_ID в початок (prepend) CLUSTER_LIST. Якщо список CLUSTER_LIST порожній, вузол повинен створити новий список. Використовуючи цей атрибут, RR може визначати виникнення петель при передачі маршрутної інформації в результаті конфігураційних помилок. Якщо локальне значення CLUSTER_ID присутній в списку кластерів, отриманий анонс слід ігнорувати.
8. Питання реалізації методу
Слід вжити заходів щодо запобігання зміни описаних вище атрибутів шляху (засобами конфігурації) в процесі обміну маршрутною інформацією між RR і клієнтами або партнерами, які не є клієнтами. Така зміна атрибутів може призводити до виникнення маршрутних петель.
Крім того, коли RR відображає маршрут, йому не слід змінювати в маршруті значення атрибутів NEXT_HOP, AS_PATH, LOCAL_PREF і MED, оскільки це може призводити до виникнення маршрутних петель.
9. Питання настройки і розгортання
Протокол BGP не забезпечує клієнтам способу динамічної ідентифікації себе в якості клієнтів RR. Найпростішим способом такої ідентифікації є настройка конфігурації вручну.
Одним з ключових моментів методу відображення маршрутів в контексті проблеми масштабування є те, що RR обробляє отриману інформацію і відображає тільки кращий шлях.
На вибір маршруту BGP можуть впливати обидві метрики MED і IGP. Оскільки атрибути MED не завжди сумісні, а метрика IGP може відрізнятися для кожного маршрутизатора, в деяких варіантах топології відображення метод відображення може давати при виборі маршруту результат, що відрізняється від випадку полносвязной системи IBGP. Для отримання співпадаючих результатів у випадках використання відображення і повно системи IBGP слід зробити так, щоб рефлектори маршрутів ніколи не обирали найкращий маршрут BGP на основі метрики IGP, яка істотно відрізняється від IGP-метрики їх клієнтів, або на основі несумісних атрибутів MED. Перший варіант може бути досягнутий шляхом настройки конфігурації таким чином, щоб внутрікластерная метрика IGP завжди давала перевагу перед межкластерной метрикою IGP, і підтримки повної зв'язності (full mesh) всередині кластера. Для реалізації другого варіанту можна використовувати будь-який з перерахованих нижче способів:
встановлювати на граничному маршрутизаторі рівень локального переваги маршрутів відповідно до MED;
забезпечити, щоб довжини AS_PATH для різних AS розрізнялися при використанні довжини шляху в якості критерію вибору;
налаштувати засновану на групах (community) політику, використання якої дозволить рефлектора вибрати кращий шлях.
Можна стверджувати, що другий варіант вносить надмірні обмеження і в деяких випадках буде непрактичним. Можна також стверджувати, що при відсутності маршрутних петель не існує жорсткої необхідності забезпечувати збіг результатів вибору маршруту з використанням відображення і повно системи IBGP.
Для запобігання маршрутних петель і підтримки узгодженої картини маршрутизації важливо акуратно розглянути топологію мережі при виборі топології відображення маршрутів. У загальному випадку топологію відображення слід робити конгруентної топології мережі, коли існує безліч шляхів для даного префікса. Загальноприйнятим є використання відображення на базі POP, при якому кожна точка POP підтримує свої рефлектори маршрутів, які обслуговують клієнтів POP, і все рефлектори утворюють між собою повнозв'язну систему. На додаток до цього клієнти рефлекторів в кожній POP часто також утворюють повнозв'язну систему з метою оптимальної маршрутизації всередині POP, а внутрішня (для POP) метрика IGP є кращою у порівнянні з метрикою inter-POP IGP.
10. Питання безпеки
Це розширення протоколу BGP не змінює стану безпеки, властивого IBGP [5].
11. Подяки
13. Література
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Додаток. Порівняння з RFC 1966
Роз'яснено деякі терміни, пов'язані з відображенням маршрутів і виключені згадки маршрутів і вузлів EBGP.
Роз'яснено і зроблена більш узгодженої обробка одержувачем маршрутних петель (в результаті відображення).
Спосіб додавання атрибута CLUSTER_ID в список CLUSTER_LIST був замінений з «append» на «prepend» відповідно до реалізованим кодом.
У главу «Питання настройки і розгортання» додано розгляд деяких питань розгортання методу.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
підтвердження
Фінансування функцій RFC Editor забезпечується Internet Society.
1 Border Gateway Protocol - протокол граничного шлюзу.
2 В оригіналі помилково сказано про два перехідних атрибута, що не відповідає визначеннями глави 7. Прим. перев.
3 Поле Length помилково вказано на малюнку, як Однооктетне. Розмір цього поля може складати 1 або 2 октету в залежності від значення прапора Extended Length (див. Параграф 4.3 RFC 4271). Прим. перев.
4 Цей документ втратив чинність і замінений RFC 4271. Переклад є на сайті www.protocols.ru. Прим. перев.
5 В оригіналі цей документ помилково названий «Limited Autonomous System Confederations for BGP». Прим. перев.
