Preguntas frecuentes de Cloud Interconnect

En este documento, se abordan las preguntas frecuentes sobre las características y la arquitectura de Cloud Interconnect agrupadas en las siguientes secciones:

Tráfico en Cloud Interconnect

En esta sección, se abordan las preguntas sobre los tipos de tráfico, el ancho de banda y la encriptación en Cloud Interconnect.

¿Qué tipos de paquetes se transmiten en Cloud Interconnect?

El circuito de Cloud Interconnect transmite marcos Ethernet 802.1q con paquetes IPv4 en la carga útil. Estos marcos también se conocen como marcos Ethernet con etiquetas VLAN.

El valor del campo ID de VLAN (VID) de 12 bit del encabezado 802.1q es el mismo que el valor del ID de VLAN que asigna Google Cloud cuando se crea un adjunto de interconexión (VLAN). Para obtener más información, consulta los siguientes documentos:

¿Cómo puedo encriptar mi tráfico en Cloud Interconnect?

Según el servicio al que se accede con Cloud Interconnect, es probable que tu tráfico ya esté encriptado sin necesidad de hacer nada en particular. Por ejemplo, si accedes a una de las API de Google Cloud a las que se puede acceder en Cloud Interconnect, ese tráfico ya se encriptó con TLS de la misma manera que si se accediera a las API a través de Internet público.

También puedes usar la solución TLS para servicios que crees. Por ejemplo, puedes usarlo para un servicio que ofreces en una instancia de Compute Engine o en un pod de Google Kubernetes Engine compatible con el protocolo HTTPS.

Si necesitas encriptar la capa de la IP, puedes crear una o más puertas de enlace de VPN (no en Google Cloud) que se administran a sí mismas en tu red de la nube privada virtual y asignar una dirección IP privada a cada puerta de enlace. Por ejemplo, puedes ejecutar una VPN StrongSwan en una instancia de Compute Engine. Luego, puedes finalizar los túneles IPsec de esas puertas de enlace de VPN con Cloud Interconnect desde las instalaciones locales.

Para obtener más detalles, consulta la documentación Encriptación en tránsito.

¿Puedo crear una conexión de 100 G en una interconexión dedicada?

Sí, puedes escalar la conexión a Google según tus necesidades.

Cloud Interconnect consiste en uno o más circuitos implementados como un grupo de vínculos de canal del puerto Ethernet (LAG). Los circuitos de Cloud Interconnect pueden ser de 10 Gbps o 100 Gbps, pero no ambos dentro de la misma interconexión Cloud Interconnect.

En la interconexión dedicada, se admiten las siguientes capacidades de circuito por interconexión:

  • 8 conexiones de 10 Gbps (80 Gbps en total)
  • 1 conexión de 100 Gbps (100 Gbps en total)
  • 2 conexiones de 100 Gbps (200 Gbps en total)

La interconexión dedicada o de socio admite capacidades de 50 Mbps a 10 Gbps, 20 Gbps o 50 Gbps para cada adjunto de interconexión (VLAN) por interconexión.

Puedes pedir más de una Cloud Interconnect y usarla de forma activa si aprovechas las funciones de enrutamiento de BGP de Cloud Router.

Para obtener información actualizada, consulta la página Cuotas de Cloud Interconnect.

¿Puedo alcanzar mis instancias con IPv6 en Cloud Interconnect?

VPC no ofrece una función nativa para finalizar el tráfico IPv6 a las instancias.

¿Puedo especificar la dirección IP de intercambio de tráfico de BGP?

  • En el caso de la interconexión de socio, no. Google elige las direcciones IP de intercambio de tráfico.
  • En la interconexión dedicada, puedes especificar un rango de direcciones IP (bloque CIDR) que Google selecciona cuando creas un adjunto de interconexión (VLAN). Este bloque CIDR debe estar dentro del rango de direcciones IP 169.254.0.0/16 de vínculo local.

¿Puedo alcanzar las API de Google a través de Cloud Interconnect desde la actividad local? ¿Qué servicios o API están disponibles?

Hay dos maneras de alcanzar las API de Google.

