Solución de problemas

Con la guía de solución de problemas, puedes resolver problemas comunes que podrían surgir mientras usas Cloud Interconnect:

Para obtener respuestas a preguntas comunes sobre la arquitectura y las funciones de Cloud Interconnect, consulta las Preguntas frecuentes de Cloud Interconnect.

Para obtener las definiciones de los términos que se usan en esta página, consulta los términos clave de Cloud Interconnect.

Para encontrar información de registro y supervisión, y ver las métricas de Cloud Interconnect, consulta Supervisa conexiones.

Solución de problemas generales

Verifica si hay interrupciones del servicio de Cloud Interconnect

  • Puedes verificar las interrupciones conocidas en el panel de estado de Google Cloud. También puedes suscribirte al feed JSON o al feed RSS de incidentes en Cloud para recibir actualizaciones push.

  • Se te notificarán los eventos de mantenimiento que afecten tus conexiones de interconexión dedicada. Para obtener más detalles, consulta Eventos de mantenimiento de infraestructura.

  • Se te notificará sobre los eventos de mantenimiento que afectan tus adjuntos de VLAN de interconexión de socio. Las notificaciones de interconexión de socio se envían de manera similar a las notificaciones de conexiones de interconexión dedicada, con algunas diferencias menores. Para obtener más detalles, consulta Eventos de mantenimiento de infraestructura.

No te puedes conectar a recursos en otras regiones

De forma predeterminada, las redes de nube privada virtual (VPC) son regionales, lo que significa que Cloud Router anuncia solo las subredes en su región. A fin de conectarte a otras regiones, establece el modo de enrutamiento dinámico de la red de VPC en global para que Cloud Router pueda anunciar todas las subredes.

Para obtener más información, consulta Modo de enrutamiento dinámico en la documentación de Cloud Router.

No puedes acceder a las VM en una red de VPC con intercambio de tráfico

En esta situación, configuraste una conexión de Cloud Interconnect entre tu red local y una red de VPC, la red A. También configuraste el intercambio de tráfico entre redes de VPC entre la red A y otra, entre la red B. Sin embargo, no puedes acceder a las VM en la red B desde tu red local.

Esta configuración no es compatible, como se describe en las restricciones de la descripción general del intercambio de tráfico entre redes de VPC.

Sin embargo, puedes usar anuncios de rangos de IP personalizados de Cloud Routers en tu red de VPC para compartir rutas a destinos en la red de intercambio de tráfico. Además, debes configurar las conexiones de intercambio de tráfico entre redes de VPC para importar y exportar rutas personalizadas.

Para obtener más información sobre las rutas de publicidad entre las redes locales y las de intercambio de tráfico de VPC, consulta los siguientes recursos:

Subredes faltantes en una conexión

Para anunciar todas las subredes disponibles, especifica las rutas faltantes con anuncios de ruta personalizados y anuncia todas las rutas de las subredes entre regiones con enrutamiento dinámico global. Para ello, siga estos pasos:

  1. Especifica rutas anunciadas personalizadas en un Cloud Router y en la sesión del Protocolo de puerta de enlace de frontera (BGP).

    Para ingresar las rutas que faltan, establece los siguientes parámetros:

    --set-advertisement-groups = ADVERTISED_GROUPS
    --set-advertisement-ranges = ADVERTISED_IP_RANGES
    

    Reemplaza lo siguiente:

    • ADVERTISED_GROUPS: Es un grupo definido por Google que Cloud Router anuncia de forma dinámica. Puede tener un valor de all_subnets, que imita el comportamiento predeterminado de un Cloud Router
    • ADVERTISED_IP_RANGES es el contenido del nuevo array de rangos de direcciones IP. Puede tener uno o más valores que elijas

    Para obtener más detalles y ejemplos, consulta Cómo anunciar rangos de IP personalizados.

  2. Habilita el modo de enrutamiento dinámico global.

No puedes hacer ping a Cloud Router

Si no puedes hacer ping a Cloud Router desde tu router local, busca el producto en la siguiente tabla y realiza los pasos para solucionar problemas de ese producto. Las VM no pueden acceder a 169.254.0.0/16.

Pasos para solucionar problemas que se deben seguir Interconexión dedicada Interconexión de socio L3 Interconexión de socio L2
En la interconexión de socio, es posible que el Cloud Router no se pueda hacer ping porque algunos socios filtran el tráfico al rango de IP (169.254.0.0/16) para Cloud Router. Para los socios L3, el socio configura automáticamente BGP. Si BGP no aparece, comunícate con tu socio. No aplicable No aplicable
Verifica que el dispositivo local haya obtenido la dirección MAC correcta para el lado de Google Cloud de la conexión. Para obtener más información, consulta Solución de problemas de ARP. No aplicable No aplicable
Verifica que el Cloud Router tenga una interfaz y un par de BGP. No se puede hacer ping a Cloud Router, a menos que la interfaz y el par de BGP estén configurados por completo, incluido el ASN remoto.
  • Para la interconexión dedicada, consulta La sesión de BGP no funciona.
  • En la interconexión de socio L2, Google agregó la interfaz y el par de BGP para Cloud Router de forma automática, pero debes configurar el ASN remoto.
