RFC 1773 Experience with the BGP-4 protocol

Network Working Group                                      P. Traina
Request for Comments: 1773                             cisco Systems
Obsoletes: 1656                                           March 1995
Category: Informational

Опыт использования протокола BGP-4

Experience with the BGP-4 protocol

PDF

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

Этот документ содержит информацию для сообщества Internet. Документ не задает каких-либо стандартов Internet и может распространяться свободно.

Введение

Целью настоящего документа является демонстрация того, как требования к повышению эффективности протокола маршрутизации, предложенного в проекте стандарта (Draft Standard) могут быть выполнены при использовании протокола BGP-4 (Border Gateway Protocol version 4). Документ основан на реальном опыте использования протокола BGP и является вторым и пары документов, посвященных опыту использования BGP. В соответствии с требованиями IAB (Internet Architecure Board) и IESG (Internet Engineering Steering Group) первый документ посвещен анализу работы протокола BGP.

В последующих разделах документа описано, как BGP выполняет общие требования (General Requirements), заданные в разделе 3 (Section 3.0), а также требования к проектам стандартов, указанные в разделе 5 (Section 5.0) документа Internet Routing Protocol Standardization Criteria [1].

Отчет основан на работах Peter Lothberg (Ebone), Andrew Partan (Alternet) и др. Результаты работы были представлены на 25-й конференции IETF и доступны в трудах IETF.

Комментарии к этому документу шлите по адресу iwg@ans.net.

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

Протокол BGP был разработан группой IDR (прежнее название BGP) в составе IETF. Автор документа выражает свою глубокую признательность Якову Рехтеру (Yakov Rekhter) и Сю Харес (Sue Hares) – сопредседателям рабочей группы IDR. Автор также хочет выразить свою благодарность Якову Рехтеру и Тони Ли (Tony Li) за прочтение документа и конструктивные комментарии.

Документация

BGP представляет собой протокол маршрутизации между автономными системами (AS) в сетях TCP/IP. Первая версия протокола BGP была опубликована в RFC 1105. После этого были разработаны версии BGP с номерами 2, 3 и 4. Вторая версия протокола была описана в RFC 1163, третья – в RFC 1267. Отличия между версиями 1, 2 и 3 рассмотрены в приложении Appendix 2 работы [2]. Версия 4 сохраняет все функции, поддерживаемые младшими версиями протокола.

В BGP версии 2 была удалена концепция отношений up, down, horizontal между автономными системами, которая использовалась в версии 1, и введена концепция атрибутов пути. Кроме того, в BGP версии 2 были определены части протокола, которые в первой версии не были специфицированы («under-specified»).

В BGP версии 3 были изменены ограничения на использование атрибута пути NEXT_HOP и добавлено поле BGP Identifier в сообщения BGP OPEN. Кроме того, были более четко сформулированы условия распространения маршрутов BGP между узлами BGP одной AS.

В BGP версии 4 была переопределена (до этого основанная на классах) часть, связанная с доступностью обновлений на сетевом уровне для использования префиксов произвольной длины, позволяющих анонсировать множество бесклассовых сетей в одном элементе, как было рассмотрено в работе [5]. В BGP-4 также был изменен атрибут AS-PATH для обеспечения возможности описывать с помощью этого атрибута как наборы автономных систем, так и отдельные AS. Кроме того, в четвертой версии был заново описан атрибут INTER-AS METRIC как MULTI-EXIT DISCRIMINATOR и добавлены атрибуты LOCAL-PREFERENCE и AGGREGATOR.

Возможности использования BGP в сети Internet рассмотрены в работе [3].

Протокол BGP был разработан группой IDR Working Group в составе IETF. Эта группа поддерживает список рассылок iwg@ans.net для обсуждения возможностей протокола и особенностей его использования. Рабочая группа IDR регулярно собирается на квартальных конференциях IETF. Отчеты о результатах этих встреч публикуются в IETF Proceedings.

MIB

Информационная база MIB (Management Information Base) для протокола BGP-4 была опубликована в работе [4]. Авторами MIB являются Стив Вилс (Steve Willis — Wellfleet), Джон Берруз (John Burruss – Wellfleet) и Джон Чу (John Chu — IBM).

За исключением нескольких системных переменных BGP MIB делится на две таблицы: BGP Peer (партнеры) и BGP Received Path Attribute (атрибуты пути).

Таблица Peer содержит сведения о соединениях с партнерами BGP (состояние, активность и т.п.). В таблице Received Path Attribute содержатся атрибуты путей, полученные от всех партнеров без применения локальной политика маршрутизации. Реальные атрибуты, используемые для определения маршрутов, являются подмножеством таблицы полученных атрибутов.

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

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

Поскольку BGP работает с использованием протоколов TCP и IP, схема аутентификации BGP может использовать любые механизмы аутентификации, обеспечиваемые этими протоколами. Однако, использование протоколов TCP и IP ведет к тому, что все уязвимости этих протоколов (например, возможность атак на службы или систему аутентификации) проявляются и в BGP.

Реализации

В настоящее время существует множество независимых интероперабельных реализаций протокола BGP. В этом разделе дан краткий обзор реализаций, используемых в сети Internet. К ним относятся реализации протокола:

— cisco Systems

— консорциум gated

— 3COM

— Bay Networks (Wellfleet)

— Proteon

Для упрощения разработки реализаций BGP и предотвращения типовых ошибок опыт реализации BGP-4 компании Cisco описан в RFC 1656 [4]. При реализации протокола настоятельно рекомендуется следовать рекомендациям этого документа и приложений к работе [2].

Опыт реализации BGP-4 показывает, что протокол достаточно прост и для реализации основных возможностей протокола BGP-4 достаточно 2 человеко-месяцев (без учета затрат времени на реализацию поддержки CIDR).

Отметим, что в соответствии с требованиями IAB/IESG для проектов стандарта (Draft Standard) существует множество независимых и полностью интероперабельных реализаций протокола.

Опыт использования протокола

В этом разделе рассматривается опыт использования BGP и BGP-4 в реальных сетях.

Протокол BGP используется в реальной сетевой среде с 1989 г., а BGP-4 – с 1993. В такое использование вовлечены по крайней мере две из перечисленных выше реализаций. Использование BGP включает применение всех значимых возможностей протокола. Сетевая среда, в которой BGP используется как протокол маршрутизации между автономными системами, является гетерогенной. В терминах полосы каналов диапазон возможных значений простирается от 28 кбит/c до 150 мбит/с. Системы, на которых реализован протокол BGP также существенно различаются по своей производительности – от небольших компьютеров PC/RT до высокопроизводительных RISC-систем. Протокол используется как на специализированных маршрутизаторах, так и на рабочих станциях общего назначения, использующих ОС UNIX.

Существенно различаются и топологии систем, где применяется протокол – от малочисленных соединений (остовное дерево ICM) до систем с высокой плотностью соединений (опорная сеть NSFNET).

Во время подготовки этого документа протокол BGP-4 использовался для маршрутизации между всеми наиболее значимыми AS, включая сети Alternet, ANS, Ebone, ICM, IIJ, MCI, NSFNET, Sprint. Меньшая из известных магистралей включает единственный маршрутизатор, а наиболее крупная – почти 90 узлов BGP. В общей сложности известно несколько сот узлов BGP1.

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

В большинстве транзитных сетей BGP используется как основной (и единственный) протокол передачи информации о внешних маршрутах. Во время подготовки этого документа протокол BGP на некоторых сайтах использоваляся вместе с протоколами внутренней маршрутизации для передачи информации о внешних маршрутах.

Полный набор внешних путей, передаваемый BGP превышает 20 000 агрегированных маршрутов2, которые описывают пути в подключенные сети.

Опыт использования протокола, описанный выше основан, прежде всего, на реализациях cisco и gated.

Конкретные детали использования BGP в сетях Alternet, ICM и Ebone были представлены на 25-й конференции IETF (Торонто, Канада) Питером Лотбергом (Peter Lothberg — Ebone), Эндрю Партаном (Andrew Partan — Alternet) и Полом Трэйна (Paul Traina — cisco).

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

Полоса, расходуемая на передачу трафика BGP измерялась в точке соединения между магистралями CA*Net и T1 NSFNET. Результаты этих измерений были представлены Деннисом Фергусоном (Dennis Ferguson) на 25-й конференции IETF и опубликованы в трудах IETF. Эти результаты явно показывают превосходство BGP по сравнению с протоколом EGP в части расхода полосы. Измерения на магистралях CA*Net (Dennis Ferguson) и T1 NSFNET (Susan Hares) также подтверждают преимущества BGP по сравнению с EGP по уровню загрузки CPU .

Переход к BGP версии 4

На многочисленных встречах ряда членов IETF неоднократно обсуждался вопрос о переходе к протоколам, поддерживающим бесклассовые сети (типа BGP-4).

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

Обсуждался вопрос о создании “маршрутных детонаторов” (route exploder), которые смогут регистрировать отдельные сети того или иного класса (class-based network) из блоков CIDR для узлов BGP-3, однако даже при беглом рассмотрении этого вопроса становится ясно, что такое решение потребует много памяти и сильно загрузит процессоры устройств BGP-3. Протокол BGP сам по себе не может отличить известные используемые сети от неиспользуемой части блоков CIDR.

Принятый большинством операторов путь перехода известен как “CIDR или смерть” («CIDR, default, or die!»).

Для проверки работы протокола BGP-4 была создана виртуальная “теневая” сеть Internet путем соединения сетей Alternet, Ebone, ICM и Cisco с помощью туннелей GRE. Эксперимент проводился с передачей реальной маршрутной информации через соединения BGP-3, обеспечивавшие нормальное функционирование участвующих в эксперименте сайтов. Такой подход позволил протестировать протокол BGP-4 до его развертывания в реальной сети.

После тестирования в теневой сети реализации BGP-4 были развернуты на реально используемом оборудовании этих сетей. Поддерживающие BGP-4 маршрутизаторы организовывали соединения BGP-4 между собой и взаимодействовали с другими маршрутизаторами по протоколу BGP-3. В сети включались некоторые тестовые агрегированные маршруты (в дополнение к сетям class-based) для обеспечения совместимости с узлами BGP-3.

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

После успешного развертывания BGP-4 множество сайтов отказалось от анонсирования на основе классов и перешло на использование CIDR-анонсов. Это подтолкнуло транзитных операторов, которые еще не перешли к новой форме анонсов, поскольку приводило к потере маршрутов в некоторые популярные сети.

Метрика

BGP-4 переопределяет старую метрику INTER-AS как MULTI-EXIT-DISCRIMINATOR. Это значение может использоваться в процессах разрыва соединений (tie breaking) при выборе предпочтительного пути к заданному блоку адресов. Значение MED используется только в тех случаях, когда сравниваются пути, полученные от разных внешних партнеров в одной AS для индикации предпочтений анонсирующей маршруты AS.

Назначением MED является определение наилучшего пути на заключительном этапе. Рабочая группа BGP считала, что любая метрика, заданная удаленным оператором будет воздействовать на маршрутизацию в локальной AS только в тех случаях, когда отсутствуют иные предпочтения. Первоочередной задачей MED было обеспечение гарантий того, что партнеры не будут «сливать» или «поглощать» трафик сетей, которые они анонсируют.

Атрибут LOCAL-PREFERENCE был добавлен для того, чтобы локальный оператор мог легко настроить правила, переопределяющие стандартный механизм выбора лучшего маршрута без настройки локальных предпочтений на других маршрутизаторах.

Одним из недостатков спецификации BGP4 было предложение использовать принятое по умолчанию значение LOCAL-PREF, если этот параметр не был задан. Использование 0 или максимального значения имеют свои недостатки, поскольку основной смысл принятого по умолчанию значения заключается в обеспечение взаимодействия маршрутизаторов разных производителей в рамках одной AS (поскольку LOCAL-PREF задается локальным администратором, при пересечении границы AS проблем совместимости не возникает).

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

            /---- транзит B ----\
пользователь                     транзит A----
            \---- транзит C ----/

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

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

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

Использование BGP внутри больших AS

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

По мере роста AS число таких соединений TCP будет расти по закону n2 и потребуется тот или иной метод настройки и поддержки таких соединений.. Протокол BGP не задает способ распространения такой информации, поэтому были предложены дополнения типа вставки атрибутов BGP в локальные протоколы IGP. Прилагались также усилия по разработке маршрутных рефлекторов BGP (route reflectors) или надежной транспортировки информации IBGP с использованием групповой адресации, что позволило бы снизить издержки по настройке, а также требования к памяти и ресурсам CPU на передачу данных всем внутренним партнерам BGP.

Динамика Internet

Как обсуждалось в работе [7], движущей силой порта производительности CPU и расширения полосы пропускания служит динамическая природа маршрутизации в Internet. По мере расширения сети растет и число изменений маршрутизации в единицу времени. Некоторый уровень снижения числа изменений возникает автоматически за счет агрегирования NLRI в более крупные блоки, однако этого не достаточно. В Приложении 6 к работе [2] описаны методы подавления, которые могут быть применены для анонсов. В будущих спецификациях протоколов, подобных BGP, методы подавления осцилляций следует рассматривать, как обязательные для соответствующих протоколу реализаций.

Подтверждения

Протокол BGP-4 был разработан рабочей группой IETF IDR/BGP. Автор выражает свою признательность Yakov Rekhter за подготовку документа RFC 1266, а также хочет явно отметить Yakov Rekhter и Tony Li за рецензирование данного документа, а также конструктивную критику и ценные замечания.

Адрес автора

Paul Traina

Cisco Systems, Inc.

170 W. Tasman Dr.

San Jose, CA 95134

EMail: pst@cisco.com

Литература

[1] Hinden, R., «Internet Routing Protocol Standardization Criteria», RFC 1264, BBN, October 1991.

[2] Rekhter, Y., and T. Li, «A Border Gateway Protocol 4 (BGP-4)», RFC 1771, T.J. Watson Research Center, IBM Corp., cisco Systems, March 1995.

[3] Rekhter, Y., and P. Gross, Editors, «Application of the Border Gateway Protocol in the Internet», RFC 1772, T.J. Watson Research Center, IBM Corp., MCI, March 1995.

[4] Willis, S., Burruss, J., and J. Chu, «Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2», RFC 1657, Wellfleet Communications Inc., IBM Corp., July 1994.

[5] Fuller V., Li. T., Yu J., and K. Varadhan, «Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy», RFC 1519, BARRNet, cisco, MERIT, OARnet, September 1993.

[6] Traina P., «BGP-4 Protocol Document Roadmap and Implementation Experience», RFC 1656, cisco Systems, July 1994.

[7] Traina P., «BGP Version 4 Protocol Analysis», RFC 1774, cisco Systems, March 1995.


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

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

nmalykh@gmail.com

1 С момента написания этого документа число узлов BGP в сети Internet многократно возросло. Прим. перев.

2 В начале 2003 года размер полной таблицы BGP превысил 120 000 записей. Прим. перев.




RFC 1772 Application of the Border Gateway Protocol in the Internet

Network Working Group                                     Y. Rekhter
Request for Comments: 1772    T.J. Watson Research Center, IBM Corp.
Obsoletes: 1655                                             P. Gross
Category:                                        Standards Track MCI
                                                             Editors
                                                          March 1995

Применение протокола BGP в Internet

Application of the Border Gateway Protocol in the Internet

PDF

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

Этот документ содержит спецификацию стандартного протокола, предложенного сообществу Internet, и является запросом для дальнейшего обсуждения в целях совершенствования протокола. Текущий статус протокола указан в «Internet Official Protocol Standards» (STD 1). Документ может распространяться свободно.

Тезисы

Этот документ вместе с «A Border Gateway Protocol 4 (BGP-4)»1 определяет протокол маршрутизации между автономными системами в среде Internet. Документ «A Border Gateway Protocol 4 (BGP-4)» содержит спецификацию протокола BGP, а данный документ описывает использование BGP в сети.

Информация об изменении протокола BGP и другие, связанные с этим протоколом сведения рассылаются по списку bgp@ans.net.

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

Первый вариант этого документа был выпущен как RFC 1164 в июне 1990 командой в составе Jeffrey C. Honig (Cornell University), Dave Katz (MERIT), Matt Mathis (PSC), Yakov Rekhter (IBM), Jessica Yu (MERIT).

В подготовке RFC 1164 значительную роль сыграли также Guy Almes (ANS, в то время Rice University), Kirk Lougheed (Cisco Systems), Hans-Werner Braun (SDSC, в то время MERIT), Sue Hares (MERIT).

Авторы выражают свою благодарность Bob Braden (ISI) за его обзор предыдущего варианта этого документа.

Обновленная версия документа является результатом работы группы IETF BGP, с Phill Gross (MCI) и Yakov Rekhter (IBM) в качестве редакторов.

John Moy (Proteon) внес свой вклад в подготовку главы 7.

Scott Brim (Cornell University) принимал участие в создании основы главы 8.

В создании большей части текста главы 9 принимал участие Gerry Meyer (Spider).

