GCP VPN-rutten fungerar bara i en region: kontrollera dynamisk routning

Arbetsbelastningen i USA når kontorsprefixet via HA VPN utan problem, medan den europeiska arbetsbelastningen i samma VPC inte får något alls. Dess routingtabell innehåller ingen post för prefixet, ingen tunnel ligger nere och ingen brandväggsregel har ändrats. Tunneln och dess BGP-session är friska i båda riktningarna. Ett VPC som spänner över regioner är inte samma sak som dess inlärda rutter som spänner över regioner, och just den klyftan förklarar hela symtomet.

Här blandas två egenskaper ihop: var subnäten ligger och var ett inlärt nästa hopp får användas.

Varifrån det regionala omfånget kommer

Cloud Router installerar inlärda rutter med ett omfång som följer VPC:ns dynamiska routningsläge. I regionalt läge kan en rutt som lärts in i en region bara användas av resurserna i den regionen, därför är den europeiska tabellen tom i stället för att visa ett trasigt nästa hopp. I globalt läge blir kvalificerade inlärda rutter tillgängliga för resurser i varje region i VPC:n. Läs det aktuella värdet innan du ändrar något, eftersom regionalt är standard. Inställningen ligger på nätverket, inte på tunneln och inte på routern.

Inventeringskommandot är skrivskyddat och svarar på det på en rad:

gcloud compute networks describe VPC_NAME --format='value(routingConfig.routingMode)'

Kör det i värdprojektet när VPC:n är delad. Nätverket tillhör det projektet, och en visningsroll i arbetsbelastningsprojektet visar kanske inte ens routingkonfigurationen. Ett snabbt svar från fel projekt är värre än inget svar.

Ändringen är ett kommando och en riktning

Växlingen är en redigering av kontrollplanet för hela VPC:n, inte en omväg per VM: gcloud compute networks update VPC_NAME --routing-mode=GLOBAL. Den är också enkelriktad, eftersom ett nätverk som satts till globalt inte kan föras tillbaka till regionalt. Kontrollera projekt- och nätverksnamnet en gång till innan du kör det, eftersom kommandot inte begär bekräftelse. Ändringen förtjänar en underhållsnotering och nätverksägarens godkännande, inte ett snabbt experiment på ett delat VPC.

Varje Cloud Router-, VPN- och Interconnect-anslutning i det nätverket ärver det nya omfånget direkt. Det inkluderar anslutningarna som ingen nämnde i ändringsbegäran. Regioner som aldrig tidigare hade rutten börjar ta emot den så snart ändringen träder i kraft, därför finns ingen stegvis utrullning för den här växlingen.

Globalt är ett omfång, inte en garanti

Behörighet och preferens är åtskilda från omfång. En rutt som krockar med ett mer specifikt prefix, förlorar valet av bästa väg eller filtreras av policy beter sig exakt som tidigare. Globalt läge vidgar var en rutt får användas, men avgör inte vilken rutt som vinner. En inlärd rutt kan ligga inom omfånget och ändå förlora mot en statisk eller mer specifik väg i samma VPC.

Den skillnaden spelar roll eftersom lägesändringen är lätt att skylla på senare. Om det europeiska subnätet fortfarande saknar rutt efter växlingen är frågan om rutten finns och är kvalificerad, inte om omfånget trädde i kraft. Prefixkonflikter och nästa hopps hälsa är de nästa två sakerna att läsa.

Fjärrsidan annonserar också annorlunda

Annonseringsbeteendet följer samma inställning. Med standardbeteende annonserar en router i regionalt läge subnäten i sin egen region, medan globalt läge annonserar VPC:ns subnät bredare. Därför ändrar läget inte bara vad dina egna regioner får använda, utan också vad fjärrsidan installerar.

En anpassad annonseringslista utökas inte när läget ändras. Om den lokala routern har en handskriven lista över intervall förblir det europeiska prefixet frånvarande i den. Returvägen förblir bruten i det fallet även om den utgående rutten nu finns. Kontrollera vad fjärrsidan installerade i stället för vad du exporterade.

Vad läget aldrig kommer att reparera

Global routing ger inte tillgång till det offentliga internet, transit mellan orelaterade VPC:er eller saknade statiska rutter. Det ändrar inte brandväggsregler eller IAM, så en anslutning som nekas av policy förblir nekad.

Dessa fel ser likadana ut inifrån en arbetsbelastning och har inget med ruttomfånget att göra.

Testa från den avlägsna regionen till den verkliga tjänsten och bekräfta sedan att svaret kommer tillbaka genom den avsedda tunneln. Anteckna läget, annonseringskonfigurationen och målet du testade. Om testet fortfarande misslyckas, jämför fjärrrouterns BGP-tabell med VPC:ns ruttlista innan du rör läget igen. Då börjar nästa rapport mellan regioner med fakta i stället för med en lägesändring.