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

редактировать
Протокол для передачи информации о маршрутизации в Интернете

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

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

Содержание

  • 1 История
  • 2 Операция
    • 2.1 Согласование расширений
    • 2.2 Подключение маршрутизатора и маршруты обучения
    • 2.3 Сообщества
    • 2.4 Дискриминаторы с ограниченными выходами
    • 2.5 Формат заголовка сообщения
  • 3 Внутренняя масштабируемость
    • 3.1 Отражатели маршрутизации
      • 3.1.1 Правила
      • 3.1.2 Кластер
    • 3.2 Конфедерация BGP
  • 4 Стабильность
  • 5 Рост таблицы маршрутизации
    • 5.1 512k в день
    • 5.2 Истощение номеров AS и 32-битные ASN
  • 6 Балансировка нагрузки
  • 7 Безопасность
  • 8 Расширения
  • 9 Использование
  • 10 Реализации
  • 11 Документы по стандартам
  • 12 См.. Также
  • 13 Ссылки
  • 14 Дополнительная литература
  • 15 Внешние ссылки

История

Протокол пограничного шлюза используется в Интернете с 1994 года. IPv6 BGP был первым определен в RFC 1883 в 1995 году, и он был улучшен до RFC 2283 в 1998 году.

Текущая версия BGP - это версия 4 (BGP4), которая была опубликована как RFC 4271 в 2006 году. RFC 4271 исправил ошибки, прояснил двусмысленность и обновил спецификацию с общепринятой отраслевой практикой. Основным улучшением была поддержка бесклассовой междоменной маршрутизации (CIDR) и использование агрегации маршрутов для уменьшения размера таблиц маршрутизации. Новый RFC позволяет BGP4 широкий диапазон «семейств адресов» IPv4 и IPv6. Это также называется многопротокольным расширением, то есть есть многопротокольным BGP (MP-BGP).

Операция

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

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

Основное различие между пирингом iBGP и eBGP заключается в том, как используются данные, полученные от одного однорангового узла, распространяются на другие одноранговые узлы. Например, новые маршруты, полученные от однорангового узла eBGP, обычно перераспределяются всем одноранговым узлам iBGP, а также всем другим одноранговым узлам eBGP (если на маршрутизаторе включен транзитный режим). Однако, если новые маршруты изучаются в пиринге iBGP, они повторно объявляются только всем одноранговым узлам eBGP. Эти правила использования процедур требуют, чтобы все одноранговые узлы iBGP внутри AS были соединены между собой в полную сетку.

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

Согласование расширений

конечный автомат BGP

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

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

  • Состояние ожидания :
    • Отклонять все входящие соединения BGP.
    • Запуск инициализации триггеров событий.
    • Иницирует TCP-соединение со своим настроенным одноранговым узлом BGP.
    • Прослушивает TCP-соединения от его однорангового узла.
    • Изменяет свое состояние на Соединение.
    • Если возникает ошибка в любом состоянии процесса FSM, сеанс BGP немедленно завершается и возвращается в состояние ожидания. Некоторые из причин, по которому маршрутизатор не выходит из состояния:
      • TCP-порт 179 не открыт.
      • Случайный TCP-порт более 1023 не открыт.
      • Адрес однорангового узла настроен неправильно на любом маршрутизаторе.
      • Номер AS настроен неправильно на любом маршрутизаторе.
  • Состояние соединения :
    • Ожидает успешного согласования TCP с одноранговым узлом.
    • BGP не тратит много время в этом состоянии, если сеанс TCP был успешно установлен.
    • Отправляет сообщение Открыть одноранговому узлу и меняет состояние на 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 ). Следующее обсуждение темы обработки UPDATE предполагает полную сетку iBGP.

