BGP Route Reflection - алтернатива на Full Mesh IBGP

статус на документ

Този документ съдържа спецификация на протокола, предложен от интернет общността. Документът служи като покана за дебат, за да се развие и подобри протокола. Сегашното състояние на стандартизацията на протокол можете да научите от документ на «Интернет Официален протокол стандарти» (STD 1). Документът може да се разпространява без ограничения.

BGP 1 [1] е протокол за маршрутизация интер-домейн предназначен за TCP / IP мрежи. В момента BGP мрежа интернет протокол е конфигуриран така, че всички BGP лектори в рамките на една AS трябва да бъдат напълно затворени контури набор от връзки (напълно смесили), както и всяка външна информация маршрута трябва да бъде съобщена на всички други рутери в рамките на този AS. Това е сериозен проблем за мащабиране, описан подробно във връзка с алтернатива, предложен в [2,3].

Този документ описва метод за "размисъл маршрут» (Reflection Route) и неговото използване за отслабване на изискването за пълно окото IBGP.

1. Въведение

В момента BGP мрежа интернет протокол е конфигуриран така, че всички BGP лектори в рамките на една AS трябва да бъдат напълно затворени контури набор от връзки и всяка външна информация за маршрутите, трябва да се съобщава на всички други рутери в рамките на този AS. За п BGP възли в колкото е необходимо да се организира п * (п-1) / 2 отделни сесии IBGP. Очевидно е, че изискването за Full става невъзможно в системите, в които голям брой IBGP единици обменят значително количество информация за маршрутите (както е обичайно в повечето съвременни мрежи).

Този проблем мащабиране и много предложения за намаляване на неговата тежест са подробно описани в документи [2,3]. Този документ представя друг вариант на разположение на пълната мрежа, известна като Отражение на маршрут. Този метод позволява възел, за да BGP (наречена Route отражател), за да рекламира IBGP научих маршрути до определени IBGP връстници. Той се променя конвенционалния концепцията за работа и добавя две нови опция непреходен 2 BGP атрибути за предотвратяване на електрически вериги в маршрута актуализации.

Този документ е преработен вариант на [4] RFC1966 и включва редакционни промени, корекции и уточнения, основани на опита от използването на маршрута на размисъл. Списъкът на промени се предоставя в допълнение.

2. Основни изисквания

метод Route размисъл отговаря на следните критерии.

Всяка алтернатива трябва да бъде ясен и лесен за инсталиране.

Трябва да е възможно да се премине от пълна конфигурация, без да се налага да сменяте топологията или като. Методът, предложен в [3], което прави разходите твърде високи по отношение на контрола.

Тези критерии се основават на опита на много големи мрежи с комплекс топология и много външни връзки.

3. Отражение на маршрут

Основната идея на метода на отражение (Route Reflection) е много проста. Да разгледаме примера, показан на Фигура 1.

Фигура 1: подход Пълният IBGP меша

система на батерията има три възли ASX IBGP (РТР-A фрези, РТР-B, РТР-C). В рамките на съществуващото BGP модел, ако RTR-A получава външен маршрут и избира маршрута като най-добрия път тя трябва да се рекламират на външния път към двата възела RTR-B и RTR-C. Възли RTR-B и RTR-C (като говорителите IBGP) няма да възстанови рекламират тези IBGP научих маршрути до други говорители IBGP.

Ако това правило е да отслабва и да позволи на възел RTR-С рекламира маршрути, получени от IBGP IBGP други партньори, а след това отново ще се рекламират (или отразява) IBGP маршрути научили от RTR-A, B възел RTR-и обратно. Това ще премахне организация IBGP сесия между възлите RTR-A и RTR-B, както е показано на фигура 2.

Фигура 2: IBGP с отражение маршрут

Шофиране метод Route размисъл тя се основава на този принцип.

4. терминологията и понятията

Ние използваме термина "маршрут размисъл", за да опише действията на говорител BGP, обявявайки IBGP научих маршрути до други IBGP говорители. Ако възелът BGP се нарича "метод на рефлекторите» (Route рефлектор или RR), това означава, че възелът "отразява" получиха своите партньори маршрути.

Партньори, които не са клиенти.

Един RR отразява маршрути между тези групи и могат да отразяват маршрути между клиенти. Един RR заедно със своите клиенти връстници образуват клъстер (Cluster).

Партньори, които не са клиенти (Non-Client връстници), трябва да поддържат Full съчетаването, но това изискване се повдига за клиентите. Фигура 3 показва пример за мрежа с базови RR, илюстрираща терминология.

Фигура 3: RR компоненти

Вътрешен възел партньори RR са разделени в две групи:

5. Метод на работа

Когато RR получава маршрут от IBGP партньорската той избира най-добрия път на базата на собствените си критерии. След най-добрият път е избран, трябва да направите следните операции в зависимост от вида на партньора, които получават най-добрия начин:

Маршрутът от партньор, който не е клиент.

Отразяване на всички клиенти.

Маршрутът от клиент.

Отразяване на всички партньори, които не са клиенти и партньори-клиенти (като клиенти не могат да бъдат напълно око).

Автономна система може да включва множество от RR. Един RR лакомства други рефлектори RR, както всички други вътрешни високоговорители BGP. RR може да бъде конфигуриран да има друга RR, както сред клиентите и между партньорите, а не на клиента.

В една проста конфигурация, основната мрежа може да бъде разделена на множество клъстери. Всеки RR ще бъде конфигуриран с други RR, който не принадлежи към групата на клиенти (по този начин, всички RR ще бъде напълно око). Клиентите ще бъдат конфигурирани да поддържат IBGP сесия само с RR в техния сектор. Благодарение на размисъл маршрут, всички говорители IBGP ще получават отразени информация за маршрутите.

6. Превишение RR

Обикновено клъстер от клиентите ще имат една единствена RR. В този случай, на клъстера ще бъдат определени от RR на стойност ROUTER_ID рефлектор. Въпреки това, тази опция може да не осигурява достатъчна надеждност и множество RR може да се генерира за архивиране в същия клъстер. Всички рефлектори RR един клъстер може да бъде конфигуриран да използва общо 4 байта идентификатор CLUSTER_ID, която позволява на всеки да хвърли рефлектор RR маршрути, получени от други RR на същия клъстер.

7. Предотвратяване на електрически вериги

При използване на отражение маршрут може да възникне, когато reanonsirovanii линия Получената неправилна конфигурация. метод Route Отражение определя следните характеристики за откриване и избягване на маршрута цикли.

ORIGINATOR_ID - по избор, без преходен BGP атрибут на Type код 9. Този атрибут е с дължина 4 байта и е създадена RR рефлектор отразен маршрут. Умение ще носи източник маршрут ROUTER_ID (източника) в местния АС. А BGP говорител не трябва да създава ORIGINATOR_ID атрибут, ако някой вече съществува. Router атрибут дискриминатор ORIGINATOR_ID, трябва да се игнорира по маршрута, съдържащ стойността на своята ROUTER_ID като ORIGINATOR_ID.

CLUSTER_LIST - по желание непреходен BGP атрибут тип код 10. Този атрибут е на CLUSTER_ID последователност ценности, представляващи пътя на размисъл, по маршрута е изтекъл. атрибут формат е показано по-долу.

3 поле Дължина показва броя на октета.

Когато RR отразява маршрут, тя трябва да добавите местната CLUSTER_ID до начало (сравнява първите) CLUSTER_LIST. Ако CLUSTER_LIST е празен, той трябва да създадете нов списък. С помощта на този атрибут, RR може да идентифицира ако контурът ако информация за маршрутите, в резултат на грешки в конфигурацията. Ако рекламата получените трябва да се пренебрегва местната CLUSTER_ID настоящето в списъка на клъстери.

8. относно внедряването

Трябва да се вземат мерки, за да се предотврати промяна на атрибутите описани по-горе път (конфигурация средства) по време на размяна на информация за маршрутите между RR и клиенти и чуждестранни клиенти. Такова изменение може да доведе до маршрутизиране бримки.

В допълнение, когато RR отразява маршрут, то не следва да се промени в атрибутите на пътя: NEXT_HOP, AS_PATH, LOCAL_PREF и MED, тъй като това може да доведе до маршрутите цикли.

9. Конфигуриране и внедряване

BGP протокол предвижда никакъв начин за клиент, за да се идентифицира като динамично RR клиенти. Най-лесният начин да се постигне това е чрез ръчна настройка.

Един ключов подход маршрут отражение при решаването на въпроса за мащабиране е, че RR обобщава информация за маршрутите и само отразява най-добре по пътя си.

Изборът на маршрут, BGP може да повлияе и на двете метрики МЕД и интегрирани графични процесори. Тъй като MED атрибути не винаги са съвместими и IGP показател може да се различава за всеки рутер, в някои варианти, размисъл размисъл метод топология може да предвиди при избора резултат на маршрута, че на цялата система IBGP. За да се получи същите резултати биха били с подхода на пълно IBGP на окото трябва да бъде да се уверите, че маршрутните отражатели никога да изберат най-добрия маршрут на базата на BGP IGP показатели, което се различава значително от IGP-показателите на своите клиенти, или въз основа на непоследователна MED атрибути. В първото изпълнение може да се постигне чрез регулиране на конфигурация, така че в рамките на IGP показател винаги дава предимство над intercluster IGP показател, и подкрепят пълно свързване (пълен меша) в клъстер. всеки от следните методи могат да бъдат използвани за прилагане на второто изпълнение:

инсталиран на местна предпочитанията на маршрути в съответствие с MED гранично ниво рутер;

гарантира, че AS_PATH дължини се различават за различните AS дължина на пътя, когато се използва като критерий за подбор;

коригира въз основа на групите политики (общност), чието използване ще даде възможност на рефлектора, за да изберете най-добрия път.

Може да се твърди, че второто изискване е прекалено рестриктивен, а в някои случаи ще бъде непрактично. Човек може да се твърди, че при липса на маршрута примки не е необходимо да се осигури труден мач резултати за маршрутизация с използване на цялата система за IBGP мрежа.

За да се предотврати маршрутизиране линии и поддържат в съответствие маршрутизация е важно внимателно да се разгледа мрежова топология при избора отражение маршрут топология. Като цяло, отражение топология маршрут трябва да лежи на топологията на мрежата, за да се направи, когато има много начини за даден префикс. Безспорно е да използвате POP отражение основа, в която всеки POP води собствено маршрут отражатели, обслужващи клиенти в POP, както и всички рефлекторите са напълно смесили. В допълнение, клиентите рефлектори във всяка POP често напълно зацепени с цел оптимално маршрутизиране в POP и вътрешният (за POP) IGP показател се предпочита в сравнение с показател между POP IGP.

10. Съображения за сигурност

Това разширение на BGP не се променя нивото на сигурност на присъщото IBGP [5].

11. Благодарение

13. Позоваването

Cisco Systems, Inc.

170 West Тасман диск

Сан Хосе, Калифорния 95134

Заявление. Сравнение с RFC 1966

Обяснено някои от условията, свързани с отражението на трасетата и маршрутите справка EBGP и възли.

Изяснени и са по-последователна обработка на получателя на маршрутизация вериги (чрез отражение).

Метод за добавяне CLUSTER_ID на CLUSTER_LIST бе заменен с «прикрепя» на «сравнява първите» в съответствие с провежданата код.

В глава "Конфигуриране и внедряване", добави внимание на някои въпроси, разгръщане метод.

Ограничените разрешенията, издадени по-горе са вечни и няма да бъде отменено от Интернет общество или неговите наследници или правоприемници.

Този документ и информацията, съдържаща се тук, се предоставя на "КАКТО Е" и обществото интернет и Internet Engineering Работна група ОТХВЪРЛЯ ВСИЧКИ ГАРАНЦИИ, изрични или подразбиращи се, включително, но не само, ГАРАНЦИЯ, ЧЕ ИЗПОЛЗВАНЕТО НА ИНФОРМАЦИЯТА ТУК НЯМА нарушава правата ИЛИ ГАРАНЦИИ ЗА ПРОДАВАЕМОСТ ИЛИ ПРИГОДНОСТ ЗА ОПРЕДЕЛЕНА ЦЕЛ.

потвърждаване

функция Финансиране RFC Editor е предоставена от Интернет общество.

1 Гранична Gateway Protocol - Border Gateway Protocol.

2 Оригиналът погрешно каза за две преход атрибут, който не съответства на определения от глава 7. Прибл. Транс.

3 поле дължина е погрешно е показано на фигурата като октет. Размерът на тази област може да бъде 1 или 2 октета, в зависимост от стойността на флага продължителен период на (см. Точка 4.3 RFC 4271). Прибл. Транс.

4 Този документ е нищожен и заменен от RFC 4271. Преводът е на разположение на www.protocols.ru уебсайт. Прибл. Транс.

5 В оригинала, документът погрешно наречен «Ограничени автономна система за Конфедерациите BGP». Прибл. Транс.