VGW BGP-aankondigings teenoor die VPC-roetetabel: wat verander wat

'n Ontbrekende prefiks in 'n VPC-subnetroetetabel en 'n ontbrekende prefiks op die kliëntrouter is twee verskillende foute, en net een van hulle word binne AWS-roetetabelle herstel. Die virtuele privaatpoort adverteer die CIDR-blokke wat aan sy VPC gekoppel is; die subnetroetetabel bepaal waar 'n werklading 'n antwoord stuur. Om die tweede as 'n manier te sien om die eerste te verander is die mees algemene verkeerde draai in hierdie diagnose. Voer die kontroles hieronder in volgorde uit en hou die twee rigtings apart.

Noem die aanhegsel voordat jy enige tabel lees

'n Site-to-Site VPN eindig óf op 'n virtuele privaatpoort óf op 'n transito-gateway, en die hulpbron-ID's bepaal watter roetemodel geld. Lees hulle eerste: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'. Die antwoord sê vir jou of die volgende tabel wat ondersoek moet word 'n VPC-roetetabel of 'n transito-gateway-roetetabel is.

As die VPN aan 'n transito-gateway geheg is, moet jy ophou om die VPC-roetetabel as die beheervlak te behandel. Daar wys die VPC-tabel na die gateway-aanhegsel, en assosiasie en propagasie vind in die transito-gateway-roetetabel plaas. Om die twee sienings te vermeng lewer selfversekerde gevolgtrekkings oor die verkeerde objek.

Die AWS-na-kantoor-rigting is 'n aankondiging

Vir 'n VGW-aanhegsel adverteer die poort die CIDR-blokke wat aan sy VPC gekoppel is aan die kliëntpoort oor BGP. Om 'n individuele subnetroete by te voeg, of om 'n roete na 'n gepeerde VPC of 'n toestel te wys, voeg nie nog 'n gekoppelde CIDR by nie en verskyn nie in daardie aankondiging nie. As die kantoor 'n prefiks mis, vergelyk die lys van ontvangde roetes met die VPC-assosiasies voordat jy enige roetetabel wysig.

Die eenvoudige reël het uitsonderings, dus hou dit beperk. 'n VPN CloudHub-reëling kan terreinprefikse tussen kliëntpoorte her-adverteer, en 'n transito-gateway volg sy eie propagasiereëls. Die stelling dat 'n VGW slegs sy eie VPC adverteer is 'n nuttige verstek, nie 'n wet wat elke topologie dek wat jy sal teëkom nie.

Die kantoor-na-AWS-rigting is propagasie plus seleksie

In die omgekeerde rigting leer die VGW die kantoorprefiks, maar dit alleen verskuif nie 'n werklading nie. Die subnetroetetabel moet óf propagasie vir die aanhegsel geaktiveer hê óf 'n statiese roete na dieselfde bestemming dra. Wanneer albei vir een prefiks bestaan, wen die statiese roete, en die langste-prefiks-ooreenkoms loop voor enige van hulle.

Lees die oorsprong eerder as om dit te aanvaar: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'. 'n Inskrywing met oorsprong EnableVgwRoutePropagation het van BGP gekom; 'n inskrywing met oorsprong CreateRoute is deur 'n mens getik en sal aanhou wen totdat iemand dit verwyder.

'n Runbook wat die twee rigtings apart hou

Teken vier feite aan die AWS-kant aan voordat jy enigiets verander: die aanhegseltipe, die gekoppelde VPC-CIDR's, die subnetroete-oorsprong vir die betrokke prefiks, en die tonnel- en BGP-toestand. Dieselfde describe-oproep gee VgwTelemetry met 'n telling van aanvaarde roetes per tonnel, wat jou sê of AWS enige roetes hoegenaamd aanvaar het. Vergelyk dit dan met wat die kliënttoestel werklik geïnstalleer het. 'n Prefiks wat in BGP voorkom maar in die aansturingstabel ontbreek, is 'n plaaslike invoer- of beste-roete-probleem, nie 'n AWS-roetetabelprobleem nie.

As die subnettabel die prefiks heeltemal kort, aktiveer propagasie of voeg 'n statiese roete by, en lees dan dieselfde navraag weer nadat die propagasie-interval verstreke is eerder as om aan te neem die verandering was onmiddellik. As die prefiks bestaan en verkeer steeds faal, laat die beheervlak met rus en beweeg na die datapad.

Wat nie verander moet word terwyl jy daar is nie

Moenie propagasie op onverwante roetetabelle omdraai om een ontbrekende prefiks reg te maak nie, en moenie 'n verstekroete byvoeg om 'n enkele afwesige CIDR te bedek nie. Albei veranderinge vergroot die impakarea en maak die volgende diagnose moeiliker. Hou die wysiging beperk tot die tabel wat die betrokke werklading-subnet bedien.

Die datapad is apart van dit alles. Sekuriteitsgroepe is toestandsvol, netwerk-ACL's nie, en 'n gasheerfirewall of 'n asimmetriese terugpad kan verkeer laat val wat roetering korrek afgelewer het. 'n Geadverteerde samevatting magtig ook nie elke diens daarbinne nie, so beperk toegang by die beleidsgrens eerder as om te staatmaak op of 'n adres toevallig in 'n BGP-aankondiging verskyn nie.

Stoor die voor en na van elke roetetabel-navraag in die veranderingsrekord. As die verandering dinge vererger, herstel die vorige roetes en bevestig met dieselfde navraag, want 'n terugrol wat jy nie kan verifieer nie is net 'n raaiskoot.