BGP-annonseringar frå VGW kontra VPC-rutetabellen: kva endrar kva

Eit manglande prefiks i ein VPC-undernetts-rutetabell og eit manglande prefiks på rutaren til kunden er to ulike feil, og berre éin av dei blir reparert inne i AWS-rutetabellane. Den virtuelle private gatewayen annonserer CIDR-blokkene som er knytte til VPC-en sin; rutetabellen til undernettet avgjer kvar ei arbeidslast sender eit svar. Å handsame det andre som ein måte å endre det første på er den vanlegaste feilsvingen i denne diagnosen. Køyr kontrollane nedanfor i rekkjefølgje og hald dei to retningane frå kvarandre.

Namngi tilkoplinga før du les nokon tabell

Ein Site-to-Site-VPN blir avslutta anten på ein virtuell privat gateway eller på ein transit-gateway, og ressurs-ID-ane avgjer kva rutemodell som gjeld. Les dei først: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'. Svaret fortel deg om neste tabell som skal undersøkjast er ein VPC-rutetabell eller ein rutetabell for transit-gatewayen.

Dersom VPN-en er knytt til ein transit-gateway, slutt å handsame VPC-rutetabellen som kontrollplanet. Der peikar VPC-tabellen på gateway-tilkoplinga, og assosiering og propagering skjer i rutetabellen for transit-gatewayen. Å blande dei to visingane gjev sjølvsikre konklusjonar om feil objekt.

Retninga frå AWS til kontoret er ei annonsering

For ei VGW-tilkopling annonserer gatewayen CIDR-blokkene knytte til VPC-en sin til kundegatewayen over BGP. Å leggje til ei einskild undernettsrute, eller å peike ei rute mot ein peer-VPC eller ein eining, legg ikkje til ein annan tilknytt CIDR og blir ikkje vist i den annonseringa. Dersom kontoret manglar eit prefiks, samanlikn lista over mottekne ruter med VPC-tilknytingane før du redigerer nokon rutetabell.

Den enkle regelen har unntak, så hald han innanfor ramma. Ein VPN CloudHub-konfigurasjon kan reannonsere områdeprefiks mellom kundegatewayar, og ein transit-gateway følgjer sine eigne propageringsreglar. Påstanden om at ein VGW berre annonserer sin eigen VPC er ein nyttig standard, ikkje ei lov som dekkjer kvar topologi du møter.

Retninga frå kontoret til AWS er propagering pluss utveljing

I motsett retning lærer VGW-en prefikset til kontoret, men det åleine flyttar ikkje ei arbeidslast. Rutetabellen til undernettet må anten ha propagering slege på for tilkoplinga eller innehalde ei statisk rute til same mål. Når begge finst for eitt prefiks, vinn den statiske ruta, og det lengste prefikssamanfallet køyrer før begge.

Les opphavet i staden for å anta det: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'. Ei oppføring med opphav EnableVgwRoutePropagation kom frå BGP; ei oppføring med opphav CreateRoute vart skriven av eit menneske og vil halde fram med å vinne til nokon slettar henne.

Ein runbook som held dei to retningane frå kvarandre

Noter fire fakta på AWS-sida før du endrar noko: tilkoplingstypen, dei tilknytte VPC-CIDR-ane, opphavet til undernettsruta for det aktuelle prefikset, og tilstanden til tunnelen og BGP. Den same describe-kallinga returnerer VgwTelemetry med talet på godtekne ruter per tunnel, noko som fortel deg om AWS i det heile tok imot nokre ruter. Samanlikn så med det kundeeininga faktisk installerte. Eit prefiks som finst i BGP men manglar i vidaresendingstabellen, er eit lokalt import- eller beste-veg-problem, ikkje eit AWS-rutetabellproblem.

Dersom undernettstabellen heilt manglar prefikset, slå på propagering eller legg til ei statisk rute, og les deretter den same spørjinga på nytt etter propageringsintervallet i staden for å anta at endringa var momentan. Dersom prefikset finst og trafikken framleis sviktar, lat kontrollplanet vere og gå vidare til datastien.

Kva du ikkje skal endre medan du er der

Ikkje slå propagering på eller av på urelaterte rutetabellar for å fikse eitt manglande prefiks, og ikkje legg til ei standardrute for å dekkje over éin manglande CIDR. Begge endringane aukar påverkingsomfanget og gjer neste diagnose vanskelegare. Avgrense redigeringa til tabellen som tener det aktuelle undernettet for arbeidslasta.

Datastien er skild frå alt dette. Tryggingsgrupper er stateful, nettverks-ACL-ar er det ikkje, og ein vertsbrannmur eller ein asymmetrisk returveg kan sleppe trafikk som ruteringa leverte rett. Ei annonsert aggregering autoriserer heller ikkje kvar teneste inni henne, så avgrense tilgang ved policygrensa i staden for å stole på om ei adresse tilfeldigvis blir vist i ei BGP-annonsering.

Lagre før og etter for kvar rutetabellspørjing i endringsloggen. Dersom endringa gjer ting verre, gjenopprett dei førre rutene og stadfest med den same spørjinga, fordi ei tilbakerulling du ikkje kan stadfeste berre er ei gissing.