No aplicable

Solución de problemas de ARP

Para la interconexión dedicada, a fin de encontrar la dirección MAC correcta, ejecuta el siguiente comando de gcloud:

  gcloud compute interconnects get-diagnostics INTERCONNECT_NAME

googleSystemID contiene la dirección MAC que debe estar presente en la tabla ARP de tu dispositivo para las direcciones IP asignadas a Cloud Router.

  result:
    links:
    — circuitId: SAMPLE-0
      googleDemarc: sample-local-demarc-0
      lacpStatus:
        googleSystemId: ''
        neighborSystemId: ''
        state: DETACHED
      receivingOpticalPower:
        value: 0.0
      transmittingOpticalPower:
        value: 0.0
    macAddress: 00:00:00:00:00:00

Si el dispositivo no obtuvo una dirección MAC, verifica que se hayan configurado la dirección IP y el ID de VLAN correctos en la subinterfaz.

En el caso de la interconexión de socio, si ves una dirección MAC incorrecta en tu dispositivo, verifica que no se haya realizado un puente a los segmentos de Capa 2 de dos adjuntos de VLAN. El lado de Google Cloud de la conexión de Cloud Interconnect está configurado con ip proxy-arp, que responde a todas las solicitudes ARP y puede provocar que el router local obtenga entradas de ARP incorrectas.

No se puede crear el adjunto de VLAN

Verás un mensaje de error, si intentas crear un adjunto de VLAN para la interconexión dedicada o la interconexión de socio que infringe una política de la organización. Consulta el siguiente mensaje de error de ejemplo de la ejecución de gcloud compute interconnects attachments partner create:

ERROR: (gcloud.compute.interconnects.attachments.partner.create) Could not fetch resource:
- Constraint constraints/compute.restrictPartnerInterconnectUsage violated for projects/example-project. projects/example-project/global/networks/example-network is not allowed to use the Partner Interconnect.

Para obtener más información, consulta Restringe el uso de Cloud Interconnect y Usa políticas de la organización personalizadas, y comunícate con el administrador de tu organización.

Comparte conexiones con otros proyectos en la organización

Usa una VPC compartida para compartir una conexión, como un adjunto de VLAN o una interconexión dedicada en un proyecto host.

Para obtener más información sobre cómo configurar una red de VPC compartida, consulta Aprovisiona la VPC compartida.

Si quieres obtener más información para configurar adjuntos en una red de VPC compartida, consulta Opciones para conectarse a varias redes de VPC.

Interconexión dedicada

Google no puede hacerte ping durante el proceso de aprovisionamiento de conexión

Comprueba que estés usando la configuración IP y LACP correcta. Durante el proceso de prueba, Google te envía diferentes opciones de configuración IP de prueba para tu router local, según si pides un paquete de varios vínculos o un paquete de un solo vínculo. No configures adjuntos de VLAN para ninguna de estas pruebas.

  • El primer conjunto de direcciones IP que Google envía es para probar la conectividad de varios circuitos en cada vínculo individual. Debes configurar las direcciones IP de prueba en cada vínculo físico (sin LACP configurado) de acuerdo con las instrucciones que se encuentran en los correos electrónicos que te envió Google. Google debe hacer ping correctamente a todas las direcciones IP antes de que se pase esta primera prueba.
  • Para la segunda prueba, quita todas las direcciones IP de la primera prueba. Configura el canal del puerto con LACP aunque tu interconexión tenga un solo vínculo. Google hace ping a la dirección del canal del puerto. No modifiques la configuración LACP de tu canal de puerto después de que la conexión haya pasado la prueba final. No obstante, debes quitar la dirección IP de prueba de la interfaz del canal del puerto.
  • Google envía la dirección IP de producción final para probar la conectividad de circuito único. Configura la dirección IP en la interfaz del conjunto (con LACP configurado, ya sea en modo activo o pasivo) siguiendo las instrucciones presentes en el correo electrónico que te envío Google. Google debe hacer ping correctamente a la dirección IP de la interfaz del conjunto antes de que se pase esta prueba. Configura el canal del puerto con LACP aunque tu interconexión tenga un solo vínculo.

No puedes hacer ping a Cloud Router

  • Verifica que puedas hacer ping a la dirección IP del canal del puerto de Google. La dirección IP es el valor googleIpAddress cuando ves los detalles de la conexión.
  • Verifica que tengas la VLAN correcta en la subinterfaz de tu router local. La información de VLAN debe coincidir con la que proporcionó el adjunto de VLAN.
  • Verifica que tengas la dirección IP correcta en la subinterfaz de tu router local. Cuando creas un adjunto de VLAN, este asigna un par de direcciones IP de vínculo local. Una es para una interfaz en un Cloud Router (cloudRouterIpAddress), y la otra está destinada a una subinterfaz en el canal del puerto del router local, no el canal del puerto en sí (customerRouterIpAddress).
  • Si pruebas el rendimiento de los adjuntos de VLAN, no hagas ping a Cloud Router. En su lugar, crea y usa una instancia de máquina virtual (VM) de Compute Engine en tu red de VPC. Para obtener más información, consulta Prueba el rendimiento.

