Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Бесплатный конструктор сайтов и Landing Page

Хостинг с DDoS защитой от 2.5$ + Бесплатный SSL и Домен

SSD VPS в Нидерландах под различные задачи от 2.6$

✅ Дешевый VPS-хостинг на AMD EPYC: 1vCore, 3GB DDR4, 15GB NVMe всего за €3,50!

🔥 Anti-DDoS защита 12 Тбит/с!

VPS в 21 локации

От 104 рублей в месяц

Безлимитный трафик. Защита от ДДоС.

🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях

💸 Гифткод CITFORUM (250р на баланс) и попробуйте уже сейчас!

🛒 Скидка 15% на первый платеж (в течение 24ч)

2004 г.

4.4.11.9. Мультипротокольные расширения для BGP-4

Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru

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

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

  2. возможность для заданного протокола сетевого уровня работать с NLRI (Network Layer Reachibility Information).

Чтобы идентифицировать протокол сетевого уровня в данной статье используется понятие семьи адресов (Address Family), как определено в [RFC1700].

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

Чтобы обеспечить обратную совместимость, а также упростить введение мультипротокольных возможностей в BGP-4, в данном документе используются новые атрибуты: многопротокольная NLRI достижимости (MP_REACH_NLRI), и многопротокольная NLRI недостижимости (MP_UNREACH_NLRI). Первый из них (MP_REACH_NLRI) используется для хранения набора достижимых адресатов и данных о следующем шаге, который следует использовать для достижения этих мест назначения. Второй атрибут (MP_UNREACH_NLRI) используется для хранения набора недостижимых адресатов. Таким способом партнер BGP, который не поддерживает мультипротокольные возможности, будет просто игнорировать информацию, содержащуюся в этих атрибутах, и не передаст эти данные другим BGP партнерам.

2. Многопротокольная NLRI достижимости - MP_REACH_NLRI (Код типа 14):

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

(a)

Чтобы оповестить о возможном пути до партнера

(b)

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

(c)

Чтобы позволить данному маршрутизатору уведомить некоторую или все точки подключения к субсети SNPA (Subnetwork Points of Attachment), которые имеются в локальной системе

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

Идентификатор семейства адресов (2 октета)

Идентификатор семейства последующих адресов (1 октет)

Длина сетевого адреса следующего шага (1 октет)

Сетевой адрес следующего шага (переменная длина)

Число SNPA (1 октет)

Длина первого SNPA (1 октет)

Первое SNPA (переменная длина)

Длина второго SNPA (1 октет)

Второе SNPA (переменная длина)

………………………..

Длина последнего SNPA (1 октет)

Последнее SNPA (переменная длина)

Информация о достижимости сетевого уровня (переменная длина)

Использование и значения этих полей описаны ниже:

Идентификатор семейства адресов:

Это поле содержит код протокола сетевого уровня, соответствующего последующему сетевому адресу. Определенные на данный момент значения этого поля специфицированы в RFC 1700 (смотри раздел кодов семейств адресов).

Идентификатор семейства последующих адресов:

Это поле предоставляет дополнительные данные о типе информации достижимости сетевого уровня, содержащейся в атрибуте.

Длина сетевого адреса следующего шаг:

1-октетное поле, значение которого определяет длину поля "Сетевой адрес следующего шага", измеренную в октетах.

Сетевой адрес следующего шага:

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

Число SNPA:

1-октетное поле, которое содержит число SNPA, которые перечислены в последующих полях. Значение 0 может использоваться для индикации отсутствия SNPA в данном атрибуте.

Длина N-го SNPA:

1-октетное поле, чье значение определяет длину поля "N-ый SNPA следующего шага ", выраженную в полуоктетах.

N-ый SNPA следующего шага:

Поле переменной длины, которое содержит SNPA маршрутизатора, чей сетевой адрес размещен в поле "Сетевой адрес следующего шага". Поле длины определяет целое число октетов в длине, точнее округленное до целого значение половины длины SNPA, выраженное в полуоктетах; если SNPA содержит нечетное число полуоктетов, значение этого поля дополняется полуоктетом, заполненным нулями.

Информация о достижимости сетевого уровня:

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

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

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

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

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

Сообщение UPDATE, которое содержит MP_REACH_NLRI должно также содержать атрибуты ORIGIN и AS_PATH (как в EBGP так и в IBGP обменах). Более того, в IBGP-обменах такое сообщение должно также содержать атрибут LOCAL_PREF. Если такое сообщение получено от внешнего партнера, локальная система проверит, является ли самая левая AS в атрибуте AS_PATH автономной системой партнера, пославшего это сообщение. Если это не так, локальная система пошлет сообщение предупреждения (NOTIFICATION) с кодом ошибки UPDATE Message Error, и субкодом ошибки Malformed AS_PATH.

Сообщение UPDATE, которое не содержит NLRI, отличных от записанных в атрибуте MP_REACH_NLRI, не должно нести в себе атрибута NEXT_HOP. Если такое сообщение содержит атрибут NEXT_HOP, BGP-партнер, который получает это сообщение, должен игнорировать этот атрибут.

3. Мультипротокольное NLRI недостижимости - MP _UNREACH_NLRI (Код типа 15):

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

Идентификатор семейства адресов (2 октета)

Идентификатор последующего семейства адресов (1 октет)

Ликвидируемые маршруты (переменная длина)


Использование и значения этих полей представлено ниже:

Идентификатор семейства адресов:

Это поле содержит идентификатор протокола сетевого уровня, ассоциированного с последующим NLRI. В настоящее время, значения, определенные для этого поля, специфицированы в RFC 1700 (смотри раздел коды адресных семейств).

