stringtranslate.com

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

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

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

История

Генезис BGP произошел в 1989 году, когда Кирк Лохид, Лен Босак и Яков Рехтер обедали на конференции IETF . Они набросали схему своего нового протокола маршрутизации на обратной стороне салфеток, поэтому его часто называют «Протоколом двух салфеток». [4] [5] [6]

Впервые он был описан в 1989 году в RFC 1105 и используется в Интернете с 1994 года. [7] IPv6 BGP был впервые определен в RFC  1654 в 1994 году и был улучшен до RFC 2283 в 1998 году.

Текущая версия BGP — это версия 4 (BGP4), которая была впервые опубликована как RFC 1654 в 1994 году, впоследствии обновлена ​​RFC 1771 в 1995 году и RFC 4271 в 2006 году. [8] RFC 4271 исправил ошибки, прояснил неоднозначности и обновил спецификацию с учетом общепринятых отраслевых практик. Основным усовершенствованием BGP4 стала поддержка бесклассовой междоменной маршрутизации (CIDR) и использование агрегации маршрутов для уменьшения размера таблиц маршрутизации . RFC 4271 позволяет BGP4 переносить широкий спектр «семейств адресов» IPv4 и IPv6. Его также называют Multiprotocol Extensions, что является Multiprotocol BGP (MP-BGP).

Операция

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

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

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

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

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

Переговоры о продлении

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

Для принятия решений в своих операциях с одноранговыми узлами одноранговый узел BGP использует простой конечный автомат (FSM), который состоит из шести состояний: Idle; Connect; Active; OpenSent; OpenConfirm; и Established. Для каждого однорангового сеанса реализация BGP поддерживает переменную состояния, которая отслеживает, в каком из этих шести состояний находится сеанс. BGP определяет сообщения, которыми должен обмениваться каждый одноранговый узел, чтобы изменить состояние сеанса.

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

Маршрутизаторное подключение и маршруты обучения

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

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

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

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

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

Сообщества

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

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

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

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

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

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

Атрибут расширенного сообщества BGP был добавлен в 2006 году [20] для того, чтобы расширить диапазон таких атрибутов и обеспечить структурирование атрибута сообщества с помощью поля типа. Расширенный формат состоит из одного или двух октетов для поля типа, за которыми следуют семь или шесть октетов для соответствующего содержимого атрибута сообщества. Определение этого атрибута расширенного сообщества задокументировано в RFC 4360. IANA администрирует реестр для типов расширенных сообществ BGP. [21] Сам атрибут расширенного сообщества является транзитивным необязательным атрибутом BGP. Бит в поле типа внутри атрибута определяет, является ли закодированное расширенное сообщество транзитивным или нетранзитивным по своей природе. Поэтому реестр IANA предоставляет различные диапазоны номеров для типов атрибутов. Из-за расширенного диапазона атрибутов его использование может быть многообразным. RFC 4360 в качестве примера определяет «Двухоктетное расширенное сообщество AS», «Расширенное сообщество IPv4-адреса», «Непрозрачное расширенное сообщество», «Целевое сообщество маршрута» и «Сообщество источника маршрута». Ряд проектов BGP QoS также используют эту структуру атрибутов расширенного сообщества для междоменной сигнализации QoS. [22]

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

Многовыходные дискриминаторы

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

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

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

# run  show  ospf  route Топология Таблица маршрутов по умолчанию: Префикс Путь Маршрут NH Метрика Следующий переход  Тип следующего перехода Тип Тип Интерфейс Адрес/LSP 10.32.37.0/24 Внутренний отброшенный 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 # показать  маршрут  advertising-protocol  bgp 10 .32.94.169  Префикс Nexthop MED Lclpref AS path * 10.32.37.0/24 Я 16777215 I * 10.32.37.0/26 Я 101 I * 10.32.37.64/26 Я 102 I * 10.32.37.128/26 Я 101 I

Формат пакета

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

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

Открытый пакет

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

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

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

Пакет обновления

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

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

Тип: ОБНОВЛЕНИЕ Сообщение (2)Длина отозванных маршрутов: 0Общая длина атрибута пути: 25Атрибуты пути ПРОИСХОЖДЕНИЕ: ИГП 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 и т. д. Затем маршрутизатор отправляет одноранговому узлу сообщение-уведомление, в котором указывается причина возникновения ошибки.

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

