BGP-annonseringer fra VGW kontra VPC-rutetabellen: hva endrer hva

Et manglende prefiks i en VPC-undernetts-rutetabell og et manglende prefiks på kundens ruter er to forskjellige feil, og bare én av dem repareres inne i AWS-rutetabellene. Den virtuelle private gatewayen annonserer CIDR-blokkene som er knyttet til VPC-en sin; undernettets rutetabell avgjør hvor en arbeidsbelastning sender et svar. Å behandle det andre som en måte å endre det første er den vanligste feilsvingen i denne diagnosen. Kjør kontrollene nedenfor i rekkefølge og hold de to retningene fra hverandre.

Navngi tilkoblingen før du leser noen tabell

En Site-to-Site-VPN avsluttes enten på en virtuell privat gateway eller på en transit-gateway, og ressurs-ID-ene avgjør hvilken rutemodell som gjelder. Les dem først: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'. Svaret forteller deg om neste tabell som skal undersøkes er en VPC-rutetabell eller en rutetabell for transit-gatewayen.

Hvis VPN-en er knyttet til en transit-gateway, slutt å behandle VPC-rutetabellen som kontrollplanet. Der peker VPC-tabellen på gateway-tilkoblingen, og assosiering og propagering skjer i rutetabellen for transit-gatewayen. Å blande de to visningene gir selvsikre konklusjoner om feil objekt.

Retningen fra AWS til kontoret er en annonsering

For en VGW-tilkobling annonserer gatewayen CIDR-blokkene knyttet til VPC-en sin til kundegatewayen over BGP. Å legge til en enkelt undernettsrute, eller peke en rute mot en peeret VPC eller en enhet, legger ikke til en annen tilknyttet CIDR og vises ikke i den annonseringen. Hvis kontoret mangler et prefiks, sammenlign listen over mottatte ruter med VPC-tilknytningene før du redigerer noen rutetabell.

Den enkle regelen har unntak, så hold den innenfor rammen. En VPN CloudHub-konfigurasjon kan reannonsere områdeprefikser mellom kundegatewayer, og en transit-gateway følger sine egne propageringsregler. Påstanden om at en VGW bare annonserer sin egen VPC er en nyttig standard, ikke en lov som dekker hver topologi du møter.

Retningen fra kontoret til AWS er propagering pluss utvelgelse

I motsatt retning lærer VGW-en kontorets prefiks, men det alene flytter ikke en arbeidsbelastning. Undernettets rutetabell må enten ha propagering aktivert for tilkoblingen eller inneholde en statisk rute til samme destinasjon. Når begge finnes for ett prefiks, vinner den statiske ruten, og det lengste prefikssammenfallet kjører før begge.

Les opprinnelsen i stedet for å anta den: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'. En oppføring med opprinnelse EnableVgwRoutePropagation kom fra BGP; en oppføring med opprinnelse CreateRoute ble skrevet av et menneske og vil fortsette å vinne til noen sletter den.

En runbook som holder de to retningene fra hverandre

Noter fire fakta på AWS-siden før du endrer noe: tilkoblingstypen, de tilknyttede VPC-CIDR-ene, undernettsrutens opprinnelse for det aktuelle prefikset, og tilstanden til tunnelen og BGP. Det samme describe-kallet returnerer VgwTelemetry med antall aksepterte ruter per tunnel, noe som forteller deg om AWS i det hele tatt aksepterte ruter. Sammenlign så med det kundeenheten faktisk installerte. Et prefiks som finnes i BGP men mangler i videresendingstabellen, er et lokalt import- eller beste-vei-problem, ikke et AWS-rutetabellproblem.

Hvis undernetstabellen helt mangler prefikset, aktiver propagering eller legg til en statisk rute, og les deretter den samme spørringen på nytt etter propageringsintervallet i stedet for å anta at endringen var umiddelbar. Hvis prefikset finnes og trafikken fortsatt feiler, la kontrollplanet være og gå videre til datastien.

Hva du ikke skal endre mens du er der

Ikke slå propagering på eller av på urelaterte rutetabeller for å fikse ett manglende prefiks, og ikke legg til en standardrute for å dekke over én manglende CIDR. Begge endringene øker påvirkningsomfanget og gjør neste diagnose vanskeligere. Begrens redigeringen til tabellen som betjener det aktuelle arbeidsbelastnings-undernettet.

Datastien er atskilt fra alt dette. Sikkerhetsgrupper er stateful, nettverks-ACL-er er det ikke, og en vertsbrannmur eller en asymmetrisk returvei kan slippe trafikk som rutingen leverte riktig. En annonsert aggregering autoriserer heller ikke hver tjeneste inni den, så begrens tilgang ved policygrensen i stedet for å stole på om en adresse tilfeldigvis vises i en BGP-annonsering.

Lagre før og etter for hver rutetabellspørring i endringsloggen. Hvis endringen gjør ting verre, gjenopprett de forrige rutene og bekreft med den samme spørringen, fordi en tilbakerulling du ikke kan verifisere bare er en gjetning.