RFC 1966 BGP Route Reflection An alternative to full mesh IBGP

Network Working Group                                       T. Bates
Request for Comments: 1966                             cisco Systems
Category: Experimental                                    R. Chandra
                                                       cisco Systems
                                                           June 1996

BGP Route Reflection – альтернатива полносвязности IBGP

BGP Route Reflection

An alternative to full mesh IBGP

PDF

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

Этот документ определяет экспериментальный протокол (Experimental Protocol) для сообщества Internet. Документ не задает каких-либо стандартов Internet и служит приглашением к дискуссии в целях дальнейшего совершенствования. Допускается свободное распространение документа.

Тезисы

BGP2 [1] представляет собой протокол междоменной маршрутизации, разработанный для сетей TCP/IP. В настоящее время в сети Internet протокол BGP настроен так, что все узлы BGP в одной AS должны образовывать полносвязный набор соединений (fully meshed) и любая внешняя маршрутная информация должна передаваться всем остальным маршрутизаторам внутри данной AS. Это порождает серьезные проблемы масштабирования, которые подробно описаны вместе с альтернативными предложениями в документах [2, 3].

В данном документе описан метод «отражения маршрутов» (Route Reflection) и его использование, ослабляющее требование полносвязности для IBGP.

1. Введение

В настоящее время в сети Internet протокол BGP настроен так, что все узлы BGP в одной AS должны образовывать полносвязный набор соединений и любая внешняя маршрутная информация должна передаваться всем остальным маршрутизаторам внутри данной AS. Очевидно, что требование полносвязности становится невыполнимым в системах, где большое число узлов IBGP обменивается значительными объемами маршрутной информации (такая ситуация наблюдается в большинстве современных сетей).

Для n узлов BGP в данной AS требуется организовать n*(n-1)/2 уникальных сессий IBGP. При конечных размерах полосы каналов и производительности процессоров в маршрутизаторах это требование очевидно невыполнимо.

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

2. Базовые требования

Метод Route Reflection удовлетворяет перечисленным ниже критериям.

  • Простота

    Любое дополнение должно быть понятным и простым в настройке.

  • Простота перехода

    Должна обеспечиваться возможность перехода от полносвязной конфигурации без необходимости изменения топологии или AS. Метод, предложенный в [3], вносит слишком высокие издержки в части управления.

  • Совместимость

    Должна обеспечиваться возможность сохранения не поддерживающих данный метод узлов IBGP, как части исходной AS или домена, без потери какой-либо маршрутной информации BGP.

Эти критерии основаны на опыте использования метода в очень больших сетях со сложной топологией и множеством внешних соединений.

+-------+        +-------+
|       |  IBGP  |       |
| RTR-A |--------| RTR-B |
|       |        |       |
+-------+        +-------+
     \             /
 IBGP \     ASX   / IBGP
       \         /
        +-------+
        |       |
        | RTR-C |
        |       |
        +-------+

Рисунок 1: Полносвязная система IBGP

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

Основная идея метода отражения очень проста. Рассмотрим пример, показанный на рисунке 1.

В автономной системе 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.

 +-------+          +-------+
 |       |          |       |
 | RTR-A |          | RTR-B |
 |       |          |       |
 +-------+          +-------+
       \             /
   IBGP \    ASX    / IBGP
         \         /
          +-------+
          |       |
          | RTR-C |
          |       |
          +-------+

Рисунок 2: IBGPс отражением маршрутов

Схема метода Route Reflection основана именно на этом принципе.

4. Терминология и концепции

Мы используем термин «рефлектор маршрутов» (Route Reflector или RR) для обозначения узла BGP, принимающего участие в отражении. Внутренние партнеры узла RR делятся на две группы:

  1.  Партнеры-клиенты.

  2. Партнеры, не являющиеся клиентами.

Узел RR отражает маршруты между этими группами. Рефлектор RR вместе со своими клиентами образует кластер. Партнеры, не являющиеся клиентами, должны сохранять полносвязность, но для клиентов это требование снимается. Клиентам не следует организовывать партнерских отношений с внутренними узлами, не входящими в их кластер. На рисунке 3 показан пример сети с базовыми компонентами RR, иллюстрирующий терминологию.

