VGW:n BGP-ilmoitukset vastaan VPC:n reititystaulu: mikä muuttaa mitä

Puuttuva etuliite VPC:n aliverkon reititystaulusta ja puuttuva etuliite asiakkaan reitittimestä ovat kaksi eri vikaa, ja vain toinen niistä korjataan AWS:n reititystaulujen sisällä. Virtuaalinen yksityinen yhdyskäytävä ilmoittaa VPC:hensä liittyvät CIDR-lohkot; aliverkon reititystaulu päättää, mihin työkuorma lähettää vastauksen. Jälkimmäisen käsitteleminen tapana muuttaa ensimmäistä on yleisin väärä käänne tässä diagnoosissa. Suorita alla olevat tarkistukset järjestyksessä ja pidä kaksi suuntaa erillään.

Nimeä liitäntä ennen kuin luet mitään taulukkoa

Site-to-Site VPN päättyy joko virtuaaliseen yksityiseen yhdyskäytävään tai transit-yhdyskäytävään, ja resurssitunnukset päättävät, mitä reititysmallia sovelletaan. Lue ne ensin: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'. Vastaus kertoo, onko seuraava tarkistettava taulukko VPC:n reititystaulu vai transit-yhdyskäytävän reititystaulu.

Jos VPN on liitetty transit-yhdyskäytävään, lopeta VPC:n reititystaulun käsitteleminen ohjaustasona. Siellä VPC-taulukko osoittaa yhdyskäytävän liitäntään, ja liittäminen ja propagointi tapahtuvat transit-yhdyskäytävän reititystaulussa. Näkymien sekoittaminen tuottaa varmoja johtopäätöksiä väärästä objektista.

Suunta AWS:stä toimistoon on ilmoitus

VGW-liitännän osalta yhdyskäytävä ilmoittaa VPC:hensä liittyvät CIDR-lohkot asiakkaan yhdyskäytävälle BGP:n kautta. Yksittäisen aliverkkoreitin lisääminen tai reitin osoittaminen vertais-VPC:hen tai laitteeseen ei lisää toista liittyvää CIDR:iä eikä näy kyseisessä ilmoituksessa. Jos toimistosta puuttuu etuliite, vertaa vastaanotettujen reittien luetteloa VPC:n liitoksiin ennen minkään reititystaulun muokkaamista.

Yksinkertaisella säännöllä on poikkeuksia, joten pidä se rajauksissaan. VPN CloudHub -järjestely voi ilmoittaa uudelleen sivuston etuliitteitä asiakasyhdyskäytävien välillä, ja transit-yhdyskäytävä noudattaa omia propagointisääntöjään. Väite, että VGW ilmoittaa vain oman VPC:nsä, on hyödyllinen oletusarvo, ei laki, joka kattaa jokaisen kohtaamasi topologian.

Suunta toimistosta AWS:ään on propagointi plus valinta

Vastakkaisessa suunnassa VGW oppii toimiston etuliitteen, mutta se yksin ei siirrä työkuormaa. Aliverkon reititystaulussa on joko oltava propagointi käytössä liitännälle tai siinä on oltava staattinen reitti samaan kohteeseen. Kun molemmat ovat olemassa yhdelle etuliitteelle, staattinen reitti voittaa, ja pisimmän etuliitteen osuma ajetaan ennen kumpaakaan niistä.

Lue alkuperä sen sijaan että olettaisit sen: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'. Alkuperältään EnableVgwRoutePropagation -merkintä tuli BGP:stä; alkuperältään CreateRoute -merkinnän kirjoitti ihminen, ja se voittaa, kunnes joku poistaa sen.

Runbook, joka pitää kaksi suuntaa erillään

Kirjaa neljä tosiasiaa AWS:n puolella ennen kuin muutat mitään: liitännän tyyppi, liittyvät VPC:n CIDR:t, kyseisen etuliitteen aliverkkoreitin alkuperä sekä tunnelin ja BGP:n tila. Sama describe-kutsu palauttaa VgwTelemetryn, jossa on hyväksyttyjen reittien määrä tunnelia kohden, mikä kertoo, hyväksyikö AWS ylipäänsä reittejä. Vertaa sitä sitten siihen, mitä asiakaslaite todella asensi. Etuliite, joka on BGP:ssä mutta puuttuu edelleenlähetystaulusta, on paikallinen tuonti- tai parhaan reitin ongelma, ei AWS:n reititystaulun ongelma.

Jos aliverkkotaulusta puuttuu etuliite kokonaan, ota propagointi käyttöön tai lisää staattinen reitti, ja lue sitten sama kysely uudelleen propagointivälin jälkeen sen sijaan että olettaisit muutoksen olleen välitön. Jos etuliite on olemassa ja liikenne silti epäonnistuu, jätä ohjaustaso rauhaan ja siirry datapolulle.

Mitä ei pidä muuttaa siellä ollessa

Älä kytke propagointia päälle tai pois toisiinsa liittymättömissä reititystauluissa yhden puuttuvan etuliitteen korjaamiseksi äläkä lisää oletusreittiä yhden puuttuvan CIDR:n peittämiseksi. Molemmat muutokset laajentavat vaikutusaluetta ja vaikeuttavat seuraavaa diagnoosia. Rajoita muokkaus taulukkoon, joka palvelee kyseistä työkuorman aliverkkoa.

Datapolku on erillään kaikesta tästä. Turvaryhmät ovat tilallisia, verkon ACL:t eivät, ja isäntäkoneen palomuuri tai epäsymmetrinen paluupolku voi pudottaa liikennettä, jonka reititys toimitti oikein. Ilmoitettu aggregaatti ei myöskään valtuuta jokaista palvelua sen sisällä, joten rajoita pääsyä käytännön rajalla sen sijaan että luottaisit siihen, sattuuko osoite esiintymään BGP-ilmoituksessa.

Tallenna jokaisen reititystaulukyselyn ennen ja jälkeen muutoslokiin. Jos muutos pahentaa tilannetta, palauta aiemmat reitit ja vahvista samalla kyselyllä, sillä palautus, jota et voi varmistaa, on vain arvaus.