Фрагменты введения почти дословно перенесены из работы [3].

Авторы выражают свою благодарность Dan Long (NEARNET) и Tony Li (Cisco Systems) за их обзор и комментарии к текущей версии документа.

Работу Yakov Rekhter частично финансировал National Science Foundation в рамках Grant Number NCR-9219216.

1. Введение

В этом документе рассматривается использование протокола BGP (Border Gateway Protocol) [1] в среде Internet. BGP представляет собой протокол маршрутизации между автономными системами (AS). Информация о доступности сетей, передаваемая с помощью BGP, обеспечивает достаточно данных для обнаружения петель и принятия решений о маршрутизации на основе предпочтений и политики, согласованных в соответствии с RFC 1104 [2]. В частности, BGP обеспечивает обмен маршрутными данными, содержащими полные пути AS и обеспечивающими реализацию политики маршрутизации на основе конфигурационных параметров.

По мере роста сети Internet стали очевидными серьезные проблемы масштабирования, включающие:

Нехватку адресного пространства для сетей класса B. Одной из фундаментальных причин такой нехватки является бедность выбора класса сети по числу поддерживаемых адресов. Сети класса C позволяют адресовать 254 хоста и слишком малы для множества организаций, тогда как сети класса B, позволяющие адресовать 65534 хоста, слишком велики.

Рост размеров таблиц маршрутизации в сети Internet превышает возможности программ (и людей) по эффективному управлению этими таблицами.

Возможность нехватки пространства 32-битовых адресов IP.

Очевидно, что первые две проблемы достигнут критического уровня в ближайшие три года2. Бесклассовая междоменная маршрутизация CIDR (Classless inter-domain routing) является попыткой решения этих проблем за счет замедления роста таблиц маршрутизации и выделения новых номеров для сетей IP. CIDR не включает попыток решения третьей проблемы, которая по своей природе является не такой критичной во времени, но в результате возникает ряд осложнений, связанных с обеспечением эффективной работы сети Internet до решения глобальной проблемы нехватки адресного пространства.

Протокол BGP-4 является расширением BGP-3, обеспечивающим поддержку агрегирования маршрутной информации и снижения объема передаваемых данных за счет использования архитектуры бесклассовой междоменной маршрутизации CIDR [3]. Данный документ описывает использование BGP-4 в среде Internet.

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

По классическому определению автономная система представляет собой множество маршрутизаторов с единым техническим администрированием, использующих один протокол внутренней маршрутизации (IGP) и единую метрику для маршрутизации пакетов внутри AS, а для передачи пакетов в другие автономные системы применяющих протокол внешней маршрутизации (exterior gateway protocol или EGP). Со временем классическое определение было расширено и в современном понимании AS может использовать несколько протоколов внутренней маршрутизации, а в некоторых случаях даже несколько наборов метрик в рамках одной AS. Использование термина AS в таких случаях обусловлено тем, что даже при использовании множества метрик и протоколов IGP администрирование такой AS с точки зрения других автономных систем выглядит как единый план внутренней маршрутизации и показывает согласованную картину доступности адресатов с использованием данной AS.

2. Топологическая модель BGP

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

Физическое соединение – общая подсеть канального (Data Link) уровня между двумя AS, в которой каждая из AS имеет, по крайней мере, один граничный маршрутизатор, относящийся к данной AS. Таким образом, граничный маршрутизатор каждой AS может пересылать пакеты граничному маршрутизатору другой AS без использования внутридоменной или междоменной маршрутизации.

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

В этом документе к узлам BGP, формирующим BGP-соединение, предъявляется ряд дополнительных требований. Эти узлы должны находиться в той же подсети канального уровня (Data Link subnetwork), к которой относятся их граничные маршрутизаторы. Таким образом, сессия BGP между смежными AS не требует поддержки внутридоменной или междоменной маршрутизации. Ситуации, когда это требование не выполняется, выходит за пределы рассмотрения данного документа.

Таким образом, в любом соединении каждая AS имеет, по крайней мере, один узел BGP и, по крайней мере, один граничный маршрутизатор – эти узлы BGP и граничные маршрутизаторы должны находиться в одной подсети канального уровня. Отметим, что узлы BGP не обязаны быть граничными маршрутизаторами и наоборот. Пути, анонсируемые узлом BGP одной AS в данном соединении, пригодны для всех граничных маршрутизаторов другой AS той же подсети канального уровня, т. е., возможен обмен при отсутствии прямого соседства.

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

В зависимости от того, как конкретная AS поступает с транзитным трафиком, автономные системы можно разделить на три категории:

Тупиковая (stub) AS – автономная система, имеющая соединение только с одной AS. Очевидно, что тупиковая AS может поддерживать только локальный трафик.

Многодомная (multihomed) AS – автономная система, соединенная с несколькими AS, но не принимающая транзитный трафик.

Транзитная AS – автономная система, соединенная с множеством других AS и предназначенная (с некоторыми ограничениями на уровне политики) для поддержки как локального, так и транзитного трафика.

Поскольку полный путь AS обеспечивает простой и эффективный способ предотвращения маршрутных петель и избавляет от проблемы «count-to-infinity» (подсчет бесконечности), связанной с некоторыми алгоритмами на базе вектора расстояния, протокол BGP не вносит ограничений в топологию соединений между AS.

3. BGP в сети Internet

3.1 Топология

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

Рекомендуется, однако, использовать протокол BGP и для тупиковых/многодомных AS. В таких ситуациях протокол BGP обеспечивает более высокую производительность и меньший расход полосы, по сравнению с другими протоколами (типа EGP). Кроме того, этот протокол избавляет от необходимости задания принятых по умолчанию маршрутизаторов.

3.2 Глобальная природа BGP

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

         +-------+         +-------+
   BGP   |  BGP  |   BGP   |  BGP  |  BGP
---------+       +---------+       +---------
         |  IGP  |         |  IGP  |
         +-------+         +-------+
         <--ASA-->         <--ASB-->

Из приведенной диаграммы видно, что BGP служит для передачи информации между AS, а внутри каждой автономной системы может использоваться как BGP, так и IGP. Обеспечение совместимости маршрутной информации между протоколами BGP и IGP внутри AS имеет важное значение и рассматривается в Приложении A.

3.3 Соседство в BGP

Мы рассматриваем Internet как множество произвольно соединенных между собой AS. Маршрутизаторы, непосредственно взаимодействующие один с другим про протоколу BGP, называют узлами BGP (BGP speaker). Узлы BGP могут располагаться в одной или разных AS. Узлы BGP в каждой AS обмениваются между собой информацией о доступности сетей на основе наборов правил, заданных в каждой AS. По отношению к данному узлу BGP другие узлы, с которыми данный узел взаимодействует, называются внешними партнерами (external peer), если они размещаются в другой AS, или внутренними партнерами (internal peer), если они находятся в той же AS.

В автономной системе может присутствовать множество узлов BGP (сколько требуется для данной AS). Обычно автономные системы, имеющие множество соединений с другими AS, должны использовать более одного узла BGP. Все узлы BGP, представляющие одну AS, должны предоставлять согласованные маршрутные данные. Это требует согласования маршрутной информации между узлами BGP в автономной системе. Маршрутизаторы могут обмениваться информацией по протоколу BGP или иным способом. Правила, применяемые ко всем узлам BGP одной AS, должны быть согласованы. Для обнаружения рассогласований могут использоваться методы типа tagged IGP (см. стр. 7).

В случае внешних партнеров узлы находятся в разных AS, но должны входить в общую подсеть канального уровня (Data Link subnetwork). Эта общая подсеть должна использоваться для передачи информации BGP между узлами. Использование BGP через AS, мешающие обмену, делает информацию о путях AS некорректной. Для указания автономной системы, к которой относится узел BGP, следует использовать номер AS.

4. Требования к агрегированию маршрутов

Соответствующие требованиям BGP-4 реализации должны обеспечивать возможность информирования о тех случаях, когда агрегированный маршрут может быть сгенерирован только для части маршрутной информации. Например, узел BGP на границе автономной системы (или группы AS) должен быть способен генерировать агрегированный маршрут для целого набора IP-адресов получателей (в терминах BGP-4 такой набор называется Network Layer Reachability Information или NLRI), по отношению к которым он имеет административный контроль (включая делегированные узлом адреса), даже если некоторые из этих адресов в данный момент недоступны.

Соответствующие спецификации BGP-4 реализации протокола могут обеспечивать возможность указать, когда может генерироваться агрегированный NLRI.

Соответствующие спецификации BGP-4 реализации протокола должны обеспечивать возможность указать, как можно деагрегировать NLRI.

Соответствующие спецификации BGP-4 реализации протокола должны поддерживать перечисленные ниже опции при работе с перекрывающимися маршрутами:

  • установка как более специфичных, так и менее специфичных маршрутов
  • установка только более специфичного маршрута
  • установка только менее специфичного маршрута
  • отказ от установки маршрута

Некоторые аспекты политики маршрутизации могут зависеть от NLRI (например, «research» в сравнении с «commercial»). Следовательно, узел BGP, выполняющий агрегирование маршрутов, должен быть (по возможности) осведомлен о потенциальной причастности правил маршрутизации при агрегировании NLRI.

5. Создание политики BGP

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

BGP реализует политику путем выбора варианта пути при наличии множества возможностей и путем контроля за распространением маршрутной информации. Политика определяется администраторами AS.

Политика маршрутизации связана с вопросами безопасности, экономическими и политическими аспектами. Например, если AS не желает передавать трафик в какую-либо другую AS, она может реализовать политику, блокирующую передачу такого трафика. Ниже приведено несколько примеров политики маршрутизации, которая может быть реализована при использовании BGP:

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

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

Основой BGP является правило, согласно которому AS анонсирует в соседние AS только те маршруты, которые использует сама. Это правило отражает парадигму поэтапной (hop-by-hop) маршрутизации, широко используемую в современной сети Internet.

6. Выбор пути для BGP

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

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

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

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

Процесс определения уровня предпочтения для каждого из путей может основываться на нескольких источниках информации:

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

При выборе уровня предпочтения для пути возможно использование следующих критериев:

Счетчик AS. Путь с меньшим числом AS обычно является более предпочтительным.

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

Присутствие или отсутствие заданных AS в пути. Используя информацию, полученную от других протоколов (не BGP), AS может знать некоторые параметры производительности (например, полосу, MTU, внутренний диаметр AS) некоторых AS и использовать это знание при выборе пути.

Источник пути. Путь, полученный только от BGP (т. е., конечная точка пути является внутренней по отношению к последней AS на пути), в общем случае лучше путей, информация о которых получена от EGP или иным способом.

Подмножество пути AS. Путь AS, являющийся подмножеством более длинного пути AS к тому же адресату, является более предпочтительным. Любые проблемы, которые могут возникнуть на коротком пути, будут присутствовать и на длинном.

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

7. Требуемый набор поддерживаемых правил маршрутизации

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

Мы не пытаемся стандартизировать политику маршрутизации, которая должна поддерживаться каждой реализацией BGP, но настоятельно рекомендуем всем разработчикам поддерживать перечисленные ниже возможности:

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

Реализациям BGP следует давать AS возможность предпочтения конкретного пути к адресату (когда доступно несколько путей). Реализация должна, по крайней мере, поддерживать такую функциональность для административного выбора уровня предпочтения маршрутов на основе IP-адреса соседа, от которого получен маршрут. Допустимый диапазон значений уровня предпочтения составляет 0 — (231 – 1).

Реализации BGP следует предоставлять AS возможность игнорировать маршруты с некоторыми AS в атрибуте AS_PATH. Такая функция может быть реализована с использованием метода, описанного в работе [2], или путем присваивания таким AS «бесконечного» веса. Процесс выбора маршрута должен игнорировать пути с бесконечным весом.

8. Взаимодействие с другими протоколами внешней маршрутизации

Приведенные здесь рекомендации согласованы с рекомендациями работы [3].

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

Маршрут, содержащий атрибут пути ATOMIC_AGGREGATE, не следует экспортировать в системы BGP-3 или EGP2, если такой экспорт не может быть организован без использования NLRI для маршрута.

8.1 Обмен информацией с протоколом EGP2

Предлагается осуществлять обмен маршрутной информацией между BGP-4 и EGP2 в соответствии с приведенными здесь рекомендациями.

Для обеспечения элегантного перехода узел BGP может принимать участие в работе EGP2, используя одновременно BGP-4. Таким образом, узел BGP может получать данные о доступности IP-адресов как от EGP2, так и от BGP-4. Информация, полученная от EGP2, может быть помещена в BGP-4 с установкой для атрибута пути ORIGIN значения 1. Подобно этому, сведения от BGP-4 могут быть переданы EGP2. В последнем случае следует принимать во внимание сложности, которые могут возникнуть в тех случаях, когда префикс IP, полученный от BGP-4, обозначает набор последовательных сетей класса A/B/C. Вставка полученных от BGP-4 значений NLRI, соответствующих подсетям IP, требует от узла BGP вставки соответствующей сети в EGP2. Локальная система должна обеспечивать механизм контроля за обменом информацией о доступности между EGP2 и BGP-4. В частности, соответствующие стандарту реализации должны поддерживать при вставке полученных от BGP-4 сведений о доступности в EGP2 следующие опции:

  • по умолчанию используется только (0.0.0.0) без экспорта каких либо NLRI
  • обеспечивается контролируемое деагрегирование, но только для указанных маршрутов; обеспечивается экспорт неагрегированных NLRI
  • обеспечивается экспорт только неагрегированных NLRI

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

8.2 Обмен информацией с протоколом BGP-3

Предлагаемая схема обмена маршрутной информацией между BGP-4 и BGP-3, описана ниже.

Для обеспечения элегантного перехода узел BGP может принимать участие в работе BGP-3, используя в то же время BGP-4. Таким образом, узел BGP может поучать данные о доступности адресов IP как от BGP-3, так и от BGP-4.

Узел BGP может помещать полученные от BGP-4 сведения в BGP-3 описанным здесь способом.

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

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

  • по умолчанию используется только (0.0.0.0) без экспорта каких либо NLRI
  • обеспечивается контролируемое деагрегирование, но только для указанных маршрутов; обеспечивается экспорт неагрегированных NLRI
  • обеспечивается экспорт только неагрегированных NLRI

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

9. Работа в системах с SVC

При использовании BGP в подсетях с SVC (коммутируемые виртуальные устройства) может оказаться желательной минимизация трафика, генерируемого BGP. В частности, может оказаться желательным избавление от трафика, связанного с периодическими сообщениями KEEPALIVE. Протокол BGP включает специальный механизм для работы с SVC, позволяющий избежать постоянного использования коммутируемых каналов и не передавать периодических сообщений KEEPALIVE.

В этом разделе описана организация работы без периодических сообщений KEEPALIVE для минимизации использования SVC при работе с интеллектуальными менеджерами устройств SVC. Предложенная схема может использоваться и для постоянных соединений, которые поддерживают функции типа мониторинга качества или эхо-запросов для контроля за состоянием соединений.

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

9.1 Организация соединения BGP

Для активизации этого режима нужно задать нулевое значение параметра Hold Time в сообщении OPEN.

9.2 Свойства менеджера устройств

Возможности менеджера устройств должны обеспечивать компенсацию потери периодических сообщений KEEPALIVE:

  • Менеджер устройств должен обеспечивать возможность определения недоступности канала за предсказуемое конечное время после сбоя на канале.
  • После определения недоступности канала менеджер должен:
    • запустить настраиваемый dead-таймер (значение таймера сравнимо с типичным значением Hold timer).
  • попытаться восстановить соединение на канальном уровне.
  • По завершении отсчета dead-таймера менеджер должен:
    • передать информацию о разрыве соединения внутренними средствами (индикация DEAD) протоколу TCP.
  • После того, как соединение будет восстановлено, менеджер должен:
    • сбросить dead-таймер.
    • передать информацию о восстановлении (внутренний сигнал UP) протоколу TCP.

9.3 Свойства TCP

Для обработки сигналов от менеджера устройств требуется внести небольшие изменения в работу протокола TCP:

DEAD – сброс очередей передачи и разрыв соединения TCP.

UP – передача всех данных из очереди и возможность обработки входящих вызовов TCP.

9.4 Координация работы

Некоторые реализации не могут гарантировать, что процесс BGP и менеджер устройств будут работать как единое целое – т. е., один процесс может существовать сам по себе в результате остановки или краха другого процесса.

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

10. Заключение

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

Приложение A. Взаимодействие BGP и IGP

В этом разделе схематически рассмотрены методы обмена маршрутной информацией между протоколами BGP и IGP. Описанная схема не предлагается как часть стандарта на использование BGP и приведена только для информации. Разработчики могут использовать описанные здесь методы при импорте данных IGP.

Приведенная здесь информация имеет общий смысл и может применяться к любому протоколу IGP.

Взаимодействие между BGP и каким-либо конкретным протоколом IGP не рассматривается в данном документе и может быть включено в будущие стандарты.

Обзор

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

В зависимости от механизма, используемого для передачи информации BGP в данной AS, могут потребоваться специальные средства согласования между протоколами BGP и IGP, поскольку сведения об изменении состояний распространяются в AS с различными скоростями. В качестве такого средства может использоваться временное окно между моментом, когда тот или иной граничный маршрутизатор (A) получает новые маршрутные данные BGP, происходящие от другого граничного маршрутизатора (B) в той же AS, и моментом, когда IGP в данной AS сможет передавать транзитный трафик граничному маршрутизатору (B). Пока длится это «временное окно», возможна некорректная маршрутизация или возникновение «черных дыр».

Для минимизации влияния таких проблем граничному маршрутизатору (A) не следует анонсировать кому-либо из своих внешних партнеров маршрут к некому набору внешних адресатов, связанных с данным префиксом X через граничный маршрутизатор (B) до тех пор, пока внутренние маршрутизаторы в AS не будут готовы передавать трафик этим адресатам через корректный выходной граничный шлюз (B). Иными словами, внутренняя маршрутизация должна сойтись на подходящем выходном граничном маршрутизаторе до анонсирования маршрутов через этот шлюз внешним партнерам.

A.2 Методы стабилизации

Ниже схематически рассмотрены некоторые методы стабилизации взаимодействия между протоколами BGP и IGP внутри автономной системы.

A.2.1 Распространение информации BGP по протоколу IGP

Хотя протокол BGP может обеспечивать перенос информации BGP внутри AS за счет собственных средств, можно также использовать протокол IGP для транспортировки такой информации, если IGP поддерживает лавинную рассылку (flooding) маршрутных данных (обеспечивает механизм распространения информации BGP) и обеспечивает достаточную сходимость. Если протокол IGP используется для передачи информации BGP, тогда описанный выше период рассинхронизации не будет возникать совсем, поскольку информация BGP распространяется внутри AS синхронно с IGP и схождение IGP происходит более или менее синхронно с прибытием новых маршрутных данных. Отметим, что IGP только переносит информацию BGP и не должен интерпретировать или обрабатывать эти данные.

A.2.2 Tagged IGP

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

Все граничные маршрутизаторы одной AS должны придерживаться следующих правил:

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

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

Соблюдение этих правил дает гарантию того, что маршрутная информация не будет распространяться за пределы AS, пока IGP не обеспечит корректную поддержку для этих маршрутов. Эти правила позволяют также предотвратить возникновение «черных дыр».

Одним из методов обозначения маршрутов BGP и IGP внутри AS является использование в качестве метки IP-адреса выходного граничного маршрутизатора, анонсировавшего внешний маршрут в AS. В этом случае поле «gateway» сообщения BGP UPDATE служит в качестве метки.

Другой метод установки меток для маршрутов BGP и IGP заключается в использовании протоколами BGP и IGP согласованных идентификаторов для маршрутизаторов (Router ID). В этом случае значение Router ID доступно всем узлам BGP (начиная с версии 3). Поскольку этот идентификатор является уникальным, его можно применять в качестве тега IGP.

A.2.3 Инкапсуляция

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

Адрес выходного маршрутизатора A для некого внешнего адресата X указывается в поле идентификатора BGP сообщения BGP OPEN, принятого от маршрутизатора A (по протоколу BGP) всеми прочими граничными маршрутизаторами этой AS. Для маршрутизации трафика адресату X каждый граничный маршрутизатор в AS инкапсулирует этот трафик в дейтаграммы, адресованные маршрутизатору A. Получив такие дейтаграммы, маршрутизатор A извлекает из них пакеты и пересылает подходящему маршрутизатору другой AS.

Поскольку инкапсуляция не требует от IGP переноса внешних маршрутных данных, не нужна и синхронизация между протоколами BGP и IGP.

При использовании такого метода должен быть определен способ идентификации инкапсулированных пакетов IP (например, тип протокола IP).

Отметим, что при инкапсуляции пакетов, размер которых близок к значению MTU, пакет будет фрагментироваться выполняющим инкапсуляцию маршрутизатором.

A.2.4 Повсеместное распространение BGP

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

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

Поскольку в этом варианте IGP не переносит внешних маршрутных данных, все маршрутизаторы AS будут обеспечивать схождение, как только все узлы BGP получат информацию о новом маршруте. Задержки для IGP не требуется и маршруты можно анонсировать сразу же.

A.2.5 Другие случаи

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

Полученная от внутреннего партнера граничным маршрутизатором A информация о недоступности адресатов должна незамедлительно рассылаться всем внешним партнерам A.

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

Выполнение приведенных выше правил является необходимым (но не достаточным) условием для распространения маршрутной информации BGP в другие AS. В отличие от tagged IGP, эти правила не обеспечивают гарантии того, что внутренние маршруты к подходящим выходным шлюзам будут включены в таблицу до того, как начнется рассылка маршрутной информации в другие AS.

Если время схождения IGP меньше некого малого значения X, временное окно, в течение которого отсутствует синхронизация между IGP и BGP, также будет меньше X и проблему можно игнорировать за исключением кратких (меньше X) периодов маршрутной нестабильности. Определение значений X является предметом для дальнейшего изучения, но (по возможности) это значение должно быть меньше секунды.

Если время схождения IGP нельзя игнорировать, требуется использовать другие механизмы. В настоящее время ведется работа по изучению таких механизмов.

Литература

[1] Rekhter Y., and T. Li, «A Border Gateway Protocol 4 (BGP-4), RFC 1771, T.J. Watson Research Center, IBM Corp., Cisco Systems, March 1995.

[2] Braun, H-W., «Models of Policy Based Routing», RFC 1104, Merit/NSFNET, June 1989.

[3] Fuller, V., Li, T., Yu, J., and K. Varadhan, «Supernetting: an Address Assignment and Aggregation Strategy», RFC1519, BARRNet, Сisco, MERIT, OARnet, September 1993.

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

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

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

Yakov Rekhter

T.J. Watson Research Center IBM Corporation

P.O. Box 704, Office H3-D40

Yorktown Heights, NY 10598

Phone: +1 914 784 7361

EMail: yakov@watson.ibm.com

 

Phill Gross

MCI Data Services Division

2100 Reston Parkway, Room 6001,

Reston, VA 22091

Phone: +1 703 715 7432

EMail: 0006423401@mcimail.com

Список рассылки IETF IDR WG: bgp@ans.net

Адрес для добавления в список: bgprequest@ans.net


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

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

nmalykh@gmail.com

2 Т. е. в 1996-98 гг. Прим. перев.

3 В настоящее время этот документ заменен RFC 4271. Перевод имеется на сайте http://www.protocols.ru. Прим. перев.




RFC 1771 A Border Gateway Protocol 4 (BGP-4)

Network Working Group                                     Y. Rekhter
Request for Comments: 1771    T.J. Watson Research Center, IBM Corp.
Obsoletes: 1654                                                T. Li
Category: Standards Track                              Cisco Systems
                                                             Editors
                                                          March 1995

A Border Gateway Protocol 4 (BGP-4)

Протокол BGP-4

PDF

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

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

Тезисы

Этот документ вместе с Application of the Border Gateway Protocol in the Internet2 определяет протокол маршрутизации между автономными системами Internet.

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

Первый вариант этого документа был опубликован в RFC 1267 (октябрь 1991), разработанном Kirk Lougheed (Cisco Systems) и Yakov Rekhter (IBM).

Авторы выражают свою благодарность Guy Almes (ANS), Len Bosack (Cisco Systems) и Jeffrey C. Honig (Cornell University) за их вклад в подготовку предварительных вариантов документа.

Отдельно отметим Bob Braden (ISI) за обзор предварительных вариантов документа и конструктивные замечания.

Благодарим также Bob Hinden (Director for Routing of the Internet Engineering Steering Group) и команду специалистов, подготовивших обзор предыдущей версии документа (BGP-2). Эта команда, в состав которой входят Deborah Estrin, Milo Medin, John Moy, Radia Perlman, Martha Steenstrup, Mike St. Johns и Paul Tsuchiya, показала в работе высокий уровень профессионализма, упорство и такт.

Обновленный вариант документа является результатом работы IETF IDR Working Group. Редакторами документа являются Yakov Rekhter и Tony Li. Некоторые разделы этого документа заимствованы из спецификации IDRP [7], описывающей протокол BGP в рамках OSI. Подготовку этой спецификации обеспечила группа ANSI X3S3.3 под руководством Lyman Chapin (BBN) и Charles Kunzinger (IBM Corp.), который выполнял в группе функции редактора IDRP. Благодарим также Mike Craren (Proteon, Inc.), Dimitry Haskin (Bay Networks, Inc.), John Krawczyk (Bay Networks, Inc.) и Paul Traina (Cisco Systems) за полезные и важные комментарии.

Особо отметим значительный вклад в работу Dennis Ferguson (MCI).

Работа Yakov Rekhter поддерживалась фондом National Science Foundation в рамках гранта NCR-9219216.

2. Введение

BGP (Border Gateway Protocol – протокол граничного шлюза) является протоколом маршрутизации между автономными системами (AS). Протокол разработан с учетом опыта создания протокола EGP (RFC 904 [1]) и применения EGP на магистрали NSFNET (см. RFC 1092 [2] и RFC 1093 [3]).

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

BGP-4 обеспечивает новые механизмы поддержки бесклассовой междоменной маршрутизации (CIDR). Эти механизмы включают поддержку анонсирования префикса IP и позволяют обойтись без концепции «класса» сетей в рамках BGP. BGP-4 также включает механизм объединения маршрутов, включающий объединение путей AS. Эти изменения в совокупности обеспечивают поддержку схемы «суперсетей» (supernetting scheme) [8, 9].

Для того чтобы охарактеризовать набор решений, которые могут быть реализованы с использованием BGP, следует принять правило, по которому узел BGP может анонсировать узлам-партнерам (peer) в соседних AS только те маршруты, которые этот узел использует сам. Это правило отражает парадигму поэтапной (hop-by-hop) маршрутизации, используемую в сети Internet для большинства случаев. Отметим, что некоторые правила не могут поддерживаться в рамках парадигмы «hop-by-hop» и, следовательно, требуется использовать другие методы маршрутизации (такие, как source routing). Например, BGP не позволяет AS передавать в соседнюю AS информацию, показывающую маршрут, отличающийся от того, который будет использоваться для трафика, происходящего из соседней AS. С другой стороны, BGP может поддерживать любые правила, соответствующие парадигме поэтапной маршрутизации. Поскольку в современной сети Internet используется только парадигма поэтапной маршрутизации и BGP может поддерживать любые правила, соответствующие этой парадигме, протокол BGP очень распространен для маршрутизации между AS в современной сети Internet.

Более полное обсуждение возможности использования тех или иных правил с протоколом BGP выходит за пределы данного документа и рассматривается в работе [5], посвященной использованию BGP.

BGP использует транспортные протоколы с гарантированной доставкой. Это позволяет избавиться от необходимости поддержки механизмов фрагментации, передачи, подтверждения доставки и нумерации пакетов. Любая схема аутентификации, обеспечиваемая транспортным протоколом, может использоваться в дополнение к встроенным средствам аутентификации BGP. Используемый в BGP механизм уведомлений об ошибках предполагает, что транспортный протокол поддерживает «элегантное завершение сеансов («graceful» close), т. е. все остающиеся данные будут доставлены до разрыва соединения.

BGP использует на транспортном уровне протокол TCP [4]. TCP удовлетворяет транспортным требованиям BGP и поддерживается практически всеми современными маршрутизаторами и хостами. При последующем обсуждении слова «соединение транспортного уровня» (transport protocol connection) следует понимать как соединение TCP. Протокол BGP использует для организации соединений порт TCP с номером 179.

В этом документе постоянно будет встречаться термин «автономная система» (AS). По классическому определению автономная система представляет собой множество маршрутизаторов с единым техническим администрированием, использующих один протокол внутренней маршрутизации (IGP) и единую метрику для маршрутизации пакетов внутри AS, а для передачи пакетов в другие автономные системы применяющих протокол внешней маршрутизации (exterior gateway protocol или EGP). Со временем классическое определение было расширено и в современном понимании AS может использовать несколько протоколов внутренней маршрутизации, а в некоторых случаях даже несколько наборов метрик в рамках одной AS. Использование термина AS в таких случаях обусловлено тем, что даже при использовании множества метрик и протоколов IGP администрирование такой AS с точки зрения других автономных систем выглядит как единый план внутренней маршрутизации и показывает согласованную картину доступности адресатов с использованием данной AS.

Планируемое использование BGP в среде Internet включает такие вопросы, как топология, взаимодействие между BGP и протоколами IGP, а также исполнение правил политики маршрутизации, рассмотренных в работе [5], являющейся дополнением к настоящей спецификации. Этот документ является первым из серии планируемых работ по различным аспектам применения протокола BGP. Вы можете отправлять свои комментарии к этому документу по адресу списка рассылок BGP (bgp@ans.net).

3. Обзор

Две системы организуют между собой соединение на транспортном уровне. После этого системы обмениваются сообщениями для согласования и подтверждения параметров соединения. Первоначальный поток данных включает всю таблицу маршрутизации BGP. При изменении таблиц маршрутизации передаются обновления. Протокол BGP не требует периодического обновления всей таблицы маршрутизации BGP. Следовательно, узел BGP должен сохранять текущие версии полных таблиц маршрутов BGP всех соседей одного уровня (peer) в течение всего соединения. Для обеспечения сохранности соединения периодически передаются сообщения KeepAlive. При возникновении ошибок и в иных специальных случаях передаются специальные уведомления. При возникновении ошибок в соединении передается уведомление об этом и соединение закрывается.

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

Если отдельная AS имеет множество узлов BGP и обеспечивает транзит для других AS, внутри этой системы должна обеспечиваться согласованная картина маршрутизации, обеспечиваемая протоколом внутренней маршрутизации (IGP). Согласованная картина путей за пределы AS может обеспечиваться за счет прямых соединений между всеми узлами BGP в масштабе данной AS. Используя общий набор правил, узлы BGP согласуют политику обслуживания точек входа-выхода для конкретных адресатов за пределами данной AS. Эта информация передается внутренним маршрутизаторам AS (возможно с использованием протокола внутренней маршрутизации). Должны быть приняты меры по обеспечению обновления транзитной информации на внутренних маршрутизаторах до того, как узлы BGP анонсируют другим AS возможность обеспечения транзитного сервиса.

Соединения между узлами BGP разных AS будем называть внешними каналами, а соединения между узлами BGP в одной AS — внутренними. Узлы одного уровня (peer) из других AS будем называть внешними, а узлы в той же AS — внутренними.

3.1 Маршруты: анонсирование и хранение

При описании этого протокола маршрут определяется как единица информации, содержащая пару «отправитель-получатель» с атрибутами каждого из них.

  1. Маршруты анонсируются между парами узлов BGP как сообщения UPDATE – получателем является система, чей IP-адрес указывается в поле NLRI (Network Layer Reachability Information – информация о доступности на сетевом уровне), а путь указывается содержимым полей атрибутов пути в том же сообщении UPDATE.
  2. Маршруты сохраняются в базах данных RIB (Routing Information Base – база маршрутной информации) с использованием формата Adj-RIBs-In, Loc-RIB, Adj-RIBs-Out. Маршруты, которые будут анонсироваться другим узлам BGP, должны быть включены в Adj-RIB-Out; маршруты, используемые локальным узлом BGP, должны быть указаны в Loc-RIB, а следующий маршрутизатор (next hop) для каждого из этих маршрутов должен быть представлен в базе рассылки маршрутной информации локального узла BGP; маршруты, полученные от других узлов BGP, включаются в Adj-RIBs-In.

Если узел BGP решает анонсировать маршрут, он может добавить или изменить атрибуты пути для этого маршрута перед анонсированием маршрута другому узлу (peer).

Протокол BGP обеспечивает механизм, с помощью которого узел BGP может информировать узел-партнер (peer) о том, что анонсированный ранее маршрут больше не может использоваться. Для такого оповещения могут служить три метода:

  • в поле WITHDRAWN ROUTES сообщения UPDATE может быть передан префикс IP, указывающий получателя для анонсированного маршрута,– это говорит, что связанный с адресатом маршрут больше не доступен;
  • может быть анонсирован новый маршрут с тем же значением NLRI в качестве замены прежнего маршрута;
  • соединение между двумя узлами BGP может быть закрыто – это ведет к полному удалению всех маршрутов, которые эта пара узлов BGP анонсировала друг другу.

3.2 Базы данных о маршрутах

База маршрутной информации (RIB) узла BGP состоит из трех частей:

  1. Adj-RIBs-In: маршрутная информация, полученная во входящих сообщениях UPDATE. Эти данные представляют маршруты, которые могут использоваться в качестве входных данных для принятия решения (Decision Process).
  2. Loc-RIB: локальные маршрутные данные, которые узел BGP выбирает на основе своих локальных правил из данных Adj-RIBs-In.
  3. Adj-RIBs-Out: данные, которые локальный узел BGP выбрал для анонсирования peer-узлам. Маршрутные данные из Adj-RIBs-Out будут передаваться локальным узлом BGP в сообщениях UPDATE.

