Защо маршрут в подмрежата на AWS VGW не може да избере един VPN тунел
Маршрут в подмрежата към виртуалния частен шлюз не може да назове един от своите тунели. Къде живее истинското предпочитание: AS_PATH, състоянието на тунелите и статичните маршрути.
Две 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 на връзката, която искате да избегнете, е по-дълъг от другия. И реален поток от инстанция в тази подмрежа преминава през очаквания тунел, наблюдаван от двата края, а не изведен от зелен статус.
След това изпълнете одобрения тест за превключване и наблюдавайте как оцелялият път носи услугата. Предпочитание, което съществува само в разлика в конфигурацията, още не е предпочитание.