La sesión de BGP no funciona

  • Habilita BGP con salto múltiple en tu router local con al menos dos saltos.
  • Verifica que tengas la dirección IP vecina correcta configurada en tu router local. Usa la dirección IP de par de BGP (cloudRouterIpAddress) que asignó el adjunto de VLAN.
  • Verifica que la configuración del ASN local en tu router local coincida con el ASN de par en el Cloud Router. Además, verifica que la configuración del ASN local en Cloud Router coincida con el ASN de par en tu router local.
  • A cada adjunto se le asigna un CIDR único /29 a partir de 169.254.0.0/16 dentro de tu red de VPC. Se asigna una dirección IP del CIDR /29 al Cloud Router y otra al router local.

    Verifica que se asignen las direcciones IP correctas a la interfaz del router local y a su vecino de BGP. Un error común es configurar un CIDR /30 en la interfaz del router local en lugar de uno /29. Google Cloud reserva todas las demás direcciones en el CIDR /29.

    Asegúrate de que no asignaste ninguna otra IP de este CIDR a la interfaz de adjunto de VLAN en el router.

No puedes acceder a las VM en tu red de VPC

  • Verifica que puedes hacer ping al canal del puerto y al adjunto de VLAN.
  • Verifica que tu sesión de BGP esté activa.
  • Verifica que tu router local esté anunciando y recibiendo rutas.
  • Verifica que no haya superposiciones entre los anuncios de ruta locales y los rangos de red de Google Cloud.
  • Establece el tamaño de la MTU con los mismos valores para tu router local, VPC y adjunto de VLAN.

El tráfico IPv6 no pasa por el adjunto de VLAN

Si tienes dificultades para conectarte a los hosts IPv6, haz lo siguiente:

  1. Verifica que las rutas IPv6 se anuncien correctamente. Si las rutas IPv6 no se anuncian, consulta Soluciona problemas de rutas de BGP y selección de rutas.
  2. Inspecciona las reglas de firewall para asegurarte de permitir el tráfico de IPv6.
  3. Verifica que no tengas rangos de subred IPv6 superpuestos en tu red de VPC y en tu red local. Consulta Verifica rangos de subred superpuestos.
  4. Determina si superaste las cuotas y los límites de tus rutas aprendidas en Cloud Router. Si superaste la cuota de las rutas aprendidas, los prefijos IPv6 se descartan antes de los prefijos IPv4. Consulta Verifica cuotas y límites.
  5. Verifica que todos los componentes relacionados con la configuración de IPv6 se hayan configurado de forma correcta.

    • La red de VPC habilitó el uso de direcciones IPv6 internas con la marca --enable-ula-internal-ipv6.
    • La subred de VPC está configurada para usar el tipo de pila IPV4_IPV6.
    • La subred de VPC tiene --ipv6-access-type configurado como INTERNAL.
    • Las VM de Compute Engine en la subred se configuran con direcciones IPv6.
    • El adjunto de VLAN está configurado para usar el tipo de pila IPV4_IPV6.
    • El par de BGP habilitó IPv6 y se configuraron las direcciones IPv6 de siguiente salto correctas para la sesión de BGP.

No se puede crear un adjunto de VLAN con el tipo de pila IPv4 e IPv6 (pila doble)

La creación de un adjunto de VLAN con el tipo de pila IPv4 e IPv6 (pila doble) falla con el siguiente mensaje de error:

Cannot create a dual stack interconnect attachment. Dual stack attachment can only be used
with a provisioned interconnect attachments that have Dataplane version 2.

Para solucionar este problema, haz lo siguiente:

  1. Consulta la tabla Todas las instalaciones de colocación para ver qué regiones admiten la creación de adjuntos en Dataplane v2.

  2. Si la región no aparece en la lista, vuelve a crear el adjunto en una región compatible.

No se puede modificar un adjunto de VLAN existente para que use el tipo de pila IPv4 e IPv6 (pila doble)

La actualización de un adjunto de VLAN existente para usar el tipo de pila IPv4 e IPv6 (pila doble) falla con el siguiente mensaje de error:

Cannot create a dual stack interconnect attachment. Dual stack attachment can only
be used with a provisioned interconnect attachments that have Dataplane version 2.

Para solucionar este problema, haz lo siguiente:

  1. Verifica la versión del Dataplane del archivo adjunto y verifica que el adjunto use la versión 1 de Dataplane. Consulta Verifica la versión de Dataplane de un archivo adjunto.

  2. Vuelve a crear el adjunto en una región que admita la creación de todos los adjuntos nuevos en Dataplane v2. Para obtener una lista de regiones, consulta Todas las instalaciones de colocación.

Prueba de rendimiento en tus adjuntos de VLAN

Si necesitas probar el rendimiento de los adjuntos de VLAN, usa una VM en la red de VPC. Agrega las herramientas de rendimiento que necesitas en la VM. No uses la dirección IP del vínculo local de Cloud Router para probar la latencia, como el ping ICMP o la ruta de acceso MTU. El uso de Cloud Router puede dar resultados impredecibles.

Obtener diagnósticos

Para obtener información técnica actualizada y detallada sobre el extremo de Google Cloud de la conexión de interconexión dedicada a pedido, consulta Obtén diagnósticos.

