BGP-annonseringar från VGW kontra VPC-routtabellen: vad ändrar vad

Ett saknat prefix i en VPC-undernäts-routtabell och ett saknat prefix på kundens router är två olika fel, och bara ett av dem åtgärdas inne i AWS routtabeller. Den virtuella privata gatewayen annonserar de CIDR-block som hör till dess VPC; undernätets routtabell avgör vart en arbetsbelastning skickar ett svar. Att behandla det andra som ett sätt att ändra det första är den vanligaste felaktiga svängen i den här diagnosen. Kör kontrollerna nedan i ordning och håll de två riktningarna åtskilda.

Namnge anslutningen innan du läser någon tabell

En Site-to-Site-VPN avslutas antingen på en virtuell privat gateway eller på en transitgateway, och resurs-ID:na avgör vilken routningsmodell som gäller. Läs dem först: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'. Svaret talar om ifall nästa tabell att undersöka är en VPC-routtabell eller en routtabell för transitgatewayen.

Om VPN:et är anslutet till en transitgateway ska du sluta behandla VPC-routtabellen som kontrollplanet. Där pekar VPC-tabellen på gatewayanslutningen, och associering och spridning sker i routtabellen för transitgatewayen. Att blanda de två vyerna ger självsäkra slutsatser om fel objekt.

Riktningen från AWS till kontoret är en annonsering

För en VGW-anslutning annonserar gatewayen de CIDR-block som hör till dess VPC till kundgatewayen via BGP. Att lägga till en enskild undernätsrutt, eller peka en rutt mot en peerad VPC eller en enhet, lägger inte till ytterligare ett associerat CIDR och visas inte i den annonseringen. Om kontoret saknar ett prefix, jämför listan över mottagna rutter med VPC-associeringarna innan du redigerar någon routtabell.

Den enkla regeln har undantag, så håll den inom ramen. En VPN CloudHub-konfiguration kan återannonsera platsperfixer mellan kundgatewayer, och en transitgateway följer sina egna spridningsregler. Påståendet att en VGW bara annonserar sin egen VPC är en användbar standard, inte en lag som täcker varje topologi du möter.

Riktningen från kontoret till AWS är spridning plus urval

I motsatt riktning lär sig VGW:en kontorets prefix, men det ensamt flyttar inte en arbetsbelastning. Undernätets routtabell måste antingen ha spridning aktiverad för anslutningen eller innehålla en statisk rutt till samma destination. När båda finns för ett prefix vinner den statiska rutten, och den längsta prefixmatchningen körs före båda.

Läs ursprunget i stället för att anta det: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'. En post med ursprung EnableVgwRoutePropagation kom från BGP; en post med ursprung CreateRoute skrevs av en människa och kommer att fortsätta vinna tills någon raderar den.

En runbook som håller de två riktningarna åtskilda

Anteckna fyra fakta på AWS-sidan innan du ändrar något: anslutningstypen, de associerade VPC-CIDR:na, undernätsruttens ursprung för det aktuella prefixet samt tunnelns och BGP:s tillstånd. Samma describe-anrop returnerar VgwTelemetry med antal accepterade rutter per tunnel, vilket talar om ifall AWS överhuvudtaget accepterade några rutter. Jämför sedan med vad kundenheten faktiskt installerade. Ett prefix som finns i BGP men saknas i vidarebefordranstabellen är ett lokalt import- eller bästa-väg-problem, inte ett AWS-routtabellsproblem.

Om undernätstabellen helt saknar prefixet, aktivera spridning eller lägg till en statisk rutt, och läs sedan samma fråga igen efter spridningsintervallet i stället för att anta att ändringen var omedelbar. Om prefixet finns och trafiken fortfarande misslyckas, låt kontrollplanet vara och gå vidare till datavägen.

Vad du inte ska ändra medan du är där

Slå inte på eller av spridning på orelaterade routtabeller för att fixa ett saknat prefix, och lägg inte till en standardrutt för att dölja ett enda saknat CIDR. Båda ändringarna ökar påverkan och gör nästa diagnos svårare. Begränsa redigeringen till tabellen som betjänar det aktuella arbetsbelastningsundernätet.

Datavägen är åtskild från allt detta. Säkerhetsgrupper är stateful, nätverks-ACL:er är det inte, och en värdbrandvägg eller en asymmetrisk returväg kan släppa trafik som routningen levererade korrekt. En annonserad aggregering auktoriserar inte heller varje tjänst inuti den, så begränsa åtkomsten vid policygränsen i stället för att lita på om en adress råkar dyka upp i en BGP-annonsering.

Spara före och efter för varje routtabellsfråga i ändringsloggen. Om ändringen gör saker värre, återställ de tidigare rutterna och bekräfta med samma fråga, eftersom en återrullning du inte kan verifiera bara är en gissning.