BGP-oankundigingen fan VGW tsjin de VPC-routetabel: wat feroaret wat

In ûntbrekkend foarheaksel yn in VPC-subnetroutetabel en in ûntbrekkend foarheaksel op 'e router fan 'e klant binne twa ferskillende storingen, en mar ien fan beide wurdt binnen AWS-routetabellen reparearre. De firtuele privee-poarte kundiget de CIDR-blokken oan dy't by syn VPC hearre; de subnetroutetabel beslút wêr't in wurklast in antwurd hinne stjoert. It twadde behannelje as in manier om it earste te feroarjen is de meast foarkommende ferkearde draai yn dizze diagnoaze. Fier de kontrôles hjirûnder yn folchoarder út en hâld de twa rjochtingen apart.

Neam de oanhechting foardat jo hokker tabel dan ek lêze

In Site-to-Site VPN einiget itsij op in firtuele privee-poarte, itsij op in transito-poarte, en de boarnep-ID's beslisse hokker routemodel jildt. Lês se earst: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'. It antwurd fertelt jo oft de folgjende tabel dy't ûndersocht wurde moat in VPC-routetabel is of in transito-poarte-routetabel.

As it VPN oan in transito-poarte ferbûn is, stopje dan mei it behanneljen fan 'e VPC-routetabel as it kontrôleflak. Dêr wiist de VPC-tabel nei de poarte-oanhechting, en assosjaasje en propagaasje barre yn 'e transito-poarte-routetabel. It mingen fan beide werjeften jout selsbetrouwen konklúzjes oer it ferkearde objekt.

De rjochting fan AWS nei kantoar is in oankundiging

Foar in VGW-oanhechting kundiget de poarte de CIDR-blokken dy't by syn VPC hearre oan 'e poarte fan 'e klant oer BGP. It tafoegjen fan in yndividuele subnetrûte, of it rjochtsjen fan in rûte nei in pear-VPC of in apparaat, foeget gjin oare assosjearre CIDR ta en ferskynt net yn dy oankundiging. As it kantoar in foarheaksel mist, fergelykje dan de list fan ûntfongen rûtes mei de VPC-assosjaasjes foardat jo hokker routetabel dan ek bewurkje.

De ienfâldige regel hat útsûnderingen, hâld him dus binnen syn berik. In VPN CloudHub-opstelling kin sidefoarheaksels op 'e nij oankundigje tusken klantpoarten, en in transito-poarte folget syn eigen propagaasjeregels. De bewearing dat in VGW allinnich syn eigen VPC oankundiget is in nuttige standert, gjin wet dy't elke topology dy't jo tsjinkomme dekt.

De rjochting fan kantoar nei AWS is propagaasje plus seleksje

Yn 'e tsjinoerstelde rjochting leart de VGW it kantoarfoarheaksel, mar dat allinnich ferpleatst gjin wurklast. De subnetroutetabel moat itsij propagaasje ynskeakele hawwe foar de oanhechting, itsij in statyske rûte nei deselde bestemming drage. As beide foar ien foarheaksel bestean, wint de statyske rûte, en de langste-foarheaksel-oerienkomst rint foar beide.

Lês de oarsprong ynstee fan him te ferûnderstellen: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'. In ynfier mei oarsprong EnableVgwRoutePropagation kaam fan BGP; in ynfier mei oarsprong CreateRoute is troch in minske yntype en sil bliuwe winnen oant immen him ferwideret.

In runbook dy't de twa rjochtingen apart hâldt

Skriuw fjouwer feiten oan 'e AWS-kant op foardat jo eat feroarje: it type oanhechting, de assosjearre VPC-CIDR's, de oarsprong fan 'e subnetrûte foar it oangeande foarheaksel, en de tastân fan 'e tunnel en BGP. Deselde describe-oprop jout VgwTelemetry werom mei in tal akseptearre rûtes per tunnel, wat jo fertelt oft AWS dan ek rûtes akseptearre hat. Fergelykje dat dan mei wat it klantapparaat wier ynstallearre hat. In foarheaksel dat yn BGP stiet mar ûntbrekt yn 'e trochstjoertabel is in pleatslik ymport- of bêste-rûte-probleem, net in AWS-routetabelprobleem.

As de subnettabel it foarheaksel hielendal mist, skeakelje propagaasje yn of foegje in statyske rûte ta, en lês dan deselde fraach op 'e nij nei it propagaasje-ynterval ynstee fan oan te nimmen dat de feroaring fuortendaliks wie. As it foarheaksel bestiet en it ferkear dochs mislearret, lit it kontrôleflak gewurde en gean nei it datapaad.

Wat jo net feroarje moatte wylst jo dêr binne

Skeakelje propagaasje net oan of út op net-relatearre routetabellen om ien ûntbrekkend foarheaksel te reparearjen, en foegje gjin standertrûte ta om ien ôfwêzige CIDR te bedekken. Beide feroaringen fergrutsje it ynfloedberik en meitsje de folgjende diagnoaze dreger. Behein de bewurking ta de tabel dy't it oangeande wurklast-subnet betsjinnet.

It datapaad is los fan dit alles. Feiligensgroepen binne steatbefêstige, netwurk-ACL's net, en in host-firewall of in asymmetrysk werompaad kin ferkear falle litte dat routing korrekt levere hat. In oankundige aggregaat jouwt ek net elke tsjinst deryn tastimming, beheinje dêrom tagong by de beliedsgrens ynstee fan te fertrouwen op oft in adres tafallich yn in BGP-oankundiging ferskynt.

Bewarje it foar en nei fan elke routetabel-fraach yn it feroaringsregister. As de feroaring de saak minder makket, set de eardere rûtes werom en befêstigje mei deselde fraach, want in weromdraai dy't jo net kontrolearje kinne is mar in gissing.