AAA

RFC 4271 — Протокол BGP-4

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

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

Тезисы

Этот документ посвящен обсуждению протокола BGP (Border Gateway Protocol — протокол граничного шлюза), который является протоколом маршрутизации между автономными системами (inter-Autonomous System routing protocol).

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

BGP-4 обеспечивает новые механизмы поддержки бесклассовой междоменной маршрутизации (CIDR — Classless Interdomain Routing). Эти механизмы включают поддержку анонсирования группы адресатов с помощью префикса IP и позволяют обойтись без концепции «класса» сетей в рамках протокола BGP. BGP-4 также добавляет механизм объединения маршрутов, включающий объединение путей AS.

Этот документ прекращает действие RFC 1771.

Оглавление

1. Введение

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

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

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

Маршрутная информация, передаваемая с использованием BGP поддерживает только парадигму пересылки на основе адреса получателя (destination-based forwarding paradigm), которая предполагает, что маршрутизатор пересылает пакеты, опираясь лишь на адрес получателя, содержащийся в заголовке IP-пакета. Это, в свою очередь, отражает набор правил политики, которые могут быть применены (или не применены) с использованием BGP. Протокол BGP может поддерживать только правила, соответствующие парадигме пересылки по адресу получателя.

1.1. Определения основных терминов

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

1.2. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [RFC2119].

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

Первый вариант этого документа был опубликован в 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 (директор по маршрутизации в IESG) и команду специалистов, подготовивших обзор предыдущей версии документа (BGP-2). Эта команда, в состав которой входят Deborah Estrin, Milo Medin, John Moy, Radia Perlman, Martha Steenstrup, Mike St. Johns и Paul Tsuchiya, показала в работе высокий уровень профессионализма, упорство и такт.

Некоторые фрагменты этого документа были заимствованы из протокола IDRP [IS10747], являющегося аналогом BGP в OSI. В связи с этим следует отметить работу группы ANSI X3S3.3 под руководством Lyman Chapin и Charles Kunzinger, который также был редактором IDRP в этой группе.

Авторы также выражают свою признательность Benjamin Abarbanel, Enke Chen, Edward Crabbe, Mike Craren, Vincent Gillet, Eric Gray, Jeffrey Haas, Dimitry Haskin, Stephen Kent, John Krawczyk, David LeRoy, Dan Massey, Jonathan Natale, Dan Pei, Mathew Richardson, John Scudder, John Stewart III, Dave Thaler, Paul Traina, Russ White, Curtis Villamizar, Alex Zinin за их комментарии.

Отдельной благодарности заслуживает Andrew Lange за его помощь в подготовке окончательного варианта этого документа.

И, наконец, благодарим всех членов группы IDR за их идеи и поддержку в процессе создания этого документа.

3. Основы работы протокола

Протокол граничного шлюза BGP является протоколом маршрутизации между автономными системами. Он создан на основе опыта, полученного при разработке протокола EGP (определен в [RFC904]) и его использовании в магистралях NSFNET ([RFC1092] и [RFC1093]). Дополнительную информацию о протоколе BGP можно найти в документах [RFC1772], [RFC1930], [RFC1997] и [RFC2858].

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

В контексте этого документа предполагается, что узел BGP анонсирует своим партнерам только те маршруты, которые он сам использует (т. е., узел BGP говорит, что он «использует» маршрут BGP, если тот является наиболее предпочтительным из BGP-маршрутов и применяется для пересылки пакетов). Рассмотрение прочих случаев не входит в задачи данного документа.

В контексте этого документа термин "IP-адрес" относится к адресам IP версии 4 [RFC791].

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

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

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

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

Между парой систем организуется соединение TCP. После этого системы обмениваются между собой стандартными сообщениями для согласования и подтверждения параметров соединения.

Первоначальный поток данных является частью таблицы маршрутизации BGP, которая разрешена политикой экспорта, и называется Adj-Ribs-Out (см. параграф 3.2). В дальнейшем при при изменении таблицы маршрутов передаются нарастающие обновления. BGP не требует периодического обновления таблицы маршрутизации. Чтобы локальные изменения политики могли вступать в силу без сброса соединений, узлу BGP следует (a) сохранять текущую версию маршрутов, анонсированных ему всеми партнерами в течение работы соединения или (b) использовать расширение Route Refresh [RFC2918].

Для обеспечения сохранности соединения периодически передаются сообщения KEEPALIVE. Сообщения NOTIFICATION передаются в ответ на ошибки или при возникновении особых условий. При возникновении ошибок в соединении передается сообщение NOTIFICATION и соединение закрывается.

Партнер в другой AS называется внешним партнером (external peer), а партнер из той же AS называется внутренним (internal peer). Для внутренних и внешних соединений BGP обычно используются аббревиатуры IBGP и EBGP, соответственно.

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

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

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

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

Маршруты анонсируются между узлами BGP в сообщениях UPDATE. Множество маршрутов с одинаковыми атрибутами пути может быть объединено в одном сообщении UPDATE путем включения множества префиксов в поле NLRI сообщения UPDATE.

Маршруты хранятся в базах маршрутных данных (RIB) Adj-RIBs-In, Loc-RIB и Adj-RIBs-Out, описанных в параграфе 3.2.

Если узел BGP решает анонсировать полученный ранее маршрут, он может добавить или изменить атрибуты пути перед анонсированием маршрута партнерам.

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

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

3.2. База маршрутной информации RIB

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

Таким образом, Adj-RIBs-In содержит необработанные маршрутные данные, которые были анонсированы локальному узлу BGP его партнерами, Loc-RIB содержит маршруты, которые выбраны в процессе принятия решения локальным узлом BGP, Adj-RIBs-Out содержит маршруты для анонсирования заданным партнерам (в передаваемых локальным узлом сообщениях UPDATE).

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

Маршрутная информация, которую узел BGP использует для пересылки пакетов (или для создания таблицы, используемой для пересылки пакетов) сохраняется в таблице маршрутизации. Таблица маршрутизации включает маршруты в непосредственно подключенные сети, статические маршруты, маршруты, полученные от протоколов IGP, и маршруты, полученные от BGP. Включение того или иного маршрута BGP в таблицу маршрутизации или замена маршрута, полученного из других источников, маршрутом BGP определяются локальной политикой, а не спецификациями данного документа. В дополнение к пересылке пакетов таблица маршрутизации используется для преобразования адресов next-hop, заданных в обновлениях BGP (см. параграф 5.1.3).

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

В этой главе описан формат сообщений BGP.

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

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

4.1. Формат заголовка

Каждое сообщение BGP имеет заголовок фиксированного размера, за которым может (но не обязано) следовать поле данных, зависящих от типа сообщения. Схема заголовка показана на рисунке.

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     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

После организации соединения TCP первое сообщение от каждой из сторон соединения имеет тип OPEN. После восприятия сообщения OPEN узел BGP возвращает подтверждающее сообщение KEEPALIVE.

В дополнение к стандартному заголовку 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 (variable)                    |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

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

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

+-----------------------------------------------------+
|   Withdrawn Routes Length (2 octets)                |
+-----------------------------------------------------+
|   Withdrawn Routes (variable)                       |
+-----------------------------------------------------+
|   Total Path Attribute Length (2 octets)            |
+-----------------------------------------------------+
|   Path Attributes (variable)                        |
+-----------------------------------------------------+
|   Network Layer Reachability Information (variable) |
+-----------------------------------------------------+

Минимальный размер сообщения UPDATE составляет 23 октета; 19 занимает постоянный заголовок BGP, 2 октета — поле Withdrawn Routes Length и 2 октета — Total Path Attribute Length (поля Withdrawn Routes Length и Total Path Attribute Length в этом случае содержат значение 0).

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

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

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

В сообщениях UPDATE не следует указывать один и тот же префикс в полях WITHDRAWN ROUTES и NLRI. Однако узел BGP должен быть способен к обработке сообщений такого типа. Узлу BGP следует трактовать такие сообщения UPDATE, как будто они не содержат адресного префикса в поле WITHDRAWN ROUTES.

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

BGP не использует на уровне TCP каких-либо механизмов для проверки доступности других узлов. Вместо этого используются сообщения 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 (variable)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

Атрибуты делятся на 4 категории:

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

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

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

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

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

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

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

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

АтрибутEBGPIBGP
ORIGINобязательнообязательно
AS_PATHобязательнообязательно
NEXT_HOPобязательнообязательно
MULTI_EXIT_DISCпо своему усмотрениюпо своему усмотрению
LOCAL_PREFсм. параграф 5.1.5требуется
ATOMIC_AGGREGATEсм. параграфы 5.1.6 и 9.1.4
AGGREGATORпо своему усмотрениюпо своему усмотрению

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

Ниже описывается использование всех атрибутов пути BGP.

5.1.1. ORIGIN

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

5.1.2. AS_PATH

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

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

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

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

5.1.3. NEXT_HOP

Общеизвестный обязательный атрибут NEXT_HOP определяет IP-адрес маршрутизатора, который следует использовать в качестве следующего интервала на пути к адресатам, указанным в сообщении UPDATE. Атрибут NEXT_HOP определяется следующим образом:

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

  2. При передаче сообщения внешнему партнеру X, когда тот находится на расстоянии одного интервала IP от данного узла:

    • Если анонсируемый маршрут получен от внутреннего партнера или имеет локальное происхождение, узел BGP может использовать в качестве атрибута NEXT_HOP адрес интерфейса внутреннего партнера (или внутреннего маршрутизатора), через который анонсируемая сеть доступна для данного узла. В этом случае партнер X будет иметь общую подсеть с указанным адресом. Этот случай является вариантом NEXT_HOP из «третьих рук» (third party).

    • В остальных случаях, если анонсируемый маршрут получен от внешнего партнера, узел BGP может использовать в атрибуте NEXT_HOP адрес IP любого смежного маршрутизатора (известный из принятого атрибута NEXT_HOP), который данный узел использует для локального определения маршрута, В таких случаях X имеет с указанным адресом общую подсеть. Этот случай является вариантом NEXT_HOP из «третьих рук».

    • В противном случае, если внешний партнер, для которого анонсируется маршрут, имеет общую подсеть с одним из интерфейсов анонсирующего узла, последний может использовать связанный с таким интерфейсом адрес IP в качестве значения атрибута NEXT_HOP. Этот случай является вариантом NEXT_HOP из «первых рук» (first party).

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

  3. При передаче сообщения внешнему партнеру X, находящемуся на расстоянии нескольких интервалов IP от данного узла (multihop EBGP):

    • Узел может быть настроен на распространение атрибута NEXT_HOP. В таких случаях при анонсировании полученного от одного из партнеров маршрута узел должен указывать в качестве атрибута NEXT_HOP в анонсируемом маршруте значение NEXT_HOP, полученное в анонсе маршрута от партнера (т. е, узел не изменяет значение NEXT_HOP).

    • По умолчанию узлу BGP следует использовать IP-адрес интерфейса, который узел указывает в атрибуте NEXT_HOP для организации соединения BGP с узлом X.