Interconexión de socio

La sesión de BGP no funciona (conexiones de capa 2)

  • Verifica que tu router local se haya configurado con una sesión de BGP a tus Cloud Routers. Si deseas obtener más información, consulta Configura routers locales para interconexión de socio.
  • Habilita BGP con salto múltiple en tu router local con al menos dos saltos.
  • Verifica que tengas la dirección IP vecina correcta configurada en tu router local. Usa la dirección IP de par de BGP (cloudRouterIpAddress) que asignó el adjunto de VLAN.
  • Verifica que la configuración del ASN local en tu Cloud Router local coincida con el ASN de par en el Cloud Router (16550). Además, verifica que la configuración del ASN local en Cloud Router coincida con el ASN de par en tu router local.

La sesión de BGP no funciona (conexiones de capa 3)

  • Tu Cloud Router debe estar configurado con el ASN de tu proveedor de servicios. Comunícate con tu proveedor de servicios para obtener asistencia.

Adjunto de VLAN inactivo para una conexión de interconexión de socio

El estado de un adjunto de VLAN puede mostrarse como inactivo incluso si no hay problemas con la configuración de Google Cloud ni con la conexión de interconexión de socio.

Asegúrate de haber configurado el salto múltiple de EBGP en tu router local para tener al menos cuatro saltos. Puedes ver una configuración de muestra en Configura routers locales.

Problemas con la clave de vinculación en una conexión de interconexión de socio

Cuando intentas configurar una conexión de interconexión de socio, puedes encontrar un mensaje de error como “Google: El estado del proveedor no está disponible”. Para solucionar el problema, sigue estos pasos:

  1. Asegúrate de que el adjunto de VLAN del lado del cliente haya generado la clave de vinculación (tipo PARTNER). La clave es una string aleatoria larga que Google usa para identificar el adjunto. La región de Google Cloud de destino y el dominio de disponibilidad perimetral están codificados en la clave de vilculación en el siguiente formato:

    <random_string>/<region_name>/<domain>
    

    El campo domain contiene la string any si el adjunto de VLAN no está restringido a un dominio en particular o si no especificas el dominio de disponibilidad perimetral. Para obtener más información sobre las claves de sincronización, consulta Clave de sincronización.

  2. Asegúrate de que el dominio de disponibilidad perimetral de la conexión de interconexión de socio coincida con el dominio especificado por la clave de vinculación.

No puedes hacer ping al Cloud Router (conexiones de capa 2)

  • Verifica que tengas el adjunto de VLAN correcto en la subinterfaz del router local. La información del adjunto de VLAN debe coincidir con la que proporcionó tu proveedor de servicios.
  • Verifica que tengas la dirección IP correcta en la subinterfaz de tu router local. Una vez que el proveedor de servicios configura tu adjunto de VLAN, el adjunto asigna un par de direcciones IP de vínculo local. Una es para una interfaz en el Cloud Router asociado (cloudRouterIpAddress) y la otra, para una subinterfaz en el canal del puerto de tu router local, no el canal del puerto en sí mismo (customerRouterIpAddress).
  • Si estás probando el rendimiento de tus adjuntos, no hagas ping al Cloud Router. En su lugar, crea y usa una VM en tu red de VPC. Para obtener más información, consulta Prueba el rendimiento.

Pérdida de potencia óptica en el puerto de conexión de interconexión de socio

Si se produce una pérdida de potencia óptica en un puerto, es posible que ocurra uno de los siguientes problemas:

  • Pérdida de conectividad de capa 3 (pérdida de una sesión de BGP) o incapacidad para acceder a las instancias de VM de Google Cloud
  • Rendimiento degradado de tu paquete de vínculos. Este problema ocurre si varios puertos 10GE están agrupados y solo funcionan algunos de los vínculos de un paquete.

La pérdida de potencia óptica en un puerto significa que el hardware no puede detectar una señal del otro extremo. Esto puede deberse a uno de los siguientes problemas:

  • Un transceptor defectuoso
  • Un sistema de transporte defectuoso
  • Un problema de fibra física

Para solucionar este problema, comunícate con tu interconexión de socio o proveedor de circuitos. Ellos pueden seguir estos pasos:

  1. Comprueba que el transceptor esté funcionando.
  2. Ejecuta un bucle estricto a la sala de Meet-Me (MMR) para comprobar si los niveles de luz de su dispositivo funcionan como se esperaba.
  3. Verifica si los problemas son de su lado o del lado de Google. La mejor manera de aislar la interfaz es colocar un bucle bidireccional en la demarcación. Las interfaces de cada lado transmitirán una luz baja a la demarcación en la que se repetirá de forma indefinida. El lado defectuoso será el de la demarcación que no aparezca de manera correcta.
  4. Limpia y vuelve a colocar toda la fibra de su lado.

No puedes enviar y aprender valores MED a través de una conexión de interconexión de socio L3

