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

«BGP» перенаправляется сюда. Чтобы узнать о других значениях, см. BGP (значения) .

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

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

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

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

История

Протокол пограничных шлюзов был набросан инженерами в 1989 году на обратной стороне «трех салфеток, испачканных кетчупом», и до сих пор известен как протокол трех салфеток . Впервые он был описан в 1989 году в RFC 1105 и используется в Интернете с 1994 года. 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 году. В RFC 4271 исправлены ошибки, разъяснены неясности и обновлена ​​спецификация с учетом общепринятых отраслевых практик. Основным усовершенствованием BGP4 стала поддержка бесклассовой междоменной маршрутизации (CIDR) и использование агрегации маршрутов для уменьшения размера таблиц маршрутизации . RFC 4271 позволяет BGP4 поддерживать широкий спектр «семейств адресов» IPv4 и IPv6. Его также называют многопротокольными расширениями, то есть многопротокольным BGP (MP-BGP).

Операция

Соседи BGP, называемые одноранговыми узлами, устанавливаются на маршрутизаторах путем ручной настройки для создания сеанса TCP на порту 179. Узел BGP отправляет 19-байтовые сообщения проверки активности каждые 30 секунд (значение протокола по умолчанию, настраиваемое) для поддержания соединения. Среди протоколов маршрутизации 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 могут согласовывать дополнительные возможности сеанса. включая многопротокольные расширения и различные режимы восстановления. Если многопротокольные расширения BGP согласовываются во время создания, узел BGP может префикс информации о доступности сетевого уровня (NLRI), которую он объявляет, префиксом семейства адресов. Эти семейства включают IPv4 (по умолчанию), IPv6, виртуальные частные сети IPv4/IPv6 и многоадресную рассылку BGP. BGP все чаще используется в качестве универсального протокола сигнализации для передачи информации о маршрутах, которые могут не быть частью глобального Интернета, например о VPN.

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

• Сообщества
• дискриминаторы с несколькими выходами (MED).
• автономные системы (АС)

Процесс выбора маршрута

Стандарт 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, отозванный маршрут будет удален из основной таблицы маршрутизации.

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

Шаги для определения лучшего пути в порядке тай-брейка :

