Usa la siguiente guía para solucionar problemas comunes con las pruebas de conectividad.
Para obtener más información sobre las pruebas de conectividad, consulta la descripción general.
Para interpretar los estados de un análisis de configuración de pruebas de conectividad, consulta los estados de análisis de configuración.
Problemas generales
Toma demasiado tiempo obtener los resultados de la prueba
Debido a que las pruebas de conectividad consultan la última instantánea de la configuración de red de nube privada virtual (VPC), puede demorar un poco obtener resultados. Para obtener más información, consulta los tiempos de respuesta esperados por consulta.
Si experimentas latencias largas o inestables cuando ejecutas Pruebas de conectividad, informa el problema a la Asistencia y describe cómo reproducirlo.
El análisis de configuración de mi prueba no reconoce el cambio de configuración que realicé
Después de realizar un cambio en la configuración de los recursos de Google Cloud en tu ruta de prueba, es posible que desees usar el análisis de configuración de la prueba para validar el cambio. Sin embargo, las pruebas de conectividad tardan entre 20 y 120 segundos en recibir una actualización de configuración y, luego, incorporarlas al análisis. Asegúrate de esperar el tiempo suficiente entre el cambio de configuración y la ejecución de las pruebas.
Ciertos tipos de parámetros de configuración pueden tomar más tiempo en completarse. Si el cambio de configuración no se verifica con las pruebas de conectividad después de un período extendido y se puede reproducir, informa el problema en Asistencia y describe cómo reproducirlo.
Esta demora no se aplica al análisis del plano de datos en tiempo real. Por lo tanto, es posible que veas una discrepancia temporal entre los resultados que se muestran en el análisis del plano de datos en tiempo real y el análisis de configuración. Por ejemplo, si creas una regla de firewall, el análisis de plano de datos en tiempo real suele responder de inmediato a la regla nueva. Sin embargo, es posible que debas esperar 20 segundos o más antes de que el análisis de configuración pueda evaluar la regla de firewall junto con los otros recursos en la ruta de prueba.
Problemas con el estado de la prueba
No puedo acceder a los detalles de una política de firewall jerárquica
El seguimiento de tu prueba puede hacer referencia a una política de firewall jerárquica que no tienes permiso para ver.
Sin embargo, aunque no tengas permiso para ver la política, puedes ver sus reglas aplicadas a tu red de VPC. Para obtener más detalles, consulta Reglas de firewall efectivas en la descripción general de las políticas de firewall jerárquicas.
El acceso a las políticas de firewall jerárquicas se define a nivel de la organización y de la carpetas. Si deseas obtener detalles sobre los permisos que necesitas para ver estas políticas, consulta Identity and Access Management (IAM) en la descripción general de las políticas de firewall jerárquicas.
Mi prueba muestra un estado final de análisis de configuración de Deliver, pero la conectividad está interrumpida
En algunos casos, el análisis de configuración sugiere que se puede acceder a un extremo de origen y de destino. Sin embargo, es posible que, en la práctica, la conectividad se interrumpa entre los dos extremos o que el análisis del plano de datos en vivo muestre una pérdida de paquetes del 100%.
Para comprender esta situación, recuerda que las pruebas de conectividad aplican dos tipos de análisis: un análisis de configuración, que detecta problemas en los parámetros de configuración activos en tu proyecto, y el análisis del plano de datos en vivo, que envía sondeos al plano de datos.
Cuando el estado final de análisis de configuración es
Deliver,
significa que las pruebas de conectividad no detectaron ningún problema de configuración.
Sin embargo, todavía podría haber problemas en la ruta de acceso de datos que causan problemas
de conectividad. Para solucionar el problema, considera lo siguiente:
- La VM de origen o destino experimenta problemas de SO invitado, como el error irrecuperable del kernel del SO invitado, un controlador de interfaz de red (NIC) que no se inicializó o controladores de red incompatibles. Verifica el estado de la VM y la configuración de NIC.
- Un problema generalizado está afectando al plano de datos de la red. Consulta el Panel de rendimiento de tu proyecto y presta especial atención a la pérdida de paquetes para el par de zonas correspondiente. Además, consulta el Google Cloud Panel de estado.
- Tu red está experimentando problemas esporádicos de programación de red, por ejemplo, problemas con la propagación de la configuración de red para entidades específicas de Google Cloud. Considera volver a ejecutar la prueba después de una demora de cinco minutos. Si el problema persiste, detén y vuelve a iniciar la VM de origen o destino, como se describe en Inicia y detén una instancia, y vuelve a ejecutar la prueba.
Mi prueba mostró un resultado general de análisis de configuración de Undetermined
Cuando el resultado de accesibilidad general es
Undetermined,
significa que el análisis de configuración no pudo determinar la conectividad.
Este resultado puede aparecer por cualquiera de los siguientes motivos:
- Se produjo un error de permisos. Por ejemplo, es posible que el usuario no tenga permisos de lectura para todos los recursos nombrados en la prueba.
- Se produjo un error interno.
- El analizador recibió un argumento no válido o no admitido, o no pudo identificar un extremo conocido.
- Estás intentando verificar una ruta que se extiende más allá de Google Cloud. Las pruebas de conectividad no tienen acceso a los parámetros de configuración de red fuera de Google Cloud.
Mi prueba mostró un resultado general de análisis de configuración de Ambiguous
Cuando el resultado general de análisis de configuración es
Ambiguous,
significa que las pruebas de conectividad mostraron varios seguimientos y que
hay un estado final mixto.
En la siguiente tabla, se indican algunos motivos comunes y soluciones para este estado.
| Motivo | Ejemplo | Cómo corregirlo |
|---|---|---|
| La ubicación de la fuente no es única. | Especificaste una dirección IP de origen interna sin especificar la red de VPC en la que se encuentra la dirección IP (una dirección IP de origen interna es una dirección a la que no puedes acceder desde Internet). Dado que se puede acceder a esta dirección desde varias redes de VPC, las pruebas de conectividad podrían iniciar un seguimiento desde cada ubicación. | Actualiza la prueba con la red de VPC en la que se encuentra esta dirección IP. |
| El seguimiento tiene varios destinos posibles. | El destino de seguimiento es un balanceador de cargas que tiene varios backends o uno solo con una política de selección de direcciones IP de PREFER_IPV6, y no se puede acceder a todos los backends en todas las versiones de IP configuradas. | Averigua por qué ocurre esto y corrige los problemas según sea necesario antes de volver a ejecutar la prueba. |
Mi prueba mostró un resultado general de análisis de configuración de Abort con un mensaje de Invalid Argument
A continuación, se indican algunas razones comunes de un mensaje Invalid Argument:
- No se admite la dirección IP que proporcionaste. Los ejemplos incluyen una dirección de bucle invertido, una dirección IP multicast o una dirección IPv6 a una instancia de VM que solo tiene asignada una dirección IPv4.
- La instancia de VM o la red especificada no existe. Esta situación puede ocurrir si se borró la instancia de VM o la red de VPC mientras creabas la prueba.
Cuando se utiliza la API de Network Management, el mensaje Invalid Argument suele
mostrarse por uno de los siguientes motivos:
- Un nombre mal escrito o una ubicación incorrecta para la VM o el URI de red
- Un ID del proyecto especificado de manera incorrecta. Este error ocurre si usaste el nombre del proyecto en lugar de su ID
- Una diferencia entre la dirección IP interna especificada y la red seleccionada. Aunque la consola de Google Cloud para las pruebas de conectividad realiza una validación estricta de la instancia, la red y el proyecto de Compute Engine especificados, este tipo de desigualdad aún puede ocurrir.
El resultado del análisis de configuración es Packet could not be delivered, pero el análisis del plano de datos activo indica que se entregaron todos los paquetes
Esta posible falta de coincidencia podría producirse por varios motivos. Considera las siguientes posibles causas y sus soluciones:
Los cambios recientes en la configuración de la red de VPC causaron una incoherencia entre el análisis de configuración y el sondeo activo. Vuelve a ejecutar la prueba y, si es posible, asegúrate de que la configuración de red no cambie antes o durante la prueba.
Se produjeron problemas esporádicos de programación de la red. Detén y, luego, inicia la VM de origen o de destino, como se describe en Inicia y detén una instancia y vuelve a ejecutar la prueba.
El resultado del análisis de configuración es Packet could be delivered, pero el análisis del plano de datos en tiempo real indica una pérdida parcial del paquete
Esta posible falta de coincidencia podría producirse por varios motivos. Entre las posibles causas y soluciones, se incluyen las siguientes:
La VM de origen o destino se limita mientras supera el ancho de banda de salida o de entrada permitido. Analiza el volumen de tráfico de VM. Para eso, consulta a la página Detalles de la instancia de VM y revisa los detalles en la pestaña Supervisión. Revisa la métrica Bytes de red y compárala con los límites de ancho de banda descritos para el tipo de máquina en Ancho de banda de red.
Un problema generalizado está afectando al plano de datos de la red. Consulta el Panel de rendimiento de tu proyecto y presta especial atención al par de zonas correspondiente. Además, consulta el Panel de estadoGoogle Cloud .
El resultado del análisis de configuración es Packet could be delivered y el análisis del plano de datos en vivo muestra la entrega completa, pero mi aplicación experimenta pérdidas
Esta posible falta de coincidencia podría producirse por varios motivos. Entre las posibles causas y soluciones, se incluyen las siguientes:
- El SO invitado puede bloquear el tráfico (por ejemplo, por reglas de firewall internas). Verifica que el tráfico no esté bloqueado y vuelve a intentar la prueba.
- Los paquetes de datos de la aplicación podrían recorrer una ruta de red diferente a la de los sondeos de análisis del plano de datos en tiempo real. Considera restablecer la conexión de red. Por ejemplo, prueba usar otro puerto de origen.
- El análisis del plano de datos en tiempo real detecta la pérdida unidireccional de paquetes. En tu caso, la pérdida de paquetes puede producirse en la ruta de retorno. Considera ejecutar una prueba en la dirección opuesta.
Los resultados de la prueba no incluyen un resultado del análisis del plano de datos en tiempo real
No todos los parámetros de configuración compatibles con las pruebas de conectividad se pueden verificar con el análisis del plano de datos en tiempo real. Asegúrate de que la prueba cumpla con las condiciones que se requieren para el análisis del plano de datos en tiempo real, como se especifica en la descripción general.
La API de aNetwork Management mostró un INTERNAL_ERROR
Por lo general, este evento no debería ocurrir. Pero si sucede, deberás informar el problema a Asistencia y describir cómo reproducirlo.
Problemas de consola deGoogle Cloud
La consola de Google Cloud para las pruebas de conectividad presentó fallas
Por lo general, la consola de Google Cloud no debería fallar. Pero si sucede, deberás informar el problema a Asistencia y describir cómo reproducirlo.
¿Qué sigue?
- Identificar y solucionar problemas de ICMP (instructivo)