и CISCO. Главная цель BGP
4.4.11.4 Внешний протокол BGP
Семенов Ю.А. (ГНЦ ИТЭФ)
Протокол BGP (RFC-1267, BGP-3; RFC-1268; RFC-1467, BGP-4; -1265-66, 1655) разработан компаниями IBM и CISCO. Главная цель BGP - сократить транзитный трафик. Местный трафик либо начинается, либо завершается в автономной системе (AS); в противном случае - это транзитный трафик. Системы без транзитного трафика не нуждаются в BGP (им достаточно EGP для общения с транзитными узлами). Но не всякая ЭВМ, использующая протокол BGP, является маршрутизатором, даже если она обменивается маршрутной информацией с пограничным маршрутизатором соседней автономной системы. AS передает информацию только о маршрутах, которыми она сама пользуется. BGP-маршрутизаторы обмениваются сообщениями об изменении маршрутов (UPDATE-сообщения, рис. 4.4.11.4.1). Максимальная длина таких сообщений составляет 4096 октетов, а минимальная 19 октетов. Каждое сообщение имеет заголовок фиксированного размера. Объем информационных полей зависит от типа сообщения.
Рис. 4.4.11.4.1. Формат BGP-сообщений об изменениях маршрутов
Поле маркер содержит 16 октетов и его содержимое может легко интерпретироваться получателем. Если тип сообщения "OPEN", или если код идентификации в сообщении open равен нулю, то поле маркер должно быть заполнено единицами. Маркер может использоваться для обнаружения потери синхронизации в работе BGP-партнеров. Поле длина имеет два октета и определяет общую длину сообщения в октетах, включая заголовок. Значение этого поля должно лежать в пределах 19-4096. Поле тип представляет собой код разновидности сообщения и может принимать следующие значения:
| 1 | OPEN | (открыть) |
| 2 | UPDATE | (изменить) |
| 3 | NOTIFICATION | (внимание) |
| 4 | KEEPALIVE | (еще жив) |
Кроме заголовка сообщение open содержит следующие поля (рис. 4.4.11.4.2):
Рис. 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 всегда содержит стандартный заголовок и может содержать другие поля в соответствии со схемой:
Рис. 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) - стандартный обязательный атрибут, который определяет происхождение путевой информации. Генерируется автономной системой, которая является источником маршрутной информации. Значение атрибута в этом случае может принимать следующие значения:
| Код атрибута | Описание |
| 0 | IGP - информация достижимости сетевого уровня является внутренней по отношению к исходной автономной системе; |
| 1 | EGP - информация достижимости сетевого уровня получена с помощью внешнего протокола маршрутизации; |
| 2 | Incomplete - информация достижимости сетевого уровня получена каким-то иным способом. |
| Код типа сегмента | Описание |
| 1 | AS_set: неупорядоченный набор маршрутов в update сообщении; |
| 2 | AS_sequence: упорядоченный набор маршрутов автономной системы в UPDATE-сообщении. |
br>
Длина сегмента пути представляет собой одно-октетное поле, содержащее число 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. Коды ошибок
| Код ошибки | Описание |
| 1 | Ошибка в заголовке сообщения. |
| 2 | Ошибка в сообщении open |
| 3 | Ошибка в сообщении update |
| 4 | Истекло время сохранения |
| 5 | Ошибка машины конечных состояний |
| 6 | Прерывание |
Одно-октетное поле cубкод ошибки предоставляет дополнительную информацию об ошибке. Каждый код ошибки может иметь один или более субкодов. Если поле содержит нуль, это означает, что никаких субкодов не определено.
Таблица 4.4.11.4.2 Субкоды ошибок
| Ошибка | Субкод | Описание |
| Заголовок | 1 2 3 |
Соединение не синхронизовано Неверная длина сообщения Неверный тип сообщения |
| Сообщения OPEN | 1 2 3 4 5 6 |
Неверный код версии Ошибочный код as-партнера Ошибочный идентификатор BGP Ошибка в коде идентификации Ошибка при идентификации Неприемлемое время сохранения |
| Сообщения UPDATE | 1 2 3 4 5 6 7 8 9 10 11 |
Ошибка в списке атрибутов Не узнан стандартный атрибут Отсутствует стандартный атрибут Ошибка в флагах атрибута Ошибка в длине атрибута Неправильный атрибут origin Циклический маршрут Ошибка в атрибуте next_hop Ошибка в опционном атрибуте Ошибка в сетевом поле Ошибка в as_path |
| 1. | ADJ-RIBS-IN: | Запоминает маршрутную информацию, которая получена из update-сообщений. Это список маршрутов, из которого можно выбирать. (policy information base - PIB). |
| 2. | LOC-RIB: | Содержит локальную маршрутную информацию, которую BGP-маршрутизатор отобрал, руководствуясь маршрутной политикой, из ADJ-RIBS-IN. |
| 3. | ADJ-RIBS-OUT: | Содержит информацию, которую локальный BGP-маршрутизатор отобрал для рассылки соседям с помощью UPDATE-сообщений. |
br>
Так как разные BGP- партнеры могут иметь разную политику маршрутизации, возможны осцилляции маршрутов. Для исключения этого необходимо выполнять следующее правило: если используемый маршрут объявлен не рабочим (в процессе корректировки получено сообщение с соответствующим атрибутом), до переключения на новый маршрут необходимо ретранслировать сообщение о недоступности старого всем соседним узлам.
Протокол BGP позволяет реализовать маршрутную политику, определяемую администратором AS (см. раздел ""). Политика отражается в конфигурационных файлах BGP. Маршрутная политика это не часть протокола, она определяет решения, когда место назначения достижимо несколькими путями, политика отражает соображения безопасности, экономические интересы и пр. Количество сетей в пределах одной AS не лимитировано. Один маршрутизатор на много сетей позволяет минимизировать таблицу маршрутов.
BGP использует три таймера:
Connectretry (сбрасывается при инициализации и коррекции; 120 сек),
Holdtime (запускается при получении команд Update или Keepalive; 90сек) и
keepalive (запускается при посылке сообщения Keepalive; 30сек).
BGP отличается от RIP и OSPF тем, что использует TCP в качестве транспортного протокола. Две системы, использующие BGP, связываются друг с другом и пересылают посредством TCP полные таблицы маршрутизации. В дальнейшем обмен идет только в случае каких-то изменений. ЭВМ, использующая 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, которые позволяют группировать маршруты. Структура данных отражается и на схеме принятия решения, которая имеет три фазы:
- Вычисление степени предпочтения для каждого маршрута, полученного от соседней AS, и передача информации другим узлам местной AS.
- Выбор лучшего маршрута из наличного числа для каждой точки назначения и укладка результата в LOC-RIB.
- Рассылка информации из 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. Основу протокола составляет идея бесклассовых адресов, где нет деления между полем сети и полем ЭВМ. Дополнительная информация, например 32-разрядная маска, выделяющая поле адреса сети, передается в рамках протокола маршрутизации. При этом выдерживается строгая иерархия адресов: провайдер > предприятие > отдел/здание > сегмент локальной сети.
Групповой (агрегатный) адрес воспринимается маршрутизатором как один адрес. Группу может образовывать только непрерывная последовательность IP-адресов. Такой бесклассовый интернетовский адрес часто называется IP-префиксом. Так адрес 192.1.1.0/24 означает диапазон адресов 192.1.1.0 - 192.1.1.255, а адрес 192.1.128.0/17 описывает диапазон 192.1.128.0 - 192.1.255.255, таким образом, число, следующее после косой черты, задает количество двоичных разрядов префикса. Это представление используется при описании политики маршрутизации и самих маршрутов (см. разд.4.4.11.4 - ). Для приведенных примеров это в терминах масок выглядит следующим образом:
24 и 17 длины префикса сети.
Следует помнить, что маски с разрывами здесь недопустимы. Ниже приведена таблица метрик маршрутизации для различных протоколов.
| Протокол | Метрика | Диапазон | Код "маршрут недостижим" |
| RIP hello BGP |
Число скачков Задержка в ms Не определена |
0-15 0-29999 0-65534 |
16 30000 65535 |
Рис. 4.4.11.4.4. Пример разных маршрутов для пути "туда" и "обратно".
Предполагается, что оператор находится в ЭВМ-отправителе. Команда traceroute 192.148.166.33 в этом случае выдаст:
| 1 GW-1 | (192.148.166.35) |
| 2 Место назначения | (192.148.166.33) |
| 1 GW-1 | (192.148.166.35) |
| 2 GW-2 | (192.148.166.7) |
| 3 Место назначения | (192.148.165.80) |
| 1 GW-1 | (192.148.166.35) |
| 2 ***** | ; В этом режиме маршрутизатор не откликается |
| 3 Место назначения | (192.148.165.80) |
| 4 GW-1 | (192.148.166.35) |
| 5 ЭВМ-отправитель | (192.148.166.32) |
Из приведенных примеров видна также полезность команды traceroute для понимания того, как движутся пакеты в сети. В некоторых случаях это может помочь оптимизировать маршрутизацию и улучшить пропускную способность сети.
Другой полезной командой является Netstat, которая позволяет получить разнообразную информацию о состоянии сети. Существует четыре модификации этой команды:
-a отображает состояния всех соединений;
-i отображает значения конфигурационных параметров;
-r отображает таблицу маршрутов;
-v отображает статистику обмена локального Ethernet-интерфейса.
Например, команда netstat -r может выдать:
Routing tables (таблицы маршрутизации)
| Destination | Gateway | Flags | Refcnt | Use | Interface |
| Stavropol-GW.ITEP.RU | nb | UGHD | 0 | 109 | le0 |
| ihep.su | itepgw | UGHD | 0 | 103 | le0 |
| m10.ihep.su | itepgw | UGHD | 0 | 16 | le0 |
| 194.85.66.50 | itepgw | UGHD | 0 | 455 | le0 |
| Kharkov.ITEP-Kharkov | nb | UGHD | 0 | 105 | le0 |
| Bryansk-GW.ITEP.Ru | nb | UGHD | 1 | 8113 | le0 |
| 193.124.225.67 | nb | UGHD | 0 | 0 | le0 |
| ixwin.ihep.su | itepgw | UGHD | 1 | 6450 | le0 |
| ihep.su | itepgw | UGHD | 0 | 14 | le0 |
| 192.148.166.21 | nb | UGHD | 0 | 109 | le0 |
| ihep.su | itepgw | UGHD | 0 | 224 | le0 |
| 193.124.225.71 | nb | UGHD | 0 | 10 | le0 |
| 194.85.112.0 | ITEP-FDDI-BBone.ITEP | UGD | 0 | 253 | le0 |
| default | itepgw | UG | 10 | 102497 | le0 |
Базовая команда netstat может обеспечить следующую информацию:
Active Internet connections (активные Интернет связи)
| Proto | Recv-Q | Send-Q | Local Address | Foreign Address | (state) |
| tcp | 0 | 0 | 127.0.0.1.1313 | 127.0.0.1.sunrpc | TIME_WAIT |
| tcp | 0 | 0 | ns.1312 | 193.124.18.65.smtp | SYN_SENT |
| tcp | 0 | 0 | 127.0.0.1.1311 | 127.0.0.1.sunrpc | TIME_WAIT |
| tcp | 0 | 0 | ns.1310 | ns.domain | TIME_WAIT |
| tcp | 0 | 0 | 127.0.0.1.1309 | 127.0.0.1.sunrpc | TIME_WAIT |
| tcp | 39 | 24576 | ns.nntp | Bryansk-GW.ITEP.1697 | ESTABLISHED |
| tcp | 0 | 0 | ns.telnet | semenov.1802 | ESTABLISHED |
| tcp | 0 | 188 | ns.1033 | xmart.desy.de.6000 | ESTABLISHED |
| udp | 0 | 0 | 127.0.0.1.domain | *.* | |
| udp | 0 | 0 | ns.domain | *.* |
| Address | Type | Recv-Q | Send-Q | Vnode | Conn | Refs | Nextref Addr |
| ff64b38c | stream | 0 | 0 | ff13187c | 0 | 0 | 0 /dev/printer |
| ff64b28c | dgram | 0 | 0 | 0 | 0 | 0 | 0 |
| ff64698c | dgram | 0 | 0 | <>ff137fa8 | 0 | 0 | 0 /dev/log |
|