Протокол пограничного шлюза

Протокол пограничного шлюза
Протокол связи
	Конечный автомат BGP
Сокращение	BGP
Цель	обмениваться интернет-протокола информацией о маршрутизации
Введение	1 июня 1989 г .; 35 лет назад
На основе	египетский фунт
Уровень OSI	Прикладной уровень
Порт(ы)	TCP/179
RFC(ы)	§ Стандартные документы

Протокол пограничного шлюза ( BGP ) — это стандартизированный протокол внешнего шлюза , предназначенный для обмена информацией о маршрутизации и доступности между автономными системами (AS) в Интернете . ^[2] BGP классифицируется как протокол маршрутизации на основе вектора пути . ^[3] и он принимает решения о маршрутизации на основе путей, сетевых политик или наборов правил, настроенных сетевым администратором .

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

История [ править ]

Протокол пограничных ворот был набросан инженерами в 1989 году на обратной стороне «трех салфеток, испачканных кетчупом», и до сих пор известен как протокол трех салфеток . ^[4] Впервые он был описан в 1989 году в RFC 1105 и используется в Интернете с 1994 года. ^[5] IPv6 BGP был впервые определен в RFC 1654 в 1994 году, и он был улучшен до RFC 2283 в 1998 году.

Текущей версией BGP является версия 4 (BGP4), которая впервые была опубликована как RFC 1654 in 1994, subsequently updated by RFC 1771 in 1995 and RFC 4271 в 2006 году. ^[6]В RFC 4271 исправлены ошибки, разъяснены неясности и обновлена спецификация с учетом общепринятых отраслевых практик. Основным усовершенствованием BGP4 стала поддержка бесклассовой междоменной маршрутизации (CIDR) и использование агрегации маршрутов для уменьшения размера таблиц маршрутизации . RFC 4271 позволяет BGP4 поддерживать широкий спектр IPv4 и IPv6 «семейств адресов» . Его также называют многопротокольными расширениями, то есть многопротокольным BGP (MP-BGP).

Операция [ править ]

Соседи BGP, называемые одноранговыми узлами, устанавливаются среди маршрутизаторов путем ручной настройки для создания сеанса TCP на порту 179. Узел BGP отправляет 19-байтовые сообщения проверки активности каждые 30 секунд (значение протокола по умолчанию, настраиваемое) для поддержания соединения. ^[7] Среди протоколов маршрутизации BGP уникален тем, что в качестве транспортного протокола используется TCP.

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

Основное различие между пирингом iBGP и eBGP заключается в том, как маршруты, полученные от одного узла, обычно по умолчанию передаются другим узлам:

Новые маршруты, полученные от узла eBGP, повторно объявляются всем узлам iBGP и eBGP.
Новые маршруты, полученные от узла iBGP, повторно объявляются только всем узлам eBGP.

Эти правила распространения маршрутов фактически требуют, чтобы все одноранговые узлы iBGP внутри AS были соединены в полносвязной сети с сеансами iBGP.

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

Переговоры о расширениях [ править ]

Во время пирингового установления связи, когда происходит обмен сообщениями OPEN, узлы BGP могут согласовывать дополнительные возможности сеанса. ^[8] включая многопротокольные расширения ^[9]и различные режимы восстановления. Если многопротокольные расширения BGP согласовываются во время создания, узел BGP может префикс информации о доступности сетевого уровня (NLRI), которую он объявляет, префиксом семейства адресов. Эти семейства включают IPv4 (по умолчанию), IPv6, виртуальные частные сети IPv4/IPv6 и многоадресную рассылку BGP. BGP все чаще используется в качестве обобщенного протокола сигнализации для передачи информации о маршрутах, которые могут не быть частью глобального Интернета, например о VPN. ^[10]

Для принятия решений в своих операциях с узлами узел BGP использует простой конечный автомат (FSM), который состоит из шести состояний: режим ожидания; Соединять; Активный; ОпенСент; ОткрытьПодтвердить; и Установлен. Для каждого однорангового сеанса реализация BGP поддерживает переменную состояния, которая отслеживает, в каком из этих шести состояний находится сеанс. BGP определяет сообщения, которыми должен обмениваться каждый одноранговый узел, чтобы перевести сеанс из одного состояния в другое.

Первое состояние — это состояние ожидания. В состоянии ожидания BGP инициализирует все ресурсы, отклоняет все входящие попытки подключения BGP и инициирует TCP-соединение с одноранговым узлом. Второе состояние — Connect. В состоянии Connect маршрутизатор ожидает завершения TCP-соединения и в случае успеха переходит в состояние OpenSent. В случае неудачи он запускает таймер ConnectRetry и переходит в активное состояние по истечении срока действия. В активном состоянии маршрутизатор сбрасывает таймер ConnectRetry на ноль и возвращается в состояние Connect. В состоянии OpenSent маршрутизатор отправляет сообщение Open и ожидает его в ответ, чтобы перейти в состояние OpenConfirm. Происходит обмен сообщениями Keepalive, и после успешного получения маршрутизатор переходит в состояние «Установлено». В состоянии «Установлено» маршрутизатор может отправлять и получать: Keepalive; Обновлять; и уведомительные сообщения своему партнеру и от него.

Состояние ожидания :
- Отклонить все входящие соединения BGP.
- Запустите инициализацию триггеров событий.
- Инициирует TCP-соединение со своим настроенным узлом BGP.
- Прослушивает TCP-соединение от своего узла.
- Меняет свое состояние на Connect.
- Если ошибка возникает в любом состоянии процесса FSM, сеанс BGP немедленно завершается и возвращается в состояние ожидания. Некоторые из причин, по которым маршрутизатор не выходит из состояния ожидания:
  - TCP-порт 179 не открыт.
  - Случайный TCP-порт более 1023 не открыт.
  - Одноранговый адрес настроен неправильно на любом маршрутизаторе.
  - Номер AS настроен неправильно на любом маршрутизаторе.
Состояние подключения :
- Ожидает успешного TCP-согласования с партнером.
- BGP не проводит много времени в этом состоянии, если сеанс TCP успешно установлен.
- Отправляет сообщение Open партнеру и меняет состояние на OpenSent.
- В случае возникновения ошибки BGP переходит в активное состояние. Некоторые причины ошибки:
  - TCP-порт 179 не открыт.
  - Случайный TCP-порт более 1023 не открыт.
  - Одноранговый адрес настроен неправильно на любом маршрутизаторе.
  - Номер AS настроен неправильно на любом маршрутизаторе.
Активное состояние :
- Если маршрутизатору не удалось установить успешный TCP-сеанс, он переходит в активное состояние.
- BGP FSM пытается перезапустить другой сеанс TCP с узлом и в случае успеха отправляет узлу сообщение Open.
- Если попытка снова окажется неудачной, FSM сбрасывается в состояние ожидания.
- Повторяющиеся сбои могут привести к циклическому переключению маршрутизатора между состояниями ожидания и активности. Некоторые из причин этого включают в себя:
  - TCP-порт 179 не открыт.
  - Случайный TCP-порт более 1023 не открыт.
  - Ошибка конфигурации BGP.
  - Перегрузка сети.
  - Болтающийся сетевой интерфейс.