/ - - - - - - - - - - - - - -\
|          Cluster           |
  +-------+        +-------+
| |       |        |       | |
  | RTR-A |        | RTR-B |
| |Client |        |Client | |
  +-------+        +-------+
|      \             /       |
   IBGP \           / IBGP
|        \         /         |
          +-------+
|         |       |          |
          | RTR-C |
|         |  RR   |          |
          +-------+
|           /   \            |
\ - - - - -/- - -\- - - - - -/
     IBGP /       \ IBGP
   +-------+     +-------+
   | RTR-D |IBGP | RTR-E |
   | Non-  |-----| Non-  |
   |Client |     |Client |
   +-------+     +-------+

Рисунок 3: Компоненты RR

5. Работа метода

Когда RR получает маршрут от партнера IBGP, он выбирает лучший путь на основе своих критериев. После выбора лучшего пути узел должен выполнить перечисленные ниже операции в зависимости от типа партнера, передавшего информацию о лучшем пути:

  1. Маршрут получен от партнера, не являющегося клиентом.

    Отразить маршрут всем клиентам.

  2. Маршрут получен от клиента.

    Отразить маршрут всем партнерам, не являющимся клиентами, а также всем партнерам-клиентам, кроме источника маршрута (поскольку клиенты могут не быть полносвязными).

  3. Маршрут получен от партнера EBGP.

    Передать всем партнерам, независимо от того, являются ли они клиентами.

Автономная система может включать множество 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

ORIGINATOR_ID – необязательный, непереходный атрибут BGP с кодом типа 9. Этот атрибут имеет размер 4 байта и создается рефлектором RR в отраженном маршруте. Атрибут будет включать значение ROUTER_ID источника маршрута в локальной AS. Узлу BGP не следует создавать атрибут ORIGINATOR_ID, если последний уже присутствует. Маршрутизатору, распознающему атрибут ORIGINATOR_ID, следует игнорировать маршрут, содержащие значение его ROUTER_ID в качестве ORIGINATOR_ID.

CLUSTER_LIST

CLUSTER_LIST – необязательный, непереходный атрибут BGP с кодом типа 10. Этот атрибут представляет собой список значений CLUSTER_ID, представляющий путь отражения, по которому передавался маршрут. Формат атрибута показан ниже.

         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Attr. Flags  |Attr. Type Code|    Length     | value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле Length4 указывает число октетов.

Когда рефлектор RR отражает маршрут, он должен добавить локальное значение CLUSTER_ID в конец списка CLUSTER_LIST. Если список CLUSTER_LIST отсутствует, узел должен создать новый список. Используя этот атрибут, RR может определять возникновение петель при передаче маршрутной информации в результате конфигурационных ошибок. Если локальное значение CLUSTER_ID присутствует в списке кластеров, полученный анонс следует игнорировать.

8. Вопросы реализации метода

Следует принять меры по предотвращению изменения описанных выше атрибутов пути (средствами конфигурации) в процессе обмена маршрутной информацией между RR и клиентами или партнерами, не являющимися клиентами. Такое изменение атрибутов может приводить к возникновению маршрутных петель.

В некоторых реализациях возможно изменение атрибута пути BGP NEXT_HOP. Например, рефлектору RR может потребоваться изменение NEXT_HOP для полученных от EBGP маршрутов при их передаче внутренним партнерам. Однако для рефлектора RR это должно быть невозможно на отражаемых маршрутах IBGP, поскольку такое изменение будет приводить к нарушению основного принципа отражения и может приводить к возникновению «черных дыр».

RR не следует изменять какие-либо атрибуты AS-PATH, которые могут влиять на согласованность выбора маршрута (т. е., LOCAL_PREF, MED, DPA). Такое изменение может приводить к возникновению маршрутных петель.

Протокол BGP не обеспечивает клиентам способа динамической идентификации себя в качестве клиентов RR. Простейшим способом такой идентификации является настройка конфигурации вручную.

9. Вопросы безопасности

Вопросы безопасности не обсуждаются в этом документе.