Adj-RIBs-In содержит необработанные маршрутные данные, которые получены локальным узлом BGP от узлов-партнеров; Loc-RIB содержит маршруты, выбранные с помощью Decision Process локального узла BGP; Adj-RIBs-Out включает маршрут, которые анонсируются в другие системы с помощью сообщений UPDATE.

Хотя концептуальная модель различает Adj-RIBs-In, Loc-RIB и Adj-RIBs-Out, совершенно не обязательно хранить три отдельных копии маршрутной информации. Выбор числа копий для конкретной реализации (например, 3 копии или 1 копия с указателями на каждую часть) не рассматривается в данной спецификации.

4. Формат сообщений

В этом разделе описаны форматы сообщений, используемых протоколом BGP.

Сообщения передаются с использованием транспортных соединений с гарантированной доставкой. Обработка сообщения происходит после того, как оно будет полностью принято. Максимальный размер сообщения составляет 4096 октетов. От всех реализаций требуется поддержка указанного значения для максимального размера сообщений. Минимальное сообщение, которое может быть передано, содержит только заголовок BGP (19 октетов).

4.1 Формат заголовка сообщений

Каждое сообщение имеет заголовок фиксированного размера. В зависимости от типа сообщения после заголовка может следовать то или иное количество полей данных. Схема размещения полей показана ниже:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                                                               +
|                           Marker                              |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Length               |      Type     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Marker — маркер

Это 16-октетное поле содержит значение, которое может быть предсказано получателем сообщения. Если Type = OPEN или сообщение OPEN не содержит Authentication Information (как дополнительного параметра — Optional Parameter), все биты поля Marker должны иметь значение 1. В остальных случаях значение маркера может быт предсказано путем расчетов, являющихся частью используемого механизма аутентификации (часть Authentication Information). Поле Marker может использоваться для обнаружения потери синхронизации между парой узлов BGP и аутентификации входящих сообщений BGP.

Length — длина

Это 2-октетное поле содержит беззнаковое целое число, указывающее общий размер сообщения (с учетом заголовка) в октетах. Эта информация позволяет находить следующее сообщение (поле Marker) в транспортном потоке. Значение поля Length должно лежать в диапазоне от 19 до 4096 (в зависимости от типа сообщения возможны дополнительные ограничения). Заполнение сообщений пустыми полями не допускается, поэтому поле длины должно иметь минимальное значение, достаточное для передачи сообщения.

Type — тип

Это 1-октетное поле содержит беззнаковое целое число, определяющее тип сообщения:

1 – OPEN (соединение)
2 – UPDATE (обновление)
3 – NOTIFICATION (уведомление)
4 – KEEPALIVE (подтверждение)

4.2 Формат сообщений OPEN

После организации соединения на транспортном уровне, первым сообщение от каждой из сторон имеет тип OPEN. После восприятия сообщения OPEN узел возвращает сообщение KEEPALIVE, которое подтверждает прием сообщения OPEN. После подтверждения OPEN может происходить обмен сообщениями UPDATE, KEEPALIVE, и NOTIFICATION.

В дополнение к стандартному заголовку BGP сообщение OPEN содержит следующие поля:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
|    Version    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     My Autonomous System      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Hold Time           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         BGP Identifier                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt Parm Len  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       Optional Parameters                     |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version — версия

Однооктетное беззнаковое целое, указывающее номер версии протокола BGP (для данной версии – 4).

My Autonomous System – моя AS

2-октетное беззнаковое целое, указывающее номер автономной системы отправителя.

Hold Time — время удержания

2-октетное беззнаковое целое, определяющее время (в секундах), которое отправитель предлагает в качестве значения таймера удержания (Hold Timer). Получив сообщение OPEN, узел BGP должен выбрать значение Hold Timer (меньшее из настроенного и полученного в сообщении OPEN значений Hold Time). Если значение Hold Time не равно 0, оно должно быть не меньше 3 секунд. Реализации протокола могут отвергать соединения на основе значения Hold Time. Выбранное значение показывает максимальный интервал (в секундах) между передачей последовательных сообщений KEEPALIVE и/или UPDATE.

BGP Identifier — идентификатор BGP

4-октетное беззнаковое целое, указывающее идентификатор BGP для отправителя. Узел BGP устанавливает в качестве значения идентификатора BGP IP-адрес, присвоенный этому узлу BGP. Значение BGP Identifier определяется при загрузке и совпадает для всех локальных интерфейсов и всех узлов BGP одного ранга.

Optional Parameters Length – размер дополнительных параметров

Это 1-октетное поле показывает размер поля дополнительных параметров (Optional Parameters) в октетах. Нулевое значение поля говорит об отсутствии дополнительных параметров.

Optional Parameters – дополнительные параметры

Это поле может содержать список дополнительных параметров, представленный в формате <Parameter Type, Parameter Length, Parameter Value> (тип, размер и значение параметра).

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
|  Parm. Type   | Parm. Length  | Parameter Value (переменный размер)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

Поле Parameter Type занимает один октет и однозначно идентифицирует отдельно взятый параметр. Поле Parameter Length имеет размер 1 октет и определяет число октетов в поле Parameter Value. Поле Parameter Value не имеет фиксированного размера и интерпретируется в зависимости от значения поля Parameter Type.

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

  1. Authentication Information (данные аутентификации, тип 1):

Этот параметр может использоваться для подтверждения полномочий партнера BGP (peer). Поле Parameter Value содержит 1-октетный код аутентификации, за которым следует поле данных переменной длины.

 0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
|  Auth. Code   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                     |
|              Authentication Data                    |
|                                                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Authentication Code (код аутентификации)

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

  • значение кода (Authentication Code), показывающее используемый механизм
  • форма или значение поля Authentication Data
  • алгоритм расчета значений полей Marker.

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

Authentication Data (данные аутентификации)

Форм и значение этого поля переменной длины зависят от кода аутентификации (Authentication Code).

Минимальный размер сообщения OPEN составляет 29 октетов с учетом заголовка.

4.3 Формат сообщений UPDATE

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

Сообщение UPDATE служит для анонсирования одного возможного маршрута к узлу-партнеру или для отзыва группы анонсированных ранее маршрутов (см. 3.1). Сообщение UPDATE может одновременно анонсировать доступный маршрут и отзывать группу недоступных более маршрутов. Сообщения UPDATE всегда включают заголовок BGP фиксированного размера и могут содержать дополнительные поля, показанные ниже:

Unfeasible Routes Length (2 октета)

Withdrawn Routes (переменный размер)

Total Path Attribute Length (2 октета)

Path Attributes (переменный размер)

Network Layer Reachability Information (переменный размер)

Unfeasible Routes Length (размер недоступных маршрутов)

Это 2-октетное беззнаковое целое число указывает общий размер поля Withdrawn Routes в октетах. Значение этого поля должно позволять определение размера поля Network Layer Reachability Information в соответствии с приведенным ниже описанием.

Нулевое значение говорит об отсутствии отзываемых маршрутов и поля Withdrawn Routes в сообщении UPDATE.

Withdrawn Routes (отзываемые маршруты)

Это поле переменной длины содержит список префиксов IP-адресов, маршруты к которым исключаются из обслуживания. Каждый префикс IP-адреса представляется в 2-компонентном формате <length, prefix>, показанном ниже:

Length (1 октет)

Prefix (переменный размер)

Поля имеют следующие значения:

      1. Length (длина):
        показывает размер префикса IP-адреса в битах; нулевое значение поля длины указывает префикс, соответствующий всем адресам IP (сам префикс содержит 0 октетов).

      2. Prefix (префикс):
        содержит префикс адреса IP, за которым следует несколько битов, используемых для выравнивания по границе октета (отметим, что значение битов заполнения не играет роли).

Total Path Attribute Length (общий размер атрибутов пути)

Это 2-октетное беззнаковое целое задает общую длину поля атрибутов пути (Path Attributes) в октетах. Значение этого поля должно позволять определение длины поля Network Layer Reachability в соответствии с описанной ниже процедурой.

Значение 0 говорит об отсутствии поля Network Layer Reachability Information в данном сообщении UPDATE.

Path Attributes (атрибуты пути):

Последовательность атрибутов пути (переменной длины) присутствует в каждом сообщении UPDATE. Каждый атрибут представляет собой триплет формата <attribute type, attribute length, attribute value> размер которого может меняться.

2-октетное поле Attribute Type содержит октет флагов (Attribute Flags) за которым следует октет типа (Attribute Type Code).

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

Старший бит (0) октета Attribute Flags является битом Optional и определяет тип атрибута – дополнительный (1) или хорошо известный (0).

Второй бит (1) поля Attribute Flags является битом Transitive, определяющим назначение дополнительного атрибута – переходный (1) или непереходный (0). Для хорошо известных атрибутов бит Transitive должен всегда иметь значение 1 (дополнительное рассмотрение переходных атрибутов приводится в главе 5).

Третий бит (2) поля Attribute Flags является флагом Partial. Этот бит показывает полноту информации, содержащейся в дополнительном переходном атрибуте – информация полная (0) или неполная (1). Для хорошо известных атрибутов бит Partial должен иметь значение 0.

Четвертый флаг (бит 3) задает бит Extended Length, определяющий размер поля Attribute Length – 1 октет (0) или 2 октета (1). Флаг Extended Length может использоваться только в тех случаях, когда размер поля атрибутов превышает 255 октетов.

Четыре младших бита поля Attribute Flags не используются и должны иметь нулевые значения (на приемной стороне эти биты игнорируются).

Октет Attribute Type Code содержит код типа атрибута. Определенные в настоящее время типы рассматриваются в главе 5.

Если бит Extended Length поля Attribute Flags имеет значение 0, третий октет поля Path Attribute содержит размер данных атрибута в октетах.

Если бит Attribute Flags поля флагов имеет значение 1, третий и четвертый октеты содержат размер данных атрибута в октетах.

Оставшиеся октеты поля Path Attribute представляют значение атрибута и интерпретируются в соответствии со значениями полей Attribute Flags и Attribute Type Code:

  1. ORIGIN (тип 1):

    Атрибут ORIGIN относится к числу хорошо известных и является обязательным – он определяет источник информации о пути. Октет данных атрибута может принимать следующие значения:

    0 IGP – информация NLRI является внутренней для AS, из которой пришло сообщение

    1 EGP – информация NLRI получена с помощью EGP

    INCOMPLETE – данные NLRI получены каким-либо иным способом.

    Использование этого атрибута описано в параграфе 5.1.1

  2. AS_PATH (тип 2):

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

    1-октетное поле типа сегмента может содержать следующие значения:

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

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

    Поле path segment length размером 1 октет указывает число AS в сегменте пути.

    Значение path segment value содержит один или несколько номеров AS, каждый из которых представлен 2-октетным полем. Использование этого атрибута описано в параграфе 5.1.2.

  3. NEXT_HOP (тип 3):

    Этот хорошо известный обязательный атрибут указывает IP-адрес граничного маршрутизатора, который следует использовать как следующий интервал (next hop) для адресата, указанного в поле Network Layer Reachability сообщения UPDATE. Использование этого атрибута описано в параграфе 5.1.3.

  4. MULTI_EXIT_DISC (тип 4):

    Этот необязательный непереходный атрибут представляет собой 4-октетное неотрицательное целое число. Значение атрибута может использоваться в процессе принятия узлом BGP решения по вопросу избавления от множественных точек выхода в соседнюю автономную систему. Использование этого атрибута описано в параграфе 5.1.4.

  5. LOCAL_PREF (тип 5):

    LOCAL_PREF является хорошо известным необязательным атрибутом, содержащим 4-октетное неотрицательное целое число. Значение атрибута используется узлом BGP для информирования других узлов BGP в своей автономной системе об уровне предпочтения для анонсируемого маршрута. Использование этого атрибута описано в параграфе 5.1.5.

  6. ATOMIC_AGGREGATE (тип 6)

    ATOMIC_AGGREGATE является хорошо известным необязательным атрибутом нулевой длины. Этот атрибут используется узлом BGP для информирования других узлов BGP о том, локальная система выбрала менее специфичный маршрут без выбора более специфичного маршрута, который включен в нее. Использование этого атрибута описано в параграфе 5.1.6.

  7. AGGREGATOR (тип 7)

    AGGREGATOR представляет собой дополнительный атрибут длиной 6 октетов. Этот атрибут содержит номер последней AS, которая формирует агрегированный маршрут (2 октета), за ним следует IP-адрес узла BGP, который формирует агрегированный маршрут (4 октета). Использование этого атрибута описано в параграфе 5.1.7

Network Layer Reachability Information (информация о доступности на сетевом уровне):

Это поле переменной длины содержит список префиксов IP-адресов. Размер поля NLRI в октетах не задается в явном виде, но может быть рассчитан как:

UPDATE message Length - 23 - Total Path Attributes Length - Unfeasible Routes Length

Значение UPDATE message Length берется из заголовка BGP, значения полей Total Path Attribute Length и Unfeasible Routes Length определяются из сообщения UPDATE, а значение 23 является суммарной длиной заголовка BGP и полей Total Path Attribute Length, Unfeasible Routes Length field.

Информация о доступности представляется в виде одной или нескольких последовательностей <length, prefix>, описанных ниже:

Length (1 октет)

Prefix (переменный размер)

  1. Length (размер):

    Это поле задает число битов префикса IP-адреса. Нулевое значение задает префикс, соответствующий любому адресу IP (сам префикс в этом случае содержит 0 октетов).

  2. Prefix (префикс):

    Это поле содержит префикс адреса IP, за которым могут следовать биты заполнения для выравнивания по границе октета. Значение битов заполнения не играет роли.

Минимальный размер сообщения UPDATE составляет 23 октета — 19 октетов занимает стандартный заголовок, 2 октета – поле Unfeasible Routes Length, 2 октета – поле Total Path Attribute Length (Unfeasible Routes Length = 0 и Total Path Attribute Length = 0).

Сообщение UPDATE может анонсировать по крайней мере один маршрут, который может быть описан несколькими атрибутами пути. Все атрибуты пути, содержащиеся в данном сообщении UPDATE, применимы к адресатам, указанным в поле Network Layer Reachability Information сообщения UPDATE.

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

Сообщение UPDATE может анонсировать только отзыв маршрутов. В этом случае сообщение не содержит атрибутов пути и данных NLRI. И наоборот, сообщение может анонсировать только доступный маршрут и не включать поля WITHDRAWN ROUTES.

4.4 Формат сообщения KEEPALIVE

BGP не использует на транспортном уровне каких-либо механизмов keep-alive для проверки доступности других узлов (peer). Вместо этого используются сообщения KEEPALIVE, которыми партнеры обмениваются достаточно часто, чтобы между двумя сообщениями не истекло время, заданное таймером удержания (Hold Timer). Разумным значением максимального интервала между передачей двух последовательных сообщений KEEPALIVE является треть интервала, заданного значением Hold Time. Недопустимо передавать сообщения KEEPALIVE чаще одного раза в секунду. Разработчики могут установить интервал между передачей сообщений KEEPALIVE как функцию значения Hold Time.

Если Hold Time = 0, периодическая передача сообщений KEEPALIVE недопустима.

Сообщение KEEPALIVE состоит только из заголовка, следовательно, размер такого сообщения равен 19 октетам.

4.5 Формат сообщения NOTIFICATION

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

В дополнение к стандартному заголовку BGP сообщение NOTIFICATION содержит следующие поля:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Error code   | Error subcode |           Data                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Error Code (код ошибки)

Это 1-октетное поле содержит беззнаковое целое число, указывающее тип сообщения NOTIFICATION:

Код

Название

Дополнительная информация

1

Message Header Error (ошибка в заголовке сообщения)

6.1 Обработка ошибок в заголовке.

2

OPEN Message Error (ошибка сообщения OPEN)

6.2 Обработка ошибок в сообщениях OPEN.

3

UPDATE Message Error (ошибка сообщения UPDATE)

6.3 Обработка ошибок в сообщениях UPDATE.

4

Hold Timer Expired (закончилось время удержания)

6.5 Обработка ошибок Hold Timer Expired.

5

Finite State Machine Error (ошибка машины конечных состояний)

6.6 Обработка ошибок машины конечных состояний.

6

Cease (разрыв соединения)

6.7 Разрыв соединения.

Error subcode (субкод ошибки)

Это 1-октетное поле содержит беззнаковое целое число, которое предоставляет дополнительные сведения о природе произошедшей ошибки. Каждое значение Error Code может быть связано с одним или несколькими значениями Error Subcode.

Если не определено подходящего субкода, устанавливается Error Subcode = 0 (неуказанная ошибка).

Субкоды ошибок Message Header Error:

1 — Connection Not Synchronized — соединение не синхронизировано.
2 — Bad Message Length – некорректный размер сообщения.
3 — Bad Message Type – некорректный тип сообщения.

Субкоды ошибок OPEN Message Error:

1 — Unsupported Version Number – неподдерживаемый номер версии.
2 — Bad Peer AS – некорректная AS партнера.
3 — Bad BGP Identifier – некорректный идентификатор BGP.
4 — Unsupported Optional Parameter – неподдерживаемый дополнительный параметр.
5 — Authentication Failure – отказ при аутентификации.
6 — Unacceptable Hold Time – недопустимое время удержания.

Субкоды ошибок UPDATE Message Error:

1 — Malformed Attribute List — некорректный список атрибутов.
2 — Unrecognized Well-known Attribute – нераспознанный атрибут из числа хорошо известных.
3 — Missing Well-known Attribute – отсутствует хорошо известный атрибут.
4 — Attribute Flags Error – ошибка во флагах атрибута.
5 — Attribute Length Error – некорректный размер атрибута.
6 — Invalid ORIGIN Attribute – некорректный атрибут ORIGIN
7 — AS Routing Loop – петля в маршрутизации AS.
8 — Invalid NEXT_HOP Attribute – некорректный атрибут NEXT_HOP.
9 — Optional Attribute Error- ошибка в дополнительном атрибуте.
10 — Invalid Network Field – некорректное поле сети.
11 — Malformed AS_PATH – некорректный формат AS_PATH.

Данные

Это поле переменной длины служит для диагностики причин генерации сообщений NOTIFICATION. Содержимое поля данных зависит от значений полей Error Code и Error Subcode. Дополнительная информация приведена в главе 6. Обработка ошибок BGP..

Отметим, что размер поля данных может быть определен по приведенной ниже формуле:

Message Length = 21 + Data Length

Минимальный размер сообщений NOTIFICATION составляет 21 октет (с учетом стандартного заголовка).

5. Атрибуты пути

В этой главе рассматриваются атрибуты пути, используемые в сообщениях UPDATE. Атрибуты делятся на 4 категории:

  1. Well-known mandatory – общеизвестные, обязательные.
  2. Well-known discretionary – общеизвестные, необязательные.
  3. Optional transitive – дополнительные, переходные.
  4. Optional non-transitive – дополнительные, непереходные.

Хорошо известные атрибуты должны распознаваться всеми реализациями BGP. Некоторые из этих атрибутов являются обязательными и должны присутствовать в каждом сообщении UPDATE. Остальные атрибуты являются необязательными и могут отсутствовать в некоторых сообщениях UPDATE. Все хорошо известные атрибуты должны (после соответствующей обработки, если это нужно) передаваться другим узлам BGP.

Кроме хорошо известных атрибутов каждый путь может содержать один или несколько дополнительных атрибутов. Поддержка дополнительных атрибутов не является обязательной для каждой реализации BGP. Обработка нераспознанных дополнительных атрибутов определяется установкой бита Transitive в октете флагов атрибута. Пути с нераспознанными переходными дополнительными атрибутами должны приниматься. Если путь с нераспознанными дополнительными переходными атрибутами принят и передается другим узлам BGP, нераспознанные атрибуты этого пути должны передаваться другим узлам BGP с установленным (1) битом Partial в поле Attribute Flags. Если путь с распознанным переходным атрибутом воспринят и передается другим узлам BGP, а бит Partial октета Attribute Flags имеет значение 1, установленное какой-либо из предыдущих AS, данная автономная система не должна сбрасывать этот бит в 0. Нераспознанные дополнительные непереходные атрибуты следует просто игнорировать, не передавая их другим узлам BGP.

Новые дополнительные переходные атрибуты могут добавляться в путь исходным отправителем (originator) или любой AS в пути. Если эти атрибуты не добавляются исходным отправителем, устанавливается значение Partial = 1 в октете Attribute Flags. Правила присоединения новых непереходных дополнительных атрибутов будут зависеть от природы конкретного атрибута. Предполагается, что документация к каждому новому дополнительному непереходному атрибуту будет включать такие правила (описание атрибута MULTI_EXIT_DISC может служить примером). Все дополнительные атрибуты (переходные и непереходные) могут обновляться (если это допустимо) автономными системами в пути.

Отправителю сообщения UPDATE следует размещать атрибуты пути в сообщениях UPDATE в порядке возрастания типа атрибутов. Получатель сообщения UPDATE должен быть готов к обработке атрибутов пути из сообщения с изменением их порядка.

Один атрибут не может появляться более одного раза в поле Path Attributes конкретного сообщения UPDATE.

5.1 Использование атрибута пути

Ниже описано использование каждого атрибута пути BGP.

5.1.1 ORIGIN

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

5.1.2 AS_PATH

AS_PATH относится к хорошо известным обязательным атрибутам и служит для идентификации автономных систем, через которые передается информация в данном сообщении UPDATE. Компонентами списка являются поля AS_SET или AS_SEQUENCE.

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

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

  2. Когда данный узел BGP анонсирует маршрут узлу BGP, расположенному в соседней автономной системе, анонсирующему узлу следует изменить связанный с этим маршрутом атрибут AS_PATH как показано ниже:
  1. если первый сегмент AS_PATH имеет тип AS_SEQUENCE, локальной системе следует поместить свой номер AS как последний элемент списка (в крайнюю левую позицию).
  2. если первый сегмент AS_PATH имеет тип AS_SET, локальной системе следует поместить новый сегмент типа AS_SEQUENCE в путь AS_PATH, включив свой номер AS в этот сегмент.

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

  1. исходному узлу следует включить свой номер AS в атрибут AS_PATH всех сообщений UPDATE, передаваемых узлам BGP в соседних автономных системах (в этом случае номер AS исходного отправителя будет единственным элементом атрибута AS_PATH).
  2. исходному узлу следует включить пустой атрибут AS_PATH во все сообщения UPDATE, передаваемые узлам BGP в своей автономной системе (пустой атрибут AS_PATH содержит нулевое значение в поле размера).

5.1.3 NEXT_HOP

Атрибут пути NEXT_HOP определяет IP-адрес граничного маршрутизатора, который следует использовать в качестве следующего пункта (next hop) на пути к адресату, указанному в сообщении UPDATE. Если граничный маршрутизатор находится в той же AS – это внутренний граничный маршрутизатор, в остальных случаях — внешний. Узел BGP может анонсировать любой внутренний граничный маршрутизатор как next hop, если интерфейс, связанный с IP-адресом этого граничного маршрутизатора (указывается в атрибуте NEXT_HOP), входит в подсеть, разделяемую локальным и удаленным узлами BGP. Узел BGP может анонсировать любой внешний граничный маршрутизатор как next hop, если IP-адрес этого маршрутизатора, полученный от партнера BGP, и интерфейс, связанный с IP-адресом данного граничного маршрутизатора (указан в атрибуте NEXT_HOP), разделяют общую подсеть с локальным и удаленным узлами BGP. Узел BGP должен обеспечивать возможность запрета анонсирования внешних граничных маршрутизаторов.

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

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

5.1.4 MULTI_EXIT_DISC

Атрибут MULTI_EXIT_DISC может использоваться на внешних (между AS) соединениях для избавления от многочисленных точек выхода или входа в одну соседнюю AS. Значение атрибута MULTI_EXIT_DISC является четырехоктетным беззнаковым целым числом, которое называют метрикой. При прочих равных из множества точек входа/выхода следует выбирать ту, которая имеет наименьшее значение метрики. Если сообщение получено через внешний канал, атрибут MULTI_EXIT_DISC может распространяться через внутренние соединения другим узлам BGP в той же AS. Атрибут MULTI_EXIT_DISC недопустимо распространять узлам BGP в соседних AS.

5.1.5 LOCAL_PREF

Атрибут LOCAL_PREF относится к числу хорошо известных необязательных. Это атрибут следует включать во все сообщения UPDATE, которые данный узел BGP передает другим узлам BGP, расположенным в той же автономной системе. Узлу BGP следует рассчитать уровень предпочтения для каждого внешнего маршрута и указывать этот уровень при анонсировании маршрута внутренним партнерам. Предпочтение должно отдаваться маршрутам с более высоким уровнем. Узлу BGP следует использовать уровень предпочтения, определенный с помощью LOCAL_PREF, в процессе принятия решений о маршрутизации (см. параграф 9.1.1 Фаза 1 — расчет уровня предпочтения).

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

5.1.6 ATOMIC_AGGREGATE

Хорошо известный атрибут ATOMIC_AGGREGATE относится к числу необязательных. Если узел BGP при наличии набора перекрывающихся маршрутов от одного из его партнеров (см. параграф. 9.1.4 Перекрывающиеся маршруты) выбирает менее специфический маршрут (без выбора более специфического), тогда локальной системе следует присоединить атрибут ATOMIC_AGGREGATE к маршруту, распространяемому этой системой другим узлам BGP (если этот атрибут уже не был установлен в принятом менее специфичном маршруте). Узлу BGP, получившему маршрут с атрибутом ATOMIC_AGGREGATE, не следует удалять этот атрибут при распространении маршрута другим узлам. Узлу BGP, получившему маршрут с атрибутом ATOMIC_AGGREGATE, не следует делать каких-либо NLRI этого маршрута более специфическими (см. определение в параграфе 9.1.4 Перекрывающиеся маршруты) при анонсировании этого маршрута другим узлам BGP. Узел BGP, получивший маршрут с атрибутом ATOMIC_AGGREGATE, должен знать реальный путь к адресату, как указано в поле NLRI маршрута, хотя при отсутствии петель возможна передача через AS, которые не указаны в атрибуте AS_PATH.

5.1.7 AGGREGATOR

Атрибут AGGREGATOR является дополнительным переходным и может включаться в обновления, которые формируются при агрегировании (см. параграф 9.2.4.2 Агрегирование маршрутной информации). Узел BGP, объединяющий маршруты, может добавлять атрибут AGGREGATOR, содержащий номер AS и IP-адрес этого узла.

6. Обработка ошибок BGP.

В этой главе описаны операции обработки ошибок, которые обнаруживаются при обслуживании сообщений BGP.

При обнаружении любого из описанных здесь условий передается сообщение NOTIFICATION с соответствующими значениями полей Error Code, Error Subcode, Data и соединение BGP разрывается. Если субкод ошибки не задан, следует устанавливать Error Subcode = 0.

Фраза «соединение BGP разрывается» означает, что закрывается соединение транспортного уровня и освобождаются все ресурсы, выделенные для соединения BGP. Записи таблицы маршрутизации, связанные с удаленным партнером, помечаются как некорректные, а информация об этом передается другим партнерам BGP до того, как маршруты будут удалены из системы.

Если явно не указано иное, поле Data (данные) сообщений NOTIFICATION, передаваемых для индикации ошибки, остается пустым.

6.1 Обработка ошибок в заголовке.

При обнаружении какой-либо ошибки в процессе обработки заголовка передается сообщение NOTIFICATION с Error Code = Message Header Error. Поле Error Subcode показывает конкретную причину ошибки.

Предполагается, что поле Marker в заголовке сообщений типа OPEN содержит только единицы. Ожидаемое значение поля Marker для остальных типов сообщений BGP определяется на основе присутствия дополнительного параметра Authentication Information в сообщении BGP OPEN и используемого механизма аутентификации (если поле Authentication Information присутствует в сообщении BGP OPEN). Если значение поля Marker в заголовке сообщения не совпадает с ожидаемым, происходит ошибка синхронизации и устанавливается значение Error Subcode = Connection Not Synchronized.

Если значение поля Length в заголовке сообщения меньше 19 или больше 4096, поле Length в заголовке сообщения OPEN, NOTIFICATION или UPDATE меньше минимального размера сообщения OPEN/NOTIFICATION/UPDATE или поле Length в заголовке сообщения KEEPALIVE не равно 19, устанавливается значение Error Subcode = Bad Message Length. Поле данных содержит ошибочное значение поля Length.

Если поле Type в заголовке сообщения не удается распознать, устанавливается Error Subcode = Bad Message Type и поле данных содержит ошибочное значение поля Type.

6.2 Обработка ошибок в сообщениях OPEN.

При обнаружении какой-либо ошибки в процессе обработки сообщений OPEN генерируется сообщение NOTIFICATION с Error Code = OPEN Message Error. Поле Error Subcode показывает конкретную причину ошибки.

Если версия, указанная в поле Version полученного сообщения OPEN не поддерживается, устанавливается значение Error Subcode = Unsupported Version Number. Поле данных содержит 2-октетное беззнаковое целое, которое показывает максимальный номер локально поддерживаемой версии BGP (который меньше номера версии, указанного в принятом сообщении OPEN).

Если поле Autonomous System в сообщении OPEN содержит неприемлемое значение, устанавливается Error Subcode = Bad Peer AS. Определение приемлемости номеров AS выходит за пределы рассмотрения этого документа.

Если неприемлемо значение поля Hold Time в сообщении OPEN, в поле Error Subcode должно быть установлено значение Unacceptable Hold Time. Реализации протокола должны отвергать значения Hold Time 1 или 2 секунды. Протокол может отвергать любые значения Hold Time. Реализация протокола, принимающая значение Hold Time, должна использовать согласованное значение Hold Time.

Если поле BGP Identifier в сообщении OPEN синтаксически некорректно, устанавливается значение Error Subcode = Bad BGP Identifier. Синтаксическая корректность означает, что поле BGP Identifier содержит корректный IP-адрес хоста.

Если один из дополнительных параметров (Optional Parameter) в сообщении OPEN не удалось распознать, устанавливается значение Error Subcode = Unsupported Optional Parameters.

Если сообщение OPEN содержит данные для аутентификации (как Optional Parameter), включается соответствующая процедура аутентификации. Если процедура аутентификации (на основе Authentication Code и Authentication Data) дает отказ, устанавливается значение Error Subcode = Authentication Failure.

6.3 Обработка ошибок в сообщениях UPDATE.

При обнаружении какой-либо ошибки в процессе обработки сообщений UPDATE генерируется сообщение NOTIFICATION с Error Code = UPDATE Message Error. Поле Error Subcode показывает конкретную причину ошибки.

Контроль ошибок в сообщении UPDATE начинается с проверки атрибутов пути. Если значение Unfeasible Routes Length или Total Attribute Length слишком велико (т. е., Unfeasible Routes Length + Total Attribute Length + 23 превышает размер сообщения — Length), устанавливается значение Error Subcode = Malformed Attribute List.

Если любой из распознанных атрибутов имеет значение Attribute Flags, конфликтующее с Attribute Type Code, устанавливается значение Error Subcode = Attribute Flags Error. Поле данных содержит ошибочный атрибут (тип, размер и значение).

Если любой из распознанных атрибутов имеет значение Attribute Length, не соответствующее ожидаемой длине (на основе кода типа атрибута), устанавливается значение Error Subcode = Attribute Length Error. Поле данных содержит ошибочный атрибут (тип, размер и значение).

Если отсутствует какой-либо из обязательных хорошо известных атрибутов, устанавливается значение Error Subcode = Missing Well-known Attribute. Поле данных содержит значение Attribute Type Code для отсутствующего атрибута.

Если не распознан какой-либо из обязательных хорошо известных атрибутов, устанавливается значение Error Subcode = Unrecognized Well-known Attribute. Поле данных содержит нераспознанный атрибут (тип, размер и значение).

Если атрибут ORIGIN имеет неопределенное значение, устанавливается Error Subcode = Invalid Origin Attribute. Поле данных содержит нераспознанный атрибут (тип, размер и значение).

Если атрибут NEXT_HOP синтаксически некорректен, устанавливается Error Subcode = Invalid NEXT_HOP Attribute. Поле данных содержит некорректный атрибут (тип, размер и значение). Синтаксическая корректность означает, что атрибут NEXT_HOP представляет корректный IP-адрес хоста. Семантическая корректность применима только к внешним соединениям BGP. Это означает, что интерфейс, связанный с IP-адресом, который указан атрибутом NEXT_HOP, относится к той же подсети, в которой находится принимающий узел BGP, но его адрес не совпадает с IP-адресом принимающего узла BGP. Если атрибут NEXT_HOP семантически некорректен, ошибка должна протоколироваться и маршрут следует игнорировать (в этом случае сообщение NOTIFICATION не передается).

Проверяется семантическая корректность атрибута AS_PATH. Если путь семантически некорректен, устанавливается значение Error Subcode = Malformed AS_PATH.

Если дополнительный атрибут распознан, проверяется значение этого атрибута. При обнаружении ошибки атрибут отбрасывается и устанавливается значение Error Subcode = Optional Attribute Error. Поле данных содержит ошибочный атрибут (тип, размер и значение).

Если какой-либо из атрибутов появляется в сообщении UPDATE более одного раза, устанавливается значение Error Subcode = Malformed Attribute List.

Проверяется семантическая корректность поля NLRI в сообщении UPDATE. При обнаружении ошибки устанавливается значение Error Subcode = Invalid Network Field.

6.4 Обработка ошибок в сообщениях NOTIFICATION.

Если узел передает сообщение NOTIFICATION и при этом возникает ошибка, не существует способа уведомить об этой ошибке путем передачи последующего сообщения NOTIFICATION. Все ошибки такого типа (нераспознанное значение Error Code или Error Subcode) должны протоколироваться и передаваться администратору узла, отправившего ошибочное сообщение. Способы такого протоколирования и уведомления не рассматриваются в данном документе.

6.5 Обработка ошибок Hold Timer Expired.

Если система не получает сообщений KEEPALIVE и/или UPDATE и/или NOTIFICATION в течение периода, заданного полем Hold Time в сообщении OPEN, передается сообщение NOTIFICATION с кодом ошибки Hold Timer Expired и соединение BGP закрывается.

6.6 Обработка ошибок машины конечных состояний.

Любая ошибка, обнаруженная машиной конечных состояний (Finite State Machine — FSM) BGP (например, неожиданное событие), приводит к генерации сообщения NOTIFICATION с Error Code = Finite State Machine Error.

6.7 Разрыв соединения.

При отсутствии каких-либо фатальных ошибок из числа описанных выше узел BGP может в любой момент закрыть соединение BGP, передав партнеру сообщение NOTIFICATION с Error Code = Cease. Однако такие сообщения не должны использоваться при возникновении какой-либо из перечисленных выше фатальных ошибок.

6.8 Обнаружение конфликтов при соединении.

Если пара узлов BGP пытается одновременно организовать соединение TCP друг с другом, между узлами такой пары могут возникнуть два параллельных соединения. Будем называть такую ситуацию конфликтом при соединении. Очевидно, что при возникновении такого конфликта одно из соединений должно быть закрыто.

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

При получении сообщения OPEN локальная система должна проверить все свои соединения, находящиеся в состоянии OpenConfirm. Узел BGP может также проверить соединения, которые находятся в состоянии OpenSent, если он имеет информацию о значении BGP Identifier узла на противоположной стороне соединения (эта информация получается с помощью других протоколов). Если какое-либо из этих соединений относится к удаленному узлу BGP, идентификатор которого совпадает со значением BGP Identifier в сообщении OPEN, локальные система выполняет следующие процедуры разрешения конфликта:

  1. Значение BGP Identifier локальной системы сравнивается с идентификатором удаленного узла BGP, указанным в сообщении OPEN.

  2. Если локальное значение BGP Identifier меньше удаленного, локальная система закрывает существующее соединение BGP (оно находится в состоянии OpenConfirm) и принимает соединение, инициированное удаленным узлом BGP.
  3. Если идентификатор BGP локальной системы больше удаленного идентификатора, закрывается новое соединение (связанное с принятым сообщением OPEN) и продолжается использование существующего (в состоянии OpenConfirm).

При сравнении идентификаторов BGP их значения трактуются как беззнаковые целые числа (4 октета).

Если одно из участвующих в конфликте соединений BGP находится в состоянии Established, такой конфликт разрешается безусловным закрытием нового соединения. Отметим, что конфликты с соединениями, находящимися в состоянии Idle, Connect или Active обнаружить невозможно.

Закрытие соединения BGP в результате процедуры разрешения конфликта сопровождается передачей сообщений NOTIFICATION с Error Code = Cease.

7. Согласование версий BGP.

Узлы BGP могут согласовать версию протокола путем повторных попыток организации соединения BGP, используя в первой попытке высший номер, поддерживаемый локальной стороной. Если при попытке организации соединения возникает ошибка с Error Code = OPEN Message Error и Error Subcode = Unsupported Version Number, узел BGP имеет информацию о номере версии, который был использован при неудачной попытке, номере версии, которую пытался использовать партнер, номере версии, переданном партнером в сообщении NOTIFICATION, и номере версии, которую он поддерживает. Если номера одной или более версий из числа поддерживаемых обоими партнерами совпадают, имеющаяся информация позволяет быстро определить максимальный поддерживаемый номер версии. Для поддержки согласования версии BGP в будущих версиях протокола должен сохраняться формат сообщений OPEN и NOTIFICATION.

8. Машина конечных состояний BGP.

В этой главе рассматривается работа BGP в терминах машины конечных состояний (Finite State Machine или FSM). Ниже приведено краткое описание и обзор состояний BGP, определенных FSM. Краткое описание BGP FSM дано в Приложении 1.

Изначально BGP находится в состоянии Idle.

Состояние Idle

В этом состоянии BGP отвергает все входящие соединения BGP. Для партнера не выделяется никаких ресурсов. В ответ на событие Start (инициируется системой или оператором) локальная система инициализирует все ресурсы BGP, запускает таймер ConnectRetry, инициирует транспортное соединение с другим узлом BGP, начинает прослушивание входящих соединений от удаленных узлов BGP и переходит в состояние Connect. Значение таймера ConnectRetry определяется локальными условиями, но должно быть достаточно велико для того, чтобы обеспечить инициализацию TCP.

Если узел BGP обнаруживает ошибку, он закрывает соединение и переходит в состояние Idle. Выход из состояния Idle требует генерации нового события Start. Если эти события генерируются автоматически, возникновение ошибки BGP может привести к автогенерации попыток выхода из состояния Idle (flapping) на узле. Во избежание таких ситуаций рекомендуется генерировать события Start с некоторой задержкой после перехода узла в состояние Idle в результате ошибки. Для узла, перешедшего в состояние Idle в результате ошибки, интервал между генерацией последовательных событий Start (если они генерируются автоматически) должен возрастать экспоненциально. Начальная задержка должна составлять 60 секунд и после каждой попытки пауза должна удваиваться.

Все остальные события в состоянии Idle игнорируются.

Состояние Connect

В этом состоянии BGP ожидает завершения процесса организации транспортного соединения.

При успешном соединении на транспортном уровне локальная система сбрасывает таймер ConnectRetry, завершает инициализацию, передает партнеру сообщение OPEN и переходит в состояние OpenSent.

При отказе в соединении (например, тайм-аут повторной передачи), локальная система заново запускает таймер ConnectRetry, продолжает прослушивать попытки организации соединений от удаленных узлов BGP и переходит в состояние Active.

В случае завершения отсчета таймера ConnectRetry локальная система запускает его заново, инициирует транспортное соединение с другим узлом BGP, продолжая прослушивать вызовы от удаленных узлов BGP, и остается в состоянии Connect.

События Start игнорируются в состоянии Connect3.

В ответ на все прочие события (инициируемые системой или оператором) локальная система освобождает все ресурсы BGP, связанные с этим соединением и переходит в состояние Idle.

Состояние Active

В этом состоянии BGP пытается приобрести партнера, инициируя транспортное соединение.

При успешном соединении локальная система сбрасывает таймер ConnectRetry, завершает инициализацию, передает партнеру сообщение OPEN, устанавливает для Hold Timer достаточно большое значение и переходит в состояние OpenSent. Рекомендуется устанавливать для таймера удержания значение Hold Timer = 4 минуты.

При завершении отсчета таймера ConnectRetry локальная система запускает этот таймер снова, инициирует транспортное соединение с другим узлом BGP, продолжая прослушивать входящие соединения от удаленных узлов BGP, и переходит в состояние Connect.

Если локальная система обнаруживает попытки удаленного узла BGP связаться с ней и IP-адрес удаленного узла не совпадает с ожидаемым, локальная система заново запускает таймер ConnectRetry, отвергает попытку соединения, продолжая прослушивать попытки соединений от удаленных узлов BGP и сохраняя состояние Active.

События Start игнорируются в состоянии Active.

В ответ на все прочие события (инициируемые системой или оператором) локальная система освобождает все ресурсы BGP, связанные с этим соединением и переходит в состояние Idle.

Состояние OpenSent

В этом состоянии BGP ждет сообщения OPEN от своего партнера. При получении сообщения OPEN проверяется корректность всех полей этого сообщения. Если при проверке заголовка или содержимого сообщения OPEN обнаруживаются ошибки (см. параграф 6.2 Обработка ошибок в сообщениях OPEN.) или возникает конфликт при организации соединения (см. параграф 6.8 Обнаружение конфликтов при соединении.), локальная система передает сообщение NOTIFICATION и переходит в состояние Idle.

Если в сообщении OPEN не обнаружено ошибок, узел BGP передает сообщение KEEPALIVE и устанавливает таймер KeepAlive. Для таймера Hold Timer, значение которого изначально устанавливается достаточно большим (см. выше), выбирается согласованное значение (см. параграф 4.2 Формат сообщений OPEN). Если согласовано нулевое значение Hold Time, таймеры Hold Time и KeepAlive не используются. Если значение поля Autonomous System совпадает с номером локальной AS, соединение является внутренним, в остальных случаях соединение является внешним (это будет влиять на обработку сообщений UPDATE, описанную ниже). После этого состояние меняется на OpenConfirm.

Если приходит уведомление о разрыве соединения от нижележащего протокола транспортного уровня, локальная система закрывает соединение BGP, заново запускает таймер ConnectRetry, продолжая слушать попытки соединений от удаленных узлов BGP, и переходит в состояние Active.

По истечении времени Hold Timer локальная система передает сообщение NOTIFICATION с кодом ошибки Hold Timer Expired и переходит в состояние Idle.

В ответ на событие Stop (инициируется системой или оператором) локальная система передает сообщение NOTIFICATION с Error Code = Cease и переходит в состояние Idle.

События Start игнорируются в состоянии OpenSent.

В ответ на все остальные события локальная система передает сообщение NOTIFICATION с Error Code = Finite State Machine Error и переходит в состояние Idle.

Всякий раз, когда BGP переходит из состояния OpenSent в состояние Idle, закрывается соединение BGP (и транспортное соединение) и освобождаются все ресурсы, связанные с этим соединением.

Состояние OpenConfirm

В этом состоянии BGP ожидает сообщений KEEPALIVE или NOTIFICATION.

Получив сообщение KEEPALIVE, система переходит в состояние Established.

По истечении времени Hold Timer до прихода сообщения KEEPALIVE, локальная система передает сообщение NOTIFICATION с кодом ошибки Hold Timer Expired и переходит в состояние Idle.

Получив сообщение NOTIFICATION, система переходит в состояние Idle.

По истечении времени KeepAlive локальная система передает сообщение KEEPALIVE и заново запускает таймер KeepAlive.

При получении от транспортного протокола уведомления о разрыве соединения локальная система переходит в состояние Idle.

В ответ на событие Stop (инициируется системой или оператором) локальная система передает сообщение NOTIFICATION с Error Code = Cease и переходит в состояние Idle.

События Start игнорируются в состоянии OpenConfirm.

В ответ на все остальные события локальная система передает сообщение NOTIFICATION с Error Code = Finite State Machine Error и переходит в состояние Idle.

Всякий раз, когда BGP переходит из состояния OpenConfirm в состояние Idle, закрывается соединение BGP (и транспортное соединение) и освобождаются все ресурсы, связанные с этим соединением.

Состояние Established

В состоянии Established узел BGP может обмениваться со своим партнером сообщениями UPDATE, NOTIFICATION и KEEPALIVE.

Если локальная система получает сообщение UPDATE или KEEPALIVE, она заново запускает таймер Hold Timer (если согласованное значение Hold Time не равно нулю).

Получив сообщение NOTIFICATION, система переходит в состояние Idle.

Если локальная система получает сообщение UPDATE и процедура обработки ошибок в сообщениях UPDATE (см. параграф 6.3 Обработка ошибок в сообщениях UPDATE.) обнаруживает ошибку, локальная система передает сообщение NOTIFICATION и переходит в состояние Idle.

При получении от нижележащего транспортного протокола уведомления о разрыве соединения локальная система переходит в состояние Idle.

По истечении времени Hold Timer до прихода сообщения KEEPALIVE, локальная система передает сообщение NOTIFICATION с кодом ошибки Hold Timer Expired и переходит в состояние Idle.

По истечении времени KeepAlive локальная система передает сообщение KEEPALIVE и заново запускает таймер KeepAlive.

Передав сообщение KEEPALIVE или UPDATE, локальная система заново запускает таймер KeepAlive, если согласованное значение Hold Time не равно нулю.

В ответ на событие Stop (инициируется системой или оператором) локальная система передает сообщение NOTIFICATION с Error Code = Cease и переходит в состояние Idle.

События Start игнорируются в состоянии Established.

В ответ на все остальные события локальная система передает сообщение NOTIFICATION с Error Code = Finite State Machine Error и переходит в состояние Idle.

Всякий раз, когда BGP переходит из состояния Established в состояние Idle, закрывается соединение BGP (и транспортное соединение) и освобождаются все ресурсы, связанные с этим соединением.

9. Обработка сообщений UPDATE

Сообщение UPDATE может быть получено только в состоянии Established. При получении сообщения UPDATE проверяется корректность каждого поля в соответствии с параграфом 6.3 Обработка ошибок в сообщениях UPDATE..

Если не удается распознать дополнительные непереходные атрибуты, они просто игнорируются. Если не удается распознать дополнительные переходные атрибуты, устанавливается значение Partial=1 в поле флагов атрибута (третий по старшинству бит) и атрибут сохраняется для передачи другим узлам BGP.

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

Если сообщение UPDATE содержит непустое поле WITHDRAWN ROUTES (отзываемые маршруты), ранее анонсированные маршруты, чьи адресаты указаны префиксами в данном поле, удаляются из таблицы Adj-RIB-In. Узлу BGP следует запустить Decision Process, поскольку анонсированные ранее маршруты больше не являются доступными.

Если сообщение UPDATE содержит доступный маршрут, это маршрут следует поместить в таблицу Adj-RIB-In и выполнить по отношению к нему перечисленные ниже операции:

  1. Если поле NLRI идентично одному из маршрутов, хранящихся в Adj-RIB-In, новый маршрут должен использоваться взамен имеющегося в таблице Adj-RIB-In (т.е., старый маршрут отзывается). Узел BGP должен запустить Decision Process, поскольку старый маршруты больше не может использоваться.

  2. Если новый маршрут перекрывается с маршрутом, включенным ранее (см. 9.1.4 Перекрывающиеся маршруты) в таблицу Adj-RIB-In, узел BGP должен запустить Decision Process, поскольку более специфичный маршрут, явно указанный, как часть менее специфичного, недоступен для использования.
  3. Если атрибуты пути нового маршрута идентичны атрибутам пути маршрута, содержащегося в Adj-RIB-In, и новый маршрут более специфичен (см. 9.1.4 Перекрывающиеся маршруты), чем старый маршрут, выполнять какие-либо специальные действия не требуется.
  4. Если значение NLRI нового маршрута не присутствует ни в одном из имеющихся в таблице Adj-RIB-In маршрутов, этот маршрут просто добавляется в таблицу Adj-RIB-In и узел BGP должен запустить Decision Process.

  5. Если новый маршрут перекрывается с более специфичным маршрутом (см. 9.1.4 Перекрывающиеся маршруты), указанным в таблице Adj-RIB-In, узел BGP должен запустить Decision Process для множества адресатов, связанных с менее специфичным маршрутом.

9.1 Процесс принятия решений

Процесс принятия решений (Decision Process) обеспечивает выбор маршрутов для последующего анонсирования путем применения правил, заданных в локальной базе PIB (Policy Information Base), к маршрутам из таблицы Adj-RIB-In. Результатом процесса является набор маршрутов, которые будут анонсироваться всем партнерам – эти маршруты хранятся в таблице Adj-RIB-Out.

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

Процесс выбора применяется ко всем маршрутам из таблицы Adj-RIB-In и отвечает за:

  • Выбор маршрутов, анонсируемых узлам BGP в локальной AS;
  • Выбор маршрутов, анонсируемых узлам BGP в соседних AS;
  • Агрегирование маршрутов и снижение объема маршрутных данных.

Decision Process делится на три фазы, каждая из которых включается определенными событиями:

Фаза 1 отвечает за расчет уровня предпочтения для каждого маршрута, полученного от узла BGP, расположенного в соседней AS, и анонсирование узлам BGP в локальной AS маршрутов с максимальным уровнем предпочтения для каждого из адресатов.
Фаза 2 начинается по завершении фазы 1 и отвечает за выбор лучшего маршрута из числа доступных для каждого адресата, а также включение выбранных маршрутов в подходящие Loc-RIB.
Фаза 3 начинается после обновления Loc-RIB и отвечает за распространение маршрутов из Loc-RIB всем партнерам, расположенным в соседних AS, в соответствии с политикой, содержащейся в PIB. На этой фазе также может выполняться объединение маршрутов и снижение объема маршрутной информации.

9.1.1 Фаза 1 — расчет уровня предпочтения

Фазу 1 следует активизировать всякий раз, когда локальный узел BGP получает сообщение UPDATE от партнера, расположенного в соседней AS, которое анонсирует новый маршрут или замену/отзыв существующего маршрута.

Фаза 1 представляет собой автономный процесс, который завершается после выполнения всех требуемых операций.

Функция, используемая в фазе 1, должна заблокировать таблицу Adj-RIB-In прежде, чем начать работу с содержащимися в ней маршрутами и снять блокировку по завершении расчетов.

