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 Cloud de Confiance Panel de estado. 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 Sí No aplicable
Verifica que el dispositivo local haya obtenido la dirección MAC correcta para el lado de Cloud de Confiance by S3NS de la conexión. Para obtener más información, consulta Solución de problemas de ARP. Sí 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.
 Sí No aplicable Sí

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 Cloud de Confiance de la conexión de Cloud Interconnect se configura con ip proxy-arp, que responde a todas las solicitudes ARP y puede hacer que tu router local aprenda entradas 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. Cloud de Confiance 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 Cloud de Confiance .
  • 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.

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 Cloud de Confiance de una conexión de interconexión dedicada a pedido, consulta Obtén diagnósticos.

Problemas con la Carta de Autorización (LOA)

En estas subsecciones, se abordan los problemas relacionados con la LOA.

No recibiste la LOA en un plazo de 3 días hábiles después de la confirmación del pedido.

Revisa la carpeta de spam o correo no deseado de tu correo electrónico. Si aún no encuentras la carta de autorización, responde el correo electrónico de order_received para comunicarte con Atención al cliente de Cloud y obtener ayuda.

El proveedor de colocación requiere aclaraciones sobre los detalles de la LOA

Actuar como enlace entre el proveedor y Google Responde la notificación por correo electrónico con las preguntas específicas del proveedor, y la Atención al cliente de Cloud puede ayudarte a aclarar los detalles.

Instalación incorrecta de la conexión cruzada

La conexión debe realizarse exactamente como se especifica en la LOA más reciente. Cualquier desviación provocará una falla en la conexión. A menudo, los problemas de configuración que se deben a la desviación de la LOA devuelven un error de "No se detectó luz". Consulta Recibí el error "No se detectó luz" para obtener más información.

Recibiste el error "No se detectó luz"

Cuando recibes el error "No se detectó luz", significa que las pruebas automatizadas de Google no detectan suficiente luz óptica del router local en uno o más puertos. Esto indica un problema en la capa física (capa 1). Sigue estos pasos para solucionar el problema:

  1. Verifica la instalación de la conexión cruzada: Comunícate con tu proveedor de colocación y confirma que se cumplan las siguientes condiciones:

    • Se completó la instalación de la conexión cruzada.
    • La conexión cumple con los puertos especificados en la versión más reciente de la LOA del lado de la demarcación de Google.
    • El proveedor tiene resultados de pruebas, incluidas las lecturas del nivel de luz tomadas con un medidor de potencia óptica en la demarcación de Google, en dirección a tu equipo.

  2. Inspecciona tu infraestructura física: Verifica los siguientes componentes:

    • Asegúrate de que los cables de conexión de fibra sean del tipo correcto y estén conectados de forma segura a los puertos del router, así como a los paneles de conexión intermedios dentro del rack. Busca señales de daños, dobleces pronunciados o nudos en los cables.
    • Verifica tus transceptores (como los SFP y los QSFP):
      • Confirma que el modelo del transceptor sea compatible con tu router y la velocidad de la interconexión dedicada que solicitaste.
      • Asegúrate de que el transceptor esté bien colocado en el puerto del router.
      • Intenta volver a colocar el transceptor. Si tienes un transceptor de repuesto, puedes intentar cambiarlo.
    • Comprueba los LEDs de los puertos físicos del router. Si se detecta una señal, debería iluminarse una luz de vínculo (por lo general, de color verde). La luz apagada o la luz ámbar suelen indicar un problema.
    • Usa las herramientas de limpieza de fibra óptica adecuadas (como los lápices de limpieza) para limpiar los extremos de los cables de fibra y las interfaces ópticas del transceptor. El y los contaminantes son causas muy comunes de pérdida de señal.

  3. Verifica la configuración de los puertos del router: Asegúrate de que la interfaz del router esté habilitada de forma administrativa. No debe estar en estado "apagado". Usa los siguientes comandos para verificar el estado, según tu router:

    • Cisco IOS/NX-OS: Usa el comando show interface [interface]. Si muestra "administrativamente inactiva", ingresa al modo de configuración de la interfaz y usa el comando no shutdown.
    • Juniper Junos: Usa el comando show interfaces [interface]. El "vínculo de administrador" debe estar "activo". Si es necesario, puedes habilitarlo con el comando set interfaces [interface] enable en el modo de configuración.
    • Arista EOS: Usa el comando show interface [interface] status. Si muestra "disabled", ingresa al modo de configuración de la interfaz y usa el comando no shutdown.

  4. Analiza los niveles de luz en tu router: Accede a la CLI del router para verificar los niveles de potencia óptica de transmisión (TX) y recepción (RX). Puedes usar los siguientes comandos de ejemplo para verificar los niveles de potencia, según el fabricante del router:

    • Cisco: show interface [interface] transceiver details
    • Juniper: show interfaces diagnostics optics [interface]
    • Arista: show interface [interface] transceiver dom

    Después de usar el comando, sigue las instrucciones que se indican a continuación para interpretar la información:

    • Potencia de transmisión: Es la potencia con la que transmite el router. Debe estar dentro de la especificación del transceptor (por lo general, de -5 a +2 dBm para la óptica LR estándar). Una potencia de transmisión muy baja sugiere que hay un puerto o una óptica defectuosos de tu lado.
    • Potencia de RX: Es la potencia que recibe tu router de parte de Google. Usa los siguientes rangos de potencia para evaluar la calidad de la vinculación:
      • Buena: Entre -1 dBm y -10 dBm
      • Marginal: Entre -10 dBm y -14 dBm. Es posible que el vínculo sea inestable.
      • Sin señal: Menos de -15 dBm, a menudo se muestra como -30 dBm, -40 dBm o “Baja”, indica que se recibe poca o ninguna luz. Esto apunta claramente a una rotura física, una conexión incorrecta o un problema de polaridad.

  5. Prueba la polaridad de la fibra: Las conexiones de fibra óptica requieren un "cruce". La fibra transmit del router debe conectarse a la fibra receive en la demarcación de Google, y la fibra transmit de la demarcación de Google debe conectarse a la fibra receive del router.

    Para resolver problemas de polaridad, en el router o el panel de conexión, intenta con cuidado "girar" el conector de fibra, intercambiando las posiciones de los dos hilos de fibra dentro del conector dúplex. Si la luz de vínculo se enciende o si los niveles de RX mejoran significativamente, resolviste un problema de polaridad.

  6. Realiza pruebas de bucle invertido: Puedes realizar pruebas de bucle invertido locales y remotas para aislar qué lado de la conexión está experimentando problemas:

    • Bucle local: Usa un conector de bucle de fibra óptica físico en el puerto del router. Esto dirige la señal TX del router de vuelta a su propio puerto RX. Si el estado del puerto cambia a "up", es probable que el puerto y el transceptor del router funcionen correctamente.
    • Bucle de retorno remoto (con el proveedor): Solicita a tu proveedor de coubicación que coloque un bucle invertido físico en la fibra en la demarcación de Google, orientado hacia tu equipo. Si aparece el puerto del router, esto indica que la ruta desde tu router hasta la demarcación de Google es correcta y que el problema podría estar del lado de Google de la demarcación.

  7. Verificar el diagnóstico: Puedes usar el siguiente comando para obtener información de diagnóstico del lado de Google de la conexión:

    gcloud compute interconnects get-diagnostics INTERCONNECT_NAME
   --project=PROJECT_ID

    Reemplaza lo siguiente:

    • INTERCONNECT_NAME: Es el nombre único que asignaste a tu conexión de Interconexión dedicada.
    • PROJECT_ID: el ID de tu proyecto.

    En el resultado, verifica los valores de receivingOpticalPower y transmittingOpticalPower para cada vínculo del array de vínculos. Estos valores muestran lo que ve el equipo de Google. Compara la potencia de recepción de Google con la potencia de transmisión de tu router, y compara la potencia de transmisión de Google con la potencia de recepción de tu router, teniendo en cuenta cierta pérdida de señal a través de la fibra.

  8. Recopila información para el equipo de atención al cliente: Si probaste los pasos anteriores y los problemas persisten, te recomendamos que respondas el correo electrónico del pedido con la siguiente información:

    • Confirmación del proveedor de colocación de que la conexión cruzada se instaló según la LOA más reciente
    • Cualquier resultado de prueba que proporcione el proveedor (como las lecturas del medidor de luz en el punto de demarcación)
    • La configuración completa de las interfaces pertinentes en tu router
    • El resultado completo de los comandos de diagnóstico del nivel de luz del router (como el resultado de show interface transceiver details).
    • Es la salida JSON completa de gcloud compute interconnects get-diagnostics.
    • Los resultados detallados de cualquier intercambio de polaridad o prueba de bucle invertido que se haya realizado.
    • Cualquier alarma o error que registren los registros del router para las interfaces

La configuración de LACP no funciona

Sigue los pasos de esta sección para verificar si hay problemas con la configuración de tu paquete del Protocolo de control de agregación de vínculos (LACP).

  1. Verifica la configuración de LACP en tu router: Comprueba los siguientes parámetros de configuración de LACP en tu router:

    • Todas las interfaces físicas que forman parte de tu conexión de interconexión dedicada deben agruparse en un solo grupo de agregación de vínculos (LAG).
    • LACP debe establecerse en el modo ACTIVE en tu router. Google usa el modo activo de LACP. Si configuras tu lado en modo PASIVO, se evitará que se forme el paquete LACP.
    • Establece los temporizadores de LACP en FAST (1 segundo) o en un parámetro de configuración equivalente en tu dispositivo. Los temporizadores lentos (30 segundos) pueden retrasar la formación de paquetes y fallar en las pruebas automatizadas.
    • Configura los puertos de miembro con los siguientes comandos o combinaciones de comandos, según tu router:
      • Cisco: interface [interface] y, luego, channel-group [number] mode active
      • Juniper: set interfaces [interface] gigether-options 802.3ad ae[number]
      • Arista: interface [interface] y, luego, channel-group [number] mode active
    • Si usas un router Juniper, realiza la configuración de la interfaz LAG con los siguientes comandos: set interfaces ae[number] aggregated-ether-options lacp active, y, luego, set interfaces ae[number] aggregated-ether-options lacp periodic fast.

  2. Analiza el estado de LACP: Usa los siguientes comandos o combinaciones de comandos para verificar el estado de LACP de tu router, según el fabricante:

    • Cisco: show lacp neighbor, luego show lacp internal y, por último, show etherchannel summary.
    • Juniper: show lacp interfaces ae[number].

    • Arista: show port-channel [number] lacp neighbor y, luego, show etherchannel.

    • Verifica que tu router muestre el ID del sistema de Google como su socio de LACP.

    • Verifica que los puertos miembro deben estar en estado "Collecting Distributing" (Recopilando y distribuyendo) (a menudo, se muestran como "Bundled", "Active" o "Up"). Los estados como "Desconectado", "En espera", "Inicialización" o "Suspendido" indican un problema de negociación de LACP.

    • Verifica que los contadores de unidades de datos de LACP (LACPDU) aumenten, lo que indica que se intercambian mensajes de LACP entre tu router y Google.

  3. Recopila información para el equipo de atención al cliente: Si probaste los pasos anteriores y los problemas persisten, te recomendamos que respondas el correo electrónico del pedido con la siguiente información:

    • La configuración completa de LACP de tu router.
    • El resultado completo de los comandos de estado o vecinos de LACP (como show lacp neighbor).

La conectividad de la dirección IP no funciona

Sigue estos pasos para probar la conectividad IP:

  1. La dirección IP de prueba temporal y la máscara de subred que se te proporcionaron en el correo electrónico de productionConfig se deben configurar directamente en la interfaz LAG lógica (como Port-Channel en Cisco/Arista, interfaz AE en Juniper), NO en las interfaces miembro físicas. Usa los siguientes comandos o combinaciones de comandos para verificar que configuraste las direcciones IP de prueba correctamente, según el fabricante del router:

    • Cisco: show running-config interface port-channel [number] y, luego, show ip interface port-channel [number]
    • Juniper: show configuration interfaces ae[number] unit 0 family inet y, luego, show interfaces terse ae[number].0
    • Arista: show running-config interface port-channel [number] y, luego, show ip interface port-channel [number]

  2. Consulta la tabla ARP de tu router para ver si resolvió la dirección MAC de la IP de prueba del lado de Google en la interfaz del LAG. Usa los siguientes comandos:

    • Cisco: show arp | include [Google Test IP]
    • Juniper: show arp no-resolve | match [Google Test IP]
    • Arista: show arp | grep [Google Test IP]

    Una entrada ARP "Incompleta" indica un problema de capa 2 o que Google no responde a las solicitudes ARP.

  3. Realiza una prueba de ping desde la interfaz LAG de tu router a la IP de prueba de Google. Usa el ping de la dirección IP de prueba asignada a tu interfaz de LAG. Cuando hayas recuperado la dirección IP, usa los siguientes comandos según el fabricante del router:

    • Cisco/Arista: ping [Google Test IP] source [Your LAG Test IP]
    • Juniper: ping [Google Test IP] source [Your LAG Test IP]

  4. Asegúrate de que ningún firewall, lista de control de acceso (LCA) o política de seguridad de tu router bloquee LACP (LACP usa EtherType 0x8809) o ICMP Echo/Reply (ping).

  5. Verifica el estado de LACP de tu router con el siguiente comando:

    gcloud compute interconnects get-diagnostics INTERCONNECT_NAME
   --project=PROJECT_ID

    Reemplaza lo siguiente:

    • INTERCONNECT_NAME: Es el nombre único que asignaste a tu conexión de Interconexión dedicada.
    • PROJECT_ID: el ID de tu proyecto.

    Examina el campo lacpStatus de cada uno de tus vínculos. Los valores state, googleSystemId y neighborSystemId indican si Google ve tu router como un socio de LACP y si los estados están sincronizados. Luego, verifica el array arpCache para ver si el lado de Google resolvió el ARP para tu dirección IP de prueba.

  6. Recopila información para el equipo de atención al cliente: Si probaste los pasos anteriores y los problemas persisten, te recomendamos que respondas el correo electrónico del pedido con la siguiente información:

    • Es la configuración de IP de la interfaz de LAG.
    • Es el resultado de la tabla ARP en la LAG.
    • Son los resultados de la prueba de ping basada en la fuente desde la interfaz de LAG.
    • Confirmación de que ningún firewall o ACL bloquea LACP o ICMP
    • Es el resultado JSON completo del comando gcloud compute interconnects get-diagnostics.

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 deCloud de Confiance y 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 Cloud de Confiance de destino y el dominio de disponibilidad perimetral están codificados en la clave de vinculación con 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 tus instancias de Cloud de Confiance VM
  • 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 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.

Las métricas de adjunto de VLAN muestran disminuciones debido a BANDWIDTH_THROTTLE

Cuando visualices las métricas de adjunto de VLAN en Supervisar conexiones, es posible que veas disminuciones debido a BANDWIDTH_THROTTLE. Esto ocurre cuando el tráfico se envía a una velocidad demasiado alta a través del adjunto, por lo que se limita algo de tráfico.

Sin embargo, cuando se visualizan los gráficos de utilización de entrada y salida correspondientes, no se muestran picos de tráfico. Esto se debe a que las métricas se capturan en un intervalo de muestreo de 60 segundos, lo que puede ocultar picos o ráfagas de tráfico breves.

Para solucionar este problema, reduce el uso de este adjunto, aumenta su capacidad o utiliza más adjuntos de VLAN.

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. Con tu permiso, el equipo de Atención al cliente 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. Sin embargo, debes tener un ticket de asistencia abierto con el otro proveedor.

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 Cloud de Confiance 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 Cloud de Confiance asignó automáticamente. 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 Cloud de Confiance y tu red de nube remota: