Формат BGP-сообщений об изменениях маршрутов

Рис. 4.4.11.4.1. Формат BGP-сообщений об изменениях маршрутов

Поле маркер содержит 16 октетов и его содержимое может легко интерпретироваться получателем. Если тип сообщения "OPEN", или если код идентификации в сообщении open равен нулю, то поле маркер должно быть заполнено единицами. Маркер может использоваться для обнаружения потери синхронизации в работе BGP-партнеров. Поле длина имеет два октета и определяет общую длину сообщения в октетах, включая заголовок. Значение этого поля должно лежать в пределах 19-4096. Поле тип представляет собой код разновидности сообщения и может принимать следующие значения:

После того как связь на транспортном протокольном уровне установлена, первое сообщение, которое должно быть послано - это OPEN. При успешном прохождении этого сообщения партнер должен откликнуться сообщением KEEPALIVE ("Еще жив"). После этого возможны любые сообщения. Кроме заголовка сообщение open содержит следующие поля (рис. 4.4.11.4.2):

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

Рис. 4.4.11.4.2 Формат сообщения open

Поле версия описывает код версии используемого протокола, на сегодня для BGP он равен 4. Двух-октетное поле моя автономная система определяет код AS отправителя. Поле время сохранения характеризует время в секундах, которое отправитель предлагает занести в таймер сохранения. После получения сообщения OPEN BGP-маршрутизатор должен выбрать значение времени сохранения. Обычно выбирается меньшее из полученного в сообщении open и значения, определенного при конфигурации системы (0-3сек). Время сохранения определяет максимальное время в секундах между сообщениями KEEPALIVE и UPDATE или между двумя UPDATE-сообщениями. Каждому узлу в рамках BGP приписывается 4-октетный идентификатор (BGP-identifier, задается при инсталляции и идентичен для всех интерфейсов локальной сети). Если два узла установили два канала связи друг с другом, то согласно правилам должен будет сохранен канал, начинающийся в узле, BGP-идентификатор которого больше. Предусмотрен механизм разрешения проблемы при равных идентификаторах.

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

Длина сообщения = 29 + длина поля идентификационных данных.
Минимальная длина сообщения open составляет 29 октетов, включая заголовок.

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

Формат update-сообщения

Рис. 4.4.11.4.3 Формат update-сообщения

Если длина списка отмененных маршрутов равна нулю, ни один маршрут не отменен, а поле отмененные маршруты в сообщении отсутствует. Поле отмененные маршруты имеет переменную длину и содержит список IP-адресных префиксов маршрутов, которые стали недоступны. Каждая такая запись имеет формат:

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

Нулевое значение полной длины списка атрибутов пути говорит о том, что информация о доступности сетевого уровня в UPDATE-сообщении отсутствует. Список атрибутов пути присутствует в любом UPDATE-сообщении. Этот список имеет переменную длину, а каждый атрибут содержит три составные части: тип атрибута, длину атрибута и значение атрибута. Тип атрибута представляет собой двух-октетное поле со структурой:

Старший бит (бит0) поля флаги атрибута определяет, является ли атрибут опционным (бит0=1) или стандартным (well-known, бит0=0). Бит 1 этого поля определяет, является ли атрибут переходным (бит1=1) или непереходным (бит1=0). Для обычных атрибутов этот бит должен быть равен 1. Третий бит (бит 2) поля Флагов атрибута определяет, является ли информация в опционном переходном атрибуте полной (бит2=0) или частичной (бит2=1). Для обычных и для опционных непереходных атрибутов этот бит должен быть равен нулю. Бит 3 поля флагов атрибута информирует о том, имеет ли длина атрибута один (бит3=0) октет или два октета (бит3=1). Бит3 может быть равен 1 только в случае, когда длина атрибута более 255 октетов. Младшие 4 бита октета флагов атрибута не используются (и должны обнуляться). Если бит3=0, то третий октет атрибута пути содержит длину поля данных атрибута в октетах. Если же бит3=1, то третий и четвертый октеты атрибута пути хранят длину поля данных атрибута. Остальные октеты поля атрибут пути характеризуют значение атрибута и интерпретируются согласно флагам атрибута.