Состояние OpenSent :
- BGP FSM прослушивает сообщение Open от своего узла.
- После получения сообщения маршрутизатор проверяет достоверность сообщения Open.
- Если возникает ошибка, то это связано с тем, что одно из полей в сообщении «Открыть» не совпадает между узлами, например, несоответствие версии BGP, пиринговый маршрутизатор ожидает другой My AS и т. д. Затем маршрутизатор отправляет узлу сообщение уведомления. с указанием причины возникновения ошибки.
- Если ошибок нет, отправляется сообщение Keepalive, устанавливаются различные таймеры и состояние меняется на OpenConfirm.
Состояние OpenConfirm :
- Узел прослушивает сообщение Keepalive от своего узла.
- Если получено сообщение Keepalive и до получения сообщения Keepalive не истекло время таймера, BGP переходит в состояние «Установлено».
- Если время таймера истекает до получения сообщения Keepalive или возникает ошибка, маршрутизатор возвращается в состояние ожидания.
Основанное государство :
- В этом состоянии узлы отправляют сообщения обновления для обмена информацией о каждом маршруте, рекламируемом узлу BGP.
- Если в сообщении обновления есть какая-либо ошибка, одноранговому узлу отправляется сообщение уведомления, и BGP возвращается в состояние ожидания.

Подключение к маршрутизатору и изучение маршрутов [ править ]

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

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

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

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

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

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

Процесс выбора маршрута [ править ]

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

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

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

Пока существует тай-брейк, процесс выбора маршрута переходит к следующему этапу.

Шаги для определения лучшего пути в порядке тай-брейка : ^[11] ^[12]
Шаг	Объем	Имя	По умолчанию	Предпочтительный	Поле BGP	ПРИМЕЧАНИЕ
1	Локально для маршрутизатора	местный вес	"Выключенный"	Выше		Специфический для Cisco параметр
2	Внутренний для AS	Местные предпочтения	«Выкл.», все установлено на 100.	Выше	LOCAL_PREF	Если от соседа существует несколько маршрутов iBGP, выбирается тот, который имеет наивысшее локальное предпочтение, если только нет нескольких маршрутов с одинаковым локальным предпочтением.
3	Внутренний для AS	Протокол накопленного внутреннего шлюза (AIGP)	"Выключенный"	Самый низкий	АИГП	rfc7311
4	Внешний для AS	Автономная система (АС) прыгает	«Вкл.», пропускается, если игнорируется в конфигурации.	Самый низкий	AS-путь	Переходы AS — это количество номеров AS, которые необходимо пройти, чтобы достичь объявленного пункта назначения. AS1–AS2–AS3 — более короткий путь с меньшим количеством переходов, чем AS4–AS5–AS6–AS7.
5		тип происхождения	"ИГП"	Самый низкий	ИСТОЧНИК	0 = ИГП 1 = египетский фунт 2 = Неполный
6		многовыходной дискриминатор (MED)	«включено», импортировано из IGP	Самый низкий	MULTI_EXIT_DISC	По умолчанию сравнивается только маршрут с одной и той же автономной системой (АС). Можно настроить игнорирование той же автономной системы (AS). По умолчанию внутренний IGP не добавляется. Можно настроить добавление метрики IGP. До появления самой последней редакции стандарта BGP, если обновление не имело значения MED, в некоторых реализациях создавалось MED с максимально возможным значением. Действующий стандарт определяет, что отсутствующие MED рассматриваются как минимально возможное значение. Поскольку текущее правило может вызывать поведение, отличное от интерпретации поставщика, реализации BGP, в которых использовалось нестандартное значение по умолчанию, имеют функцию конфигурации, позволяющую выбрать старое или стандартное правило.
7	Локально для маршрутизатора (Loc-RIB)	eBGP через пути iBGP	"на"			Связано напрямую, а не косвенно
8		Метрика IGP для следующего перехода BGP	«включено», импортировано из IGP	Самый низкий		Продолжайте, даже если лучший путь уже выбран. Предпочитайте маршрут с наименьшими внутренними затратами следующему переходу в соответствии с основной таблицей маршрутизации. Если два соседа объявили один и тот же маршрут, но один сосед доступен по каналу с низкой скоростью передачи данных, а другой — по каналу с высокой скоростью передачи данных, а протокол внутренней маршрутизации вычисляет наименьшую стоимость на основе наивысшей скорости передачи данных, маршрут через канал с высокой скоростью передачи данных будет предпочтительнее, а другие маршруты будут исключены.
9		Путь, который был получен первым	"на"	самый старый		Используется для игнорирования изменений на шагах 10+.
10		Идентификатор маршрутизатора	"на"	Самый низкий
11		Длина списка кластеров	"на"	Самый низкий
12		Адрес соседа	"на"	Самый низкий

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

Сообщества [ править ]

Сообщества BGP — это теги атрибутов, которые можно применять к входящим или исходящим префиксам для достижения какой-либо общей цели. ^[13]Хотя принято говорить, что BGP позволяет администратору устанавливать политику обработки префиксов интернет-провайдерами, на самом деле это, строго говоря, невозможно. Например, в BGP изначально не предусмотрена концепция, позволяющая одной AS сообщать другой AS ограничить рекламу префикса только клиентам пирингового узла в Северной Америке. Вместо этого интернет-провайдер обычно публикует список известных или частных сообществ с описанием каждого из них, что, по сути, становится соглашением о том, как следует обращаться с префиксами.

Известные сообщества BGP ^[14]
Значение атрибута	Атрибут	Описание	Ссылка
0x00000000-0x0000FFFF	Сдержанный		РФК 1997 г.
0x00010000-0xFFFEFFFF	Зарезервировано для частного использования		РФК 1997 г.
0xFFFF0000	GRACEFUL_SHUTDOWN	На соседнем AS-peer установите LOCAL_PREF, меньшее значение для маршрутизации от источника.	RFC 8326
0xFFFF0001	ACCEPT_OWN	Используется для изменения способа импорта маршрута, созданного в одном VRF, в другие VRF.	RFC 7611
0xFFFF0002	ROUTE_FILTER_TRANSLATED_v4		Проект RFC-l3vpn-legacy-rtc
0xFFFF0003	ROUTE_FILTER_v4		Проект RFC-l3vpn-legacy-rtc
0xFFFF0004	ROUTE_FILTER_TRANSLATED_v6		Проект RFC-l3vpn-legacy-rtc
0xFFFF0005	ROUTE_FILTER_v6		Проект RFC-l3vpn-legacy-rtc
0xFFFF0006	ЛЛГР_СТАЛЕ		Черновик RFC-uttaro-idr-bgp-persistence
0xFFFF0007	НЕТ_LLGR		Черновик RFC-uttaro-idr-bgp-persistence
0xFFFF0008	принять-собственный-следующий		Черновик RFC-agrewal-idr-accept-own-nexthop
0xFFFF0009	Резервный PE	Обеспечьте более быстрое восстановление подключения при различных типах сбоев с помощью многоадресной рассылки в VPN BGP/MPLS.	RFC 9026
0xFFFF000A-0xFFFF0299	Неназначенный
0xFFFF029A	ЧЕРНАЯ ДЫРА	Для временной защиты от атаки типа «отказ в обслуживании» путем включения черной дыры на соседнем AS-узле.	РФК 7999
0xFFFF029B-0xFFFFFF00	Неназначенный
0xFFFFFF01	NO_EXPORT	ограничение границы конфедерации BGP	РФК 1997 г.
0xFFFFFF02	НЕТ_РЕКЛАМА	ограничение для узла BGP	РФК 1997 г.
0xFFFFFF03	NO_EXPORT_SUBCONFED	предел автономной системы	РФК 1997 г.
0xFFFFFF04	НЕТ	ограничить количество конкретных маршрутов для всего Интернета. Для многодомных AS, у которых есть 2 или более соседей, которым нравится балансировать нагрузку, где они будут указывать более подробный маршрут.	RFC 3765
0xFFFFFF05-0xFFFFFFFF	Неназначенный