Si utilizas una conexión de interconexión de socio en la que un proveedor de servicios de capa 3 se encarga del BGP, Cloud Router no puede aprender los valores MED de tu router local ni enviar valores MED a ese router. Esto se debe a que los valores MED no pueden pasar por sistemas autónomos. En este tipo de conexión, no puedes establecer prioridades de ruta para las rutas que anuncia Cloud Router a tu router local. Además, no puedes establecer prioridades de ruta para las rutas que anuncia tu router local a la red de VPC.

El tráfico IPv6 no funciona después de cambiar el tipo de pila de un adjunto a pila doble

  1. Visualiza el estado de Cloud Router y verifica que se muestre status: UP.

    Si BGP no está activo, sigue estos pasos:

    1. Confirma que tu router local (o el router de tu socio si usas un socio de capa 3) esté configurado con una sesión de BGP IPv6 y que la sesión use las direcciones IPv6 correctas.

    2. Visualiza la configuración de la sesión de BGP y verifica que bgpPeers.enable muestre 'TRUE' para tu Cloud Router.

    Si BGP está activo, consulta las rutas de Cloud Router para verificar que se muestren los best_routes IPv6 esperados.

    Si no se muestran los best_routes esperados, confirma que tu router local (o el router de tu socio si usas un socio de capa 3) esté configurado con las rutas IPv6 correctas.

El resto de los problemas

Para obtener asistencia adicional, comunícate con el proveedor de servicios. De ser necesario, tu proveedor de servicios se comunicará con Google para corregir los problemas relacionados con el lado de Google de la red.

VPN con alta disponibilidad mediante Cloud Interconnect

Cuando implementas una VPN con alta disponibilidad en Cloud Interconnect, creas dos niveles operativos:

  • El nivel de Cloud Interconnect, que incluye los adjuntos de VLAN y el Cloud Router para Cloud Interconnect.
  • El nivel de VPN con alta disponibilidad, que incluye las puertas de enlace y los túneles de VPN con alta disponibilidad, y el Cloud Router para las VPN con alta disponibilidad.

Cada nivel requiere su propio Cloud Router:

  • El Cloud Router para Cloud Interconnect se usa exclusivamente para intercambiar prefijos de puerta de enlace de VPN entre los adjuntos de VLAN. Solo los adjuntos de VLAN del nivel de Cloud Interconnect usan este Cloud Router. No se puede usar en el nivel de VPN con alta disponibilidad.
  • El Cloud Router para VPN con alta disponibilidad intercambia prefijos entre tu red de VPC y tu red local. Configura el Cloud Router para la VPN con alta disponibilidad y sus sesiones de BGP de la misma manera que lo harías para una implementación normal de VPN con alta disponibilidad.

Debes compilar el nivel de VPN con alta disponibilidad sobre el nivel de Cloud Interconnect. Por lo tanto, el nivel de VPN con alta disponibilidad requiere que el nivel de Cloud Interconnect, basado en la interconexión dedicada o la interconexión de socio, esté configurado y esté en funcionamiento de forma correcta.

Para solucionar problemas de una VPN con alta disponibilidad en la implementación de Cloud Interconnect, primero soluciona los problemas del nivel de Cloud Interconnect. Después de verificar que Cloud Interconnect funcione de forma correcta, soluciona los problemas del nivel de VPN con alta disponibilidad.

No se puede crear un adjunto de VLAN encriptado

La creación del adjunto de VLAN encriptado falla con el siguiente mensaje de error:

  Cannot create an interconnect attachment with IPSEC encryption.
  IPSEC encryption can only be used with a provisioned interconnect attachments
  that have Dataplane version 2.
  

Para solucionar el problema, sigue estos pasos:

  1. Consulta la tabla Todas las instalaciones de colocación para ver qué regiones admiten la creación de adjuntos en Dataplane v2.

  2. Si la región no aparece en la lista, vuelve a crear el adjunto en una región compatible.

No se puede establecer la sesión de BGP para el Cloud Router para Cloud Interconnect

Para detectar si la sesión de BGP asociada con el adjunto de VLAN está inactiva, ejecuta el siguiente comando:

   gcloud compute routers get-status INTERCONNECT_ROUTER_NAME

Reemplaza INTERCONNECT_ROUTER_NAME con el nombre del Cloud Router que creaste para el nivel de Cloud Interconnect de tu VPN con alta disponibilidad en la implementación de Cloud Interconnect.

Para solucionar el problema, sigue estos pasos:

  1. Sigue los pasos en Prueba conexiones y Obtén diagnósticos para asegurarte de que la conexión subyacente de Cloud Interconnect esté en buen estado.
  2. Verifica que la interfaz de la sesión de BGP apunte al adjunto correcto.
  3. Verifica las direcciones IP configuradas para la interfaz de sesión de BGP en Cloud Router y en el router local.
  4. Comprueba que los números de ASN estén configurados correctamente en Cloud Router y en el router local.
  5. Verifica que la conexión de Cloud Interconnect y el adjunto de VLAN estén en un estado admin-enabled.

No se puede establecer un túnel VPN con alta disponibilidad

Para verificar el estado del túnel, ejecuta el siguiente comando:

gcloud compute vpn-tunnels describe VPN_TUNNEL_NAME

Reemplaza VPN_TUNNEL_NAME por el nombre del túnel VPN con alta disponibilidad.