Шаг	Объем	Имя	По умолчанию	Предпочтительный	Поле BGP	ПРИМЕЧАНИЕ
1	Локально для маршрутизатора	местный вес	"Выключенный"	Выше		Специфический для Cisco параметр
2	Внутренний для AS	Местные предпочтения	«Выкл.», все установлено на 100.	Выше	LOCAL_PREF	Если от соседа существует несколько маршрутов iBGP, выбирается тот, который имеет наивысшее локальное предпочтение, если только нет нескольких маршрутов с одинаковым локальным предпочтением.
3		Протокол накопленного внутреннего шлюза (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 — это теги атрибутов, которые можно применять к входящим или исходящим префиксам для достижения какой-либо общей цели. Хотя принято говорить, что BGP позволяет администратору устанавливать политику обработки префиксов интернет-провайдерами, на самом деле это, строго говоря, невозможно. Например, в BGP изначально не предусмотрена концепция, позволяющая одной AS сообщать другой AS ограничить рекламу префикса только клиентам пирингового узла Северной Америки. Вместо этого интернет-провайдер обычно публикует список известных или частных сообществ с описанием каждого из них, что, по сути, становится соглашением о том, как следует обращаться с префиксами.

Известные сообщества BGP

Значение атрибута	Атрибут	Описание	Ссылка
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

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

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

Атрибут расширенного сообщества BGP

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

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

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

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

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

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

# run show ospf route   
Topology default Route Table:
Prefix             Path  Route      NH       Metric NextHop       Nexthop     
                   Type  Type       Type            Interface     Address/LSP
10.32.37.0/24      Inter Discard    IP       16777215
10.32.37.0/26      Intra Network    IP          101 ge-0/0/1.0    10.32.37.241
10.32.37.64/26     Intra Network    IP          102 ge-0/0/1.0    10.32.37.241
10.32.37.128/26    Intra Network    IP          101 ge-0/0/1.0    10.32.37.241

# show route advertising-protocol bgp 10.32.94.169
  Prefix               Nexthop       MED    Lclpref            AS path
* 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

битовое смещение	0–15																16–23								24–31
0	Маркер (всегда: 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 бит): общая длина поля дополнительных параметров.

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

Type: Open Message (1)
Version: 4
My AS: 64496
Hold Time: 90
BGP Identifier: 192.0.2.254
Optional Parameters Length: 16
Optional Parameters:
 Capability: Multiprotocol extensions capability (1)
 Capability: Route refresh capability (2)
 Capability: Route refresh capability (Cisco) (128)

Обновление пакета

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

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

Type: UPDATE Message (2)
Withdrawn Routes Length: 0
Total Path Attribute Length: 25
Path attributes
 ORIGIN: IGP
 AS_PATH: 64500
 NEXT_HOP: 192.0.2.254
 MULTI_EXIT_DISC: 0
Network Layer Reachability Information (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
		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

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

Type: NOTIFICATION Message (3)
Major error Code: OPEN Message Error (2)
Minor error Code (Open Message): Bad Peer AS (2)
Bad Peer AS: 65200

KeepAlive

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

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

Type: KEEPALIVE Message (4)

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

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

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

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

Type: ROUTE-REFRESH Message (5)
Address family identifier (AFI): IPv4 (1)
Subtype: Normal route refresh request [RFC2918] with/without ORF [RFC5291] (0)
Subsequent address family identifier (SAFI): Unicast (1)

Внутренняя масштабируемость

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

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

Отражатели трассы

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

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

Правила

Типичная конфигурация развертывания BGP RR, предложенная в разделе 6 RFC 4456.

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

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

Кластер

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

Конфедерация

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

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

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

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

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

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

Стабильность

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

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

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

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

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

Рост таблиц BGP в Интернете

Количество AS в Интернете и количество зарегистрированных AS

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

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

512 тыс. дней

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

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

Фактическим распределением, которое привело к увеличению количества маршрутов выше 512 тыс., стало объявление около 15 000 новых маршрутов в короткие сроки, начиная с 07:48 UTC. Почти все эти маршруты были к Verizon Autonomous Systems 701 и 705, созданные в результате дезагрегации более крупных блоков, введения тысяч новых маршрутов / 24 и достижения таблицы маршрутизации 515 000 записей. Новые маршруты, судя по всему, были объединены в течение 5 минут, но нестабильность в Интернете, судя по всему, продолжалась в течение нескольких часов. Даже если бы 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.64.0/18 AS2 будет решить и 172.16.128.0/18 видеть 172.16.0.0/16 ) , политика маршрутизации AS2 должна , следует ли возьмите копию четырех маршрутов или, поскольку все , перекрывает чтобы просто сохранить сводку 172.16.0.0/16 другие конкретные маршруты , . 172.16.0.0/16

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

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

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

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

В спецификации RFC 1771 BGP-4 номера AS закодированы в 16 битах, что соответствует 64 510 возможным общедоступным номерам AS. В 2011 году все еще было доступно только 15 000 номеров AS, и прогнозы предполагали полное исчерпание доступных номеров 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) является технически и экономически сложной проблемой.

Расширения

Многопротокольные расширения для 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 г. превышает 590 000 префиксов. Крупные интернет-провайдеры могут добавить еще 50% для внутренних и клиентских маршрутов. Опять же, в зависимости от реализации, отдельные таблицы могут храниться для каждого представления другой одноранговой AS.

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

• BIRD — пакет маршрутизации GPL для Unix-подобных систем.
• FRRouting — форк Quagga для Unix-подобных систем; и его предки:
  • Quagga — форк GNU Zebra для Unix-подобных систем (больше не разрабатывается).
  • GNU Zebra — пакет маршрутизации GPL, поддерживающий BGP4 (выведен из эксплуатации).
• 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 - Механизм организации дорожного движения
• Региональный реестр Интернета - организация, ответственная за управление нумерацией сети.
• Ресурсная инфраструктура открытых ключей — система безопасности маршрутизации в Интернете.
• Фильтрация маршрутов — процесс исключения определенных сетевых маршрутов.
• База данных ресурсов маршрутизации — реестр маршрутизации для сетей Интернета.

Дальнейшее чтение

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

Внешние ссылки

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