En la Opción 1, puedes habilitar el Acceso privado a Google para una o más subredes en la red de VPC y, luego, implementar una o más instancias de proxy inverso en dichas subredes. Estos proxies inversos solo tienen la IP privada de VPC configurada, por lo que se pueden alcanzar a través del vínculo de Cloud Interconnect desde las instalaciones locales. Con esta solución, se otorgan la mayoría de los accesos a las API de Cloud, a las API del desarrollador y a la mayoría de los servicios de Google Cloud.

Consulta la sección sobre cómo configurar el Acceso privado a Google para obtener más detalles, incluida una lista de servicios de GCP compatibles con el Acceso privado a Google.

En la Opción 2, puedes aprovechar el Acceso privado a Google para los hosts locales. En este caso, las solicitudes de los hosts locales deben enviarse a restricted.googleapis.com, que se resuelve de manera persistente en el rango de IP 199.36.153.4/30, también conocido como el rango VIP restringido.

Agrega una ruta personalizada a Cloud Router para anunciar el rango VIP restringido. Esto garantiza que el tráfico a la VIP restringida (como un destino) se enrute desde la actividad local a los extremos de la API en Cloud Interconnect. Con esta solución, solo se alcanzan las API de Google y los servicios compatibles con la VIP restringida.

Para obtener la información más reciente sobre los detalles de configuración y los servicios compatibles, consulta Cómo configurar el Acceso privado a Google de los hosts locales.

¿Puedo usar Cloud Interconnect como un canal privado para acceder a todos los servicios de G Suite a través de un navegador?

Desde diciembre de 2018, no es posible acceder a las aplicaciones de G Suite mediante Cloud Interconnect.

¿Por qué mis sesiones de BGP fluctúan continuamente después de un intervalo determinado?

Busca una máscara de subred incorrecta en tu rango de IP de BGP local. Por ejemplo, en lugar de configurar 169.254.10.0/29, es probable que hayas configurado 169.254.10.0/30.

Arquitectura de Cloud Interconnect

En esta sección, se abordan preguntas frecuentes que pueden surgir durante el diseño o el uso de una arquitectura de Cloud Interconnect.

¿Puedo usar Cloud Interconnect para conectar a la Internet pública?

Desde diciembre de 2018, las rutas de Internet no se anuncian en Cloud Interconnect.

¿Cómo puedo conectarme a Google Cloud si me encuentro en una ubicación POP que no aparece en la página Ubicaciones de instalaciones de colocación Cloud Interconnect?

Tienes dos opciones, luego de las cuales puedes seguir con el proceso normal de pedido y aprovisionamiento para la interconexión dedicada:

  • Puedes pedirle líneas arrendadas a un proveedor para conectarte desde tu ubicación de punto de presencia (POP) a una instalación de colocación de Cloud Interconnect de Google. Por lo general, es mejor que te comuniques con el proveedor de instalación de tu colocación existente y que obtengas una lista de proveedores en la red. Un proveedor en la red es un proveedor que ya tiene la infraestructura en la compilación en la que te encuentras, lo que hace que esta opción sea más económica y rápida que usar un proveedor diferente que tenga que compilar infraestructura para adaptarse a tus necesidades en tu ubicación POP existente.
  • Otra opción es que uses la interconexión de socio con un proveedor socio que pueda proporcionarte un circuito de último tramo para adaptarse a tus necesidades. Por lo general, los proveedores de colocación no pueden proporcionar este tipo de servicio, ya que tienen ubicaciones fijas en las que ya debes estar.

Si uso la interconexión de socio, ¿veré la interconexión en el proyecto en el que creo el adjunto de interconexión (VLAN)?

Cuando usas el servicio de interconexión de socio, el objeto de interconexión se crea en el proyecto del socio y no está visible en el tuyo. El adjunto de interconexión (VLAN) continúa visible en tu proyecto, como en el caso de Cloud Interconnect.

¿Cómo creo arquitectura redundante que aprovecha Cloud Interconnect?

Según el ANS deseado, hay arquitecturas específicas que deben implementarse para la interconexión dedicada y la de socio.

