Маршрутные протоколы RIP, OSPF и BGP

8.3. Внешний протокол маршрутизации BGP-4

Протокол BGP (RFC-1267 BGP-3; RFC-1665; RFC-1467 BGP-4; -1771, -1863, -1997, -2439, -2545, -2796, -2858, -2918, -3065, -3107, -3392) разработан компаниями IBM и CISCO. Главная цель BGP — сократить транзитный трафик. Местный трафик либо начинается, либо завершается в автономной системе (AS); в противном случае – это транзитный трафик. Но не всякая ЭВМ, использующая протокол BGP, является маршрутизатором, даже если она обменивается маршрутной информацией с пограничным маршрутизатором соседней автономной системы. AS передает информацию только о маршрутах, которыми она сама пользуется. BGP-маршрутизаторы обмениваются сообщениями об изменении маршрутов (UPDATE-сообщения). Максимальная длина таких сообщений составляет 4096 октетов, а минимальная — 19 октетов. Каждое сообщение имеет заголовок фиксированного размера.

Здесь уместно заметить, что Интернет – это клуб джентльменов. Очень многие узлы пропускают через себя значительный транзитный трафик, который ограничивает возможности непосредственных клиентов узла. Как правило, этот трафик никак не оплачивается. Администраторы могут в рамках протокола BGP существенно ограничить или даже исключить такой транзитный трафик, но они обычно этого не делают, понимая, что их клиенты создают такой же транзитный трафик для других узлов. Эгоистичное поведение администраторов развалило бы сеть Интернет на ряд враждующих феодальных крепостей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. AdjRIBsIn: Запоминает маршрутную информацию, которая получена из UPDATE-сообщений. Это список маршрутов, из которого можно выбирать (Policy Information Base — PIB)
2. LocRIB: Содержит локальную маршрутную информацию, которую BGP-маршрутизатор отобрал, руководствуясь маршрутной политикой, из Adj-RIBs-In
3. AdjRIBsOut: Содержит информацию, которую локальный BGP-маршрутизатор отобрал для рассылки соседям с помощью UPDATE-сообщений

Так как разные 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 позволяет пересылать информацию о маршруте в рамках одного 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-1517, -1518-20) – способ избежать того, чтобы каждая С-сеть требовала свою таблицу маршрутизации. Основополагающий принцип CIDR заключается в группировке (агрегатировании) IP-адресов таким образом, чтобы сократить число входов в таблицах маршрутизации (RFC-1519, RFC-1518, RFC-1467, RFC-1466). Протокол совместим с RIP-2, OSPF и BGP-4.

Основу протокола CIDR составляет идея бесклассовых адресов, где нет деления между полем сети и полем ЭВМ.

Дополнительная информация, например 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, таким образом, число, следующее после косой черты, задает число двоичных разрядов префикса. Это представление используется при описании политики маршрутизации и самих маршрутов.

Обычно предполагается, что при посылке пакета из точки <А> в точку <B> маршруты в одном и другом направлении совпадают. Но это не всегда так. Пример, когда маршруты пакетов туда и обратно не совпадают, представлен на рис. 8.14. В предложенной схеме имеется "ЭВМ-Место назначения" и "ЭВМ-отправитель", а также два маршрутизатора GW-2 и GW-1.

Рис. 8.14. Пример разных маршрутов для пути туда и обратно

Предполагается, что оператор находится в ЭВМ-отправителе. Команда traceroute 192.148.166.33 в этом случае выдаст:

1 GW1					(192.148.166.35)
2 Место назначения		(192.148.166.33)

Команда же traceroute 192.148.165.80 распечатает:

1 GW1					(192.148.166.35)
2 GW2					(192.148.166.7)
3 Место назначения		(192.148.165.80)

Команда traceroute -g 192.148.165.80 сообщит вам:

1 GW1					(192.148.166.35)
2 ***** 			; В этом режиме маршрутизатор не откликается
3 Место назначения		(192.148.165.80)
4 GW1					(192.148.166.35)
5 ЭВМ-отправитель		(192.148.166.32)

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

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

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

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

Конфигурирование BGP требует хорошего понимания его работы. Для облегчения спецификации маршрутной политики на различных уровнях иерархии, например, на уровне автономных систем (AS) был разработан язык описания маршрутной политики RPSL (Routing Policy Specification Language). Теперь низкоуровневые конфигурации маршрутизаторов могут генерироваться на основании спецификаций RPSL. Язык RPSL (см. http://book.itep.ru/4/4/rpsl.htm) является расширяемым и не препятствует внедрению новых протоколов маршрутизации.

Язык RPSL призван заменить язык спецификации маршрутной политики, используемый в настоящее время и описанный в документах RIPE-181 или RFC-1786 RIPE-81 был первым языком, примененным в Интернет для спецификации маршрутных политик. В процессе использования RIPE-181 стало понятно, что некоторые политики не могут быть специфицированы и необходим более совершенный язык.

Язык RPSL был сконструирован так, чтобы описание всей политики маршрутизации записывалось в одну распределенную базу данных, улучшая целостность маршрутизации в Интернет. RPSL не является языком конфигурации маршрутизатора. Язык RPSL сформирован таким образом, чтобы конфигурация маршрутизатора осуществлялась на основе описания маршрутной политики автономной системы (класс aut-num ) в сочетании с описанием маршрутизатора (класс inet-rtr ), которое предоставляет идентификатор маршрутизатора, номер автономной системы, описания интерфейсов и партнеров маршрутизатора. Эти данные используются совместно с глобальной базой данных карты автономных систем (класс as-set ), и информацией об автономных системах отправителях и о маршрутных префиксах (классы route и routeset ).

Язык RPSL является объектно-ориентированным, — то есть, его объекты содержат блоки описания политики и административную информацию. Эти объекты регистрируются в IRR (Internet Routing Registry) авторизованными организациями.