GCP BYOIP: offentleg annonsering er ikkje ei privat rute
Å dele eit BYOIP-prefiks mellom lokasjon og sky krev to planar. Skil den offentlege annonseringa, delegasjonen og det private neste hoppet.
Ein del av ein offentleg blokk blir verande på lokasjonen, og ein del flyttar inn i Google Cloud. Den setninga skildrar to planar, ikkje éin: ein plan for annonsering på internett og ein plan for privat vidaresending. Å handsame dei som eitt einskilt ruteproblem er der BYOIP-design går gale.
Objekta som er involverte, svarar på ulike spørsmål, og berre eitt av dei handlar om kvar pakkane går vidare.
Tre objekt, tre spørsmål
Eit offentleg annonsert prefiks er eininga Google annonserer til internett på dine vegner. Eit offentleg delegert prefiks er korleis importert plass blir tildelt støtta Cloud-ressursar. Ei VPC-rute, inkludert ei som blir lært via Cloud Router frå ein VPN, vel eit privat neste hopp. Kvar har sitt eige omfang, sin eigen API og si eiga feilmelding.
Tabellversjonen er kortare.
| 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 |
Berre den tredje rada handlar om vidaresending inne i nettverket ditt.
Kva BYOIP-overlappvarselet dekkjer
Googles BYOIP-dokumentasjon handsamar det annonserte prefikset som ei annonseringseining og varslar mot overlappande eksterne annonseringar, inkludert eit subprefiks annonsert utanfor Google. Det varselet handlar om den offentlege annonseringsplanen. Det er ikkje ei utsegn om kvar privat rute du måtte leggje til.
Å delegere ei mindre tildeling inne i eit importert prefiks gir deg ikkje i seg sjølv løyve til å annonsere resten frå ein annan opphav.
Still spørsmålet i form av kven som annonserer kva. Viss Google annonserer heile det importerte prefikset, skaper ein annan opphav som annonserer eit subprefiks nøyaktig den overlappen dokumentasjonen varslar mot, same kor ryddig VPC-rutene dine ser ut.
Kva ei privat rute avgjer
Eit prefiks lært via ein VPN er ikkje ei internettannonsering, og ingen mengd BGP vil gjere det til ei. Det er ei oppføring i ein VPC-rutetabell som seier kva tunnel eller gateway som skal bera trafikken for den destinasjonen. Om oppføringa er kvalifisert, vald eller brukbar avheng av VPC-en sine eigne ruteringsreglar.
Lengste prefiks-samsvar gjeld inne i rutetabellen, så ei lengre VPN-rute kan vinne lokalt utan å endre noko på den offentlege kanten.
Å dele eit prefiks: avgjerda som kjem først
Viss arkitekturen krev at halve blokka blir annonsert frå eit datasenter og halve frå Google, avgjer annonseringsplanen før du importerer noko. Stadfest kva område Google kan annonsere, kva som blir verande annonsert andre stader, og om dei to overlappar. Design deretter den private vegen for kvar destinasjon og returvegen hans. Viss leverandørane ikkje støttar delinga du vil ha, endre delinga i staden for å håpe at eit lengre VPN-prefiks overstyrer ei avgjerd på den offentlege kanten.
Den rekkjefølgja betyr noko, fordi den andre planen ikkje kan reparere den første.
Verifiser begge planane separat
Kontroller den offentlege sida med gcloud compute public-advertised-prefixes list og stadfest områda og statusen deira. Kontroller den private sida med gcloud compute routes list og gcloud compute routers get-status, som viser kva BGP faktisk utveksla.
Eitt sett med utdata fortel deg kva internett ser. Det andre fortel deg kvar trafikken din går. Ingen av dei erstattar den andre.