Тип: УВЕДОМЛЕНИЕ Сообщение (3)Основная ошибка Код: ОТКРЫТОЕ сообщение Ошибка (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): Unicast (1)

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

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

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

Маршрутные отражатели

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

Этот подход, аналогичный функции 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 на основе следующих правил:

Кластер

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

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

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

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

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

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

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

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

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

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

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

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

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

Рост таблицы BGP в Интернете
Количество AS в Интернете против количества зарегистрированных AS

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

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

512 тыс. день

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

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

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

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

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

Если AS2 хочет отправить данные на префикс 172.16.192.0 / 18 , они будут отправлены на маршрутизаторы AS1 по маршруту 172.16.0.0 / 16. На 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 , он будет отброшен или на маршрутизаторах AS2 (а не AS1, как раньше) будет отправлено ICMP-сообщение о недоступности пункта назначения, поскольку 172.16.192.0 / 18 отсутствует в таблице маршрутизации.

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

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

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

Балансировка нагрузки

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

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

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

Безопасность

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

Расширения

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

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

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

Использует

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

Реализации

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

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

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

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

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

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

Смотрите также

Примечания

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

Ссылки

  1. ^ "История для rfc1105". IETF . Июнь 1989. Получено 1 декабря 2023 .
  2. ^ "BGP: Border Gateway Protocol Explained". Orbit-Computer Solutions.Com . Архивировано из оригинала 2013-09-28 . Получено 2013-10-08 .
  3. ^ Собриньо, Жоау Луис (2003). «Сетевая маршрутизация с протоколами вектора пути: теория и приложения» (PDF) . Архивировано (PDF) из оригинала 14 июля 2010 г. Проверено 16 марта 2018 г.
  4. ^ Jabloner, Paula (2015-03-04). "The Two-Napkin Protocol". Computer History Museum . Получено 2024-10-01 .
  5. ^ Jabloner, Paula (2020-07-02). "The Two-Napkin Protocol #WeAreCisco". Cisco . Получено 2024-10-01 .
  6. ^ "BGP - История двух салфеток" (PDF) . Пакет . 1 (2). Cisco Systems. 1989 . Получено 2024-10-01 .
  7. ^ "История протокола пограничного шлюза". blog.datapath.io . Архивировано из оригинала 29 октября 2020 г.
  8. ^ Протокол пограничного шлюза 4 (BGP-4) . RFC 4271 . 
  9. ^ RFC 4274
  10. ^ Р. Чандра; Дж. Скудер (май 2000 г.). Реклама возможностей с BGP-4. doi : 10.17487/RFC2842 . RFC 2842.
  11. ^ T. Bates и др. (июнь 2000 г.). Расширения многопротокольного протокола для BGP-4. doi : 10.17487/RFC2858 . RFC 2858.
  12. ^ Э. Розен; Ю. Рехтер (апрель 2004 г.). BGP/MPLS VPN. дои : 10.17487/RFC2547 . РФК 2547.
  13. ^ "Алгоритм выбора лучшего пути BGP". Cisco .com .
  14. ^ «Понимание выбора пути BGP». Juniper .com .
  15. ^ RFC  1997
  16. ^ "Border Gateway Protocol (BGP) Известные сообщества". www.iana.org . Получено 2022-12-04 .
  17. ^ "Поддержка сообщества BGP | iFog GmbH". ifog.ch . Получено 2022-12-04 .
  18. ^ "Сообщества BGP". retn.net . Получено 2022-12-04 .
  19. ^ "BGP Community Guides" . Получено 13 апреля 2015 г. .
  20. ^ RFC  4360
  21. ^ "Расширенные сообщества протокола BGP". www.iana.org . Получено 04.12.2022 .
  22. ^ Проекты IETF по QoS, сигнализируемому BGP. Архивировано 23 февраля 2009 г. на Wayback Machine , Томас Нолл, 2008 г.
  23. ^ "Крупные сообщества BGP" . Получено 2021-11-27 .
  24. ^ Y. Rekhter; T. Li; S. Hares, ред. (январь 2006 г.). Протокол пограничного шлюза 4 (BGP-4). Сетевая рабочая группа. doi : 10.17487/RFC4271 . RFC 4271. Проект стандарта. п. 4.1.
  25. ^ "Протокол пограничного шлюза (BGP)". Cisco .com .
  26. ^ Т. Бейтс и др. (апрель 2006 г.). Отражение маршрута BGP: альтернатива полносвязному внутреннему BGP (iBGP) . RFC 4456 . 
  27. ^ "Информация". www.ietf.org . Получено 2019-12-17 .
  28. ^ "Информация". www.ietf.org . Получено 2019-12-17 .
  29. ^ "Информация". www.ietf.org . Получено 2019-12-17 .
  30. ^ "Route Flap Damping Exacerbates Internet Routing Convergence" (PDF) . Ноябрь 1998 г. Архивировано (PDF) из оригинала 2022-10-09.
  31. ^ Чжан, Бэйчуань; Пэй Дань; Дэниел Мэсси; Лися Чжан (июнь 2005 г.). "Взаимодействие таймеров при демпфировании флэпов маршрута" (PDF) . IEEE 25-я международная конференция по распределенным вычислительным системам . Получено 2006-09-26 . Мы показываем, что текущая конструкция демпфирования приводит к предполагаемому поведению только при постоянном флэпинге маршрута. Когда количество флэпов мало, глобальная динамика маршрутизации значительно отклоняется от ожидаемого поведения с более длительной задержкой сходимости.
  32. ^ Вильямизар, Кертис; Чандра, Рави; Говиндан, Рамеш (ноябрь 1998 г.). "BGP Route Flap Damping". Ietf Datatracker . Tools.ietf.org.
  33. ^ "RIPE Routing Working Group Recommendations On Route-flap Damping". Координационный центр сети RIPE. 2006-05-10 . Получено 2013-12-04 .
  34. ^ "draft-ymbk-rfd-usable-02 - Making Route Flap Damping Usable". Ietf Datatracker . Tools.ietf.org . Получено 2013-12-04 .
  35. ^ "Процедуры корректировки распределения TCAM для маршрутизаторов и коммутаторов серий CAT 6500 и 7600". Cisco .
  36. ^ Коуи, Джим (13 августа 2014 г.). «Интернет затрагивает полмиллиона маршрутов: на следующей неделе возможны сбои». renesys.com . Архивировано из оригинала 13 августа 2014 г.
  37. ^ ab "Отчеты BGP". potaroo.net .
  38. ^ "Процедуры корректировки распределения TCAM для маршрутизаторов и коммутаторов серий CAT 6500 и 7600". Cisco . 9 марта 2015 г.
  39. ^ Джим Коуи. «Интернет коснулся полумиллиона маршрутов: на следующей неделе возможны сбои». Dyn Research . Архивировано из оригинала 2014-08-17 . Получено 2015-01-02 .
  40. ^ Гарсайд, Джульетта; Гиббс, Сэмюэл (14 августа 2014 г.). «Инфраструктура Интернета нуждается в обновлении, иначе будут происходить новые отключения электроэнергии». The Guardian . Получено 15 августа 2014 г.
  41. ^ "BOF report" (PDF) . www.nanog.org. Архивировано (PDF) из оригинала 2022-10-09 . Получено 2019-12-17 .
  42. ↑ Грег Ферро (26 января 2011 г.). «TCAM — более глубокий взгляд и влияние IPv6». EtherealMind .
  43. ^ "Сайт истощения IPv4". ipv4depletion.com .
  44. ^ "Что стало причиной сегодняшнего сбоя в работе Интернета". bgpmon.net .
  45. ^ Отчет о 16-битной автономной системе, Джефф Хьюстон 2011 (оригинал заархивирован по адресу https://web.archive.org/web/20110906085724/http://www.potaroo.net/tools/asn16/)
  46. ^ Vohra, Quaizar; Chen, Enke (май 2007 г.). Поддержка BGP для четырехоктетного пространства номеров AS. IETF . doi : 10.17487/RFC4893 . RFC 4893.
  47. ^ Крейг Тимберг (2015-05-31). «Быстрое решение ранней проблемы Интернета живо четверть века спустя». The Washington Post . Получено 2015-06-01 .
  48. ^ «Zebra — проект GNU — Фонд свободного программного обеспечения».

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

Стандартные документы

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