маршрутизатор BGP может данным ОБНОВЛЕНИЯ информации о доступности сетевого уровня (NLRI) от нескольких соседей и объявлять NLRI тем же или другому набору соседей. Концептуально BGP поддерживает свою «главную» таблицу маршрутизации, которая называется Local База маршрутной информации (Loc-RIB), отдельно от основной таблицы маршрутизации маршрутизатора. Для каждого процесса BGP поддерживает концептуальную базу информации о соседней маршрутизации, входящую (Adj-RIB-In), содержащую NLRI, содержащую от соседа, и концептуальный Adj-RIB-Out (исходящий) для NLRI, который должен быть отправлен соседу..

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

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

После проверки доступности следующего перехода, если маршрут исходит от внутреннего (то есть iBGP) однорангового узла, первое правило, которое следует применить, согласно стандарту, - проверить атрибут LOCAL_PREFERENCE. Если существует несколько маршрутов iBGP от соседа, выбирается тот, у которого LOCAL_PREFERENCE наивысший, если только не существует нескольких маршрутов с одинаковым LOCAL_PREFERENCE. В последнем случае процесса выбора маршрута переходит к следующему разрешению конфликта. Хотя LOCAL_PREFERENCE является правилами в стандарте, после проверки доступности NEXT_HOP Cisco и несколько других поставщиков сначала учитывают принятие решений, называемый WEIGHT, который является локальным для маршрутизатора (т. Е. Не передается по BGP). Предпочтительно маршрут с наибольшим ВЕСОМ.

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

На уровне соседа - игнорируя модификаторы политики, зависящие от реализации - порядок правил разрешения конфликтов следующий:

  1. Предпочитаю маршрут с самым коротким AS_PATH. AS_PATH - это набор номеров AS, которые необходимо пройти, чтобы достичь объявленного пункта назначения. AS1-AS2-AS3 короче AS4-AS5-AS6-AS7.
  2. Предпочитать маршруты с наименьшим значением их атрибута ORIGIN.
  3. Предпочитать маршруты с наименьшим MULTI_EXIT_DISC (дискриминатор с ограниченными выходами или MED).

До последней редакции стандарта BGP, если UPDATE не имеет значения MULTI_EXIT_DISC, несколько реализаций создавали MED с максимально возможным максимальным. Тем не менее в текущем стандарте указывается, что отсутствующие атрибуты MED должны рассматривать как минимальное возможное значение. Согласно схеме, используемой в качестве альтернативы, использует BGP, которая позволяет выбрать старое или стандартное правило, которое позволяет выбрать нестандартное значение по умолчанию, функцию конфигурации, которая позволяет выбрать старое или стандартное правило.

После получения маршрутов-кандидатов от соседей программное обеспечение Loc-RIB применяет дополнительные средства разрешения конфликтов к маршрутам к тому же месту назначения.

  1. Если хотя бы один маршрут был получен от внешнего соседа (т. Е. Маршрут был получен от eBGP), отбросьте все маршруты, полученные от iBGP.
  2. Предпочитайте маршрут с наименьшей внутренней стоимостью NEXT_HOP, согласно основной таблице маршрутизации. Если два соседа анонсировали один и тот же маршрут, но один сосед доступен по каналу с низкой скоростью передачи данных, а другой по каналу с высокой скоростью передачи данных, а протокол внутренней маршрутизации вычисляет наименьшую стоимость на основе максимальной скорости передачи данных, маршрут через канал с высокой скоростью передачи данных будет предпочтительнее, а другие маршруты будут отброшены.

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

  1. Предпочитать маршрут, полученный от узла BGP с числовым наименьшим идентификатором BGP
  2. Предпочитать маршрут, полученный от узла BGP с наименьшим IP-адресом однорангового узла

Сообщества