Las topologías de las arquitecturas listas para la producción con un ANS de un 99.99% y de las aplicaciones no esenciales con un ANS de un 99.9% se encuentran disponibles en https://cloud.google.com/interconnect/docs/tutorials.

Estos niveles de ANS hacen referencia a la disponibilidad de Cloud Interconnect, que es la disponibilidad de la conexión enrutada entre la ubicación local y la red de VPC. Por ejemplo, si creas un servicio en instancias de Compute Engine que se puedan alcanzar a través de Cloud Interconnect, la disponibilidad del servicio dependerá de la disponibilidad combinada del servicio de Cloud Interconnect y del servicio de Compute Engine.

  • En la interconexión dedicada, existe una única interconexión (paquete LACP) Sin ANS de tiempo de actividad.
  • En la interconexión de socio, existe un único adjunto de interconexión (VLAN) Sin ANS de tiempo de actividad.

Los problemas relacionados con fallas de interconexión o de paquete individuales se tratan con una prioridad de los casos de ayuda que no es superior a P3: impacto medio: uso del servicio parcialmente afectado, por lo que no puedes esperar que se resuelvan rápido o que se haga un análisis adicional de la causa raíz.

Debido al mantenimiento planificado o no planificado, los vínculos o paquetes individuales pueden desviarse incluso durante largos períodos de tiempo, como horas o días.

¿Puedo desviar el tráfico en Cloud Interconnect entre mi aplicación heredada local y mis backends del balanceador de cargas interno?

En esta situación, implementaste una app que consta de dos niveles: uno local que aún no se migró a Google Cloud (nivel heredado) y otro en la nube que se ejecuta en instancias de VPC que también son backends de un Balanceador de cargas interno (ILB) de Google Cloud.

Puedes usar Cloud Interconnect para desviar el tráfico entre estos dos niveles de aplicación, siempre y cuando implementes las rutas necesarias entre Cloud Router y tu router local. El Cloud Router que usas para la Cloud Interconnect que administra el tráfico de esta aplicación debe residir en la misma región que la subred que contiene los backends del ILB. Esto se debe a que el ILB solo admite el enrutamiento regional y el acceso al ILB se pierde cuando el enrutamiento global para la VPC usa un túnel fuera de la región en la que se encuentran los backends del ILB. Consulta la sección sobre cómo implementar el balanceo de cargas interno con clientes en la VPN o la interconexión para obtener más información.

Si el tráfico local entra a la red de VPC desde una región diferente, puedes implementar un ILB con los backends respectivos en la otra región o enrutar el tráfico a un proxy inverso desde el que se pueda alcanzar el VIP del ILB.

¿Puedo mover una o más instancias de Cloud Interconnect entre organizaciones o proyectos de Google Cloud?

Si quieres trasladar un proyecto a una nueva organización de Google Cloud, puedes abrir un caso de ayuda para que Cloud Support facilite el traslado.

Las interconexiones dedicadas y los adjuntos de interconexión (VLAN) no se ven afectados por los cambios de organización, siempre y cuando el proyecto sea el mismo.

Para cambios en el proyecto, si quieres realizar una activación de Cloud Interconnect y ya tienes una LOA, pero no completaste la activación, cancela la activación actual y crea una nueva en el proyecto correcto. Google emite una LOA nueva, que puedes darle a tu proveedor de interconexión.

Sin embargo, no se puede mover una Cloud Interconnect activa entre proyectos, ya que es un objeto secundario del proyecto y no se pueden migrar objetos automáticamente entre proyectos. Si es posible, deberías iniciar una solicitud para una nueva Cloud Interconnect.

¿Cómo puedo usar la misma Cloud Interconnect para conectar varias redes de VPC en varios proyectos dentro de la misma organización de Google Cloud?

Se admite la especificación de un adjunto de VLAN existente en un proyecto distinto del proyecto al que está adjunta la interconexión Cloud Interconnect, tanto para la interconexión dedicada como para la de socio.

Para interconexión de socio

Si tienes varios adjuntos de interconexión (VLAN), incluidos los que están en diferentes proyectos, puedes vincularlos con una interconexión de socio del mismo proveedor de servicios o con interconexiones de socio de diferentes proveedores de servicios.

Para interconexión dedicada

Si tienes muchos proyectos, puedes proporcionar un adjunto de interconexión (VLAN) y un Cloud Router a cada proyecto, a la vez que configuras todos los adjuntos para que usen la misma interconexión dedicada física en un proyecto especificado.

El adjunto de interconexión (VLAN), además de ser un VLAN con un ID 802.1q, es un objeto secundario de una Cloud Interconnect existente en un proyecto.

En este modelo, cada red de VPC tiene su propia configuración de enrutamiento. Si quieres centralizar las políticas de enrutamiento, puedes revisar el modelo de VPC compartida y las consideraciones de VPC compartida, y finalizar el adjunto de interconexión (VLAN) en la red de VPC del proyecto host de la VPC compartida. Tu proyecto host tiene una cuota para la cantidad máxima de adjuntos de interconexión (VLAN) por Cloud Interconnect. Para obtener más detalles, consulta la página de cuotas y límites de Cloud Interconnect.

¿Cómo puedo usar una sola Cloud Interconnect para conectar varios sitios locales a mi red de VPC?

Es muy fácil de hacer. Por ejemplo, si varios sitios son parte de una red de VPN de MPLS, autoadministrada o administrada por un proveedor, puedes "agregar de forma lógica" la red de VPC como un sitio adicional mediante un enfoque similar a la opción A de VPN de MPLS de Inter-AS. Consulta RFC 4364, párrafo 10.

Esta solución se describe en la respuesta para que una red de VPC se muestre en el servicio de VPN de MPLS de un socio. Si aprovechas las funciones de BGP de Cloud Router, es posible incorporar rutas de VPC dentro de la estructura de conexión de una IP existente con técnicas y arquitecturas similares a las usadas para importar rutas de Internet.

¿Puedo "parchear" físicamente Cloud Interconnect y una interconexión de otro proveedor de servicios en la nube?

Si ya usas otro proveedor de servicios en la nube que ofrece un servicio que es funcionalmente equivalente a Cloud Interconnect, no existe una configuración acordada entre los proveedores de servicios en la nube para "parchear" de forma física dos interconexiones, una que proporciona Google Cloud y otra que proporciona el otro proveedor de servicios en la nube. Sin embargo, puedes enrutar entre el espacio de dirección privada de la red de VPC y la red de otro proveedor de servicios en la nube.

Si el punto de transferencia del servicio del otro proveedor de servicios en la nube se encuentra en la misma ubicación de Cloud Interconnect, puedes aprovisionar tu propio router en la ubicación para finalizar los dos servicios de interconexión. Entonces, el router enrutará entre la red de VPC y la red del otro proveedor de servicios en la nube. Esta configuración te permite enrutar directamente desde las dos redes en la nube hasta tu red local con un retraso mínimo.

Algunos proveedores de interconexiones de socio pueden ofrecer esto como un servicio administrado, basado en un router virtual. Si Google Cloud y el otro proveedor de servicios en la nube finalizan los servicios de interconexión en diferentes ubicaciones, entonces debes proporcionar un circuito que conecte las dos ubicaciones.

¿Cómo puedo conectar AWS y Google Cloud sin colocar el equipo en una instalación de colocación cerca del perímetro de Google?

Megaport ofrece su propia solución de Cloud Router para los clientes de Google Cloud que no quieren colocar hardware cerca del perímetro de Google. Consulta la página de instrucciones de configuración, en la que se muestra cómo configurar este producto con Google Cloud.

Adjuntos de interconexión (VLAN)

En esta sección, se tratan preguntas sobre los adjuntos de interconexión (VLAN).

¿Cómo puedo elegir el ID de VLAN que se usa para un adjunto de interconexión (VLAN)?

Para un adjunto de interconexión creado con la interconexión de socio, el socio elige el ID de VLAN durante el proceso de creación o te permite elegirlo. Verifica si tu socio te permite elegir el ID de VLAN para los adjuntos de interconexión.

En un adjunto de interconexión creado con la interconexión dedicada, puedes usar el comando gcloud compute interconnects attachments create con la marca --vlan o puedes seguir las instrucciones de Google Cloud Console.