При получении нового маршрута или замене доступного локальный узел BGP должен определять уровень предпочтения для полученного маршрута. Если маршрут получен от узла BGP в локальной AS, в качестве уровня предпочтения следует брать значение атрибута LOCAL_PREF или рассчитывать этот уровень на основе конфигурационных параметров политики. Если маршрут получен от узла BGP в соседней AS, уровень предпочтения следует рассчитывать на основе конфигурационных параметров политики. Метод определения уровня предпочтения задается локальными условиями. Локальному узлу следует запустить внутренний процесс обновления (см. 9.2.1 Внутренние обновления) для выбора и анонсирования маршрута с высшим уровнем предпочтения.

9.1.2 Фаза 2 — выбор маршрута

Фаза 2 выполняется после завершения фазы 1 и представляет собой независимый процесс, который завершается после выполнения всех необходимых операций. В фазе 2 используются все маршруты из таблицы Adj-RIBs-In, включая маршруты, полученные от узлов BGP в локальной AS и соседних автономных системах.

Фаза 2 не должна начинаться, пока не будет завершено принятие решения для фазы 3. Фаза 2 должна блокировать таблицу Adj-RIBs-In перед началом работы и снимать блокировку по завершении работы.

Если атрибут NEXT_HOP маршрута BGP указывает адрес, к которому локальный узел BGP не имеет маршрута в таблице Loc-RIB, этот маршрут BGP следует исключать из обработки в фазе 2.

Для каждого набора адресатов, к которому существует доступный маршрут в таблице Adj-RIBs-In, локальный узел BGP должен убедиться, что выполняется хотя бы одно из перечисленных ниже условий:

  1. маршрут имеет высший уровень предпочтения из всего набора путей к этому адресату;

  2. маршрут является единственным для данного адресата;
  3. маршрут выбран в результате применения в фазе 2 правил «разрыва связей» (tie breaking) описанных ниже (9.1.2.1 Разрыв связей (фаза 2).

После этого локальному узлу следует поместить маршрут в таблицу Loc-RIB, заменяя все маршруты к тому же адресату, которые будут обнаружены в Loc-RIB. Локальный узел должен определить следующий маршрутизатор (immediate next hop) для адреса, указанного атрибутом NEXT_HOP выбранного маршрута, запрашивая IGP и выбирая один из возможных путей в IGP. Адрес этого маршрутизатора должен использоваться при включении выбранного маршрута в таблицу Loc-RIB. Если маршрут к адресу, указанному атрибутом NEXT_HOP, меняется так, что изменяется адрес next hop, требуется повторить описанную выше процедуру выбора маршрута.

Недоступные маршруты должны удаляться из таблицы Loc-RIB и Adj-RIBs-In.

9.1.2.1 Разрыв связей (фаза 2)

В таблице Adj-RIBs-In узла BGP может храниться несколько маршрутов к одному адресату, имеющих одинаковый уровень предпочтения. Локальный узел может выбрать только один из таких маршрутов для включения в таблицу Loc-RIB. В рассмотрение принимаются все маршруты с одинаковым уровнем предпочтения – как полученные от узлов BGP в соседних AS, так и принятые от узлов той же автономной системы.

В описанной ниже процедуре разрыва связей предполагается, что для каждого маршрута-кандидата все узлы BGP в автономной системе могут определить стоимость пути (внутренняя дистанция) до адреса, указанного атрибутом NEXT_HOP в данном маршруте. Разрыв связей выполняется по следующему алгоритму:

  1. Если локальная система принимает во внимание атрибут MULTI_EXIT_DISC и маршруты-кандидаты отличаются значениями этого атрибута, следует выбирать маршрут с минимальным значением MULTI_EXIT_DISC.

  2. В противном случае выбирается маршрут с минимальной стоимостью (внутренней дистанцией) до элемента, указанного атрибутом NEXT_HOP. Если стоимость нескольких маршрутов совпадает, процедура продолжается следующим образом:

  • если хотя бы один из таких маршрутов анонсирован узлом BGP в соседней AS, среди таких маршрутов выбирается путь, анонсированный узлом с наименьшим значением BGP Identifier из числа находящихся в соседней AS;

  • в противном случае выбирается маршрут, анонсированный узлом с минимальным значением BGP Identifier.

9.1.3 Фаза 3 – распространение информации о маршруте

Фаза 3 выполняется после завершения фазы 2 или при возникновении одного из следующих событий:

  1. изменение маршрутов к локальным адресатам в таблице Loc-RIB;

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

Фаза 3 представляет собой самостоятельный процесс, завершающийся после выполнения требуемых операций. Функция Routing Decision фазы 3 должна быть заблокирована, пока не завершится принятие решения в фазе 2.

Все маршруты из таблицы Loc-RIB должны быть обработаны и включены в соответствующие записи связанной таблицы Adj-RIBs-Out. Возможно использование методов агрегирования маршрутов и снижения объема маршрутных данных (см. 9.2.4.1 Снижение объема информации).

Для поддержки будущих вариантов использования групповой адресации между AS узлам BGP, принимающим участие в multicast-маршрутизации между AS, следует анонсировать маршруты, полученные от одного из своих внешних партнеров и, если такой маршрут включен в таблицу Loc-RIB данного узла, анонсировать его также партнеру, от которого маршрут получен. Для узлов BGP, не принимающих участия в multicast-маршрутизации между AS, такое анонсирование является необязательным. При передаче таких анонсов атрибут NEXT_HOP должен содержать адрес партнера. Реализация протокола может также оптимизировать рассылку таких анонсов, отсекая часть информации в атрибуте AS_PATH и оставляя только номер своей AS и партнера, которому анонсируется маршрут (при этом следует устанавливать для атрибута ORIGIN значение INCOMPLETE). Кроме того, не требуется передавать дополнительные и необязательные атрибуты пути в таких анонсах.

По завершении обновлений таблиц Adj-RIBs-Out и FIB (Forwarding Information Base – база рассылки информации) локальному узлу BGP следует активизировать процесс внешнего обновления 9.2.2.

9.1.4 Перекрывающиеся маршруты

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

Отношения предпочтительности позволяют разделить менее специфичный маршрут на 2 части:

  • множество адресатов, описываемое менее специфичным маршрутом, и

  • множество адресатов, описываемое перекрытием менее специфичного и более специфичного маршрутов.

Когда перекрывающиеся маршруты присутствуют в одной таблице Adj-RIB-In, более специфичные маршруты должны следовать перед менее специфичными.

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

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

  1. установить оба маршрута;

  2. установить только более специфичный маршрут;
  3. установить только неперекрывающуюся часть менее специфичного маршрута (т. е., деагрегировать его)
  4. объединить два маршрута и установить агрегированный маршрут;
  5. установить только менее специфичный маршрут;
  6. не устанавливать ни один из маршрутов.

Если узел BGP выбирает вариант e), он должен добавить в маршрут атрибут ATOMIC_AGGREGATE (маршрут с таким атрибутом не может быть деагрегирован, т. е., значение NLRI такого маршрута не может быть более специфичным). Пересылка по такому маршруту не гарантирует, что пакеты IP будут на самом деле проходить только через те AS, которые указаны в атрибуте AS_PATH этого маршрута. Если узел BGP выбирает вариант a), он не должен анонсировать более общий маршрут без более специфичного.

9.2 Процесс передачи обновлений

Процесс передачи обновлений (Update-Send) отвечает за анонсирование сообщений UPDATE всем партнерам. Например, он распространяет маршруты, выбранные Decision Process, другим узлам BGP, которые могут располагаться в той же или соседних AS. Правила для обмена информацией между узлами BGP, расположенными в различных AS, приводятся в параграфе 9.2.2, а правила обмена информацией внутри автономной системы – в параграфе 9.2.1.

Распространение маршрутных данных между узлами BGP в одной AS будем называть внутренним распределением.

9.2.1 Внутренние обновления

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

Когда узел BGP получает сообщение UPDATE от другого узла BGP, расположенного в той же AS, принимающий узел не должен перераспределять информацию, содержащуюся в сообщении UPDATE другим узлам BGP той же AS.

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

  1. уровень предпочтения полученного локальным узлом BGP нового маршрута выше уровня, присвоенного другому маршруту, который был получен от узла BGP в соседней AS

  2. нет других маршрутов, полученных от узлов BGP в соседних AS
  3. полученный недавно маршрут выбран в результате разрыва связи между несколькими маршрутами, которые имели высший уровень предпочтения и вели к тому же адресату (см. параграф 9.2.1.1).

Когда узел BGP получает сообщение UPDATE с непустым полем WITHDRAWN ROUTES, он должен удалить из таблицы Adj-RIB-In все маршруты к адресатам, указанным этим полем (как префикс IP). Кроме того, узел должен выполнить следующие операции:

  1. если соответствующий доступный маршрут не был ранее анонсирован, дополнительных действий не требуется;

  2. если соответствующий доступный маршрут был анонсирован, нужно выполнить следующее:

  1. если выбранный для анонсирования новый маршрут имеет такое же значение NLRI, как недоступные маршруты, локальный узел BGP должен анонсировать замену маршрута;
  2. если взятый на замену маршрут невозможно анонсировать, узел BGP должен включить адресатов недоступного маршрута (префикс IP) в поле WITHDRAWN ROUTES сообщения UPDATE и разослать это сообщение каждому партнеру, которому ранее была анонсирована доступность соответствующего маршрута.

Все возможные маршруты, которые анонсируются, должны быть помещены в таблицу Adj-RIBs-Out, а все недоступные маршруты следует удалить из Adj-RIBs-Out.

9.2.1.1 Разорванные связи (внутренние обновления)

Если локальный узел BGP имеет соединения с несколькими узлами BGP в соседних AS, это ведет к существованию множества таблиц Adj-RIBs-In, связанных с этими партнерами. Таблицы Adj-RIBs-In могут содержать несколько маршрутов к одному адресату и с одинаковым уровнем предпочтения, которые были анонсированы узлами BGP из соседних AS. Локальный узел BGP должен выбирать один из таких маршрутов, пользуясь приведенными правилами:

  1. Если маршруты-кандидаты отличаются только атрибутами NEXT_HOP и MULTI_EXIT_DISC, а локальная система принимает во внимание атрибут MULTI_EXIT_DISC, следует выбирать маршрут с минимальным значением атрибута MULTI_EXIT_DISC.

  2. Если локальная система может установить стоимость пути к объекту, указанному атрибутом NEXT_HOP маршрута-кандидата, следует выбирать маршрут с минимальной стоимостью.
  3. Во всех остальных случаях следует выбирать маршрут, анонсированный узлом BGP с наименьшим значением BGP Identifier.

9.2.2 Внешние обновления

Процесс внешнего обновления включает рассылку маршрутной информации узлам BGP, расположенным в соседних AS. В фазе 3 процесса выбора маршрутов узел BGP обновляет Adj-RIBs-Out и свою таблицу рассылки (Forwarding Table). Все новые маршруты и маршруты, недавно ставшие недоступными, для которых нет замены, должны анонсироваться узлам BGP, расположенным в соседних AS, с помощью сообщений UPDATE.

Все маршруты из таблицы Loc-RIB, помеченные как недоступные, должны быть удалены. Изменения в доступных адресатах своей AS также должны анонсироваться с помощью сообщений UPDATE.

9.2.3 Управление объемом служебного трафика

Протокол BGP вынужден ограничивать объем служебного трафика (сообщения UPDATE) в целях снижения расхода полосы каналов, требуемой для анонсирования, и ресурсов системы, требуемых на этапе принятия решения (Decision Process) для обработки информации, содержащейся в сообщениях UPDATE.

9.2.3.1 Частота анонсирования маршрутов

Параметр MinRouteAdvertisementInterval определяет минимальное время, которое должно пройти между анонсированием маршрутов для конкретного адресата от одного узла BGP. Процедура ограничения скорости рассылки применяется независимо для каждого адресата, хотя значение MinRouteAdvertisementInterval устанавливается для узла BGP в целом.

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

Поскольку внутри AS требуется быстрое схождение маршрутов, эта процедура не применяется для маршрутов, полученных от внутренних узлов BGP. Чтобы избавиться от длительных «черных дыр», процедура не применяется при явном отзыве недоступных маршрутов (для которых адресат, указанный префиксом IP, включен в поле WITHDRAWN ROUTES сообщения UPDATE).

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

9.2.3.2 Частота обновления из исходной AS

Параметр MinASOriginationInterval определяет минимальный интервал времени между последовательными сообщениями UPDATE, которые содержат информацию об изменениях внутри AS анонсирующего узла BGP.

9.2.3.3 Флуктуации

Для снижения вероятности пиковой нагрузки при распределении сообщений BGP данным узлом BGP таймеры, связанные с MinASOriginationInterval, Keepalive и MinRouteAdvertisementInterval должны задаваться с использованием флуктуаций (jitter). Каждый узел BGP должен использовать одинаковое отклонение для всех перечисленных таймеров, независимо от адресатов, для которых будут передаваться сообщения (т. е., флуктуации задаются на уровне узла).

Величина флуктуации должна определяться умножением базовой величины на случайное значение от 0,75 до 1,0 (с равномерным распределением).

9.2.4 Эффективная организация маршрутных данных

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

9.2.4.1 Снижение объема информации

Снижение объема информации означает снижение уровня гранулярности контроля над политикой маршрутизации – после сжатия информации одни и те же правила будут применяться ко всем адресатам и путям одного класса.

Перечисленные способы позволяют снизить объем данных, помещаемых в Adj-RIBs-Out на этапе Decision Process:

  1. NLRI. IP-адреса получателей могут быть представлены префиксами IP. В тех случаях, когда имеется соответствие между структурой адреса и системами, находящимися под управлением администратора AS, можно уменьшить размер NLRI, передаваемых в сообщениях UPDATE.

  2. AS_PATH. Информация о пути AS может быть представлена как в упорядоченной (AS_SEQUENCE), так и в неупорядоченной (AS_SET) форме. AS_SET используется в алгоритме агрегирования маршрутов, описанном в параграфе 9.2.4.2. Это позволяет снизить объем данных AS_PATH за счет однократного указания номера каждой AS (независимо от числа ее упоминаний во множестве объединяемых AS_PATH).

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

9.2.4.2 Агрегирование маршрутной информации

Агрегирование представляет собой процесс объединения характеристик нескольких разных маршрутов таким образом, чтобы их можно было анонсировать как единый маршрут. Агрегирование может выполняться как часть процесса принятия решения для снижения объема маршрутных данных, помещаемых в Adj-RIBs-Out.

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

Маршруты с атрибутами MULTI_EXIT_DISC и NEXT_HOP не могут агрегироваться, если значения этих атрибутов не совпадают для всех маршрутов.

Атрибуты пути с различными кодами типа не могут быть агрегированы. Однотипные атрибуты пути могут агрегироваться в соответствии с приведенными ниже правилами:

Атрибут ORIGIN. Если хотя бы один из агрегируемых маршрутов имеет ORIGIN = INCOMPLETE, для объединенного маршрута также должно устанавливаться ORIGIN = INCOMPLETE. Если хотя бы один из объединяемых маршрутов имеет значение ORIGIN = EGP, агрегированный маршрут также должен иметь значение EGP для этого атрибута. В остальных случаях для агрегированного маршрута устанавливается ORIGIN = INTERNAL.

Атрибут AS_PATH. Если у агрегируемых маршрутов совпадают значения AS_PATH, объединенный маршрут имеет такое же значение AS_PATH.

В целях объединения атрибутов AS_PATH будем моделировать каждую AS в атрибуте AS_PATH как пару <type, value>, где type определяет тип сегмента пути, к которому относится AS (например, AS_SEQUENCE, AS_SET), а value указывает номер AS. Если агрегируемые маршруты имеют разные атрибуты AS_PATH, агрегированный атрибут AS_PATH должен удовлетворять каждому из перечисленных ниже требований:

  • Все пары типа AS_SEQUENCE объединенного атрибута AS_PATH должны присутствовать в каждом атрибуте AS_PATH исходного набора агрегируемых маршрутов.

  • Все пары типа AS_SET объединенного атрибута AS_PATH должны присутствовать хотя бы в одном атрибуте AS_PATH исходного набора (как AS_SET или AS_SEQUENCE).
  • Для любой пары X типа AS_SEQUENCE в агрегированном AS_PATH, которая предшествует паре Y агрегированного AS_PATH, X предшествует Y в каждом атрибуте AS_PATH исходного набора, который содержит Y (независимо от типа Y).
  • Ни одна пара (независимо от ее типа) не должна появляться в агрегированном AS_PATH более одного раза.

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

  • Определить наиболее длинную последовательность лидирующих пар (как описано выше), присутствующую в атрибутах AS_PATH всех объединяемых маршрутов и сделать ее лидирующей в объединенном атрибуте AS_PATH.

  • Установить для оставшихся пар из атрибутов AS_PATH объединяемых маршрутов тип AS_SET и присоединить их к агрегированному атрибуту AS_PATH.
  • Если объединенный атрибут AS_PATH содержит несколько одинаковых пар (независимо от типа), лишние (все, кроме одной) пары типа AS_SET следует удалить из объединенного атрибута AS_PATH.

В Приложении 6 (параграф 6.8) рассмотрен другой алгоритм, удовлетворяющий приведенным здесь требованиям и обеспечивающим поддержку более сложных вариантов политики.

Атрибут ATOMIC_AGGREGATE. Если хотя бы один из объединяемых маршрутов имеет атрибут ATOMIC_AGGREGATE, объединенный маршрут также должен иметь этот атрибут.

Атрибут AGGREGATOR. Все атрибуты AGGREGATOR в объединяемых маршрутах следует игнорировать.

9.3 Критерии выбора маршрута

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

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

  • Для обеспечения эффективной распределенной обработки следует выбирать только маршруты, представляющиеся стабильными. Таким образом, AS должна избегать применения нестабильных маршрутов и не должна вносить скороспелых спонтанных изменений при выборе путей. Трактовка слов «нестабильный» и «скороспелый» в предыдущем предложении требует некоторого опыта, но, в принципе, достаточно понятна.

9.4 Порождение маршрутов BGP

Узел BGP может порождать (originate) маршруты BGP, помещая информацию, полученную из других источников (например, IGP), в BGP. Порождающий маршруты узел BGP должен указывать для таких маршрутов уровень предпочтения, используя для этого Decision Process (см. 9.1 Процесс принятия решений). Эти маршруты могут также рассылаться другим узлам BGP в локальной AS, как часть процесса внутреннего обновления (см. 9.2.1 Внутренние обновления). Решение о целесообразности рассылки полученной от других источников информации внутри AS с использованием BGP зависит от используемой в AS среды (например, типа IGP) и должно задаваться на уровне конфигурации.

Приложение 1. Переходы и действия BGP FSM.

В этом приложении рассматриваются переходы между состояниями BGP FSM, вызванные событиями BGP. Ниже приведен список таких состояний и событий для тех случаев, когда согласованное значение Hold Time отличается от нуля.

Состояния BGP

1 – Idle — бездействие
2 – Connect — соединение
3 – Active — активно
4 – OpenSent – передано сообщение OPEN
5 – OpenConfirm – подтверждено сообщение OPEN
6 – Established – соединение организовано

События BGP

1 — BGP Start – начало работы
2 — BGP Stop — остановка
3 — BGP Transport connection open – транспортное соединение открыто
4 — BGP Transport connection closed – транспортное соединение закрыто
5 — BGP Transport connection open failed – неудачная попытка открыть транспортное соединение
6 — BGP Transport fatal error – неисправимая ошибка на транспортном уровне
7 — ConnectRetry timer expired – завершен отсчет таймера ConnectRetry
8 — Hold Timer expired – завершен отсчет таймера Hold Timer
9 — KeepAlive timer expired – завершен отсчет таймера KeepAlive
10 — Receive OPEN message – получено сообщение OPEN
11 — Receive KEEPALIVE message – получено сообщение KEEPALIVE
12 — Receive UPDATE messages – получено сообщение UPDATE
13 — Receive NOTIFICATION message – получено сообщение NOTIFICATION

В приведенной ниже таблице перечислены состояния и переходы BGP FSM, а также указаны действия в результате таких переходов.

Событие

Действия

Сообщение

Следующий этап

Idle (1)

1

Инициализация ресурсов

Запуск таймера ConnectRetry

Инициирование транспортного соединения

Нет

2

прочие

Нет

Нет

1

Connect(2)

1

Нет

Нет

2

3

Полная инициализация

Сброс таймера ConnectRetry

OPEN

4

5

Перезапуск таймера ConnectRetry

Нет

3

7

Перезапуск таймера ConnectRetry

Нет

2

прочие

Освобождение ресурсов

Нет

1

Active (3)

1

Нет

Нет

2

2

Полная инициализация

Сброс таймера ConnectRetry

OPEN

4

5

Разрыв соединения

Перезапуск таймера ConnectRetry

3

7

Перезапуск таймера ConnectRetry

Нет

2

прочие

Освобождение ресурсов

Нет

1

OpenSent(4)

1

Нет

Нет

4

4

Разрыв транспортного соединения

Перезапуск таймера ConnectRetry

Нет

3

6

Освобождение ресурсов

Нет

1

10

Обработка сообщения OPEN завершена успешно

Неудача при обработке сообщения OPEN

KEEPALIVE

NOTIFICATION

5

1

прочие

Разрыв транспортного соединения

Освобождение ресурсов

NOTIFICATION

1

OpenConfirm (5)

1

Нет

Нет

5

4

Освобождение ресурсов

Нет

1

6

Освобождение ресурсов

Нет

1

9

Перезапуск таймера KeepAlive

KEEPALIVE

5

11

Полная инициализация

Перезапуск таймера Hold Timer

Нет

6

13

Разрыв транспортного соединения

Освобождение ресурсов

1

прочие

Разрыв транспортного соединения

Освобождение ресурсов

NOTIFICATION

1

Established (6)

1

Нет

Нет

6

4

Освобождение ресурсов

Нет

1

6

Освобождение ресурсов

Нет

1

9

Перезапуск таймера KeepAlive

KEEPALIVE

6

11

Перезапуск таймера Hold Timer

KEEPALIVE

6

12

Обработка сообщения UPDATE завершена успешно

Неудача при обработке сообщения UPDATE

UPDATE

NOTIFICATION

1

1

13

Разрыв транспортного соединения

Освобождение ресурсов

1

прочие

Разрыв транспортного соединения

Освобождение ресурсов

NOTIFICATION

1

Ниже приведен сжатый вариант таблицы состояний и переходов.

События

Idle (1)

Connect (2)

Active (3)

OpenSent (4)

OpenConfirm (5)

Estab (6)

1

2

2

3

4

5

6

2

1

1

1

1

1

1

3

1

4

4

1

1

1

4

1

1

1

3

1

1

5

1

3

3

1

1

1

6

1

1

1

1

1

1

7

1

2

2

1

1

1

8

1

1

1

1

1

1

9

1

1

1

1

5

5

10

1

1

1

1 или 5

1

1

11

1

1

1

1

6

6

12

1

1

1

1

1

1 или 6

13

1

1

1

1

1

1

Приложение 2. Сравнение с RFC 1267

BGP-4 может работать в среде, где множество доступных адресатов может указываться с помощью одного префикса IP. Концепция классов сетей или подсетей чужеродна для BGP-4. Для поддержки работы с префиксами в BGP-4 изменена семантика и кодирование, связанное с атрибутом AS_PATH. В спецификацию добавлено определение семантики, связанное с префиксами IP. Такое расширение позволяет BGP-4 поддерживать предложенную схему supernet [9].

Для упрощения настройки вводится новый атрибут LOCAL_PREF, упрощающий процедуру выбора маршрута.

Атрибут INTER_AS_METRIC переименован в MULTI_EXIT_DISC. Добавлен новый атрибут ATOMIC_AGGREGATE для управления возможностью деагрегирования маршрутов. Другой новый атрибут – AGGREGATOR – может добавляться в агрегированные маршруты, чтобы указать, какая AS и какой узел BGP в этой AS вызвали агрегирование.

Для обеспечения симметрии значение Hold Time согласуется на уровне соединений. Поддерживаются нулевые значения Hold Time.

Приложение 3. Сравнение с RFC 1163

Все изменения, перечисленные в Приложении 2, и изменения, указанные ниже.

Для обнаружения конфликтов при соединениях BGP и восстановления работы протокола добавлено новое поле BGP Identifier в сообщения OPEN. Для описания процедур детектирования и разрешения конфликтов при соединениях в документ добавлен новый параграф (6.8 Обнаружение конфликтов при соединении.).

Снято ограничение, требовавшее чтобы граничный маршрутизатор, указанный атрибутом пути NEXT_HOP, относился к той же AS, в которой находится узел BGP.

В новом документе оптимизировано и упрощено описание процедур обмена информацией о ранее доступных маршрутах.

Приложение 4. Сравнение с RFC 1105

Все изменения, перечисленные в Приложениях 2 и 3, а также перечисленные ниже отличия.

Потребовалось внесение незначительных изменений в машину конечных состояний RFC1105 для согласования с пользовательским интерфейсом TCP в системах 4.3 BSD.

Понятия и соотношения Up/Down/Horizontal, присутствующие в RFC1105, были исключены из протокола.

Внесен ряд изменений в формат сообщений RFC1105:

  • Поле Hold Time было удалено из заголовка BGP и включено в сообщение OPEN.

  • Поле номера версии было удалено из заголовка BGP и включено в сообщение OPEN.
  • Из сообщений OPEN было удалено поле Link Type.
  • Вместо подтверждений OPEN CONFIRM используются сообщения KEEPALIVE.
  • Существенно изменен формат сообщений UPDATE, добавлены новые поля для поддержки множества атрибутов пути.
  • Поле Marker было расширено и стало использоваться также для аутентификации.

Отметим, что достаточно часто протокол BGP, соответствующий RFC 1105, называют BGP-1, соответствующий RFC 1163 — BGP-2, а соответствующий RFC 1267 — BGP-3. Вариант BGP, описанный в этом документе, называют BGP-4.

Приложение 5. Опции TCP, которые могут использоваться с BGP

Если пользовательский интерфейс TCP в локальной системе поддерживает функцию TCP PUSH, каждое сообщение BGP следует передавать с установленным флагом PUSH. Установка флага приводит к ускорению передачи сообщений BGP.

Если пользовательский интерфейс TCP в локальной системе поддерживает предпочтения для соединений TCP, транспортные соединения BGP следует открывать с уровнем предпочтения Internetwork Control (110) [6].

Приложение 6. Рекомендации разработчикам

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

6.1 Множество префиксов сетей в одном сообщении

Протокол BGP позволяет указывать в одном сообщении множество адресных префиксов с одинаковым путем AS и адресом следующего маршрутизатора (next-hop). Настоятельно рекомендуется использовать эту возможность при реализации протокола. Передача сообщений с единственным префиксом существенно повышает уровень служебного трафика и увеличивает нагрузку при сканировании таблиц маршрутизации в случаях обновления для узлов BGP и других протоколов маршрутизации (увеличивается и объем передаваемых обновлений). Одним из способов создания сообщений с множеством префиксов для каждого пути AS на основе таблицы, не организованной по путям AS, является создание множества сообщений при сканировании таблицы. При обработке префиксов сообщение для связанных с префиксом пути AS и шлюза создается только в том случае, когда сообщения для такой пары путь-маршрутизатор не существует – в противном случае префикс просто добавляется в конец существующего сообщения. Если в сообщение уже нельзя добавить новый префикс по соображениям размера, имеющееся сообщение передается, а для префикса создается новое сообщение. После завершения сканирования всей таблицы маршрутов созданные сообщения передаются и выделенные для них ресурсы освобождаются. Максимальное сжатие при таком методе обеспечивается в тех случаях, когда все адресаты перекрываются адресными префиксами с одним шлюзом и атрибутом пути. В этом случае сообщение может содержать столько префиксов, сколько позволяет ограничение на размер сообщений (4096 октетов).

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

6.2 Обработка сообщений при использовании потокового протокола

BGP использует протокол TCP в качестве транспортного механизма. Из-за потоковой природы TCP данные для каждого принятого сообщения не обязаны прибывать одновременно. Это может приводить к возникновению трудностей при обработке данных как сообщений, особенно в системах типа BSD Unix, где невозможно определить количество принятых, но еще не обработанных данных.

Одним из вариантов решения проблемы является просмотр заголовка до обработки сообщения. Для типа KEEPALIVE сообщение состоит только из заголовка, остальные типы сообщений требуют предварительной проверки заголовка (в частности, общего размера сообщения). Если проверка дает положительный результат, указанная в заголовке длина сообщения за вычетом размера заголовка дает размер данных в сообщении, которые осталось прочитать. Реализации протокола, сталкивающиеся с проблемами при попытке чтения данных от партнера, могут установить для каждого партнера буфер сообщений (4096 байтов) и заполнять его данными, по мере их поступления от партнера.

6.3 Отказ от избыточных переключений маршрутов

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

6.4 Таймеры BGP

BGP использует 5 таймеров: ConnectRetry, Hold Time, KeepAlive, MinASOriginationInterval и MinRouteAdvertisementInterval. Для ConnectRetry предлагается устанавливать значение 120 секунд, для Hold Time — 90, для KeepAlive и MinRouteAdvertisementInterval – 30, а для MinASOriginationInterval — 15 секунд.

Реализация BGP должна обеспечивать возможность установки значений для всех таймеров.

6.5 Порядок атрибутов пути

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

6.6 Сортировка AS_SET

Другим полезным способом оптимизации является упорядочивание по номерам AS, найденным в атрибуте AS_SET. Такая оптимизация также не является обязательной.

6.7 Контроль за согласованием версий

Поскольку протокол BGP-4 может передавать агрегированные маршруты, которые не могут быть корректно представлены в BGP-3, реализации, поддерживающие BGP-4 и иные версии BGP, должны обеспечивать возможность работы только с BGP-4 независимо для каждого партнера.

6.8 Комплексное агрегирование AS_PATH

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

Для объединения атрибутов AS_PATH двух маршрутов будем представлять каждую AS как пару <type, value>, где type указывает тип сегмента пути, к которому принадлежит AS (например, AS_SEQUENCE, AS_SET), а value задает номер AS. Если две пары <type, value> совпадают, они относятся к одной AS.

Алгоритм объединения двух атрибутов AS_PATH работает следующим образом:

  1. Идентифицируется совпадение AS (как описано выше) в каждом атрибуте AS_PATH, которые находятся в том же относительном порядке для каждого атрибута AS_PATH. Две AS (X и Y) следуют в одинаковом порядке, если:
  • X предшествует Y в обоих атрибутах AS_PATH или Y предшествует X в обоих атрибутах AS_PATH.
  1. Агрегированный атрибут AS_PATH состоит из AS, найденных на этапе (a) и представленных в том же порядке, который был обнаружен в объединяемых атрибутах AS_PATH. Если две последовательные AS, найденные на этапе (a), не следуют одна за другой непосредственно в каждом из объединяемых атрибутов AS_PATH, мешающие AS (AS, расположенные между двумя последовательно совпадающими AS) в обоих атрибутах объединяются в сегмент пути AS_SET, который содержит мешающие AS из обоих атрибутов AS_PATH. Этот сегмент пути помещается в комбинированном атрибуте между двумя последовательными AS, идентифицированными в пункте (a).

Если две последовательные AS, идентифицированные на этапе (a), непосредственно следуют одна за другой в одном атрибуте, но этого не наблюдается в другом, то мешающие AS второго атрибута комбинируются в сегмент пути AS_SET, который помещается между двумя последовательными AS в агрегированном атрибуте.

Если в результате применения описанной выше процедуры данный номер AS появляется в агрегированном атрибуте AS_PATH более одного раза, все вхождения этого номера, кроме последнего (самый правый) следует удалить из агрегированного атрибута PATH.

Литература

[1] Mills, D., «Exterior Gateway Protocol Formal Specification», RFC 904, BBN, April 1984.

[2] Rekhter, Y., «EGP and Policy Based Routing in the New NSFNET Backbone», RFC 1092, T.J. Watson Research Center, February 1989.

[3] Braun, H-W., «The NSFNET Routing Architecture», RFC 1093, MERIT/NSFNET Project, February 1989.

[4] Postel, J., «Transmission Control Protocol — DARPA Internet Program Protocol Specification», STD 7, RFC 793, DARPA, September 1981.

[5] Rekhter, Y., and P. Gross, «Application of the Border Gateway Protocol in the Internet», RFC 1772, T.J. Watson Research Center, IBM Corp., MCI, March 1995.

[6] Postel, J., «Internet Protocol — DARPA Internet Program Protocol Specification», STD 5, RFC 791, DARPA, September 1981.

[7] «Information Processing Systems — Telecommunications and Information Exchange between Systems — Protocol for Exchange of Inter-domain Routing Information among Intermediate Systems to Support Forwarding of ISO 8473 PDUs», ISO/IEC IS10747, 1993

[8] Fuller, V., Li, T., Yu, J., and K. Varadhan, «Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy», RFC 1519, BARRNet, cisco, MERIT, OARnet, September 1993

[9] Rekhter, Y., Li, T., «An Architecture for IP Address Allocation with CIDR», RFC 1518, T.J. Watson Research Center, Cisco, September 1993

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

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

Адреса редакторов

Yakov Rekhter

T.J. Watson Research Center IBM Corporation

P.O. Box 704, Office H3-D40

Yorktown Heights, NY 10598

Phone: +1 914 784 7361

EMail: yakov@watson.ibm.com

Tony Li

Cisco Systems, Inc.

170 W. Tasman Dr.

San Jose, CA 95134

EMail: tli@cisco.com


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

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

nmalykh@gmail.com

1В январе 2006 г. выпущен документ RFC 4271, в котором данная спецификация признана утратившей силу. Перевод RFC 4271 имеется на сайте http://www.protocols.ru. Прим. перев.

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