Сообщества BGP являются теги атрибутов, которые можно применять к входящим или исходящим префиксам для достижения общей цели (RFC 1997 ). Хотя принято говорить, что BGP позволяет администратору устанавливать политики обработки префиксов поставщиками услуг Интернета, строго говоря, это, как правило, невозможно. Например, BGP изначально не имеет концепции, позволяющей одной AS указывать другой AS, чтобы она ограничивала рекламу префикса только для клиентов пиринга в Северной Америке. Вместо этого интернет-провайдер обычно публикует список известных или закрытых сообществ с описанием каждого из них, что по сути становится соглашением о том, как следует обращаться с префиксами. RFC 1997 также определяет три хорошо известных сообщества, имеющих глобальное значение; NO_EXPORT, NO_ADVERTISE и NO_EXPORT_SUBCONFED. RFC 7611 определяет ACCEPT_OWN. Примеры распространенных сообществ включают в себя настройки локальных предпочтений, географические ограничения или ограничения типа однорангового узла, предотвращение DoS-атак (черные дыры) и параметры предварительного добавления AS. Интернет-провайдер может заявить, что любыемаршруты, полученные от клиентов из сообщества XXX: 500, будут объявляться всем одноранговым узлам (по умолчанию), в то время как сообщество XXX: 501 будет ограничивать рекламу в Северной Америке. Клиент просто настраивает свою конфигурацию, чтобы включить правильное сообщество или сообщества для каждого маршрута, а поставщик услуг Интернета отвечает за то, кому объявляется префикс. Конечный пользователь не имеет технической возможности обеспечить выполнение правильных действий со стороны провайдера, хотя проблемы в этой области, как правило, редки и случайны.

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

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

Примечание: начиная с RFC 7153, расширенные сообщества совместимы с 32-битными ASN. 141>

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

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

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

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

Ниже приведен формат заголовка сообщений BGP версии 4:

битовое смещение0–1516–2324–31
0Маркер
32
64
96
128ДлинаТип
  • Маркер : Включено для совместимости, должно быть установлено на все.
  • Длина : Общая длина сообщения в октетах, включая заголовок.
  • Тип : Тип сообщения BGP. Определены следующие значения:
    • Открыть (1)
    • Обновить (2)
    • Уведомление (3)
    • KeepAlive (4)
    • Route-Refresh (5)

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

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

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

Отражатели маршрута

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

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

Отражатель маршрута - это единая точка отказа, поэтому, по меньшей мере, второй отражатель маршрута может быть настроен для избыточности. Он включает дополнительный одноранговым узлом для других 10 маршрутизаторов, он предлагает дополнительный счетчик, который удваивает это минус 2 по сравнению с настройкой одного отражателя маршрута. Дополнительные 11 * 2-2 = 20 операторов в этом случае из-за добавления дополнительного маршрутизатора. Кроме того, в среде многопутевого протокола BGP также может быть выгодно за счет добавления пропускной способности коммутации / маршрутизации, если RR как стандартные маршрутизаторы, а не только как выделенная роль сервера отражателя маршрутов.

Правила

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

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

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

Кластер

RR и его клиенты образуют «Кластер». Затем прилагается "Cluster-ID" прикрепленному к каждому клиенту, предоставленному клиенту. Cluster-ID - это совокупный, нетранзитивный атрибут BGP, и RR ДОЛЖЕН добавлены локальный CLUSTER_ID каждый к CLUSTER_LIST, чтобы избежать петель маршрутизации. Отражатели маршрутов и конфедерации уменьшают количество одноранговых узлов iBGP для каждого маршрутизатора и, таким образом, сокращают накладные расходы на обработку. Отражатели агрутов - это чистый метод повышения производительности, в то время как конфедерации объявили, что реализация для реализации более детальной политики.

Конфедерация 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 Routing Working Group написать, что «с текущими реализациями демпфирования закрытых сетей BGP применение демпфирования закрытых сетей ISP НЕ рекомендуется... Если демпфирование закрылков реализовано, ISP, работающий в этой сети, вызовет побочные -влияние на клиентов и интернет -пользователями и услугами их клиентов... Эти побочные эффекты, скорее всего, будут хуже, чем воздействие, вызванное просто отсутствием демпфирования заслонок ». Повышение стабильности без проблем с демпфированием закрылков является предметом текущих исследований.

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

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

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

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

512 тыс. Руб. Дней

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

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

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

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