Обычно значение атрибута NEXT_HOP выбирается так, чтобы принимался кратчайший из возможных путей. Узел BGP должен обеспечивать возможность запрета анонсирования атрибутов NEXT_HOP, полученных «из третьих рук» для работы в сетях с несовершенными мостами.

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

Атрибут NEXT_HOP используется узлами BGP для определения реального выходного интерфейса и адреса ближайшего маршрутизатора (immediate next-hop address), по которому следует пересылать транзитные пакеты для связанных с маршрутом адресатов.

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

5.1.4. MULTI_EXIT_DISC

Дополнительный непереходный атрибут MULTI_EXIT_DISC предназначен для использования на внешних (между AS) соединениях при выборе из множества путей в одну смежную AS. Значение атрибута MULTI_EXIT_DISC представляет собой 4-октетное целое число без знака, которое называют метрикой. При прочих равных из нескольких маршрутов следует выбирать тот, у которого меньше значение метрики. При получении через EBGP атрибут MULTI_EXIT_DISC можно распространять через IBGP другим узлам BGP в данной AS (см. также параграф 9.1.2.2). Атрибут MULTI_EXIT_DISC, полученный из соседней AS, недопустимо распространять в другие соседние AS.

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

Реализация может также в соответствии с локальной конфигурацией изменять значение атрибутов MULTI_EXIT_DISC, полученных через EBGP. Если узел BGP настроен на изменение значений атрибута MULTI_EXIT_DISC, принятых через EBGP, такое изменение должно выполняться до того, как будет определяться предпочтительный маршрут или происходить выбор маршрута (фазы 1 и 2 Decision Process). Некоторые ограничения описаны в параграфе 9.1.2.2.

5.1.5. LOCAL_PREF

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

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

5.1.6. ATOMIC_AGGREGATE

Атрибут ATOMIC_AGGREGATE относится к числу общеизвестных, но не обязательных.

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

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

Узлу BGP, получившему маршрут с атрибутом ATOMIC_AGGREGATE, не следует удалять этот атрибут при распространении маршрута другим узлам.

Для узла BGP, получившего маршрут с атрибутом ATOMIC_AGGREGATE, недопустимо указание каких-либо NLRI из этого маршрута как более специфичных (в соответствии с определением параграфа 9.1.4) при анонсировании данного маршрута другим узлам BGP.

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

5.1.7. AGGREGATOR

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

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

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

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

Фраза «соединение BGP разрывается» означает, что закрывается соединение TCP, очищается связанная с соединением BGP база Adj-RIB-In и удаляются все ресурсы, выделенные данному соединению BGP. Записи в базе Loc-RIB, связанные с удаленным партнером, помечаются как некорректные. Локальная система заново рассчитывает наилучшие маршруты для адресатов, маршруты к которым помечены как некорректные. До удаления некорректных маршрутов из таблицы они анонсируются партнерам путем отзыва ставших некорректными маршрутов или задания новых маршрутов взамен некорректных.

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

6.1. Отработка ошибок в заголовках сообщений

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

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

Если выполняется хотя бы одно из перечисленных здесь условий:

для поля Error Subcode должно устанавливаться значение Bad Message Length (некорректный размер сообщения). Поле Data в таких случаях должно содержать ошибочное значение поля Length.

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

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

Все ошибки, детектируемые в процессе обработки сообщений OPEN, должны указываться сообщениями NOTIFICATION с Error Code = OPEN Message Error. Значение Error Subcode уточняет природу ошибки.

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

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

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

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

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

Если один из дополнительных параметров принятого сообщения OPEN распознан, но имеет некорректный формат, должно устанавливаться значение Error Subcode = 0.

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

Все ошибки, детектируемые при обработке сообщений UPDATE, должны приводить к генерации сообщения NOTIFICATION с Error Code = UPDATE Message Error. Субкод ошибки уточняет ее природу.

Проверка ошибок в сообщении UPDATE начинается с атрибутов пути. Если значение поля Withdrawn Routes Length или Total Attribute Length слишком велико (т. е., Withdrawn Routes Length + Total Attribute Length + 23 превосходит значение поля Length в заголовке сообщения), в поле Error Subcode должно устанавливаться значение Malformed Attribute List.

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

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

При отсутствии любого из общеизвестных обязательных атрибутов, должен устанавливаться субкод Missing Well-known Attribute, а в поле Data должен включаться код типа (Attribute Type Code) пропущенного атрибута.

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

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

Если поле атрибута NEXT_HOP синтаксически некорректно, для поля Error Subcode должно устанавливаться значение Invalid NEXT_HOP Attribute. Поле Data должно содержать некорректный атрибут (тип, размер и значение). Синтаксическая корректность означает, что атрибут NEXT_HOP содержит допустимый IP-адрес хоста.

Семантически корректный адрес IP в поле NEXT_HOP должен соответствовать двум критериям:

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

Проверяется синтаксическая корректность атрибута AS_PATH. При наличии синтаксических ошибок в пути должно устанавливаться значение Error Subcode = Malformed AS_PATH.

Если сообщение UPDATE получено от внешнего партнера, локальная система может проверить совпадение расположенного слева (по порядку октетов протокольного сообщения) номера AS в атрибуте AS_PATH с номером автономной системы партнера, передавшего сообщение. Если номера не совпадают, должно устанавливаться значение Error Subcode = Malformed AS_PATH.

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

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

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

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

