GCP BYOIP: el anuncio público no es una ruta privada
Dividir un prefijo BYOIP entre la sede y la nube exige dos planes. Separe el anuncio público, la delegación y el siguiente salto privado.
Parte de un bloque público se queda en la sede y parte se traslada a Google Cloud. Esa frase describe dos planes, no uno: un plan de anuncio en internet y un plan de reenvío privado. Tratarlos como un único problema de enrutamiento es donde fallan los diseños BYOIP.
Los objetos implicados responden a preguntas distintas, y solo uno de ellos trata de hacia dónde van los paquetes después.
Tres objetos, tres preguntas
Un prefijo anunciado públicamente es la unidad que Google anuncia a internet en su nombre. Un prefijo delegado públicamente es cómo se asigna el espacio importado a los recursos de Cloud admitidos. Una ruta de VPC, incluida una aprendida por Cloud Router desde una VPN, selecciona un siguiente salto privado. Cada uno tiene su propio ámbito, su propia API y su propio mensaje de error.
La versión en tabla es más corta.
| 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 |
Solo la tercera fila trata del reenvío dentro de su red.
Qué cubre la advertencia de solapamiento de BYOIP
La documentación de BYOIP de Google trata el prefijo anunciado como una unidad de anuncio y advierte sobre anuncios externos solapados, incluido un subprefijo anunciado fuera de Google. Esa advertencia trata del plan de anuncio público. No es una afirmación sobre cada ruta privada que pueda añadir.
Delegar una asignación menor dentro de un prefijo importado no le da, por sí solo, permiso para anunciar el resto desde otro origen.
Plantee la pregunta en términos de quién anuncia qué. Si Google anuncia todo el prefijo importado, un segundo origen que anuncie un subprefijo crea exactamente el solapamiento del que advierte la documentación, por ordenadas que parezcan sus rutas de VPC.
Qué decide una ruta privada
Un prefijo aprendido por una VPN no es un anuncio en internet, y ninguna cantidad de BGP lo convertirá en uno. Es una entrada en una tabla de rutas de VPC que dice qué túnel o puerta de enlace debe transportar el tráfico hacia ese destino. Que esa entrada sea elegible, seleccionada o utilizable depende de las propias reglas de enrutamiento de la VPC.
La coincidencia de prefijo más largo se aplica dentro de la tabla de rutas, así que una ruta VPN más larga puede ganar localmente sin cambiar nada en el borde público.
Dividir un prefijo: la decisión que llega primero
Si la arquitectura necesita que la mitad del bloque se anuncie desde un centro de datos y la otra mitad desde Google, resuelva el plan de anuncio antes de importar nada. Confirme qué rangos puede anunciar Google, cuáles siguen anunciados en otro lugar y si ambos se solapan. Después diseñe la ruta privada para cada destino y su ruta de retorno. Si los proveedores no admiten la división que usted quiere, cambie la división en lugar de esperar que un prefijo VPN más largo anule una decisión en el borde público.
Ese orden importa porque el segundo plan no puede reparar el primero.
Verifique ambos planes por separado
Compruebe el lado público con gcloud compute public-advertised-prefixes list y confirme los rangos y su estado. Compruebe el lado privado con gcloud compute routes list y gcloud compute routers get-status, que muestra qué intercambió realmente BGP.
Un conjunto de salidas le dice qué ve internet. El otro le dice adónde va su tráfico. Ninguno sustituye al otro.