Visión general
La conectividad del sitio es primordial para que los hosts detrás de un socket tengan acceso a la WAN a través del Cato cloud. La falta de conectividad de un sitio puede interrumpir funciones comerciales. Este manual busca proporcionar orientación sobre cómo solucionar este escenario.
Síntomas
Una falla en la conectividad del socket puede manifestarse de varias maneras. Un administrador puede notar los siguientes síntomas:
- El sitio está desconectado en CMA
-
El sitio se conecta a un PoP inesperado
- Network Analytics muestra que el túnel es inestable
Posibles Causas
Las siguientes son posibles causas que puedes identificar mientras solucionas problemas
- Sin conectividad del socket
- Tráfico DTLS unidireccional
- Rendimiento deficiente del subyacente
- Restricciones de geolocalización de IP
- Configuración de selección de PoP inadecuada
- Configuración de SLA en lineamientos incorrectos
- Dispositivo NAT delante del socket
Solucionando el problema
Los pasos para solucionar los síntomas que puede encontrar un Administrador se enumeran a continuación. Estos pasos están destinados a identificar posibles causas de los problemas enfrentados. Los pasos de resolución se destacarán más adelante en el manual.
Solucionando la desconexión del sitio en CMA
Reunir información de Eventos
Utilizando la página Inicio > Eventos en CMA, un administrador puede obtener rápidamente un historial de eventos de conectividad para los sitios dentro de una cuenta. Los eventos se pueden filtrar para mostrar eventos relevantes seleccionando el ajuste preestablecido 'Sites connectivity status' o filtrando por Event type 'Connectivity' y Sub-type 'Disconnected' Puedes filtrar aún más por el nombre del sitio en cuestión con el campo 'Sitio de origen'.
Ver el sello de tiempo del evento de desconexión relevante del sitio en cuestión puede ayudar a enfocar la investigación. ¿Hubo algún evento más amplio de red o eventos de energía locales conocidos que ocurrieran en este sello de tiempo? ¿Hay cambios en la ruta de auditoría previos a esto que puedan estar correlacionados?
Verificación de conectividad del socket
Consulta los Requisitos previos de conexión del socket de Cato para comprender los requisitos de la conexión de un socket.
El estado de conectividad del socket se puede ver a través de su WebUI local, consulta Iniciar sesión en el Socket WebUI localmente. Para que un socket esté conectado, el puerto WAN que se está utilizando para dar servicio a la conexión al Cato Cloud debe mostrar un icono de estado verde. Un indicador diferente al verde sugiere un problema de conectividad. El significado de los diferentes colores de los iconos de estado se describe en Comprender los iconos de estado de enlace
Para un icono rojo, asegúrate de que hay un enlace físico funcionando entre el socket y el dispositivo ISP. Esto incluye que los cables estén conectados de forma segura y que los LED de los puertos se enciendan como se esperaba.
Un conflicto de IP también será detectado por el estado de conectividad del socket. La advertencia de conflicto de IP continuará mostrándose durante un período de 24 horas, comenzando desde que se detectó por primera vez el conflicto como se explica en este artículo de la base de conocimientos.
Confirma que el estado de Recuperación forzada a través de Internet Bypass debajo de Herramientas sea Normal. El botón 'Forzar Bypass' forzará todo el tráfico LAN a omitir Cato y derribará el túnel de Cato, mostrando el sitio como desconectado en CMA. Por lo tanto, toda la configuración remota y el acceso a este dispositivo fallará. En una configuración HA, si el socket primario tiene 'Desvío forzado' habilitado, el socket secundario continuará como el socket de respaldo, y el tráfico detrás de los sockets se enrutará directamente a Internet.
La captura de pantalla a continuación muestra 'Force Bypass' habilitado en el Socket primario, y el Socket secundario permanece como Respaldo.
Si el estado de recuperación forzada es activo, salga de este estado haciendo clic en el botón Salir de omisión forzada.
En caso de un problema de conectividad, podemos utilizar la pestaña Herramientas para realizar más pruebas. Para conectarse a Cato, el socket requiere acceso a nivel L3 a las direcciones IP públicas de Cato. Utiliza la herramienta de ping para garantizar que este Socket pueda alcanzar direcciones IP o dominios de Cato, o direcciones IP conocidas como 8.8.8.8 a través del puerto WAN directamente. Si ninguna es accesible, por favor consulta la sección Resolución de la falta de conectividad del socket.
Ejecutando captura de paquetes
También se puede realizar una captura de paquetes para garantizar que la solicitud del Socket para establecer un túnel DTLS hacia el PoP esté siendo respondida. Al capturar en el puerto WAN en cuestión, deben verse paquetes bidireccionales en UDP/443 hacia el PoP. La siguiente captura de pantalla muestra un apretón de manos DTLS exitoso y el intercambio de paquetes de Datos de Aplicación.
Si solo se detectan paquetes DTLS salientes o el apretón de manos DTLS está incompleto, por favor consulta Resolución de apretón de manos DTLS incompleto.
Incapaz de establecer un túnel debido a dispositivo NAT frente al socket
Para sockets que utilizan múltiples enlaces WAN, si hay un dispositivo NAT entre el Socket y el PoP, entonces es posible que uno o más de los enlaces WAN no puedan conectarse al PoP. Esto puede crear problemas de conectividad, como que el estado HA del sitio no esté listo.
El PoP utiliza el puerto de origen de cada conexión DTLS entrante para conectar cada enlace WAN al mismo túnel lógico. El dispositivo NAT puede cambiar el puerto de origen e impedir que un enlace WAN se conecte al mismo túnel lógico que los otros enlaces WAN.
Conexiones DTLS fallidas con proveedores LTE/5G
Como se menciona en este estudio de caso, si se utilizan proveedores LTE/5G para conectarse a Cato, es posible que el ISP interfiera con el apretón de manos DTLS en el puerto UDP/443, lo que se puede ver como datos específicos del operador (por ejemplo, APN) durante el apretón de manos.
Aunque hay comunicación DTLS bidireccional, el apretón de manos no se completa; por lo tanto, el túnel de Cato no se establecerá.
Para resolver este problema, cambia el puerto DTLS a UDP/1337, por favor consulta Resolución de apretón de manos DTLS incompleto.
Solucionar la selección inesperada de PoP
Verificar dirección IP del ISP y el PoP seleccionado actualmente
Bajo el monitoreo, selecciona un sitio y abre el panel de visión general del sitio. En la sección de sockets del sitio, haz clic en 'Ver registro' para ver todas las conexiones recientes. Busca la IP pública del ISP (IP remota) que se conecta a Cato, junto con el nombre y la ubicación del ISP. La columna 'PoP' mostrará el PoP actual al que está conectado el sitio.
Es importante verificar que la 'IP remota' y la ubicación del ISP sean las esperadas y que el ISP no esté derivando la conexión a través de una ubicación inesperada. La ubicación del ISP (ciudad) debe corresponder o estar cerca del país/ciudad especificado en la configuración general del sitio dentro de CMA.
Verificar configuración de selección de PoP en CMA
Una ubicación de PoP preferida obsoleta o mal configurada en un sitio puede forzar conexiones a PoPs subóptimos. La configuración de selección de PoP se puede ver por sitio a través de la página Network > Site > Configuración del sitio > General.
Si aquí se configura una ubicación que no parece adecuada para una conexión óptima, o si se prefiere permitir que el mecanismo de selección de PoP de Cato determine el PoP óptimo, por favor consulta la sección Resolución de configuración inadecuada de selección de PoP.
Verificar configuración de selección de PoP en el socket
La configuración de selección de PoP obsoleta o inadecuada también puede existir en la configuración del socket. Para ver si es este el caso, navega a la configuración de conexión a la nube en el webUI del socket, consulta Uso del Socket WebUI.
Si la configuración existe aquí y se prefiere permitir que el mecanismo de selección de PoP de Cato determine el PoP óptimo, por favor consulta la sección Resolución de configuración inadecuada de selección de PoP.
Verificar estado del PoP
Los Sockets pueden conectarse a un PoP inesperado debido a que el PoP geográfico más cercano está siendo afectado por mantenimiento u otro problema similar. Por favor consulta la página de estado del PoP para verificar si este es el caso.
Verificar restricciones de ubicación para la geolocalización
Según el MSA de Cato, los sitios de socket en algunas geolocalizaciones están restringidos para conectarse a PoPs en otras ubicaciones. El MSA se detalla al adquirir servicios de Cato.
Los sitios de socket en algunas geolocalizaciones estarán limitados a un conjunto de PoPs disponibles, por ejemplo, los sitios de socket en China se conectarán a PoPs dentro de China, y los sitios de socket vietnamitas se conectarán a un conjunto de PoPs dentro de Asia.
Para más información sobre esto, por favor consulta el MSA.
Verificar signos de que el socket se mueve entre PoPs
La página de eventos se puede utilizar para determinar si un socket probablemente no está en el PoP óptimo originalmente determinado debido a problemas de conectividad. Utilizando una selección de campos, un cronograma de la conectividad del socket a diferentes PoPs.
Utilizando el ajuste preestablecido de eventos 'Sitio reconectado', y filtrando aún más al sitio en cuestión y también configurando el valor del campo 'mensaje_del_evento' a 'Problema de rendimiento detectado, reconectado a un nodo de servicio diferente en la nube de Cato', podemos ver todas las instancias donde un sitio de socket se ha movido entre PoPs debido a que los parámetros de conectividad del túnel exceden los umbrales de SLA configurados. Si un sitio de socket está excediendo los umbrales de SLA a múltiples PoPs, continúa el flujo de solución de problemas para verificar la configuración de SLA de conexión.
Verificar que la conexión SLA no sea demasiado estricta
La conexión SLA juega un papel importante en garantizar que un sitio esté conectado al PoP óptimo, especialmente en ambientes de red dinámicos con subyacente público como a través de conexiones de Internet del ISP. Sin embargo, una conexión SLA demasiado estricta puede causar reconexiones innecesarias a PoPs que no son la ubicación preferida de un administrador.
La configuración de SLA de conexión por sitio se puede ver en Network > Site > Configuración del sitio > Conexión SLA.
Utilizando Network Analytics para construir una línea base de métricas de rendimiento de última milla, considera si las métricas de SLA son adecuadas para este sitio.
Si estos parámetros no son adecuados, por favor consulta Resolución de configuración de SLA en lineamientos incorrectos
Si los parámetros son adecuados, pero aún ocurren eventos de reoptimización de PoP regularmente a varios PoPs, por favor consulta la sección Resolución de rendimiento deficiente del subyacente.
Si el socket sigue conectándose a un PoP inadecuado después de seguir los pasos anteriores, por favor abre un ticket con soporte y destaca el PoP actual y esperado.
Solucionar túnel inestable
Verificar la correlación entre el rendimiento de última milla y la conexión del sitio
Al observar que un sitio determinado experimenta un rendimiento deficiente en su conexión a un PoP, es importante aislar si esta pérdida de paquetes probablemente se debe al rendimiento en la línea ISP subyacente.
Esto se puede hacer correlacionando cualquier problema de rendimiento dado en un periodo de tiempo con el rendimiento observado en la última milla dentro del mismo intervalo de tiempo y buscando patrones.
Se puede utilizar Network Analytics para hacer esto.
El ejemplo anterior muestra pérdida de paquetes aguas arriba detectada en un túnel del sitio hacia el PoP. Podemos ver varios picos de ~10% y un nivel bajo constante de pérdida durante el periodo de tiempo.
Al comparar esto con el rendimiento de la última milla durante el mismo periodo, podemos ver lo siguiente:
La última milla también puede verse afectada por una variación en el rendimiento, pero está afectada por un nivel constante de pérdida entre ~10-20%. De esto es claro que la pérdida de paquetes en el túnel del socket al PoP de Cato probablemente sea un síntoma de un rendimiento deficiente en el subyacente.
Si este es el caso al solucionar un problema de rendimiento, por favor consulta Resolución de rendimiento deficiente del subyacente
Cruzar referencias de sitios similares
Las propiedades compartidas entre sitios pueden usarse para intentar inferir datos sobre el problema en cuestión. Por ejemplo, el sitio que se muestra a continuación está teniendo problemas de conectividad. Tenga presente que el PoP conectado es Londres:
Esta información puede utilizarse para comparar con otros sitios que puedan estar conectados a Londres para ver si se comparten problemas. Esto se puede ver en la captura de pantalla a continuación:
Si la comparación sugiere que el problema está en un Cato PoP, vea la sección Verificar Estado del PoP.
La comparación también es útil para sitios con ISPs compartidos. Esto se está haciendo en el ejemplo a continuación:
Si esta comparación implica que el ISP tiene problemas de conectividad, vea la sección Resolver Desempeño Deficiente del Subyacente.
Verifique que el Connection SLA no sea demasiado indulgente
SLA de Conexión juega un papel importante para asegurar que un sitio está conectado al PoP óptimo, especialmente en entornos de red dinámicos con subyacente público como a través de conexiones a Internet de ISP. Un SLA de Conexión que sea demasiado indulgente, sin embargo, puede hacer que los sockets mantengan conexiones subóptimas con los PoPs por más tiempo de lo que un administrador desearía, impactando así aplicaciones sensibles.
La configuración de SLA de Conexión por sitio puede verse en Red > Sitio > Configuración del Sitio > SLA de Conexión.
Usando Análisis de Red para construir una línea base de métricas de rendimiento de la última milla, considere si las métricas de SLA son adecuadas para este sitio.
Si estos parámetros no son adecuados, por favor vea Resolución de Configuración de SLA en Líneas Base Incorrectas.
Resolución de Problemas Descubiertos
Resolución de Conectividad de Socket
Es importante aislar si los problemas de conectividad solo afectan al Socket. Si conectas un laptop a la misma conexión ISP, ¿encuentras los mismos problemas al resolver DNS o hacer ping a direcciones? Si es así, contacta a tu ISP para avanzar.
Asegúrate de que el laptop de prueba tenga IPv6 deshabilitado y, en caso de que la asignación de dirección IP sea estática, asigna la misma IP que el Socket al probar.
Si los problemas de conectividad están aislados a tu Socket, asegúrate de que la configuración de IP sea correcta bajo la pestaña Configuración de Red de la WebUI:
Resolución de Handshake Incompleto de DTLS
Asegúrate con tu proveedor que el tráfico DTLS en el puerto UDP 443 esté permitido para salir hacia el internet. Si es necesario, este puerto puede cambiarse a UDP/1337 como se describe en Configuración de un Puerto Diferente para Conectar al Cato PoP.
Resolución de Desempeño Deficiente del Subyacente
Un mal desempeño del subyacente impactará cualquier túnel construido sobre ese subyacente. Mientras que el subyacente es dominio del ISP, hay algunas herramientas que pueden usarse para identificar dónde se introducen los problemas de rendimiento, y también para intentar mitigar problemas de rendimiento donde sea posible.
La WebUI del socket tiene una herramienta de traceroute que te permitirá hacer ping a hosts accesibles públicamente a través de la conexión ISP. Al hacer ping a nombres de host accesibles públicamente, se puede determinar el salto en el que se introduce la pérdida o el retraso excesivo en el camino l3 entre un socket y el servicio.
En el ejemplo anterior, la pérdida de paquetes se introduce claramente directamente desde el límite L3 proporcionado por el ISP.
Mientras que, en última instancia, cualquier problema de subyacente tendrá que ser presentado al ISP, asegurar que la configuración en CMA es correcta ayudará a mitigar el impacto de los problemas de rendimiento. Asegúrate de que la configuración de ancho de banda para una interfaz de socket sea precisa para el ancho de banda proporcionado por la línea. Las herramientas de prueba de velocidad de Socket WebUI pueden realizarse para evaluar el rendimiento de la conexión. Además, reducir los parámetros de explosión de una conexión puede forzar a Cato a activar el motor de QoS más rápido, y permitir que tu tráfico menos prioritario sea descartado en favor de aplicaciones más críticas.
Resolución de Configuración de Selección de PoP Inadecuada
Para revertir cualquier configuración manual de selección de PoP y permitir que Cato seleccione el PoP óptimo para una conexión de socket, primero asegúrate de que no haya configuración manual de ubicación de PoP en CMA, y luego haz lo mismo para el socket.
En CMA, esto puede hacerse en Red > Sitio > General > Ubicaciones de PoP Preferidas.
Asegúrate de que 'Automático' esté seleccionado.
En la WebUI del socket, navega a Configuración de Conexión a la Nube.
Asegúrate de que Destino esté configurado a 'Steering'.
Resolución de Configuración de SLA en Líneas Base Incorrectas
El primer paso para garantizar que la configuración de SLA sea adecuada es entender cuáles son los umbrales críticos o requisitos para aplicaciones críticas en uso desde el sitio.
Para ampliar esto, considere dos ejemplos.
- La Aplicación A es tolerante a bajos niveles de pérdida de paquetes y tiene buenas capacidades de reordenamiento de paquetes, sin embargo, la sesión necesita mantenerse para que el servicio funcione; interrumpir y recrear el flujo causa problemas dentro de la aplicación.
- La Aplicación B es muy sensible a la pérdida de paquetes esporádica. Incluso bajos niveles de pérdida pueden causar que las transferencias de datos se interrumpan y la transferencia tendría que iniciarse nuevamente desde el principio. Dicho esto, el canal de control es muy resistente a que las sesiones terminen y se reconecten.
Con el perfil de la aplicación A, crearíamos una configuración de SLA que permita bajos niveles de pérdida incluso en ventanas de tiempo largas; es preferible retener la conexión al PoP para mantener la sesión incluso si la pérdida está afectando el servicio.
La Aplicación B, en contraste, requiere una configuración de SLA más estricta. Es preferible cambiar de PoP si se detectan incluso pequeñas cantidades de pérdida de paquetes para proteger la integridad de las transferencias.
Los sitios obviamente usan una mezcla de aplicaciones con diferentes perfiles y requisitos. Un administrador tendrá que ser estratégico para equilibrar estas necesidades para una política de SLA adecuada.
Plantear casos al Soporte de Cato
Si siguiendo este manual no se ha resuelto el problema, envíe un ticket de soporte. Para obtener la respuesta más útil a una solicitud, un administrador debe proporcionar resultados de los pasos de solución de problemas llevados a cabo durante el uso de este manual. Incluyendo, por ejemplo:
- Filtros relevantes para llamar la atención sobre eventos específicos.
- Resultados de pruebas de WebUI.
- Hallazgos del Análisis de Redes.
- Requisitos de configuración de SLA.
0 comentarios
Inicie sesión para dejar un comentario.