Guía de resolución de problemas de red

Esta guía describe los pasos colaborativos necesarios para diagnosticar y resolver problemas de rendimiento de la red. Está organizada como un diagrama de flujo priorizado, que comienza con los problemas más sencillos y comunes antes de pasar a investigaciones más complejas.

Requisito previo: revisar las mejores prácticas de la aplicación

Antes de proceder a una investigación en profundidad de la red, es esencial asegurarse de que su aplicación esté diseñada para un rendimiento óptimo. Muchos problemas de rendimiento pueden resolverse abordando el diseño de la aplicación, como las llamadas a la API de alta frecuencia o los desencadenantes ineficientes.

Consulta aquí la guía sobre diseño de aplicaciones.

Si su aplicación ya sigue estas directrices, continúe con las siguientes fases de investigación de la red y los pasos posteriores:

Fase 1: Comprobaciones básicas

Descarta rápidamente, con el mínimo esfuerzo, los problemas locales, del lado del cliente y de la capa física.

1. Ejecuta los diagnósticos actuales desde la estación afectada

• Acción: Ejecuta los siguientes comandos TANTO en el servicio de destino COMO en un punto final público estable y de gran ancho de banda (por ejemplo, google.com o cloudflare.com) para compararlos.
• Ping prolongado (entre 50 y 100 pings o más) para mostrar la latencia mínima, media y máxima, así como la pérdida de paquetes.
• ping 1.1.1.1 (Cloudflare)
• ping 8.8.8.8 (Google)
• pathping (si se utiliza Windows)
• Consultas DNS: nslookup, dig, drill
• Motivo de prioridad: Son los datos más rápidos de recopilar. La prueba comparativa es fundamental y permite saber de inmediato si el problema es específico de la ruta del servicio o si se trata de un problema general de Internet desde esa estación.
• Acción: utiliza la «Comprobación de red» de Tulip
  • Opción 1: en una ventana del navegador, acceda a https://{Su Tulip Instance}.tulip.co/networkCheck
  • Opción 2: desde Tulip Player, haz clic en el menú «Herramientas» y, a continuación, en «Comprobación de red».
  • Revisa los resultados
    • Comprueba si todas las pruebas se superan. Si no es así, haz una captura de pantalla de esta pantalla y pulsa «Descargar diagnóstico». Envía la captura de pantalla y el archivo de diagnóstico a support.tulip.co, y un representante de Tulip podrá ayudarte.
    • También puede compartir estos archivos con su equipo interno de TI para que le ayuden a solucionar el problema.

2. Realiza una inspección física del hardware

• Acción: Realiza una inspección física exhaustiva del hardware de las estaciones afectadas. Comprueba si hay cables Ethernet defectuosos, tarjetas de red mal conectadas o problemas con el puerto físico del conmutador.Motivo de prioridad: Los problemas de la capa física son fundamentales y pueden simular problemas de red más complejos. Descartarlos primero evita perder tiempo en diagnósticos a nivel de software.

3. Verificar la configuración de la estación local

• Acción: Comprueba los ajustes de DNS de la estación, las configuraciones del proxy local (en busca de posibles redireccionamientos), el software de seguridad o cortafuegos local, e investiga los registros del servidor DHCP para confirmar que la estación no está experimentando renegociaciones frecuentes de DHCP.
• Motivo de la prioridad: Se trata de ajustes específicos del cliente que pueden causar problemas a un único usuario sin afectar al resto de la red. Es el siguiente paso lógico tras descartar problemas físicos y generales de Internet.

4. Revisar los registros del sistema local en busca de eventos recientes

• Acción: Desde la estación afectada, comprueba los registros de eventos del sistema (por ejemplo, el Visor de eventos de Windows, la Consola de macOS o journalctl/dmesg en Linux) en busca de errores recientes relacionados con la red, advertencias o cambios significativos que coincidan con el inicio del problema de rendimiento. Busca eventos relacionados con cambios en el estado del adaptador de red, fallos en las asignaciones DHCP, problemas de resolución de DNS o alertas del cortafuegos o del software de seguridad.
• Motivo de prioridad: Esto ayuda a identificar si el problema es de nueva aparición o está relacionado con un cambio de configuración reciente o con un problema de red localizado anterior que pudiera haber dejado rastros en el equipo cliente.