Сообщения UPDATE с корректными атрибутами пути, но без NLRI следует трактовать как корректные.

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

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

6.5. Отработка значений Hold Timer

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

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

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

6.7. Обработка Cease

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

Узел BGP может обеспечивать возможность вносить задаваемый параметрами локальной конфигурации верхний предел для числа адресных префиксов, принимаемых от соседа. В случае превышения порога, заданного параметрами локальной конфигурации (a) новые префиксы от этого соседа отбрасываются (с сохранением соединения с данным соседом) или (b) закрывается соединение BGP с этим соседом. Если узел BGP принимает решение о разрыве соединения BGP со своим соседом в результате получения от того избыточного числа префиксов, этот узел должен передать соседу сообщение NOTIFICATION с Error Code = Cease. Узел может также записать информацию об этом в журнальный файл.

6.8. Детектирование конфликтов в соединениях BGP

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

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

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

  1. Значение BGP Identifier локальной системы сравнивается с идентификатором удаленного узла BGP, указанным в сообщении OPEN. Сравнение производится с преобразованием значений BGP Identifier к принятому для хостов порядку байтов (host byte order) и трактовкой полученных значений как 4-октетных целых чисел без знака.

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

  3. В противном случае локальная система закрывает недавно созданное соединение BGP (связанное с недавно полученным сообщением OPEN) и продолжает использовать существующее соединение с этим партнером (то, которое уже находится в состоянии OpenConfirm).

Если конфигурационные параметры не задают иного, конфликт с существующим соединением 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

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

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

  1. Описание событий для машины состояний (параграф 8.1)
  2. Описание FSM (параграф 8.2)

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

  1. State — состояние;
  2. ConnectRetryCounter — счетчик числа попыток организации соединения;
  3. ConnectRetryTimer — таймер повторов для соединения;
  4. ConnectRetryTime — время ожидания для повтора;
  5. HoldTimer — таймер удержания;
  6. HoldTime — время удержания;
  7. KeepaliveTimer — таймер сохранения;
  8. KeepaliveTime — время сохранения.

Атрибуты состояния сессии показывают текущее состояние BGP FSM. Счетчик ConnectRetryCounter показывает число попыток узла BGP организовать соединение с партнером.

Обязательные атрибуты, связанные с таймерами, описаны в главе 10. Для каждого таймера существуют значения "timer" и "time" (начальное значение).

Ниже перечислены дополнительные атрибуты сессий. Эти атрибуты могут поддерживаться для соединений или для локальной системы в целом:

  1. AcceptConnectionsUnconfiguredPeers
  2. AllowAutomaticStart
  3. AllowAutomaticStop
  4. CollisionDetectEstablishedState
  5. DampPeerOscillations
  6. DelayOpen
  7. DelayOpenTime
  8. DelayOpenTimer
  9. IdleHoldTime
  10. IdleHoldTimer
  11. PassiveTcpEstablishment
  12. SendNOTIFICATIONwithoutOPEN
  13. TrackTcpState

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

Первый параметр (DelayOpen, DampPeerOscillations) является дополнительным атрибутом, который показывает, что функция Timer активна. Значение "Time" указывает начальное состояние таймера (DelayOpenTime, IdleHoldTime). "Timer" задает реальный таймер.

Описание взаимодействия между дополнительными атрибутами и состояниями, передаваемыми FSM, приведено в параграфе 8.1.1. Параграф 8.2.1.3 содержит краткий обзор двух различных типов дополнительных атрибутов (флаги и таймеры).

8.1. События BGP FSM

8.1.1. Дополнительные события, связанные с дополнительными атрибутами сессии

Входной информацией для BGP FSM являются события, которые могут относиться к числу обязательных (mandatory) и необязательных (optional). Некоторые из дополнительных событий связаны с дополнительными атрибутами сессии. Дополнительные атрибуты сессий включают несколько групп функций FSM.

Связи между функциями FSM, событиями и дополнительными атрибутами сессий описаны ниже:

8.1.2. События административного плана

К числу административных относятся те события, при которых операторский интерфейс машины политики BGP сигнализирует машине конечных состояний BGP о необходимости запуска или остановки машины состояний BGP. Базовые средства индикации запуска и остановки дополняются необязательными атрибутами соединения, которые передают сигналы о некоторых типах запуска и остановки BGP FSM. Примером такой комбинации может служить Событие 5 — AutomaticStart_with_PassiveTcpEstablishment. С помощью такого события реализация BGP сигнализирует BGP FSM об использовании Automatic Start с опцией для применения процедуры Passive TCP Establishment. В свою очередь Passive TCP establishment сигнализирует, что BGP FSM будет ждать вызова удаленной стороны для организации соединения TCP.

Отметим, что только Событие 1 (ManualStart) и Событие 2 (ManualStop) относятся к числу обязательных административных событий. Все остальные события административного типа (События 3—8) являются дополнительными. Каждое из описанных ниже событий имеет номер, определение, статус (обязательное или дополнительное), а также дополнительные атрибуты сессии, которые следует устанавливать на каждой стадии. При генерации Событий 1 — 8 для BGP FSM проверяются условия, заданные в поле "Статус дополнительных атрибутов". Если любое из этих условий не выполняется, локальной системе следует записать в журнальный файл сведения об ошибке FSM.

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

8.1.3. События, связанные с таймерами

