Varför en AWS VGW-subnätväg inte kan välja en enda VPN-tunnel

Två Site-to-Site VPN-anslutningar terminerar på en och samma virtuella privata gateway och annonserar samma grenprefix. Subnätets rutttabell har en post för det prefixet, som pekar på gatewayen, och inget fält som namnger en tunnel. Preferensen mellan anslutningarna sker därför någonstans som konsolen inte kallar routning. Att veta vilket lager som äger beslutet är skillnaden mellan en fungerande standby och en ändring som inte gör något.

Två lager är i spel: VPC-vägen som säger vilken gateway, och gatewayens eget tunnelval. Att blanda ihop dem ger ändringar som ser korrekta ut i rutttabellen och aldrig flyttar ett paket.

Två lager som ser ut som ett

Subnätvägen svarar på en enda fråga: för den här destinationen, vilken koppling? Målet är den virtuella privata gatewayen, och dess metrik konkurrerar bara med andra rutter i samma tabell. Inget i posten skiljer tunnel ett från tunnel två, eller anslutning A från anslutning B. Ett mer specifikt prefix är en annan destinationsmatchning, inte ett finare vägval.

Gatewayen svarar på nästa fråga: bland tunnlarna den håller för det prefixet, vilken bär trafik nu. Det beslutet kommer från tunnelhälsa och de BGP-attribut som tas emot från kundgatewayen, och det syns aldrig i subnätets rutttabell.

Vad VGW faktiskt jämför

Hälsa kommer först. En tunnel som ligger nere, eller en BGP-session som inte kommit upp, förlorar innan något attribut undersöks. Därför ändrar det ingenting att sätta en väg framför på en anslutning som redan misslyckas.

Bland kvalificerade vägar för samma prefix föredrar AWS den kortare AS_PATH. När två vägar är lika långa jämför den MED, med förbehåll för det dokumenterade villkoret om den första AS i vägen. Läs den publicerade ordningen i stället för folksago-versionen, eftersom folksagan oftast hoppar över hälsosteget och undantaget för statiska rutter. En konsekvens: tre framflyttningar på reservanslutningen gör den primära strikt kortare, och det är det vanliga sättet att uttrycka preferensen.

Framflyttning, och när den inte gör något

Framflyttning sker i kundgatewayens utgående annonser, inte inne i AWS. Du lägger till din egen ASN två eller tre gånger på prefixet du vill att AWS ska undvika, och AWS ser då en längre väg för den anslutningen. Den primära anslutningen behåller annonsen utan framflyttning. Om båda anslutningarna annonserar från samma ASN med samma antal framflyttningar har du inte uttryckt någon preferens.

Kontrollera den mottagna vägen på AWS-sidan efter ändringen. En framflyttning som aldrig lämnade kundutrustningen ser exakt ut som en som AWS ignorerade.

Statiska rutter ignorerar hela argumentet

Om anslutningen använder statisk routning finns ingen AS_PATH att förlänga. AWS dokumenterar statiska VPN-rutter som prioriterade framför BGP-inlärda rutter för samma prefix, så en blandad design beter sig inte som en helt dynamisk. Bestäm routingtypen först och välj sedan den preferensmekanism som finns för den.

Med två statiska anslutningar som annonserar samma prefix är den användbara hävstången prefixet: annonsera ett mer specifikt intervall på den anslutning du vill använda, och acceptera att du ändrade vilken destination som matchar, inte vilken väg som vinner.

Varför en transitgateway är ett annat svar

En transitgateway stöder equal-cost multipath över VPN-kopplingar, så två anslutningar kan dela trafiken i stället för att en står standby. Den designen har en annan felyta: flöden sprids över tunnlar, och en tunnel som går ner flyttar bara en del av lasten. Att kopiera ett VGW-recept till en transitgateway, eller tvärtom, skapar förväntningar som ingen av plattformarna infriar.

Välj modellen före mekanismen: aktiv och standby med en fastlåst preferens, eller aktiv och aktiv med ECMP.

Vad du bör verifiera när du har ställt in det

Bekräfta fyra saker i ordning. Subnätets tabell löser fortfarande prefixet till den avsedda gatewayen. Gatewayen listar båda tunnlarna som uppe. Den mottagna AS_PATH på anslutningen du vill undvika är längre än den andra. Och ett verkligt flöde från en instans i det subnätet går genom den förväntade tunneln, observerat i båda ändar i stället för härlett från en grön status.

Kör sedan det godkända failovertestet och se den överlevande vägen bära tjänsten. En preferens som bara finns i en konfigurationsdiff är ännu inte en preferens.