В RFC 1771 (протокол пограничного шлюза 4 (BGP-4)) планировалось кодирование номеров AS на 16 битах. для использования 64510 использовавшихся общедоступных AS, поскольку ASN с 64512 по 65534 были зарезервированы для частного (0 и 65535 запрещены). В 2011 году было доступно только 15000 номеров AS, и прогнозы предполагали полное исчерпание доступных номеров AS в сентябре 2013 года.

RFC 6793 расширяет кодирование AS с 16 до 32 бит (сохраняя 16-битный диапазон AS 0. до 65535 и его зарезервированных номеров AS), что теперь позволяет использовать до 4 миллиардов доступных AS. Дополнительный частный диапазон AS также определен в RFC 6996 (от 4200000000 до 4294967294, 4294967295 запрещен в RFC 7300 ).

Чтобы разрешить обход групп маршрутизаторов, не способных управлять этими новыми ASN, используется новый атрибут OT AS4_PATH.

Назначение 32-битных АСН началось в 2007 году.

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

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

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

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

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

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

Расширения

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

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

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

Использует

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

Реализации

Маршрутизаторы, особенно маленькие, предназначенные для использования в малом / домашнем офисе (SOHO), могут не участвовать в программном обеспечении BGP. Некоторые маршрутизаторы SOHO могут просто не запускать BGP / использовать таблицы маршрутизации BGP любого размера. Другим коммерческий маршрутизаторам может потребоваться исполняемый образ программного обеспечения, предоставленный конкретным BGP, или лицензия, которая разрешает. Пакеты с открытым исходным кодом, которые запускают BGP, включают GNU Zebra, Quagga, OpenBGPD, BIRD, XORP <169.>и Вятта. Устанавливаемые, продаваемые как коммутаторы уровня 3, с меньшей вероятностью будут поддерживать BGP, чем устройства, продаваемые как маршрутизаторы, но коммутаторы уровня 3 высокого уровня обычно могут запускать BGP.

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

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

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

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

Системы тестирования качества BGP, стрессовой или стрессовой производительности:

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

  • Выборочное обновление маршрута для BGP, IETF черновик
  • RFC 1772, Применение протокола пограничного шлюза в Интернет-протоколе (BGP-4) с использованием SMIv2
  • RFC 2439, демпфирование заслонки маршрута BGP
  • RFC 2918, возможность обновления маршрута для BGP-4
  • RFC 3765, NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control
  • 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 4456, внедрение маршрута BGP - альтернатива полному внутреннему BGP (iBGP)
  • RFC 4724, механизм плавного перезапуска для BGP
  • RFC 4760, многопротокольные расширения для BGP- 4
  • RFC 4893, Поддержка BGP для четырехоктетного пространства номеров AS
  • RFC 5065, Конфедерации автономных систем для BGP
  • RFC 5492, Объявление пространства с BGP-4
  • RFC 5575, Распространение правил потока
  • RFC 7752, Распределение информации о состоянии канала и управления трафиком по северной границе с использованием BGP
  • RFC 7911, Объявление множественных путей в BGP
  • draft -ietf-idr-custom-solution-08 - Процесс принятия индивидуального решения BGP, 3 февраля 2017 г.
  • RFC 3392, Устаревший - Объявление возможностей с BGP-4
  • RFC 2796, Устаревший - Отражение маршрута BGP - альтернатива Full Mesh iBGP
  • RFC 3065, Устаревший - Конфедерации автономных систем для BGP
  • RFC 1965, Устаревший - Конфедерации автономных систем для BGP
  • RFC 1771, Устаревший - Протокол пограничного шлюза 4 (BGP-4)
  • RFC 1657, Устаревший - определения управляемых объектов для четвертой версии пограничного шлюза
  • RFC 1655, устаревшее применение протокола пограничного шлюза в Интернете
  • RFC 1654, Устаревший - протокол пограничного шлюза 4 (BGP-4)
  • RFC 1105, Устаревший - протокол пограничного шлюза (BGP)
  • RFC 2858, Устаревший - многопротокольные расширения для BGP-4

См. Также

Ссылки

Дополнительные материалы для чтения

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

Последняя правка сделана 2021-05-13 14:52:16
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте