Part d’un bloc públic es queda al lloc i part es trasllada a Google Cloud. Aquesta frase descriu dos plans, no un: un pla d’anunci a internet i un pla de reenviament privat. Tractar-los com un sol problema d’encaminament és on els dissenys BYOIP fallen.

Els objectes implicats responen preguntes diferents, i només un d’ells tracta d’on van els paquets a continuació.

Tres objectes, tres preguntes

Un prefix anunciat públicament és la unitat que Google anuncia a internet en nom vostre. Un prefix delegat públicament és com s’assigna l’espai importat als recursos de Cloud admesos. Una ruta de VPC, inclosa una apresa a través de Cloud Router des d’una VPN, selecciona un següent salt privat. Cadascuna té el seu abast, la seva API i el seu missatge d’error.

La versió en taula és més curta.

ObjectQuestion it answers
Public advertised prefixWhich authorized range Google announces publicly
Public delegated prefixHow imported space is allocated to Cloud resources
VPN or Cloud Router routeWhich private next hop carries a destination

Només la tercera fila tracta del reenviament dins de la vostra xarxa.

Què cobreix l’avís de solapament de BYOIP

La documentació de BYOIP de Google tracta el prefix anunciat com una unitat d’anunci i adverteix dels anuncis externs solapats, inclòs un subprefix anunciat fora de Google. Aquest avís tracta del pla d’anunci públic. No és una afirmació sobre cada ruta privada que pugueu afegir.

Delegar una assignació més petita dins d’un prefix importat no us dona, per si sol, permís per anunciar la resta des d’una altra origen.

Plantegeu la pregunta en termes de qui anuncia què. Si Google anuncia tot el prefix importat, un segon origen que anunciï un subprefix crea exactament el solapament del qual adverteix la documentació, per ordenades que semblin les vostres rutes de VPC.

Què decideix una ruta privada

Un prefix après per una VPN no és un anunci a internet, i cap quantitat de BGP el convertirà en un. És una entrada en una taula de rutes de VPC que diu quin túnel o passarel·la ha de portar el trànsit per a aquesta destinació. Si aquesta entrada és elegible, seleccionada o utilitzable depèn de les regles d’encaminament del propi VPC.

La coincidència de prefix més llarg s’aplica dins de la taula de rutes, de manera que una ruta VPN més llarga pot guanyar localment sense canviar res a la vora pública.

Dividir un prefix: la decisió que arriba primer

Si l’arquitectura necessita que la meitat del bloc s’anunciï des d’un centre de dades i l’altra meitat des de Google, decidiu el pla d’anunci abans d’importar res. Confirmeu quins rangs pot anunciar Google, quins continuen anunciats en un altre lloc i si els dos es solapen. Després dissenyeu el camí privat per a cada destinació i el seu camí de retorn. Si els proveïdors no admeten la divisió que voleu, canvieu la divisió en lloc d’esperar que un prefix VPN més llarg anul·li una decisió a la vora pública.

Aquest ordre importa perquè el segon pla no pot reparar el primer.

Verifiqueu els dos plans per separat

Comproveu el costat públic amb gcloud compute public-advertised-prefixes list i confirmeu els rangs i el seu estat. Comproveu el costat privat amb gcloud compute routes list i gcloud compute routers get-status, que mostra què ha intercanviat realment BGP.

Un conjunt de sortides us diu què veu internet. L’altre us diu on va el vostre trànsit. Cap dels dos substitueix l’altre.

Articles relacionats