Почему маршрут подсети в AWS VGW не может выбрать один туннель VPN

Два подключения Site-to-Site VPN завершаются на одном виртуальном частном шлюзе и анонсируют один и тот же префикс филиала. В таблице маршрутов подсети есть одна запись для этого префикса, указывающая на шлюз, и ни одного поля, которое называло бы туннель. Поэтому предпочтение между подключениями возникает там, где консоль не называет это маршрутизацией. Знание того, какой уровень владеет решением, — это разница между работающим резервом и изменением, которое ничего не делает.

В игре два уровня: маршрут в VPC, указывающий шлюз, и собственный выбор туннеля самим шлюзом. Их смешение даёт изменения, которые выглядят правильными в таблице маршрутов и никогда не перемещают ни один пакет.

Два уровня, которые выглядят как один

Маршрут подсети отвечает на один вопрос: для этого назначения какое присоединение? Его цель — виртуальный частный шлюз, а метрика конкурирует только с другими маршрутами той же таблицы. Ничто в этой записи не отличает туннель один от туннеля два или подключение A от подключения B. Более конкретный префикс — это другое совпадение назначения, а не более тонкий выбор пути.

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

Что VGW на самом деле сравнивает

Состояние идёт первым. Туннель, который опущен, или сессия BGP, которая не поднялась, проигрывает прежде, чем будет рассмотрен любой атрибут. Поэтому добавление пути в начало на подключении, которое уже сбоит, ничего не меняет.

Среди допустимых путей для одного префикса AWS предпочитает более короткий AS_PATH. Когда два пути равны по длине, он сравнивает MED, с учётом документированного условия о первом AS в пути. Читайте опубликованный порядок, а не фольклорную версию, потому что фольклор обычно опускает шаг состояния и исключение для статических маршрутов. Одно следствие: три добавления в начало на резервном подключении делают основное строго короче, и это обычный способ выразить предпочтение.

Добавление в начало, и когда оно ничего не делает

Добавление в начало происходит в исходящих анонсах клиентского шлюза, а не внутри AWS. Вы добавляете свой ASN два или три раза к префиксу, который AWS должен избегать, и тогда AWS видит более длинный путь для этого подключения. Основное подключение сохраняет анонс без добавления. Если оба подключения анонсируют из одного ASN с одинаковым числом добавлений, вы не выразили никакого предпочтения.

Проверьте полученный путь на стороне AWS после изменения. Добавление, которое так и не покинуло устройство клиента, выглядит точно так же, как то, которое AWS проигнорировал.

Статические маршруты игнорируют весь аргумент

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

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

Почему транзитный шлюз — другой ответ

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

Выберите модель до механизма: активный и резервный с закреплённым предпочтением или активный и активный с ECMP.

Что проверить после настройки

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

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