Dvě připojení Site-to-Site VPN končí na jedné virtuální soukromé bráně a inzerují stejný prefix pobočky. Tabulka tras podsítě drží jeden záznam pro tento prefix, směřující na bránu, a žádné pole, které by pojmenovalo tunel. Preference mezi připojeními se proto odehrává někde, co konzole neoznačuje jako směrování. Vědět, která vrstva vlastní rozhodnutí, je rozdíl mezi funkční zálohou a změnou, která nic nedělá.

Ve hře jsou dvě vrstvy: trasa ve VPC, která říká kterou bránu, a vlastní volba tunelu samotnou bránou. Jejich záměna vytváří úpravy, které v tabulce tras vypadají správně a nikdy nepohnou paketem.

Dvě vrstvy, které vypadají jako jedna

Trasa podsítě odpovídá na jedinou otázku: pro tento cíl, která přípojka? Jejím cílem je virtuální soukromá brána a její metrika soutěží jen s ostatními trasami ve stejné tabulce. Nic v tomto záznamu nerozlišuje tunel jedna od tunelu dva ani připojení A od připojení B. Konkrétnější prefix je jiná shoda cíle, ne jemnější volba cesty.

Brána odpovídá na další otázku: mezi tunely, které pro tento prefix drží, který nyní nese provoz. To rozhodnutí vychází ze stavu tunelu a z atributů BGP přijatých od zákaznické brány a nikdy se neobjeví v tabulce tras podsítě.

Co VGW skutečně porovnává

Stav je první. Tunel, který je dole, nebo relace BGP, která nenaběhla, prohrává dřív, než se prozkoumá jakýkoli atribut. Proto předsazení cesty na připojení, které už selhává, nic nemění.

Mezi způsobilými cestami pro stejný prefix AWS preferuje kratší AS_PATH. Když jsou dvě cesty stejně dlouhé, porovnává MED, s výhradou dokumentované podmínky o prvním AS v cestě. Čtěte zveřejněné pořadí, ne verzi z ústního podání, protože to obvykle vynechává krok stavu a výjimku pro statické trasy. Jeden důsledek: tři předsazení na záložním připojení dělají primární striktně kratší, což je obvyklý způsob, jak preferenci vyjádřit.

Předsazení a kdy nic nedělá

Předsazení se děje ve výchozích inzerátech zákaznické brány, ne uvnitř AWS. Přidáte své ASN dvakrát nebo třikrát k prefixu, kterému se má AWS vyhnout, a AWS pak pro toto připojení vidí delší cestu. Primární připojení si inzerát bez předsazení ponechává. Pokud obě připojení inzerují ze stejného ASN se stejným počtem předsazení, nevyjádřili jste žádnou preferenci.

Po změně zkontrolujte přijatou cestu na straně AWS. Předsazení, které nikdy neopustilo zařízení zákazníka, vypadá přesně jako to, které AWS ignoroval.

Statické trasy ignorují celý argument

Pokud připojení používá statické směrování, není co prodlužovat, žádný AS_PATH. AWS dokumentuje statické trasy VPN jako prioritní před trasami naučenými přes BGP pro stejný prefix, takže smíšený návrh se nechová jako plně dynamický. Nejprve rozhodněte typ směrování, potom zvolte mechanismus preference, který pro něj existuje.

Se dvěma statickými připojeními inzerujícími stejný prefix je užitečnou pákou prefix: inzerujte konkrétnější rozsah na připojení, které chcete použít, a přijměte, že jste změnili, který cíl se shoduje, a ne která cesta vyhraje.

Proč je tranzitní brána jiná odpověď

Tranzitní brána podporuje vícecestnost se stejnými náklady přes připojení VPN, takže dvě připojení mohou sdílet provoz místo toho, aby jedno stálo v záloze. Tento návrh má jinou plochu selhání: toky se rozprostírají přes tunely a výpadek jednoho tunelu přesune jen část zátěže. Kopírování receptu VGW na tranzitní bránu nebo naopak vytváří očekávání, která ani jedna platforma nesplňuje.

Zvolte model před mechanismem: aktivní a záložní s pevně danou preferencí, nebo aktivní a aktivní s ECMP.

Co ověřit po nastavení

Potvrďte čtyři věci v pořadí. Tabulka podsítě stále překládá prefix na zamýšlenou bránu. Brána uvádí oba tunely jako aktivní. Přijatý AS_PATH na připojení, kterému se chcete vyhnout, je delší než ten druhý. A skutečný tok z instance v této podsíti prochází očekávaným tunelem, pozorovaný na obou koncích, ne odvozený ze zeleného stavu.

Potom spusťte schválený test přepnutí a sledujte, jak přeživší cesta nese službu. Preference, která existuje jen v rozdílu konfigurace, ještě není preference.

Související články