маршрутизация BGP

[srimal99]

![Screenshot 2026-01-09 at 2.00.14 pm.png] Здравствуйте, эксперты!
Здравствуйте, команда!
В настоящее время у нас есть
две облачные среды (AWS и GCP)
, подключенные к нашим
конечным устройствам COLO через два транзитных концентратора
, с включенной функцией
ECMP
по всем путям.
Существующая конструкция
В настоящее время сеть работает в режиме
«активный/активный»
на обоих транзитных концентраторах.
Сейчас возникла необходимость перехода этой конфигурации на модель
«активный/резервный
».
Архитектура транзитного концентратора
Транзитный узел 1 (TR-HUB1)
Устройства:
Nexus 9K (SW1 и SW2),
настроенные как
vPC-узлы
Протокол:
iBGP
VRF:
AWS VRF
GCP VRF
Конечная точка VRF
В качестве протокола используется BGP
Для каждого коммутатора используются отдельные исходные VLAN:
VLAN 101 → TR-HUB1-SW1
VLAN 102 → TR-HUB1-SW2
Транзитный концентратор 2 (TR-HUB2)
Устройства:
коммутаторы Arista (SW1 и SW2)
MLAG:
не настроен
Протокол:
iBGP
VRF:
AWS VRF
GCP VRF
VRF конечной точки
Подключение конечных точек
Конечные устройства COLO подключены к обоим транзитным узлам.
Для обеспечения масштабируемости и роста в будущем
планируется установить дополнительные
«синие соединения»
между
транзитными узлами и конечными устройствами
, чтобы увеличить пропускную способность и отказоустойчивость.
Требование
Нам необходима возможность
контролировать трафик, исходящий из облака (например, AWS),
таким образом, чтобы:
трафик мог
перенаправляться на
TR-HUB1 или
TR-HUB2
при необходимости (техобслуживание, сбой или эксплуатационные потребности)
Конструкция должна оставаться
масштабируемой
и
совместимой с планируемым расширением синих каналов связи.
Вопросы
Можно ли реализовать эту предпочтительную маршрутизацию трафика с помощью
атрибутов BGP на маршрутизаторах транзитного концентратора
?
Необходимо ли
перенастраивать VLAN с HSRP
, или это требование может быть выполнено
исключительно с помощью инженерии трафика на основе BGP
, даже с учетом будущих синих каналов?

[paul driver]

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

[Edgar Benavente]

The simplest way to prioritize your traffic is to consider "normal conditions" and/or "contingency conditions" scenarios and let the protocol handle them automatically. The suggestion is:

• For traffic from the cloud, you could use AS Prepend.
• For outbound traffic to your ISP, use Local Preference. Both scenarios include traffic selection. Regards

[Cristian Matei]

Привет, В сетевом проектировании чем больше можно достичь с меньшим количеством настроек, без их избытка, тем лучше, это называется принципом KISS. Итак, учитывая, что у вас есть iBGP, я рекомендую использовать Local Preference, чтобы обеспечить следующее: 1. Выберите, какой из путей является основным, а какой — второстепенным и т. д. 2. Убедитесь, что трафик слева направо и справа налево симметричен, то есть следует по тому же предпочтительному пути, который вы выбрали. Спасибо, Кристиан.

[srimal99]

BGP настраивается в WAN, а iBGP — между внутренними маршрутизаторами. Между одноранговыми узлами Nexus vPC не настроен механизм резервирования уровня 2 (например, HSRP). Топология выглядит следующим образом: Облако
eBGP
Транзитный концентратор 1 / Транзитный концентратор 2
Транзитный концентратор 1
iBGP
Транзитный концентратор 2
Транзитный узел 1 / Транзитный узел 2
eBGP
Конечные устройства На коммутаторах транзитного концентратора BGP настраивается с использованием интерфейсов исходной VLAN в каждом VRF . Кроме того, каждый коммутатор транзитного концентратора использует выделенную VLAN для каждого пиринга BGP. Например: Транзитный узел 1 — коммутатор 1 использует VLAN 101 (/30) в качестве исходного интерфейса BGP
Транзитный узел 1 – коммутатор 2 использует VLAN 102 (/30) для другого пиринга BGP
оба коммутатора являются частью транзитного узла в одном и том же стойке. В этой конструкции намеренно не используется HSRP или любой другой протокол резервирования шлюзов уровня 2. Текущая конфигурация развернута в производственной сети и успешно работает. Цель Хотя существующая конструкция является стабильной и функциональной, существует заинтересованность в оптимизации архитектуры с целью снижения загрузки ЦП на коммутаторах транзитного концентратора и перепроектировании поведения BGP для работы в
активной/пассивной
модели, а не в полностью активной. Требуются рекомендации по лучшим практикам или изменениям архитектуры, которые могли бы обеспечить эту оптимизацию без ущерба для стабильности или отказоустойчивости.