Fase 2: Análisis correlacionado de la infraestructura

Utilice datos de eventos específicos para investigar la infraestructura de red compartida. Esta fase requiere acceso y colaboración del departamento de TI.

5. Identifica las marcas de tiempo y revisa los registros internos

• Acción: Correlaciona los tiempos de ralentización notificados por los usuarios con los registros internos de los dispositivos de red. Busca:
• Alto jitter de red
• Pérdida de paquetes o altas tasas de retransmisión
• Revisar el diagrama de la red y facilitar los registros
• Registros de red correspondientes al periodo en el que se produjo el problema (incluido el proxy, si procede)
• Eventos de congestión de la red local o de saturación del ancho de banda
• Motivo de prioridad: esto centra la investigación en momentos concretos, lo que la hace mucho más eficiente que revisar registros de varios días. Esto debe hacerse antes de recurrir a terceros.

6. Revisar el rendimiento del cortafuegos y de los dispositivos de seguridad

• Acción: Durante las franjas horarias en las que se produjo el problema, revise los registros del cortafuegos y del proxy en busca de conexiones TCP/UDP bloqueadas y compruebe los recursos de los dispositivos (CPU, RAM, conexiones). Además, confirme que todas las direcciones IP y dominios de Tulip necesarios estén actualmente en la lista blanca y no estén sujetos a una inspección excesivamente agresiva que pueda añadir latencia. Presta atención a las métricas específicas del proxy, como los límites de conexión, las sesiones simultáneas y la latencia provocada por la inspección profunda de paquetes.
• Motivo de la prioridad: Los dispositivos de seguridad suelen constituir un cuello de botella. Esto permite comprobar tanto la existencia de reglas de bloqueo explícitas como la degradación del rendimiento debida a una sobrecarga del hardware o a políticas de inspección intrusivas.

7. Examina la configuración de la calidad de servicio (QoS)

• Acción: Si tiene políticas de QoS implementadas, compruebe cómo se clasifica el tráfico hacia y desde los servicios de la aplicación. Asegúrese de que no se le esté restando prioridad accidentalmente.
• Motivo de la prioridad: La configuración incorrecta de la QoS es una causa específica y a menudo pasada por alto de los problemas de rendimiento de las aplicaciones, especialmente durante períodos de alta actividad en la red.

8. Analizar el ancho de banda global y los datos SNMP

• Acción: Revisa el uso máximo de ancho de banda en todo el sitio y comprueba los datos SNMP de los routers y switches para detectar una alta utilización o errores durante los momentos en que se produjo el problema.
• Motivo de la prioridad: Esto determina si el problema está relacionado con la capacidad general de la red o con la contienda.

9. Analizar la ruta de red del proveedor de servicios de Internet (ISP)

• Acción: Ponte en contacto con tu proveedor de servicios de Internet (ISP) y facilítale las marcas de tiempo específicas en las que se produjo una alta latencia.
• Detalles para el ISP: Pídeles que comprueben si hay un enrutamiento subóptimo, congestión en los puntos de interconexión, pérdida de paquetes o aumento de la latencia en sus segmentos o rutas de tránsito, o cualquier política de red relevante activa durante esos momentos concretos.
• Motivo de prioridad: Esto implica a una parte externa y resulta más eficaz cuando se le pueden proporcionar datos precisos y marcas de tiempo procedentes de su investigación interna.

Fase 3: Análisis avanzado en profundidad

Utilice métodos altamente técnicos y que requieran muchos recursos para detectar los problemas más difíciles de identificar.

10. Análisis en profundidad avanzado a nivel de paquetes

• Acción: Realiza una captura completa de paquetes (pcap) en una máquina afectada durante un episodio de ralentización. La clave está en centrarse específicamente en la correlación de marcas de tiempo en todas las capas de análisis. Analiza la captura en busca de manipulación de paquetes (p. ej., cambios en el TTL), errores de protocolo (retransmisiones TCP) o mensajes de error ICMP específicos.
• Motivo de la prioridad: Este es el paso más complejo. Proporciona la verdad definitiva, pero se reserva para cuando todas las demás investigaciones hayan fracasado a la hora de encontrar la causa.