8.1.4. События, связанные с соединениями TCP

8.1.5. События, связанные с сообщениями BGP

8.2. Описание FSM

8.2.1. Определение FSM

Реализация BGP должна поддерживать отдельную FSM для каждого включенного в конфигурацию партнера. Каждый узел BGP, включенный в потенциальное соединение, будет пытаться связаться с партнером, если для данного узла не задано сохранение состояния Idle или пассивный режим. В последующем обсуждении активная или подключающаяся сторона соединения TCP (та сторона, с которой был передан первый пакет TCP SYN) называется исходящей (outgoing). Пассивная или ожидающая сторона (отправитель первого пакета SYN/ACK) будет называться входящей. Дополнительные разъяснения терминов «активный» и «пассивный» приведены ниже в параграфе 8.2.1.1.

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

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

Между парой партнеров может существовать несколько соединений, если в них используются различные пары адресов IP. Такая ситуация называется «множественным партнерством» (multiple "configured peerings").

8.2.1.1. Термины «активный» и «пассивный»

Термины «активный» и «пассивный» присутствуют в сленге операторов Internet уже почти десятилетие и оказались весьма полезными. Эти термины в контексте соединений TCP или соединений с партнерами имеют специфическое толкование. В любом соединении TCP может быть только одна активная и одна пассивная сторона (в соответствии с приведенным выше определением и описанными ниже состояниями FSM). Когда узел BGP настроен как активный, он может располагаться как на активной, так и на пассивной стороне соединения, которое будет организовано в результате. После завершения процесса организации соединения TCP уже не имеет значения, какая из сторон была активной, а какая пассивной на этапе организации соединения. Единственное различие заключается в том, какая из сторон будет использовать порт TCP с номером 179.

8.2.1.2. FSM и детектирование конфликтов

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

8.2.1.3. FSM и дополнительные атрибуты сессий

Дополнительные атрибуты сессий действуют как флаги (TRUE или FALSE) или дополнительные таймеры. Для атрибутов, являющихся флагами, должно поддерживаться соответствующее действие BGP FSM, если для флага может быть установлено значение TRUE. Например, если в реализации BGP могут быть установлены опции AutoStart и PassiveTcpEstablishment, должны поддерживаться События 3, 4 и 5. Если дополнительный атрибут сессии не может иметь значения TRUE, соответствующие события не поддерживаются.

Каждый из дополнительный таймеров (DelayOpenTimer и IdleHoldTimer) имеет группу атрибутов, включающую:

Формат дополнительный таймеров показан ниже:

Если флаг индикации поддержки для дополнительного таймера (DelayOpen или DampPeerOscillations) не может иметь значение TRUE, таймеры и события, поддерживающие данную опцию, не поддерживаются.

8.2.1.4. Номера событий FSM

Номера событий (1-28) используются при описании машины состояний. Реализации могут использовать эти номера для систем сетевого управления. Точная форма FSM или событий FSM зависит от реализации.

8.2.1.5. Действия FSM, зависящие от реализации

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

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

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

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

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

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

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

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

После того, как узел BGP обновит базу Adj-RIB-In, ему следует инициировать процесс выбора маршрутов (Decision Process).

9.1. Процесс выбора маршрутов (Decision Process)

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

BGP Decision Process описывается здесь концептуально и не обязательно должен быть реализован в точном соответствии с этим описанием. Если реализация поддерживает описанную функциональность, она будет демонстрировать внешнее поведение, соответствующее данному описанию.

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

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

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

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

9.1.1. Фаза 1: Расчет предпочтений (Calculation of Degree of Preference)

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

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

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

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

9.1.2. Фаза 2: Выбор маршрута (Route Selection)

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

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

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

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

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

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

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

Локальный узел должен определить адрес ближайшего маршрутизатора (immediate next-hop) из атрибута NEXT_HOP выбранного маршрута (см. параграф 5.1.3). При смене ближайшего маршрутизатора или стоимости IGP до NEXT_HOP (NEXT_HOP преобразуется через маршрут IGP) выбор маршрута в фазе 2 должен быть проведен заново.

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

Маршруты, которые невозможно преобразовать, следует удалить из базы Loc-RIB и таблицы маршрутизации. Однако соответствующие непреобразуемые маршруты следует сохранить в базе Adj-RIBs-In (впоследствии их преобразование может стать возможным).

9.1.2.1. Возможность преобразования маршрута

Как сказано в параграфе 9.1.2, узлам BGP следует исключать непреобразуемые маршруты из рассмотрения в фазе 2. Это позволяет включать в базу Loc-RIB и таблицу маршрутизации только действующие маршруты.

Возможность преобразования маршрута определяется перечисленными ниже условиями:

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

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

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

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

9.1.2.2. «Отбрасывание лишнего» (фаза 2)

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

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

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

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

9.1.3. Фаза 3: Распространение маршрутов (Route Dissemination)

Фаза 3 выполняется после завершения операций фазы 2 или по любому из перечисленных ниже событий:

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

Все маршруты базы Loc-RIB обрабатываются для включения в Adj-RIBs-Out, согласно заданной конфигурацией политике. Эта политика может исключать маршруты, содержащиеся в Loc-RIB, из числа добавляемых в базу Adj-RIB-Out. Маршрут не следует устанавливать в Adj-Rib-Out, если для адресатов и NEXT_HOP этого маршрута а таблице маршрутизации нет соответствующей записи. Если маршрут из базы Loc-RIB не включается в ту или иную базу Adj-RIB-Out, ранее анонсированный маршрут этой базы Adj-RIB-Out должен быть отозван с помощью сообщения UPDATE (см. параграф 9.2).

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

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