Атрибуты пути бывают "стандартные обязательные" (well-known mandatory), "стандартные на усмотрение оператора", "опционные переходные" и "опционные непереходные". Стандартные атрибуты должны распознаваться любыми BGP-приложениями. Опционные атрибуты могут не распознаваться некоторыми приложениями. Обработка нераспознанных атрибутов задается битом 1 поля флагов. Пути с нераспознанными переходными опционными атрибутами должны восприниматься, как рабочие. Один и тот же атрибут может появляться в списке атрибутов пути только один раз.

Разновидности кодов типа атрибута

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

ORIGIN (код типа = 1) - стандартный обязательный атрибут, который определяет происхождение путевой информации. Генерируется автономной системой, которая является источником маршрутной информации. Значение атрибута в этом случае может принимать следующие значения:

AS_PATH (код типа = 2) также является стандартным обязательным атрибутом, который составлен из совокупности сегментов пути. Атрибут определяет автономные системы, через которые доставлена маршрутная информация. Когда BGP-маршрутизатор передает описание маршрута, которое он получил от своего BGP-партнера, он модифицирует AS_PATH-атрибут, соответствующий этому маршруту, если информация передается за пределы автономной системы. Каждый сегмент AS_PATH состоит из трех частей <тип сегмента пути, длина сегмента пути и оценка сегмента пути>. Тип сегмента пути представляет в свою очередь однооктетное поле, которое может принимать следующие значения:

Длина сегмента пути представляет собой одно-октетное поле, содержащее число as, записанных в поле оценка сегмента пути. Последнее поле хранит один или более кодов автономной системы, по два октета каждый.

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

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

LOCAL_PREF (код типа = 5) является опционным атрибутом, занимающим 4 октета. Он используется BGP-маршрутизатором, чтобы сообщить своим BGP-партнерам в своей собственной автономной системе степень предпочтения объявленного маршрута.

ATOMIC_AGGREGATE (код типа = 6) представляет собой стандартный атрибут, который используется для информирования партнеров о выборе маршрута, обеспечивающего доступ к более широкому списку адресов.

aggregator (код типа = 7) - опционный переходной атрибут с длиной в 6 октетов. Атрибут содержит последний код автономной системы, который определяет агрегатный маршрут (занимает два октета), и IP-адрес BGP-маршрутизатора, который сформировал этот маршрут (4 октета). Объем информации о достижимости сетевого уровня равен (в октетах):

Длина сообщения UPDATE - 23 - полная длина атрибутов пути - длина списка отмененных маршрутов. Информация о достижимости кодируется в следующей форме:

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

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

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

Код ошибки представляет собой одно-октетное поле и указывает на тип данного сообщения. Возможны следующие коды ошибки:

Коды ошибок

Таблица 4.4.11.4.1. Коды ошибок

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

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

Таблица 4.4.11.4.2 Субкоды ошибок

Маршрутная база данных RIB

Вся маршрутная информация хранится в специальной базе данных RIB (routing information base). Маршрутная база данных BGP состоит из трех частей:

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

Алгоритм вектора расстояния

BGP является протоколом, ориентирующимся на вектор расстояния. Вектор описывается списком AS по 16 бит на AS. BGP регулярно (каждые 30сек) посылает соседям TCP-сообщения, подтверждающие, что узел жив (это не тоже самое что "Keepalive" функция в TCP). Если два BGP-маршрутизатора попытаются установить связь друг с другом одновременно, такие две связи могут быть установлены. Такая ситуация называется столкновением, одна из связей должна быть ликвидирована. При установлении связи маршрутизаторов сначала делается попытка реализовать высший из протоколов (например, BGP-4), если один из них не поддерживает эту версию, номер версии понижается.

