Сетевой инженер создал следующее для соединения двух производственных VPC в разных регионах (Prod A в eu-west-1 с 10.0.0.0/16 и Prod B в eu-central-1 с 10.1.0.0/16): 1) по одному transit gateway в каждом регионе, 2) предоставил общий доступ и принял transit gateways в производственных аккаунтах, 3) создал пиринговое присоединение между transit gateways, 4) присоединил каждый VPC к transit gateway своего региона, 5) создал таблицы маршрутизации transit gateway и связанные присоединения, 6) добавил статические маршруты в каждую таблицу маршрутизации transit gateway для отправки трафика в удаленный VPC, и 7) включил распространение маршрутов в таблицах маршрутизации VPC. Соединения из Prod A в Prod B завершились неудачей. Что должен сделать инженер для достижения требуемого соединения?

Инженер должен создать маршруты в таблицах маршрутизации VPC, указывающие на Transit Gateway. Текущая конфигурация включает распространение маршрутов в таблицах маршрутизации VPC, но это относится к маршрутам, распространяемым ИЗ VPC В Transit Gateway, а не наоборот. Для того чтобы трафик из VPC мог достичь удаленных сетей через Transit Gateway, в таблицах маршрутизации VPC должны быть явные маршруты, указывающие на Transit Gateway как на следующий хоп для этих удаленных сетей. Диапазон 10.0.0.0/8 включает оба VPC (10.0.0.0/16 и 10.1.0.0/16). Изменение IP-адреса пирингового присоединения не решит проблему маршрутизации в VPC. Удаление статических маршрутов из таблиц маршрутизации Transit Gateway и включение распространения маршрутов может быть полезным, но не является основной причиной сбоя соединения, так как проблема заключается в отсутствии маршрутов в VPC. Динамическое распространение маршрутов между VPC через Transit Gateway не является стандартной функцией, и проблема остается в отсутствии маршрутов в таблицах маршрутизации VPC.