После завершения процессов обновления Adj-RIBs-Out и таблицы маршрутизации локальный узел BGP запускает процесс передачи обновлений (Update-Send — параграф 9.2).

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

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

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

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

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

Если узел BGP выбирает агрегирование маршрутов, ему следует включить все AS, используемые при формировании агрегированного маршрута, в AS_SET или добавить в маршрут атрибут ATOMIC_AGGREGATE. Данный атрибут в настоящее время используется в основном как информационный. По мере избавления от протоколов маршрутизации IP, хостов и маршрутизаторов, не поддерживающих бесклассовую маршрутизацию, необходимость в деагрегировании маршрутов отпадет. Маршруты не следует деагрегировать. В частности, маршруты с атрибутом ATOMIC_AGGREGATE деагрегировать недопустимо. Таким образом, значение NLRI такого маршрута не может быть более специфичным. Пересылка по такому маршруту не обеспечивает гарантии, что пакеты IP будут в реальности проходить только через AS, указанные в атрибуте AS_PATH этого маршрута.

9.2. Процесс передачи обновлений (Update-Send)

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

Когда узел BGP получает сообщение UPDATE от внутреннего партнера, принимающему узлу BGP не следует заново распространять содержащуюся в сообщении UPDATE информацию другим внутренним узлам (если данный узел не используется как BGP Route Reflector [RFC2796]).

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

Узлу BGP не следует анонсировать доступный маршрут BGP из своей базы Adj-RIB-Out, если это будет порождать сообщение UPDATE, содержащее маршрут BGP, который уже был анонсирован.

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

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

9.2.1. Контроль служебного трафика

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

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

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

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

Поскольку внутри AS требуется быстрое схождение маршрутов, (a) значение MinRouteAdvertisementIntervalTimer, используемое для внутренних партнеров, следует делать меньше значения этого параметра для внешних партнеров или (b) описанную здесь процедуру не следует применять для маршрутов, передаваемых внутренним партнерам.

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

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

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

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

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

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

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

Процесс выбора маршрутов (Decision Process) может дополнительно снижать объем информации, включаемой в базу Adj-RIBs-Out, любым из перечисленных ниже методов.

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

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

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

Маршруты с разными атрибутами MULTI_EXIT_DISC не следует агрегировать.

Если агрегированный маршрут имеет сегмент AS_SET в качестве первого элемента атрибута AS_PATH, маршрутизатору, от которого исходит маршрут, не следует анонсировать с этим маршрутом атрибут MULTI_EXIT_DISC.

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

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

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

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

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

10. Таймеры BGP

BGP поддерживает пять таймеров — ConnectRetryTimer (см. главу 8), HoldTimer (см. параграф 4.2), KeepaliveTimer (см. главу 8), MinASOriginationIntervalTimer (см. параграф 9.2.1.2) и MinRouteAdvertisementIntervalTimer (см. параграф 9.2.1.1).

Могут также поддерживаться два дополнительных таймера — DelayOpenTimer и IdleHoldTimer (см. главу 8). Использование этих таймеров описано в главе 8. Полное описание работы этих дополнительных таймеров выходит за пределы данного документа.

Параметр ConnectRetryTime является обязательным атрибутом FSM и хранит начальное значение для таймера ConnectRetryTimer. Предлагается по умолчанию устанавливать значение ConnectRetryTime равным 120 секундам.

Параметр HoldTime является обязательным атрибутом FSM и сохраняет начальное значение таймера HoldTimer. Предлагается по умолчанию использовать для HoldTime значение 90 секунд.

На некоторых этапах (см. главу 8) для HoldTimer устанавливается большое значение. Предлагается в качестве такого значения устанавливать 4 минуты.

Параметр KeepaliveTime является обязательным атрибутом FSM и сохраняет начальное значение таймера KeepaliveTimer. По умолчанию предлагается устанавливать для KeepaliveTime значение 1/3 HoldTime.

Для таймера MinASOriginationIntervalTimer предлагается по умолчанию использовать значение 15 секунд.

Для таймера MinRouteAdvertisementIntervalTimer предлагается устанавливать значение 30 секунд на соединениях EBGP.

Для таймера MinRouteAdvertisementIntervalTimer предлагается устанавливать значение 5 секунд на соединениях IBGP.

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

Для снижения вероятности возникновения пиков при распространении сообщений BGP данным узлом следует использовать флуктуации (jitter) для таймеров, связанных с MinASOriginationIntervalTimer, KeepaliveTimer, MinRouteAdvertisementIntervalTimer и ConnectRetryTimer. Данный узел BGP может использовать одинаковые флуктуации для каждого из этих таймеров независимо от адресатов передаваемых обновлений (т. е., флуктуации не требуется делать независимыми для каждого партнера).

Предлагаемую по умолчанию величину флуктуаций следует определять путем умножения базового значения соответствующего таймера на случайное значение из диапазона 0,75 — 1,0. При каждой установке таймера следует выбирать новое случайное значение. Диапазон флуктуаций может быть настраиваемым.

Приложение A. Сравнение с RFC 1771

В настоящем документе имеется множество редакторских правок спецификации [RFC1771] (слишком много для перечисления).

Ниже приводится список технических изменений:

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

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

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

Все изменения, перечисленные в Приложениях A и B, а также указанные ниже изменения:

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

Все изменения, перечисленные в Приложениях A, B и C, а также указанные ниже изменения:

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

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

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

Если пользовательский интерфейс TCP в локальной системе поддерживает установку поля DSCP [RFC2474] для соединений TCP, транспортные соединения для BGP следует открывать с битами 0-2 поля DSCP, имеющими двоичное значение 110.

Реализация должна поддерживать опцию TCP MD5 [RFC2385].

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

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

Приложение F.1. Множество префиксов сетей в одном сообщении

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

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

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

Приложение F.2. Снижение числа переключений маршрутов

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

Приложение F.3. Упорядочение атрибутов пути

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

Приложение F.4. Сортировка AS_SET

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

Приложение F.5. Контроль за согласованием версий

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

Приложение F.6. Комплексное агрегирование ASAS_PATH

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

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

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

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

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

Реализация BGP должна поддерживать механизм аутентификации, определенный в RFC 2385 [RFC2385]. Аутентификация на основе этого механизма может осуществляться независимо для каждого партнера.

BGP использует протокол TCP для организации надежного обмена трафиком между маршрутизаторами-партнерами. Для обеспечения целостности соединений и аутентификации источников данных в соединениях между парами узлов спецификация BGP задает использование механизма, определенного в RFC 2385. Этот механизм предназначен для детектирования и предотвращения активного перехвата (wiretapping attacks) данных из соединений TCP между маршрутизаторами. В отсутствие такого рода механизмов обеспечения безопасности атакующие могут разрывать соединения TCP и/или маскироваться под легитимные партнерские маршрутизаторы. Поскольку определенный в RFC механизм не обеспечивает аутентификацию партнеров, протокольные соединения могут служить объектом некоторых атак с повторным использованием перехваченных ранее данных (replay attack), которые не будут детектироваться уровнем TCP. Такие атаки могут приводить к доставке (от уровня TCP) «испорченных» или «подмененных» сообщений BGP.

Механизм, определенный в RFC 2385, добавляет к обычным контрольным суммам TCP 16-байтовый код аутентификации сообщения (MAC) который рассчитывается на основе тех же данных, что и контрольная сумма TCP. Расчет MAC основан на использовании необратимой хэш-функции (MD5) и закрытых ключей. Ключ известен паре маршрутизаторов-партнеров и используется для генерации значений MAC, которые не могут быть вычислены атакующим без знания ключа. Соответствующие спецификации реализации протокола должны поддерживать этот механизм и позволять администратору активизировать его использование независимо для каждого партнера.

RFC 2385 не задает механизмов поддержки ключей (например, их генерации, распространения и замены), используемых для расчета MAC. Документ RFC 3562 [RFC3562] (он имеет статус информационного) содержит некоторые рекомендации в этом направлении с обоснованием приведенных рекомендаций. В документе отмечается, что следует использовать разные ключи для связи с каждым защищенным партнером. Если один ключ используется для множества партнеров, это может привести к снижению уровня безопасности (например, за счет того, что при компрометации одного маршрутизатора становятся известными ключи, используемые для других маршрутизаторов).

Используемые для расчета MAC ключи следует периодически заменять для минимизации возможности компрометации ключа или успешной криптоаналитической атаки. В RFC 3562 предлагается устанавливать крипто-период (срок действия ключа) не более 90 дней. Более частая смена ключей снижает вероятность успеха атак с повторным использованием перехваченных данных. Однако отсутствие стандартного механизма эффективной координированной замены ключа, используемого парой маршрутизаторов, не позволяет надеяться, что реализации BGP-4, соответствующие данной спецификации, будут поддерживать такую частоту смены ключей.

Очевидно, что ключи следует выбирать так, чтобы атакующему было сложно угадать или подобрать ключ. Описанные в RFC 1750 методы генерации случайных чисел обеспечивают руководство по созданию значений, которые могут использоваться в качестве ключей. RFC 2385 предлагает разработчикам использовать ключи, представляющие собой строки печатных символов ASCII размером 80 байтов или меньше. В RFC 3562 предлагается в таком контексте использовать ключи размером от 12 до 24 байтов, состоящие из случайных (псевдослучайных) битов. Это полностью совместимо с предложениями для аналогичных алгоритмов MAC, которые обычно используют ключи размером от 16 до 20 байтов. В части обеспечения достаточного уровня случайности при использовании ключей минимальной длины в RFC 3562 также отмечается,что типичная срока текста ACSII будет близка к верхней границе диапазона длины ключей, заданного в RFC 2385.

Анализ уязвимостей протокола BGP приводится в документе [RFC4272].

Согласование с IANA

Все сообщения BGP содержат 8-битовые идентификаторы типа сообщения, для которых агентство IANA создало и поддерживает реестр «BGP Message Types». В данном документе определены следующие типы сообщений:

ИмяЗначениеОпределение
OPEN1См. параграф 4.2.
UPDATE2См. параграф 4.3.
NOTIFICATION3См. параграф 4.5.
KEEPALIVE4См. параграф 4.4.

Выделение новых значений для типов сообщений происходит на основе процесса стандартизации (Standards Action), определенного в [RFC2434], или путем «Заблаговременного выделения агентством IANA», как описано в [RFC4020]. Типы сообщений задаются именем и числовым идентификатором.

Сообщения BGP UPDATE могут содержать один или множество атрибутов пути (Path Attribute), каждый из которых включает 8-битовый код типа (Attribute Type Code). Агентство IANA поддерживает реестр таких кодов, названный "BGP Path Attributes". В этом документе определяются следующие типы атрибутов пути (Path Attributes Type Code):