Идентификатор семейства последующих адресов:

Это поле предоставляет дополнительную информацию о типе данных доступности, содержащихся в атрибуте.

Ликвидируемые маршруты:

Поле переменной длины, где перечисляются NLRI для маршрутов, которые отзываются. Когда поле идентификатора семейства последующих адресов соответствует коду, определенному в данном документе, каждое из NLRI кодируется согласно разделу "Кодирование NLRI ".

Сообщение UPDATE, которое содержит MP_UNREACH_NLRI, не обязано нести какие-либо другие атрибуты пути.

4. Кодирование NLRI

Информация достижимости сетевого уровня кодируется в виде одного или более 2-полуоктетов в форме <длина, префикс>, представленной ниже:

Длина (1 октет)

Префикс (переменная длина)

Использование и значения этих полей представлено ниже:

a) Длина:

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

b) Префикс:

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

5. Идентификатор семейства последующих адресов

Этот документ определяет следующие значения для поля идентификатора семейства последующих адресов, содержащегося в атрибутах MP_REACH_NLRI и MP_UNREACH_NLRI:

1 – Информация достижимости сетевого уровня, используемая для уникастной переадресации
2 - Информация достижимости сетевого уровня, используемая для мультикастной переадресации
3 - Информация достижимости сетевого уровня, используемая для уникастной и мультикастной переадресации

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

Если BGP-партнер получает от соседа сообщение Update, которое содержит атрибут MP_REACH_NLRI или MP_UNREACH_NLRI, и партнер определяет, что атрибут некорректен, он должен аннулировать BGP-маршруты, полученные от соседа, чье AFI/SAFI совпадает со значением в некорректном атрибуте MP_REACH_NLRI или MP_UNREACH_NLRI. На время BGP сессии, когда получено сообщение Update, отправитель должен игнорировать все маршруты с AFI/SAFI, полученными в ходе сессии.

Кроме того, партнер может завершить BGP сессию, во время которой получено сообщение Update. Сессия должна быть завершена посылкой сообщения-предупреждения с кодом/субкодом, "Update Message Error "/"Optional Attribute Error" (ошибка сообщения обновления/ошибка опционного атрибута).

7. Использование возможности оповещения в BGP

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

В параметре Опционные возможности содержатся следующие поля. Поле кода возможности устанавливается равным 1 (что указывает на возможность многопротокольных расширений). Поле длины возможностей устанавливается равным 4. Формат поля возможностей представлен ниже:
0 7 15 23 31
AFI Резерв SAFI

Использование и значение полей:

AFI

Идентификатор семейства адресов (16 бит), представленный также как в мультипротокольном расширении

Резерв

Зарезервированное поле (8 бит). Должно быть установлено равным 0 отправителем и игнорироваться получателем.

SAFI

Идентификатор семейства последующих адресов (8 бит), кодируется также как и в мультипротокольных расширениях

Партнер, который поддерживает множественные комбинации полубайтов <AFI, SAFI>, включает их как множественные возможности в параметр опционных возможностей.

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

8. Соображения IANA

Как специфицировано в данном документе, атрибуты MPL_REACH_NLRI и MP_UNREACH_NLRI содержат поле SAFI (Subsequence Address Family Identifier). Пространство имен SAFI определено в разделе 9. IANA будет поддерживать и регистрировать значения для пространства имен SAFI следующим образом. Значение SAFI = 0 зарезервировано. Значения SAFI 1, 2 и 3 определены в данном документе. Значения SAFI от 4 до 63 должны быть определены IANA на основе политики "IETF согласия", определенной в RFC 2434. Значения SAFI от 64 до 127 должны будут определены IANA, используя принцип " First Come First Served" (первым пришел – первым обслужен), описанный в RFC 2434. Значения SAFI от 128 до 255 предназначены для частного использования и не будут присваиваться IANA.

9. Сравнение с RFC 2283

Данный документ ограничивает использование атрибута MP_REACH_NLRI только случаем <AFI, SAFI, информация следующего шага, ...>.

Данный документ ограничивает применение атрибута MP_UNREACH_NLRI только случаем <AFI, SAFI, ...>.

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

Этот документ разъясняет обработку ошибок в присутствии атрибутов MP_REACH_NLRI или MP_ UNREACH_NLRI.

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

10. Ссылки

[BGP-CAP]

Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 2842, May 2000.

[BGP-4]

Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.

[Heffernan]

Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.

[IPv4]

Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

[RFC1700]

Postel, J. and J. K. Reynolds, "Assigned Numbers", STD 2, RFC 1700, October 1994. (see also http://www.iana.org/iana/assignments.html)

Назад: 4.4.11.8. Язык описания маршрутной политики RPSL
Оглавление: Телекоммуникационные технологии
Вперёд: 4.4.12. DNS (структура, обработка запросов, ресурсные записи)

Скидка до 20% на услуги дата-центра. Аренда серверной стойки. Colocation от 1U!

Миграция в облако #SotelCloud. Виртуальный сервер в облаке. Выбрать конфигурацию на сайте!

Виртуальная АТС для вашего бизнеса. Приветственные бонусы для новых клиентов!

Виртуальные VPS серверы в РФ и ЕС

Dedicated серверы в РФ и ЕС

По промокоду CITFORUM скидка 30% на заказ VPS\VDS

VPS/VDS серверы. 30 локаций на выбор

Серверы VPS/VDS с большим диском

Хорошие условия для реселлеров

4VPS.SU - VPS в 17-ти странах

2Gbit/s безлимит

Современное железо!

Новости мира IT:

Архив новостей

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 495 7861149
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2019 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...