GCP BYOIP: offentlig annonsering er ikke en privat rute
Å dele et BYOIP-prefiks mellom lokasjon og sky krever to planer. Skill den offentlige annonseringen, delegasjonen og det private neste hoppet.
En del av en offentlig blokk blir værende på lokasjonen, og en del flytter inn i Google Cloud. Den setningen beskriver to planer, ikke én: en plan for annonsering på internett og en plan for privat videreformidling. Å behandle dem som ett enkelt ruteproblem er der BYOIP-design går galt.
Objektene som er involvert, svarer på ulike spørsmål, og bare ett av dem handler om hvor pakkene går videre.
Tre objekter, tre spørsmål
Et offentlig annonsert prefiks er enheten Google annonserer til internett på dine vegne. Et offentlig delegert prefiks er hvordan importert plass tildeles støttede Cloud-ressurser. En VPC-rute, inkludert en som læres via Cloud Router fra en VPN, velger et privat neste hopp. Hver har sitt eget omfang, sin egen API og sin egen feilmelding.
Tabellversjonen er kortere.
| Object | Question it answers |
|---|---|
| Public advertised prefix | Which authorized range Google announces publicly |
| Public delegated prefix | How imported space is allocated to Cloud resources |
| VPN or Cloud Router route | Which private next hop carries a destination |
Bare den tredje raden handler om videreformidling inne i nettverket ditt.
Hva BYOIP-overlappvarselet dekker
Googles BYOIP-dokumentasjon behandler det annonserte prefikset som en annonseringsenhet og advarer mot overlappende eksterne annonseringer, inkludert et subprefiks annonsert utenfor Google. Det varselet handler om den offentlige annonseringsplanen. Det er ikke en uttalelse om hver privat rute du måtte legge til.
Å delegere en mindre tildeling inne i et importert prefiks gir deg ikke i seg selv tillatelse til å annonsere resten fra en annen opprinnelse.
Still spørsmålet i form av hvem som annonserer hva. Hvis Google annonserer hele det importerte prefikset, skaper en annen opprinnelse som annonserer et subprefiks nøyaktig den overlappen dokumentasjonen advarer mot, uansett hvor ryddig VPC-rutene dine ser ut.
Hva en privat rute avgjør
Et prefiks lært via en VPN er ikke en internettannonsering, og ingen mengde BGP vil gjøre det til en. Det er en oppføring i en VPC-rutetabell som sier hvilken tunnel eller gateway som skal bære trafikken for den destinasjonen. Om oppføringen er kvalifisert, valgt eller brukbar avhenger av VPC-ens egne ruteningsregler.
Lengste prefiks-samsvar gjelder inne i rutetabellen, så en lengre VPN-rute kan vinne lokalt uten å endre noe på den offentlige kanten.
Å dele et prefiks: beslutningen som kommer først
Hvis arkitekturen krever at halve blokken annonseres fra et datasenter og halve fra Google, avgjør annonseringsplanen før du importerer noe. Bekreft hvilke områder Google kan annonsere, hvilke som forblir annonsert andre steder, og om de to overlapper. Design deretter den private veien for hver destinasjon og returveien dens. Hvis leverandørene ikke støtter delingen du vil ha, endre delingen i stedet for å håpe at et lengre VPN-prefiks overstyrer en beslutning på den offentlige kanten.
Den rekkefølgen betyr noe, fordi den andre planen ikke kan reparere den første.
Verifiser begge planene separat
Kontroller den offentlige siden med gcloud compute public-advertised-prefixes list og bekreft områdene og statusen deres. Kontroller den private siden med gcloud compute routes list og gcloud compute routers get-status, som viser hva BGP faktisk utvekslet.
Ett sett med utdata forteller deg hva internett ser. Det andre forteller deg hvor trafikken din går. Ingen av dem erstatter den andre.