ИмяЗначениеОпределение
ORIGIN1См. параграф 5.1.1.
AS_PATH2См. параграф 5.1.2.
NEXT_HOP3См. параграф 5.1.3.
MULTI_EXIT_DISC4См. параграф 5.1.4.
LOCAL_PREF5См. параграф 5.1.5.
ATOMIC_AGGREGATE6См. параграф 5.1.6.
AGGREGATOR7См. параграф 5.1.7.

Выделение новых значений для кодов атрибутов пути происходит на основе процесса стандартизации (Standards Action), определенного в [RFC2434], или путем «Заблаговременного выделения агентством IANA», как описано в [RFC4020]. Типы атрибутов задаются именем и числовым идентификатором.

Сообщения BGP NOTIFICATION содержат 8-битовые значения кода ошибки (Error Code), для которых агентство IANA создало и поддерживает реестр "BGP Error Codes". В этом документе определены следующие коды ошибок:

ИмяЗначениеОпределение
Message Header Error1См. параграф 6.1.
OPEN Message Error2См. параграф 6.2.
UPDATE Message Error3См. параграф 6.3.
Hold Timer Expired4См. параграф 6.5.
Finite State Machine Error5См. параграф 6.6.
Cease6См. параграф 6.7.

Выделение новых значений для кодов ошибок происходит на основе процесса стандартизации (Standards Action), определенного в [RFC2434], или путем «Заблаговременного выделения агентством IANA», как описано в [RFC4020]. Коды ошибок задаются именем и числовым идентификатором.

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

Агентство IANA создало и поддерживает набор реестров "Error Subcodes", в котором для каждого кода ошибки BGP имеется отдельный реестр. Выделение новых значений для субкодов ошибок происходит на основе процесса стандартизации (Standards Action), определенного в [RFC2434], или путем «Заблаговременного выделения агентством IANA», как описано в [RFC4020]. Субкоды ошибок задаются именем и числовым идентификатором.

В этом документе определяются следующие субкоды для ошибок в заголовках сообщений (Message Header Error):

ИмяЗначениеОпределение
Connection Not Synchronized1См. параграф 6.1.
Bad Message Length2См. параграф 6.1.
Bad Message Type3См. параграф 6.1.

В этом документе определяются следующие субкоды для ошибок в сообщениях OPEN (OPEN Message Error):

ИмяЗначениеОпределение
Unsupported Version Number1См. параграф 6.2.
Bad Peer AS2См. параграф 6.2.
Bad BGP Identifier3См. параграф 6.2.
Unsupported Optional Parameter4См. параграф 6.2.
[отменено]5См. Приложение A.
Unacceptable Hold Time6См. параграф 6.2.

В этом документе определяются следующие субкоды для ошибок в сообщениях UPDATE (UPDATE Message Error):

ИмяЗначениеОпределение
Malformed Attribute List1См. параграф 6.3.
Unrecognized Well-known Attribute2См. параграф 6.3.
Missing Well-known Attribute3См. параграф 6.3.
Attribute Flags Error4См. параграф 6.3.
Attribute Length Error5
Invalid ORIGIN Attribute6См. параграф 6.3.
[отменено]7См. Приложение A.
Invalid NEXT_HOP Attribute8
Optional Attribute Error9
Invalid Network Field10
Malformed AS_PATH11

Нормативные документы

  1. [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981
  2. [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981
  3. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  4. [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
  5. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

Дополнительная литература

  1. [RFC904] Mills, D., "Exterior Gateway Protocol formal specification", RFC 904, April 1984.
  2. [RFC1092] Rekhter, J., "EGP and policy based routing in the new NSFNET backbone", RFC 1092, February 1989.
  3. [RFC1093] Braun, H., "NSFNET routing architecture", RFC 1093, February 1989.
  4. [RFC1105] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol (BGP)", RFC 1105, June 1989.
  5. [RFC1163] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol (BGP)", RFC 1163, June 1990.
  6. [RFC1267] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol 3 (BGP-3)", RFC 1267, October 1991.
  7. [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
  8. [RFC1772] Rekhter, Y. and P. Gross, "Application of the Border Gateway Protocol in the Internet", RFC 1772, March 1995.
  9. [RFC1518] Rekhter, Y. and T. Li, "An Architecture for IP Address Allocation with CIDR", RFC 1518, September 1993.
  10. [RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
  11. [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", BCP 6, RFC 1930, March 1996.
  12. [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996.
  13. [RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998.
  14. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
  15. [RFC2796] Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection — An Alternative to Full Mesh IBGP", RFC 279, April 2000.
  16. [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
  17. [RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 3392, November 2002.
  18. [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, September 2000.
  19. [RFC3065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 3065, February 2001.
  20. [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003
  21. [IS10747] "Information Processing Systems — Telecommunications and Information Exchange between Systems — Protocol for Exchange of Inter-domain Routeing Information among Intermediate Systems to Support Forwarding of ISO 8473 PDUs", ISO/IEC IS10747, 1993.
  22. [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006
  23. [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 4020, February 2005.

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

Yakov Rekhter
Juniper Networks
EMail: ten.repinuj@vokay

Tony Li
EMail: il.ynot@il.ynot

Susan Hares
NextHop Technologies, Inc.
825 Victors Way
Ann Arbor, MI 48108
Phone: (734)222-1610
EMail: moc.pohtxen@hks

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

Николай Малых, ur.slocotorp@hkylamn