Протокол пограничного шлюза ( BGP ) — это стандартизированный протокол внешнего шлюза , предназначенный для обмена информацией о маршрутизации и доступности между автономными системами (AS) в Интернете . [2] BGP классифицируется как протокол маршрутизации на основе вектора пути , [3] и принимает решения о маршрутизации на основе путей, сетевых политик или наборов правил, настроенных сетевым администратором .
BGP, используемый для маршрутизации внутри автономной системы, называется протоколом внутреннего пограничного шлюза ( IBGP ). Напротив, интернет-приложение протокола называется протоколом внешнего пограничного шлюза ( EBGP ).
Протокол пограничных шлюзов был набросан инженерами в 1989 году на обратной стороне «трех салфеток, испачканных кетчупом», и до сих пор известен как протокол трех салфеток . [4] Впервые он был описан в 1989 году в RFC 1105 и используется в Интернете с 1994 года. [5] IPv6 BGP был впервые определен в RFC 1654 в 1994 году и улучшен до RFC 2283 в 1998 году.
Текущей версией BGP является версия 4 (BGP4), которая была впервые опубликована как RFC 1654 в 1994 году, впоследствии обновлена RFC 1771 в 1995 году и RFC 4271 в 2006 году. [6] RFC 4271 исправил ошибки, разъяснил двусмысленности и обновил спецификацию с помощью общепринятые отраслевые практики. Основным усовершенствованием BGP4 стала поддержка бесклассовой междоменной маршрутизации (CIDR) и использование агрегации маршрутов для уменьшения размера таблиц маршрутизации . RFC 4271 позволяет BGP4 поддерживать широкий спектр «семейств адресов» IPv4 и IPv6 . Его также называют многопротокольными расширениями, то есть многопротокольным BGP (MP-BGP).
Соседи BGP, называемые одноранговыми узлами, устанавливаются на маршрутизаторах путем ручной настройки для создания сеанса TCP на порту 179. Узел BGP отправляет 19-байтовые сообщения проверки активности каждые 30 секунд (значение протокола по умолчанию, настраиваемое) для поддержания соединения. [7] Среди протоколов маршрутизации BGP уникален тем, что в качестве транспортного протокола используется TCP.
Когда BGP работает между двумя узлами в одной автономной системе (AS), он называется внутренним BGP ( iBGP или протокол внутреннего пограничного шлюза ). Когда он работает между различными автономными системами, он называется внешним BGP ( eBGP или протокол внешнего пограничного шлюза ). Маршрутизаторы на границе одной AS, обменивающиеся информацией с другой AS, называются пограничными или пограничными маршрутизаторами или просто узлами eBGP и обычно подключаются напрямую, тогда как узлы iBGP могут соединяться между собой через другие промежуточные маршрутизаторы. Возможны также другие топологии развертывания , такие как пиринг eBGP внутри VPN- туннеля, позволяющий двум удаленным узлам безопасно и изолированно обмениваться информацией о маршрутизации.
Основное различие между пирингом iBGP и eBGP заключается в том, как маршруты, полученные от одного узла, обычно по умолчанию передаются другим узлам:
Эти правила распространения маршрутов фактически требуют, чтобы все одноранговые узлы iBGP внутри AS были соединены в полносвязной сети с сеансами iBGP.
Способ распространения маршрутов можно детально контролировать с помощью механизма карт маршрутов . Этот механизм состоит из набора правил. Каждое правило описывает, какое действие следует предпринять для маршрутов, соответствующих некоторым заданным критериям. Действием может быть удаление маршрута или изменение некоторых атрибутов маршрута перед вставкой его в таблицу маршрутизации .
Во время пирингового установления связи, когда происходит обмен сообщениями OPEN, узлы BGP могут согласовывать дополнительные возможности сеанса, [8] включая многопротокольные расширения [9] и различные режимы восстановления. Если многопротокольные расширения BGP согласовываются во время создания, узел BGP может префикс информации о доступности сетевого уровня (NLRI), которую он объявляет, префиксом семейства адресов. Эти семейства включают IPv4 (по умолчанию), IPv6, виртуальные частные сети IPv4/IPv6 и многоадресную рассылку BGP. BGP все чаще используется в качестве обобщенного протокола сигнализации для передачи информации о маршрутах, которые могут не быть частью глобального Интернета, например о VPN. [10]
Для принятия решений в своих операциях с узлами узел BGP использует простой конечный автомат (FSM), который состоит из шести состояний: режим ожидания; Соединять; Активный; ОпенСент; ОткрытьПодтвердить; и Установлен. Для каждого однорангового сеанса реализация BGP поддерживает переменную состояния, которая отслеживает, в каком из этих шести состояний находится сеанс. BGP определяет сообщения, которыми должен обмениваться каждый одноранговый узел, чтобы перевести сеанс из одного состояния в другое.
Первое состояние — это состояние ожидания. В состоянии ожидания BGP инициализирует все ресурсы, отклоняет все входящие попытки подключения BGP и инициирует TCP-соединение с одноранговым узлом. Второе состояние — Connect. В состоянии Connect маршрутизатор ожидает завершения TCP-соединения и в случае успеха переходит в состояние OpenSent. В случае неудачи он запускает таймер ConnectRetry и переходит в активное состояние по истечении срока действия. В активном состоянии маршрутизатор сбрасывает таймер ConnectRetry на ноль и возвращается в состояние Connect. В состоянии OpenSent маршрутизатор отправляет сообщение Open и ожидает его в ответ, чтобы перейти в состояние OpenConfirm. Происходит обмен сообщениями Keepalive, и после успешного получения маршрутизатор переходит в состояние «Установлено». В состоянии «Установлено» маршрутизатор может отправлять и получать: Keepalive; Обновлять; и уведомительные сообщения своему партнеру и от него.
В простейшем случае все маршрутизаторы в одной AS, участвующие в маршрутизации BGP, должны быть настроены в полносвязной сети: каждый маршрутизатор должен быть настроен как одноранговый по отношению к каждому другому маршрутизатору. Это вызывает проблемы с масштабированием, поскольку количество необходимых подключений растет квадратично с количеством задействованных маршрутизаторов. Чтобы облегчить эту проблему, BGP реализует два варианта: отражатели маршрутов (RFC 4456) и конфедерации BGP (RFC 5065). Следующее обсуждение базовой обработки обновлений предполагает полную сетку iBGP.
Данный маршрутизатор BGP может принимать обновления информации о достижимости сетевого уровня (NLRI) от нескольких соседей и объявлять NLRI тому же или другому набору соседей. Процесс BGP поддерживает несколько баз маршрутной информации :
RIB: основная таблица базовой информации о маршрутизации маршрутизатора .Loc-RIB: локальная база информации маршрутизации BGP поддерживает свою собственную главную таблицу маршрутизации отдельно от основной таблицы маршрутизации маршрутизатора.Adj-RIB-In: Для каждого соседа процесс BGP поддерживает концептуальную базу информации о соседней маршрутизации , входящую , содержащую NLRI, полученный от соседа.Adj-RIB-Out: Для каждого соседа процесс BGP поддерживает концептуальную базу информации о смежной маршрутизации , исходящую , содержащую NLRI, отправляемый соседу.Физическое хранилище и структура этих концептуальных таблиц определяются разработчиком кода BGP. Их структура не видна другим маршрутизаторам BGP, хотя их обычно можно запросить с помощью команд управления на локальном маршрутизаторе. Например, весьма распространено хранение Adj-RIB-Inи Adj-RIB-Outthe 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 — это теги атрибутов, которые можно применять к входящим или исходящим префиксам для достижения какой-либо общей цели. [13] Хотя принято говорить, что BGP позволяет администратору устанавливать политику обработки префиксов интернет-провайдерами, на самом деле это, строго говоря, невозможно. Например, в BGP изначально не предусмотрена концепция, позволяющая одной AS сообщать другой AS ограничить рекламу префикса только клиентам пирингового узла в Северной Америке. Вместо этого интернет-провайдер обычно публикует список известных или частных сообществ с описанием каждого из них, что по сути становится соглашением о том, как следует обращаться с префиксами.
Примеры общих сообществ включают в себя:
Интернет-провайдер может заявить, что любые маршруты, полученные от клиентов, со следующими примерами:
Клиент просто настраивает свою конфигурацию, чтобы включить правильное сообщество или сообщества для каждого маршрута, а интернет-провайдер несет ответственность за контроль над тем, кому рекламируется префикс. Конечный пользователь не имеет технической возможности обеспечить соблюдение правильных действий интернет-провайдера, хотя проблемы в этой области, как правило, редки и случайны. [15] [16]
Конечные клиенты обычно используют сообщества BGP (обычно ASN:70,80,90,100) для управления локальными предпочтениями, которые интернет-провайдер назначает рекламируемым маршрутам вместо использования MED (эффект аналогичен). Атрибут сообщества является транзитивным, но сообщества, применяемые клиентом, очень редко распространяются за пределы AS следующего перехода. Не все интернет-провайдеры предоставляют свои сообщества публике. [17]
Расширенный атрибут сообщества BGP был добавлен в 2006 году [18] для расширения диапазона таких атрибутов и обеспечения структурирования атрибутов сообщества с помощью поля типа. Расширенный формат состоит из одного или двух октетов для поля типа, за которыми следуют семь или шесть октетов для соответствующего содержимого атрибута сообщества. Определение этого расширенного атрибута сообщества задокументировано в RFC 4360. IANA администрирует реестр типов расширенных сообществ BGP. [19] Атрибут Extended Communities сам по себе является транзитивным необязательным атрибутом BGP. Бит в поле типа внутри атрибута определяет, имеет ли закодированное расширенное сообщество транзитивный или нетранзитивный характер. Поэтому реестр IANA предоставляет разные диапазоны номеров для типов атрибутов. Благодаря расширенному диапазону атрибутов его использование может быть разнообразным. RFC 4360 в качестве примера определяет «двуоктетное расширенное сообщество, специфичное для AS», «расширенное сообщество, специфичное для адреса IPv4», «непрозрачное расширенное сообщество», «целевое сообщество маршрута» и «сообщество источника маршрута». В ряде проектов BGP QoS также используется структура расширенного атрибута сообщества для междоменной сигнализации QoS. [20]
С введением 32-битных номеров AS сразу стали очевидны некоторые проблемы с атрибутом сообщества, который определяет только 16-битное поле ASN, что предотвращает сопоставление между этим полем и реальным значением ASN. Начиная с RFC 7153, расширенные сообщества совместимы с 32-битными ASN. RFC 8092 и RFC 8195 вводят атрибут Large Community длиной 12 байт, разделенный на три поля по 4 байта каждое (AS:function:parameter). [21]
MED, определенные в основном стандарте BGP, изначально предназначались для того, чтобы показывать другой соседней AS предпочтение рекламной AS в отношении того, какой из нескольких каналов является предпочтительным для входящего трафика. Другое применение MED — это объявление значения (обычно основанного на задержке) нескольких AS, присутствующих в IXP , которое они навязывают для отправки трафика в какой-либо пункт назначения.
Некоторые маршрутизаторы (например, Juniper) используют метрику из OSPF для установки MED.
Примеры использования MED с BGP при экспорте в BGP на Juniper SRX
# run show ospf маршрут Топология по умолчанию Таблица маршрутов: Префикс Путь Маршрут NH Метрика Следующий переход Следующий переход Тип Тип Интерфейс Адрес/LSP 10.32.37.0/24 Inter Discard IP 16777215 10.32.37.0/26 Внутрисетевой IP 101 ge-0/0/1.0 10.32 .37.241 10.32.37.64/26 Внутрисетевой IP 102 ge-0/0/1.0 10.32.37.241 10.32.37.128/26 Внутрисетевой IP 101 ge-0/0/1.0 10.32.37.241 # показать маршрут рекламного протокола bgp 10.32.94.169 Префикс Nexthop MED Lclpref AS path * 10.32.37.0/24 Self 16777215 I * 10.32.37.0/26 Self 101 I * 10.32.37.64/26 Self 102 I * 10.32.37.128/ 26 Я 101 Я Примечание. «Маркер» и «Длина» в примерах опущены.
Пример открытого сообщения
Тип: Открытое сообщение (1)Версия: 4Мой АС: 64496Время удержания: 90Идентификатор BGP: 192.0.2.254Дополнительные параметры Длина: 16Дополнительные параметры: Возможности: возможность расширения нескольких протоколов (1) Возможности: возможность обновления маршрута (2) Возможности: возможность обновления маршрута (Cisco) (128)Отправляются только изменения, после первоначального обмена отправляются только различия (добавление/изменение/удаление).
Пример сообщения ОБНОВЛЕНИЕ
Тип: Сообщение ОБНОВЛЕНИЕ (2)Длина отозванных маршрутов: 0Общая длина атрибута пути: 25Атрибуты пути ПРОИСХОЖДЕНИЕ: IGP AS_PATH: 64500 СЛЕДУЮЩИЙ_ХОП: 192.0.2.254 MULTI_EXIT_DISC: 0Информация о доступности сетевого уровня (NLRI) 192.0.2.0/27 192.0.2.32/27 192.0.2.64/27
Если возникает ошибка, это связано с тем, что одно из полей в сообщении OPEN или UPDATE не совпадает между узлами, например, несоответствие версии BGP, пиринговый маршрутизатор ожидает другой My AS и т. д. Затем маршрутизатор отправляет сообщение уведомления на узел, указывающий причину возникновения ошибки.
Пример сообщения УВЕДОМЛЕНИЯ
Тип: УВЕДОМЛЕНИЕ (3)Код основной ошибки: Ошибка сообщения OPEN (2)Код незначительной ошибки (открытое сообщение): Bad Peer AS (2)Плохой партнер AS: 65200
Сообщения KeepAlive отправляются периодически, чтобы убедиться, что удаленный узел все еще активен. Keepalive следует отправлять с интервалом в одну треть holdtime.
Пример сообщения KEEPALIVE
Тип: Сообщение KEEPALIVE (4)
Определено в RFC 7313.
Позволяет мягко обновлять файлы Adj-RIB-inбез сброса соединения.
Пример сообщения ROUTE-REFRESH
Тип: Сообщение ROUTE-REFRESH (5)Идентификатор семейства адресов (AFI): IPv4 (1)Подтип: Обычный запрос на обновление маршрута [RFC2918] с ORF или без него [RFC5291] (0)Последующий идентификатор семейства адресов (SAFI): Одноадресная рассылка (1)
BGP — «наиболее масштабируемый из всех протоколов маршрутизации». [23]
В автономной системе с внутренним BGP (iBGP) все ее узлы iBGP должны соединяться друг с другом в полносвязной сети (где все общаются со всеми напрямую). Эта полносвязная конфигурация требует, чтобы каждый маршрутизатор поддерживал сеанс с каждым другим маршрутизатором. В больших сетях такое количество сеансов может снизить производительность маршрутизаторов либо из-за нехватки памяти, либо из-за высоких требований к процессору.
Отражатели маршрутов (RR) уменьшают количество соединений, необходимых в AS. Один маршрутизатор (или два для резервирования) можно сделать RR: другие маршрутизаторы в AS необходимо только настроить как равноправные по отношению к ним. RR предлагает альтернативу логическому полносвязному требованию iBGP. Цель RR – концентрация. Несколько маршрутизаторов BGP могут взаимодействовать с центральной точкой, RR, действующей как сервер RR, а не с каждым другим маршрутизатором в полной ячеистой сети. Все остальные маршрутизаторы iBGP становятся клиентами RR. [24]
Этот подход, аналогичный функции DR/BDR OSPF , обеспечивает крупным сетям дополнительную масштабируемость iBGP. В полностью объединенной сети iBGP из 10 маршрутизаторов 90 отдельных операторов CLI (распределенных по всем маршрутизаторам в топологии) необходимы только для определения удаленного AS каждого узла: управление этим быстро становится головной болью. Топология RR может сократить эти 90 операторов до 18, предлагая жизнеспособное решение для более крупных сетей, администрируемых интернет-провайдерами.
RR — это единственная точка отказа , поэтому для обеспечения резервирования можно настроить как минимум второй RR. Поскольку он является дополнительным партнером для остальных 10 маршрутизаторов, он примерно удваивает количество операторов CLI, требуя в этом случае дополнительных 11 × 2 − 2 = 20 операторов. В многопутевой среде BGP дополнительный RR также может принести пользу сети, увеличивая пропускную способность локальной маршрутизации, если RR действуют как традиционные маршрутизаторы, а не просто в роли выделенного сервера RR.
И RR, и конфедерации сокращают количество одноранговых узлов iBGP для каждого маршрутизатора и, таким образом, уменьшают накладные расходы на обработку. RR — это чисто метод повышения производительности, а конфедерации также можно использовать для реализации более детальной политики.
Серверы RR распространяют маршруты внутри AS на основе следующих правил:
RR и его клиенты образуют кластер . Затем идентификатор кластера прикрепляется к каждому маршруту, объявленному RR к его клиентским или неклиентским узлам. Идентификатор кластера — это совокупный нетранзитивный атрибут BGP, и каждый ресурс записи должен добавлять идентификатор локального кластера в начало списка кластеров, чтобы избежать петель маршрутизации.
Конфедерации представляют собой наборы автономных систем. В обычной практике [25] Интернет в целом видит только один из номеров AS конфедерации. Конфедерации используются в очень больших сетях, где большую AS можно настроить так, чтобы она включала в себя более мелкие и более управляемые внутренние AS.
Конфедеративная AS состоит из нескольких AS. Каждая конфедеративная AS имеет полностью объединенную сеть iBGP и имеет соединения с другими AS внутри конфедерации. Несмотря на то, что эти AS имеют одноранговые узлы eBGP с AS внутри конфедерации, AS обмениваются маршрутизацией, как если бы они использовали iBGP. Таким образом, конфедерация сохраняет информацию о следующем переходе, метрике и локальных предпочтениях. Внешнему миру конфедерация кажется единой AS. С помощью этого решения можно решить проблемы транзитной AS iBGP, поскольку iBGP требует полной сетки между всеми маршрутизаторами BGP: большого количества сеансов TCP и ненужного дублирования маршрутизируемого трафика. [ нужны разъяснения ]
Конфедерации можно использовать вместе с отражателями маршрутов. Как конфедерации, так и отражатели маршрутов могут подвергаться постоянным колебаниям, если не соблюдать определенные правила проектирования, влияющие как на BGP, так и на протокол внутренней маршрутизации. [26]
Эти альтернативы могут создавать собственные проблемы, в том числе следующие:
Кроме того, отражатели маршрутов и конфедерации BGP не предназначены для облегчения настройки маршрутизатора BGP. Тем не менее, это обычные инструменты для опытных сетевых архитекторов BGP. Эти инструменты можно комбинировать, например, в виде иерархии отражателей маршрутов.
Таблицы маршрутизации, управляемые реализацией BGP, постоянно корректируются, чтобы отражать фактические изменения в сети, например, выходы из строя каналов или маршрутизаторов и их возобновление. В сети в целом эти изменения происходят почти постоянно, но для любого конкретного маршрутизатора или канала ожидается, что изменения будут относительно редкими. Если маршрутизатор неправильно настроен или неправильно управляется, он может попасть в быстрый цикл между выключенным и активным состояниями. Этот шаблон повторного вывода и повторного объявления, известный как колебание маршрута , может вызвать чрезмерную активность на всех других маршрутизаторах, которые знают о циклическом объекте, поскольку один и тот же маршрут постоянно вводится и удаляется из таблиц маршрутизации. Конструкция BGP такова, что доставка трафика может не работать во время обновления маршрутов. В Интернете изменение маршрутизации BGP может привести к сбоям в работе на несколько минут.
Функция, известная как демпфирование колебаний маршрутов ( RFC 2439), встроена во многие реализации BGP в попытке смягчить последствия колебаний маршрутов. Без демпфирования чрезмерная активность может вызвать большую нагрузку на маршрутизаторы, что, в свою очередь, может задержать обновления на других маршрутах и, таким образом, повлиять на общую стабильность маршрутизации. При демпфировании колебания маршрута экспоненциально затухают . В первый раз, когда маршрут становится недоступным и быстро появляется снова, демпфирование не вступает в силу, чтобы поддерживать нормальное время переключения при сбое BGP. Во втором случае BGP игнорирует этот префикс в течение определенного периода времени; последующие появления игнорируются экспоненциально дольше. После того, как аномалии прекратились и прошел подходящий период времени для нарушающего маршрута, префиксы можно восстановить с чистого листа. Демпфирование также может смягчить атаки типа «отказ в обслуживании» .
В RFC 2439 также предлагается : Раздел 4 , что демпфирование колебаний маршрута является более желательной функцией, если она реализована в сеансах протокола внешнего пограничного шлюза (сеансы eBGP или просто называемые внешними узлами), а не в сеансах протокола внутреннего пограничного шлюза (сеансы iBGP или просто называемые внутренние коллеги). При таком подходе, когда маршрут меняется внутри автономной системы, он не распространяется на внешние AS — изменение маршрута к eBGP вызовет цепочку изменений для конкретного маршрута по всей магистральной сети. Этот метод также успешно позволяет избежать накладных расходов на демпфирование колебаний маршрута для сеансов iBGP.
Последующие исследования показали, что в некоторых случаях демпфирование колебаний может фактически увеличить время конвергенции и вызвать прерывания соединения, даже если каналы не колеблются. [28] [29] Более того, поскольку магистральные каналы и процессоры маршрутизаторов стали быстрее, некоторые сетевые архитекторы предположили, что демпфирование колебаний может быть не таким важным, как раньше, поскольку изменения в таблице маршрутизации могут обрабатываться маршрутизаторами гораздо быстрее. . [30] Это привело к тому, что Рабочая группа по маршрутизации RIPE написала: «При нынешних реализациях динамического демпфирования BGP применение флэш-демпфирования в сетях интернет-провайдера НЕ рекомендуется. вызовет побочные эффекты для их клиентов и интернет-пользователей контента и услуг их клиентов... Эти побочные эффекты, вполне вероятно, будут хуже, чем воздействие, вызванное просто отсутствием демпфирования закрылков вообще». [31] Улучшение устойчивости без проблем с демпфированием закрылков является предметом текущих исследований. [32] [ нужно обновить ]
Одной из крупнейших проблем, с которыми сталкивается BGP, да и инфраструктура Интернета в целом, является рост таблицы маршрутизации Интернета. Если глобальная таблица маршрутизации вырастет до такой степени, что некоторые старые, менее мощные маршрутизаторы не смогут справиться с требованиями к памяти или нагрузкой на ЦП, необходимой для поддержания таблицы, эти маршрутизаторы перестанут быть эффективными шлюзами между частями Интернета, которые они подключают. Кроме того, что, возможно, еще более важно, большие таблицы маршрутизации требуют больше времени для стабилизации после серьезного изменения подключения, в результате чего сетевые службы становятся ненадежными или даже недоступными на это время.
До конца 2001 года глобальная таблица маршрутизации росла в геометрической прогрессии , угрожая в конечном итоге повсеместным нарушением связи. Пытаясь предотвратить это, интернет-провайдеры сотрудничали, чтобы сделать глобальную таблицу маршрутизации как можно меньшей, используя бесклассовую междоменную маршрутизацию (CIDR) и агрегацию маршрутов . Хотя это замедлило превращение таблицы маршрутизации в линейный процесс на несколько лет, с ростом спроса на множественную адресацию со стороны сетей конечных пользователей к середине 2004 года рост снова стал сверхлинейным.
В 2014 году произошло переполнение , подобное Y2K , для тех моделей, которые не были должным образом обновлены.
Хотя полная таблица BGP IPv4 по состоянию на август 2014 года [update](512 тыс. дней) [33] [34] превышала 512 000 префиксов, [35] многие старые маршрутизаторы имели ограничение в 512 тыс. (512 000–524 288) [36] [37] маршрутизации записи таблицы. 12 августа 2014 г. сбои в работе, вызванные заполнением таблиц, затронули, в частности, eBay , LastPass и Microsoft Azure . [38] Ряд широко используемых маршрутизаторов Cisco имели TCAM , разновидность высокоскоростной памяти с адресацией по содержимому , для хранения объявленных маршрутов BGP. На затронутых маршрутизаторах TCAM по умолчанию распределялся как 512 тыс. маршрутов IPv4 и 256 тыс. маршрутов IPv6. Хотя заявленное количество объявленных маршрутов IPv6 составляло всего около 20 тыс., количество рекламируемых маршрутов IPv4 достигло предела по умолчанию, что вызвало побочный эффект , поскольку маршрутизаторы пытались компенсировать проблему, используя медленную программную маршрутизацию (в отличие от быстрой аппаратной маршрутизации через TCAM). ). Основной метод решения этой проблемы заключается в том, что операторы изменяют распределение TCAM, чтобы разрешить больше записей IPv4, путем перераспределения части TCAM, зарезервированной для маршрутов IPv6, что требует перезагрузки на большинстве маршрутизаторов. Проблема 512k была предсказана рядом ИТ-специалистов. [39] [40] [41]
Фактическим распределением, которое привело к увеличению числа маршрутов выше 512 тыс., стало объявление около 15 000 новых маршрутов в короткие сроки, начиная с 07:48 UTC. Почти все эти маршруты были к Verizon Autonomous Systems 701 и 705, созданные в результате дезагрегации более крупных блоков, введения тысяч новых / 24 маршрутов и доведения таблицы маршрутизации до 515 000 записей. Новые маршруты, судя по всему, были объединены в течение 5 минут, но нестабильность в Интернете, судя по всему, сохранялась в течение нескольких часов. [42] Даже если бы Verizon не стал причиной превышения таблицы маршрутизации 512 тыс. записей во время короткого всплеска, это вскоре произошло бы в результате естественного роста.
Суммирование маршрутов часто используется для улучшения агрегации глобальной таблицы маршрутизации BGP, тем самым уменьшая необходимый размер таблицы в маршрутизаторах AS. Предположим, что AS1 выделено большое адресное пространство 172.16.0.0/16 , это будет считаться одним маршрутом в таблице, но из-за требований клиента или в целях организации трафика 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 , они будут отброшены или ICMP - сообщение о недостижимости пункта назначения будет отправлено обратно на маршрутизаторы AS2 (а не AS1, как раньше), поскольку 172.16.192.0/18 не находится в таблицу маршрутизации.
В спецификации RFC 1771 BGP-4 номера AS закодированы в 16 битах, что соответствует 64 510 возможным общедоступным номерам AS. [a] В 2011 году только 15 000 номеров AS все еще были доступны, и прогнозы [43] предполагали полное истощение доступных номеров AS в сентябре 2013 года.
RFC 6793 расширяет кодировку AS с 16 до 32 бит, [b] что теперь позволяет использовать до 4 миллиардов доступных AS. Дополнительный частный диапазон AS также определен в RFC 6996. [c] Чтобы разрешить обход групп маршрутизаторов, которые не могут управлять этими новыми номерами ASN, используется новый атрибут AS4_PATH (необязательный транзитивный). Присвоение 32-битных ASN началось в 2007 году.
Еще одним фактором, способствующим росту таблицы маршрутизации, является необходимость балансировки нагрузки в многодомных сетях. Балансировка входящего трафика в многосетевой сети по множеству входящих путей — нетривиальная задача из-за ограничений процесса выбора маршрута BGP. Для многодомной сети, если она объявляет одни и те же сетевые блоки всем своим узлам BGP, результатом может быть то, что один или несколько ее входящих каналов становятся перегруженными, в то время как другие каналы остаются недостаточно загруженными, поскольку все внешние сети выбрали этот вариант. набор перегруженных путей как оптимальный. Как и большинство других протоколов маршрутизации, BGP не обнаруживает перегрузку.
Чтобы обойти эту проблему, администраторы BGP этой многосетевой сети могут разделить большой непрерывный блок IP-адресов на более мелкие блоки и настроить объявление маршрута так, чтобы разные блоки выглядели оптимально на разных путях, чтобы внешние сети выбирали разные пути для достижения разных путей. блоки этой многодомной сети. В таких случаях количество маршрутов увеличится, как показано в глобальной таблице BGP.
Одним из способов решения проблемы таблицы маршрутизации, связанной с балансировкой нагрузки, является развертывание шлюзов протокола разделения локаторов/идентификаторов (BGP/LISP) в точке обмена Интернетом , чтобы обеспечить возможность управления входящим трафиком по нескольким каналам. Этот метод не увеличивает количество маршрутов, отображаемых в глобальной таблице BGP.
По своей конструкции маршрутизаторы, на которых работает BGP, по умолчанию принимают объявленные маршруты от других маршрутизаторов BGP. Это обеспечивает автоматическую и децентрализованную маршрутизацию трафика через Интернет, но также делает Интернет потенциально уязвимым для случайных или злонамеренных сбоев, известных как перехват BGP . Ввиду того, насколько BGP встроен в базовые системы Интернета, а также количества различных сетей, управляемых множеством различных организаций, которые в совокупности составляют Интернет, исправление этой уязвимости (например, путем введения использования криптографических ключей для проверки идентичность маршрутизаторов BGP) является технически и экономически сложной проблемой. [44]
Многопротокольные расширения для BGP (MBGP), иногда называемые многопротокольными BGP или многоадресными BGP и определенные в RFC 4760, представляют собой расширение BGP, которое позволяет параллельно распределять различные типы адресов (известные как семейства адресов). В то время как стандартный BGP поддерживает только одноадресные адреса IPv4, многопротокольный BGP поддерживает адреса IPv4 и IPv6, а также варианты одноадресной и многоадресной рассылки каждого из них. Многопротокольный BGP позволяет обмениваться информацией о топологии IP-маршрутизаторов с поддержкой многоадресной рассылки отдельно от топологии обычных одноадресных маршрутизаторов IPv4. Таким образом, это позволяет использовать топологию многоадресной маршрутизации, отличную от топологии одноадресной маршрутизации. Хотя MBGP обеспечивает обмен информацией о междоменной многоадресной маршрутизации, для построения деревьев и пересылки многоадресного трафика необходимы другие протоколы, такие как семейство протокольно-независимой многоадресной рассылки.
Многопротокольный BGP также широко применяется в случае MPLS L3 VPN для обмена метками VPN, полученными для маршрутов от сайтов клиентов через сеть MPLS, чтобы различать разные сайты клиентов, когда трафик с других сайтов клиентов поступает к провайдеру . крайний маршрутизатор для маршрутизации.
Еще одним расширением BGP является многопутевая маршрутизация . Обычно для этого требуется идентичный MED, вес, источник и путь AS, хотя некоторые реализации предоставляют возможность ослабить проверку пути AS, чтобы ожидать только равной длины пути, а не ожидаемого совпадения фактических номеров AS в пути. Затем это можно расширить с помощью таких функций, как dmzlink-bw от Cisco, который обеспечивает соотношение распределения трафика на основе значений пропускной способности, настроенных на отдельных каналах.
BGP4 является стандартом для интернет-маршрутизации и требуется от большинства интернет-провайдеров (ISP) для установления маршрутизации между собой. Очень крупные частные IP-сети внутренне используют BGP. Примером использования является объединение нескольких крупных сетей с открытым кратчайшим путем (OSPF), когда OSPF сам по себе не масштабируется до требуемого размера. Другая причина использования BGP — это множественная адресация сети для лучшей избыточности либо для нескольких точек доступа к одному интернет-провайдеру, либо к нескольким интернет-провайдерам.
Маршрутизаторы, особенно небольшие, предназначенные для использования в небольших или домашних офисах (SOHO), могут не поддерживать поддержку BGP. Другим коммерческим маршрутизаторам может потребоваться специальный исполняемый образ программного обеспечения, поддерживающий BGP, или лицензия, которая его включает. Устройства, продаваемые как коммутаторы уровня 3, с меньшей вероятностью будут поддерживать BGP, чем устройства, продаваемые как маршрутизаторы , но многие высокопроизводительные коммутаторы уровня 3 могут работать с BGP.
Продукты, продаваемые как коммутаторы, могут иметь ограничение на размер таблиц BGP, которое намного меньше, чем полная таблица Интернета плюс внутренние маршруты. Эти устройства могут быть вполне разумными и полезными при использовании для BGP-маршрутизации некоторой меньшей части сети, например, AS-конфедерации, представляющей одно из нескольких небольших предприятий, связанных между собой магистралью BGP, или небольшого предприятия, которое объявляет маршруты к интернет-провайдеру, но принимает только маршрут по умолчанию и, возможно, небольшое количество агрегированных маршрутов.
Маршрутизатор BGP, используемый только для сети с одной точкой входа в Интернет, может иметь гораздо меньший размер таблицы маршрутизации (и, следовательно, требования к ОЗУ и ЦП), чем многосетевая сеть. Даже простая множественная адресация может иметь скромный размер таблицы маршрутизации. Фактический объем памяти, необходимый для маршрутизатора BGP, зависит от объема информации BGP, которой обмениваются другие узлы BGP, и способа, которым конкретный маршрутизатор хранит информацию BGP. Маршрутизатору, возможно, придется хранить более одной копии маршрута, чтобы он мог управлять различными политиками объявления и принятия маршрутов для конкретной соседней AS. Термин «представление» часто используется для обозначения различных отношений политики на работающем маршрутизаторе.
Если одна реализация маршрутизатора требует больше памяти на маршрут, чем другая реализация, это может быть законным выбором конструкции, предполагающим компромисс между скоростью обработки и памятью. Полная таблица BGP IPv4 по состоянию на август 2015 года [update]содержит более 590 000 префиксов. [35] Крупные интернет-провайдеры могут добавить еще 50% для внутренних и клиентских маршрутов. Опять же, в зависимости от реализации, отдельные таблицы могут храниться для каждого представления другой одноранговой AS.
Известные бесплатные реализации BGP с открытым исходным кодом включают:
Системы для тестирования соответствия BGP, производительности нагрузки или нагрузки поставляются такими поставщиками, как:
Когда нависла перспектива краха системы, мужчины начали записывать идеи решения на обратной стороне салфетки, испачканной кетчупом.
Потом секунда.
Потом третий.
«Протокол трех салфеток», как его в шутку прозвали его изобретатели, вскоре произведет революцию в Интернете.
И хотя проблемы оставались, инженеры рассматривали свое творение как «взлом» или «кладж», что на сленге означает краткосрочное исправление, которое должно быть заменено, как только появится лучшая альтернатива.
Мы показываем, что нынешняя конструкция демпфирования приводит к желаемому поведению только при постоянном колебании маршрута.
Когда количество клапанов невелико, глобальная динамика маршрутизации значительно отклоняется от ожидаемого поведения с более длительной задержкой сходимости.