Примеры общих сообществ включают в себя:

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

Интернет-провайдер может заявить, что любые маршруты, полученные от клиентов, со следующими примерами:

Клиентам Северная Америка (Восточное побережье) 3491:100
Клиентам Северная Америка (Западное побережье) 3491:200

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

Конечные клиенты обычно используют сообщества BGP (обычно ASN:70,80,90,100) для управления локальными предпочтениями, которые интернет-провайдер назначает рекламируемым маршрутам вместо использования MED (эффект аналогичен). Атрибут сообщества является транзитивным, но сообщества, применяемые клиентом, очень редко распространяются за пределы AS следующего перехода. Не все интернет-провайдеры предоставляют свои сообщества публике. ^[17]

Расширенный атрибут сообщества BGP [ править ]

Атрибут расширенного сообщества BGP был добавлен в 2006 году. ^[18]с целью расширения диапазона таких атрибутов и обеспечения структурирования атрибутов сообщества посредством поля типа. Расширенный формат состоит из одного или двух октетов для поля типа, за которыми следуют семь или шесть октетов для соответствующего содержимого атрибута сообщества. Определение этого расширенного атрибута сообщества задокументировано в RFC 4360. IANA администрирует реестр типов расширенных сообществ BGP. ^[19]Атрибут Extended Communities сам по себе является транзитивным необязательным атрибутом BGP. Бит в поле типа внутри атрибута определяет, имеет ли закодированное расширенное сообщество транзитивный или нетранзитивный характер. Поэтому реестр IANA предоставляет разные диапазоны номеров для типов атрибутов. Благодаря расширенному диапазону атрибутов его использование может быть разнообразным. RFC 4360 в качестве примера определяет «двуоктетное расширенное сообщество, специфичное для AS», «расширенное сообщество, специфичное для адреса IPv4», «непрозрачное расширенное сообщество», «целевое сообщество маршрута» и «сообщество источника маршрута». В ряде проектов BGP QoS также используется структура расширенного атрибута сообщества для междоменной сигнализации QoS. ^[20]

С введением 32-битных номеров AS сразу стали очевидны некоторые проблемы с атрибутом сообщества, который определяет только 16-битное поле ASN, что предотвращает сопоставление между этим полем и реальным значением ASN. Начиная с RFC 7153, расширенные сообщества совместимы с 32-битными ASN. RFC 8092 и RFC 8195 вводят атрибут Large Community длиной 12 байт, разделенный на три поля по 4 байта каждое (AS:function:parameter). ^[21]

Дискриминаторы с несколькими выходами [ править ]

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

Некоторые маршрутизаторы (например, Juniper) используют метрику из OSPF для установки MED.

Примеры использования MED с BGP при экспорте в BGP на Juniper SRX

#  run   show   ospf   маршрут     
 Топология по умолчанию Таблица маршрутов: 
 Префикс Путь Маршрут NH Метрика Следующий переход Следующий переход 
 Тип Тип Интерфейс Адрес/LSP 
 10.32.37.0/24 Inter Discard IP 16777215 
 10.32.37.0/26 Внутрисетевой IP 101 ge-0/0/1.0 10.32 .37.241 
 10.32.37.64/26 Внутрисетевой IP 102 ge-0/0/1.0 10.32.37.241 
 10.32.37.128/26 Внутрисетевой IP 101 ge-0/0/1.0 10.32.37.241 

 #  show   Route   рекламный протокол   bgp   10  .32.94 .169 
    Префикс Nexthop MED Lclpref AS путь 
 * 10.32.37.0/24 Self 16777215 I 
 * 10.32.37.0/26 Self 101 I 
 * 10.32.37.64/26 Self 102 I 
 * 10.32.37.128/26 Self 101 I

Формат пакета [ править ]

Формат заголовка сообщения [ править ]

Формат заголовка сообщения BGP версии 4 ^[22]
битовое смещение	0–15	16–23
0	Маркер (всегда: ff ff ff ff ff ff ff ff ff ff ff ff ff ff)
32
64
96
128	Длина	Тип

Маркер : включен для совместимости, должен быть установлен для всех.
Длина : общая длина сообщения в октетах , включая заголовок.
Тип : Тип сообщения BGP. Определены следующие значения:
- Открыть (1)
- Обновление (2)
- Уведомление (3)
- KeepAlive (4)
- Маршрут-Обновление (5)

Примечание. «Маркер» и «Длина» в примерах опущены.

Открытый пакет [ править ]

Версия (8бит): Используемая версия BGP.
Моя AS (16 бит): отправителя Номер автономной системы .
Время удержания (16 бит): Таймер тайм-аута, используемый для расчета сообщений KeepAlive. По умолчанию 90 секунд.
Идентификатор BGP (32-битный): IP-адрес отправителя.; Длина дополнительных параметров (8 бит): общая длина поля дополнительных параметров.

Пример открытого сообщения

Тип: Открытое сообщение (1) 
  Версия: 4 
  Мой АС: 64496 
  Время удержания: 90 
  Идентификатор BGP:  192.0.2.254 
  Дополнительные параметры Длина: 16 
  Дополнительные параметры:  
   Возможности: возможность расширения нескольких протоколов (1) 
   Возможности: возможность обновления маршрута (2) 
   Возможности: возможность обновления маршрута (Cisco) (128)

Пакет обновления [ править ]

Отправляются только изменения, после первоначального обмена отправляются только различия (добавление/изменение/удаление).

Пример сообщения ОБНОВЛЕНИЕ

Тип: Сообщение ОБНОВЛЕНИЕ (2) 
  Длина отозванных маршрутов: 0 
  Общая длина атрибута пути: 25 
  Атрибуты пути 
   ПРОИСХОЖДЕНИЕ: IGP 
   AS_PATH: 64500 
   СЛЕДУЮЩИЙ_ХОП: 192.0.2.254 
   MULTI_EXIT_DISC: 0 
  Информация о доступности сетевого уровня (NLRI) 
   192.0.2.0/27 
  192.0.2.32/27 
  192.0.2.64/27

Уведомление [ править ]

Если возникает ошибка, то это связано с тем, что одно из полей в сообщении OPEN или UPDATE не совпадает между узлами, например, несоответствие версии BGP, пиринговый маршрутизатор ожидает другой My AS и т. д. Затем маршрутизатор отправляет сообщение уведомления на узел, указывающий причину возникновения ошибки.

Коды ошибок
Error Code	Name	subcodes
Error Code	Name	Code	Name
1	Message Header Error	1	Connection Not Synchronized
		2	Bad Message Length
		3	Bad Message Type
2	OPEN Message Error	1	Unsupported Version Number.
		2	Bad Peer AS.
		3	Bad BGP Identifier.
		4	Unsupported Authentication Code.
		5	Authentication Failure.
		6	Unacceptable Hold Time.
3	UPDATE Message Error	1	Malformed Attribute List.
		2	Unrecognized Well-known Attribute.
		3	Missing Well-known Attribute.
		4	Attribute Flags Error.
		5	Attribute Length Error.
		6	Invalid ORIGIN Attribute
		7	AS Routing Loop.
		8	Invalid NEXT_HOP Attribute.
		9	Optional Attribute Error.
		10	Invalid Network Field.
		11	Malformed AS_PATH.