Para solucionar el problema, sigue estos pasos:

  1. Debido a que el túnel VPN se enruta a través de un adjunto de VLAN, verifica que se establezca la sesión de BGP asociada con el adjunto de VLAN. De lo contrario, consulta No se puede establecer la sesión de BGP para el Cloud Router para Cloud Interconnect.
  2. Comprueba si los algoritmos de cifrado y el PSK del túnel están configurados de forma correcta en las puertas de enlace de Cloud VPN y en las puertas de enlace de VPN locales.
  3. Verifica que el anuncio de BGP del router local incluya las direcciones de la puerta de enlace de VPN local. De lo contrario, ajusta la configuración de BGP del router local para anunciar las direcciones.
  4. Verifica que las rutas a las puertas de enlace de VPN locales no se hayan descartado debido a conflictos con las rutas BGP existentes. Si hay conflictos, ajusta las direcciones de la puerta de enlace de VPN o las rutas anunciadas.
  5. Comprueba que el anuncio de BGP de Cloud Router incluya las direcciones de la puerta de enlace de VPN con alta disponibilidad. Verifica esto desde el router local o inspecciona el campo advertisedRoutes del par de BGP. Para ver el campo advertisedRoutes, ejecuta el siguiente comando:

    gcloud compute routers get-status INTERCONNECT_ROUTER_NAME
    

    Reemplaza INTERCONNECT_ROUTER_NAME con el nombre del Cloud Router que creaste para el nivel de Cloud Interconnect de tu VPN con alta disponibilidad en la implementación de Cloud Interconnect.

    Si las direcciones de la puerta de enlace de VPN con alta disponibilidad no se anuncian, asegúrate de que los adjuntos de VLAN estén asociados con el router encriptado de Cloud Interconnect. Verifica que cada adjunto de VLAN esté configurado con las direcciones IPv4 internas regionales esperadas (--ipsec-internal-addresses).

No se puede establecer la sesión de BGP para el Cloud Router para VPN con alta disponibilidad

Para verificar si la sesión de BGP asociada con el adjunto de VLAN está inactiva, ejecuta el siguiente comando:

gcloud compute routers get-status VPN_ROUTER_NAME

Reemplaza VPN_ROUTER_NAME con el nombre del Cloud Router que creaste para el nivel de VPN con alta disponibilidad de su VPN con alta disponibilidad en la implementación de Cloud Interconnect.

Para solucionar el problema, sigue estos pasos:

  1. Debido a que el tráfico de BGP se enruta a través del túnel VPN, verifica que esté establecido un túnel VPN. De lo contrario, sigue los pasos No se puede establecer un túnel VPN con alta disponibilidad.
  2. Verifica que la interfaz de la sesión de BGP para Cloud Router apunte al túnel VPN correcto.
  3. Verifica que las direcciones IP de la interfaz de sesión de BGP estén configuradas de forma correcta en Cloud Router y en el dispositivo de VPN local.
  4. Comprueba que los números de ASN estén configurados correctamente en Cloud Router y en el router local.

El tráfico de VPC no llega a las redes locales o viceversa

El tráfico generado desde una VM, como ping o iperf, no puede llegar a la red local, o esta red no puede llegar al tráfico generado desde una VM.

Para solucionar el problema, sigue estos pasos:

  1. Debido a que el tráfico de VM se enruta a través del túnel VPN, asegúrate de que Cloud Router envíe la ruta desde la VM hasta el túnel VPN.

  2. Verifica que se establezca la sesión de Cloud Router para VPN con alta disponibilidad. De lo contrario, consulta No se puede establecer la sesión de BGP para el Cloud Router para VPN con alta disponibilidad.

Pérdida de paquetes o capacidad de procesamiento baja

El tráfico desde las VMs en redes de VPC hasta las redes locales o el tráfico desde las redes locales a las redes de VPC se interrumpe.

Observas una pérdida de paquetes o una capacidad de procesamiento baja a través de ping, iperf y otras herramientas de supervisión de redes.

Para solucionar el problema, sigue estos pasos:

  1. Verifica si el adjunto de VLAN está sobrecargado con tráfico. Si es así, distribuye el tráfico en más adjuntos de VLAN o actualiza la capacidad del adjunto.
  2. Comprueba si la VPN con alta disponibilidad está sobrecargada con tráfico. Si es así, crea túneles VPN adicionales en el adjunto de VLAN para redistribuir el tráfico.
  3. Asegúrate de que no haya aumentos repentinos o inesperados en el tráfico. Las transmisiones de TCP pueden verse afectadas por otras transmisiones, como el tráfico de UDP inestable.
  4. Verifica si los paquetes que exceden la MTU del túnel están fragmentados. Asegúrate de que la MTU esté configurada de forma correcta con tus adjuntos de VLAN y verifica que el tráfico de UDP no esté restringido a MSS.

No se puede borrar un adjunto de VLAN encriptado

Recibes el siguiente error cuando intentas borrar un archivo adjunto de VLAN encriptado para la interconexión dedicada o la interconexión de socio:

ResourceInUseByAnotherResourceException