Протокол BGP-4 является усовершенствованной версией (по сравнению с BGP-3). Эта версия позволяет пересылать информацию о маршруте в рамках одного IP-пакета. Концепция классов сетей и субсети находятся вне рамок этой версии. Для того чтобы приспособиться к этому, изменена семантика и кодирование атрибута AS_PASS. Введен новый атрибут LOCAL_PREF (степень предпочтительности маршрута для собственной AS), который упрощает процедуру выбора маршрута. Атрибут INTER_AS_METRICSпереименован в MULTI_EXIT_DISC (4 октета; служит для выбора пути к одному из соседей). Введены новые атрибуты ATOMIC_AGGREGATE и AGGREGATOR, которые позволяют группировать маршруты. Структура данных отражается и на схеме принятия решения, которая имеет три фазы:

1. Вычисление степени предпочтения для каждого маршрута, полученного от соседней AS, и передача информации другим узлам местной AS.
2. Выбор лучшего маршрута из наличного числа для каждой точки назначения и укладка результата в LOC-RIB.
3. Рассылка информации из loc_rib всем соседним AS согласно политике, заложенной в RIB. Группировка маршрутов и редактирование маршрутной информации.

Бесклассовая интердоменная маршрутизация (CIDR- classless interdomain routing, RFC-1520, -1519) - способ избежать того, чтобы каждая С-сеть требовала свою таблицу маршрутизации. Основополагающий принцип CIDR заключается в группировке (агрегатировании) IP-адресов таким образом, чтобы сократить число входов в таблицах маршрутизации (RFC-1519, RFC-1518, RFC-1467, RFC-1466). Протокол совместим с RIP-2, OSPF и BGP-4.

Метрика маршрута в BGP

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

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

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

-a отображает состояния всех соединений;
-i отображает значения конфигурационных параметров;
-r отображает таблицу маршрутов;
-v отображает статистику обмена локального Ethernet-интерфейса.

Например, команда netstat -r может выдать:

Таблица маршрутизации

Routing tables (таблицы маршрутизации)

Здесь приведен только фрагмент маршрутной таблицы. Колонка destination указывает на конечную точку маршрута (default - маршрут по умолчанию), колонка gateway - имена маршрутизаторов, через которые достижим адресат. Флаг "U" (Up) свидетельствует о том, что канал в рабочем состоянии. Флаг "G" указывает на то, что маршрут проходит через маршрутизатор (gateway). При этом вторая колонка таблицы содержит имя этого маршрутизатора. Если флаг "G" отсутствует, ЭВМ непосредственно связана с указанной сетью. Флаг "D" указывает на то, что маршрут был добавлен динамически. Если маршрут связан только с конкретной ЭВМ, а не с сетью, он помечается флагом "H" (host), при этом первая колонка таблицы содержит его IP-адрес. Базовая команда netstat может обеспечить следующую информацию:

Active Internet connections (активные Интернет связи)

Active UNIX domain sockets (активные UNIX-соединители домена)

Размеры маршрутных таблиц протокола BGP для IPv4 росли последние года практически линейно (см. рис. 4.4.11.4.5 и 6 - What's So Special About 512?, Geoff Huston, APNIC, The Internet Protocol Journal, V17, N2, стр. 2).

Рис. 4.4.11.4.5. Рост размера маршрутных таблиц BGP для IPv4 (2011-14гг)

Рис. 4.4.11.4.6. Рост размера маршрутных таблиц BGP для IPv6 (2011-14гг)

Рис. 4.4.11.4.7. Обновления маршрутных таблиц BGP в течение дня

Размер таблицы маршрутизации для IPv4 с2008 по 2018гг увеличился втрое, с 250,000 рекордов до немного более 750,000 рекордов в 2018 году. История маршрутизации IPv6 является более драматической с ростом от 1,100 до 52,000 рекордов. А протокол BGP продолжает обслуживать Интернет, как и прежде.

Уязвимость протокола BGP вынуждает разработки версий, более устойчивых для вторжений. Например, Geoff Huston, “A Survey on Securing Inter-Domain Routing, Part 1 – BGP: Design, Threats and Security Requirements, а также ” The Internet Protocol Journal, Volume 24, No. 3, October 2021.Geoff Huston, "A Survey on Securing Inter-Domain Routing Part 2 – Approaches to Securing BGP", The Internet Protocol Jourmal, V25, N1, p2.