4	Hold Timer Expired
5	Finite State Machine Error
6	Cease

Пример сообщения УВЕДОМЛЕНИЯ

Тип: УВЕДОМЛЕНИЕ (3)
 Код основной ошибки: Ошибка сообщения OPEN (2)
 Код незначительной ошибки (открытое сообщение): Bad Peer AS (2)
 Плохой партнер AS: 65200

KeepAlive [ править ]

Сообщения KeepAlive отправляются периодически, чтобы убедиться, что удаленный узел все еще активен. сообщения Keepalive должны отправляться с интервалом в одну треть holdtime.

Пример сообщения KEEPALIVE

Тип: Сообщение KEEPALIVE (4)

Маршрут-Обновить [ править ]

Определено в RFC 7313 .

Позволяет мягко обновлять Adj-RIB-in, без сброса соединения.

Пример сообщения ROUTE-REFRESH

Тип: Сообщение ROUTE-REFRESH (5)
 Идентификатор семейства адресов (AFI): IPv4 (1)
 Подтип: Обычный запрос на обновление маршрута [RFC2918] с ORF или без него [RFC5291] (0)
 Последующий идентификатор семейства адресов (SAFI): Одноадресная рассылка (1)

Внутренняя масштабируемость [ править ]

BGP — «наиболее масштабируемый из всех протоколов маршрутизации». ^[23]

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

Отражатели маршрута [ править ]

Отражатели маршрутов (RR) уменьшают количество соединений, необходимых в AS. Один маршрутизатор (или два для резервирования) можно сделать RR: другие маршрутизаторы в AS необходимо только настроить как равноправные по отношению к ним. RR предлагает альтернативу логическому полносвязному требованию iBGP. Цель RR – концентрация. Несколько маршрутизаторов BGP могут взаимодействовать с центральной точкой, RR, действующей как сервер RR, а не с каждым другим маршрутизатором в полной ячеистой сети. Все остальные маршрутизаторы iBGP становятся клиентами RR. ^[24]

Этот подход, аналогичный функции DR/BDR OSPF , обеспечивает крупным сетям дополнительную масштабируемость iBGP. В полностью объединенной сети iBGP из 10 маршрутизаторов 90 отдельных операторов CLI (распределенных по всем маршрутизаторам в топологии) необходимы только для определения удаленного AS каждого узла: управление этим быстро становится головной болью. Топология RR может сократить эти 90 операторов до 18, предлагая жизнеспособное решение для более крупных сетей, администрируемых интернет-провайдерами.

RR — это единственная точка отказа , поэтому для обеспечения резервирования можно настроить как минимум второй RR. Поскольку он является дополнительным партнером для остальных 10 маршрутизаторов, он примерно удваивает количество операторов CLI, требуя дополнительных 11 × 2 − 2 = 20 в этом случае операторов. В многопутевой среде BGP дополнительный RR также может принести пользу сети, увеличивая пропускную способность локальной маршрутизации, если RR действуют как традиционные маршрутизаторы, а не просто в роли выделенного сервера RR.

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

Правила [ править ]

Серверы RR распространяют маршруты внутри AS на основе следующих правил:

Маршруты всегда передаются узлам eBGP.
Маршруты никогда не отражаются для создателя маршрута.
Если маршрут получен от узла, не являющегося клиентом, отразите его на узлах-клиентах.
Если маршрут получен от клиентского узла, отразите его на клиентских и неклиентских узлах.

Кластер [ править ]

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

Конфедерация [ править ]

Конфедерации представляют собой наборы автономных систем. В обычной практике ^[25]только один из номеров AS конфедерации виден Интернету в целом. Конфедерации используются в очень больших сетях, где большую AS можно настроить так, чтобы она включала в себя более мелкие и более управляемые внутренние AS.

Конфедеративная AS состоит из нескольких AS. Каждая конфедеративная AS имеет полностью объединенную сеть iBGP и имеет соединения с другими AS внутри конфедерации. Несмотря на то, что эти AS имеют одноранговые узлы eBGP с AS внутри конфедерации, AS обмениваются маршрутизацией, как если бы они использовали iBGP. Таким образом, конфедерация сохраняет информацию о следующем переходе, метрике и локальных предпочтениях. Внешнему миру конфедерация кажется единой AS. С помощью этого решения можно решить проблемы транзитной AS iBGP, поскольку iBGP требует полной сетки между всеми маршрутизаторами BGP: большого количества сеансов TCP и ненужного дублирования маршрутизируемого трафика. ^{[ нужны разъяснения ]}

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

Эти альтернативы могут создавать собственные проблемы, в том числе следующие:

колебание маршрута
неоптимальная маршрутизация
увеличение времени конвергенции BGP ^[27]

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

Стабильность [ править ]

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

Функция, известная как демпфирование закрылков маршрута ( RFC 2439 ) встроен во многие реализации BGP в попытке смягчить последствия изменения маршрута. Без демпфирования чрезмерная активность может вызвать большую нагрузку на маршрутизаторы, что, в свою очередь, может задержать обновления на других маршрутах и, таким образом, повлиять на общую стабильность маршрутизации. При демпфировании колебания маршрута экспоненциально затухают . В первый раз, когда маршрут становится недоступным и быстро появляется снова, демпфирование не вступает в силу, чтобы поддерживать нормальное время переключения при сбое BGP. Во втором случае BGP игнорирует этот префикс в течение определенного периода времени; последующие появления игнорируются экспоненциально дольше. После того, как аномалии прекратились и прошел подходящий период времени для нарушающего маршрута, префиксы можно восстановить с чистого листа. Демпфирование также может смягчить атаки типа «отказ в обслуживании» .

Это также предлагается в RFC 2439. ^{: Раздел 4}что демпфирование колебаний маршрута является более желательной функцией, если оно реализовано в сеансах протокола внешнего пограничного шлюза (сеансы eBGP или просто называемые внешними узлами), а не во внутренних сеансах протокола пограничного шлюза (сеансы iBGP или просто называемые внутренними узлами). При таком подходе, когда маршрут меняется внутри автономной системы, он не распространяется на внешние AS — изменение маршрута к eBGP вызовет цепочку изменений для конкретного маршрута по всей магистральной сети. Этот метод также успешно позволяет избежать накладных расходов на демпфирование колебаний маршрута для сеансов iBGP.

Последующие исследования показали, что в некоторых случаях демпфирование колебаний может фактически увеличить время конвергенции и вызвать прерывания соединения, даже если каналы не колеблются. ^[28]^[29] Более того, поскольку магистральные каналы и процессоры маршрутизаторов стали быстрее, некоторые сетевые архитекторы предположили, что демпфирование колебаний может быть не таким важным, как раньше, поскольку изменения в таблице маршрутизации могут обрабатываться маршрутизаторами гораздо быстрее. ^[30] Это привело к тому, что Рабочая группа по маршрутизации RIPE написала: «При нынешних реализациях флэш-демпфирования BGP применение флэш-демпфирования в сетях интернет-провайдеров НЕ рекомендуется. - последствия для их клиентов и интернет-пользователей контента и услуг их клиентов... Эти побочные эффекты, скорее всего, будут хуже, чем воздействие, вызванное просто отсутствием демпфирования закрылков вообще». ^[31] Улучшение устойчивости без проблем с демпфированием закрылков является предметом текущих исследований. ^[32]^{[ нужно обновить ]}

таблицы маршрутизации Рост

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

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

512 тыс. дней [ править ]

обновлены . В 2014 году произошло переполнение, подобное Y2K, для тех моделей, которые не были должным образом

Полная таблица IPv4 BGP по состоянию на август 2014 г. ^[update] (512 тыс. дней) ^[33]^[34] превышало 512 000 префиксов, ^[35] у многих старых маршрутизаторов было ограничение 512 КБ (512 000–524 288). ^[36]^[37]записи таблицы маршрутизации. 12 августа 2014 г. сбои в работе, вызванные переполнением таблиц, затронули, eBay , LastPass и Microsoft Azure . в частности, ^[38]Ряд широко используемых маршрутизаторов Cisco имели TCAM , разновидность высокоскоростной памяти с адресацией по содержимому , для хранения объявленных маршрутов BGP. На затронутых маршрутизаторах TCAM по умолчанию распределялся как 512 тыс. маршрутов IPv4 и 256 тыс. маршрутов IPv6. Хотя заявленное количество объявленных маршрутов IPv6 составляло всего около 20 тысяч, количество рекламируемых маршрутов IPv4 достигло предела по умолчанию, что вызвало побочный эффект , поскольку маршрутизаторы пытались компенсировать проблему, используя медленную программную маршрутизацию (в отличие от быстрой аппаратной маршрутизации через TCAM). ). Основной метод решения этой проблемы заключается в том, что операторы изменяют распределение TCAM, чтобы разрешить больше записей IPv4, путем перераспределения части TCAM, зарезервированной для маршрутов IPv6, что требует перезагрузки на большинстве маршрутизаторов. Проблема 512k была предсказана рядом ИТ-специалистов. ^[39]^[40]^[41]

Фактическим распределением, которое привело к увеличению количества маршрутов выше 512 тыс., стало объявление около 15 000 новых маршрутов в короткие сроки, начиная с 07:48 UTC. Почти все эти маршруты были направлены к Verizon Autonomous Systems 701 и 705, созданные в результате дезагрегации более крупных блоков, введения тысяч новых / 24 маршрутов и доведения таблицы маршрутизации до 515 000 записей. Новые маршруты, судя по всему, были объединены в течение 5 минут, но нестабильность в Интернете, судя по всему, сохранялась в течение нескольких часов. ^[42] Даже если бы Verizon не стал причиной превышения таблицы маршрутизации 512 тысяч записей во время короткого всплеска, это вскоре произошло бы в результате естественного роста.

Суммирование маршрутов часто используется для улучшения агрегации глобальной таблицы маршрутизации BGP, тем самым уменьшая необходимый размер таблицы в маршрутизаторах AS. что AS1 выделено большое адресное пространство 172.16.0.0/16 172.16.0.0 Предположим , , это будет считаться одним маршрутом в таблице, но из-за требований клиента или в целях организации трафика AS1 хочет анонсировать меньшие и более конкретные маршруты . / 18 , 172.16.64.0/18 и 172.16.128.0/18   . Префикс 172.16.192.0/18 не объявляет имеет хостов, поэтому AS1 не 172.16.192.0/18 маршрут конкретный . Все это считается объявлением AS1 четырех маршрутов.

четыре маршрута от AS1 ( 172.16.0.0/18 и 172.16.128.0/18 , 172.16.64.0/18 политика , и 172.16.0.0/16 ) , , AS2 будет видеть следует ли маршрутизации AS2 должна решить возьмите копию четырех маршрутов или, поскольку перекрывает другие конкретные маршруты все чтобы просто сохранить сводку, 172.16.0.0/16 172.16.0.0/16 , .

отправить данные на префикс они Если AS2 хочет будут отправлены маршрутизаторам AS1 по маршруту 172.16.0.0/16 172.16.192.0/18 , . В AS1 оно либо будет отброшено, либо ICMP- сообщение о недостижимости места назначения будет отправлено обратно, в зависимости от конфигурации маршрутизаторов AS1.

удалить маршрут 172.16.0.0/16 , до , оставив 172.16.0.0/18 . Если позже , 172.16.64.0/18 , уменьшится и 172.16.128.0/18 AS1 решит трех количество маршрутов, объявляемых AS1 от политики маршрутизации AS2 он будет хранить копии трех маршрутов или объединять и двух 172.16.0.0/18 172.16.64.0/18 в В зависимости 172.16 172.16.0.0/17 , ( тем уменьшая количество маршрутов, хранимых AS2, до самым .0.0 / 17 и 172.16.128.0/18 )  .

Если AS2 теперь захочет отправить данные на префикс 172.16.192.0/18 или ICMP-сообщение о недостижимости места назначения , они будут отброшены будет отправлено обратно на маршрутизаторы AS2 (а не AS1, как раньше), поскольку не находится 172.16.192.0/18 в таблицу маршрутизации.

AS и 32-битные ASN номера Истощение номера

В спецификации RFC 1771 BGP-4 номера AS закодированы в 16 битах, что соответствует 64 510 возможным общедоступным номерам AS. ^[а] В 2011 году все еще было доступно только 15 000 номеров AS, и прогнозы ^[43] предполагали полное исчерпание доступных номеров AS в сентябре 2013 года.

RFC 6793 расширяет кодирование AS с 16 до 32 бит. ^[б]что теперь позволяет использовать до 4 миллиардов доступных AS. Дополнительный диапазон частных AS также определен в RFC 6996. ^[с]Чтобы разрешить обход групп маршрутизаторов, которые не могут управлять этими новыми номерами ASN, новый атрибут AS4_PATH используется (необязательный транзитивный). Присвоение 32-битных ASN началось в 2007 году.

Балансировка нагрузки [ править ]

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

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

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

Безопасность [ править ]

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

Расширения [ править ]

Многопротокольные расширения для BGP (MBGP), иногда называемые многопротокольными BGP или многоадресными BGP и определенные в RFC 4760 — это расширение BGP, которое позволяет параллельно распределять различные типы адресов (известные как семейства адресов). В то время как стандартный BGP поддерживает только одноадресные адреса IPv4, многопротокольный BGP поддерживает адреса IPv4 и IPv6, а также варианты одноадресной и многоадресной рассылки каждого из них. Многопротокольный BGP позволяет обмениваться информацией о топологии IP-маршрутизаторов с поддержкой многоадресной рассылки отдельно от топологии обычных одноадресных маршрутизаторов IPv4. Таким образом, это позволяет использовать топологию многоадресной маршрутизации, отличную от топологии одноадресной маршрутизации. Хотя MBGP обеспечивает обмен информацией о междоменной многоадресной маршрутизации, для построения деревьев и пересылки многоадресного трафика необходимы другие протоколы, такие как семейство протокольно-независимой многоадресной рассылки.

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

Еще одним расширением BGP является многопутевая маршрутизация . Обычно для этого требуется идентичный MED, вес, источник и путь AS, хотя некоторые реализации предоставляют возможность ослабить проверку пути AS, чтобы ожидать только равной длины пути, а не ожидаемого совпадения фактических номеров AS в пути. Затем это можно расширить с помощью таких функций, как dmzlink-bw от Cisco, который обеспечивает соотношение распределения трафика на основе значений пропускной способности, настроенных на отдельных каналах.

Использует [ править ]

BGP4 является стандартом для интернет-маршрутизации и требуется от большинства интернет-провайдеров (ISP) для установления маршрутизации между собой. Очень крупные частные IP-сети внутренне используют BGP. Примером использования является объединение нескольких крупных сетей с открытым кратчайшим путем (OSPF), когда OSPF сам по себе не масштабируется до требуемого размера. Другая причина использования BGP — это множественная адресация сети для лучшей избыточности либо для нескольких точек доступа к одному интернет-провайдеру, либо к нескольким интернет-провайдерам.

Реализации [ править ]

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

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

Маршрутизатор BGP, используемый только для сети с одной точкой входа в Интернет, может иметь гораздо меньший размер таблицы маршрутизации (и, следовательно, требования к ОЗУ и ЦП), чем многосетевая сеть. Даже простая множественная адресация может иметь скромный размер таблицы маршрутизации. Фактический объем памяти, необходимый для маршрутизатора BGP, зависит от объема информации BGP, которой обмениваются другие узлы BGP, и способа, которым конкретный маршрутизатор хранит информацию BGP. Маршрутизатору, возможно, придется хранить более одной копии маршрута, чтобы он мог управлять различными политиками объявления и принятия маршрутов для конкретной соседней AS. Термин « представление» часто используется для обозначения различных отношений политики на работающем маршрутизаторе.

Если одна реализация маршрутизатора требует больше памяти на маршрут, чем другая реализация, это может быть законным выбором конструкции, предполагающим компромисс между скоростью обработки и памятью. Полная таблица IPv4 BGP по состоянию на август 2015 г. ^[update] превышает 590 000 префиксов. ^[35]Крупные интернет-провайдеры могут добавить еще 50% для внутренних и клиентских маршрутов. Опять же, в зависимости от реализации, отдельные таблицы могут храниться для каждого представления другой одноранговой AS.

Известные бесплатные реализации BGP с открытым исходным кодом включают:

BIRD — пакет маршрутизации GPL для Unix-подобных систем.
FRRouting — форк Quagga для Unix-подобных систем; и его предки:
- Quagga — форк GNU Zebra для Unix-подобных систем (больше не разрабатывается).
- GNU Zebra — пакет маршрутизации GPL, поддерживающий BGP4 (выведен из эксплуатации). ^[45]
OpenBGPD — под лицензией BSD, реализация разработанная командой OpenBSD .
XORP , расширяемая открытая платформа маршрутизации, набор протоколов маршрутизации под лицензией BSD.

Системы для тестирования соответствия BGP, производительности нагрузки или нагрузки поставляются такими поставщиками, как:

Аджилент Технологии
GNS3 с открытым исходным кодом Симулятор сети
Иксия
Дух

Документы по стандартам [ править ]

RFC 1772 , Применение протокола пограничного шлюза в интернет-протоколе (BGP-4) с использованием SMIv2.
RFC 1997 , Атрибут сообществ BGP
RFC 2439 , Демпфирование изменения маршрута BGP
RFC 2918 , Возможность обновления маршрутов для BGP-4
RFC 3765 , Сообщество NOPEER для управления областью маршрута протокола пограничного шлюза (BGP)
RFC 4271 , Протокол пограничного шлюза 4 (BGP-4)
RFC 4272 , Анализ уязвимостей безопасности BGP
RFC 4273 , Определения управляемых объектов для BGP-4.
RFC 4274 , Анализ протокола BGP-4
RFC 4275 , Обзор внедрения BGP-4 MIB
RFC 4276 , Отчет о реализации BGP-4
RFC 4277 , Опыт работы с протоколом BGP-4.
RFC 4278 , Разница в зрелости стандартов относительно опции подписи TCP MD5 (RFC 2385) и спецификации BGP-4
RFC 4360 , атрибут расширенных сообществ BGP
RFC 4456 , Отражение маршрута BGP — альтернатива полносвязному внутреннему BGP (iBGP)
RFC 4724 , Механизм плавного перезапуска BGP.
RFC 4760 , Многопротокольные расширения для BGP-4
RFC 5065 , Конфедерации автономных систем для BGP.
RFC 5492 , Объявление о возможностях BGP-4.
RFC 5701 , атрибут расширенного сообщества BGP для конкретного адреса IPv6
RFC 6793 , Поддержка BGP для четырехоктетного пространства номеров автономной системы (AS)
RFC 7153 , Реестры IANA для расширенных сообществ BGP
RFC 7606 , Пересмотренная обработка ошибок для сообщений BGP UPDATE
RFC 7911 , Объявление нескольких путей в BGP
RFC 8092 , Атрибут больших сообществ BGP
RFC 8195 , Использование больших сообществ BGP
RFC 8642 , Поведение политик для известных сообществ BGP
RFC 8955 , Распространение правил спецификации потока
RFC 9552 , Распространение информации о состоянии канала и организации трафика с использованием BGP.
Процесс принятия индивидуального решения BGP , проект IETF, 3 февраля 2017 г.
Выборочное обновление маршрута для BGP , проект IETF, 7 ноября 2015 г.
RFC 1105 , устаревший — протокол пограничного шлюза (BGP)
RFC 1654 , устаревший – протокол пограничного шлюза 4 (BGP-4)
RFC 1655 , устаревший – применение протокола пограничного шлюза в Интернете.
RFC 1657 , устаревший – определения управляемых объектов для четвертой версии пограничного шлюза
RFC 1771 , устаревший – протокол пограничного шлюза 4 (BGP-4)
RFC 1965 , устаревший – автономные системные конфедерации для BGP.
RFC 2796 , устарело – Отражение маршрута BGP – альтернатива полносвязному iBGP
RFC 2858 , устаревший – многопротокольные расширения для BGP-4.
RFC 3065 , устаревший – Конфедерации автономных систем для BGP
RFC 3392 , устаревший – объявление о возможностях BGP-4.
RFC 4893 , устарело — поддержка BGP для четырехоктетного пространства номеров AS

См. также [ править ]

Отключение Facebook в 2021 году. Отключение затронуло все службы Facebook.
Инцидент с AS 7007 - серьезный сбой в работе Интернета 25 апреля 1997 г.
Управление по присвоению номеров в Интернете - организация по стандартизации, контролирующая IP-адреса.
Пересылка пакетов – ретрансляция пакетов из одного сегмента сети в другой.
Частный IP
QPPB - Механизм организации дорожного движения
Региональный реестр Интернета - организация, ответственная за управление нумерацией сети.
Ресурсная инфраструктура открытых ключей — система безопасности маршрутизации в Интернете.
Фильтрация маршрутов — процесс исключения определенных сетевых маршрутов.
База данных ресурсов маршрутизации — реестр маршрутизации для сетей Интернета.

Примечания [ править ]

^ ASN с 64512 по 65534 были зарезервированы для частного использования, а номера 0 и 65535 запрещены.
^ 16-битный диапазон AS от 0 до 65535 и его зарезервированные номера AS сохраняются.
^ ASN от 4200000000 до 4294967294 являются частными, а номера 4294967295 запрещены RFC 7300.

Ссылки [ править ]