En el siguiente ejemplo, se muestra cómo usar el comando gcloud para cambiar el ID de VLAN a 5:

    gcloud compute interconnects attachments dedicated create my-attachment \
      --router my-router \
      --interconnect my-interconnect \
      --vlan 5 \
      --region us-central1
    

Para obtener las instrucciones completas, consulta uno de los siguientes documentos:

¿Puedo usar Cloud Router con más de un adjunto de interconexión?

Sí, esta es una configuración compatible.

MPLS

En esta sección, se tratan preguntas sobre Cloud Interconnect y MPLS.

¿Puedo usar Cloud Interconnect para finalizar un LSP de MPLS en mi red de VPC?

Desde diciembre de 2018, VPC no cuenta con una función nativa en Google Cloud para finalizar el LSP de MPLS.

En un servicio de VPN de MPLS autoadministrado, ¿puedo hacer que mi red de VPC se muestre como un sitio adicional?

Si tienes un servicio de VPN de MPLS que administras, puedes hacer que tu red de VPC se muestre como un sitio adicional que consta de solo una VPN autoadministrada.

Esta situación supone que no compras un servicio de VPN de MPLS a un proveedor. En cambio, tienes un entorno de VPN de MPLS en el que administras y configuras los routers de P y PE de la red de MPLS.

Esto es lo que debes hacer para que tu red de VPC se muestre como un sitio adicional en tu servicio de VPN de MPLS autoadministrado:

  1. Conecta uno de tus dispositivos perimetrales de PE de VPN de MPLS a tu dispositivo perimetral de intercambio de tráfico para la interconexión dedicada mediante un modelo muy similar a la opción A de VPN de MPLA de Inter-AS. Consulta RFC 4,364, párrafo 10. En otras palabras, puedes finalizar la VPN de VPN-MPLS obligatoria, por ejemplo, VRF_A, en tu dispositivo perimetral de PE y, luego, usar la asignación VLAN a VRF para "unir" el adjunto de interconexión (VLAN) de Google Cloud a esta VPN, lo que esencialmente asigna este VLAN a VRF_A en el dispositivo perimetral de PE.

  2. Crea una sesión de BGP IPv4 estándar entre el router de PE y Cloud Router a fin de garantizar que las rutas se intercambian entre ellos. Las rutas que envía Cloud Router se mostrarán solo en la tabla de enrutamiento de VPN (dentro de VRF_A) y no en la tabla de enrutamiento global del dispositivo perimetral de PE.

    Crea varias VPN separadas para administrar los rangos de IP que se superponen. Por ejemplo, puedes crear VRF_A y VRF_B, cada una con una sesión de BGP en Cloud Router en una red de VPC específica (por ejemplo, VPC_A y VPC_B). Este procedimiento no requiere un encapsulamiento de MPLS entre tu dispositivo perimetral de PE y el dispositivo perimetral de intercambio de tráfico de la interconexión dedicada.

¿Puedo hacer que mi red de VPC se muestre como un sitio adicional en mi VPN de MPLS de un proveedor que también es un socio de interconexión de socio?

Si compras un servicio de VPN de MPLS de un proveedor que también es un socio oficial de la interconexión de socio, puedes hacer que tu red de VPC se muestre como un sitio adicional en tu VPN de MPLS.

En este caso, el proveedor administra y configura los routers de P y PE de su red de MPLS. Como la interconexión de socio usa el mismo modelo de conectividad que la interconexión dedicada, el proveedor puede aprovechar un modelo muy similar a la opción A de VPN de MPLS de Inter-AS. Consulta RFC 4364, párrafo 10.

Básicamente, el proveedor te proporciona un servicio de capa 3 de interconexión de socio y "vincula" tu adjunto de interconexión (VLAN) con la VPN de MPLS correcta en el dispositivo perimetral del proveedor. Consulta la Descripción general de la interconexión de socio para obtener más detalles. Debido a que este es un modelo de servicio de capa 3, la sesión de BGP se establece entre tu Cloud Router y tu VRF dentro del dispositivo perimetral del proveedor.