Para solucionar este problema, asegúrate de haber borrado primero todas las puertas de enlace y los túneles de VPN con alta disponibilidad asociados con el adjunto de VLAN encriptado. Para obtener más información, consulta Borra la VPN con alta disponibilidad en Cloud Interconnect.

Tipos de direcciones IP no coincidentes en adjuntos de VLAN encriptados

Cuando intentas crear una puerta de enlace de VPN con alta disponibilidad para usarla en una implementación de VPN con alta disponibilidad en Cloud Interconnect, recibirás el siguiente error:

One of the VLAN attachments has private IP address type, while the other one
has public IP address type; they must have same IP address type.

Este error ocurre cuando especificas dos adjuntos de VLAN encriptados para una puerta de enlace de VPN con alta disponibilidad y estos tienen diferentes esquemas de direccionamiento IP para las interfaces de túnel VPN con alta disponibilidad. La dirección IP deben coincidir entre ambos adjuntos de VLAN.

Durante la creación de la puerta de enlace de VPN, especifica los adjuntos de VLAN que usen direcciones IP privadas o ambas direcciones IP públicas. Si recibes este error cuando creas una puerta de enlace de VPN, vuelve a crear el adjunto de VLAN con el tipo de dirección correcto.

Falta el adjunto de VLAN de la interfaz de puerta de enlace de VPN con alta disponibilidad

Si se implementa para una VPN con alta disponibilidad a través de Cloud Interconnect, una puerta de enlace de VPN con alta disponibilidad debe tener un adjunto de VLAN encriptado especificado para ambas interfaces.

Si especificas solo un adjunto de VLAN, aparecerá el siguiente error:

VPN Gateway should have VLAN attachment specified in both interfaces or in none.

Para solucionar este problema, crea la puerta de enlace de VPN con alta disponibilidad y especificar dos adjuntos de VLAN.

Tipo de adjunto de VLAN no válido

Los adjuntos de VLAN encriptados deben tener el tipo DEDICATED o PARTNER.

Si especificas un tipo no válido para un adjunto de VLAN encriptado, aparecerá el siguiente mensaje de error:

VLAN attachment should have type DEDICATED or PARTNER.

Para solucionar este problema, solo crea adjuntos de VLAN encriptados con el tipo DEDICATED o PARTNER.

Valor de MTU incorrecto para el adjunto de VLAN

Cuando creas un adjunto de VLAN encriptado para la interconexión dedicada, aparece el siguiente mensaje de error:

Wrong MTU value [mtuValue] for VLAN attachment.
The supported MTU for IPsec packets for HA VPN over Cloud Interconnect is 1440.

Para solucionar este problema, vuelve a crear el adjunto con el valor correcto de 1440, que es el valor predeterminado.

Los adjuntos de VLAN tienen un tipo diferente

Cuando especificas adjuntos de VLAN encriptados para tus interfaces de puerta de enlace de VPN con alta disponibilidad, aparece el siguiente mensaje de error:

VLAN attachments should both have same type DEDICATED or PARTNER.
But found one DEDICATED and one PARTNER.

Para solucionar este problema, especifica dos adjuntos de VLAN que sean del mismo tipo DEDICATED o PARTNER.

Los adjuntos de VLAN dedicados no están en la misma área metropolitana

Cuando especificas adjuntos de VLAN encriptados para tus interfaces de puerta de enlace de VPN con alta disponibilidad, aparece el siguiente mensaje de error:

Dedicated VLAN attachments should be in the same metropolitan area.

A fin de solucionar este problema, crea dos adjuntos de VLAN encriptados para la interconexión dedicada en la misma área metropolitana.

La puerta de enlace de VPN con alta disponibilidad no se encuentra en la misma red que el adjunto de VLAN

Cuando especifiques adjuntos de VLAN encriptados para tu VPN con alta disponibilidad de puerta de enlace, aparecerá el siguiente mensaje de error:

VPN Gateway should be in the same network as VLAN attachment.
VLAN attachment network: [networkName], VPN gateway network: [networkName]

Para solucionar este problema, crea la puerta de enlace de VPN con alta disponibilidad en la misma red que los adjuntos de VLAN encriptados.

Tipo de encriptación incorrecto para el adjunto de VLAN

Cuando especificas adjuntos de VLAN encriptados para tus interfaces de puerta de enlace de VPN con alta disponibilidad, aparece el siguiente mensaje de error:

Wrong encryption type for VLAN attachment [interconnectAttachmentName],
required IPSEC.

Para solucionar este problema, especifica solo los adjuntos de VLAN encriptados que estén configurados con el tipo de encriptación IPSEC. Si es necesario, crea adjuntos de VLAN encriptados.

La zona del adjunto de VLAN no coincide con interfaceId

Cuando especificas adjuntos de VLAN encriptados para tus interfaces de puerta de enlace de VPN con alta disponibilidad, aparece el siguiente mensaje de error:

VLAN attachment zone should match interfaceId: interface 0 - zone1,
interface 1 - zone2, but found interface [interfaceId] - [zone] for
[interconnectAttachmentName].

La primera interfaz de puerta de enlace de VPN con alta disponibilidad (interface 0) debe coincidir con el adjunto de VLAN encriptado de la zona 1, y la segunda interfaz (interface 1) debe coincidir con el adjunto de VLAN encriptado de la zona 2.

