Hvorfor en AWS VGW-subnettrute ikke kan velge én VPN-tunnel

To Site-to-Site VPN-tilkoblinger terminerer på én virtuell privat gateway og annonserer samme grenprefiks. Subnettrutetabellen har én oppføring for det prefikset, som peker på gatewayen, og ingen felt som navngir en tunnel. Preferansen mellom tilkoblingene skjer derfor et sted konsollen ikke kaller ruting. Å vite hvilket lag som eier beslutningen er forskjellen mellom en fungerende standby og en endring som ikke gjør noe.

To lag er i spill: VPC-ruten som sier hvilken gateway, og gatewayens eget tunnelvalg. Å blande dem gir endringer som ser riktige ut i rutetabellen og aldri flytter en pakke.

To lag som ser ut som ett

Subnettruten svarer på ett spørsmål: for denne destinasjonen, hvilken vedheng? Målet er den virtuelle private gatewayen, og metrikken konkurrerer bare med andre ruter i samme tabell. Ingenting i den oppføringen skiller tunnel én fra tunnel to, eller tilkobling A fra tilkobling B. Et mer spesifikt prefiks er en annen destinasjonsmatch, ikke et finere veivalg.

Gatewayen svarer på neste spørsmål: blant tunnelene den holder for det prefikset, hvilken bærer trafikk nå. Den beslutningen kommer fra tunnelhelse og BGP-attributtene som mottas fra kundegatewayen, og den vises aldri i subnettrutetabellen.

Hva VGW faktisk sammenligner

Helse kommer først. En tunnel som er nede, eller en BGP-økt som ikke har kommet opp, taper før noen attributt undersøkes. Derfor endrer det ingenting å sette en sti foran på en tilkobling som allerede feiler.

Blant kvalifiserte stier for samme prefiks foretrekker AWS den kortere AS_PATH. Når to stier er like lange, sammenlignes MED, underlagt den dokumenterte betingelsen om den første AS i stien. Les den publiserte rekkefølgen i stedet for folkeminne-versjonen, fordi folkeminnet vanligvis dropper helsetrinnet og unntaket for statiske ruter. En konsekvens: tre foran-stillinger på reserveforbindelsen gjør den primære strengt kortere, og det er den vanlige måten å uttrykke preferansen på.

Foran-stilling, og når den ikke gjør noe

Foran-stilling skjer i kundegatewayens utgående annonseringer, ikke inne i AWS. Du legger til din egen ASN to eller tre ganger på prefikset du vil at AWS skal unngå, og AWS ser da en lengre sti for den tilkoblingen. Den primære tilkoblingen beholder annonseringen uten foran-stilling. Hvis begge tilkoblinger annonserer fra samme ASN med samme antall foran-stillinger, har du ikke uttrykt noen preferanse.

Kontroller den mottatte stien på AWS-siden etter endringen. En foran-stilling som aldri forlot kundeutstyret ser nøyaktig ut som en AWS ignorerte.

Statiske ruter ignorerer hele argumentet

Hvis tilkoblingen bruker statisk ruting, finnes det ingen AS_PATH å forlenge. AWS dokumenterer statiske VPN-ruter som prioritert foran BGP-lærte ruter for samme prefiks, så et blandet design oppfører seg ikke som et fullt dynamisk. Bestem rutingtypen først, og velg deretter preferansemekanismen som finnes for den.

Med to statiske tilkoblinger som annonserer samme prefiks, er den nyttige spaken prefikset: annonser et mer spesifikt område på tilkoblingen du vil bruke, og aksepter at du endret hvilken destinasjon som matcher, ikke hvilken sti som vinner.

Hvorfor en transitgateway er et annet svar

En transitgateway støtter equal-cost multipath over VPN-vedheng, så to tilkoblinger kan dele trafikken i stedet for at én står standby. Det designet har en annen feilflate: flyter spres over tunneler, og én tunnel som går ned flytter bare deler av lasten. Å kopiere en VGW-oppskrift over på en transitgateway, eller omvendt, skaper forventninger som ingen av plattformene innfrir.

Velg modellen før mekanismen: aktiv og standby med en fastlåst preferanse, eller aktiv og aktiv med ECMP.

Hva du bør verifisere etter at du har satt det opp

Bekreft fire ting i rekkefølge. Subnettrutetabellen løser fortsatt prefikset til den tiltenkte gatewayen. Gatewayen viser begge tunnelene som oppe. Den mottatte AS_PATH på tilkoblingen du vil unngå er lengre enn den andre. Og en reell flyt fra en instans i det subnettet går gjennom den forventede tunnelen, observert i begge ender i stedet for utledet fra en grønn status.

Kjør deretter den godkjente failovertesten og se at den overlevende stien bærer tjenesten. En preferanse som bare finnes i en konfigurasjonsdiff er ennå ikke en preferanse.