10. Благодарности

Авторы благодарят Dennis Ferguson, John Scudder, Paul Traina и Tony Li за дискуссии, которые привели к созданию этого документа. Идея метода основана на давней дискуссии между Tony Li и Dimitri Haskin.

11. Литература

[1] Rekhter, Y., and T. Li, «A Border Gateway Protocol 4 (BGP-4)», RFC 1771, March 1995.

[2] Haskin, D., «A BGP/IDRP Route Server alternative to a full mesh routing», RFC 1863, October 1995.

[3] Traina, P., «Autonomous System Confederations for BGP»6, RFC 1965, June 1996.

12. Адреса авторов

Tony Bates

cisco Systems

170 West Tasman Drive

San Jose, CA 95134

Phone: +1 408 527 2470

EMail: tbates@cisco.com

Ravishanker Chandrasekeran

(Ravi Chandra)

cisco Systems

170 West Tasman Drive

San Jose, CA 95134

EMail: rchandra@cisco.com


Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

1Этот документ обновлен и дополнен RFC 2796. Впоследствии документ был признан устаревшим и заменен RFC 4356. Переводы обоих документов имеются на сайте www.protocols.ru. Прим. перев.

2Border Gateway Protocol – протокол граничного шлюза.

3В оригинале ошибочно сказано про два переходных атрибута, что не соответствует определениями главы 7. Прим. перев.

4Поле Length ошибочно указано на рисунке, как 1-октетное. Размер этого поля может составлять 1 или 2 октета в зависимости от значения флага Extended Length (см. параграф 4.3 RFC 4271). Прим. перев.

5Этот документ утратил силу и заменен RFC 4271. Перевод имеется на сайте www.protocols.ru. Прим. перев.

6В оригинале этот документ ошибочно назван «Limited Autonomous System Confederations for BGP». Прим. перев.

7Этот документ был признан устаревшим и заменен RFC 3065. Перевод обоих документов имеется на сайте www.protocols.ru. Прим. перев.




RFC 1965 Autonomous System Confederations for BGP

Network Working Group                                      P. Traina
Request for Comments: 1965                             cisco Systems
Category: Experimental                                     June 1996

Конфедерации автономных систем в BGP

Autonomous System Confederations for BGP1

PDF

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

В этом документе определяется экспериментальный протокол (Experimental Protocol) для сообщества Internet. Документ не задает каких-либо стандартов. Принимаются предложения и комментарии. Документ может распространяться свободно.

Тезисы

Протокол BGP2 [1] представляет собой протокол маршрутизации между автономными системами, разработанный для сетей TCP/IP.

Данный документ описывает расширение BGP, которое может использоваться для создания конфедерации автономных систем, представляющихся как единая АС для узлов BGP, не входящих в конфедерацию.

Смысл этого расширения состоит в расширении возможностей управления политикой и упрощения поддержки больших автономных систем.

Описанное здесь расширение широко используется в сети Internet.

Введение

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

Кроме потенциального повышения уровня контроля за политикой маршрутизации современные методы развертывания BGP в одной AS организуют полносвязную (full mesh) систему соединений TCP между всеми узлами для обмена внешней маршрутной информацией. В автономных системах число внутридоменных соединений, которые должен поддерживать каждый граничный маршрутизатор, может становиться весьма значительным.

Деление автономной системы на части позволяет существенно снизить общее число внутридоменных соединений BGP, поскольку в этом случае требования связности упрощаются до уровня модели, используемой для междоменных соединений.

К сожалению деление автономной системы на части может увеличить сложность реализации политики маршрутизации на основе данных из атрибутов AS_PATH для всех членов Internet. Кроме того, это деление увеличит издержки на управление и координацию внешних партнерских связей при изменении внутренней топологии этого множества автономных систем.

И, наконец, деление больших AS может привести к неоправданному увеличению размера упорядоченной части атрибута AS_PATH. Некоторые распространенные реализации BGP могут использовать число «интервалов между AS» до данного адресата, как часть критерия выбора пути. Хотя такой метод определения предпочтительного маршрута не является оптимальным, при нехватке других данных он обеспечивает разумное поведение «по умолчанию», широко используемое в сети Internet. Следовательно, деление автономной системы на отдельные фрагменты может оказать существенное влияние на уровень оптимальности маршрутизации пакетов через Internet.

Однако обычно не возникает необходимости в раскрытии внутренней топологии таких поделенных на части автономных систем и это означает, что возможно представление множества автономных систем с единым администрированием как единого объекта или AS с точки зрения находящихся за пределами данной конфедерации автономных систем.

Термины и определения

AS Confederation

Группа автономных систем, анонсируемых с общим номером AS узлам BGP, не входящим в данную конфедерацию.

AS Confederation Identifier

Видимый снаружи номер автономной системы, идентифицирующий конфедерацию в целом.

Member-AS

Автономная система, включенная в данную конфедерацию AS.

Обзор

IDRP [2] представляет собой концепцию создания конфедераций в системах междоменной маршрутизации. Конфедерация маршрутных доменов IDRP представляется узлам IDRP, не входящим в эту конфедерацию, как единый административный объект. Описываемое здесь расширение основано на этой работе.

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

Расширение AS_CONFED для типа сегмента

В действующей спецификации BGP сказано, что атрибут AS_PATH является хорошо известным обязательным атрибутом, состоящим из последовательности сегментов пути (AS path segment). Каждый сегмент пути представляется триплетом <type/length/value>.

В соответствии с [1] тип сегмента пути задается однооктетным полем, для которого определены следующие значения:

Значение Имя Описание

1

AS_SET Неупорядоченный набор AS, через которые проходит маршрут из сообщения UPDATE.

2

AS_SEQUENCE Упорядоченный набор AS, через которые проходит маршрут из сообщения UPDATE.

В настоящем документе определены два дополнительных типа сегментов пути:

Значение Имя Описание

3

AS_CONFED_SET Неупорядоченный набор номеров Member AS в локальной конфедерации, через которую передается сообщение UPDATE.

4

AS_CONFED_SEQUENCE Упорядоченный набор номеров Member AS в локальной конфедерации, через которую передается сообщение UPDATE.

Принцип работы

Член конфедерации BGP будет использовать свой идентификатор конфедерации во всех транзакциях с партнерами, которые не являются членами данной конфедерации. Идентификатор конфедерации рассматривается как видимый извне номер AS, этот номер используется в сообщениях OPEN и анонсируется в атрибуте AS_PATH.

Член конфедерации BGP будет использовать свой идентификатор домена маршрутизации (routing domain identifier3) во всех транзакциях с партнерами, входящими в данную конфедерацию.

Узлу BGP, получившему атрибут AS_PATH с идентификатором конфедерации, соответствующим его конфедерации, следует трактовать путь так же, как это делается для путей, содержащих номер AS этого узла.

Правила изменения AS_PATH

Параграф 5.1.2 документа [1] заменяется приведенным ниже текстом:

Когда узел BGP распространяет маршрут, который был получен в сообщении UPDATE от другого узла BGP, ему следует изменить атрибут AS_PATH с учетом размещения узла BGP, которому передается маршрут:

a) Когда данный узел BGP анонсирует маршрут другому узлу BGP, расположенному в той же автономной системе, анонсирующему узлу не следует изменять связанный с этим маршрутом атрибут AS_PATH.

b) Когда данный узел BGP анонсирует маршрут узлу BGP, расположенному в соседней автономной системе, анонсирующему узлу следует изменить связанный с этим маршрутом атрибут AS_PATH как показано ниже:

1) если первый сегмент AS_PATH имеет тип AS_CONFED_SEQUENCE, локальной системе следует поместить свой номер AS как последний элемент списка (в крайнюю левую позицию).

2) если первый сегмент AS_PATH имеет тип, отличный от AS_CONFED_SEQUENCE, локальной системе следует поместить новый сегмент типа AS_CONFED_SEQUENCE в путь AS_PATH, включив свой идентификатор конфедерации в этот сегмент.

c) Когда данный узел BGP анонсирует маршрут узлу BGP, расположенному в соседней автономной системе и не являющемуся членом конфедерации (в которую входит данный узел), анонсирующему узлу следует изменить атрибут AS_PATH как показано ниже:

1) если первый сегмент AS_PATH имеет тип AS_CONFED_SEQUENCE, данный сегмент и все непосредственно следующие за ним сегменты типа AS_CONFED_SET или AS_CONFED_SEQUENCE удаляются из атрибута AS_PATH и после этого для атрибута выполняется этап 2 или 3 (см. ниже).

2) если первый оставшийся сегмент AS_PATH имеет тип AS_SEQUENCE, локальной системе следует поместить свой идентификатор конфедерации в качестве последнего элемента (поместить идентификатор в крайнюю левую позицию).

3) если после удаления сегментов AS_CONFED_SET/AS_CONFED_SEQUENCE не остается других сегментов пути или первый сегмент оставшейся части AS_PATH имеет тип AS_SET, локальной системе следует включить (prepend) в атрибут AS_PATH новый сегмент типа AS_SEQUENCE, указав в нем свой идентификатор конфедерации.

Когда узел BGP является источником маршрута, этому узлу следует:

a) включать пустой атрибут AS_PATH во все сообщения UPDATE, передаваемые узлам BGP в Member AS Number (пустой атрибут AS_PATH содержит нулевое значение в поле размера);

b) включать свой Member AS Number в сегмент AS_CONFED_SEQUENCE атрибута AS_PATH всех сообщений UPDATE, передаваемых узлам BGP в соседних AS, являющихся членами конфедерации (т. е., значение Member AS Number исходного отправителя будет единственным элементом атрибута AS_PATH);

c) включать номер AS своей конфедерации в сегмент AS_SEQUENCE атрибута AS_PATH всех сообщений UPDATE, передаваемых узлам BGP в соседних AS, которые не являются членами данной конфедерации; в этом случае номер AS конфедерации будет единственным элементом атрибута AS_PATH.

Общие вопросы администрирования

Вполне разумно в рамках конфедерации использовать единое администрирование и информацию IGP.

Узлам BGP следует разрешить анонсирование неизмененных атрибутов NEXT_HOP и MULTI_EXIT_DISCRIMINATOR (MED)партнерам из соседних AS, входящих в ту же конфедерацию. В дополнение к этому отменяется ограничение на передачу атрибута LOCAL_PREFERENCE партнерам из соседних AS своей конфедерации. Критерии выбора пути для информации, полученной от членов конфедерации могут быть такими же, как для партнеров из своей автономной системы.

Совместимость

Все включенные в конфедерацию узлы BGP должны распознавать расширения типа сегмента AS_CONFED_SET и AS_CONFED_SEQUENCE в атрибутах AS_PATH.

Любой узел BGP, не поддерживающий эти расширения, будет генерировать сообщение NOTIFICATION с кодом ошибки UPDATE Message Error и субкодом Malformed AS_PATH.

Перечисленные выше проблемы совместимости требуют от всех включаемых в конфедерацию узлов BGP поддержки данного расширения (BGP confederations). Однако от узлов BGP за пределами конфедерации такой поддержки не требуется.

Проблемы совместимости

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

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

Литература

[1] Rekhter, Y., and T. Li, «A Border Gateway Protocol 4 (BGP-4)», RFC 1771, March 1995.

[2] Kunzinger, C. Editor, «Inter-Domain Routing Protocol», ISO/IEC 10747, October 1993.

Вопросы безопасности

В этом документе не рассматриваются вопросы безопасности.

Благодарности

Автор благодарит Ravi Chandra и Yakov Rekhter за просмотр документа и конструктивные, полезные замечания.

Адрес автора

Paul Traina

cisco Systems, Inc.

170 W. Tasman Dr.

San Jose, CA 95134

EMail: pst@cisco.com


Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

1Документ утратил силу и заменен RFC 3065, который, в свою очередь, был заменен RFC 5065. Прим. перев.

2Border Gateway Protocol.

3Видимый только членам конфедерации номер AS

4Только внутри своей AS. Прим. перев.

5Этот вариант спецификации протокола признан устаревшим и заменен RFC 4271. Прим. перев.