^ «История rfc1105» . IETF . Июнь 1989 года . Проверено 1 декабря 2023 г.
^ «BGP: объяснение протокола пограничного шлюза» . Орбита-Компьютерные решения.Com . Архивировано из оригинала 28 сентября 2013 г. Проверено 8 октября 2013 г.
^ Собриньо, Жоау Луис (2003). «Сетевая маршрутизация с протоколами вектора пути: теория и приложения» (PDF) . Архивировано (PDF) из оригинала 14 июля 2010 г. Проверено 16 марта 2018 г.
^ Тимберг, Крейг (31 мая 2015 г.). «Сеть небезопасности. Быстрое решение ранней проблемы с Интернетом живет и четверть века спустя» . Вашингтон Пост . Архивировано из оригинала 1 июня 2015 года . Проверено 4 января 2021 г. Когда нависла перспектива краха системы, мужчины начали записывать идеи решения на обратной стороне салфетки, испачканной кетчупом. Потом секунда. Потом третий. «Протокол трех салфеток», как его в шутку окрестили его изобретатели, вскоре произведет революцию в Интернете. И хотя проблемы оставались, инженеры рассматривали свое творение как «взлом» или «кладж», что на сленге означает краткосрочное исправление, которое должно быть заменено, как только появится лучшая альтернатива.
^ «История протокола пограничных шлюзов» . blog.datapath.io . Архивировано из оригинала 29 октября 2020 года.
^ Протокол пограничного шлюза 4 (BGP-4) . РФК 4271 .
^ RFC 4274
^ Р. Чандра; Дж. Скаддер (май 2000 г.). Объявление возможностей с помощью BGP-4 . дои : 10.17487/RFC2842 . РФК 2842 .
^ Т. Бейтс; и другие. (июнь 2000 г.). Мультипротокольные расширения для BGP-4 . дои : 10.17487/RFC2858 . РФК 2858 .
^ Э. Розен; Ю. Рехтер (апрель 2004 г.). BGP/MPLS VPN . дои : 10.17487/RFC2547 . РФК 2547 .
^ «Алгоритм выбора наилучшего пути BGP» . Cisco.com  .
^ «Понимание выбора пути BGP» . Можжевельник.com  .
^ РФК 1997 г.
^ «Протокол пограничного шлюза (BGP) известных сообществ» . www.iana.org . Проверено 4 декабря 2022 г.
^ «Поддержка сообщества BGP | iFog GmbH» . ifog.ch. Проверено 4 декабря 2022 г.
^ «Сообщества BGP» . retn.net . Проверено 4 декабря 2022 г.
^ «Руководства сообщества BGP» . Проверено 13 апреля 2015 г.
^ RFC 4360
^ «Расширенные сообщества протокола пограничного шлюза (BGP)» . www.iana.org . Проверено 4 декабря 2022 г.
^ Черновики IETF по BGP, сигнализирующие о QoS. Архивировано 23 февраля 2009 г. в Wayback Machine , Томас Нолл, 2008 г.
^ «Большие сообщества BGP» . Проверено 27 ноября 2021 г.
^ Ю. Рехтер; Т. Ли; С. Харес, ред. (январь 2006 г.). Протокол пограничного шлюза 4 (BGP-4) . Сетевая рабочая группа. дои : 10.17487/RFC4271 . РФК 4271 . Проект стандарта. сек. 4.1.
^ «Протокол пограничного шлюза (BGP)» . Cisco.com  .
^ Т. Бейтс; и другие. (апрель 2006 г.). Отражение маршрута BGP: альтернатива полносвязному внутреннему BGP (iBGP) . РФК 4456 .
^ "Информация" . www.ietf.org . Проверено 17 декабря 2019 г.
^ "Информация" . www.ietf.org . Проверено 17 декабря 2019 г.
^ "Информация" . www.ietf.org . Проверено 17 декабря 2019 г.
^ «Демпфирование колебаний маршрутов усугубляет конвергенцию маршрутизации в Интернете» (PDF) . Ноябрь 1998 г. Архивировано (PDF) из оригинала 9 октября 2022 г.
^ Чжан, Бэйчуань; Пей Дань; Дэниел Мэсси; Лися Чжан (июнь 2005 г.). «Взаимодействие таймера при демпфировании изменения маршрута» (PDF) . 25-я Международная конференция IEEE по распределенным вычислительным системам . Проверено 26 сентября 2006 г. Мы показываем, что нынешняя конструкция демпфирования приводит к желаемому поведению только при постоянном колебании маршрута. Когда количество клапанов невелико, глобальная динамика маршрутизации значительно отклоняется от ожидаемого поведения с более длительной задержкой сходимости.
^ Вильямисар, Кертис; Чандра, Рави; Говиндан, Рамеш (ноябрь 1998 г.). «Демпфирование закрылков маршрута BGP» . Ietf Datatracker . Tools.ietf.org.
^ «Рекомендации рабочей группы по маршрутизации RIPE по демпфированию колебаний маршрута» . Координационный центр сети RIPE. 10 мая 2006 г. Проверено 4 декабря 2013 г.
^ «draft-ymbk-rfd-usable-02 — Обеспечение возможности использования демпфирования закрылков маршрута» . Ietf Datatracker . Tools.ietf.org . Проверено 4 декабря 2013 г.
^ «Проблема коммутатора Cisco» .
^ Коуи, Джим (13 августа 2014 г.). «Интернет затронул полмиллиона маршрутов: на следующей неделе возможны сбои» . renesys.com . Архивировано из оригинала 13 августа 2014 года.
^ Перейти обратно: ^а ^б «Отчеты BGP» . potaroo.net .
^ «Процедуры настройки распределения TCAM для маршрутизаторов и коммутаторов серий CAT 6500 и 7600» . Циско . 9 марта 2015 г.
^ Джим Коуи. «Интернет затронул полмиллиона маршрутов: на следующей неделе возможны сбои» . Дин Исследования . Архивировано из оригинала 17 августа 2014 г. Проверено 2 января 2015 г.
^ Гарсайд, Джульетта; Гиббс, Сэмюэл (14 августа 2014 г.). «Интернет-инфраструктура нуждается в обновлении, иначе произойдет еще больше отключений электроэнергии » . Хранитель . Проверено 15 августа 2014 г.
^ «Отчет BOF» (PDF) . www.nanog.org. Архивировано (PDF) из оригинала 9 октября 2022 г. Проверено 17 декабря 2019 г.
^ Грег Ферро (26 января 2011 г.). «TCAM — более глубокий взгляд и влияние IPv6» . Эфирный разум .
^ «Сайт истощения IPv4» . ipv4depletion.com .
^ «Что вызвало сегодняшний сбой в Интернете» . bgpmon.net .
^ Отчет об 16-битной автономной системе , Джефф Хьюстон, 2011 г. (оригинал заархивирован по адресу https://web.archive.org/web/20110906085724/http://www.potaroo.net/tools/asn16/ )
^ Крейг Тимберг (31 мая 2015 г.). «Быстрое решение ранней проблемы с Интернетом живет и четверть века спустя» . Вашингтон Пост . Проверено 1 июня 2015 г.
^ «ГНУ Зебра» .

Дальнейшее чтение [ править ]

«Протокол пограничного шлюза (BGP)» , Справочник по технологиям IOS , Cisco Systems , заархивировано из оригинала 8 июля 2011 г.

Внешние ссылки [ править ]

Ресурсы маршрутизации BGP (включает специальный раздел, посвященный базовой безопасности BGP и ISP )
Статистика таблицы BGP

[43] ASN с 64512 по 65534 были зарезервированы для частного использования, а номера 0 и 65535 запрещены.

[45] 16-битный диапазон AS от 0 до 65535 и его зарезервированные номера AS сохраняются.

[46] ASN от 4200000000 до 4294967294 являются частными, а номера 4294967295 запрещены RFC 7300.

[1] «История rfc1105» . IETF . Июнь 1989 года . Проверено 1 декабря 2023 г.

[orbit-2] «BGP: объяснение протокола пограничного шлюза» . Орбита-Компьютерные решения.Com . Архивировано из оригинала 28 сентября 2013 г. Проверено 8 октября 2013 г.

[3] Собриньо, Жоау Луис (2003). «Сетевая маршрутизация с протоколами вектора пути: теория и приложения» (PDF) . Архивировано (PDF) из оригинала 14 июля 2010 г. Проверено 16 марта 2018 г.

[4] Тимберг, Крейг (31 мая 2015 г.). «Сеть небезопасности. Быстрое решение ранней проблемы с Интернетом живет и четверть века спустя» . Вашингтон Пост . Архивировано из оригинала 1 июня 2015 года . Проверено 4 января 2021 г. Когда нависла перспектива краха системы, мужчины начали записывать идеи решения на обратной стороне салфетки, испачканной кетчупом. Потом секунда. Потом третий. «Протокол трех салфеток», как его в шутку окрестили его изобретатели, вскоре произведет революцию в Интернете. И хотя проблемы оставались, инженеры рассматривали свое творение как «взлом» или «кладж», что на сленге означает краткосрочное исправление, которое должно быть заменено, как только появится лучшая альтернатива.

[5] «История протокола пограничных шлюзов» . blog.datapath.io . Архивировано из оригинала 29 октября 2020 года.

[6] Протокол пограничного шлюза 4 (BGP-4) . РФК 4271 .

[7] RFC 4274

[8] Р. Чандра; Дж. Скаддер (май 2000 г.). Объявление возможностей с помощью BGP-4 . дои : 10.17487/RFC2842 . РФК 2842 .

[9] Т. Бейтс; и другие. (июнь 2000 г.). Мультипротокольные расширения для BGP-4 . дои : 10.17487/RFC2858 . РФК 2858 .

[10] Э. Розен; Ю. Рехтер (апрель 2004 г.). BGP/MPLS VPN . дои : 10.17487/RFC2547 . РФК 2547 .

[11] «Алгоритм выбора наилучшего пути BGP» . Cisco.com  .

[12] «Понимание выбора пути BGP» . Можжевельник.com  .

[13] РФК 1997 г.

[14] «Протокол пограничного шлюза (BGP) известных сообществ» . www.iana.org . Проверено 4 декабря 2022 г.

[15] «Поддержка сообщества BGP | iFog GmbH» . ifog.ch. Проверено 4 декабря 2022 г.

[16] «Сообщества BGP» . retn.net . Проверено 4 декабря 2022 г.

[17] «Руководства сообщества BGP» . Проверено 13 апреля 2015 г.

[18] RFC 4360

[19] «Расширенные сообщества протокола пограничного шлюза (BGP)» . www.iana.org . Проверено 4 декабря 2022 г.

[20] Черновики IETF по BGP, сигнализирующие о QoS. Архивировано 23 февраля 2009 г. в Wayback Machine , Томас Нолл, 2008 г.

[21] «Большие сообщества BGP» . Проверено 27 ноября 2021 г.

[20-22] Ю. Рехтер; Т. Ли; С. Харес, ред. (январь 2006 г.). Протокол пограничного шлюза 4 (BGP-4) . Сетевая рабочая группа. дои : 10.17487/RFC4271 . РФК 4271 . Проект стандарта. сек. 4.1.

[23] «Протокол пограничного шлюза (BGP)» . Cisco.com  .

[24] Т. Бейтс; и другие. (апрель 2006 г.). Отражение маршрута BGP: альтернатива полносвязному внутреннему BGP (iBGP) . РФК 4456 .

[25] "Информация" . www.ietf.org . Проверено 17 декабря 2019 г.

[26] "Информация" . www.ietf.org . Проверено 17 декабря 2019 г.

[27] "Информация" . www.ietf.org . Проверено 17 декабря 2019 г.

[28] «Демпфирование колебаний маршрутов усугубляет конвергенцию маршрутизации в Интернете» (PDF) . Ноябрь 1998 г. Архивировано (PDF) из оригинала 9 октября 2022 г.

[29] Чжан, Бэйчуань; Пей Дань; Дэниел Мэсси; Лися Чжан (июнь 2005 г.). «Взаимодействие таймера при демпфировании изменения маршрута» (PDF) . 25-я Международная конференция IEEE по распределенным вычислительным системам . Проверено 26 сентября 2006 г. Мы показываем, что нынешняя конструкция демпфирования приводит к желаемому поведению только при постоянном колебании маршрута. Когда количество клапанов невелико, глобальная динамика маршрутизации значительно отклоняется от ожидаемого поведения с более длительной задержкой сходимости.

[30] Вильямисар, Кертис; Чандра, Рави; Говиндан, Рамеш (ноябрь 1998 г.). «Демпфирование закрылков маршрута BGP» . Ietf Datatracker . Tools.ietf.org.

[31] «Рекомендации рабочей группы по маршрутизации RIPE по демпфированию колебаний маршрута» . Координационный центр сети RIPE. 10 мая 2006 г. Проверено 4 декабря 2013 г.

[32] «draft-ymbk-rfd-usable-02 — Обеспечение возможности использования демпфирования закрылков маршрута» . Ietf Datatracker . Tools.ietf.org . Проверено 4 декабря 2013 г.

[33] «Проблема коммутатора Cisco» .

[34] Коуи, Джим (13 августа 2014 г.). «Интернет затронул полмиллиона маршрутов: на следующей неделе возможны сбои» . renesys.com . Архивировано из оригинала 13 августа 2014 года.

[Potaroo_—_BGP_Table_data-35] Перейти обратно: ^а ^б «Отчеты BGP» . potaroo.net .

[36] «Процедуры настройки распределения TCAM для маршрутизаторов и коммутаторов серий CAT 6500 и 7600» . Циско . 9 марта 2015 г.

[37] Джим Коуи. «Интернет затронул полмиллиона маршрутов: на следующей неделе возможны сбои» . Дин Исследования . Архивировано из оригинала 17 августа 2014 г. Проверено 2 января 2015 г.

[38] Гарсайд, Джульетта; Гиббс, Сэмюэл (14 августа 2014 г.). «Интернет-инфраструктура нуждается в обновлении, иначе произойдет еще больше отключений электроэнергии » . Хранитель . Проверено 15 августа 2014 г.

[39] «Отчет BOF» (PDF) . www.nanog.org. Архивировано (PDF) из оригинала 9 октября 2022 г. Проверено 17 декабря 2019 г.

[40] Грег Ферро (26 января 2011 г.). «TCAM — более глубокий взгляд и влияние IPv6» . Эфирный разум .

[41] «Сайт истощения IPv4» . ipv4depletion.com .

[42] «Что вызвало сегодняшний сбой в Интернете» . bgpmon.net .

[44] Отчет об 16-битной автономной системе , Джефф Хьюстон, 2011 г. (оригинал заархивирован по адресу https://web.archive.org/web/20110906085724/http://www.potaroo.net/tools/asn16/ )

[47] Крейг Тимберг (31 мая 2015 г.). «Быстрое решение ранней проблемы с Интернетом живет и четверть века спустя» . Вашингтон Пост . Проверено 1 июня 2015 г.

[48] «ГНУ Зебра» .

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

[38]

[39]

[40]

[41]

[42]

[а]

[43]

[б]

[с]

[44]

[45]