Para solucionar este problema, especifica los adjuntos de VLAN encriptados de las zonas coincidentes de forma correcta a las interfaces de puerta de enlace de VPN con alta disponibilidad.

La puerta de enlace de VPN no está en la misma región que el adjunto de VLAN

Cuando especificas adjuntos de VLAN encriptados para tus interfaces de puerta de enlace de VPN con alta disponibilidad, aparece el siguiente mensaje de error:

VPN Gateway should be in the same region as VLAN attachment.
VLAN attachment region: [region], VPN gateway region: [region].

Para solucionar este problema, crea puertas de enlace de VPN con alta disponibilidad y adjuntos de VLAN encriptados en la misma región.

El adjunto de VLAN de socio no está en estado activo

Cuando especificas adjuntos de VLAN encriptados para la interconexión de socio para tus interfaces de puerta de enlace de VPN con alta disponibilidad, aparece el siguiente mensaje de error:

Interconnect Attachments [name] must be in active state.

Debes activar los adjuntos de VLAN para la interconexión de socio antes de asociarlos con las interfaces de puerta de enlace de VPN con alta disponibilidad.

Para obtener más información, consulta Cómo activar las conexiones.

Tipo de Cloud Router incorrecto especificado para el adjunto de VLAN

Cuando intentas crear un adjunto de VLAN encriptado, aparece el siguiente mensaje de error:

Router must be an encrypted interconnect router.

Para solucionar este problema, crea un Cloud Router con la marca --encrypted-interconnect-router. Este Cloud Router se usa exclusivamente para VPN con alta disponibilidad en Cloud Interconnect.

Luego, crea el adjunto de VLAN encriptado y proporciona el Cloud Router encriptado.

Cross‑Cloud Interconnect

En esta sección, se describen los problemas que pueden surgir entre Cross Cloud Interconnect.

Google admite la conexión hasta el punto en el que llega a la red de tu otro proveedor de servicios en la nube. Google no garantiza el tiempo de actividad del otro proveedor de servicios en la nube y no puede crear un ticket de asistencia en tu nombre. Sin embargo, con tu permiso, el equipo de Asistente al Google Cloud puede comunicarse directamente con el equipo de asistencia al cliente de tu otro proveedor de servicios en la nube para acelerar la resolución de problemas.

Discrepancias entre puertos redundantes

Después de pedir puertos de Cloud Interconnect, le proporcionas a Google información sobre cómo deseas que los puertos se conecten a tus puertos de nube remota. También usarás esta información más adelante, cuando configures tus recursos. Si tienes problemas de conectividad, es posible que no hayas usado los detalles de conectividad correctos.

Por ejemplo, puedes proporcionar instrucciones como las siguientes:

  • Conectar gcp-1 a azure-1.

  • Conectar gcp-2 a azure-2.

Sin embargo, cuando configuras tus recursos, puedes suponer que los puertos están conectados de la siguiente manera:

  • Conectar gcp-1 a azure-2.

  • Conectar gcp-2 a azure-1.

Esta condición puede detectarse mediante el análisis de la caché ARP. Sin embargo, una solución más simple es ir a la nube remota e intentar intercambiar los rangos de direcciones IP asignados a los dos pares BGP.

Por ejemplo, supongamos que azure-1 tiene un intercambio de tráfico de adjunto de VLAN en 169.254.0.2 y azure-2 tiene un intercambio de tráfico entre adjuntos de VLAN en 169.254.99.2. Intercambia los rangos de direcciones IP para que el adjunto azure-1 use 169.254.99.2 y el adjunto azure-2 use 169.254.0.2.

Si usaste diferentes ID de VLAN para el adjunto de cada puerto, también tendrás que intercambiar los ID de VLAN que usan los adjuntos. Para Azure, esta situación es imposible porque se requiere el mismo ID de VLAN en ambos puertos para cada adjunto.

IDs de VLAN

A veces, se pueden rastrear problemas de conectividad hasta errores con valores de ID de VLAN. El ID de VLAN es un campo en tu adjunto de VLAN de Cloud-Interconnect.

Azure

Azure requiere que los ID de VLAN se asignen de forma idéntica en ambos puertos de un par. Cuando creas el adjunto de VLAN, la consola de Google Cloud aplica este requisito. Sin embargo, si configuras los adjuntos mediante Google Cloud CLI o la API, es posible asignar diferentes IDs de VLAN. Este riesgo es muy grande si permites que los IDs de VLAN se asignen de forma automática cuando creas el adjunto. Si no configuras el ID de forma explícita, se asigna de forma automática.

AWS

Cuando te conectas a AWS, está bien usar la asignación automática de ID de VLAN. Sin embargo, cuando configures los recursos de AWS, debes configurar los IDs de VLAN de forma manual para que coincidan con los que Google Cloud asignó de forma automática. Además, es importante no confundir qué ID de VLAN se debe usar para cada puerto. Si se configura un ID de VLAN incorrecto en un puerto, los routers virtuales no se podrán comunicar.

Verifica la conectividad

Si aún no lo hiciste, sigue los pasos para verificar la conectividad entre Google Cloud y tu red de nube remota: